Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1.33 -> 1.34 update causes hangs in GNU Emacs >=30.0.50 (git) #243

Closed
xgqt opened this issue Mar 4, 2024 · 8 comments
Closed

1.33 -> 1.34 update causes hangs in GNU Emacs >=30.0.50 (git) #243

xgqt opened this issue Mar 4, 2024 · 8 comments

Comments

@xgqt
Copy link

xgqt commented Mar 4, 2024

Hello!

I was investigating recent failures on the Gentoo CI server after buttercup update from 1.33 -> 1.34.

For reference:

On my machine's Emacs instead of having the above failures, buttercup hangs indefinitely.

Please ask for more info becasue I am not sure what information should I provide.

@snogge
Copy link
Collaborator

snogge commented Mar 5, 2024

@xgqt
Copy link
Author

xgqt commented Mar 5, 2024

@snogge

Thanks a lot! I did not know that lack of lexical-bindign would manifest like that.

Would this always be the case with the error (cl-assertion-failed ((eq closure (car-safe oclosure)) nil))?

Btw, a qucik look at webrequest.el and circe shows they do not have lexical-binding at all, and circe's case it is only in some files.

Are you plannign to add a workaround for this for dynamic-binding?
If not, should this issue be clsoed?

@snogge
Copy link
Collaborator

snogge commented Mar 5, 2024

And https://bugs.gentoo.org/926083 should be fixed by emacs-circe/circe#416

@snogge
Copy link
Collaborator

snogge commented Mar 5, 2024

Thanks a lot! I did not know that lack of lexical-binding would manifest like that.

No, that was new for the Oclosures introduced in buttercup 1.34.
Note that buttercup has been documented as requiring lexical binding for test files for a long time https://github.com/jorgenschaefer/emacs-buttercup/blob/master/docs/writing-tests.md#its-just-functions , but it was only actually required if you used certain features. Now it is really mandatory.

Would this always be the case with the error (cl-assertion-failed ((eq closure (car-safe oclosure)) nil))?

The error will happen on all GNU Emacs 29.1 or newer, but it will look slightly different depending on the Emacs version. As far as I can tell this is an assert from the Emacs implementation of Oclosures, not in buttercup itself.

Btw, a quick look at webrequest.el and circe shows they do not have lexical-binding at all, and circe's case it is only in some files.

I've fixed the tests on circe in emacs-circe/circe#416 , I was not aware of the problems in webrequest.el, but as I said, it is only the test files that have to use lexical-binding: t. Also, see #244 .

Are you planning to add a workaround for this for dynamic-binding? If not, should this issue be closed?

There is no way to make buttercup work without lexical binding. I will try to make it more obvious what the problem actually is, but I will track that work from #244. So feel free to close this bug if you are satisfied.

@xgqt
Copy link
Author

xgqt commented Mar 5, 2024

@snogge

I will try to make it more obvious what the problem actually is, but I will track that work from #244.

Thanks, I'm looking forward to this.

Will close this one.

@xgqt xgqt closed this as completed Mar 5, 2024
@xgqt
Copy link
Author

xgqt commented Mar 5, 2024

Btw, a qucik look at webrequest.el and circe shows they do not have lexical-binding at all, and circe's case it is only in some files.

s/webrequest/webpaste/

for ref:
https://github.com/etu/webpaste.el/tree/main/tests

@snogge
Copy link
Collaborator

snogge commented Mar 5, 2024

Thanks, I had a really hard time finding webrequest.el :)

@snogge
Copy link
Collaborator

snogge commented Mar 5, 2024

Fix for webpaste.el etu/webpaste.el#58 . All workflows are broken, so I have no idea about the test status.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants