* Test succeeding only from edebug
@ 2024-08-05 6:41 Andreas Röhler
2024-08-05 15:32 ` Michael Heerdegen via Users list for the GNU Emacs text editor
0 siblings, 1 reply; 7+ messages in thread
From: Andreas Röhler @ 2024-08-05 6:41 UTC (permalink / raw)
To: help-gnu-emacs@gnu.org
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Test succeeding only from edebug
2024-08-05 6:41 Test succeeding only from edebug Andreas Röhler
@ 2024-08-05 15:32 ` Michael Heerdegen via Users list for the GNU Emacs text editor
2024-08-05 16:06 ` Andreas Röhler
0 siblings, 1 reply; 7+ messages in thread
From: Michael Heerdegen via Users list for the GNU Emacs text editor @ 2024-08-05 15:32 UTC (permalink / raw)
To: help-gnu-emacs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Test succeeding only from edebug
2024-08-05 15:32 ` Michael Heerdegen via Users list for the GNU Emacs text editor
@ 2024-08-05 16:06 ` Andreas Röhler
2024-08-06 1:49 ` Michael Heerdegen via Users list for the GNU Emacs text editor
0 siblings, 1 reply; 7+ messages in thread
From: Andreas Röhler @ 2024-08-05 16:06 UTC (permalink / raw)
To: help-gnu-emacs
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.
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Test succeeding only from edebug
2024-08-05 16:06 ` Andreas Röhler
@ 2024-08-06 1:49 ` Michael Heerdegen via Users list for the GNU Emacs text editor
2024-08-06 7:16 ` Andreas Röhler
0 siblings, 1 reply; 7+ messages in thread
From: Michael Heerdegen via Users list for the GNU Emacs text editor @ 2024-08-06 1:49 UTC (permalink / raw)
To: help-gnu-emacs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Test succeeding only from edebug
2024-08-06 1:49 ` Michael Heerdegen via Users list for the GNU Emacs text editor
@ 2024-08-06 7:16 ` Andreas Röhler
2024-08-06 14:53 ` Michael Heerdegen via Users list for the GNU Emacs text editor
0 siblings, 1 reply; 7+ messages in thread
From: Andreas Röhler @ 2024-08-06 7:16 UTC (permalink / raw)
To: help-gnu-emacs
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Test succeeding only from edebug
2024-08-06 7:16 ` Andreas Röhler
@ 2024-08-06 14:53 ` Michael Heerdegen via Users list for the GNU Emacs text editor
2024-08-06 18:21 ` Andreas Röhler
0 siblings, 1 reply; 7+ messages in thread
From: Michael Heerdegen via Users list for the GNU Emacs text editor @ 2024-08-06 14:53 UTC (permalink / raw)
To: help-gnu-emacs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Test succeeding only from edebug
2024-08-06 14:53 ` Michael Heerdegen via Users list for the GNU Emacs text editor
@ 2024-08-06 18:21 ` Andreas Röhler
0 siblings, 0 replies; 7+ messages in thread
From: Andreas Röhler @ 2024-08-06 18:21 UTC (permalink / raw)
To: help-gnu-emacs
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".
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-08-06 18:21 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-08-05 6:41 Test succeeding only from edebug Andreas Röhler
2024-08-05 15:32 ` Michael Heerdegen via Users list for the GNU Emacs text editor
2024-08-05 16:06 ` Andreas Röhler
2024-08-06 1:49 ` Michael Heerdegen via Users list for the GNU Emacs text editor
2024-08-06 7:16 ` Andreas Röhler
2024-08-06 14:53 ` Michael Heerdegen via Users list for the GNU Emacs text editor
2024-08-06 18:21 ` Andreas Röhler
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).