On Sun, 2005-01-30 at 16:38 +0100, Han-Wen Nienhuys wrote:
> This is so incredibly way way cool! I fully support this initiative,
> and will gladly work to make running lily on your server as flawless
> as possible.
I hoped so!
> * Perhaps you can work together with Graham to copy snippets from
> the manual. If the LSR is a success, we can drop the more esoteric
> examples from the manual.
That was my idea, too. I'm a bit exhasted by the last three-days full-
time on the project, but examples from the manual are a perfect source.
> * I suspect that you could import the input/{test,regression}/
> directory wholesale.
Well, I thought about that, but many regressions show that lily does the
right thing when writing stuff normally, so they're not a good candidate
for explaining how to do strange staff. Unless, however, we want to have
a "regression" flag and we have a separate search engine for
regressions, mainly for developer. I'd be glad to do that if you think
it's useful.
> * Also, the vast experience on the list with troubleshooting and
> tweaking lily may be put to good use here. Mats?
Yes, there are a few things in which a little help might be useful.
> * is there a way to condense the DB into an file/package, both
> for offline viewing?
The DB is trivial: "mysqldump lsr" works like a charm. Packaging the
engine is slightly more complex because I would like to have a *single*
jar file, and java -jar lsr.jar should just run the engine. It can be
done, but some more tomcat proficiency is involved.
> * Maybe it would be a good idea to have separate snippet DB for each
> branch (ie. a 2.4 and 2.6 database.). It is possible to run
> multiple versions of Lily alongside eachother. If you can't make
> it work, that is a serious bug, and I will gladly work with you to
> make it work
Yes, this is an excellent idea--much better than the goofy versioning
stuff I've put in. I'll work on that next week.
>
> * every time we branch a devel version, the last stable DB is copied
> over (eg. 2.7), and we let the snippets evolve along with the
> branch. Once we release 2.8, the number is changed from 2.7 to 2.8
That's a good idea. In that case, certainly we need a way (currently
there's none) to run the image updater in such a way to catch
compilation mistakes in a log, so to know which snippet need fixing. But
this is easy.
> This probably also requires that you can create a test-run DB,
> base.
...sorry, can you rephrase that?
>
> Hmmm. Or we developers should include an offline version in the
> RPM/docs package, and run the entire collection as a release-test,
> just like we don't release until the entire doc site build without
> hickups.
No, I think that instead I can just inhibit from showing what does not
compile.
>
> * If I understand you correctly, you run untrusted .ly snippets
> unattended? In that case, I hope you are running lilypond with
> --safe, preferably sandboxed/chrooted. It is possible to do
>
> #(system "rm -rf / ")
>
> and other nasty code from .ly if --safe isn't used.
This is maybe the main problem, and some of you can help. The problem is
that *not all snippets compile in safe mode, even apparently innocuous
ones.* The two snippets about fermate, for instance
\relative c'' {
\override Score.RehearsalMark #'break-visibility = #begin-of-line-invisible
c1 \mark \markup { \musicglyph #"scripts-ufermata" }
}
do NOT compile... so it's a big problem, because important snippets are
out if I use -s. Presently is active, but this will further confuse
users.
chroot'ing would be a kind of mess--lilypond uses zillions of files. But
in case I can rebuild a separate tree. If you have any suggestion about
sandboxing, they're welcome--you know lily, so you know what it could
stand. Maybe with a careful sandboxing we can avoid using safe mode
(maybe killing the process after 10s 8^).
> OK, just a minor concern here; are the state-of-the-art techniques
> freely available: will there be any trade-secret/patent/copyright
> problems in the future, or is the code available now?
I've added some stuff in What's This. Everything is GPL'd or LGPL'd. The
techniques we used a published in scientific journals. I can't speak for
Clarke & Cormack (the guys who published interval semantics first), but
they never claimed to have filed any patents, in any paper.
On the other hand, MG4J is based on vast extensions of Clarke & Cormack
semantics by Paolo Boldi and myself, and THAT, you can be sure, will
never be patented.
> Hey, if you want, we can endow you with the official LilyPond
> Development Team title of SNIPPET MEISTER, and have all the official
> benefits, such as groupies, free beer at the Linux Audio Conference,
> etc. :-)
I like the idea; unfortunately I don't drink 8^).
In any case, my job is nothing compared to the fantastic software you're
working at. It's just that I hate C++ and never understood functional
programming, so I can't really contribute to Lilypond directly. This was
the best I could think of...
--
Ciao,
seba
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
