Re: Frescobaldi external PDF viewer not updating
Am 2018-04-23 um 17:08 schrieb David Wright : > On Mon 23 Apr 2018 at 22:30:54 (+1000), Andrew Bernard wrote: >> Also, allow me to clarify. When I said I cannot reproduce the problem, I >> went on to say that Preview is erratic. So in fact, I can reproduce the >> problem (apologies for being obtuse!). Preview only updates sometimes after >> a compile - this is what I mean by erratic. > > Yes, sorry, I got caught out by "Preview" being the first word of a > sentence (and therefore capitalised) and thought it was part of Skim, > whereas I guess it's part of Frescobaldi, which I can't speak to. Preview.app is part of OSX. While I normally use Frescobaldi’s internal PDF view and Acrobat Pro for every other PDF, I tried Preview.app for some TeX projects. My run script always uses OSX’s "open" (similiar to xdg-open on Linux and start on Windows) to open the completed PDF file. Preview.app sometimes updates the already open file and sometimes opens a new window, I don’t get on what that might depend. Also the "old" windows sometimes update somewhen (but mostly not). Greetlings, Hraban --- fiëé visuëlle Henning Hraban Ramm http://www.fiee.net ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Frescobaldi external PDF viewer not updating
On Mon 23 Apr 2018 at 22:30:54 (+1000), Andrew Bernard wrote:
> Hi All,
>
> I don't think it's case closed yet.
>
> Although this is referring to pdflatex, it directly references problems
> with Skim and file notifications in the Mac OS kernel.
>
> https://tex.stackexchange.com/questions/36504/latexmk-pvc-option-breaks-when-compiling-beamer-class/36585#36585
>
> There may be something similar in our context with ghostscript etc, and
> definitely we don';t know enough about Mac OS internals and files and
> notifications.
>
> Also, allow me to clarify. When I said I cannot reproduce the problem, I
> went on to say that Preview is erratic. So in fact, I can reproduce the
> problem (apologies for being obtuse!). Preview only updates sometimes after
> a compile - this is what I mean by erratic.
Yes, sorry, I got caught out by "Preview" being the first word of a
sentence (and therefore capitalised) and thought it was part of Skim,
whereas I guess it's part of Frescobaldi, which I can't speak to.
Nor do I have any knowledge of Skim, nor of current Mac filesystems.
However, I looked at the web page reference and the problem as outlined
could be caused by Skim relying on an open file descriptor, whereas
pdflatex could, after an error has occurred, write a new file from
scratch. Skim is now left holding an open file descriptor pointing to
the inode (unix-speak) of a deleted file (ie no directory entry).
The reply adds a new factor which is that the OS is deciding when to
refresh Skim's display, rather than, as in my experience with xpdf,
leaving it up to the user to do. It sounds as if some OS notifications
happen to arrive at inopportune moments.
However, I'm not aware that Frescobaldi uses pdflatex to write its PDF
files, but was under the impression that they were generated by being
converted from a complete and discrete PostScript file¹. OTOH, the web
page reply might be relevant to people using things like lilypond-book
and \begin{lilypond} with LaTeX documents.
> It would be interesting to get to the bottom of this matte, but I fear we
> are dealing with deep internals issues here, in remote regions normally
> untrodden by mortals - the Mac OS kernel.
I don't understand why the kernel should be involved. I see it as a
userspace problem and the way the applications have been written.
> Skim works for me, but there seems to be something related to large files.
> I am trying one line scores, but Kieren I would imagine you have very large
> orchestral scores. This could be part of the plot, with file writes we
> don't fully have a handle on.
It does sound as if Skim has a very different approach to updating
from my choice of viewer. Xpdf only rereads the file and updates the
display when you (a) change page number, (b) rescale the page,
(c) change the window size, or (d) type r. In particular, it doesn't
update when you expose its window by switching viewports or closing a
window that was concealing it.
This makes it possible to compare two generations of a score by
leaving the old version in one xpdf, running LP, and updating the
version in another xpdf: the blink comparator method², something
that's impossible with a viewer that updates itself, and a feature
I use a lot myself.
¹lilypond -dno-delete-intermediate-files will leave it around.
²used in the discovery of Pluto.
Cheers,
David.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Frescobaldi external PDF viewer not updating
On 23 April 2018 at 22:30, Andrew Bernard wrote: > > https://tex.stackexchange.com/questions/36504/latexmk-pvc-option-breaks-when-compiling-beamer-class/36585#36585 > It wouldn't be difficult to get Frescobaldi to make a copy for viewing after compilation like this suggests. I'm not sure how Ghostscript makes PDFs, but I imagine a single write in a big blob would be the best bet for triggering updates. Vaughan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Frescobaldi external PDF viewer not updating
Hi Andrew, > Although this is referring to pdflatex, it directly references problems with > Skim and file notifications in the Mac OS kernel. > https://tex.stackexchange.com/questions/36504/latexmk-pvc-option-breaks-when-compiling-beamer-class/36585#36585 Nice catch! Yes, that looks promising as a possible root of (or at least related to) the issue I experience. > Preview only updates sometimes after a compile - this is what I mean by > erratic. I noticed that, which is why I originally switched to Skim (which explicitly allows updating). Even with the "once in a while stops updating" issue, Skim still beats Preview as my main external PDF application when doing my Lilypounding. > Skim works for me, but there seems to be something related to large files. I > am trying one line scores, but Kieren I would imagine you have very large > orchestral scores. This could be part of the plot, with file writes we don't > fully have a handle on. Ah! Very astute point. My composing and engraving schedule recently has meant that I have only been engraving small files (2-4 pages), and only working with files for short periods of time (< 1 hour) — and, if memory serves, I’ve not run into the problem lately. I will be tackling some of my bigger files again starting next week, and will be working for much longer chunks of time (up to a whole work day), and will keep my eyes on the behaviour. Thanks! Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Frescobaldi external PDF viewer not updating
Am 2018-04-23 um 14:30 schrieb Andrew Bernard : > Also, allow me to clarify. When I said I cannot reproduce the problem, I went > on to say that Preview is erratic. So in fact, I can reproduce the problem > (apologies for being obtuse!). Preview only updates sometimes after a compile > - this is what I mean by erratic. I experience the same with TeX generated PDFs in Preview. Never tried Skim. Of course, Adobe apps don’t update at all. Greetlings, Hraban --- fiëé visuëlle Henning Hraban Ramm http://www.fiee.net ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Frescobaldi external PDF viewer not updating
Hi All, I don't think it's case closed yet. Although this is referring to pdflatex, it directly references problems with Skim and file notifications in the Mac OS kernel. https://tex.stackexchange.com/questions/36504/latexmk-pvc-option-breaks-when-compiling-beamer-class/36585#36585 There may be something similar in our context with ghostscript etc, and definitely we don';t know enough about Mac OS internals and files and notifications. Also, allow me to clarify. When I said I cannot reproduce the problem, I went on to say that Preview is erratic. So in fact, I can reproduce the problem (apologies for being obtuse!). Preview only updates sometimes after a compile - this is what I mean by erratic. It would be interesting to get to the bottom of this matte, but I fear we are dealing with deep internals issues here, in remote regions normally untrodden by mortals - the Mac OS kernel. Skim works for me, but there seems to be something related to large files. I am trying one line scores, but Kieren I would imagine you have very large orchestral scores. This could be part of the plot, with file writes we don't fully have a handle on. Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Frescobaldi external PDF viewer not updating
On Sun 22 Apr 2018 at 17:55:30 (+1000), Andrew Bernard wrote: > OK. Mac up and running: > > Mac OS 10.13.4 > Frescobaldi 2.20.0 > Lilypond 2.19.80 > Skim 1.4.34 > > All works fine. I am unable to duplicate your problem. I do note that I have > explicitly turned on 'check for file changes' and 'reload automatically' in > the Sync tab of Skim preferences. > > Preview seems erratic. Precise symptoms? > I am loading the named output file. > > Speaking as UNIX programmer with 40 year plus experience, I would > tend not to rely on loading a temp file autogenerated, Who knows how > this is implemented? The tmp file may not be fully written out to disk > by the time the PDF viewer looks at it as this can be asynchronous and > so on, and updates may be missed. It would be useful to know if you ever see the phenomena I described as this might indicate that there isn't any file-locking going on (which appears to be the case in linux). I've been used to running LP on pretty slow machines, but heavy loads could have a similar effect, increasing the chances of seeing partial updates. Mind, it could also depend on details of how the viewer accesses the file. > Writing this down I am aware this sounds like nonsense, but the fact > is that tmp files can have different semantics to disk files and you > just don’t know enough about how it all works. Sometimes tmp file > systems are in RAM and this can change things in subtle ways. Given > this, it sounds dodgy to me to be reading the temp file into a > viewer. I know that Mac writes to /var/folders but again I do not > know enough about how these files are buffered to disk to be > prepared to be using these as an authoritative source for the PDF > viewer. I think this goes partly toward explaining the erratic > behaviour you are seeing. Restarting F obviously works because all > is redone afresh. Then after a while it will go bung again. AIUI Frescobaldi runs LP and LP writes PostScript into a nonce file (named PS files went out with 2.18.2 or thereabouts) which is then converted into a PDF. That means that Frescobaldi isn't using an "apparently PDF" file as some sort of direct-access scratchpad. Buffering/RAM/SSD/spinning rust and has nothing to do with that. The job of the kernel is to hide all that from userspace. Buffers might never get written to an actual device (you might pull the stick out, or just rewrite different information to the file in the meantime), but the kernel will make sure that a reader sees what "ought" to be on the device at the appropriate instant. I assume that F runs LP which produces a discrete log with each run. Does F have its own log of what it's telling LP to do and whether it was successful each time? Does F use any of the "dodgy" command line constructions that have recently been reported here (ie cd'ing into other directories; relative paths containing ../ and so on)? Or eg does it run LP in a temporary directory with its output redirected (and then lose/forget the redirection at some point)? Where are the PS files being written pre- and post-lapse? Cheers, David. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Frescobaldi external PDF viewer not updating
Hi Andrew, Thanks for this. I think I may have miswritten. > I know that Mac writes to /var/folders but again I do not know enough about > how these files are buffered to disk to be prepared to be using these as an > authoritative source for the PDF viewer. I think this goes partly toward > explaining the erratic behaviour you are seeing. I'm saying that the **NON-TEMP** file — sitting on the "regular" part of the drive, right next to the saved Lilypond source file(s) — is the one that stops updating in Skim [with the 'check for file changes' and 'reload automatically' preferences checked]. The only reason I then go to the temp file is because the updates on the **NON-TEMP** file stopped happening. I’m *not* using the temp file as my "primary viewing file". > I am unable to duplicate your problem. As I perhaps didn’t explain well enough, there is an *indeterminate* period of time that passes from the [re]starting of Frescobaldi to the time that the non-temp output PDF file corresponding to a given Lilypond file stops updating. Perhaps helpfully (?), if I'm compiling two or more Lilypond score files, they don’t all suddenly stop updating their respective PDFs at the same time. It’s a very unusual bug, in my opinion. Thanks, Kieren. Kieren MacMillan, composer ‣ website: www.kierenmacmillan.info ‣ email: i...@kierenmacmillan.info ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Frescobaldi external PDF viewer not updating
HI Keiren, I have unhijacked the thread with a new subject. OK. Mac up and running: Mac OS 10.13.4 Frescobaldi 2.20.0 Lilypond 2.19.80 Skim 1.4.34 All works fine. I am unable to duplicate your problem. I do note that I have explicitly turned on 'check for file changes' and 'reload automatically' in the Sync tab of Skim preferences. Preview seems erratic. I am loading the named output file. Speaking as UNIX programmer with 40 year plus experience, I would tend not to rely on loading a temp file autogenerated, Who knows how this is implemented? The tmp file may not be fully written out to disk by the time the PDF viewer looks at it as this can be asynchronous and so on, and updates may be missed. Writing this down I am aware this sounds like nonsense, but the fact is that tmp files can have different semantics to disk files and you just don’t know enough about how it all works. Sometimes tmp file systems are in RAM and this can change things in subtle ways. Given this, it sounds dodgy to me to be reading the temp file into a viewer. I know that Mac writes to /var/folders but again I do not know enough about how these files are buffered to disk to be prepared to be using these as an authoritative source for the PDF viewer. I think this goes partly toward explaining the erratic behaviour you are seeing. Restarting F obviously works because all is redone afresh. Then after a while it will go bung again. Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
