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

[Bug] Extremely slow after initializing kernel #100

Open
Bigbadboybob opened this issue Jul 16, 2023 · 3 comments
Open

[Bug] Extremely slow after initializing kernel #100

Bigbadboybob opened this issue Jul 16, 2023 · 3 comments
Labels
bug Something isn't working

Comments

@Bigbadboybob
Copy link

Bigbadboybob commented Jul 16, 2023

Describe the bug
Everything functionally works technically but when I run MagmaInit python3 vim becomes extremely slow, like there is a half second delay between any vim shortcut and the action. Additionally when I evaluate a line the out put just says Out[...]: * On Hold, even if it's just a print statement.

To Reproduce
Steps to reproduce the behavior:

  1. Install plugin using lazy.nvim
  2. Go to any file (*.py or any other type of file) and run :MagmaInit python3

Expected behavior
Vim should be reasonably responsive and magma outputs should show print statements.

Desktop (please complete the following information):

  • OS: Ubuntu 22.04
  • Version NVIM v0.8.3
@Bigbadboybob Bigbadboybob added the bug Something isn't working label Jul 16, 2023
@Bigbadboybob
Copy link
Author

I installed ipython and ipykernel and added another jupyter kernel to my conda environment but now the original kernel works fine. So I guess installing ipython and ipykernel fixed it.

@dccsillag
Copy link
Owner

Sounds like there is some bad busy loop (probably in the kernel status tracking code?), which should really be fixed.

@dccsillag
Copy link
Owner

dccsillag commented Jul 16, 2023

This is probably at blame:

Which is odd, since get_iopub_msg should be sleeping iirc. Unless it's consistently giving a "weird" reply, falling into the condition in

if "content" not in message or "msg_type" not in message:
. So maybe we should add some logic before that continue to avoid a busy loop.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants