|
From: | Urs Liska |
Subject: | Re: On Frescobaldi |
Date: | Mon, 22 Apr 2019 07:56:57 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 |
Hi Andrew, I don't see any issue with you sending this on-list accidentally
because I think this is where it should be discussed. Am 22.04.19 um 04:31 schrieb Andrew
Bernard:
I must admit I don't recally *exactly* what you described then.
Which is definitely not how it should be ...
Is the no-update issue in any way related to the complexity of the scores or does it already happen with the case when you have one usage.ly and one module.ily file as mentioned at the top of your message? I'm sure I have never looked into the code responsible for updating the Music View, so I seem not to have participated thoroughly in the mentioned previous discussion. So: Is this happening consistently? Only with specific/certain combinations of score files? Does it depend on whether the compiled file is the "current" file or found implicitly (i.e. you have the "module.ily" open but compile the other through the "Always compile this file" option? If I have a set of LilyPond files to work with I'd put some
print() debug statements in a few places in the code to start
figuring out what might be the issue.
Well, as said, having a reproducible state would be a prerequisite. Without that I can't give any advice at this point. However, while we're at it, what you *could* do something about is the slow-down issue. And that would be a *massive* contribution (in terms of impact) (which I'd always perfer over helping to move the oll-snippets files). The problem is that Frescobaldi collects data for syntax
highlighting and autocompletion by parsing the input files. With
large input files and especially large numbers of included files
this becomes very time-consuming, and the basic flaw in the code
is that the full process is triggered upon *every* change in the
current document while being implemented blockingly. So as you
noticed (and I have noticed that too in a few projects) working
with Frescobaldi can become in fact impossible when loading a file
or waiting after each keystroke may become a matter of minutes). The solution is pretty clear and should not be too hard, but I've
never tackled it so far and it's obviously too time-consuming for
Wilbert to do either. a) The update process should be more limited
to what actually has changed (I'd say: only repeat going through
the includes when it's actually an \include statement that has
been modified), and b) the code should be moved to an external
process. It has always been talk about a "background thread", but
as far as I know (which may be wrong) a *thread* wouldn't help us
much because Python threads wouldn't actually use a separate
thread on the CPU. But for using a background *process* we now
have the parallel job queue to reliably manage the background
processes, which should be of use for this problem. Another
approach would be a server process that is spawned at program
startup and that can always be called when an update is necessary.
That might be a better approach because invoking the process would
occur very often and a server process *might* even be a better
place to cache the results (for multiple open documents). I would be happy to give you pointers and assistance, and I'm sure Wilbert (who definitely knows that part of the code better than I do) would be too. The task is not very big but probably risky in terms of side-effects, so it has to be thoroughly discussed, planned and tested (making it somewhat bigger than inherently necessary). But I'm sure the effort-to-impact ratio would be very gratifying :-) Best
|
[Prev in Thread] | Current Thread | [Next in Thread] |