Re: Your Friendly Neighborhood LSR

[Valentin Villenave]

2007/11/27, Rune Zedeler <address@hidden>:

Hi Rune,

> Valentin Villenave skrev:
>
> >     --> First rule of LSR is: do not add a \version line.
> >     --> Second rule of LSR is: do NOT add a \version line.
>
> What is the reason for this?

OK, let me explain more about it (I had a hard time understanding that
too, by the way).

The snippets are supposed to be *all* compatible with the latest
stable version. If one wish to demonstrate a new bleeding-edge feature
from the development branch, one has to comment all the non-stable
code, and mark it as "version-specific". It's that simple.

The reason why I'm doing this is that otherwise we would even *not*
accept non-stable snippets at all (I had to convince Graham that we
needed those, and I don't know if I have convinced him yet).

> The version line might be good information to have - at least in a
> comment. If a snippet stops behaving correctly, the original author of
> the snippet is gone, nobody any longer really remembers what the snippet
> was supposed to do - then the version line will give a hint on which
> ancient lilypond to use in order to see the snippet as the contributor
> intended.

No. If we ever find such a snippet, and if we really have *no idea* of
what it's supposed to do, *no way* to contact its author and *not a
clue* about how to make it work, we just delete it.

The last time I deleted a snippet that was not a duplicate, it was an
obviously deprecated TeX-based snippet that, frankly I don't care if
it was built on 2.2 or 2.4.

> Automatically commenting out version lines - and automatically
> complaining if the snippet asks for a wrong version - should be quite
> simple.

Mmm... This might be a good idea. I'll submit it to Graham and
Sebastiano; however IMHO this wouldn't be very much useful; as I've
explained above, snippets are not meant to be ever old. The only
utility I can see to such an addition would be to prevent users that
are still running an old LilyPond version from adding snippets based
on their version.

> Why is it that you cannot preview a snippet from the database before you
> are logged in?

Good point. I'll add it on my ask-Seba list.

> And I really think that the author of each snippet should be visible
> from within the database. If you have a question regarding some code it
> is good to know who provided the snippet.

I'll ask as well. See below.

> The tagging is great, of course :-)
> You did not really write anything about how far the implementation has
> gone. afaics you are unable to search on the tags - or use them in any
> way. What are the plans for this?

Yes, this is kind of an annoyance.
Actually, there is a list.php?type=tag page, which I use everyday. But
this is not meant for users. However, as soon as I finish tagging the
snippets, I think we'll remove the "directory" search, and replace it
with "tag" search.


2007/11/27, Mats Bengtsson <address@hidden>:

Hi Mats,

> I have some similar thoughts. I definitely think that the .ly code shown
> when
> you click on a snippet should include a \version line (even if it isn't
> stored
> internally in the database). This is crucial information for the end
> user, who
> maybe isn't always using the latest version (or has already updated to an
> unstable version) and doesn't realize why a snippet doesn't work as
> expected. Also, it's not easy to find information the LSR web pages on
> what version you are currently using. The only place I could find is under
> "Contributing", which is not a place where an end user is expected to look.

The current LSR version could be more visible, I agree.
Now, should the snippets include a \version? I'm not sure; this would
imply that *all* snippets, excepted those marked as "version-specific"
would begin with the same \version "2.10" or \version "2.12"...  After
all, verbatim fragments from the manual never include a \version line,
do they?

> However, Rune has also got a point that it would
> be good to know at least about the last version where we are sure that the
> snippet worked as originally intended. Valentin, I think it was you who
> sent some questions some half year ago when you tried to understand and
> update snippets that were outdated (and had not even been updated
> correctly with convert-ly). In the upgrade to the next stable version, I'm
> sure that you will make sure to use convert-ly and manually review every
> snippet to make sure that it produces correct output, but especially for
> more
> complex snippets it may still be easy to miss that there have been some
> unintentional changes in the result.

Hence the "version-specific" tag. Suppose some day we drop the native
Postscript markup backend like we did for TeX. As soon as we did, it
would be really easy to search every snippets including a \postscript
command, and tag them as "version-specific", before considering
modifying or removing them.

> Regarding information on the original author, this would certainly be useful
> for the LSR maintainer, but there are also good reasons not to publish names
> on a public web page, at least not with an email address.

One solution I can imagine would be, once logged, to be able (at least
for the maintainer) to see all users on the list.php?type=usr page.
Currently, I'm unable to see any other account than mine on this page.

2007/11/27, Palmer, Ralph <address@hidden>:
> Greetings -

Hi Ralph,
(btw sorry for having used your first name -- i meant Raph Little, of course).

> Does code ever work in one version, then not work in a subsequent
> version, then work again in an even later version? I can see where it
> might, at least at the x.x.xx level. If that's the case, snippets could
> end up with multiple version lines.

Yes, this is an interesting idea...

However I don't think the stable branch breaks code, and then fix it,
and then breaks it again etc. (at least, i don't think it's meant to).
I would certainly not be happy with having to use such workarounds...
I sometimes dream of a multiple-lilypond-versions LSR, but both Graham
and Sebastiano (as well as anyone less insane than me) agree to think
this is pure dream.

When you come to use functions that get broken, fixed etc. the only
place to look at would be code.google.com/p/lilypond rather than
lsr.dsi.unimi.it, I'm afraid...

Anyway, I'm glad to see that this do-not-add-a-\version thing inspires
some debates and suggestions. This is by far one of the most important
issues in maintaining the LSR both up-to-date and reliable in the same
time.

Regards,
Valentin