Disarchive occasionally fails tests

  • Done
  • quality assurance status badge
Details
4 participants
  • Bengt Richter
  • Ludovic Courtès
  • Ludovic Courtès
  • Timothy Sample
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
normal
L
L
Ludovic Courtès wrote on 30 Apr 2021 12:00
(address . bug-guix@gnu.org)
87v984gkhn.fsf@inria.fr
Hi Timothy,

Disarchive 0.2.0 occasionally fails two tests:

FAIL: tests/kinds/octal.scm - [prop] Writing is reversible
FAIL: tests/kinds/octal.scm - [prop] Serializing is reversible

(Thanks, Quickcheck! :-))

I added ‘pk’ calls like so:

Toggle snippet (14 lines)
(test-assert "[prop] Writing is reversible"
(quickcheck
(property ((octal $octal))
(test-when (valid-octal? octal)
(begin
(equal? (pk 'oct octal) (pk 'decode (decode-octal (encode-octal octal)))))))))

(test-assert "[prop] Serializing is reversible"
(quickcheck
(property ((octal $octal))
(test-when (valid-octal? octal)
(equal? (pk 'OCT octal) (pk 'DECODE (serdeser -octal- octal)))))))

and got this output:

Toggle snippet (27 lines)
;;; (oct #<<unstructured-octal> value: 0 source: #<<zero-string> value: "\U0f94a4\u0912\U025627\U10e96a\u9576\u2077\u048f\U0f2f60\U0f744b" trailer: #vu8(172 156 23 48 25 29 159 226 210)>>)

;;; (decode #<<unstructured-octal> value: 0 source: #<<zero-string> value: "\U0f94a4\u0912\U025627\U10e96a\u9576\u2077\u048f\U0f2f60\U0f744b" trailer: #vu8(172 156 23 48 25 29 159 226 210)>>)
actual-value: #f
actual-error:
+ (out-of-range
+ #f
+ "Value out of range ~S to ~S: ~S"
+ (8 9 10)
+ (10))
result: FAIL

[…]

;;; (OCT #<<unstructured-octal> value: 0 source: #<<zero-string> value: "\U0f94a4\u0912\U025627\U10e96a\u9576\u2077\u048f\U0f2f60\U0f744b" trailer: #vu8(172 156 23 48 25 29 159 226 210)>>)

;;; (DECODE #<<unstructured-octal> value: 0 source: #<<zero-string> value: "\U0f94a4\u0912\U025627\U10e96a\u9576\u2077\u048f\U0f2f60\U0f744b" trailer: #vu8(172 156 23 48 25 29 159 226 210)>>)
actual-value: #f
actual-error:
+ (out-of-range
+ #f
+ "Value out of range ~S to ~S: ~S"
+ (8 9 10)
+ (10))
result: FAIL

I’m not sure where the exception comes from though.

Thoughts?

Thanks,
Ludo’.
T
T
Timothy Sample wrote on 30 Apr 2021 21:49
(name . Ludovic Courtès)(address . ludovic.courtes@inria.fr)(address . 48114@debbugs.gnu.org)
87pmybeen3.fsf@ngyro.com
Hey,

Ludovic Courtès <ludovic.courtes@inria.fr> writes:

Toggle quote (5 lines)
> Disarchive 0.2.0 occasionally fails two tests:
>
> FAIL: tests/kinds/octal.scm - [prop] Writing is reversible
> FAIL: tests/kinds/octal.scm - [prop] Serializing is reversible

These two tests have a bit of a problem. They occasionally fail by
“giving up”, which is when too many test cases are discarded rather than
used. (This happens because you might write a generator for a superset
of the values you’re interested in, and then filter out some values with
“test-when”.) I don’t think this is happening here, though. You would
see something like “Gave up! Passed only 0 ests [sic].”

Toggle quote (46 lines)
> I added ‘pk’ calls like so:
>
> (test-assert "[prop] Writing is reversible"
> (quickcheck
> (property ((octal $octal))
> (test-when (valid-octal? octal)
> (begin
> (equal? (pk 'oct octal) (pk 'decode (decode-octal (encode-octal octal)))))))))
>
> (test-assert "[prop] Serializing is reversible"
> (quickcheck
> (property ((octal $octal))
> (test-when (valid-octal? octal)
> (equal? (pk 'OCT octal) (pk 'DECODE (serdeser -octal- octal)))))))
>
>
> and got this output:
>
> ;;; (oct #<<unstructured-octal> value: 0 source: #<<zero-string> value: "\U0f94a4\u0912\U025627\U10e96a\u9576\u2077\u048f\U0f2f60\U0f744b" trailer: #vu8(172 156 23 48 25 29 159 226 210)>>)
>
> ;;; (decode #<<unstructured-octal> value: 0 source: #<<zero-string> value: "\U0f94a4\u0912\U025627\U10e96a\u9576\u2077\u048f\U0f2f60\U0f744b" trailer: #vu8(172 156 23 48 25 29 159 226 210)>>)
> actual-value: #f
> actual-error:
> + (out-of-range
> + #f
> + "Value out of range ~S to ~S: ~S"
> + (8 9 10)
> + (10))
> result: FAIL
>
> […]
>
> ;;; (OCT #<<unstructured-octal> value: 0 source: #<<zero-string> value: "\U0f94a4\u0912\U025627\U10e96a\u9576\u2077\u048f\U0f2f60\U0f744b" trailer: #vu8(172 156 23 48 25 29 159 226 210)>>)
>
> ;;; (DECODE #<<unstructured-octal> value: 0 source: #<<zero-string> value: "\U0f94a4\u0912\U025627\U10e96a\u9576\u2077\u048f\U0f2f60\U0f744b" trailer: #vu8(172 156 23 48 25 29 159 226 210)>>)
> actual-value: #f
> actual-error:
> + (out-of-range
> + #f
> + "Value out of range ~S to ~S: ~S"
> + (8 9 10)
> + (10))
> result: FAIL
>
> I’m not sure where the exception comes from though.

I can’t seem to reproduce this. I’ve run the test suite many, many
times, but I also tried:

,use (disarchive kinds octal)
,use (disarchive kinds zero-string)
,use (disarchive serialization)
(define the-zero-string
(make-zero-string
"\U0f94a4\u0912\U025627\U10e96a\u9576\u2077\u048f\U0f2f60\U0f744b"
#vu8(172 156 23 48 25 29 159 226 210)))
(define the-octal
(make-unstructured-octal 0 the-zero-string))
(equal? the-octal (decode-octal (encode-octal the-octal)))
(equal? the-octal (serdeser -octal- the-octal))

Which works fine. (Does it work for you?)

However, isn’t it possible that these values aren’t the culprits? With
the “pk” calls you added, isn’t it printing the last OK value without
telling us the value causing the issue?

What if you run it with the following?

(test-assert "[prop] Writing is reversible"
(quickcheck
(property ((octal $octal))
(test-when (valid-octal? octal)
(false-if-exception ; <-- changed!
(equal? octal (decode-octal (encode-octal octal))))))))

This way, Guile-QuickCheck should print the offending value and the seed
used for the tests, which could be helpful for reproducing. (The fact
that it doesn’t handle exceptions well is a known bug!)


-- Tim
L
L
Ludovic Courtès wrote on 2 May 2021 21:57
(name . Timothy Sample)(address . samplet@ngyro.com)(address . 48114@debbugs.gnu.org)
874kfk6h8o.fsf@gnu.org
Hello!

Timothy Sample <samplet@ngyro.com> skribis:

Toggle quote (3 lines)
> I can’t seem to reproduce this. I’ve run the test suite many, many
> times, but I also tried:

I can reproduce it quickly with:

while make check TESTS=tests/kinds/octal.scm -j5 ; do : ; done

… in C locale (LC_ALL & co. all unset).

Toggle quote (4 lines)
> However, isn’t it possible that these values aren’t the culprits? With
> the “pk” calls you added, isn’t it printing the last OK value without
> telling us the value causing the issue?

You’re right, the values printed are not the culprit. The problem comes
from the generator (I had to raise the (quickcheck …) form out of
‘test-assert’ so I could get a backtrace):

Toggle snippet (27 lines)
Backtrace:
13 (primitive-load "/data/src/disarchive/./build-aux/test-driver.scm")
In ice-9/eval.scm:
619:8 12 (_ #(#(#<directory (guile-user) 7fccb09d9f00> ((() "./tests/kinds/octal.scm") (# . "no") (# . #) ?)) #))
619:8 11 (_ #(#(#(#(#(#(#(#(#<directory (guile-user) 7fccb09d9f00> ("./tests/kinds/octal?") ?)) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
142:2 10 (dynamic-wind _ _ #<procedure 7fccaf5b81a0 at ice-9/eval.scm:330:13 ()>)
In unknown file:
9 (primitive-load "./tests/kinds/octal.scm")
In quickcheck.scm:
118:6 8 (check #<<quickcheck-config> seed: 321557891 stop?: #<procedure 7fccaf8c3540 at ice-9/eval.scm:336:13?> ?)
98:12 7 (check-results _ #<<property> names: (octal) gen/arbs: (#<<arbitrary> gen: #<<generator> proc: #<proce?>)
In quickcheck/generator.scm:
65:2 6 (_ 7 #<<rng-state> start: #(1907167801 2749187034 1190323419 1039883844 766725436 3567744198) s1: #(29?>)
65:2 5 (_ 7 #<<rng-state> start: #(1907167801 2749187034 1190323419 1039883844 766725436 3567744198) s1: #(29?>)
78:17 4 (_ 7 #<<rng-state> start: #(1907167801 2749187034 1190323419 1039883844 766725436 3567744198) s1: #(28?>)
105:22 3 (_ _)
In tests/kinds.scm:
84:22 2 (fix-unstructured-octal-value #<<unstructured-octal> value: 7 source: #<<zero-string> value: "\U0f99aa?>)
86:47 1 (_ _)
In unknown file:
0 (substring "\U0f99aa?\U0ff7c1\U0fb97a\U0ff933?\U0fe7a1" 6 8)

ERROR: In procedure substring:
Value out of range 6 to 7: 8

Note that this is in C locale, which may mean that ‘regexp-exec’, which
passes strings to libc, gets offsets wrong somehow (see
‘fixup_multibyte_match’ in libguile), though I couldn’t reproduce it
with the string above.

Anyway, ‘guix build disarchive’ builds in en_US.utf8 locale, so the
thing above is probably a wrong lead.

If I switch to en_US.utf8, I occasionally get the following error
instead:

Toggle snippet (22 lines)
test-name: [prop] Serializing is reversible
location: tests/kinds/octal.scm:154
source:
+ (test-assert
+ "[prop] Serializing is reversible"
+ (quickcheck
+ (property
+ ((octal $octal))
+ (test-when
+ (valid-octal? octal)
+ (equal?
+ (pk 'OCT octal)
+ (pk 'DECODE (serdeser -octal- octal)))))))

;;; (OCT #<<unstructured-octal> value: 0 source: #<<zero-string> value: "" trailer: "">>)

;;; (DECODE #<<unstructured-octal> value: 0 source: #<<zero-string> value: "" trailer: "">>)
Gave up! Passed only 1 est.
actual-value: #f
result: FAIL

This is more in line with what you described. Any ideas on how to
address that?

Thanks,
Ludo’.
T
T
Timothy Sample wrote on 3 May 2021 04:24
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 48114@debbugs.gnu.org)
87a6pceerf.fsf@ngyro.com
Hi,

Ludovic Courtès <ludo@gnu.org> writes:

[...]

Toggle quote (8 lines)
> ERROR: In procedure substring:
> Value out of range 6 to 7: 8
>
> Note that this is in C locale, which may mean that ‘regexp-exec’, which
> passes strings to libc, gets offsets wrong somehow (see
> ‘fixup_multibyte_match’ in libguile), though I couldn’t reproduce it
> with the string above.

I’m still looking into this, but I wanted to quickly post this
reproducer for the Guile bug:

(use-modules (ice-9 regex))
(define str "\U101514\U103ab0\U0f6e6e\U02e278\U01d9eb\U10b996\U1089b5\uea15\U0fa074\U101e41\U02e330\u0177\u2492")
(match:substring (string-match "[0-8]+" str))

This triggers the out-of-range error when run with “LC_ALL=C”.


-- Tim
T
T
Timothy Sample wrote on 3 May 2021 06:02
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 48114@debbugs.gnu.org)
8735v4ea7y.fsf@ngyro.com
Timothy Sample <samplet@ngyro.com> writes:

Toggle quote (10 lines)
> I’m still looking into this, but I wanted to quickly post this
> reproducer for the Guile bug:
>
> (use-modules (ice-9 regex))
> (define str
> "\U101514\U103ab0\U0f6e6e\U02e278\U01d9eb\U10b996\U1089b5\uea15\U0fa074\U101e41\U02e330\u0177\u2492")
> (match:substring (string-match "[0-8]+" str))
>
> This triggers the out-of-range error when run with “LC_ALL=C”.

It turns out that all that’s needed is the last code point, which is
“Number Eleven Full Stop”, or ‘?’. When Guile converts this to an ASCII
C string using ‘u32_conv_from_encoding’, it becomes “11.”. The regex
(“[0-8]+”) matches the “11” part with start index 0 and end index 2.
The ‘fixup_multibyte_match’ function does nothing (it only matters when
the locale encoding is multibyte) [1]. Guile then builds the match
vector with the original string but keeps the ASCII offsets. In other
words, it thinks the match substring goes from 0 to 2 in a single code
point string:

,use (ice-9 regex)
(string-match "11" "\u2492")
=> #("\u2492" (0 . 2))

I’m not sure there’s any way to solve this nicely in Guile. It would be
clearer if the match vector included the string as libc matched it, but
it’s still surprising that the match happens with a different string.

In Disarchive, I can rewrite the generator without regex. I’ll do that
and see what I can do about the “Gave up!” issue.

[1] It works on the converted-to-ASCII C string, which means that the
byte offsets and code point offsets are the same. Hence, it has nothing
to do.


-- Tim
B
B
Bengt Richter wrote on 3 May 2021 08:19
(name . Timothy Sample)(address . samplet@ngyro.com)
20210503061950.GA26660@LionPure
Hi Timothy, Ludo,

On +2021-05-03 00:02:09 -0400, Timothy Sample wrote:
Toggle quote (43 lines)
> Timothy Sample <samplet@ngyro.com> writes:
>
> > I’m still looking into this, but I wanted to quickly post this
> > reproducer for the Guile bug:
> >
> > (use-modules (ice-9 regex))
> > (define str
> > "\U101514\U103ab0\U0f6e6e\U02e278\U01d9eb\U10b996\U1089b5\uea15\U0fa074\U101e41\U02e330\u0177\u2492")
> > (match:substring (string-match "[0-8]+" str))
> >
> > This triggers the out-of-range error when run with “LC_ALL=C”.
>
> It turns out that all that’s needed is the last code point, which is
> “Number Eleven Full Stop”, or ‘?’. When Guile converts this to an ASCII
> C string using ‘u32_conv_from_encoding’, it becomes “11.”. The regex
> (“[0-8]+”) matches the “11” part with start index 0 and end index 2.
> The ‘fixup_multibyte_match’ function does nothing (it only matters when
> the locale encoding is multibyte) [1]. Guile then builds the match
> vector with the original string but keeps the ASCII offsets. In other
> words, it thinks the match substring goes from 0 to 2 in a single code
> point string:
>
> ,use (ice-9 regex)
> (string-match "11" "\u2492")
> => #("\u2492" (0 . 2))
>
> I’m not sure there’s any way to solve this nicely in Guile. It would be
> clearer if the match vector included the string as libc matched it, but
> it’s still surprising that the match happens with a different string.
>
> In Disarchive, I can rewrite the generator without regex. I’ll do that
> and see what I can do about the “Gave up!” issue.
>
> [1] It works on the converted-to-ASCII C string, which means that the
> byte offsets and code point offsets are the same. Hence, it has nothing
> to do.
>
>
> -- Tim
>

>
>
What happens with these?
(code ppoints in decimal)

8554 _?_ "ROMAN NUMERAL ELEVEN"
8570 _?_ "SMALL ROMAN NUMERAL ELEVEN"
9322 _?_ "CIRCLED NUMBER ELEVEN"
9342 _?_ "PARENTHESIZED NUMBER ELEVEN"
9362 _?_ "NUMBER ELEVEN FULL STOP"
9451 _?_ "NEGATIVE CIRCLED NUMBER ELEVEN"
13155 _?_ "IDEOGRAPHIC TELEGRAPH SYMBOL FOR HOUR ELEVEN"
13290 _?_ "IDEOGRAPHIC TELEGRAPH SYMBOL FOR DAY ELEVEN"

I would argue that none of these should be "decoded" into ascii polyglyphs
since they are atomic character glyphs. IMO It is over-eager transformation
to make them into ascii polyglyphs.

/Super/sub/-script placement metadata is another thing to consider --
"decode" to ascii art?? ;-)

Unicode characters representing mathematical values in
other languages are different. Those are subject to natural language
translation with locale-dependent semantics.

These might be candidates for that?:
(code points in decimal)

8544 _?_ "ROMAN NUMERAL ONE"
8545 _?_ "ROMAN NUMERAL TWO"
8546 _?_ "ROMAN NUMERAL THREE"
8547 _?_ "ROMAN NUMERAL FOUR"
8548 _?_ "ROMAN NUMERAL FIVE"
8549 _?_ "ROMAN NUMERAL SIX"
8550 _?_ "ROMAN NUMERAL SEVEN"
8551 _?_ "ROMAN NUMERAL EIGHT"
8552 _?_ "ROMAN NUMERAL NINE"
8553 _?_ "ROMAN NUMERAL TEN"
8554 _?_ "ROMAN NUMERAL ELEVEN"
8555 _?_ "ROMAN NUMERAL TWELVE"
8556 _?_ "ROMAN NUMERAL FIFTY"
8557 _?_ "ROMAN NUMERAL ONE HUNDRED"
8558 _?_ "ROMAN NUMERAL FIVE HUNDRED"
8559 _?_ "ROMAN NUMERAL ONE THOUSAND"
8560 _?_ "SMALL ROMAN NUMERAL ONE"
8561 _?_ "SMALL ROMAN NUMERAL TWO"
8562 _?_ "SMALL ROMAN NUMERAL THREE"
8563 _?_ "SMALL ROMAN NUMERAL FOUR"
8564 _?_ "SMALL ROMAN NUMERAL FIVE"
8565 _?_ "SMALL ROMAN NUMERAL SIX"
8566 _?_ "SMALL ROMAN NUMERAL SEVEN"
8567 _?_ "SMALL ROMAN NUMERAL EIGHT"
8568 _?_ "SMALL ROMAN NUMERAL NINE"
8569 _?_ "SMALL ROMAN NUMERAL TEN"
8570 _?_ "SMALL ROMAN NUMERAL ELEVEN"
8571 _?_ "SMALL ROMAN NUMERAL TWELVE"
8572 _?_ "SMALL ROMAN NUMERAL FIFTY"
8573 _?_ "SMALL ROMAN NUMERAL ONE HUNDRED"
8574 _?_ "SMALL ROMAN NUMERAL FIVE HUNDRED"
8575 _?_ "SMALL ROMAN NUMERAL ONE THOUSAND"
8576 _?_ "ROMAN NUMERAL ONE THOUSAND C D"
8577 _?_ "ROMAN NUMERAL FIVE THOUSAND"
8578 _?_ "ROMAN NUMERAL TEN THOUSAND"
8579 _?_ "ROMAN NUMERAL REVERSED ONE HUNDRED"
8581 _?_ "ROMAN NUMERAL SIX LATE FORM"
8582 _?_ "ROMAN NUMERAL FIFTY EARLY FORM"
8583 _?_ "ROMAN NUMERAL FIFTY THOUSAND"
8584 _?_ "ROMAN NUMERAL ONE HUNDRED THOUSAND"
12321 _?_ "HANGZHOU NUMERAL ONE"
12322 _?_ "HANGZHOU NUMERAL TWO"
12323 _?_ "HANGZHOU NUMERAL THREE"
12324 _?_ "HANGZHOU NUMERAL FOUR"
12325 _?_ "HANGZHOU NUMERAL FIVE"
12326 _?_ "HANGZHOU NUMERAL SIX"
12327 _?_ "HANGZHOU NUMERAL SEVEN"
12328 _?_ "HANGZHOU NUMERAL EIGHT"
12329 _?_ "HANGZHOU NUMERAL NINE"
12344 _?_ "HANGZHOU NUMERAL TEN"
12345 _?_ "HANGZHOU NUMERAL TWENTY"
12346 _?_ "HANGZHOU NUMERAL THIRTY"

Just my intuitive reaction, no academic creds to back it up ;)

--
Regards,
Bengt Richter
L
L
Ludovic Courtès wrote on 3 May 2021 22:03
(name . Timothy Sample)(address . samplet@ngyro.com)(address . 48114@debbugs.gnu.org)
874kfjwpn4.fsf@gnu.org
Hi!

Timothy Sample <samplet@ngyro.com> skribis:

Toggle quote (15 lines)
> Timothy Sample <samplet@ngyro.com> writes:
>
>> I’m still looking into this, but I wanted to quickly post this
>> reproducer for the Guile bug:
>>
>> (use-modules (ice-9 regex))
>> (define str
>> "\U101514\U103ab0\U0f6e6e\U02e278\U01d9eb\U10b996\U1089b5\uea15\U0fa074\U101e41\U02e330\u0177\u2492")
>> (match:substring (string-match "[0-8]+" str))
>>
>> This triggers the out-of-range error when run with “LC_ALL=C”.
>
> It turns out that all that’s needed is the last code point, which is
> “Number Eleven Full Stop”, or ‘?’.

Whaaat? “Number Eleven Full Stop”, I wonder how the Unicode folks came
up with that one. ? = ? + ?

Toggle quote (17 lines)
> When Guile converts this to an ASCII C string using
> ‘u32_conv_from_encoding’, it becomes “11.”. The regex (“[0-8]+”)
> matches the “11” part with start index 0 and end index 2. The
> ‘fixup_multibyte_match’ function does nothing (it only matters when
> the locale encoding is multibyte) [1]. Guile then builds the match
> vector with the original string but keeps the ASCII offsets. In other
> words, it thinks the match substring goes from 0 to 2 in a single code
> point string:
>
> ,use (ice-9 regex)
> (string-match "11" "\u2492")
> => #("\u2492" (0 . 2))
>
> I’m not sure there’s any way to solve this nicely in Guile. It would be
> clearer if the match vector included the string as libc matched it, but
> it’s still surprising that the match happens with a different string.

Yeah, I don’t think there’s much we can do. It’s a lot of fun anyway.

Thanks for investigating!

Ludo’.
L
L
Ludovic Courtès wrote on 13 May 2021 23:04
(name . Timothy Sample)(address . samplet@ngyro.com)(address . 48114@debbugs.gnu.org)
87lf8iqrad.fsf@gnu.org
Hi!

Timothy Sample <samplet@ngyro.com> skribis:

Toggle quote (3 lines)
> In Disarchive, I can rewrite the generator without regex. I’ll do that
> and see what I can do about the “Gave up!” issue.

Did you have a chance to look into it?

I’d like to make ‘guix’ and ‘guix-daemon’ depend on Disarchive, but not
before we can be sure its test suite passes.

Thanks,
Ludo’.
T
T
Timothy Sample wrote on 14 May 2021 05:06
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 48114-done@debbugs.gnu.org)
87sg2qko9s.fsf@ngyro.com
Heyo,

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (7 lines)
> Timothy Sample <samplet@ngyro.com> skribis:
>
>> In Disarchive, I can rewrite the generator without regex. I’ll do that
>> and see what I can do about the “Gave up!” issue.
>
> Did you have a chance to look into it?

I just pushed b9f0e78238e6186d28d738c7c5355a56557ce84f, which updates
Disarchive to 0.2.1, which has fixes for the test suite. The giving up
problem has not been solved outright, but it should be practically
impossible to trigger. (In fact, it probably *is* impossible to trigger
given how few PRNG states there are....)

Toggle quote (3 lines)
> I’d like to make ‘guix’ and ‘guix-daemon’ depend on Disarchive, but not
> before we can be sure its test suite passes.

Exciting!


-- Tim
Closed
L
L
Ludovic Courtès wrote on 14 May 2021 15:51
(name . Timothy Sample)(address . samplet@ngyro.com)(address . 48114-done@debbugs.gnu.org)
87o8ddmnjl.fsf@gnu.org
Hi Timothy,

Timothy Sample <samplet@ngyro.com> skribis:

Toggle quote (15 lines)
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Timothy Sample <samplet@ngyro.com> skribis:
>>
>>> In Disarchive, I can rewrite the generator without regex. I’ll do that
>>> and see what I can do about the “Gave up!” issue.
>>
>> Did you have a chance to look into it?
>
> I just pushed b9f0e78238e6186d28d738c7c5355a56557ce84f, which updates
> Disarchive to 0.2.1, which has fixes for the test suite. The giving up
> problem has not been solved outright, but it should be practically
> impossible to trigger. (In fact, it probably *is* impossible to trigger
> given how few PRNG states there are....)

Yay! Thanks for the quick reply!

I’ll have ‘guix’ depend on Disarchive and report back.

Ludo’.
Closed
?