Re: On Frescobaldi

[Urs Liska]

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:

Dear Urs,

On a different tack altogether, with the oll work, you have a usage file and a module.ily, so two files. In my Frescobaldi 3 on a brand new Ubuntu 19 installation (the latest release as of last week) it still shows the problem I mentioned a while ago where the output PDF is not updated after changes.

I must admit I don't recally *exactly* what you described then.

This slowed me down a lot as I could not understand why my outline list code was not working. Reverting to my tried and true Gvim and PDF point and click works perfectly.  Previously I worked around this by putting all the work in one file.

Which is definitely not how it should be ...

I'd like to file a bug report on, this, but I can't see a simple way to reprpduce the problem.

Sounds like a really hard issue to me. I am very sorry to tell you that with the huge slowdown I see in my complex scores - metioned in the past as you know - and with this non-updating issue, I myself can no longer use Frescobaldi. it's a shame, as it is such a brilliant development environment.

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.

Hmm. What to do? I would not know how to solve this, even though I know Python very well.

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
Urs

[I wonder if this is some sort of a buig with the PDF display not updating, perhaps some poppler file modification time issue?]

a

_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user