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
