Re: MPS: weak hash tables

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

>           (save-window-excursion
>             (let ((case-fold-search nil)
>                   (ert-batch-backtrace-right-margin nil)
>                   (ert-batch-backtrace-line-length nil)

This measn backtrace-line-limit is set to nil, meaning no limit. Default
is 5000.

  ert-batch-backtrace-line-length is a variable defined in ‘ert.el’.

  Its value is t

  Target length for lines in ERT batch backtraces.

  Even modest settings for ‘print-length’ and ‘print-level’ can
  produce extremely long lines in backtraces and lengthy delays in
  forming them.  This variable governs the target maximum line
  length by manipulating these two variables while printing stack
  traces.  Setting this variable to t will reuse the value of
  ‘backtrace-line-length’ while printing stack traces in ERT batch
  mode.  Any other value will be temporarily bound to
  ‘backtrace-line-length’ when producing stack traces in batch
  mode.


>                   (ert-batch-print-level 6)
>                   (ert-batch-print-length 11))
>               (ert-run-tests-batch
>                `(member ,failing-test-1)))))
>
> Run test failing test.
>
>         (let ((frame "ert-fail(((should (equal complex-list 1)) :form (equal ((:1 (:2 (:3 (:4 (:5 (:6 \"abc\"))))))) 1) :value nil :explanation (different-types ((:1 (:2 (:3 (:4 (:5 (:6 \"abc\"))))))) 1)))")
>               found-frame)
>
> This is what it should print with the given print-level and length.
>
>           (cl-loop for msg in (reverse messages)
>                    do
>                    (unless found-frame

We only have a few messages, but one gets really large

*** length 947
*** length 30
*** length 8184211
*** length 30
*** length 158
*** length 46
*** length 93
*** length 21
*** length 25
*** length 0

It's the backtrace string. In fact it gets larger with each preceding
test. Maybe it contains the value of a variable holding the results of
all preceding tests.

Constructing that large string gets slower and slower. Maybe an O(N^2)
somewhere or something like that.

I summary, I think this is an absoutely pathological case. I don't think
it's terribly interesting for igc.