Re: Interactive compiling

[Joao E. Pereira Jr]

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, Schikkers-List, and Firelily if a
have agenda. For now I'm worrying about daemonize lilypond, my first
concern is acquire as many architectural knowledge as I can. The
research will not include the frontend, maybe not even the lilypond
formatter plugin, as in my opinion it would spend another research
itself.

>
> Appears that I'll have to convince some investors.
>
>>
>>> I may be saying a lot of non sense, but I would like to know in
>>> details why is this a bad (very bad) idea!
>>
>> The only way to know in detail is to try.
>>
> That's good news, I'll improve the idea.
>
>> --
>> David Kastrup
>>
>>
>> _______________________________________________
>> lilypond-devel mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>
>
>
> --
> João E. Pereira Jr



-- 
João E. Pereira Jr

gdb-session.txt
Description: Text document