[Enter steps to reproduce:]
Atom: 1.40.1 x64
Electron: 3.1.10
OS: Mac OS X 10.14.6
Thrown From: Hydrogen package 2.12.0
Uncaught Error: ENOENT: no such file or directory, unlink '/Users/Chris/Library/Jupyter/runtime/kernel-5cab4ab8-5fab-4586-a9ee-1c89d98ddde7.json'
At fs.js:143
Error: ENOENT: no such file or directory, unlink '/Users/Chris/Library/Jupyter/runtime/kernel-5cab4ab8-5fab-4586-a9ee-1c89d98ddde7.json'
at Object.fs.unlinkSync (fs.js:1061:3)
at ZMQKernel.destroy (/packages/Hydrogen/lib/zmq-kernel.js:393:8)
at Kernel.destroy (/packages/Hydrogen/lib/kernel.js:435:20)
at /packages/Hydrogen/lib/main.js:300:14)
at Object.handleKernelCommand (/packages/Hydrogen/lib/main.js:310:4)
at SignalListView.signalListView.onConfirmed (/packages/Hydrogen/lib/services/consumed/status-bar/status-bar.js:59:14)
at Object.didConfirmSelection (/packages/Hydrogen/lib/services/consumed/status-bar/signal-list-view.js:40:36)
at SelectListView.confirmSelection (/packages/Hydrogen/node_modules/atom-select-list/src/select-list-view.js:400:20)
at SelectListView.didClickItem (/packages/Hydrogen/node_modules/atom-select-list/src/select-list-view.js:286:10)
at ListItemView.onclick (/packages/Hydrogen/node_modules/atom-select-list/src/select-list-view.js:221:31)
at ListItemView.didClick (/packages/Hydrogen/node_modules/atom-select-list/src/select-list-view.js:448:10)
-0:15.8.0 hydrogen:run (input.hidden-input)
-0:15.8.0 autocomplete-plus:cancel (atom-text-editor.editor.has-selection.is-focused)
-0:14.9.0 core:move-down (input.hidden-input)
-0:14.6.0 core:confirm (input.hidden-input)
-0:07.7.0 hydrogen:run (input.hidden-input)
-0:07.7.0 autocomplete-plus:cancel (atom-text-editor.editor.has-selection.is-focused)
-0:07.2.0 core:move-down (input.hidden-input)
-0:06.9.0 core:confirm (input.hidden-input)
Hydrogen 2.12.0
language-latex 1.2.0
language-markdown 0.37.0
latex 0.50.2
latex-completions 0.3.6
pdf-view 0.72.0
pen-paper-coffee-syntax 0.17.0
I am assuming this is very similar to you other issue. Can you tell us exactly what commands you used to shutdown and initialize the kernel
Hi, thanks for the fast reply.
to initialize the kernel, I press cmd-return, directly on the open script in atom, then select python 3 from the two options (python 2 or 3)
to shut it down, I press a small button which says "python 3 | idle", then select shut down kernel
By the way, I have the Global Kernel option enabled.
The same process used to work flawless before the latest update.
Unfortunately I am not familiar with kernels, so I will have to leave this for another dev
I am not an expert of kernels nor node.js. But IMHO it seems this error is solely about trying to delete a non-existing file (the connectionFile).
Currently /packages/Hydrogen/lib/zmq-kernel.js:393:393 always assumes the file's existence, which causes the error when it isn't the case. I guess it shall be safe to change /packages/Hydrogen/lib/zmq-kernel.js:393 to be the following to skip this particular error. As for the reason why the file doesn't exist, we can deal with it in another specific issue. Don't you think?
fs.unlink(this.connectionFile, (err) => {});
@aviatesk
I figured you are still debugging this, but I tried the following skip mentioned above:
I guess it shall be safe to change /packages/Hydrogen/lib/zmq-kernel.js:393 to be the following to skip this particular error
fs.unlink(this.connectionFile, (err) => {});
and got the error:
Atom: 1.40.1 x64
Electron: 3.1.10
OS: Mac OS X 10.14.6
Thrown From: Hydrogen package 2.12.0
Uncaught TypeError: Socket is closed
At /Users/jdragos/.atom/packages/Hydrogen/node_modules/zeromq/lib/index.js:734
TypeError: Socket is closed
at Socket.close (/packages/Hydrogen/node_modules/zeromq/lib/index.js:734:13)
at ZMQKernel.destroy (/packages/Hydrogen/lib/zmq-kernel.js:395:22)
at Kernel.destroy (/packages/Hydrogen/lib/kernel.js:435:20)
at /packages/Hydrogen/lib/main.js:300:14)
at Object.handleKernelCommand (/packages/Hydrogen/lib/main.js:310:4)
at SignalListView.signalListView.onConfirmed (/packages/Hydrogen/lib/services/consumed/status-bar/status-bar.js:59:14)
at Object.didConfirmSelection (/packages/Hydrogen/lib/services/consumed/status-bar/signal-list-view.js:40:36)
at SelectListView.confirmSelection (/packages/git-plus/node_modules/atom-select-list/src/select-list-view.js:400:20)
at SelectListView.didClickItem (/packages/git-plus/node_modules/atom-select-list/src/select-list-view.js:286:10)
at ListItemView.onclick (/packages/git-plus/node_modules/atom-select-list/src/select-list-view.js:221:31)
at ListItemView.didClick (/packages/git-plus/node_modules/atom-select-list/src/select-list-view.js:448:10)
-2:37.4.0 core:confirm (input.hidden-input)
2x -2:37.1.0 intentions:highlight (input.hidden-input)
-2:33.9.0 hydrogen:run-cell-and-move-down (input.hidden-input)
-2:33.9.0 autocomplete-plus:cancel (atom-text-editor.editor.emacs-plus.is-focused)
-2:33.5.0 core:move-down (input.hidden-input)
-2:33.4.0 core:confirm (input.hidden-input)
-1:23.9.0 core:copy (atom-notification.fatal.icon.icon-bug.native-key-bindings.has-detail.has-close.has-stack)
-0:43.5.0 core:paste (input.hidden-input)
-0:42.1.0 core:undo (input.hidden-input)
2x -0:41.7.0 find-and-replace:find-next (input.hidden-input)
-0:40.8.0 editor:consolidate-selections (input.hidden-input)
-0:40.8.0 go-to-line:toggle (input.hidden-input)
-0:40.6.0 editor:consolidate-selections (input.hidden-input)
-0:40.6.0 go-to-line:toggle (input.hidden-input)
-0:40.1.0 editor:consolidate-selections (input.hidden-input)
-0:40.1.0 go-to-line:toggle (input.hidden-input)
advanced-open-file 0.16.8
atom-transpose 0.3.5
busy-signal 2.0.1
emacs-plus 0.12.0
git-plus 8.7.1
Hydrogen 2.12.0
hydrogen-python 0.0.8
hydrogen-xdbg 0.0.4
intentions 1.1.5
linter 2.3.1
linter-flake8 2.4.0
linter-ui-default 1.8.0
minimap 4.29.9
quick-query 1.1.1
select-rectangle 1.0.2
split-diff 1.6.0
Sublime-Style-Column-Selection 1.7.5
I have taken another look at this issue today. Apparently it isn't much about kernel. It's about the signalListView in the status-bar.js. The signalListView is cached after the initialisation, which makes it always pointing to the first kernel. After I delete the code of caching, the bug disappears. Therefore I created a PR (#1781). Again, I am not a frontend developer and it's indeed my first time doing debug in an Javascript project. Please let me know if there is better solution or understanding of the issue.
Thanks for tackling this issue.
It's about the signalListView in the status-bar.js.
Sounds reasonable. Then we may want to revert changes around handleKernelCommand and the related code made in #1706 and #1712.
The changes were made to avoid relying on globals I guess, but we are still passing the global store anyway, and I'm really okay to discard the refactors of that part imho (iirc there was no bug with the previous implementation)
Jh-wu thank you for looking into it. You made this process so much easier. I think we are just going to revert some changes made a while back which had no bug.
Hi @wadethestealth and @aviatesk, thanks for the quick reply. I am not very sure which version you are referring to. But it seems from the history that the issue should be there since from 16 July when status-bar.js was created. So I guess you have to revert the entire changes of the serives/consumers thing. IMHO, this particular issue is a small one, it doesn't sound necessary to apply a big change just for it. If you don't like the idea of renew SignalListView every time. I think we can change the code as follows:
let signalListView = this.signalListView;
if (!signalListView) {
signalListView = new SignalListView(kernel);
this.signalListView = signalListView;
}else{
signalListView.kernel = kernel
}
signalListView.onConfirmed = (kernelCommand: { command: string }) =>
this.handleKernelCommand(kernelCommand, { kernel, markers });
So I guess you have to revert the entire changes of the serives/consumers thing. IMHO, this particular issue is a small one, it doesn't sound necessary to apply a big change just for it.
Umm, the refactors done in #1706 were made to organise our service APIs more, but this bug is not strongly related to the refactor since the changes in handlerKernelCommand was kind of incidentally introduced. (I guess @wadethestealth made the changes additionally when moving the code)
IMHO I don't like the current implemetation, since passing the part of global store sounds weird and using global store in SignalListView explicitly would more straightforward (and would work more robust in this case I guess), but atst I don't feel like reverting back the entire refactors done in #1706.
So in conclusion, I want to modify the code _only around this bug_ by reverting back to the implementation before the PR, while keeping the current file structures. (and so it won't be such a big refactoring)
I'm welcome to review a PR in this direction, and how about crafting a PR in this direction, @jh-wu ?
I don't like the current implemetation, since passing the part of global store sounds weird and using global store in SignalListView explicitly would more straightforward (and would work more robust in this case I guess), but atst I don't feel like reverting back the entire refactors done in #1706.
I like this idea. Actually I had thought about this direction before, but as I was pursuing minimal change as possible, I didn't go further. I can check and maybe propose another PR for this.
Okay, I have made some change in #1781
For this issue, please follow #1781
Thank you everyone for your patience, I have just released a patch 2.12.1 where this issue should be addressed. However, if you still get problems, please open a new issue. Thanks 馃槂