Test succeeding only from edebug

Test succeeding only from edebug

[Andreas Röhler]

Hi,

have a test succeeding when a core-function, ‘ar-thing-in-thing’, is 
instrumented by edebug.
However. same tests fails when running normally.

See failure at

https://app.circleci.com/pipelines/gh/andreas-roehler/thing-at-point-utils/82/workflows/e97906a0-d949-4f96-84be-f862265518f6/jobs/82

Test in question is ‘ar-trim-braced-in-region-test’, from

https://github.com/andreas-roehler/thing-at-point-utils/blob/master/test/ar-trim-tests.el

‘ar-thing-in-thing’ resides at

https://github.com/andreas-roehler/thing-at-point-utils/blob/master/ar-thingatpt-basic-definitions.el

Any idea?

Thanks,
Andreas

Re: Test succeeding only from edebug

[Michael Heerdegen via Users list for the GNU Emacs text editor]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> Hi,
>
> have a test succeeding when a core-function, ‘ar-thing-in-thing’, is
> instrumented by edebug.
> However. same tests fails when running normally.

I'm a bit confused: is it a core function or a function defined by
yourself?

> See failure at
>
> https://app.circleci.com/pipelines/gh/andreas-roehler/thing-at-point-utils/82/workflows/e97906a0-d949-4f96-84be-f862265518f6/jobs/82
>
> Test in question is ‘ar-trim-braced-in-region-test’, from
>
> https://github.com/andreas-roehler/thing-at-point-utils/blob/master/test/ar-trim-tests.el
>
> ‘ar-thing-in-thing’ resides at
>
> https://github.com/andreas-roehler/thing-at-point-utils/blob/master/ar-thingatpt-basic-definitions.el

Do you have a backtrace?  Does the test case work using interpreted
code?  Or fails compiled and interpreted?

I guess I could find out all of that by myself but I wanted to get at
least an idea where to look at before consulting your linked sources.


Michael.

Re: Test succeeding only from edebug

[Andreas Röhler]

Am 05.08.24 um 17:32 schrieb Michael Heerdegen via Users list for the 
GNU Emacs text editor:
> Andreas Röhler<andreas.roehler@easy-emacs.de>  writes:
>
>> Hi,
>>
>> have a test succeeding when a core-function, ‘ar-thing-in-thing’, is
>> instrumented by edebug.
>> However. same tests fails when running normally.
> I'm a bit confused: is it a core function or a function defined by
> yourself?

Defined by myself.


>> See failure at
>>
>> https://app.circleci.com/pipelines/gh/andreas-roehler/thing-at-point-utils/82/workflows/e97906a0-d949-4f96-84be-f862265518f6/jobs/82
>>
>> Test in question is ‘ar-trim-braced-in-region-test’, from
>>
>> https://github.com/andreas-roehler/thing-at-point-utils/blob/master/test/ar-trim-tests.el
>>
>> ‘ar-thing-in-thing’ resides at
>>
>> https://github.com/andreas-roehler/thing-at-point-utils/blob/master/ar-thingatpt-basic-definitions.el
> Do you have a backtrace?

Not really. If interactively called, it fails like that:

Selector: ar-trim-braced-in-region-test
Passed:  0
Failed:  1 (1 unexpected)
Skipped: 0
Total:   1/1

Started at:   2024-08-05 17:51:53+0200
Finished.
Finished at:  2024-08-05 17:51:54+0200

F

F ar-trim-braced-in-region-test
     (ert-test-failed
      ((should (eq (char-before) 102)) :form (eq 125 102) :value nil))

See also remote log as linked above.

However, it succeeds like that:


Edebug: ar-thing-in-thing
ar-thing-in-thing
  [2 times]
Result: region

Result: (1 . 21)
  [6 times]
Result: (1 . 21)

Result: 1 (#o1, #x1, ?\C-a)

Result: nil
  [3 times]
Result: (1 . 21)

Result: 1 (#o1, #x1, ?\C-a)

Result: 1 (#o1, #x1, ?\C-a)

Result: 1 (#o1, #x1, ?\C-a)
  [5 times]
Result: (1 . 21)

Result: 21 (#o25, #x15, ?\C-u)

Result: t
  [2 times]
Result: (1 . 21)

Result: 21 (#o25, #x15, ?\C-u)

Result: 21 (#o25, #x15, ?\C-u)

Result: #<marker at 21 in  *temp*-56307>
  [4 times]
Result: 1 (#o1, #x1, ?\C-a)

Result: #<marker at 21 in  *temp*-56307>

Result: nil
  [2 times]
Result: 1 (#o1, #x1, ?\C-a)

Result: 1 (#o1, #x1, ?\C-a)
  [3 times]
Result: nil

Result: nil

Result: nil
  [5 times]
Result: nil

Result: t
  [3 times]
Result: nil

Result: t

Result: t
  [3 times]
Result: 1 (#o1, #x1, ?\C-a)

Result: 1 (#o1, #x1, ?\C-a)
  [3 times]
Result: ar-th-trim

Result: braced

Result: t
  [2 times]
Result: t

Result: t

Result: t
  [4 times]
Result: nil
  [2 times]
Result: braced

Result: nil

Result: nil
  [4 times]
Result: braced

Result: 7 (#o7, #x7, ?\C-g)

Result: 7 (#o7, #x7, ?\C-g)

Result: 7 (#o7, #x7, ?\C-g)

Result: 7 (#o7, #x7, ?\C-g)
  [4 times]
Result: nil

Result: t
  [3 times]
Result: t

Result: nil
  [2 times]
Result: 1 (#o1, #x1, ?\C-a)
  [2 times]
Result: 7 (#o7, #x7, ?\C-g)

Result: t

Result: t
  [3 times]
Result: 7 (#o7, #x7, ?\C-g)

Result: 7 (#o7, #x7, ?\C-g)
  [3 times]
Result: ar-th-trim

Result: braced

Result: t
  [2 times]
Result: t

Result: t

Result: t
  [4 times]
Result: nil
  [2 times]
Result: braced

Result: nil

Result: nil
  [4 times]
Result: braced

Result: 12 (#o14, #xc, ?\C-l)

Result: 12 (#o14, #xc, ?\C-l)

Result: 12 (#o14, #xc, ?\C-l)

Result: 12 (#o14, #xc, ?\C-l)
  [4 times]
Result: nil

Result: t
  [3 times]
Result: t

Result: nil
  [2 times]
Result: 7 (#o7, #x7, ?\C-g)
  [2 times]
Result: 12 (#o14, #xc, ?\C-l)

Result: t

Result: t
  [3 times]
Result: 12 (#o14, #xc, ?\C-l)

Result: 12 (#o14, #xc, ?\C-l)
  [3 times]
Result: ar-th-trim

Result: braced

Result: t
  [2 times]
Result: t

Result: t

Result: t
  [4 times]
Result: nil
  [2 times]
Result: braced

Result: nil

Result: nil
  [4 times]
Result: braced

Result: 15 (#o17, #xf, ?\C-o)

Result: 15 (#o17, #xf, ?\C-o)

Result: 15 (#o17, #xf, ?\C-o)

Result: 15 (#o17, #xf, ?\C-o)
  [4 times]
Result: t

Result: nil

Result: nil

Result: nil

Result: nil

Result: nil

Result: nil

Ran 1 tests, 1 results were as expected

---

Selector: ar-trim-braced-in-region-test
Passed:  1
Failed:  0
Skipped: 0
Total:   1/1

Started at:   2024-08-05 17:55:11+0200
Finished.
Finished at:  2024-08-05 17:55:31+0200
---

> Does the test case work using interpreted
> code?

Yes.

Here ist the test, which should remove all braces in buffer:

(ert-deftest ar-trim-braced-in-region-test ()
   (ar-test-with-elisp-buffer-point-min
       "{asdf} {asdf} {asdf}"
       (goto-char (point-min))
       (set-mark (point))
     (end-of-line)
     (ar-trim-braced-in-region-atpt)
     (should (eq (char-before) ?f))))

>    Or fails compiled and interpreted?

Usually don't compile my stuff.

A caveat: thing-at-point-utils loads a large bunch of commands, sorry 
for that inconvenience.

Thanks for your care

>
> I guess I could find out all of that by myself but I wanted to get at
> least an idea where to look at before consulting your linked sources.
>
>
> Michael.
>
>

Re: Test succeeding only from edebug

[Michael Heerdegen via Users list for the GNU Emacs text editor]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> Here ist the test, which should remove all braces in buffer:
>
> (ert-deftest ar-trim-braced-in-region-test ()
>   (ar-test-with-elisp-buffer-point-min
>       "{asdf} {asdf} {asdf}"
>       (goto-char (point-min))
>       (set-mark (point))
>     (end-of-line)
>     (ar-trim-braced-in-region-atpt)
>     (should (eq (char-before) ?f))))
>
> >    Or fails compiled and interpreted?
>
> Usually don't compile my stuff.

Ah ok...so there is no error, just the test fails.

In my experience it is so that when something works correctly when
edebugged but not when run normally, very often the code assumes a state
that is only reached after a (or multiple) redisplay operations have
been performed.  When edebugging Emacs gets idle in situations when it
is normally not (each time edebug stops).

I'm not sure which part of your code could rely on such an assumption,
I'm too tired atm too study all details.  Could be font-locking that has
not yet been performed - if your test makes use of font-lock features.

If adding an explicit (redisplay) call at the end of the buffer setup
in the definition of `ar-test-with-elisp-buffer-point-min' or before the
`should' call helps then this would be it.  In case of font-lock you
would then want to call (font-lock-ensure) to force font-locking
explicitly before Emacs gets idle.

Please tell me if that helps to make any progress - else I try to have
an even closer look tomorrow.


Grüße,

Michael.

Re: Test succeeding only from edebug

[Andreas Röhler]

Am 06.08.24 um 03:49 schrieb Michael Heerdegen via Users list for the 
GNU Emacs text editor:
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>
>> Here ist the test, which should remove all braces in buffer:
>>
>> (ert-deftest ar-trim-braced-in-region-test ()
>>    (ar-test-with-elisp-buffer-point-min
>>        "{asdf} {asdf} {asdf}"
>>        (goto-char (point-min))
>>        (set-mark (point))
>>      (end-of-line)
>>      (ar-trim-braced-in-region-atpt)
>>      (should (eq (char-before) ?f))))
>>
>>>     Or fails compiled and interpreted?
>> Usually don't compile my stuff.
> Ah ok...so there is no error, just the test fails.
>
> In my experience it is so that when something works correctly when
> edebugged but not when run normally, very often the code assumes a state
> that is only reached after a (or multiple) redisplay operations have
> been performed.  When edebugging Emacs gets idle in situations when it
> is normally not (each time edebug stops).
>
> I'm not sure which part of your code could rely on such an assumption,
> I'm too tired atm too study all details.  Could be font-locking that has
> not yet been performed - if your test makes use of font-lock features.
>
> If adding an explicit (redisplay) call at the end of the buffer setup
> in the definition of `ar-test-with-elisp-buffer-point-min' or before the
> `should' call helps then this would be it.  In case of font-lock you
> would then want to call (font-lock-ensure) to force font-locking
> explicitly before Emacs gets idle.
Yes, however, not at stake here.
> Please tell me if that helps to make any progress - else I try to have
> an even closer look tomorrow.
>
>
> Grüße,
>
> Michael.
>

putting a

(sit-for 0.5)

into ar-thing-in-thing seems to solve it.

Thanks again,

Andreas

Re: Test succeeding only from edebug

[Michael Heerdegen via Users list for the GNU Emacs text editor]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> putting a
>
> (sit-for 0.5)
>
> into ar-thing-in-thing seems to solve it.

> Thanks again,
>
> Andreas

Ok, great.

Would not be wrong to find out what exactly happened, though.  Such
things tend to come back right after the moment you have forgotten about
it, and then you start from zero.


Michael.

Re: Test succeeding only from edebug

[Andreas Röhler]

Am 06.08.24 um 16:53 schrieb Michael Heerdegen via Users list for the 
GNU Emacs text editor:
> Would not be wrong to find out what exactly happened, though.  Such
> things tend to come back right after the moment you have forgotten about
> it, and then you start from zero.
>
>
> Michael.
Can't agree more. Had a look again at ar-thing-in-thing - and could drop 
the "sit-for".
>