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
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
