Re: adding snippets manually

[Graham Percival]

On Sat, Apr 18, 2009 at 08:26:57AM -0600, Carl D. Sorensen wrote:
> 
> On 4/18/09 6:03 AM, "Graham Percival" <address@hidden> wrote:
> 
> > On Fri, Apr 17, 2009 at 09:39:07PM -0600, Carl D. Sorensen wrote:
> > Not only that, but with a minimum of effort.  IMO, people adding
> > new features should only be required to write one .ly file (for
> > input/regression/ ); they shouldn't need to do any other manual
> > tweaking to get a snippet in input/lsr/.
> 
> This is an interesting thought, but I think it would require significant
> reworking of the existing regtests.
>
> One of the issues with regtests is that when a bug is found, a regtest is
> added to demonstrate the bug, and then when it's fixed, the test works
> properly.  But it's not clear to me that such a bug-identifying regtest
> belongs in the manual.

No, no -- when a programmer writes a regtest for a new feature,
the minimal "documentation" work is that he copies it or runs a
python script or something to put it in the snippets.  If he wants
to write more docs for it, such as a non-regtest-like snippet for
input/new/, or actual NR stuff, that's fine... but IMO those
shouldn't be necessary parts of new feature code.

> Let's consider another option -- there's a snippet somebody develops in the
> LSR that's a neat way to do something.  So we want to add it to the manual.
> Should it also be added to the regression tests?  My first thought is no,

Sweet mao no.

> but my second thought says that if it's in the manual, we ought to make sure
> it continues to work.  So I don't know where I come down on it.

We make sure it compiles by compiling the docs.  We absolutely do
not have the resources (in this case, CPU-wise as well as
people-wise) to check every single piece of .ly code that's in the
git tree for every single release.

> > Fixing this could also tie into my long-desired separation of docs
> > from code -- we kill input/ entirely.  Snippets go in docs/input,
> > and regtests go in regression/ or regtests/ or something like
> > that.  Oh, I also hate the capital letter in "Documentation", so
> > I'm wanting "docs/" instead.  And the current input/examples/ dies
> > completely and is replaced by lsr-derived stuff.  And maybe see if
> > we can set up lsr on Valentin's new server, if that new server is
> > more reliable than the current one.
> > 
> I don't have input/examples in my git tree.  Does it still exist?

Umm.  It's actually worse than I remembered; the "examples" are in
input/ directly.  They don't even have their own subdirectory!

> When we get lsr set up on another server, perhaps we can get multiple copies
> set up to handle different LilyPond versions?

Sweet mao no.

>  I think that the major
> limitation on lsr right now (other than the fact that it's frequently down)
> is that it only supports one version of LilyPond, and currently, it's an old
> version (2.10.12).  We'd like to have a 2.10 version, a 2.12 version, and
> maybe even a 2.13 version.

No.  No, we wouldn't like that.  It would be even more of a
support nightmare.

LSR should be the latest stable, which means 2.12.something.
Valentin is supposed to be coordinating this with Sebastiano, but
he's off spending time on other things right now.
*scowl*


Remember that the stable versions of lilypond mean something now,
and they'll be coming out more often.  It shouldn't be a big deal
to update LSR once every 6-8 months.  I'll admit that we might
want special tags for snippets which requires 2.x, rather than any
y < x.

> > And a pony.  I really want a pony.
> 
> Don't think you can have one in Singapore.  I think it would be a risk for
> messing up the streets!

No problem; I can add a bucket attached to the rear.

That's actually what the horse-drawn carriages in Victoria (my old
university city) did.  I always wondered what the smell was like
for the tourists, sitting directly behind such a bucket... but
hey, maybe that just added to the quaint "fake old English"
setting.  :)

Cheers,
- Graham