From: Ihor Radchenko <yantar92@posteo.net>
To: Leo Butler <Leo.Butler@umanitoba.ca>
Cc: Org Mode Mailing List <emacs-orgmode@gnu.org>
Subject: Re: [PATCH] lisp/ob-octave.el, was [PATCH] rfc: using ert-deftest with side-effects
Date: Fri, 06 Jan 2023 15:11:09 +0000 [thread overview]
Message-ID: <87a62vitpu.fsf@localhost> (raw)
In-Reply-To: <87358ovj53.fsf@t14.reltub.ca>
Leo Butler <Leo.Butler@umanitoba.ca> writes:
>> Apparently, `sleep-for' 1 second was not enough, and I decided to remove
>> checking file size completely.
>
> Hello Ihor,
>
> Is there an environment variable that could be used to determine is the
> tests are being run on sourcehut? This would let us cut out that test on
> sourcehut, while still keeping it elsewhere.
No, we have nothing like this.
In theory, we can bind something in
https://git.sr.ht/~bzg/org-mode-tests/tree/master/item/.builds/init.el,
but I am not sure if it is a good idea.
The tests are failing not because something wrong in the CI machine, but
simply because CI machine is slow. You can get similar issue when
running Org tests on an actual proper old PC or simply when someone is
running CPU-heavy process alongside with Org tests.
So, I do not think that creating exceptions for CI is a good idea.
>> https://builds.sr.ht/~bzg/job/914954
>> 2 unexpected results:
>> FAILED ob-octave/graphics-file ((should-not (get-buffer "*Org-Babel
>> Error Output*")) :form (get-buffer "*Org-Babel Error Output*") :value
>> #<killed buffer>)
>> FAILED ob-octave/graphics-file-space ((should-not (get-buffer
>> "*Org-Babel Error Output*")) :form (get-buffer "*Org-Babel Error
>> Output*") :value #<killed buffer>)
>>
>> As you can see *Org-Babel Error Output* buffer does not exist when
>> running the test.
>>
>> Leo, could you please take a look?
>
> An earlier test is creating that *Org Babel Error Output* buffer. That
> is killed on the first test, before the test is actually run. But
> GET-BUFFER behaves in an undocumented way: it returns a non-nil value,
> #<killed buffer>. To remedy that, I have wrapped the calls in
> BUFFER-LIVE-P.
This is not undocumented. The killed buffers still exists as Elisp
objects:
28.10 Killing Buffers
=====================
“Killing a buffer” makes its name unknown to Emacs and makes the memory
space it occupied available for other use.
The buffer object for the buffer that has been killed remains in
existence as long as anything refers to it, but it is specially marked
so that you cannot make it current or display it. Killed buffers retain
their identity, however; if you kill two distinct buffers, they remain
distinct according to ‘eq’ although both are dead.
> See the attached patch.
Thanks!
Installed onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=41ebc2e40
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
next prev parent reply other threads:[~2023-01-06 15:11 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-07 17:03 [PATCH] rfc: using ert-deftest with side-effects Leo Butler
2022-11-08 7:40 ` Ihor Radchenko
2022-11-08 19:55 ` [PATCH] lisp/ob-octave.el, was " Leo Butler
2022-11-09 5:14 ` Ihor Radchenko
2022-11-09 20:33 ` Leo Butler
2022-11-14 1:56 ` Ihor Radchenko
2022-11-15 19:43 ` Leo Butler
2022-12-17 8:25 ` Ihor Radchenko
2022-12-17 10:06 ` Ihor Radchenko
2022-12-21 11:56 ` Ihor Radchenko
2022-12-22 13:32 ` Leo Butler
2022-12-27 14:45 ` Ihor Radchenko
2022-12-29 9:54 ` Ihor Radchenko
2023-01-02 8:42 ` Ihor Radchenko
2023-01-05 20:08 ` Leo Butler
2023-01-06 15:11 ` Ihor Radchenko [this message]
2023-01-07 3:08 ` Leo Butler
2023-01-10 20:30 ` Leo Butler
2023-01-11 11:15 ` Ihor Radchenko
2023-01-11 21:51 ` Leo Butler
2023-01-12 8:42 ` Ihor Radchenko
2023-01-13 18:00 ` Ihor Radchenko
2023-01-14 13:04 ` Leo Butler
2023-01-14 13:13 ` Ihor Radchenko
2023-01-14 15:16 ` Max Nikulin
2023-01-23 10:32 ` Ihor Radchenko
2023-01-24 18:08 ` Leo Butler
2023-01-07 12:48 ` Ihor Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a62vitpu.fsf@localhost \
--to=yantar92@posteo.net \
--cc=Leo.Butler@umanitoba.ca \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.