Re: Interactive compiling

[Richard Shann]

On Mon, 2012-12-10 at 18:53 -0500, address@hidden wrote:
> 
> David, Richard, Graham, Jan,
> 
> On Fri, Dec 7, 2012 at 3:07 PM, Joao E. Pereira Jr <address@hidden>
> wrote:
> > David,
> >
> > On Fri, Dec 7, 2012 at 2:10 PM, David Kastrup <address@hidden> wrote:
> >> "Joao E. Pereira Jr" <address@hidden> writes:
> >>
> >>> Hi team,
> >>>
> >>> Most lilypond GUI projects (Frescobaldi, Denemo) I have seen
> implement
> >>> a wrapper in lilypond. I am investigating the possibility to
> transform
> >>> lilypond in a more interactive compiler. I have little
> understanding
> >>> of the code for now, and noticed that before start to parse
> >>> Lily_parser executes a huge amount of code loading init.ly and his
> >>> sons. Could that loading process be isolated, pre executed and
> >>> maintained in memory to serve posterior requests?
> >>
> >> You might want to look at how LilyPond deals with multiple files on
> the
> >> command line and the -djob-count option.
> >
> > I haven't noticed difference in the output of the following comands,
> > maybe wasn't exactly what you meant:
> >
> > out/bin/lilypond ../input/regression/clef-octavation.ly
> > ../input/regression/chromatic-scales.ly
> >
> > out/bin/lilypond -djob-count ../input/regression/clef-octavation.ly
> > ../input/regression/chromatic-scales.ly
> >
> 
> I figured out. I was missing the value of job-count attribute. My
> attached gdb session shows that both childs start to execute the
> init.ly loading code. I know that job-count saves the repeated
> execution of main_with_guile(). My goal now is understand how many
> percent of whole parsing process this loading code represent, and how
> the complexity of isolating this and maintain in memory. Why this
> loading init.ly is called from parse_file() ? and why it should be
> called for every file to parse?
> 
> >>
> >>> Following the same thinking line could the data structure
> (contexts,
> >>> music, property, graphical objects) be maintained in memory and
> >>> changed as user input changes. Some user changes would affect only
> one
> >>> graphical object and maybe trigger a reformatting, others would
> affect
> >>> a property object and trigger a partial recompiling, others would
> >>> affect the ly file and require compiling from scratch.
> >>
> >> The bookkeeping for that kind of thing would likely be
> prohibitively
> >> expensive.
> 
> This is almost becoming a Ph.D research plan. It's about how a backend
> to Scorio.com is supposed to be. I think that it would need many big
> machines to achieve scalable human interactive time response. I'll
> take a more detailed look in Denemo, 
What Denemo is doing is checking every, say, 1/10th second for changes
to the score and, if there are any, re-generating the LilyPond output
for a few measures/staffs around the cursor (a few measures can the the
entire score) and then spawning a new lilypond invocation, reading the
output pdf into a pdf display widget. 
The implementation is very simple - no optimization - but is even so
quite usable. Things like re-angling beaming are much better done by
drawing directly over the output pdf than by trial-and-error entering of
numbers into the LilyPond source, and things like re-shaping slurs are,
I would guess, only really feasible done that way (unless you can
visualize Bezier curves from the coordinates of the control points :)
Even simple operations such as suggesting a page break become more
natural when you can click on the link that LilyPond provides in the pdf
output and issue the page break command, even though all that is really
happening is that the LilyPond link is returning Denemo's cursor to the
correct place in the score and the command is just the same one you
would have issued looking at the input music display. It is just that
you are looking at the final typeset score while you do it, and,
depending on the score size and machine speed, there will be a gulp
before you see the effect. That gulp is, of course, the price you pay
for having LilyPond make almost all the decisions for you. One or two
tweaks are all I need for a typical score, often times none.

Richard Shann