Re: MPS: weak hash tables

[Gerd Möllmann]

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

> Pip Cet <pipcet@protonmail.com> writes:
>
>>> The big
>>> difference to the non-MPS case is that struct interval is subject to GC
>>> at all, they are malloc'd without igc. I didn't see another way to
>>> handle their plist otherwise. Making them malloc'd roots would have
>>> meant too many roots for my taste. I have currently ca. 20.000 live
>>> intervals for example, after GC.
>>
>> Does there have to be a big difference at all,
>
> The only thing i can think of is what Helmut already suspected, namely
> barriers. OTOH, it's not really noticeable in other cases, at least here
> on macOS. In any case, I wouldn't expect anything remotely that big.
> After all, it's not like a barrier is hit, the client runs a bit, and
> the barrier goes up again.
>
>> or is it possible the test is broken on vanilla Emacs, and it just so
>> happens that GC happens at the right time and hides that bug?
>
> ERT is a dark chapter for me. Digged through it once for the debugger
> handling and giving the right backtraces in condition-case, and didn't
> like it :-). I'd say everything is possible.
>
>> The attached patch to Emacs master makes
>>
>> make -C test lisp/emacs-lisp/ert-tests
>>
>> run out of memory for me (again, on master, nothing special). I don't
>> think it should: all it does is modify the test that runs before.
>>
>> So is it possible this isn't all that MPS-specific?
>
> I have to admit I don't understand how that has the effect it has. Can
> you see where it gets stuck?

Maybe it helps when I describe how I understand the test, so that others
can add something or correct me.

  (ert-deftest ert-test-run-tests-batch-expensive ()
    :tags (if (getenv "EMACS_EMBA_CI") '(:unstable))

Let's start with the purpose which is not apparent. AFAIU, this tests if
ert-batch-print-level and ert-batch-print-length work. Which is already
obvious from the test name, but I looked at the git history instead.

    (let* ((complex-list '((:1 (:2 (:3 (:4 (:5 (:6 "abc"))))))))
           (failing-test-1
            (make-ert-test :name 'failing-test-1
                           :body (lambda () (should (equal complex-list
           1))))))

Anove, we have a test that always fails. When it does it prints
something, and apparently what it prints depends on the ert-batch-xy
options.

      (let ((ert-debug-on-error nil)
            messages)
        (cl-letf* (((symbol-function 'message)
                    (lambda (format-string &rest args)
                      (push (apply #'format format-string args)
            messages))))

Setting the symbol function lets us catch what gets printed for the
failing test.

          (save-window-excursion
            (let ((case-fold-search nil)
                  (ert-batch-backtrace-right-margin nil)
                  (ert-batch-backtrace-line-length nil)
                  (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

Someone didn't know while or until. :-)

                     (setq found-frame (cl-search frame msg :test
                   'equal))))

Check that what we expect was printed.

          (should found-frame)))))

🤷