[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lybook-db etc etc.
Re: lybook-db etc etc.
Thu, 27 Oct 2011 09:07:37 +0200
Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)
Graham Percival <address@hidden> writes:
> On Thu, Oct 27, 2011 at 07:25:19AM +0200, David Kastrup wrote:
>> Graham Percival <address@hidden> writes:
>> > On Wed, Oct 26, 2011 at 05:13:56PM +0200, David Kastrup wrote:
>> >> In my opinion, the whole lybook-db stuff needs to go. Instead, Lilypond
>> >> is run _once_ for all snippets of a lybook source, generating _one_
>> >> PostScript file.
>> > ... so instead of only generating snippets it needs, you want to
>> > generate a full set of snippets for each language, thereby making
>> > "make doc" take roughly 5 times as long as it currently does?
>> Wrong. Thereby making "make doc" do about 5 times the real work as it
>> currently does, taking a fraction of the time.
> Really? if we have exactly the same @lilypond in
> es/learning.tely and fr/learning.tely, how do you avoid
> recompiling that @lilypond if you're running it on a
> .itely_file-by-.itely_file basis?
I don't. I already _said_ that it will do 5 times the real work. But
about 1% of the thrashing and reinitialization. And that is what is
eating up 95% of the time (the vast majority of snippets is trivial and
totally dominated by reinitializing). And five times 1% is still just
> Let me clarify that: "our development team is in a complete mess".
> but whatever. go ahead and write some patches.
That would not be "some patches". It would be about two months of work.
> as long as they don't break stuff, i'm fine with pushing them.
The work _will_ break stuff. For example, Lilypond will need to tell
GhostScript bounding boxes for generating snippet images. For included
PostScript code, it does not know them.
> if somebody wants to complain, they can do so right now, or during the
> review phase.
Cough, cough. We are not at a point of time where complaining makes the
least bit of sense.
> unless john or jan speaks up in the next 24 hours, there's a good
> chance that they'll reappear in 3 weeks asking "why is xyz broken",
> and then we can have another fun round of hating each other for the
> broken situation.
There will be no code in a state fit to complain about in 3 weeks.
> to emphasize: i don't know how the current system works, i don't
> care, and i'm taking no blame if any work on this is rejected or
> reverted in x days or weeks. we are collectively horrible at
> voicing objections to build system changes ahead of time, so any
> work is done at your own risk.
It has nothing to do with the build system at all. This concerns how
Lilypond, in particular lilypond-book, goes about batching its work.
If lilypond-book finishes its work on typical large documents in 5% of
the previous time without touching the lybookdb database, I have little
doubt that somebody _will_ do the job of weeding out all the complex
build-system stuff trying to meddle with the internal operation of