GNU bug report logs - #51037
[PATCH] Make `print-level` & `print-length` customizable in ERT batch tests

Previous Next

Full log

Message #132 received at 51037 <at> debbugs.gnu.org (full text, mbox):

From: Michael <sp1ff <at> pobox.com>
To: Filipp Gunbin <fgunbin <at> fastmail.fm>
Cc: gazally <at> runbox.com, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Eli Zaretskii <eliz <at> gnu.org>, 51037 <at> debbugs.gnu.org
Subject: Re: bug#51037: [PATCH] Make `print-level` & `print-length`
 customizable in ERT batch tests
Date: Mon, 22 Nov 2021 06:07:33 -0800

Filipp Gunbin <fgunbin <at> fastmail.fm> writes:

> On 20/11/2021 08:49 -0800, Michael wrote:
>
>>> On 19/11/2021 07:24 -0800, Michael wrote:
>>>
>>>> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>>>>
>>>>> Filipp Gunbin <fgunbin <at> fastmail.fm> writes:
>>>>>
>>>>>> The docstring for backtrace-line-length says: "If set to 
>>>>>> nil
>>>>>> or
>>>>>> zero,
>>>>>> backtrace mode will not abbreviate the forms it prints." 
>>>>>> So
>>>>>> the
>>>>>> above
>>>>>> sentence, which I removed, was indeed not true?  (a quick
>>>>>> look over
>>>>>> its usages confirmed that to me, but I'd like someone else 
>>>>>> to
>>>>>> check)
>>>>>
>>>>> I think the intention is that a nil value of
>>>>> backtrace-line-length
>>>>> shouldn't limit the lengths -- but I haven't tested it.
>>>>> Doesn't it
>>>>> work?
>>>>
>>>> Yes, I'm a bit lost, Filipp... what is your concern? And I
>>>> thought I *had* tested that.
>>>
>>> That the docstring contained a sentence which is not true.  A
>>> minor
>>> issue, of course.  I give examples here:
>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51037#117
>>>
>>> (there was also fix of interactive spec of
>>> `ert-run-tests-interactively',
>>> but that's obvious I think)
>>>
>> Hey Filipp,
>>
>> Note that _is_ true, as far as I know, and was intended to be
>> true before my patch, and I verified that it became true with 
>> my
>> patch :) Can you provide a test case that demonstrates it to be
>> not true?
>
> Yes, here 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51037#117, as I
> wrote above..

Oh.... oh, my-- you are on to something here, Filipp. My
apologies for not seeing it sooner. The problem lies in:

   (defun cl-print-to-string-with-limit (print-function value 
   limit)
     ...
     (setq limit (and (natnump limit)
                      (not (zerop limit))
                      limit))
     ;; Since this is used by the debugger when stack space may 
     be
     ;; limited, if you increase print-level here, add more depth 
     in
     ;; call_debugger (bug#31919).
     (let* ((print-length (when limit (min limit 50)))
            (print-level (when limit (min 8 (truncate (log 
            limit)))))


backtrace uses this function to print each frame, and as you can
see, if called with `limit' set to nil, `print-le{vel,ength}`
will *not* keep their current values, they will *also* be set to
`nil`.

So, we could do either of:

   1. As Filipp suggests, just change the contract for
   `ert-batch-backtrace-line-length' to: if set to nil, you get
   full stack traces, period.

   2. change `cl-print-to-string-with-limit' to respect the
   existing values of `print-length' & `print-level' when
   `limit' is nil. Note that the only caller (in Emacs) of this
   function is the backtrace package.

I vote for option 2. What say you all?

-- 
Michael <sp1ff <at> pobox.com>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.