Re: minimal examples

[Hans Aberg]

On 7 Dec 2007, at 14:23, Mats Bengtsson wrote:

> > The problem is that a user which does not know anything about  
> > actual LilyPond debugging is in a rather poor position doing the  
> > actual reduction you want to see unless you tell how. This is  
> > normal in bug reporting. I think you need to have at least one  
> > developer accessible to have a look at the bug reports before  
> > filing; this way others will learn, and the long term developer  
> > effort will be reduced.

> That's what Graham is trying to do. He voluntarily does a huge job  
> on both this task
> and the document revisions, all on his spare time.

He said that he did not know much about the internals. So the  
suggestion is to have somebody with that hekping out, which he  
already noticed.

> Please don't feel insulted by his
> comments on non-minimal examples. The next time you submit a bug  
> report, I'm
> sure you will spend a few more minutes yourself first.

Don't you think folks might find it insulting, as you essentially do,  
saying they should spend more time doing something they can't do  
simply because they do not have the information? It was great when  
Graham said that "this or that might not be needed, please try reduce  
it a bit further". If you work on a bit more interaction, then you  
should be able to get people to help out more. Eventually, there  
might be more folks helping out. That is the idea.

> Apart from simplifying the
> task for Graham and the LilyPond hackers, another main advantage of  
> this
> exercise is that the process of reducing an example down to a few  
> lines often
> teaches you a lot about how LilyPond works and sometimes you figure  
> out that
> it wasn't a bug at all, but just a misunderstanding from your own  
> side. Also,
> the things you learned during the process will often be very useful  
> when you
> typeset some other score in the future.

So that is why you need helping out, instead assuming folks can do it  
on their own. Getting to understand LilyPond internals is, as it is,  
harder than a debugging C++ compiler and I have reported loads of C++  
compiler internal bugs. If I think it is that hard, how do you expect  
musicans which may not have that technical training doing it?

> So, Grahams picky comments are actually
> also part of a pedagogical effort to improve the LilyPond  
> competence of every
> user (perhaps unintentionally).

He took advantage of my guessing to reduce it further, as he already  
pointed out. I did not know what to do with it. So how should I have  
proceeded.

> Anyway, the main point is that there's a lack of developers  
> resources so it's a
> great thing that the main hackers don't have to spend their time  
> sifting through
> the bug-lilypond mailing list to figure out what is a real bug and  
> was isn't.

So that is why you somehow need to forward the basic knowledge to  
others that can standby by on the mailing lists.

> > > All the bug reporting process is described on
> > > http://lilypond.org/web/devel/participating/bugs
> > > Granted, it's not very easy to find, but it does exist.
> >
> > If you want people to follow this, simplify it as much as  
> > possible. For example, it would be good if you could make sure the  
> > "\paper{ ragged-right=##t }" is not needed, somehow (a default in  
> > LilyPond?). Things that users can't understand why it should be  
> > there, no matter how useful it is to developers, is likely to drop  
> > out anyway in the user's bug reports.

> Sure, but if you take the effort to copy/paste that line from the  
> instructions, you will
> very quickly notice the difference and realize that it was indeed  
> useful, not only for
> the specific bug report (where Graham easily can add that line  
> himself) but also when
> you do your own experiments to learn more about LilyPond.

The main point is that it is not intuitive.

> Actually, some 10 years ago in the very first pre-releases of  
> LilyPond, there was
> the special feature that if you changed the file suffix from .ly  
> to .sly (or whatever, I
> don't remember exactly), then LilyPond added some standard code  
> around the
> contents of the file, similarly to what you request above.

That is equally unintuitive.

> However, this feature was
> removed a long time ago and I was one of the people who advocated  
> this change,
> since it was a feature that's not useful in any real-world  
> typesetting, just for doing
> small toy examples and that it could more confusion than help.

So this was surely right.

> Now that it's no longer necessary to include an explicit \score 
> {...} block, for example,
> we are almost back at the same situation that was previously  
> offered by the .sly file
> suffix. As has been discussed on the mailing lists, this is not  
> necessarily a good thing,
> since once you really need to explicitly specify a \score block,  
> then you have never
> learned to do it and some the things that LilyPond does by default  
> is fairly non-
> intuitive. However, this is another discussion.

LilyPond surely needs a better interface, and better syntax, but  
right now, it may more important to develop the internals.

  Hans Åberg