Urs Liska <address@hidden> writes:
Am 09.04.2014 11:53, schrieb Jan Warchoł:
Concerning compilation speed - this is indeed a serious problem for
LilyPond, and i don't know which part of the code is most responsible for
this. Unfortunately i expect that changing this would require at least one
experienced programmer spending a lot of time (3-6 months?) just on that
issue. So, unless David would like to tackle this (and unfortunately this
is not exactly his area of interest),
It's actually the area I am so good at that I never know where to start
and end up doing nothing.
It's mostly a straightforward benchmark-and-improve cycle.
In the current environment? I don't think all that much. The important
thing remains the creative process, and that does not (or should not)
involve running LilyPond.
2014-04-04 16:42 GMT+02:00 David Kastrup <address@hidden>:
That's about one page every 50 minutes. 12 seconds are not much for
that as long as the tools don't require you to recompile for doing every
trivial little correction.
I confirm that 0.2 vs 12 seconds does make a big difference. During Fried
songs beautification, i have waited probably 4-5 seconds (on average) and i
considered it waaay too slow for effective and pleasant work experience.
This is because with any non-trivial music (i.e. with any music more
complicated than "twinkle, twinkle, little star" - really) there _is_ a lot
of little corrections that require recompiling to check if they were done
correctly.
So the thing to do is making LilyPond do them right. LilyPond is _not_
the tool to use for a graphical workflow. This is like listing the time
you spend straightening out nails when using a screwdriver to drive them
into a wall and asking for a faster screwdriver to make up for it.
I can fully second that.
This isn't like "we want a graphical workflow". We _do_ want a text
based workflow, but visual feedback _is_ important for a number of use
cases.
But why would you even want a text based workflow for a fundamentally
graphical task? Of course we need LilyPond to do a better job here.
Instead people want easier ways to do LilyPond's job and basically say
"it is ok if LilyPond sucks at positioning music since we are going to
clean up after it anyway".
And the issue was currently newly pointed at from the perspective of
another engraving program that shares a number of aspects with
LilyPond but _does_ manage to provide this kind of near-instant
feedback.
If that's the priority rather than automatic typesetting, then you have
to _start_ the design with that priority and keep throwing everything
overboard interfering with it. Which includes the majority of automatic
positioning algorithms. And extensibility.
And then it makes _perfect_ sense to build the application around
graphical interfaces and instantaneous feedback. If Amadeus were not as
old as it is, that's likely what it would have started out with.
To some extent we will probably have to live with that because nobody
will want to go back to write 80s code without all the conveniences
modern programming systems have given the programmer (at the cost of
runtime speed). And because nobody's available to tackle significant
improvements in that direction. I think this means that we should
think more in the direction of partial compilation. I have some ideas
but didn't have the time so far to bring them to the shape of a
concrete question/proposal.
Let me be quite straightforward here: architecturing "partial
compilation" into a global optimization framework like that of LilyPond
is a buzzphrase that may be fun to throw around. But it will end up
more work and less useful than cranking LilyPond's speed up by a factor
of 4. And it will be quite useless for an actually text-based input
mode of LilyPond rather than a tool detached from the input like Denemo.
If you take a comparative look, Display PostScript was a footnote in
history, and it _never_ resulted in some tool where you would work on
creating PostScript files manually with some form of "partial
compilation". PostScript is not structured enough for that, and
LilyPond is not structured enough for that.
It's not just a matter of architecturing systems for interactive
response, it is also a matter of architecturing input structures
amenable to incremental interpretation.