Re: [GLISS] - alternative viewpoint
Hi all, On Mon, Sep 17, 2012 at 11:28 PM, Janek Warchoł wrote: > James, > >> [...] > > Now i feel offended, both as a user and a developer. > At first i was going to write a long reply to your email, but then i > thougt that it would only result in more misunderstandings. Can we > chat, either using text or voice? I'd really like to solve this > situation. In case you worry about this: we sorted it out - it turned out to be a really big misunderstanding on my side: James was only pretending to be an i-don't-care-fix-that-you-lazy-bum user ;) I thought that he was serious, lol! :) cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
"Sue Daniels" writes: > Graham Percival wrote Sunday, September 23, 2012 7:50 AM > >> On Sat, Sep 22, 2012 at 01:42:46PM +0200, Marc Hohl wrote: >> >>> So I repeat my proposal again: a developer *must* include >>> regression tests, he *should* do the doc work, but if he feels >>> not very comfortable at writing some paragraphs for the >>> docs, he should *have to* raise an issue about that. >> >> I don't think that piling up a bunch of issues will help. Rather, >> we should try to not alienate our existing documentation writers, >> and once that's done, recruit new doc writers. It wouldn't be >> hard for somebody to write docs for every new feature between each >> release. > > I'd prefer to see an issue raised for the documentation by the developer > at the time the new feature is pushed to staging. Otherwise it is likely > to be forgotten. It was only by chance that I happened to find the > change to \time recently and my first action was to raise an issue to > document it. If documentation is to be done as a separate activity it > should be done under an issue anyway, to keep the Bug Squad happy. The only previous documentation of set-time-signature had been in Documentation/snippets/new/conducting-signs,-measure-grouping-signs.ly and the code updated this. Ok, a snippet is not really a substitute for real documentation, so apologies. I only remembered that I eradicated set-time-signature completely including rewriting its documentation, but I did not remember it had been so flimsy to start with. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Graham Percival wrote Sunday, September 23, 2012 7:50 AM > On Sat, Sep 22, 2012 at 01:42:46PM +0200, Marc Hohl wrote: > >> So I repeat my proposal again: a developer *must* include >> regression tests, he *should* do the doc work, but if he feels >> not very comfortable at writing some paragraphs for the >> docs, he should *have to* raise an issue about that. > > I don't think that piling up a bunch of issues will help. Rather, > we should try to not alienate our existing documentation writers, > and once that's done, recruit new doc writers. It wouldn't be > hard for somebody to write docs for every new feature between each > release. I'd prefer to see an issue raised for the documentation by the developer at the time the new feature is pushed to staging. Otherwise it is likely to be forgotten. It was only by chance that I happened to find the change to \time recently and my first action was to raise an issue to document it. If documentation is to be done as a separate activity it should be done under an issue anyway, to keep the Bug Squad happy. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Hello, On 24 September 2012 09:22, Jan Nieuwenhuizen wrote: > David Kastrup writes: > >> I think it was during the documentation of the footnote stuff that we >> came up with several examples (including use of s1*0/<>) that made clear >> that we were better off refining the code rather than the documentation. >> >> And that's fine. Changing code because it would be too embarrassing to >> document it is certainly a better option than leaving it undocumented. > > New functionality must come with minimal documentation, otherwise it > does not exist. We cannot expect from documentation writers to work > from reading the code. > I think we kind of had this conversation a few months (last year?) and that the very least it should appear here: http://lilypond.org/doc/v2.16/Documentation/changes/index.html Most developers do try, or at least say there is no/should be documentation for a new feature. @devs-in-general I've always offered to tidy up any submitted documentation (i.e. via email or text file) and form a patch if that is too time consuming; all I ask is to suggest an appropriate place/section that it should go - this saves me a lot of time. The hardest thing to come up with are 'good' lilypond examples - indeed the footnote documentation in the NR (initially) was spawned from Mikes own reg tests, that is better than nothing. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
David Kastrup writes: > I think it was during the documentation of the footnote stuff that we > came up with several examples (including use of s1*0/<>) that made clear > that we were better off refining the code rather than the documentation. > > And that's fine. Changing code because it would be too embarrassing to > document it is certainly a better option than leaving it undocumented. New functionality must come with minimal documentation, otherwise it does not exist. We cannot expect from documentation writers to work from reading the code. Jan -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Am 23.09.2012 08:50, schrieb Graham Percival: On Sat, Sep 22, 2012 at 01:42:46PM +0200, Marc Hohl wrote: Am 21.09.2012 11:00, schrieb David Kastrup: A user interface change without documentation or regtest is dead code. Regtests are somewhat mandatory: http://lilypond.org/doc/v2.17/Documentation/contributor/write-regression-tests but the documentation work is not a "you'll have to do" but rather a "it would be nice if" rule. Yes, that's deliberate. There's no point holding back programmers who are not comfortable writing code. Yes, that's how I understand it as well. But at least there should be some automatism that raises an issue "xyz-needs documentation" whenever a patch has made it through the revision process but lacks of a proper documentation (*if* the patch concerns a major change, like my bar line stuff). There's already some sort of this: git diff -u -r release/2.14.0-1 -r release/2.15.95-1 \ input/regression/ then check if the new features were added to the docs. It's already listed in the Major release checklist, although we skipped over it at Waltrop. Ah, ok. The word 'automatism' was perhaps not the best choice – I had something like a developer's rule in mind: "If you have a strong feeling that this patch does something overwhelming and the documentaion is not changed accordingly, thou mightst raise an issue for that." (carved in stone, scanned, and included in the CG, of course ;-) In my case, I *will* tackle documentation if nobody else wants to, because I know that this feature needs a change in the docs, but the patch itself has undergone quite 60+ comments (part 1 and 2 altogether), so when the documentation work would have been included yet, I think we would be at 100+ (or I had already given up ;-). I suggest doing the documentation as a separate patch. Of course. We might as well remove it before the next stable release. No. So I repeat my proposal again: a developer *must* include regression tests, he *should* do the doc work, but if he feels not very comfortable at writing some paragraphs for the docs, he should *have to* raise an issue about that. I don't think that piling up a bunch of issues will help. Rather, we should try to not alienate our existing documentation writers, and once that's done, recruit new doc writers. It wouldn't be hard for somebody to write docs for every new feature between each release. Well, my idea was: (a) to avoid that this issue gets lost (b) not to alienate the documentation writers, of course! (c) helping them to find the issues where the docs have to be improved (d) to include the user community by announcing these issues on -user, because (e) if a user finds out that doing such a task is not very difficult, he might at some point turn into a developer ;-) Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
James writes: > But I believe unless we now do something that is backward-incompatible > with a (yet) undocumented function in the Notation or Learning manuals > that we don't hold back the patch for the code, it would be nice to > have it all documented as well, but that isn't always the case. > > The later footnote syntax was a case in point (I think) where we did > change the syntax significantly enough that the old documentation > would have been incorrect as opposed to incomplete/missing, we > couldn't really push that on the users until had had been documented. Well, it is unrealistic to expect both code and documentation to be created entirely linearly, without the need of iterations. In fact, sometimes it is while documenting things that it becomes clear that an interface was chosen ill-advisedly. And then it sometimes makes sense to restart the interface design. I think it was during the documentation of the footnote stuff that we came up with several examples (including use of s1*0/<>) that made clear that we were better off refining the code rather than the documentation. And that's fine. Changing code because it would be too embarrassing to document it is certainly a better option than leaving it undocumented. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Hello, On 23 September 2012 11:14, David Kastrup wrote: > "Sue Daniels" writes: > >> Graham Percival wrote Sunday, September 23, 2012 7:50 AM >> > >> If documentation is to be done as a separate activity it should be >> done under an issue anyway, to keep the Bug Squad happy. > > The initial batch of documentation is really the task of the original > author. You can't expect a good documentation writer to decipher the > code and take a guess what it does. But with some luck, a good > documentation writer has the skills or experience to decipher what a > good coder mistakes for good documentation, and take a guess at what it > was supposed to mean. That is exactly what happened with Mike Solomon's original footnote and pure-unpure container documentation - I still couldn't tell you what one is now, but Mike at least created a half formed patch and sent it to me, I tidied it up - a lot of the 'work' is also understanding/remembering the texinfo syntax and CG guidelines - gave it back to Mike to make sure it still made technical sense, he gave me another edit and explained what I hadn't got quite right (lost in translation so to speak) and it went back and forth a bit. Then when it was ok (for me and Mike) I, as a Doc editor, made a patch and then others chipped in. Mike had the good grace to answer the comments even though I submitted the patch (it was his work after all) and I then made the appropriate edits. But I believe unless we now do something that is backward-incompatible with a (yet) undocumented function in the Notation or Learning manuals that we don't hold back the patch for the code, it would be nice to have it all documented as well, but that isn't always the case. The later footnote syntax was a case in point (I think) where we did change the syntax significantly enough that the old documentation would have been incorrect as opposed to incomplete/missing, we couldn't really push that on the users until had had been documented. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
"Sue Daniels" writes: > Graham Percival wrote Sunday, September 23, 2012 7:50 AM > >> On Sat, Sep 22, 2012 at 01:42:46PM +0200, Marc Hohl wrote: >> >>> So I repeat my proposal again: a developer *must* include >>> regression tests, he *should* do the doc work, but if he feels >>> not very comfortable at writing some paragraphs for the >>> docs, he should *have to* raise an issue about that. >> >> I don't think that piling up a bunch of issues will help. Rather, >> we should try to not alienate our existing documentation writers, >> and once that's done, recruit new doc writers. It wouldn't be >> hard for somebody to write docs for every new feature between each >> release. > > I'd prefer to see an issue raised for the documentation by the developer > at the time the new feature is pushed to staging. Otherwise it is likely > to be forgotten. It was only by chance that I happened to find the > change to \time recently and my first action was to raise an issue to > document it. I want to point out that the original issue also included documentation. I readily admit that the quality and discoverability of it might have warranted the attention of more capable documentation writers, but it is not of the "I change this for my own sake and don't care whether it will or even can be useful to anybody else ever after" quality. > If documentation is to be done as a separate activity it should be > done under an issue anyway, to keep the Bug Squad happy. The initial batch of documentation is really the task of the original author. You can't expect a good documentation writer to decipher the code and take a guess what it does. But with some luck, a good documentation writer has the skills or experience to decipher what a good coder mistakes for good documentation, and take a guess at what it was supposed to mean. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
On Sat, Sep 22, 2012 at 01:42:46PM +0200, Marc Hohl wrote: > Am 21.09.2012 11:00, schrieb David Kastrup: > >A user interface change without documentation or regtest is dead code. > Regtests are somewhat mandatory: > > http://lilypond.org/doc/v2.17/Documentation/contributor/write-regression-tests > > but the documentation work is not a "you'll have to do" but rather a > "it would be nice if" rule. Yes, that's deliberate. There's no point holding back programmers who are not comfortable writing code. > But at least there should be some automatism that raises an > issue "xyz-needs documentation" whenever a patch has made it > through the revision process but lacks of a proper documentation > (*if* the patch concerns a major change, like my bar line stuff). There's already some sort of this: git diff -u -r release/2.14.0-1 -r release/2.15.95-1 \ input/regression/ then check if the new features were added to the docs. It's already listed in the Major release checklist, although we skipped over it at Waltrop. > In my case, I *will* tackle documentation if nobody else wants to, > because I know that this feature needs a change in the docs, but > the patch itself has undergone quite 60+ comments (part 1 and 2 > altogether), so when the documentation work would have been > included yet, I think we would be at 100+ (or I had already given > up ;-). I suggest doing the documentation as a separate patch. > >We might as well remove it before the next stable release. No. > So I repeat my proposal again: a developer *must* include > regression tests, he *should* do the doc work, but if he feels > not very comfortable at writing some paragraphs for the > docs, he should *have to* raise an issue about that. I don't think that piling up a bunch of issues will help. Rather, we should try to not alienate our existing documentation writers, and once that's done, recruit new doc writers. It wouldn't be hard for somebody to write docs for every new feature between each release. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
On Sat, Sep 22, 2012 at 1:42 PM, Marc Hohl wrote: > It would be interesting to post such issues on the -user list, > because this would give users a possiblility to contribute *and* > to describe the new feature from a user's point of view which > is not a bad thing, after all. +1. It would also be a good check whether the issue has good enough description - without good description a user wouldn't know what it's supposed to do. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
On Thu, Sep 20, 2012 at 11:56 AM, David Kastrup wrote:
> David Kastrup writes:
>
>> Within your own scores, be consistent in your choices. How this
>> consistency looks, does not matter. Within LilyPond, there is a large
>> consistency which elements are uppercase, and which lowercase. The one
>> thing that actually gets annoying is CamelCase. However, as a rule,
>> camelcase starts with lowercase letters. With recent changes in the
>> lexer, it would be possible to replace the CamelCase words with dashed
>> words. That would allow for things like
>>
>> \slur-up \slur-down \voice-one \one-voice \voice-two and so on. I am
>> personally not a big fan of CamelCase. You would, of course, get the
>> same principal problem "I can't remember where and whether to put
>> dashes" when making use of that option.
>>
>> Weeding out CamelCase would not, in itself, change the classes of things
>> that we use uppercase for, lowercase for, and dashes for (there would be
>> some overlap in classes since we _do_ have a few existing
>> words-with-dashes and \commands-with-dashes, but distinguishing those
>> classes is actually not important, unlike the pure lower/uppercase
>> distinction we actually use for Grob and Context names).
>
> Just quoting this as yet another example where I offer some concrete
> suggestions in a GLISS thread with nobody bothering to even reply.
I apologize. My reply is:
1) i agree that changing CamelCase to dashes won't solve the problem.
2)
> Weeding out CamelCase would not, in itself, change the classes of things
> that we use uppercase for, lowercase for, and dashes for (there would be
> some overlap in classes since we _do_ have a few existing
> words-with-dashes and \commands-with-dashes, but distinguishing those
> classes is actually not important,
you mean that we could change different naming styles that GrobNames,
property-names and Engraver_names have? So that all of them would be,
for example, in CamelCase? I think doing so might be a good idea - i
remember it was very confusing for me when i was a beginner.
> unlike the pure lower/uppercase
> distinction we actually use for Grob and Context names).
I'm not sure i understand - you are referring to the fact that
lowercase strings are note names, while upper case denotes Grobs and
Contexts? Or that grobs and contexts differ in case somewhere?
>> I don't think that this characterization is doing justice to the
>> developers since it basically assumes that their main incentive is
>> making fun of users.
>>
>> Part of the reason working on LilyPond is less rewarding than it could
>> be is this atmosphere of distrust, and the urge to rein in developers
>> who apparently have nothing better to do than damage LilyPond.
>
> "distrust" is maybe too strong a word. "non-involvement" may be closer
> to the truth. Regarding the GLISS discussions and proposals in that
> context becoming official project policy, participation of programmers
> is actively discouraged. Goals are being set without bothering to look
> at how the existing and developing code base and its underlying design
> will support them.
Sure, we shouldn't set goals without looking at how the existing and
developing code base and its underlying design will support them.
However, apart from GLISS' general goal ("let's improve the syntax") i
don't remember any specific goal that was actually set, nor any
decision finally made. Maybe i overlooked something - can you point
me to some goal that was set already? All i see is a lot of pondering
about ideas, in a "what about doing x?" manner.
> For me, one of the pillars of userfriendliness is
> coherence of design. When a user is able to predict how to do
> something.
+1
> If programmers are not supposed to participate in the design
> process,
Are you referring to Graham's suggestion that you should not bother
about current GLISS discussions? Or something else?
> and non-programmers will not be participating in executing this
> design, we get to the situation where those who have the means of
> implementing a design will do this ad-hoc, stealthily, and without
> communication or coordination.
indeed, that is bad.
> "Stealthily" may seem like too strong a word, but quite a few of the
> actual usability/language features are proposed and finally implemented
> in the way we see in
> http://code.google.com/p/lilypond/issues/detail?id=2717>. There is
> minimal feedback by few persons (this particular issue has already
> gotten more feedback than usual in its changingfirst iterations and will
> presumably pass into LilyPond silently once nobody can think of
> something to particularly dislike).
i apologize for not participating in that discussion.
> If you take a look at our "Changes" file from 2.16 and take a look at
> how many of those changes were the result from following through with
> active and planned policy decisions rather than spontaneously done work,
> it does not appear that our purported planning
Re: [GLISS] - alternative viewpoint
On Sun, Sep 16, 2012 at 6:05 PM, David Kastrup wrote:
> Janek Warchoł writes:
>> Hmm, this sounds complicated. Do you mean that implementing more
>> informative ("custom") error messages with current parser will wreak
>> havoc, but if we simplify the parser first, it would be possible to do
>> this in a sane way?
>
> No. I don't mean "wreak havoc" but rather "will be in the way while I
> am still reworking the parser internals".
ok
> It's like putting up tapestry
> and setting up furniture before doing the plumbing.
I'd say that this situation has a high probability of wreaking havoc
on tapestry and furniture :)
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Hi, i'm sorry for the delay :-( There are so many emails flying around that i find it hard to keep up. Don't feel obliged to reply to any "i don't understand" part - i have so many emails to write that some of my questions may remain unanswered. On Sun, Sep 16, 2012 at 6:02 PM, David Kastrup wrote: > Janek Warchoł writes: > >> On Sat, Sep 15, 2012 at 10:20 AM, David Kastrup wrote: >>> b) our C++ engravers announce to the type system (and via that, to the >>> documentation) which context properties they read, modify and write. >>> There is no reason that this does not also include the Grob descriptions >>> which are even now a special case of context property. >> >> I didn't understand this part well, but it guess it's not that >> important to have me understand it now (?). > > Take a look in the internals manual. It knows which engravers access > which context properties. Hmm. I thought that i will see chordNameLowercaseMinor listed under Chord name engraver (http://lilypond.org/doc/v2.17/Documentation/internals-big-page#chord_005fname_005fengraver), but i don't. > A Grob is actually just a (substructured) > context property, That's surprising to me. > so it can be documented in the same manner. agreed. >> (i write this just to provide you with feedback on the difficulty of >> some of your emails) > > This is the developer list, after all. In my opinion the difference between user and developer list should be mostly in topics discussed, not necessarily in the difficulty of the emails. Granted, some things are impossible to make really easy, though. >> So, >> \override BarNumber #'font-size = 5 >> would actually result in >> \override Score.BarNumber #'font-size = 5 >> ? > > Yes, that's the idea. As long as you have no engraver at Staff level > looking at the BarNumber properties. Maybe it would be more robust to > explicitly declare the default context for writing each property. After > all, that is a one-time job. Maybe. > Or declare an engraver "canonical" for some properties, so that if > _that_ engraver is moved, the default context moves along. At the > current point of time, an engraver declares which properties it > reads/modifies/writes (why do we need all three?), and we might let it > declare which it "owns" with respect to the default context. I don't have any opinion here, sorry. >>> Of course, this is not without drawback either: if there are multiple >>> engravers looking at that property at multiple levels and you are >>> interested in overriding the behavior of the engraver in an outer >>> level, the unspecific override will be done in the inner level and >>> again not have an apparent effect. >> >> I think i won't understand this w/o an example. > > Write an engraver at Staff level which looks at currentBarNumber, and > \override currentBarNumber will just work at Staff level instead of > Score level. Ah, ok. Thanks. >>> One might argue that users who are able to write to a mailing list >>> after looking for it in the manual make up for less than 1% of our >>> targeted demographic group, users who come to LilyPond not primarily >>> since they enjoy being in total control over the data structures >>> their typesetting program uses. >>> >>> And particularly for those it makes a big selling point if naive >>> expectations disregarding the technical necessities and >>> implementation constraints happen to hit the mark semi-regularly. Of >>> course, we can't make that 100%, but 80% is a lot more encouraging >>> than 2%. If you get everything wrong at first try, that's a big >>> turnoff. Even if some smart helpful guy explains to you why >>> everything is wrong. >> >> If i understand correctly, you mean that we don't have many emails >> from people being confused by pre/postfix issues because these people >> never make it to the mailing list (i.e. they are too discouraged by >> their first Lily try that they quit immediately)? I think you're >> right. *We* may never notice that some change simplified things >> (because we're already used to Lily), but newcomers will. > > I think that if your first five attempts to do something on your own all > end catastrophically, you'll just quit again. I don't understand why you wrote "again" here. >>> a) reflection. Should \displayLilyMusic recognize expressions that >>> can be produced by a wrapper and output them? If we answer "yes" to >>> that question, it would make sense to provide some infrastructure >>> for specifying appropriate reverse engineering rules to LilyPond in >>> a manner that is not significantly more complex to specify than the >>> wrapper itself. >> >> I don't understand what you mean here. > > \displayLilyMusic \once\erase Accidental > > might choose to display \once\erase Accidental instead of > > \once\override Accidental #'stencil = ##f > > But for that there must be an easy way to teach \displayLilyMusic about > \erase. Ah, i think i understand now. Therefore, my ans
Re: [GLISS] - alternative viewpoint
Am 21.09.2012 11:00, schrieb David Kastrup: Marc Hohl writes: But I don't want to tackle around with the documentation *yet* while it is not sure that my patch gets accepted and the new interface is considered a good idea by most of the developers. So while in an ideal world every programmer enhances the documentation on the fly, I don't think it would be a good idea to *force* them to do so. A user interface change without documentation or regtest is dead code. Regtests are somewhat mandatory: http://lilypond.org/doc/v2.17/Documentation/contributor/write-regression-tests but the documentation work is not a "you'll have to do" but rather a "it would be nice if" rule. I am quite sure that there are people who are better in writing documentation than in programming and the other way round. But at least there should be some automatism that raises an issue "xyz-needs documentation" whenever a patch has made it through the revision process but lacks of a proper documentation (*if* the patch concerns a major change, like my bar line stuff). In my case, I *will* tackle documentation if nobody else wants to, because I know that this feature needs a change in the docs, but the patch itself has undergone quite 60+ comments (part 1 and 2 altogether), so when the documentation work would have been included yet, I think we would be at 100+ (or I had already given up ;-). We might as well remove it before the next stable release. Of course. So I repeat my proposal again: a developer *must* include regression tests, he *should* do the doc work, but if he feels not very comfortable at writing some paragraphs for the docs, he should *have to* raise an issue about that. It would be interesting to post such issues on the -user list, because this would give users a possiblility to contribute *and* to describe the new feature from a user's point of view which is not a bad thing, after all. Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Marc Hohl writes: > But I don't want to tackle around with the documentation *yet* while > it is not sure that my patch gets accepted and the new interface is > considered a good idea by most of the developers. So while in an > ideal world every programmer enhances the documentation on the fly, I > don't think it would be a good idea to *force* them to do so. A user interface change without documentation or regtest is dead code. We might as well remove it before the next stable release. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Am 21.09.2012 00:31, schrieb Thomas Morley: [...] Hi David, Marc, speaking only for me: I'm terrible sorry that I currently can't give you the feedback you desire. Since my injury, I wasn't able to concentrate on any more involved project or to finish any larger one. Also, I let Marc alone with the bar-line-code, we started to tackle together. Marc, please accept my apologies. No problem for me at all – I had some bad feelings that I grabbed your ideas and modified it to my needs without some discussion with you. I hope that's ok for you. So I mostly limited my activities to answer questions on the user-list, FWIW. And you do a great job there, BTW! But perhaps you may accept some summarizing thoughts about involving users in the development-process. (Most of them already mentioned) Or better: why it doesn't work, currently. Thinking of an average user, subscribing the user-list only: (1) He's often not informed that sth is planned/discussed/in-work. Sure. (2) If he's informed and looks at the code on Rietveld, he doesn't know what to do with it, because very often there's no example/regtest/snippet _how_ to use the new syntax/feature/code/whatever. Ok, Rietveld is not the place to put in such additional, illustrating examples, etc. But I think you get my point. Ok. But this means that the programmer who worked on the patch should do the documentation part at the same time, so that any one will understand what the patch is all about. I second this if it is about writing inline comments in the source code. I did this with by current bar line patch, because more often than not I have to try to understand some parts of a programm *I* had written myself some months ago. But for the bar line patch: I would be glad if someone else wanted to write some paragraphs about the new interface, but I think this task will be mine anyway ;-) But I don't want to tackle around with the documentation *yet* while it is not sure that my patch gets accepted and the new interface is considered a good idea by most of the developers. So while in an ideal world every programmer enhances the documentation on the fly, I don't think it would be a good idea to *force* them to do so. So, you either have to figure out for yourself how the patch is supposed to work (as a user), or there is a possibility to include some small test files that show the functionality. I think *every* developer has some 'quicktest.ly' files around that he uses for testing, and they would serve as a testbed for anyone trying to get a grip on the new stuff. (3) Thinking of more involved tasks like testing a patch (and managing the tools needed to do so), I assume this is not a task an average-user is expected to manage, with the current system. At least I had some larger problems installing LilyDev (I wasn't able to install the required fontforge-version, I had to ask for help) Also, learning how to deal with the new world of git-commands is time-consuming. etc etc So I repeat my proposal: in this case we need *precompiled* test versions. I don't know if that is feasible in terms of disk space and work load (it had to be done on GUB), but at least patches with a major impact on lilypond's usability/syntax/whatever could then easily be tested by a broader user community if this just means to download and install an executable and recompile your current scores with it. Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Sorry, forgot to complete the mail adresses. 2012/9/20 David Kastrup : > Marc Hohl writes: [...] > But we don't have users involved either. And those are actually the > ones for which such additions are made. Involving them instead in a > planning stage largely disconnected from actual developments is a poor > substitute. [...] > the target audience are users (a superset of developers, > hopefully). But we don't have them involved in the feedback. > > And I don't think we should wait with getting them involved until my > devious plan of turning users into programmers almost without noticing > bears fruit. > >> Do you propose that the user base should get more information >> about development work? > > Yes. > >> When working on tablature features, I got an *overwhelming* >> response of other users, a lot of "how about x/can you do y" >> stuff which more often than not found its way into tablature.scm. >> >> In other areas, the response was about nil. >> >> So there is no common rule how to get people involved. > > Sure. But with our issue tracker, users don't get involved as a rule. > Even on issues started from a user report. > >>> We definitely can make use of a _lot_ more of this kind of user >>> involvement and exchange of knowledge, interest, and inspiration, but I >>> don't see that the syntax discussions and decisions detached from the >>> actual development are facilitating this. >> >> Well, I am still not sure about the latter. > > Within specific sub-areas like tablature support, this apparently works > better than when LilyPond as a whole is concerned. > > "Let's write a subsystem/package for this" is just much more manageable > than "let's change LilyPond as a whole". > > Obviously, we should strive to change LilyPond as a whole in order to > make it easier to delegate problems to the subsystem/package level. > That allows for much more parallelized processing. > > -- > David Kastrup Hi David, Marc, speaking only for me: I'm terrible sorry that I currently can't give you the feedback you desire. Since my injury, I wasn't able to concentrate on any more involved project or to finish any larger one. Also, I let Marc alone with the bar-line-code, we started to tackle together. Marc, please accept my apologies. So I mostly limited my activities to answer questions on the user-list, FWIW. But perhaps you may accept some summarizing thoughts about involving users in the development-process. (Most of them already mentioned) Or better: why it doesn't work, currently. Thinking of an average user, subscribing the user-list only: (1) He's often not informed that sth is planned/discussed/in-work. (2) If he's informed and looks at the code on Rietveld, he doesn't know what to do with it, because very often there's no example/regtest/snippet _how_ to use the new syntax/feature/code/whatever. Ok, Rietveld is not the place to put in such additional, illustrating examples, etc. But I think you get my point. (3) Thinking of more involved tasks like testing a patch (and managing the tools needed to do so), I assume this is not a task an average-user is expected to manage, with the current system. At least I had some larger problems installing LilyDev (I wasn't able to install the required fontforge-version, I had to ask for help) Also, learning how to deal with the new world of git-commands is time-consuming. etc etc So I second Marc: 2012/9/20 Marc Hohl : > but in other cases > you'll need a way to allow users to test patches, and that's more > difficult, -Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
[sorry, forgot to hit "Reply to all"] Am 20.09.2012 19:02, schrieb David Kastrup: Marc Hohl writes: [...] The problem is not people not interested in this kind of discussions/proposals. The problem is people who stop being interested in an oh so important problem the moment one tries offering different, more feasible solutions than what they were thinking of. If the problem is not important enough to give feasible approaches at a solution serious consideration (which most certainly would include explaining in which way they appear inferior to the less feasible approaches), then it is hard to consider it important enough to bother with the infeasible approaches. That's true. I can only speak for myself, but the main "problem" is that most of the time I can spend for working on LilyPond is put into the actual patches; the reviewing process is handled rather shabbily, I confess. With regard to reviewing user interface additions, it may indeed be the case that other developers don't care much since they could get along fine previously, trust they'll get along fine in future, and maybe trust other developers not to do all too much damage. But we don't have users involved either. And those are actually the ones for which such additions are made. Involving them instead in a planning stage largely disconnected from actual developments is a poor substitute. +1 [...] Do you propose that the user base should get more information about development work? Yes. [...] Within specific sub-areas like tablature support, this apparently works better than when LilyPond as a whole is concerned. The strategy to split the development process into sub-areas and announce them on -user might be a good plan; this means that someone has to provide a reasonable "interface" so that users can be easily informed about topic x. This is probably easy when topic x is about extending some features or defining new features lilypond should have, but in other cases you'll need a way to allow users to test patches, and that's more difficult, I think (except there is a way to extend the automatic patch test mechanism so that users can download special precompiled versions of lilypond including a certain patch set and test it thoroughly before this feature becomes official). "Let's write a subsystem/package for this" is just much more manageable than "let's change LilyPond as a whole". Obviously, we should strive to change LilyPond as a whole in order to make it easier to delegate problems to the subsystem/package level. That allows for much more parallelized processing. +1 Do you already have a strategy how to split the whole system into subsystems? Do you think of extending the way the work on lilypond is done at present (i.e. the patch revision system and the code guidelines stay mostly unchanged) or rather to allow for something like the macro packages in LaTeX, where anyone can roll his own package, writes a documentation for it and may upload it on some server? Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Marc Hohl writes: > Am 20.09.2012 11:56, schrieb David Kastrup: >> David Kastrup writes: >> >>> Within your own scores, be consistent in your choices. How this >>> consistency looks, does not matter. Within LilyPond, there is a large >>> consistency which elements are uppercase, and which lowercase. The one >>> thing that actually gets annoying is CamelCase. However, as a rule, >>> camelcase starts with lowercase letters. With recent changes in the >>> lexer, it would be possible to replace the CamelCase words with dashed >>> words. That would allow for things like >>> >>> \slur-up \slur-down \voice-one \one-voice \voice-two and so on. I am >>> personally not a big fan of CamelCase. You would, of course, get the >>> same principal problem "I can't remember where and whether to put >>> dashes" when making use of that option. >>> >>> Weeding out CamelCase would not, in itself, change the classes of things >>> that we use uppercase for, lowercase for, and dashes for (there would be >>> some overlap in classes since we _do_ have a few existing >>> words-with-dashes and \commands-with-dashes, but distinguishing those >>> classes is actually not important, unlike the pure lower/uppercase >>> distinction we actually use for Grob and Context names). >> Just quoting this as yet another example where I offer some concrete >> suggestions in a GLISS thread with nobody bothering to even reply. > It is not that I am not interested in this kind of > discussions/proposals, it is just that I have no problem > with camelCase/uppercase/lowercase stuff, so I don't need > a change here; on the other hand, if this would make it > easier for everyone, then I would not object to a > "lilypond is all lowercase" change. The problem is not people not interested in this kind of discussions/proposals. The problem is people who stop being interested in an oh so important problem the moment one tries offering different, more feasible solutions than what they were thinking of. If the problem is not important enough to give feasible approaches at a solution serious consideration (which most certainly would include explaining in which way they appear inferior to the less feasible approaches), then it is hard to consider it important enough to bother with the infeasible approaches. > I can only speak for myself, but the main "problem" is that most of > the time I can spend for working on LilyPond is put into the actual > patches; the reviewing process is handled rather shabbily, I confess. With regard to reviewing user interface additions, it may indeed be the case that other developers don't care much since they could get along fine previously, trust they'll get along fine in future, and maybe trust other developers not to do all too much damage. But we don't have users involved either. And those are actually the ones for which such additions are made. Involving them instead in a planning stage largely disconnected from actual developments is a poor substitute. > I take a look at nearly *every* issue when I got an email > notification, but I often do not find the time to get deeper into the > problem to understand what the current proposal means or what the > patch to be review actually does. And just a quick "LGTM, but not > tested" doesn't help anybody. That's more or less topical for code changes, like the stuff Mike does. For documentation and user interface changes (probably with the exception of things like "try removing the closed music category" which focuses on obliterating behavior that was not really suitable for documenting), the target audience are users (a superset of developers, hopefully). But we don't have them involved in the feedback. And I don't think we should wait with getting them involved until my devious plan of turning users into programmers almost without noticing bears fruit. > Do you propose that the user base should get more information > about development work? Yes. > When working on tablature features, I got an *overwhelming* > response of other users, a lot of "how about x/can you do y" > stuff which more often than not found its way into tablature.scm. > > In other areas, the response was about nil. > > So there is no common rule how to get people involved. Sure. But with our issue tracker, users don't get involved as a rule. Even on issues started from a user report. >> We definitely can make use of a _lot_ more of this kind of user >> involvement and exchange of knowledge, interest, and inspiration, but I >> don't see that the syntax discussions and decisions detached from the >> actual development are facilitating this. > > Well, I am still not sure about the latter. Within specific sub-areas like tablature support, this apparently works better than when LilyPond as a whole is concerned. "Let's write a subsystem/package for this" is just much more manageable than "let's change LilyPond as a whole". Obviously, we should strive to change LilyPond as a whole in order to make
Re: [GLISS] - alternative viewpoint
Am 20.09.2012 11:56, schrieb David Kastrup: David Kastrup writes: Within your own scores, be consistent in your choices. How this consistency looks, does not matter. Within LilyPond, there is a large consistency which elements are uppercase, and which lowercase. The one thing that actually gets annoying is CamelCase. However, as a rule, camelcase starts with lowercase letters. With recent changes in the lexer, it would be possible to replace the CamelCase words with dashed words. That would allow for things like \slur-up \slur-down \voice-one \one-voice \voice-two and so on. I am personally not a big fan of CamelCase. You would, of course, get the same principal problem "I can't remember where and whether to put dashes" when making use of that option. Weeding out CamelCase would not, in itself, change the classes of things that we use uppercase for, lowercase for, and dashes for (there would be some overlap in classes since we _do_ have a few existing words-with-dashes and \commands-with-dashes, but distinguishing those classes is actually not important, unlike the pure lower/uppercase distinction we actually use for Grob and Context names). Just quoting this as yet another example where I offer some concrete suggestions in a GLISS thread with nobody bothering to even reply. It is not that I am not interested in this kind of discussions/proposals, it is just that I have no problem with camelCase/uppercase/lowercase stuff, so I don't need a change here; on the other hand, if this would make it easier for everyone, then I would not object to a "lilypond is all lowercase" change. I don't think that this characterization is doing justice to the developers since it basically assumes that their main incentive is making fun of users. Part of the reason working on LilyPond is less rewarding than it could be is this atmosphere of distrust, and the urge to rein in developers who apparently have nothing better to do than damage LilyPond. "distrust" is maybe too strong a word. "non-involvement" may be closer to the truth. Regarding the GLISS discussions and proposals in that context becoming official project policy, participation of programmers is actively discouraged. Goals are being set without bothering to look at how the existing and developing code base and its underlying design will support them. I think that defining _goals_ can be done seriously only by taking the underlying design, the developers etc. into account, but _discussions_ should have any amount of freedom they need. [...] "Stealthily" may seem like too strong a word, but quite a few of the actual usability/language features are proposed and finally implemented in the way we see in http://code.google.com/p/lilypond/issues/detail?id=2717>. There is minimal feedback by few persons (this particular issue has already gotten more feedback than usual in its first iterations and will presumably pass into LilyPond silently once nobody can think of something to particularly dislike). You are right. I can only speak for myself, but the main "problem" is that most of the time I can spend for working on LilyPond is put into the actual patches; the reviewing process is handled rather shabbily, I confess. I take a look at nearly *every* issue when I got an email notification, but I often do not find the time to get deeper into the problem to understand what the current proposal means or what the patch to be review actually does. And just a quick "LGTM, but not tested" doesn't help anybody. If you take a look at our "Changes" file from 2.16 and take a look at how many of those changes were the result from following through with active and planned policy decisions rather than spontaneously done work, it does not appear that our purported planning is connected much to what actually gets done, and users could exercise more influence if they actually commented on issues in the tracker accompanying actual work in progress rather than participating in a hypothetical discussion detached from the realities of both our code base and worker base. One issue/review that recently profited a lot from interaction of developers and users was http://code.google.com/p/lilypond/issues/detail?id=2823> where people cooperated in collecting and completing information, leading to a much better informed approach to actual work. If you take a look at _who_ collected the various bits of information, however, you'll see the usual suspects again: seasoned programmers, just that some of them acted in the capacity of users in the context of this issue. Do you propose that the user base should get more information about development work? When working on tablature features, I got an *overwhelming* response of other users, a lot of "how about x/can you do y" stuff which more often than not found its way into tablature.scm. In other areas, the response was about nil. So there is no common rule how to get people involved. We definitely can make use of a _
Re: [GLISS] - alternative viewpoint
David Kastrup writes: > Within your own scores, be consistent in your choices. How this > consistency looks, does not matter. Within LilyPond, there is a large > consistency which elements are uppercase, and which lowercase. The one > thing that actually gets annoying is CamelCase. However, as a rule, > camelcase starts with lowercase letters. With recent changes in the > lexer, it would be possible to replace the CamelCase words with dashed > words. That would allow for things like > > \slur-up \slur-down \voice-one \one-voice \voice-two and so on. I am > personally not a big fan of CamelCase. You would, of course, get the > same principal problem "I can't remember where and whether to put > dashes" when making use of that option. > > Weeding out CamelCase would not, in itself, change the classes of things > that we use uppercase for, lowercase for, and dashes for (there would be > some overlap in classes since we _do_ have a few existing > words-with-dashes and \commands-with-dashes, but distinguishing those > classes is actually not important, unlike the pure lower/uppercase > distinction we actually use for Grob and Context names). Just quoting this as yet another example where I offer some concrete suggestions in a GLISS thread with nobody bothering to even reply. > I don't think that this characterization is doing justice to the > developers since it basically assumes that their main incentive is > making fun of users. > > Part of the reason working on LilyPond is less rewarding than it could > be is this atmosphere of distrust, and the urge to rein in developers > who apparently have nothing better to do than damage LilyPond. "distrust" is maybe too strong a word. "non-involvement" may be closer to the truth. Regarding the GLISS discussions and proposals in that context becoming official project policy, participation of programmers is actively discouraged. Goals are being set without bothering to look at how the existing and developing code base and its underlying design will support them. For me, one of the pillars of userfriendliness is coherence of design. When a user is able to predict how to do something. If programmers are not supposed to participate in the design process, and non-programmers will not be participating in executing this design, we get to the situation where those who have the means of implementing a design will do this ad-hoc, stealthily, and without communication or coordination. "Stealthily" may seem like too strong a word, but quite a few of the actual usability/language features are proposed and finally implemented in the way we see in http://code.google.com/p/lilypond/issues/detail?id=2717>. There is minimal feedback by few persons (this particular issue has already gotten more feedback than usual in its first iterations and will presumably pass into LilyPond silently once nobody can think of something to particularly dislike). If you take a look at our "Changes" file from 2.16 and take a look at how many of those changes were the result from following through with active and planned policy decisions rather than spontaneously done work, it does not appear that our purported planning is connected much to what actually gets done, and users could exercise more influence if they actually commented on issues in the tracker accompanying actual work in progress rather than participating in a hypothetical discussion detached from the realities of both our code base and worker base. One issue/review that recently profited a lot from interaction of developers and users was http://code.google.com/p/lilypond/issues/detail?id=2823> where people cooperated in collecting and completing information, leading to a much better informed approach to actual work. If you take a look at _who_ collected the various bits of information, however, you'll see the usual suspects again: seasoned programmers, just that some of them acted in the capacity of users in the context of this issue. We definitely can make use of a _lot_ more of this kind of user involvement and exchange of knowledge, interest, and inspiration, but I don't see that the syntax discussions and decisions detached from the actual development are facilitating this. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Janek Warchoł writes: > The most efficient way of doing things doesn't have to be the one > which makes people most happy/satisfied. Free software is a labor of love. People put their heart in it and identify with [their work on] the project, which inevitably leads to violent disagreements. Key is remember that everyone shares a similar love for the project and get into violent agreement. Discussions are good. When a discussion starts to include personal attacks, it has already gone to far. It is no longer a discussion, it's a fight. The first thing to do is to stop taking part -- to stop the flow of emails. The best thing to do next is to restore the personal connection by voice chat. And if there's no personal connection yet, try a video chat or come to the next developers meeting. If you haven't experienced this already, you'll be amazed how meeting someone in person can dissolve any willingness to fight. Easiest is if the other guy does this, so try to be the other guy. Jan -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
>> ... but as David has correctly mentioned previously, it is not >> fruitful to discuss something for a long time and make everyone >> agree to it, just to find out later on that the idea can't be >> implemented in the current framework. > > I agree that doing so isn't fruitful. However, it may be better to > waste some time and be sure that something is a bad idea than not to > discuss it at all and have bad feelings about it. Of course. However, we had some discussions, then David essentially said `this won't work', and people were still discussing exactly the same thing as if David hadn't said anything. > The most efficient way of doing things doesn't have to be the one > which makes people most happy/satisfied. The most efficient way of doing things is to listen to others, not ignoring the arguments. Sometimes David's replies are lengthy and hard to understand, but noone except you has explicitly said `I don't understand'. It's obviously much easier to skip such answers instead of trying to grasp them. I must confess that this sometimes happens to me also. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Janek Warchoł writes: > On Sat, Sep 15, 2012 at 5:25 PM, Werner LEMBERG wrote: >> >>> If there is widespread agreement that the idea is good, then at some >>> point it could be implemented. >> >> ... but as David has correctly mentioned previously, it is not >> fruitful to discuss something for a long time and make everyone agree >> to it, just to find out later on that the idea can't be implemented in >> the current framework. > > I agree that doing so isn't fruitful. However, it may be better to > waste some time and be sure that something is a bad idea than not to > discuss it at all and have bad feelings about it. Our track record for decreasing bad feelings through discussion certainly offers a lot of room for improvement. > The most efficient way of doing things doesn't have to be the one > which makes people most happy/satisfied. Ah, but this is a hobbyist project. Its ultimate goal is to make more people happy. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
On Sat, Sep 15, 2012 at 5:25 PM, Werner LEMBERG wrote: > >> If there is widespread agreement that the idea is good, then at some >> point it could be implemented. > > ... but as David has correctly mentioned previously, it is not > fruitful to discuss something for a long time and make everyone agree > to it, just to find out later on that the idea can't be implemented in > the current framework. I agree that doing so isn't fruitful. However, it may be better to waste some time and be sure that something is a bad idea than not to discuss it at all and have bad feelings about it. The most efficient way of doing things doesn't have to be the one which makes people most happy/satisfied. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
James,
On Sat, Sep 15, 2012 at 3:45 PM, James wrote:
>
>> Third, the numbers of short user-definable abbreviations gets halved.
>> Something like
>>
>> F = \markup { "Horn in F" }
>>
>> would no longer be possible because \f is already in use.
>
> So what? You are a developer, fix that. I do want to not have to
> remember what case I am supposed to be using.
Now i feel offended, both as a user and a developer.
At first i was going to write a long reply to your email, but then i
thougt that it would only result in more misunderstandings. Can we
chat, either using text or voice? I'd really like to solve this
situation.
best,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
2012/9/17 David Kastrup : > Francisco Vila writes: > >> 2012/9/16 David Kastrup : >>> This is the developer list, after all. >> >> Hey, I have the Dragon Book in my bedside table, I can give a language >> to my daughter for her birthday, and still find some things difficult. > > Why am I the one figuring out then until which time I can swap out the > lookahead token of an LALR(1) parser from under it without getting it > into unrecoverable states? No children, perhaps? The rainbow of specific circumpstances is endless. > At any rate, this is the developer list. Some things _are_ difficult > but that does not means that one should be precluded from talking about > them. It's not like I try to be opaque or anything. I fully agree, but a sound feedback, whatever our level is, is always good. -- 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
Re: [GLISS] - alternative viewpoint
Francisco Vila writes: > 2012/9/16 David Kastrup : >> This is the developer list, after all. > > Hey, I have the Dragon Book in my bedside table, I can give a language > to my daughter for her birthday, and still find some things difficult. Why am I the one figuring out then until which time I can swap out the lookahead token of an LALR(1) parser from under it without getting it into unrecoverable states? I'm an electrical engineer, not a computer scientist. At any rate, this is the developer list. Some things _are_ difficult but that does not means that one should be precluded from talking about them. It's not like I try to be opaque or anything. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
2012/9/16 David Kastrup : > This is the developer list, after all. Hey, I have the Dragon Book in my bedside table, I can give a language to my daughter for her birthday, and still find some things difficult. -- 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
Re: [GLISS] - alternative viewpoint
Janek Warchoł writes: > Hi, > > On Sat, Sep 15, 2012 at 10:20 AM, David Kastrup wrote: >> Yup. Here is my multi-stage plan for that: > > Great! It's inspiring to see such a big plan :) > >> b) our C++ engravers announce to the type system (and via that, to the >> documentation) which context properties they read, modify and write. >> There is no reason that this does not also include the Grob descriptions >> which are even now a special case of context property. > > I didn't understand this part well, but it guess it's not that > important to have me understand it now (?). Take a look in the internals manual. It knows which engravers access which context properties. A Grob is actually just a (substructured) context property, so it can be documented in the same manner. > (i write this just to provide you with feedback on the difficulty of > some of your emails) This is the developer list, after all. >> d) \override xxx is equivalent to \override Bottom.xxx, with Bottom >> being a context without \defaultchild (to be recursively created from >> the current context, if that is not a bottom context, by creating the >> respective defaultchildren in sequence until hitting bottom). If all >> our engravers had correctly registered the context properties they read, >> \override xxx could instead set the property in the context closest to >> bottom that will actually _look_ at the changed property. > > So, > \override BarNumber #'font-size = 5 > would actually result in > \override Score.BarNumber #'font-size = 5 > ? Yes, that's the idea. As long as you have no engraver at Staff level looking at the BarNumber properties. Maybe it would be more robust to explicitly declare the default context for writing each property. After all, that is a one-time job. Or declare an engraver "canonical" for some properties, so that if _that_ engraver is moved, the default context moves along. At the current point of time, an engraver declares which properties it reads/modifies/writes (why do we need all three?), and we might let it declare which it "owns" with respect to the default context. > Wonderful! >> Of course, this is not without drawback either: if there are multiple >> engravers looking at that property at multiple levels and you are >> interested in overriding the behavior of the engraver in an outer >> level, the unspecific override will be done in the inner level and >> again not have an apparent effect. > > I think i won't understand this w/o an example. Write an engraver at Staff level which looks at currentBarNumber, and \override currentBarNumber will just work at Staff level instead of Score level. >> #'4 and #4 and 4 should be quite equivalent in most cases... > > You mean that they are quite equivalent now or that we want them to be > equivalent in the future? Where function arguments are concerned, they are equivalent. Not everything is a function argument, and #4 or #'4 cannot be used as a duration. > Anyway, being equivalent in most cases is, in my opinion, only > marginally helpful: exceptions to the "most cases" introduce > confusion. If we want to simplify things, we need equivalence in all > cases. 4 has several different meanings, #4 is a number. I don't think I want #4 . to be a valid duration. >> One might argue that users who are able to write to a mailing list >> after looking for it in the manual make up for less than 1% of our >> targeted demographic group, users who come to LilyPond not primarily >> since they enjoy being in total control over the data structures >> their typesetting program uses. >> >> And particularly for those it makes a big selling point if naive >> expectations disregarding the technical necessities and >> implementation constraints happen to hit the mark semi-regularly. Of >> course, we can't make that 100%, but 80% is a lot more encouraging >> than 2%. If you get everything wrong at first try, that's a big >> turnoff. Even if some smart helpful guy explains to you why >> everything is wrong. > > If i understand correctly, you mean that we don't have many emails > from people being confused by pre/postfix issues because these people > never make it to the mailing list (i.e. they are too discouraged by > their first Lily try that they quit immediately)? I think you're > right. *We* may never notice that some change simplified things > (because we're already used to Lily), but newcomers will. I think that if your first five attempts to do something on your own all end catastrophically, you'll just quit again. >> There are several lashback issues connected with convenience wrappers, >> and they focus around the question: >> >> To what degree does a convenience wrapper become part of LilyPond's >> language? > > Good question. I think this is what Graham had in mind when he wrote > about "ly vs. ly++". > >> There are several questions following from that starting point. >> >> a) reflection. Should \displayLilyMusic recognize ex
Re: [GLISS] - alternative viewpoint
Janek Warchoł writes:
> On Sat, Sep 15, 2012 at 11:35 AM, David Kastrup wrote:
>>
>> You mean, currently we basically see the default error message from the
>> parser generator. Improving this involves basically accepting errors in
>> input and acting on them by putting out hand-tailored messages.
>>
>> Currently, the parser is still undergoing significant restructuring work
>> in major areas and mechanisms. That work entails a lot of time spent on
>> ironing out parser conflicts where some input would correspond to
>> multiple and diverging interpretations according to the current syntax.
>> It is significant work ironing out those conflicts. Adding additional
>> rules for erroneous input means more potential for conflict, so it would
>> make the ongoing work even harder. I am working towards recognizing
>> elements of the syntax in isolation, and then pasting them together.
>> The "pasting together" is then done outside of the immediate control of
>> the parser and can trigger independent error messages based on the
>> assumption that at least the elements used for combining were, by
>> themselves, recognized correctly. Those error messages can be more
>> specific and helpful than the boilerplate parse errors from the parser
>> generator.
>
> Hmm, this sounds complicated. Do you mean that implementing more
> informative ("custom") error messages with current parser will wreak
> havoc, but if we simplify the parser first, it would be possible to do
> this in a sane way?
No. I don't mean "wreak havoc" but rather "will be in the way while I
am still reworking the parser internals". It's like putting up tapestry
and setting up furniture before doing the plumbing.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
On Sat, Sep 15, 2012 at 11:35 AM, David Kastrup wrote:
>
> You mean, currently we basically see the default error message from the
> parser generator. Improving this involves basically accepting errors in
> input and acting on them by putting out hand-tailored messages.
>
> Currently, the parser is still undergoing significant restructuring work
> in major areas and mechanisms. That work entails a lot of time spent on
> ironing out parser conflicts where some input would correspond to
> multiple and diverging interpretations according to the current syntax.
> It is significant work ironing out those conflicts. Adding additional
> rules for erroneous input means more potential for conflict, so it would
> make the ongoing work even harder. I am working towards recognizing
> elements of the syntax in isolation, and then pasting them together.
> The "pasting together" is then done outside of the immediate control of
> the parser and can trigger independent error messages based on the
> assumption that at least the elements used for combining were, by
> themselves, recognized correctly. Those error messages can be more
> specific and helpful than the boilerplate parse errors from the parser
> generator.
Hmm, this sounds complicated. Do you mean that implementing more
informative ("custom") error messages with current parser will wreak
havoc, but if we simplify the parser first, it would be possible to do
this in a sane way?
On Sat, Sep 15, 2012 at 11:53 AM, Phil Holmes wrote:
> - Original Message - From: "David Kastrup"
>> You need to elaborate. It is not clear what you mean with that, and
>> what kind of remedy you envision.
>
> \new Staff works. \New staff doesn't. There's no reason for that - we
> don't have two separate \new \New commands that do different things, nor two
> contexts Staff and staff that are different. Worse is that \slurUp works
> but only with that precise casing. TBH this specific one doesn't cause me
> worry, since I remember it, but there are much more arcane casings that I
> have to refer to the manual to find - so I can remember the command, but not
> the casing!
I think we should make the casing/naming uniform across all names, for example:
\New Staff
\SlurUp
LyricExtenderEngraver
SomePropertyName
> From a user perspective, it would be much simpler if everything
> they write was ToLower()-ed before further processing.
This sounds interesting to me, but David signalled an important
problem - distinguising notenames (which are always lower case) from
grob names ant other things.
Another solution would be to have Frescobaldi auto-correct the casing.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Hi, On Sat, Sep 15, 2012 at 10:20 AM, David Kastrup wrote: > Yup. Here is my multi-stage plan for that: Great! It's inspiring to see such a big plan :) > b) our C++ engravers announce to the type system (and via that, to the > documentation) which context properties they read, modify and write. > There is no reason that this does not also include the Grob descriptions > which are even now a special case of context property. I didn't understand this part well, but it guess it's not that important to have me understand it now (?). (i write this just to provide you with feedback on the difficulty of some of your emails) > d) \override xxx is equivalent to \override Bottom.xxx, with Bottom > being a context without \defaultchild (to be recursively created from > the current context, if that is not a bottom context, by creating the > respective defaultchildren in sequence until hitting bottom). If all > our engravers had correctly registered the context properties they read, > \override xxx could instead set the property in the context closest to > bottom that will actually _look_ at the changed property. So, \override BarNumber #'font-size = 5 would actually result in \override Score.BarNumber #'font-size = 5 ? Wonderful! > Of course, this is not without drawback either: if there are multiple > engravers looking at that property at multiple levels and you are > interested in overriding the behavior of the engraver in an outer level, > the unspecific override will be done in the inner level and again not > have an apparent effect. I think i won't understand this w/o an example. > #'4 and #4 and 4 should be quite equivalent in most cases... You mean that they are quite equivalent now or that we want them to be equivalent in the future? Anyway, being equivalent in most cases is, in my opinion, only marginally helpful: exceptions to the "most cases" introduce confusion. If we want to simplify things, we need equivalence in all cases. > One might argue that users who are able to write to a mailing list after > looking for it in the manual make up for less than 1% of our targeted > demographic group, users who come to LilyPond not primarily since they > enjoy being in total control over the data structures their typesetting > program uses. > > And particularly for those it makes a big selling point if naive > expectations disregarding the technical necessities and implementation > constraints happen to hit the mark semi-regularly. Of course, we can't > make that 100%, but 80% is a lot more encouraging than 2%. If you get > everything wrong at first try, that's a big turnoff. Even if some smart > helpful guy explains to you why everything is wrong. If i understand correctly, you mean that we don't have many emails from people being confused by pre/postfix issues because these people never make it to the mailing list (i.e. they are too discouraged by their first Lily try that they quit immediately)? I think you're right. *We* may never notice that some change simplified things (because we're already used to Lily), but newcomers will. > There are several lashback issues connected with convenience wrappers, > and they focus around the question: > > To what degree does a convenience wrapper become part of LilyPond's > language? Good question. I think this is what Graham had in mind when he wrote about "ly vs. ly++". > There are several questions following from that starting point. > > a) reflection. Should \displayLilyMusic recognize expressions that > can be produced by a wrapper and output them? If we answer "yes" to > that question, it would make sense to provide some infrastructure > for specifying appropriate reverse engineering rules to LilyPond in > a manner that is not significantly more complex to specify than the > wrapper itself. I don't understand what you mean here. > b) When and how are third-party tools supposed to learn about such > wrappers when they are supposed to be part of LilyPond? ditto. > c) MusicXML? ditto. >> And providing error messages when an override has no effect because it >> was at the voice context and should have been at staff? > > See above. If the system knows what needs to be done, there is little > point in warning rather than doing it. Of course, if "Voice" has been > explicitly specified rather than via the implicit "Bottom.", using the > same mechanisms and internally available information for producing a > warning seems reasonable. Basically I prefer the behaviors: > > a) implicit default choice is non-working -> make the right choice instead > b) explicit choice is non-working -> obey but warn +1! > Now one might argue that this currently is rather a discussion on > meta-bikeshedding, namely getting something right that will serve as a > template for future bikeshedding, but it is quite clear that with > convenience wrappers, everybody actually _can_ contribute his opinion > without requirin
Re: [GLISS] - alternative viewpoint
On Fri, Sep 14, 2012 at 6:56 PM, Phil Holmes wrote:
> What does get me more concerned is how hard it is to find some of the
> correct ways of tweaking output. Using voice.SomeValue (or is it
> Voice.someValue) when it should be staff.Somevalue (or was it
> Staff.someValue) frequently results in no change to the output. And is it
> \override or \set? And \revert or \override back to something else. And
> finding what comes after the \override staff.Something - is it ##f. or #'4
> or 4 or { 4} or what?
I agree, this is a problem.
> I personally think that providing more of these simple syntax features would
> make it much easier for the average user
+1
On Fri, Sep 14, 2012 at 7:10 PM, m...@mikesolomon.org
wrote:
> consider doing Z" or even a "?" token one can put before or after an object
> to have help messages
> printed to the logfile as well as detailed information about the command in
> question and what it applies to.
interesting idea.
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
David Kastrup writes: > There are also override collections like \voiceOne, and not all > overrides might apply in every context they are used in: in that case we > don't want a warning. So it is not an issue quite as simple as it may > seem at first, but it is definitely on my agenda when I rework the > property system. > > Which does not mean that people are free to beat me to it within the > current system. Got my nots all knotted. "Which does not mean that people would not be free to beat me to it within the current system." -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Keith OHara writes: > David Kastrup gnu.org> writes: >> d) \override xxx is equivalent to \override Bottom.xxx, with Bottom >> being a context without \defaultchild (to be recursively created from >> the current context, if that is not a bottom context, by creating the >> respective defaultchildren in sequence until hitting bottom). For clarity: the above describes the _current_ situation. >> If all our engravers had correctly registered the context properties >> they read, \override xxx could instead set the property in the >> context closest to bottom that will actually _look_ at the changed >> property. > > These two steps alone will drastically increase usability and the user-base. > >> Of course, this is not without drawback either: if there are multiple >> engravers looking at that property at multiple levels > > This 'drawback' is still an improvement relative to the current situation. > \once\override TimeSignature #'stencil = ##f > If the override has effect only for one staff when we wanted it to affect > a StaffGroup, it is easier to discover the solution than currently, where > the override is ignored entirely. I was more thinking of the situation where multiple _unrelated_ engravers look at the same property for different reasons. In that case you likely need to set the property at the outermost level where somebody is listening. In contrast, when there are multiple related or identical engravers listening, the _innermost_ level is quite appropriate since it is _desired_ that the outer engravers of the same kind don't get the same information. There are also override collections like \voiceOne, and not all overrides might apply in every context they are used in: in that case we don't want a warning. So it is not an issue quite as simple as it may seem at first, but it is definitely on my agenda when I rework the property system. Which does not mean that people are free to beat me to it within the current system. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
David Kastrup gnu.org> writes: > "Phil Holmes" philholmes.net> writes: > > > What does get me more concerned is how hard > > it is to find some of the correct ways of tweaking output. Using > > voice.SomeValue (or is it Voice.someValue) when it should be > > staff.Somevalue (or was it Staff.someValue) frequently results in no > > change to the output. > As they say, "Me too." This is the reason I gave up on LilyPond, several times now. > Yup. Here is my multi-stage plan for that: > b) our C++ engravers announce to the type system (and via that, to the > documentation) which context properties they read, modify and write. > There is no reason that this does not also include the Grob descriptions > which are even now a special case of context property. > d) \override xxx is equivalent to \override Bottom.xxx, with Bottom > being a context without \defaultchild (to be recursively created from > the current context, if that is not a bottom context, by creating the > respective defaultchildren in sequence until hitting bottom). If all > our engravers had correctly registered the context properties they read, > \override xxx could instead set the property in the context closest to > bottom that will actually _look_ at the changed property. These two steps alone will drastically increase usability and the user-base. > Of course, this is not without drawback either: if there are multiple > engravers looking at that property at multiple levels This 'drawback' is still an improvement relative to the current situation. \once\override TimeSignature #'stencil = ##f If the override has effect only for one staff when we wanted it to affect a StaffGroup, it is easier to discover the solution than currently, where the override is ignored entirely. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: allowing \f and \F (was: [GLISS] - alternative viewpoint)
Graham Percival percival-music.ca> writes: > On Sat, Sep 15, 2012 at 07:56:52PM +0200, Werner LEMBERG wrote: > > > > > Distinguishing \f and \F while ignoring case is going to be a rather > > > difficult operation. > > I agree that distinguishing \f and \F is difficult. However, if > the programmers-as-developers were willing to discuss ideas and > look for solutions, there are other options. What is the > fundamental desire here, and is there any way of accomplishing > this? I did not hear any serious desire to allow both \f and \F as distinct. We have them as distinct identifiers now, of course, but do not like it when different functions differ only by case. To the contrary, the request was to accept (and complain) if we mistype \SlurDown The complete request might be, If the users types an identifier that is not defined, request that LilyPond attempt to find the lower-cased (C-locale) identifier among the lower-cased versions of defined identifiers (picking the first found in case of duplicates) and warn of the substitution "Don't know \SlurDown assuming you mean \slurDown" In the troublesome case, when both \f and \F are defined, LilyPond would have to count on the user to type the correct case, but we would separately try to avoid depending on such distinctions ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
allowing \f and \F (was: [GLISS] - alternative viewpoint)
On Sat, Sep 15, 2012 at 07:56:52PM +0200, Werner LEMBERG wrote:
>
> > Distinguishing \f and \F while ignoring case is going to be a rather
> > difficult operation. While I generally try to accommodate a lot of
> > "make that work" requests, there are limits to what one can achieve
> > when fighting not just the current code base, but rather plain
> > logic.
>
> :-)
I agree that distinguishing \f and \F is difficult. However, if
the programmers-as-developers were willing to discuss ideas and
look for solutions, there are other options. What is the
fundamental desire here, and is there any way of accomplishing
this?
For example, what about my hated idea of splitting namespaces of
music fuctions and identifiers? I'm not fond of perl, but
something like this is unambiguous:
$F = \markup { "Horn in F" }
{
c$F
}
We could even retain the current method of creating identifiers;
this doesn't need to break existing scores. The remaining
question is whether to make $names case-sensitive or not -- or,
for that matter, whether to allow only ascii characters in $names
or whether to allow any utf-8 character. Maybe non-native English
speakers would appreciate being able to name their music in their
native language.
I will undoubtedly now be subjected to a steam of abuse from
programmers about problems that I did not think of in the past 3
minutes. As a pre-emptive attempt to mitigate that abuse, I will
state THAT I DO NOT EXPECT, NOR EVEN DESIRE, DAVID TO IMPLEMENT
THIS. THIS IS AN IDEA, NOT A COMMAND FROM THE UBER-BOSS.
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
> Distinguishing \f and \F while ignoring case is going to be a rather > difficult operation. While I generally try to accommodate a lot of > "make that work" requests, there are limits to what one can achieve > when fighting not just the current code base, but rather plain > logic. :-) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Werner LEMBERG writes: >> What we're discussing is ideas. No-one has to implement ideas. > > Well... > >> If there is widespread agreement that the idea is good, then at some >> point it could be implemented. > > ... but as David has correctly mentioned previously, it is not > fruitful to discuss something for a long time and make everyone agree > to it, just to find out later on that the idea can't be implemented in > the current framework. "Case insensitity" is something that comes up a lot in computing, like with file systems. The general trend is that more and more systems that have started out case insensitive are moving to case sensitivity since the problems caused by inconsistent usage can't be all salvaged automatically. Most programmers with significant exposure to making case insensitivity work develop a deep dislike against the barrage of recurring problems. So before choosing case insensitivity as a solution to some problem, it might make sense to revisit the problem and see whether, for example, killing CamelCaps and/or other naming choices and/or replacing them by different schemes will not make the problem less relevant as it now appears to users. > It's a matter of fact that we are bound to what we have. Everything > else would be a complete redesign of LilyPond, which is certainly a > noble goal but far, far away. I don't think this is the intention of > GLISS. Guile itself would not mind case-insensitivity much, but our existing code base would. Not on a technical level, but with regard to the current naming choices and possible conflicts. >> We could certainly use it as a way to direct development - "hey, >> David, when you're working on the parser, could you also work towards >> making it case insensitive?". Reserved words are lowercase anyway. For the rest, try (read-enable 'case-insensitive) at the top of scm/lily.scm. Good luck. I really have no idea how far this will get you. But I don't want this in LilyPond myself: as I said, allowing inconsistent entry does not buy you anything but sloppiness and surprises. > The case sensitivity is special since it doesn't need syntactical > changes. However, other issues we've discussed recently are very > difficult to implement for reasons that most of us don't understand. Well, some of the things that _are_ implemented are very difficult to implement as well (I am working on dialing back the complexity, too). But if things create _conceptual_ complexity rather than implementation complexity (due to parser limitations), I like them even less. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
James writes:
> Hello,
>
> On 15 September 2012 13:55, Werner LEMBERG wrote:
>>
I'm strictly against case-insensivity.
>>>
>>> And I and others are for it. Could you state your reasoning,
>>> please? I've already stated mine.
>>
>> First, it is confusing. Virtually all programming languages of today
>> (and lilypond's input code resembles that) are case-sensitive.
>
> So what? I am not a programmer. I am a user.
Within your own scores, be consistent in your choices. How this
consistency looks, does not matter. Within LilyPond, there is a large
consistency which elements are uppercase, and which lowercase. The one
thing that actually gets annoying is CamelCase. However, as a rule,
camelcase starts with lowercase letters. With recent changes in the
lexer, it would be possible to replace the CamelCase words with dashed
words. That would allow for things like
\slur-up \slur-down \voice-one \one-voice \voice-two and so on. I am
personally not a big fan of CamelCase. You would, of course, get the
same principal problem "I can't remember where and whether to put
dashes" when making use of that option.
Weeding out CamelCase would not, in itself, change the classes of things
that we use uppercase for, lowercase for, and dashes for (there would be
some overlap in classes since we _do_ have a few existing
words-with-dashes and \commands-with-dashes, but distinguishing those
classes is actually not important, unlike the pure lower/uppercase
distinction we actually use for Grob and Context names).
>> Second, as David has already mentioned, the conversion to either
>> lowercase or uppercase is locale dependent.
>
> User's don't care, I don't care. I want to not have to remember
> whether it is \Mycommand, \myCommand or \MyCommand or \mycommand or
> \MYCOMMAND - make them all work or make one of them work.
Uh, one of them _will_ work.
>> Third, the numbers of short user-definable abbreviations gets halved.
>> Something like
>>
>> F = \markup { "Horn in F" }
>>
>> would no longer be possible because \f is already in use.
>
> So what? You are a developer, fix that. I do want to not have to
> remember what case I am supposed to be using.
Distinguishing \f and \F while ignoring case is going to be a rather
difficult operation. While I generally try to accommodate a lot of
"make that work" requests, there are limits to what one can achieve when
fighting not just the current code base, but rather plain logic.
> Phil (user) says why something pretty basic is flawed, David
> (developer) jumps in with a valid technically accurate, but frankly
> meaningless description to a user (can we do it or not?), next we'll
> have a 'developer-not-user' pitch in with an opinion on changing
> containers and contexts and properties and other things
> 'users-don't-care-about' and then David (developer) will reply with
> another technically accurate answer, probably with some 'arcane' (to a
> user-not-developer) reasoning, the rest of the developer-not-users all
> chime in, and the original 'problem' is forgotten as they all digress
> their way down some chain of gobbledygook that most of those who
> started to follow end up glazing over and realising that this is now
> beyond them as the conversation ends with words like 'lexer' and
> 'parser' and 'post-fix', and wonder if their contribution has actually
> been listened to. We wait a few more emails, cannot see if our
> suggestion is even being thought about or has it been forgotten - user
> leaves conversation wondering why he/she bothered.
I don't think that this characterization is doing justice to the
developers since it basically assumes that their main incentive is
making fun of users.
Part of the reason working on LilyPond is less rewarding than it could
be is this atmosphere of distrust, and the urge to rein in developers
who apparently have nothing better to do than damage LilyPond.
If you take a look at the "Changes" section for LilyPond 2.16, you will
find a large number of entries in the syntax department that make things
more straightforward, more consistent, more powerful, and easier to
understand. I have been working to that end, and rather hard.
If you take a look at the feedback I received, there are a lot of users
who express their belief and trust that I am on the right track by
providing me with the financial means to continue, and that frankly
means a lot to me beyond allowing me to eat.
If you take a look at the feedback from the developers and the developer
list, you'll see that 95% of all code reviews remain without comment,
and there is basically no interest at all, either for helping with the
results, or for putting them to actual use.
Now if there is a single person working on a large and important
project, and making remarkable progress, wouldn't the normal question be
"how can we give him constructive feedback with regard to work he has
already done or is planning to do"?
But that is not what happens. Instead the focus is on i
Re: [GLISS] - alternative viewpoint
Werner LEMBERG writes:
>> Currently, the parser is still undergoing significant restructuring
>> work in major areas and mechanisms. That work entails a lot of time
>> spent on ironing out parser conflicts where some input would
>> correspond to multiple and diverging interpretations according to
>> the current syntax. It is significant work ironing out those
>> conflicts. Adding additional rules for erroneous input means more
>> potential for conflict, so it would make the ongoing work even
>> harder.
>
> I suggest that the possibility of improved error messages should be
> taken into account while doing design decisions.
Well, the "accumulate expressions that make sense on their own" approach
means that the accumulation can provide useful error messages. It
basically leads to an "accept and complain" approach in the parser
regarding the actual syntax ("accept" does not mean that anything useful
is or can be done, just that the parser does not get lost altogether).
The disadvantage is that the syntax description of LilyPond (in the
appendices of the notational manual) becomes less and less useful for
figuring out what a syntactically correct LilyPond program is supposed
to look like.
At the moment, not many "design decisions" actually are happening in
parser work: most of the work focuses on creating a more coherent and
logical framework able to reflect the existing design while being better
extensible and manageable.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
> What we're discussing is ideas. No-one has to implement ideas. Well... > If there is widespread agreement that the idea is good, then at some > point it could be implemented. ... but as David has correctly mentioned previously, it is not fruitful to discuss something for a long time and make everyone agree to it, just to find out later on that the idea can't be implemented in the current framework. It's a matter of fact that we are bound to what we have. Everything else would be a complete redesign of LilyPond, which is certainly a noble goal but far, far away. I don't think this is the intention of GLISS. > We could certainly use it as a way to direct development - "hey, > David, when you're working on the parser, could you also work > towards making it case insensitive?". The case sensitivity is special since it doesn't need syntactical changes. However, other issues we've discussed recently are very difficult to implement for reasons that most of us don't understand. Admittedly, David tends to answer everything far too detailed (and he probably he reads the e-mails too carefully)... BTW, a survey of the most wanted changes to LilyPond would be a good idea. Maybe someone can set up such a poll, similar to the git survey, on survs.com or a similar site. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
>> Fourth, Scheme is not case-insensitive. > > That's not traditional. Ah, interesting. I wasn't aware of that. Thanks for the correction. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Werner LEMBERG writes:
>>> I'm strictly against case-insensivity.
>>
>> And I and others are for it. Could you state your reasoning,
>> please? I've already stated mine.
>
> First, it is confusing. Virtually all programming languages of today
> (and lilypond's input code resembles that) are case-sensitive.
>
> Second, as David has already mentioned, the conversion to either
> lowercase or uppercase is locale dependent.
>
> Third, the numbers of short user-definable abbreviations gets halved.
> Something like
>
> F = \markup { "Horn in F" }
>
> would no longer be possible because \f is already in use.
>
> Fourth, Scheme is not case-insensitive.
That's not traditional. However, the current R6RS syntax states
Case is significant except in representations of booleans, number
objects, and in hexadecimal numbers specifying Unicode scalar values.
For example, `#x1A' and `#X1a' are equivalent. The identifier `Foo'
is, however, distinct from the identifier `FOO'.
Guile has
6.17.1.4 Case Sensitivity
.
Scheme as defined in R5RS is not case sensitive when reading symbols.
Guile, on the contrary is case sensitive by default, so the identifiers
guile-whuzzy
Guile-Whuzzy
are the same in R5RS Scheme, but are different in Guile.
It is possible to turn off case sensitivity in Guile by setting the
reader option `case-insensitive'. For more information on reader
options, *Note Scheme Read::.
(read-enable 'case-insensitive)
Note that this is seldom a problem, because Scheme programmers tend
not to use uppercase letters in their identifiers anyway.
in its documentation, so the previous Scheme default has been different.
> Should everything starting with `#' be case-sensitive then? Otherwise
> we couldn't fully access our own extension language.
I doubt Guile makes use of different case versions in the predefined
stuff.
But LilyPond does.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
- Original Message - From: "Werner LEMBERG" To: Cc: Sent: Saturday, September 15, 2012 3:24 PM Subject: Re: [GLISS] - alternative viewpoint Mhmm. May I recommend a sheet of paper and a pencil instead, then? :-) Perhaps you'd prefer to recommend Sibelius, which has no such difficulties... > Users are ready to accept change, it seems that many developers are > not or are too blinkered or half-empty to even want to understand > why something is discussed, instead its taken as a personal affront > to them or their code. The very problem is that some must implement these changes. As David has said, this is far from trivial. No. Absolutely not. What we're discussing is ideas. No-one has to implement ideas. If there is widespread agreement that the idea is good, then at some point it could be implemented. We could certainly use it as a way to direct development - "hey, David, when you're working on the parser, could you also work towards making it case insensitive?". But if we are abused for making suggestions that would make life easier for users, as opposed to developers, then we should agree to stop discussion and drop GLISS. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
I'm strictly against case-insensivity. >> >> First, it is confusing. Virtually all programming languages of today >> (and lilypond's input code resembles that) are case-sensitive. > > So what? I am not a programmer. I am a user. Urgh. This is a real knock-out argument for everything. Even TeX, which has been written more than 30 years ago, and which is used by millions of non-programmers, is case-sensitive. >> Second, as David has already mentioned, the conversion to either >> lowercase or uppercase is locale dependent. > > User's don't care, I don't care. I want to not have to remember > whether it is \Mycommand, \myCommand or \MyCommand or \mycommand or > \MYCOMMAND - make them all work or make one of them work. Then use a front-end which corrects you! I can easily imagine that you get command completion with the TAB key, or a scroll-down list of command names for die-hard mouse users. I don't see any reason to cripple lilypond itself, given that a layer on top of it can hide such really `nasty' details like uppercase and lowercase. >> Third, the numbers of short user-definable abbreviations gets >> halved. > > So what? You are a developer, fix that. I do want to not have to > remember what case I am supposed to be using. Again, use a frontend which manages that for you, for example, by disallowing you to enter macro names which contain uppercase letters. >> Fourth, Scheme is not case-insensitive. [...] > > So what? > > I am not typing Scheme I am typing \mycommand. What is Scheme > anyway? Where do I find that in the Learning manual? > > I came to use lilypond to write music scores not to learn or care > about programming. Mhmm. May I recommend a sheet of paper and a pencil instead, then? :-) >> There is actually a reason for that. Staff, as a context name, is >> a container for properties, and things like Slur, as a property >> name, are also principally containers for properties. > > [user-not-developer]; huh? Since you say `huh', you are obviously on the wrong mailing list :-) > Users are ready to accept change, it seems that many developers are > not or are too blinkered or half-empty to even want to understand > why something is discussed, instead its taken as a personal affront > to them or their code. The very problem is that some must implement these changes. As David has said, this is far from trivial. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Hello,
On 15 September 2012 13:55, Werner LEMBERG wrote:
>
>>> I'm strictly against case-insensivity.
>>
>> And I and others are for it. Could you state your reasoning,
>> please? I've already stated mine.
>
> First, it is confusing. Virtually all programming languages of today
> (and lilypond's input code resembles that) are case-sensitive.
So what? I am not a programmer. I am a user.
>
> Second, as David has already mentioned, the conversion to either
> lowercase or uppercase is locale dependent.
User's don't care, I don't care. I want to not have to remember
whether it is \Mycommand, \myCommand or \MyCommand or \mycommand or
\MYCOMMAND - make them all work or make one of them work.
>
> Third, the numbers of short user-definable abbreviations gets halved.
> Something like
>
> F = \markup { "Horn in F" }
>
> would no longer be possible because \f is already in use.
So what? You are a developer, fix that. I do want to not have to
remember what case I am supposed to be using.
>
> Fourth, Scheme is not case-insensitive. Should everything starting
> with `#' be case-sensitive then? Otherwise we couldn't fully access
> our own extension language.
So what?
I am not typing Scheme I am typing \mycommand. What is Scheme anyway?
Where do I find that in the Learning manual?
I came to use lilypond to write music scores not to learn or care
about programming.
Also:
On 15 September 2012 11:19, David Kastrup wrote:
> "Phil Holmes" writes:
>
>> ----- Original Message -
>> From: "David Kastrup"
>> To:
>> Sent: Saturday, September 15, 2012 9:20 AM
>> Subject: Re: [GLISS] - alternative viewpoint
>>
>>
>>> "Phil Holmes" writes:
>>>
>>>> And getting rid of case-sensitivity in a lot of this?
>>>
>>
>>
>> \new Staff works. \New staff doesn't. There's no reason for that -
[user-not-developer]; That's right!
>
> There is actually a reason for that. Staff, as a context name, is a
> container for properties, and things like Slur, as a property name, are
> also principally containers for properties.
[user-not-developer]; huh?
[James] And there is the problem in a nutshell - not that that is
David's fault, but this is getting Kafka-esque (or Beckett depending
on your 'Absurdist' of choice).
Phil (user) says why something pretty basic is flawed, David
(developer) jumps in with a valid technically accurate, but frankly
meaningless description to a user (can we do it or not?), next we'll
have a 'developer-not-user' pitch in with an opinion on changing
containers and contexts and properties and other things
'users-don't-care-about' and then David (developer) will reply with
another technically accurate answer, probably with some 'arcane' (to a
user-not-developer) reasoning, the rest of the developer-not-users all
chime in, and the original 'problem' is forgotten as they all digress
their way down some chain of gobbledygook that most of those who
started to follow end up glazing over and realising that this is now
beyond them as the conversation ends with words like 'lexer' and
'parser' and 'post-fix', and wonder if their contribution has actually
been listened to. We wait a few more emails, cannot see if our
suggestion is even being thought about or has it been forgotten - user
leaves conversation wondering why he/she bothered.
I've refrained from really joining in with this whole debate because
of the way the discussions _always_ get twisted and turned about to
what can seem to a user-not-developer a conversation that's seemingly
an I-know-more-than-you or
I-can-think-of-really-special-cases-better-than-the-next-person,
instead of actually wondering why the original suggestion was made in
the first place by the 'rest of us'.
Like Phil has said, he doesn't care whether a command is \foobar and
gets changed to \barfoo. Users are quite resilient they shrug and go
on about their lives as long as it is documented and they have some
way of getting their old scores to work with the new version of
whatever is decided - THAT is probably more important to users than
much else. Those that say 'but what about my custom function in my
scores will no longer work' - well that is acceptable to a user, it's
called a 'hack' in my world, that is why the LSR is not documentation.
Those are hacks. Clever hacks, but hacks nonetheless and they have no
business of holding back development (syntactical or otherwise), I've
had to put up with nonsensical commands, why can't developers change
their ways too?
David made a good explanation about 1% of users on the list vs the
rest w
Re: [GLISS] - alternative viewpoint
> Currently, the parser is still undergoing significant restructuring > work in major areas and mechanisms. That work entails a lot of time > spent on ironing out parser conflicts where some input would > correspond to multiple and diverging interpretations according to > the current syntax. It is significant work ironing out those > conflicts. Adding additional rules for erroneous input means more > potential for conflict, so it would make the ongoing work even > harder. I suggest that the possibility of improved error messages should be taken into account while doing design decisions. > So I would first like to get to a state where I consider the > parser/syntax to be mostly "in harmony" with its design before > adding user-helpful error rules that make further work harder. OK. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
>> I'm strictly against case-insensivity.
>
> And I and others are for it. Could you state your reasoning,
> please? I've already stated mine.
First, it is confusing. Virtually all programming languages of today
(and lilypond's input code resembles that) are case-sensitive.
Second, as David has already mentioned, the conversion to either
lowercase or uppercase is locale dependent.
Third, the numbers of short user-definable abbreviations gets halved.
Something like
F = \markup { "Horn in F" }
would no longer be possible because \f is already in use.
Fourth, Scheme is not case-insensitive. Should everything starting
with `#' be case-sensitive then? Otherwise we couldn't fully access
our own extension language.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
- Original Message - From: "Werner LEMBERG" To: Cc: ; Sent: Saturday, September 15, 2012 1:08 PM Subject: Re: [GLISS] - alternative viewpoint \new Staff works. \New staff doesn't. [...] I'm strictly against case-insensivity. And I and others are for it. Could you state your reasoning, please? I've already stated mine. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
> \new Staff works. \New staff doesn't. [...] I'm strictly against case-insensivity. Guiding the user to find the right command name (this is, finding the `nearest' command or macro name to the non-existing one[1]) belongs to the error-help category IMHO, something which I would add as a request to the tracker. Werner [1] You can find an overview here: http://en.wikipedia.org/wiki/Approximate_string_matching ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
"Phil Holmes" writes:
> - Original Message -
> From: "David Kastrup"
> To:
> Sent: Saturday, September 15, 2012 9:20 AM
> Subject: Re: [GLISS] - alternative viewpoint
>
>
>> "Phil Holmes" writes:
>>
>>> And getting rid of case-sensitivity in a lot of this?
>>
>> You need to elaborate. It is not clear what you mean with that, and
>> what kind of remedy you envision.
>
>
> \new Staff works. \New staff doesn't. There's no reason for that -
There is actually a reason for that. Staff, as a context name, is a
container for properties, and things like Slur, as a property name, are
also principally containers for properties. There is a convention to
uppercase them in order to distinguish them from other elements. When
writing things like
\layout {
\context {
\Staff
\override ...
}
}
calling the identifier \Staff for copying an existing context definition
is not syntactically different from calling any other kind of identifier
including functions. We use the uppercasing here in order to establish
some kind of namespace.
The one consequence that I find actually annoying about that is that we
have the semi-equivalence of \score with \new Score, and that is indeed
less than pretty.
> we don't have two separate \new \New commands that do different
> things, nor two contexts Staff and staff that are different.
But \Score and \score which are entirely different things (the latter is
actually a reserved word, so they can't really be merged).
> Worse is that \slurUp works but only with that precise casing.
Given that it works on a grob called Slur, I agree that some of the
consequences of our naming schemes are not necessarily fortunate.
\upSlur would fit better into the schemes, but I don't fancy its
grammar. In practice, \voiceOne and \voiceTwo are more often than not
the saner choice (as they make for more consistent results usually since
the user often forgets to include the more obscure *Up/*Down commands),
or using ^ and _ on individual slurs (since it is rare that you actually
want to direct only slurs but nothing else for longer passages).
> TBH this specific one doesn't cause me worry, since I remember it, but
> there are much more arcane casings that I have to refer to the manual
> to find - so I can remember the command, but not the casing! From a
> user perspective, it would be much simpler if everything they write
> was ToLower()-ed before further processing.
With the current design, it is not as simple as that right now. Of
course, there is the standard argument (known from filesystem
discussions) that lowercasing is not a well-defined operation since some
people expect \lowercase{I} to be {i} and some expect it to be {ı} and
\uppercase{i} to be either {I} or {İ}.
As long as we allow arbitrary utf8 characters into identifiers, that is
not an entirely hypothetic consideration.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
David Kastrup writes: >> Is there any >> possibility to fine-tune this as requested by Phil, in particular, >> emitting the right usage as an example in the error message? > > You mean, currently we basically see the default error message from the > parser generator. Improving this involves basically accepting errors in > input and acting on them by putting out hand-tailored messages. Hopefully stating the obvious...to me, please be careful to keep mentioning the actual error condition. It can be very helpful to add error states and hand-tailor messages, and even a usage example or suggestion may be helpful... if the suggestion has a very high guestimate of being right. Some softwares replace the actual error condition -- with whatever good intention -- by a user friendly message that guessed wrong. Ugh. Also, more and more google is your friend with error messages, even or especially if they're cryptic. Hmm, people may not know that. What if upon error, after the error message, LilyPond prints google's first hit: and by the way, this is what Google thinks about your problem. ;-) Jan -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
- Original Message - From: "David Kastrup" To: Sent: Saturday, September 15, 2012 9:20 AM Subject: Re: [GLISS] - alternative viewpoint "Phil Holmes" writes: And getting rid of case-sensitivity in a lot of this? You need to elaborate. It is not clear what you mean with that, and what kind of remedy you envision. \new Staff works. \New staff doesn't. There's no reason for that - we don't have two separate \new \New commands that do different things, nor two contexts Staff and staff that are different. Worse is that \slurUp works but only with that precise casing. TBH this specific one doesn't cause me worry, since I remember it, but there are much more arcane casings that I have to refer to the manual to find - so I can remember the command, but not the casing! From a user perspective, it would be much simpler if everything they write was ToLower()-ed before further processing. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Werner LEMBERG writes:
>> Here is my multi-stage plan for that:
>
> I essentially agree with everything. Thanks for that plan.
>
>> b) our C++ engravers announce to the type system (and via that, to
>> the documentation) which context properties they read, modify and
>> write. There is no reason that this does not also include the Grob
>> descriptions which are even now a special case of context property.
>
> In general, virtually all (public) Scheme functions of LilyPond
> already have some documentation strings attached to it, and I think it
> is probably one of the most important targets on the documentation
> side to make them appear in the documentation.
>
>> d) \override xxx is equivalent to \override Bottom.xxx, [...]
>
> As soon as this works it would be extremely helpful if we could have a
> command line flag to switch on tracing of those commands so that a
> user can follow which \override gets applied which context. Actually,
> this would be extremely helpful today too.
>
>>> And finding what comes after the \override staff.Something - is it
>>> ##f. or #'4 or 4 or { 4} or what?
>>
>> #'4 and #4 and 4 should be quite equivalent in most cases...
>
> Currently, in case of error, we basically see the parser's or lexer's
> error message which isn't very useful for the beginner. Is there any
> possibility to fine-tune this as requested by Phil, in particular,
> emitting the right usage as an example in the error message?
You mean, currently we basically see the default error message from the
parser generator. Improving this involves basically accepting errors in
input and acting on them by putting out hand-tailored messages.
Currently, the parser is still undergoing significant restructuring work
in major areas and mechanisms. That work entails a lot of time spent on
ironing out parser conflicts where some input would correspond to
multiple and diverging interpretations according to the current syntax.
It is significant work ironing out those conflicts. Adding additional
rules for erroneous input means more potential for conflict, so it would
make the ongoing work even harder. I am working towards recognizing
elements of the syntax in isolation, and then pasting them together.
The "pasting together" is then done outside of the immediate control of
the parser and can trigger independent error messages based on the
assumption that at least the elements used for combining were, by
themselves, recognized correctly. Those error messages can be more
specific and helpful than the boilerplate parse errors from the parser
generator.
We have that, to some degree, concerning the type of music function
arguments. If those don't match expectations, you'll get an error that
usually is quite more specific and user-readable than "syntax error:
unexpected STRING". However, putting more user-specific error rules in
the syntax rules themselves increases the potential for syntax conflicts
in the parser. As long as the major contruction work in there is not
finished, the user benefits of such rules will likely be transitory, and
it makes working on the parser even harder.
So I would first like to get to a state where I consider the
parser/syntax to be mostly "in harmony" with its design before adding
user-helpful error rules that make further work harder.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
> Here is my multi-stage plan for that:
I essentially agree with everything. Thanks for that plan.
> b) our C++ engravers announce to the type system (and via that, to
> the documentation) which context properties they read, modify and
> write. There is no reason that this does not also include the Grob
> descriptions which are even now a special case of context property.
In general, virtually all (public) Scheme functions of LilyPond
already have some documentation strings attached to it, and I think it
is probably one of the most important targets on the documentation
side to make them appear in the documentation.
> d) \override xxx is equivalent to \override Bottom.xxx, [...]
As soon as this works it would be extremely helpful if we could have a
command line flag to switch on tracing of those commands so that a
user can follow which \override gets applied which context. Actually,
this would be extremely helpful today too.
>> And finding what comes after the \override staff.Something - is it
>> ##f. or #'4 or 4 or { 4} or what?
>
> #'4 and #4 and 4 should be quite equivalent in most cases...
Currently, in case of error, we basically see the parser's or lexer's
error message which isn't very useful for the beginner. Is there any
possibility to fine-tune this as requested by Phil, in particular,
emitting the right usage as an example in the error message?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
David Kastrup writes: > Quite agreed. That is what I call "extending the vocabulary", and > making that feasible continues to be a main objective of my work on > music functions. We got a few new people on the user list contributing > music functions so far, but those contributions are not convenience > wrappers but actually do complex jobs. > > There are several lashback issues connected with convenience wrappers, > and they focus around the question: > > To what degree does a convenience wrapper become part of LilyPond's > language? > > There are several questions following from that starting point. > > a) reflection. Should \displayLilyMusic recognize expressions that > can be produced by a wrapper and output them? If we answer "yes" to > that question, it would make sense to provide some infrastructure > for specifying appropriate reverse engineering rules to LilyPond in > a manner that is not significantly more complex to specify than the > wrapper itself. > > b) When and how are third-party tools supposed to learn about such > wrappers when they are supposed to be part of LilyPond? > > c) MusicXML? Oh, and d) bikeshedding. For a semi-example, see http://code.google.com/p/lilypond/issues/detail?id=2717> and particularly the discussion on its Rietveld review http://codereview.appspot.com/6443087>. Now one might argue that this currently is rather a discussion on meta-bikeshedding, namely getting something right that will serve as a template for future bikeshedding, but it is quite clear that with convenience wrappers, everybody actually _can_ contribute his opinion without requiring much expertise. And it makes some sense as well since we are, after all, trying to hit the sweet spot of naive expectations. Meta-bikeshedding makes some sense for prestructuring this space, but after that, filling in the blanks is pretty much possible for everyone. In some respects, this may be part of "personal style collections", but of course some stuff makes sense to be part of the core as well. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
"Phil Holmes" writes:
> OK - so there's been a lot of discussion of pre- and post-fix, and a
> load of other stuff I don't understand.So I had a think about what it
> is about lilypond syntax that p**s me off. And I concluded that it's
> nothing to do with whether we write c4 /p for a quiet crochet c, as
> opposed to /p 4c. I really don't care. When I was a tyro, I just
> read that and accepted it. What does get me more concerned is how hard
> it is to find some of the correct ways of tweaking output. Using
> voice.SomeValue (or is it Voice.someValue) when it should be
> staff.Somevalue (or was it Staff.someValue) frequently results in no
> change to the output.
Yup. Here is my multi-stage plan for that:
a) an \override is really just a subset, namely a change of the context
property named after a grob. For efficiency reasons, that context
property is not organized as an alist but something more complicated
implemented on top of a pair. Properties have to be reorganized to
make a hierarchical \set strictly equivalent to an \override.
b) our C++ engravers announce to the type system (and via that, to the
documentation) which context properties they read, modify and write.
There is no reason that this does not also include the Grob descriptions
which are even now a special case of context property.
c) Scheme engravers have no way to "register" like a C++ engraver,
telling the type system what they want to be called, and which context
properties they are accessing. This needs to change.
d) \override xxx is equivalent to \override Bottom.xxx, with Bottom
being a context without \defaultchild (to be recursively created from
the current context, if that is not a bottom context, by creating the
respective defaultchildren in sequence until hitting bottom). If all
our engravers had correctly registered the context properties they read,
\override xxx could instead set the property in the context closest to
bottom that will actually _look_ at the changed property.
Of course, this is not without drawback either: if there are multiple
engravers looking at that property at multiple levels and you are
interested in overriding the behavior of the engraver in an outer level,
the unspecific override will be done in the inner level and again not
have an apparent effect.
However, it would be a second-tier nuisance instead of a first-tier
nuisance.
> And is it \override or \set? And \revert or \override back to
> something else. And finding what comes after the \override
> staff.Something - is it ##f. or #'4 or 4 or { 4} or what?
#'4 and #4 and 4 should be quite equivalent in most cases...
> If you follow what is asked on -user, it's this stuff that causes
> confusion, not pre- or post-fix.
One might argue that users who are able to write to a mailing list after
looking for it in the manual make up for less than 1% of our targeted
demographic group, users who come to LilyPond not primarily since they
enjoy being in total control over the data structures their typesetting
program uses.
And particularly for those it makes a big selling point if naive
expectations disregarding the technical necessities and implementation
constraints happen to hit the mark semi-regularly. Of course, we can't
make that 100%, but 80% is a lot more encouraging than 2%. If you get
everything wrong at first try, that's a big turnoff. Even if some smart
helpful guy explains to you why everything is wrong.
> Now - I have no idea if this is possible or not, but when I put some
> of these complex overrides into my converter, the commands to the
> converter use a C-like syntax. For instance, I've written a feature
> that allows the converter to scale durations:
>
> scaleDurationsOn(n,m)
>
> I personally think that providing more of these simple syntax features
> would make it much easier for the average user: we do have a few
> shortcuts of this type: for example:
>
> autoBeamOff = \set autoBeaming = ##f
> melismaEnd = #(context-spec-music (make-property-unset 'melismaBusy)
> Bottom)
>
> Why not focus on making the slightly complex part of Lilypond much
> simpler (not the very complex, like customer scheme functions - if you
> can do that, you don't need help)?
Quite agreed. That is what I call "extending the vocabulary", and
making that feasible continues to be a main objective of my work on
music functions. We got a few new people on the user list contributing
music functions so far, but those contributions are not convenience
wrappers but actually do complex jobs.
There are several lashback issues connected with convenience wrappers,
and they focus around the question:
To what degree does a convenience wrapper become part of LilyPond's
language?
There are several questions following from that starting point.
a) reflection. Should \displayLilyMusic recognize expressions that
can be produced by a wrapper and output them? If we answer "yes" to
that question, it would make sense to provide some infra
Re: [GLISS] - alternative viewpoint
2012/9/14 Phil Holmes :
> OK - so there's been a lot of discussion of pre- and post-fix, and a load of
> other stuff I don't understand.So I had a think about what it is about
> lilypond syntax that p**s me off. And I concluded that it's nothing to do
> with whether we write c4 /p for a quiet crochet c, as opposed to /p 4c. I
> really don't care. When I was a tyro, I just read that and accepted it.
> What does get me more concerned is how hard it is to find some of the
> correct ways of tweaking output. Using voice.SomeValue (or is it
> Voice.someValue) when it should be staff.Somevalue (or was it
> Staff.someValue) frequently results in no change to the output. And is it
> \override or \set? And \revert or \override back to something else. And
> finding what comes after the \override staff.Something - is it ##f. or #'4
> or 4 or { 4} or what?
>
> If you follow what is asked on -user, it's this stuff that causes confusion,
> not pre- or post-fix.
The nature of the language, and the wide variety of cases you can
encounter in real scores along with plain old everyday music, makes
two subsets of language rules to exist. One is common music notation,
with no overrides. I think a musician can learn this subset in full,
and enjoy most of lilypond, most of the time. Other is the tweaking
mechanism, which I find impossible to memorize. And what is worse, is
to see the raising eyebrows in faces of people who is suppossed to use
it daily, when you try to teach it to them.
Still, we have the advantage of that, being a human-readable text
format, one can simply copy+paste cool code from LSR that works with a
high probability of success.
I have been tempted of making an automated "absolutely complete whole
collection of all possible overrides -- illustrated" for this purpose.
No time is too late for this.
--
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
Re: [GLISS] - alternative viewpoint
On Fri, Sep 14, 2012 at 10:13:00PM +0200, Marc Hohl wrote:
>
> \include "guitarSettings"
>
> \include "choirSettings" \with { \SATBoptions }
>
So you are thinking along the lines of the LaTex package system.
I would go along with that.
Bernard.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Am 14.09.2012 19:10, schrieb m...@mikesolomon.org:
On 14 sept. 2012, at 19:56, Phil Holmes wrote:
OK - so there's been a lot of discussion of pre- and post-fix, and a load of
other stuff I don't understand.So I had a think about what it is about lilypond
syntax that p**s me off. And I concluded that it's nothing to do with whether
we write c4 /p for a quiet crochet c, as opposed to /p 4c. I really don't
care. When I was a tyro, I just read that and accepted it. What does get me
more concerned is how hard it is to find some of the correct ways of tweaking
output. Using voice.SomeValue (or is it Voice.someValue) when it should be
staff.Somevalue (or was it Staff.someValue) frequently results in no change to
the output. And is it \override or \set? And \revert or \override back to
something else. And finding what comes after the \override staff.Something -
is it ##f. or #'4 or 4 or { 4} or what?
If you follow what is asked on -user, it's this stuff that causes confusion,
not pre- or post-fix.
Now - I have no idea if this is possible or not, but when I put some of these
complex overrides into my converter, the commands to the converter use a C-like
syntax. For instance, I've written a feature that allows the converter to
scale durations:
scaleDurationsOn(n,m)
I personally think that providing more of these simple syntax features would
make it much easier for the average user: we do have a few shortcuts of this
type: for example:
autoBeamOff = \set autoBeaming = ##f
melismaEnd = #(context-spec-music (make-property-unset 'melismaBusy) 'Bottom)
Why not focus on making the slightly complex part of Lilypond much simpler (not
the very complex, like customer scheme functions - if you can do that, you
don't need help)? And getting rid of case-sensitivity in a lot of this? And
providing error messages when an override has no effect because it was at the
voice context and should have been at staff?
+1
What I'd like to add: some kind of style files (as Janek proposed at
Waltrop) similar to
LaTeX packages.
If I write music for guitar, I need other settings than for a SATB choir.
Enabling them by
\include "guitarSettings"
\include "choirSettings" \with { \SATBoptions }
or something similar would improve the situation a lot without
rethinking the whole syntax in detail.
I completely agree with Phil. Reading the user list, it is comparatively rare that people seem to get hung
up on pre-and-post stuff. What'd really help is "did you mean to do thing X?" or "thing Y
will have no effect - consider doing Z" or even a "?" token one can put before or after an
object to have help messages printed to the logfile as well as detailed information about the command in
question and what it applies to.
+1, too.
Regards,
Marc
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
On 14 sept. 2012, at 19:56, Phil Holmes wrote:
> OK - so there's been a lot of discussion of pre- and post-fix, and a load of
> other stuff I don't understand.So I had a think about what it is about
> lilypond syntax that p**s me off. And I concluded that it's nothing to do
> with whether we write c4 /p for a quiet crochet c, as opposed to /p 4c. I
> really don't care. When I was a tyro, I just read that and accepted it. What
> does get me more concerned is how hard it is to find some of the correct ways
> of tweaking output. Using voice.SomeValue (or is it Voice.someValue) when it
> should be staff.Somevalue (or was it Staff.someValue) frequently results in
> no change to the output. And is it \override or \set? And \revert or
> \override back to something else. And finding what comes after the \override
> staff.Something - is it ##f. or #'4 or 4 or { 4} or what?
>
> If you follow what is asked on -user, it's this stuff that causes confusion,
> not pre- or post-fix.
>
> Now - I have no idea if this is possible or not, but when I put some of these
> complex overrides into my converter, the commands to the converter use a
> C-like syntax. For instance, I've written a feature that allows the
> converter to scale durations:
>
> scaleDurationsOn(n,m)
>
> I personally think that providing more of these simple syntax features would
> make it much easier for the average user: we do have a few shortcuts of this
> type: for example:
>
> autoBeamOff = \set autoBeaming = ##f
> melismaEnd = #(context-spec-music (make-property-unset 'melismaBusy) 'Bottom)
>
> Why not focus on making the slightly complex part of Lilypond much simpler
> (not the very complex, like customer scheme functions - if you can do that,
> you don't need help)? And getting rid of case-sensitivity in a lot of this?
> And providing error messages when an override has no effect because it was at
> the voice context and should have been at staff?
>
> --
> Phil Holmes
>
>
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
I completely agree with Phil. Reading the user list, it is comparatively rare
that people seem to get hung up on pre-and-post stuff. What'd really help is
"did you mean to do thing X?" or "thing Y will have no effect - consider doing
Z" or even a "?" token one can put before or after an object to have help
messages printed to the logfile as well as detailed information about the
command in question and what it applies to.
Chers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
[GLISS] - alternative viewpoint
OK - so there's been a lot of discussion of pre- and post-fix, and a load of
other stuff I don't understand.So I had a think about what it is about
lilypond syntax that p**s me off. And I concluded that it's nothing to do
with whether we write c4 /p for a quiet crochet c, as opposed to /p 4c. I
really don't care. When I was a tyro, I just read that and accepted it.
What does get me more concerned is how hard it is to find some of the
correct ways of tweaking output. Using voice.SomeValue (or is it
Voice.someValue) when it should be staff.Somevalue (or was it
Staff.someValue) frequently results in no change to the output. And is it
\override or \set? And \revert or \override back to something else. And
finding what comes after the \override staff.Something - is it ##f. or #'4
or 4 or { 4} or what?
If you follow what is asked on -user, it's this stuff that causes confusion,
not pre- or post-fix.
Now - I have no idea if this is possible or not, but when I put some of
these complex overrides into my converter, the commands to the converter use
a C-like syntax. For instance, I've written a feature that allows the
converter to scale durations:
scaleDurationsOn(n,m)
I personally think that providing more of these simple syntax features would
make it much easier for the average user: we do have a few shortcuts of this
type: for example:
autoBeamOff = \set autoBeaming = ##f
melismaEnd = #(context-spec-music (make-property-unset 'melismaBusy)
'Bottom)
Why not focus on making the slightly complex part of Lilypond much simpler
(not the very complex, like customer scheme functions - if you can do that,
you don't need help)? And getting rid of case-sensitivity in a lot of this?
And providing error messages when an override has no effect because it was
at the voice context and should have been at staff?
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
