Jonas Hahnfeld <hah...@hahnjo.de> writes: > Am Sonntag, den 19.04.2020, 20:03 +0200 schrieb David Kastrup: >> David Kastrup < >> d...@gnu.org >> > writes: >> >> > David Kastrup < >> > d...@gnu.org >> > > writes: >> > >> > > David Kastrup < >> > > d...@gnu.org >> > > > writes: >> > > >> > > > Valentin Villenave < >> > > > valen...@villenave.net >> > > > > writes: >> > > > >> > > > > On 4/19/20, David Kastrup < >> > > > > d...@gnu.org >> > > > > > wrote: >> > > > > > Note that the delete-file instructions are executed while the book >> > > > > > is >> > > > > > being read in while markup is typeset when the books are being >> > > > > > processed >> > > > > > at the end of the input file. >> > > > > >> > > > > Yes, it looked completely bonkers to me as well, until I realized it >> > > > > worked :-) >> > > > > >> > > > > > No idea whether the fonts made it into >> > > > > > LilyPond at that point of time, or how happy LilyPond is with them >> > > > > > appearing. >> > > > > >> > > > > No, because at this point the first \book has already been processed, >> > > > > and even GS should already be invoked. That’s the whole point of >> > > > > putting that stuff inside another \book. >> > > > >> > > > There is no point in putting the deletion of files "inside another >> > > > \book" since it is not being executed when the book is typeset but when >> > > > the book is read in. >> > > > >> > > > > > There may well be race conditions here. >> > > > > >> > > > > Well, AFAIK there’s no parallelism inside a same .ly file being >> > > > > processed for different \book outputs. (If there _was_, that would be >> > > > > great news though!) >> > > > >> > > > Again: file creation and deletion happens while the book is being read >> > > > in, typesetting happens when the book is being processed. File handles >> > > > will tend to stick around until garbage collected. That is not as much >> > > > "parallelism" as an absence of order. >> > > >> > > So I am afraid that things are rather weird at my side: >> > > >> > > input/regression/font-name-add-files.ly:244:4: error: GUILE signaled an >> > > error for the expression beginning here >> > > # >> > > (rmdir dummyfontdir) >> > > Directory not empty >> > > Finding the ideal number of pages... >> > > Fitting music on 1 page... >> > > Drawing systems... >> > > Layout output to `/tmp/lilypond-pXKtKN'... >> > > Converting to `font-name-add-files-1.pdf'... >> > > Deleting `/tmp/lilypond-pXKtKN'... >> > > fatal error: failed files: "input/regression/font-name-add-files.ly" >> > > dak@lola:/usr/local/tmp/lilypond2$ ls -l dummyfont-C5PUYM-dir/ >> > > total 0 >> > > dak@lola:/usr/local/tmp/lilypond2$ ls -la dummyfont-C5PUYM-dir/ >> > > total 12 >> > > drwxrwxr-x 2 dak dak 4096 Apr 19 19:51 . >> > > drwxrwxr-x 25 dak dak 4096 Apr 19 19:51 .. >> > > -rw-r--r-- 1 dak dak 36 Apr 19 19:51 .uuid >> > > dak@lola:/usr/local/tmp/lilypond2$ cat dummyfont-C5PUYM-dir/.uuid >> > > 35d52a4b-44f7-41b6-afca-165a4187aa4fdak@lola:/usr/local/tmp/lilypond2$ >> > > >> > > Does anybody have an idea _what_ and _why_ would leave a .uuid file >> > > lying around in the temporary file with, well, an uuid kind of number in >> > > it? Is that an artifact of my freetype library or something? >> > >> > Seems to be something that fontconfig does. >> >> Just in case: >> >> dak@lola:/usr/local/tmp/lilypond2$ fc-list -V >> fontconfig version 2.13.1 > > In case it helps, they're removing the uuid functionality again: > https://gitlab.freedesktop.org/fontconfig/fontconfig/commit/c4324f54ee16e648ba91f3e9c66af13ab3b1754c > > So I guess the fix is to delete the (temporary) directory and all > contained files? And maybe putting it under /tmp? > > Oh, and ignore my comment that I had tested this with Guile 2.2. Looks > like I didn't (at least not properly).
It may depend on how the literal string enters Guile whether the R/O detection triggers. -- David Kastrup