Re: Patchy email

[David Kastrup]

Jonas Hahnfeld <address@hidden> writes:

> Am Sonntag, den 19.04.2020, 20:03 +0200 schrieb David Kastrup:
>> David Kastrup <
>> address@hidden
>> > writes:
>> 
>> > David Kastrup <
>> > address@hidden
>> > > writes:
>> > 
>> > > David Kastrup <
>> > > address@hidden
>> > > > writes:
>> > > 
>> > > > Valentin Villenave <
>> > > > address@hidden
>> > > > > writes:
>> > > > 
>> > > > > On 4/19/20, David Kastrup <
>> > > > > address@hidden
>> > > > > > 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