Patchy email

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Patchy email

patchy
16:36:18 (UTC) Begin LilyPond compile, previous commit at 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
16:36:21 From ssh://git.sv.gnu.org/srv/git/lilypond
   12bf65758f..0cfef7069e  master     -> origin/master
   12bf65758f..0cfef7069e  staging    -> origin/staging
16:36:27 Merged staging, now at: 0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
16:36:28 Success: ./autogen.sh --noconfigure
16:36:40 Success: /tmp/lilypond-autobuild/configure --enable-checking
16:36:43 Success: nice make clean
16:40:45 Success: nice make -j9 CPU_COUNT=9
16:42:04 *** FAILED BUILD ***
        nice make test -j9 CPU_COUNT=9
        Previous good commit: 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
        Current broken commit: 0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
16:42:04 *** FAILED STEP ***
        merge from staging
        Failed runner: nice make test -j9 CPU_COUNT=9
See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
16:42:04 Traceback (most recent call last):
  File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 528, in handle_staging
    self.build (issue_id=issue_id)
  File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 328, in build
    issue_id)
  File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 266, in runner
    raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command, this_logfilename))
FailedCommand: Failed runner: nice make test -j9 CPU_COUNT=9
See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt

Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
[hidden email] writes:

> 16:36:18 (UTC) Begin LilyPond compile, previous commit at 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
> 16:36:21 From ssh://git.sv.gnu.org/srv/git/lilypond
>    12bf65758f..0cfef7069e  master     -> origin/master
>    12bf65758f..0cfef7069e  staging    -> origin/staging
> 16:36:27 Merged staging, now at: 0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
> 16:36:28 Success: ./autogen.sh --noconfigure
> 16:36:40 Success: /tmp/lilypond-autobuild/configure --enable-checking
> 16:36:43 Success: nice make clean
> 16:40:45 Success: nice make -j9 CPU_COUNT=9
> 16:42:04 *** FAILED BUILD ***
> nice make test -j9 CPU_COUNT=9
> Previous good commit: 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
> Current broken commit: 0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
> 16:42:04 *** FAILED STEP ***
> merge from staging
> Failed runner: nice make test -j9 CPU_COUNT=9
> See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
> 16:42:04 Traceback (most recent call last):
>   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 528, in handle_staging
>     self.build (issue_id=issue_id)
>   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 328, in build
>     issue_id)
>   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 266, in runner
>     raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command, this_logfilename))
> FailedCommand: Failed runner: nice make test -j9 CPU_COUNT=9
> See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt

That's again font-name-add-files.ly .

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

Jonas Hahnfeld
Am Sonntag, den 19.04.2020, 18:59 +0200 schrieb David Kastrup:

> [hidden email]
>  writes:
>
> > 16:36:18 (UTC) Begin LilyPond compile, previous commit at 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
> > 16:36:21 From ssh://git.sv.gnu.org/srv/git/lilypond
> >    12bf65758f..0cfef7069e  master     -> origin/master
> >    12bf65758f..0cfef7069e  staging    -> origin/staging
> > 16:36:27 Merged staging, now at: 0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
> > 16:36:28 Success: ./autogen.sh --noconfigure
> > 16:36:40 Success: /tmp/lilypond-autobuild/configure --enable-checking
> > 16:36:43 Success: nice make clean
> > 16:40:45 Success: nice make -j9 CPU_COUNT=9
> > 16:42:04 *** FAILED BUILD ***
> > nice make test -j9 CPU_COUNT=9
> > Previous good commit: 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
> > Current broken commit: 0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
> > 16:42:04 *** FAILED STEP ***
> > merge from staging
> > Failed runner: nice make test -j9 CPU_COUNT=9
> > See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
> > 16:42:04 Traceback (most recent call last):
> >   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 528, in handle_staging
> >     self.build (issue_id=issue_id)
> >   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 328, in build
> >     issue_id)
> >   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 266, in runner
> >     raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command, this_logfilename))
> > FailedCommand: Failed runner: nice make test -j9 CPU_COUNT=9
> > See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
>
> That's again font-name-add-files.ly .
Could you maybe share the exact error from make? I've been running this
patch during the countdown and it also passes James' testing...

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
Jonas Hahnfeld <[hidden email]> writes:

> Am Sonntag, den 19.04.2020, 18:59 +0200 schrieb David Kastrup:
>> [hidden email]
>>  writes:
>>
>> > 16:36:18 (UTC) Begin LilyPond compile, previous commit at 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
>> > 16:36:21 From ssh://git.sv.gnu.org/srv/git/lilypond
>> >    12bf65758f..0cfef7069e  master     -> origin/master
>> >    12bf65758f..0cfef7069e  staging    -> origin/staging
>> > 16:36:27 Merged staging, now at: 0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
>> > 16:36:28 Success: ./autogen.sh --noconfigure
>> > 16:36:40 Success: /tmp/lilypond-autobuild/configure --enable-checking
>> > 16:36:43 Success: nice make clean
>> > 16:40:45 Success: nice make -j9 CPU_COUNT=9
>> > 16:42:04 *** FAILED BUILD ***
>> > nice make test -j9 CPU_COUNT=9
>> > Previous good commit: 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
>> > Current broken commit: 0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
>> > 16:42:04 *** FAILED STEP ***
>> > merge from staging
>> > Failed runner: nice make test -j9 CPU_COUNT=9
>> > See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
>> > 16:42:04 Traceback (most recent call last):
>> >   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 528, in handle_staging
>> >     self.build (issue_id=issue_id)
>> >   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 328, in build
>> >     issue_id)
>> >   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 266, in runner
>> >     raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command, this_logfilename))
>> > FailedCommand: Failed runner: nice make test -j9 CPU_COUNT=9
>> > See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
>>
>> That's again font-name-add-files.ly .
>
> Could you maybe share the exact error from make? I've been running this
> patch during the countdown and it also passes James' testing...

I just get the filename so far.  However, there is the following:

dak@lola:/usr/local/tmp/lilypond$ guile
GNU Guile 2.2.7
Copyright (C) 1995-2019 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (define bla (mkstemp! "kaka-XXXXXX"))
ERROR: In procedure mkstemp!:
string is read-only: "kaka-XXXXXX"

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]>

I use Guile-1.8 in my Patchy (I hope) which should not detect this bug
but it still seems worth fixing as it breaks with Guile-2 at the latest.

Also the file that is being created is not being created in some
temporary directory but in the _current_ directory.  Not sure whether
that has something to do with it.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

Jonas Hahnfeld
Am Sonntag, den 19.04.2020, 19:07 +0200 schrieb David Kastrup:

> Jonas Hahnfeld <
> [hidden email]
> > writes:
>
> > Am Sonntag, den 19.04.2020, 18:59 +0200 schrieb David Kastrup:
> > > [hidden email]
> > >
> > >  writes:
> > >
> > > > 16:36:18 (UTC) Begin LilyPond compile, previous commit at 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
> > > > 16:36:21 From ssh://git.sv.gnu.org/srv/git/lilypond
> > > >    12bf65758f..0cfef7069e  master     -> origin/master
> > > >    12bf65758f..0cfef7069e  staging    -> origin/staging
> > > > 16:36:27 Merged staging, now at: 0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
> > > > 16:36:28 Success: ./autogen.sh --noconfigure
> > > > 16:36:40 Success: /tmp/lilypond-autobuild/configure --enable-checking
> > > > 16:36:43 Success: nice make clean
> > > > 16:40:45 Success: nice make -j9 CPU_COUNT=9
> > > > 16:42:04 *** FAILED BUILD ***
> > > > nice make test -j9 CPU_COUNT=9
> > > > Previous good commit: 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
> > > > Current broken commit: 0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
> > > > 16:42:04 *** FAILED STEP ***
> > > > merge from staging
> > > > Failed runner: nice make test -j9 CPU_COUNT=9
> > > > See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
> > > > 16:42:04 Traceback (most recent call last):
> > > >   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 528, in handle_staging
> > > >     self.build (issue_id=issue_id)
> > > >   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 328, in build
> > > >     issue_id)
> > > >   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 266, in runner
> > > >     raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command, this_logfilename))
> > > > FailedCommand: Failed runner: nice make test -j9 CPU_COUNT=9
> > > > See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
> > >
> > > That's again font-name-add-files.ly .
> >
> > Could you maybe share the exact error from make? I've been running this
> > patch during the countdown and it also passes James' testing...
>
> I just get the filename so far.  However, there is the following:
>
> dak@lola:/usr/local/tmp/lilypond$ guile
> GNU Guile 2.2.7
> Copyright (C) 1995-2019 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guile-user)> (define bla (mkstemp! "kaka-XXXXXX"))
> ERROR: In procedure mkstemp!:
> string is read-only: "kaka-XXXXXX"
>
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> scheme@(guile-user) [1]>
>
> I use Guile-1.8 in my Patchy (I hope) which should not detect this bug
> but it still seems worth fixing as it breaks with Guile-2 at the latest.
>
> Also the file that is being created is not being created in some
> temporary directory but in the _current_ directory.  Not sure whether
> that has something to do with it.
It's passing right now with "my" Guile 1.8 and I gave it a try last
week with Guile 2.2, without seeing an issue. Weird

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
Jonas Hahnfeld <[hidden email]> writes:

> Am Sonntag, den 19.04.2020, 19:07 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> [hidden email]
>> > writes:
>>
>> > Am Sonntag, den 19.04.2020, 18:59 +0200 schrieb David Kastrup:
>> > > [hidden email]
>> > >
>> > >  writes:
>> > >
>> > > > 16:36:18 (UTC) Begin LilyPond compile, previous commit at 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
>> > > > 16:36:21 From ssh://git.sv.gnu.org/srv/git/lilypond
>> > > >    12bf65758f..0cfef7069e  master     -> origin/master
>> > > >    12bf65758f..0cfef7069e  staging    -> origin/staging
>> > > > 16:36:27 Merged staging, now at: 0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
>> > > > 16:36:28 Success: ./autogen.sh --noconfigure
>> > > > 16:36:40 Success: /tmp/lilypond-autobuild/configure --enable-checking
>> > > > 16:36:43 Success: nice make clean
>> > > > 16:40:45 Success: nice make -j9 CPU_COUNT=9
>> > > > 16:42:04 *** FAILED BUILD ***
>> > > > nice make test -j9 CPU_COUNT=9
>> > > > Previous good commit: 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
>> > > > Current broken commit: 0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
>> > > > 16:42:04 *** FAILED STEP ***
>> > > > merge from staging
>> > > > Failed runner: nice make test -j9 CPU_COUNT=9
>> > > > See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
>> > > > 16:42:04 Traceback (most recent call last):
>> > > >   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 528, in handle_staging
>> > > >     self.build (issue_id=issue_id)
>> > > >   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 328, in build
>> > > >     issue_id)
>> > > >   File "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 266, in runner
>> > > >     raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command, this_logfilename))
>> > > > FailedCommand: Failed runner: nice make test -j9 CPU_COUNT=9
>> > > > See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
>> > >
>> > > That's again font-name-add-files.ly .
>> >
>> > Could you maybe share the exact error from make? I've been running this
>> > patch during the countdown and it also passes James' testing...
>>
>> I just get the filename so far.  However, there is the following:
>>
>> dak@lola:/usr/local/tmp/lilypond$ guile
>> GNU Guile 2.2.7
>> Copyright (C) 1995-2019 Free Software Foundation, Inc.
>>
>> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
>> This program is free software, and you are welcome to redistribute it
>> under certain conditions; type `,show c' for details.
>>
>> Enter `,help' for help.
>> scheme@(guile-user)> (define bla (mkstemp! "kaka-XXXXXX"))
>> ERROR: In procedure mkstemp!:
>> string is read-only: "kaka-XXXXXX"
>>
>> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>> scheme@(guile-user) [1]>
>>
>> I use Guile-1.8 in my Patchy (I hope) which should not detect this bug
>> but it still seems worth fixing as it breaks with Guile-2 at the latest.
>>
>> Also the file that is being created is not being created in some
>> temporary directory but in the _current_ directory.  Not sure whether
>> that has something to do with it.
>
> It's passing right now with "my" Guile 1.8 and I gave it a try last
> week with Guile 2.2, without seeing an issue. Weird

There is also

\book {

#(let* ((port (open-output-file dummyfontfile)))
  (base64-decode port dummyfont)
  (close port))

#(ly:font-config-add-font dummyfontfile)

\markup \fontsize #20 \override #'(font-name . "DummyGPL") "A"

#(mkdir dummyfontdir)

#(let* ((port (open-output-file dummyfontfileInSubdir)))
   (base64-decode port dummyfontAlt)
   (close port))

#(ly:font-config-add-directory dummyfontdir)

\markup \fontsize #20 \override #'(font-name . "DummyGFDL") "A"
}

%% This will not appear in collated files:

\book {
  #(delete-file dummyname)
  #(delete-file dummyfontfile)
  #(delete-file dummyfontfileInSubdir)
  #(rmdir dummyfontdir)
  \markup { These files and directories should have been removed:}

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.  No idea whether the fonts made it into
LilyPond at that point of time, or how happy LilyPond is with them
appearing.  It might be appending to the font directory after it already
has been deleted?

There may well be race conditions here.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

Valentin Villenave-3
In reply to this post by David Kastrup
On 4/19/20, David Kastrup <[hidden email]> wrote:
> ERROR: In procedure mkstemp!:
> string is read-only: "kaka-XXXXXX"

Could  the following help?

diff --git a/input/regression/font-name-add-files.ly
b/input/regression/font-name-add-files.ly
index 33f73f0c68..264e2b6532 100644
--- a/input/regression/font-name-add-files.ly
+++ b/input/regression/font-name-add-files.ly
@@ -22,7 +22,7 @@ rather than a letter glyph."
 %% but since there’s no mkdtemp in Guile, we need to fiddle with
 %% filename strings anyway:

-dummyname = #(port-filename (mkstemp! "dummyfont-XXXXXX"))
+dummyname = #(string-copy (port-filename (mkstemp! "dummyfont-XXXXXX")))

 dummyfontfile = #(string-append dummyname "-font.otf")
 dummyfontdir = #(string-append dummyname "-dir")


V.

Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

Valentin Villenave-3
In reply to this post by David Kastrup
On 4/19/20, David Kastrup <[hidden email]> 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 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!)

V.

Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
Valentin Villenave <[hidden email]> writes:

> On 4/19/20, David Kastrup <[hidden email]> 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.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
In reply to this post by Valentin Villenave-3
Valentin Villenave <[hidden email]> writes:

> On 4/19/20, David Kastrup <[hidden email]> wrote:
>> ERROR: In procedure mkstemp!:
>> string is read-only: "kaka-XXXXXX"
>
> Could  the following help?
>
> diff --git a/input/regression/font-name-add-files.ly
> b/input/regression/font-name-add-files.ly
> index 33f73f0c68..264e2b6532 100644
> --- a/input/regression/font-name-add-files.ly
> +++ b/input/regression/font-name-add-files.ly
> @@ -22,7 +22,7 @@ rather than a letter glyph."
>  %% but since there’s no mkdtemp in Guile, we need to fiddle with
>  %% filename strings anyway:
>
> -dummyname = #(port-filename (mkstemp! "dummyfont-XXXXXX"))
> +dummyname = #(string-copy (port-filename (mkstemp! "dummyfont-XXXXXX")))
>
>  dummyfontfile = #(string-append dummyname "-font.otf")
>  dummyfontdir = #(string-append dummyname "-dir")

No, that's the wrong way round.  You need (mkstemp! (string-copy "...
because mkstemp! overrides the string.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
In reply to this post by David Kastrup
David Kastrup <[hidden email]> writes:

> Valentin Villenave <[hidden email]> writes:
>
>> On 4/19/20, David Kastrup <[hidden email]> 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?

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
David Kastrup <[hidden email]> writes:

> David Kastrup <[hidden email]> writes:
>
>> Valentin Villenave <[hidden email]> writes:
>>
>>> On 4/19/20, David Kastrup <[hidden email]> 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.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
David Kastrup <[hidden email]> writes:

> David Kastrup <[hidden email]> writes:
>
>> David Kastrup <[hidden email]> writes:
>>
>>> Valentin Villenave <[hidden email]> writes:
>>>
>>>> On 4/19/20, David Kastrup <[hidden email]> 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

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

Valentin Villenave-3
In reply to this post by David Kastrup
On 4/19/20, David Kastrup <[hidden email]> wrote:
> You need (mkstemp! (string-copy "...
> because mkstemp! overrides the string.

Why, yes. What I want to copy is precisely the mkstemp-generated
string. What did I miss?

V.

Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
Valentin Villenave <[hidden email]> writes:

> On 4/19/20, David Kastrup <[hidden email]> wrote:
>> You need (mkstemp! (string-copy "...
>> because mkstemp! overrides the string.
>
> Why, yes. What I want to copy is precisely the mkstemp-generated
> string. What did I miss?

mkstemp! does not generate a string.  It overwrites an existing string
in-place, and that's bad news for a literal string.

At any rate, you don't write, as the comment states, in a "tmp
directory" but rather in the current directory.  If you want a tmp
directory, you need to add it to the path.

And the .uuid file thing is a real problem with some versions of
fontconfig, so I lean to reverting the patch for now.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

Valentin Villenave-3
In reply to this post by David Kastrup
On 4/19/20, David Kastrup <[hidden email]> wrote:
> So I am afraid that things are rather weird at my side:
> -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-165a4187aa4f

WTF. Could it be some trace left due to your filesystem?

Wait a minute, I found this Debian bug report about fontconfig:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897040#21

V.

Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

Valentin Villenave-3
In reply to this post by David Kastrup
On 4/19/20, David Kastrup <[hidden email]> wrote:
> mkstemp! does not generate a string.  It overwrites an existing string
> in-place, and that's bad news for a literal string.

Yes, it overwrite the string, opens a port, then I read the
port-filename which should be an _other_ string object, shouldn’t it?
(sigh -- _none_ of this would happen if they hadn’t decided to remove
tmpnam, or if they had bothered to make tmpnam behave correctly and
respect TMPDIR, or if they had a mkdtemp! function.)

> At any rate, you don't write, as the comment states, in a "tmp
> directory" but rather in the current directory.  If you want a tmp
> directory, you need to add it to the path.

Yes. I thought mkstemp! was located in the TMPDIR directory (as they
state in their latest documentation, which is even invoked as the
rationale for deprecating tmpnam). Turns out it’s merely created in
the cwd, which isn’t nearly as clean. And I am reluctant to use
mkstemp! "tmp/foobar-XXXXXX" because that would make it
OS-non-agnostic.

> And the .uuid file thing is a real problem with some versions of
> fontconfig, so I lean to reverting the patch for now.

Unless there is a way to make it safe for all versions and setups.
(After all, I can test for that .uuid file and delete it if found, or
rm -rf the subdirectory as I said.)

By the way, since you’ve showed us yours, here’s mine:
$: fc-scan --version
fontconfig version 2.13.92

V.

Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

Werner LEMBERG
In reply to this post by David Kastrup

>>> 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?

Definitely not FreeType, but...

>> Seems to be something that fontconfig does.

... now that you mention it, I remember an issue with that on the
fontconfig e-mail list.

> dak@lola:/usr/local/tmp/lilypond2$ fc-list -V
> fontconfig version 2.13.1

We probably have to work around this fontconfig bug for user
convenience...


    Werner

Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

Jonas Hahnfeld
In reply to this post by David Kastrup
Am Sonntag, den 19.04.2020, 20:03 +0200 schrieb David Kastrup:

> David Kastrup <
> [hidden email]
> > writes:
>
> > David Kastrup <
> > [hidden email]
> > > writes:
> >
> > > David Kastrup <
> > > [hidden email]
> > > > writes:
> > >
> > > > Valentin Villenave <
> > > > [hidden email]
> > > > > writes:
> > > >
> > > > > On 4/19/20, David Kastrup <
> > > > > [hidden email]
> > > > > > 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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Patchy email

David Kastrup
In reply to this post by Valentin Villenave-3
Valentin Villenave <[hidden email]> writes:

> On 4/19/20, David Kastrup <[hidden email]> wrote:
>> mkstemp! does not generate a string.  It overwrites an existing string
>> in-place, and that's bad news for a literal string.
>
> Yes, it overwrite the string,

You can/must not override a literal string.  It's read-only.

> opens a port, then I read the port-filename which should be an _other_
> string object, shouldn’t it?

Why?  At any rate, no problem with appending non-destructively to an
existing string.

> (sigh -- _none_ of this would happen if they hadn’t decided to remove
> tmpnam, or if they had bothered to make tmpnam behave correctly and
> respect TMPDIR, or if they had a mkdtemp!  function.)
>
>> At any rate, you don't write, as the comment states, in a "tmp
>> directory" but rather in the current directory.  If you want a tmp
>> directory, you need to add it to the path.
>
> Yes. I thought mkstemp! was located in the TMPDIR directory (as they
> state in their latest documentation, which is even invoked as the
> rationale for deprecating tmpnam). Turns out it’s merely created in
> the cwd, which isn’t nearly as clean. And I am reluctant to use
> mkstemp! "tmp/foobar-XXXXXX" because that would make it
> OS-non-agnostic.

Should be /tmp/foobar-XXXXXX anyway unless environment variable TMPDIR
is set in which case you use that.

>> And the .uuid file thing is a real problem with some versions of
>> fontconfig, so I lean to reverting the patch for now.
>
> Unless there is a way to make it safe for all versions and setups.
> (After all, I can test for that .uuid file and delete it if found, or
> rm -rf the subdirectory as I said.)

Preparing a fixed patch is not precluded by reverting it.

> By the way, since you’ve showed us yours, here’s mine:
> $: fc-scan --version
> fontconfig version 2.13.92

Ok, but at least now it's not the upcoming Ubuntu version.

--
David Kastrup

12