Re: Patchy email

[Jonas Hahnfeld]

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).

signature.asc
Description: This is a digitally signed message part