Re: What's the deal with this "programming error"?
On Thu, Jun 10, 2010 at 4:38 PM, David Kastrup wrote: > Graham Percival writes: > >> On Thu, Jun 10, 2010 at 2:37 PM, David Kastrup wrote: >> >>> And of course, adding more information is done _automatically_ when >>> someone responds to the tracked report. So adding to the tracker >>> with a canned phrase "Small example, and error symptom still missing" >>> might well be a safe choice in any case. >> >> I don't know what you mean by "error symptom still missing". If [...] >> the user explains why the output is incorrect, > > That's the error symptom. Probably "error syndrome" would have been a > more proper term. Sorry. I had to look up "syndrome" on wikipedia, but I see what you mean. I disagree, though -- I would prefer to put the onus on the bug reporter. Once the issue is in the tracker, there's no urgency for the initial reporter to add more info. The key is to respond to the issue quickly. This works quite well; I did it for a year or two. As long as there's a reply and an actual discussion happens, users are happy to provide more information, explanations, and the rest. It's when they don't hear anything for days, weeks, or months that they get (justifiably) upset. That's why I keep on harping on the "find a reason to reject the report" idea -- if there's a clear-cut policy reason to "reject" a report, then the Squad member can reply immediately, or within 30 seconds, or something. But the key is to *reply*, instead of letting reports pass them by. On this point I'm going to use whatever veto power you give me. I'm convinced it will work; I did it this way for months and it worked just fine. If the Bug Squad adopts this method and it's failing over the course of 3-4 months, I'll be wiling to re-open the discussion, but not until then. Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this "programming error"?
Graham Percival writes: > On Thu, Jun 10, 2010 at 2:37 PM, David Kastrup wrote: > >> And of course, adding more information is done _automatically_ when >> someone responds to the tracked report. So adding to the tracker >> with a canned phrase "Small example, and error symptom still missing" >> might well be a safe choice in any case. > > I don't know what you mean by "error symptom still missing". If [...] > the user explains why the output is incorrect, That's the error symptom. Probably "error syndrome" would have been a more proper term. Sorry. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this "programming error"?
On Thu, Jun 10, 2010 at 2:37 PM, David Kastrup wrote: > Graham Percival writes: > >> If you >> can't reject the report for having no Tiny example, no version number, >> not being able to reproduce it, etc., then you MUST move on to the >> final point, namely adding it to the tracker. > > I should think that asking for the missing information (with copy on the > bug list so that other members of the squad might be aware of the > response) should be a valid option as well. That's already point 5 on the list: http://kainhofer.com/~lilypond/Documentation/contributor/bug-squad-checklists.html (using kainhofer temporarily because that change isn't in the official docs until 2.13.24) > For the sake of not eventually getting swamped by leftovers, "add it to > the tracker" would likely be a better choice over "make a mental note to > ask for more information Real Soon Now (TM)". Yes. > And of course, adding more information is done _automatically_ when > someone responds to the tracked report. So adding to the tracker with a > canned phrase "Small example, and error symptom still missing" might > well be a safe choice in any case. I don't know what you mean by "error symptom still missing". If there's a Tiny example and the user explains why the output is incorrect, it goes into the tracker and the Bug Squad should forget about about that issue. They're not programmers, they're not supposed to be programmers. They should ignore that issue until a programmer marks it "fixed" and the next release is made; at that point, they verify that the fix worked (or not). If there isn't a Tiny example, or if the user didn't clearly explain why the output was bad, or any of the other points in the checklist, then they reject the report. By "reject", I mean "write back to the user, cc'd to the list, asking for more information". But then it's no longer the responsibility of the Bug Squad; it's the respnosibility of the user to come back with a better example / more info / whatever. Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this "programming error"?
Graham Percival writes: > PS note that the "new email checklist" does *not* contain an item for > "ignore the email and hope that somebody else handles it". If you > can't reject the report for having no Tiny example, no version number, > not being able to reproduce it, etc., then you MUST move on to the > final point, namely adding it to the tracker. I should think that asking for the missing information (with copy on the bug list so that other members of the squad might be aware of the response) should be a valid option as well. For the sake of not eventually getting swamped by leftovers, "add it to the tracker" would likely be a better choice over "make a mental note to ask for more information Real Soon Now (TM)". And of course, adding more information is done _automatically_ when someone responds to the tracked report. So adding to the tracker with a canned phrase "Small example, and error symptom still missing" might well be a safe choice in any case. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this "programming error"?
On Thu, Jun 10, 2010 at 03:32:46PM +0200, Valentin Villenave wrote: > I have (sorta) planned to do this as soon as I have a bit more time > (several dozen hours are easily required), aka later this month. If it takes you longer than 10 minutes to process a single email, you're doing something wrong. My initial guess is that you're not rejecting the report when you *should* be rejecting it. I handled over 90% of reports in less than 2 minutes. If the user hasn't said why the output isn't correct, write back to them. You don't need to know anything about Hebrew lyrics or whatever; keep on rejecting the reports until the user writes "the third symbol from the left should look like an upside-down rabbit, but it currently looks like a sideways raddish". If you're not familiar with violin parts, force the user to say "the upside-down square bucket on the c4\downbow note should be rotated 180 degrees". Whatever. The target is to handle **every** report within **24 hours**. Rejecting is a completely acceptable means of handling it. Look for any excuse you can find to reject the report -- but *find* one, and *write back* to the user. Pretending that you didn't see the email, or letting it rot in your "todo" folder for 3 months, is *not* an acceptable means of handling it. Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this "programming error"?
On Thu, Jun 10, 2010 at 3:23 PM, Graham Percival wrote: > Focus on processing other old reports that haven't been dealt with > yet. I have (sorta) planned to do this as soon as I have a bit more time (several dozen hours are easily required), aka later this month. As for David's bug, it does remind me of something... Perhaps #781? Dmytro: thanks for having added this! Cheers, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this "programming error"?
On Thu, Jun 10, 2010 at 09:46:49AM +0300, Dmytro O. Redchuk wrote: > I didn't know that all "programming errors" should be considered as unexpected > and therefore should be recorded. I'll try to figure out why i didn't. Don't waste your time; that's something for the CG to state, and as you know I'm already in the middle of revamping that chapter. Focus on processing other old reports that haven't been dealt with yet. Especially stuff that Phil Holmes finds -- he's searching through the archives for lost stuff; please PLEASE don't ignore the emails this time around. PS note that the "new email checklist" does *not* contain an item for "ignore the email and hope that somebody else handles it". If you can't reject the report for having no Tiny example, no version number, not being able to reproduce it, etc., then you MUST move on to the final point, namely adding it to the tracker. Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this "programming error"?
On Fri 04 Jun 2010, 17:52 David Kastrup wrote:
> David Kastrup writes:
[...]
> \new Voice \with {\consists "Ambitus_engraver"} { s4*0 \new Voice { c''4 } }
>
> creates the above errors.
Thank you, added as 1113:
http://code.google.com/p/lilypond/issues/detail?id=1113
>
> --
> David Kastrup
On Wed 09 Jun 2010, 17:02 Graham Percival wrote:
> On Wed, Jun 9, 2010 at 4:55 PM, James Bailey
> wrote:
> > Am I to understand that a programming error should have a bug report?
>
> Yes; current policy is to record all warnings (even "false warnings",
> which produce good output but include an unexpected error/warning
[...]
_unexpected_
I didn't know that all "programming errors" should be considered as unexpected
and therefore should be recorded. I'll try to figure out why i didn't.
>
> Cheers,
> - Graham
--
Dmytro O. Redchuk
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this "programming error"?
Graham Percival writes: > On Wed, Jun 9, 2010 at 4:55 PM, James Bailey > wrote: >> Am I to understand that a programming error should have a bug report? > > Yes; current policy is to record all warnings (even "false warnings", > which produce good output but include an unexpected error/warning > message on the console). This is a change from a few years ago, and > will probably add 100-200 extra issues, but there was strong feelings > towards adding them. "programming error" basically means that something happened that should never happen. If there had been no programming involved on part of the user, it is a problem in the existing Lilypond code. "programming error" also implies that the action taken (if it is not a straight abort) is just a best shot at dealing with a case that has been deemed impossible. It is probably a bit too optimistic to assume that such a best shot will always lead to correct results. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this "programming error"?
On Wed, Jun 9, 2010 at 4:55 PM, James Bailey wrote: > Am I to understand that a programming error should have a bug report? Yes; current policy is to record all warnings (even "false warnings", which produce good output but include an unexpected error/warning message on the console). This is a change from a few years ago, and will probably add 100-200 extra issues, but there was strong feelings towards adding them. (if nothing else, it was suggested that fixing these could be a good task for frogs) Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this "programming error"?
On 09.06.2010, at 17:28, Graham Percival wrote: On Wed, Jun 9, 2010 at 4:14 PM, Reinhold Kainhofer wrote: But in this case, it is probably because hardly anyone is really using the Ambitus_engraver. In my case, I have no particular knowledge, so I can't help you in any way and thus cannot answer. That's no excuse for the Bug Squad, though -- somebody should have tried compiling his example, seen the same "programming error", and added it to the tracker. Absolutely no understanding necessary. Takes 5 minutes at most. and YES, I've been considering how to best explain that in the cg, and YES, I've been thinking about how to organize the squad so that this is less likely to happen in the future, and YES, the situation was under control. Am I to understand that a programming error should have a bug report? I, like dmytro, was simply confused as to what the problem was, and what the expected should have been. Something on this level gets filed (in my brain) as "programmer stuff" which I just accept as "too difficult for me to understand". ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this "programming error"?
Reinhold Kainhofer writes: > Am Mittwoch, 9. Juni 2010, 16:52:58 schrieb David Kastrup: >> Uh, am I by now in everybody's killfile, or do people just enjoy having >> me throw a fit for every contribution? > > To be honest, I can imagine that some people might really choose to ignore > your posts (sometimes, they can really make your blood boil when reading > them...). > > But in this case, it is probably because hardly anyone is really using > the Ambitus_engraver. In my case, I have no particular knowledge, so I > can't help you in any way and thus cannot answer. I was not having an issue with nobody providing a solution right away. I was bothered about the problem not getting registered at all, even after I provided a set of simplified relevant test cases. I was not successful tracking this to the respective C++ code paths in the involved class functions. So I reported how far I got. > There are so many corners in LilyPond, where you are basically on your > own when you encounter some strange issue... How nice or not nice someone is might very well direct the resources people are willing to spend on fixing a particular bug. But merely registering the bug should not count towards being pleasant to me in particular. In fact, it might eventually save someone nicer encountering the same problem the work of boiling it down to relevant minimal test cases with differing behavior. All the best -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this "programming error"?
On Wed, Jun 9, 2010 at 4:14 PM, Reinhold Kainhofer wrote: > But in this case, it is probably because hardly anyone is really using the > Ambitus_engraver. In my case, I have no particular knowledge, so I can't help > you in any way and thus cannot answer. That's no excuse for the Bug Squad, though -- somebody should have tried compiling his example, seen the same "programming error", and added it to the tracker. Absolutely no understanding necessary. Takes 5 minutes at most. and YES, I've been considering how to best explain that in the cg, and YES, I've been thinking about how to organize the squad so that this is less likely to happen in the future, and YES, the situation was under control. Want it to happen faster? Well, it _would_ have happened faster if I wasn't reviewing patches. But I think that patch-reviewing should have *top* priority, so I pushed the CG and Bug Squad organization onto the top of my "todo" pile, instead of the active task. Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this "programming error"?
"Dmytro O. Redchuk" writes:
> On Wed 09 Jun 2010, 16:52 David Kastrup wrote:
>
>> Anyway, I should think that this bug description including a list of
>> relevant examples should warrant being recorded by the bug squad.
> i simply can not understand (tm) what's the problem (tm):
The error messages?
> On Thu 03 Jun 2010, 14:34 David Kastrup wrote:
>> When compiling
>>
>> \new Voice \with {\consists "Ambitus_engraver"}
>> {<<\new Voice { c } s>> { c } }
>>
>> I get the following two "programming error"s. What's up?
>>
>
>> programming error: note column without heads and stem
> note column is _really_ without heads and stem...
At the point of time that the "bug" is reported. But that time is
premature since respective ambitus data arrives later.
>> continuing, cross fingers
>> /tmp/junk.ly:2:26: programming error: note-column has no direction
>> {<<\new Voice { c } s>> {
>> c } }
> ... well, i can easily believe it _really_ has no direction.
See above.
> Sorry, i _really_ could not catch the idea. So i waited (as usually)
> for some discussion of the topic. And still waiting, be sure .)
The problem is that the ambitus engraver barfs because of a lack of data
that is going to arrive later.
It appears that there are some measures in the engraver that avoid those
messages for some of the simplest cases (see in particular the examples
I gave that _don't_ throw errors), but they don't seem to do the job
properly.
The ambitus engraver tries evaluating something at a time when it does
not work. Whether or not that is convenient or the only way to do it,
it should not be able to cause errors until the voice actually ends.
And then the error should not be something utterly bewildering, but
clearly pointing to the lack of collected ambitus data.
Does this make the problem clearer?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this "programming error"?
David,
I wrote to you privately to say that I was aware of your report, and
would send an "ungently public reminder to the Bug Squad if they
hadn't dealt with it in a few days".
Now, you could argue that it had been more than "a few days", but I
wanted to give them a few days to catch up without having the
distraction of a new draft of the Issues CG chapter. You may have
noticed that I hadn't sent any request to review the third draft of
this chapter, despite me making some significant changes to the
version in git. In fact, earlier today Valentin seemed to be catching
up on old issues, so there's some evidence that my hope wasn't
completely in vain.
Please trust me a bit more. If you disagreed with my waiting, I would
have hoped that you would have asked me privately why I wasn't yelling
at them yet, since I specifically wrote to you privately to explain
the situation, and said that I was quite prepared to yell at them.
Herding cats is not easy; please don't make my job harder.
- Graham
On Wed, Jun 9, 2010 at 3:52 PM, David Kastrup wrote:
>
> Uh, am I by now in everybody's killfile, or do people just enjoy having
> me throw a fit for every contribution? If it is the latter, I am afraid
> that I am currently hospitalized because of my blood pressure and I sort
> of think that my doctors would disapprove. Tough luck. Maybe next
> time.
>
> Anyway, I should think that this bug description including a list of
> relevant examples should warrant being recorded by the bug squad.
>
> All the best.
>
> David Kastrup writes:
>
>> David Kastrup writes:
>>>
>>> I get the following two "programming error"s. What's up?
>>
>> A simpler test case is
>>
>> \new Voice \with {\consists "Ambitus_engraver"} { \new Voice { c'' } }
>>
>> The key point appears to be that the music written in the inner voice
>> apparently is sufficient for triggering some processing that would
>> require the c'' to be actually in the voice with the Ambitus_engraver.
>>
>> The error occurs even if there are any notes after the inner voice. It
>> does not occur when any music (including just s) is placed before the
>> inner voice. This seems to depend on both timing as well as notes:
>>
>> \new Voice \with {\consists "Ambitus_engraver"} { s4 \new Voice { c''4 } }
>>
>> creates no error.
>>
>> \new Voice \with {\consists "Ambitus_engraver"} { c4*0 \new Voice { c''4 } }
>>
>> creates no error.
>>
>> \new Voice \with {\consists "Ambitus_engraver"} { s4*0 \new Voice { c''4 } }
>>
>> creates the above errors.
>
> --
> David Kastrup
>
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> http://lists.gnu.org/mailman/listinfo/bug-lilypond
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this "programming error"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Mittwoch, 9. Juni 2010, 16:52:58 schrieb David Kastrup: > Uh, am I by now in everybody's killfile, or do people just enjoy having > me throw a fit for every contribution? To be honest, I can imagine that some people might really choose to ignore your posts (sometimes, they can really make your blood boil when reading them...). But in this case, it is probably because hardly anyone is really using the Ambitus_engraver. In my case, I have no particular knowledge, so I can't help you in any way and thus cannot answer. There are so many corners in LilyPond, where you are basically on your own when you encounter some strange issue... Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFMD6/LTqjEwhXvPN0RAufiAKCZNFk0yA4a6rxlNOG6Tnwlo2Y82wCeKAPu DS1zKKcTY+JRPTxYeBTafEU= =ZVip -END PGP SIGNATURE- ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this "programming error"?
On Wed 09 Jun 2010, 16:52 David Kastrup wrote:
> Uh, am I by now in everybody's killfile
Not at all, be sure,
> Anyway, I should think that this bug description including a list of
> relevant examples should warrant being recorded by the bug squad.
i simply can not understand (tm) what's the problem (tm):
On Thu 03 Jun 2010, 14:34 David Kastrup wrote:
> When compiling
>
> \new Voice \with {\consists "Ambitus_engraver"}
> {<<\new Voice { c } s>> { c } }
>
> I get the following two "programming error"s. What's up?
>
> programming error: note column without heads and stem
note column is _really_ without heads and stem...
> continuing, cross fingers
> /tmp/junk.ly:2:26: programming error: note-column has no direction
> {<<\new Voice { c } s>> {
> c } }
... well, i can easily believe it _really_ has no direction.
Sorry, i _really_ could not catch the idea. So i waited (as usually) for some
discussion of the topic. And still waiting, be sure .)
>
> --
> David Kastrup
--
Dmytro O. Redchuk
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this "programming error"?
Uh, am I by now in everybody's killfile, or do people just enjoy having
me throw a fit for every contribution? If it is the latter, I am afraid
that I am currently hospitalized because of my blood pressure and I sort
of think that my doctors would disapprove. Tough luck. Maybe next
time.
Anyway, I should think that this bug description including a list of
relevant examples should warrant being recorded by the bug squad.
All the best.
David Kastrup writes:
> David Kastrup writes:
>>
>> I get the following two "programming error"s. What's up?
>
> A simpler test case is
>
> \new Voice \with {\consists "Ambitus_engraver"} { \new Voice { c'' } }
>
> The key point appears to be that the music written in the inner voice
> apparently is sufficient for triggering some processing that would
> require the c'' to be actually in the voice with the Ambitus_engraver.
>
> The error occurs even if there are any notes after the inner voice. It
> does not occur when any music (including just s) is placed before the
> inner voice. This seems to depend on both timing as well as notes:
>
> \new Voice \with {\consists "Ambitus_engraver"} { s4 \new Voice { c''4 } }
>
> creates no error.
>
> \new Voice \with {\consists "Ambitus_engraver"} { c4*0 \new Voice { c''4 } }
>
> creates no error.
>
> \new Voice \with {\consists "Ambitus_engraver"} { s4*0 \new Voice { c''4 } }
>
> creates the above errors.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: What's the deal with this "programming error"?
David Kastrup writes:
> When compiling
>
> \new Voice \with {\consists "Ambitus_engraver"}
> {<<\new Voice { c } s>> { c } }
>
> I get the following two "programming error"s. What's up?
A simpler test case is
\new Voice \with {\consists "Ambitus_engraver"} { \new Voice { c'' } }
The key point appears to be that the music written in the inner voice
apparently is sufficient for triggering some processing that would
require the c'' to be actually in the voice with the Ambitus_engraver.
The error occurs even if there are any notes after the inner voice. It
does not occur when any music (including just s) is placed before the
inner voice. This seems to depend on both timing as well as notes:
\new Voice \with {\consists "Ambitus_engraver"} { s4 \new Voice { c''4 } }
creates no error.
\new Voice \with {\consists "Ambitus_engraver"} { c4*0 \new Voice { c''4 } }
creates no error.
\new Voice \with {\consists "Ambitus_engraver"} { s4*0 \new Voice { c''4 } }
creates the above errors.
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
What's the deal with this "programming error"?
When compiling
\new Voice \with {\consists "Ambitus_engraver"}
{<<\new Voice { c } s>> { c } }
I get the following two "programming error"s. What's up?
lilypond /tmp/junk.ly
GNU LilyPond 2.13.23
Processing `/tmp/junk.ly'
Parsing...
/tmp/junk.ly:0: warning: no \version statement found, please add
\version "2.13.23"
for future compatibility
Interpreting music...
Preprocessing graphical objects...
programming error: note column without heads and stem
continuing, cross fingers
/tmp/junk.ly:2:26: programming error: note-column has no direction
{<<\new Voice { c } s>> {
c } }
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
