While working in an ipython notebook, eventually I had to Ctrl+C as the kernel seemed to be halted.
The console gave me a message like:
[NotebookApp] Kernel shutdown: 5faa86bf-........f6
[NotebookApp] Kernel shutdown: 71........22
[NotebookApp] ....
(I had three notebooks running)
But something went wrong and my notebook file.ipynb is empty (actually only the one I was actively using).
Is there a way to recover that file before it was deleted? Some place where automatically-saved o manually-saved versions are stored?
(Running python 2.7 (Anaconda) in Windows 7)
If none of the above helped, I found a workaround to recover most of the changes I did since the last checkout - by simply calling this command in your notebook:
%history -g
If you want your IPython history in a plain-text file, you can export it yourself.
You can also do it for a specific filename:
%history -g -f filename
What does -g do? – Without -g it exports the history for the current session.
With -g it exports history for all sessions.
You can check in .ipynb_checkpoints/ in the folder where your notebook was for recent enough version of IPython.
There is a great writeup about different recovery options from "Jupyter Disasters" at [1].
I want to quote one technique from there, namely opening $HOME/.ipython/profile_default/history.sqlite in the sqlite tool of your choice (e.g. sqlitebrowser) and digging around in there. This can be an option if there is no usable checkpoint file (as discussed in other answers).
[1] https://medium.com/flatiron-engineering/recovering-from-a-jupyter-disaster-27401677aeeb
Related
I have vsc version 1.63.2. I'm getting the following notification:
"File changes watcher stopped unexpectedly. A reload of the window may enable the watcher again unless the workspace cannot be watched for file changes."
When I click the reload button, the issue is temporarily fixed and Source Control shows changes to my files. Git in CLI is working fine; git log --raw shows changes to my files correctly. I've tested brand new and old repositories and workspaces. The problem occurs in all of them. Any help troubleshooting this is greatly appreciated!
I just ran into this issue today and found my solution by viewing the "Window" logs using the "Developer: Open Log File..." command from the Command Palette.
In my case, the problem was that I had added a folder to my workspace that I had since deleted on the file system. The log in question looked something like:
... [error] [File Watcher (parcel)] Unexpected error: Invalid handle (EUNKNOWN) (path: \path\that\no\longer\exists)
... [error] [File Watcher (parcel)] restarting watcher after error: Invalid handle
Hopefully viewing this log helps you find out what's breaking in your specific case.
I also encountered this problem. I was using VSCode and opening a folder in it on WSL Ubuntu 20.04. The solution for me was to install the VS Code Remote - WSL extension.
I hope this will be useful for someone.
TLDR : on Windows 10, if you have Cygwin64 installed and you got a Git For Windows update, check Git for Windows path comes before Git from Cygwin path in environment variables.
Long version : Just got into the same error today. The Git Lens extension was not working anymore.
I'm on Win 10, so there is no way (at least I didn't find one) to increase the limit of watchers like on linux. My VS Code is v1.66.2, Git Lens extension is v12.0.6.
In my case, the logs said :
... [error] [File Watcher (parcel)] Unexpected error: Invalid handle (EUNKNOWN) (path: cygwin\g\path\that\exists)
Notice that ENOSPC !== EUNKNOWN
So I searched everywhere with little to no success, except here where Gordon Christopher Weeks's answer actually hinted me towards that logs.
Then I remembered several things :
I have a terminal installed that's called cygwin64 and that allows me to use some linux utilities otherwise not available on Win (like rsync);
two days ago, I authorized an update for Git for Windows (2.35.2);
when I installed cygwin, the tutorial I followed told me about following a certain sequence in the Windows path environment variable
So I checked the path variable, noticed the Git update deleted the initial path to git and put it in the last place. I only had to move it up, before the cygwin64 path to git.exe (a git utility is included with cygwin) and everything's back to normal.
Hope this helps and so you won't waste the time I did !
[Possible quick solution] First thing to check is to see if you are tracking a WSL folder in a Visual Studio Code Explorer workspace AND you switched VS Code back to windows (was in a WSL distro).
If so, then right-clicking on it and selecting "remove from workspace" will also remove it from the file change watcher.
Refresh the file change watcher (bell icon, lower right corner of window) to see if it cleans up the problem.
This was the issue I had with the system.
I am using VSCode version 1.12.2 in Windows 10 x64 build 16193. I am trying to debug Powershell in VSCode, but I cannot get the PowerShell Integrated Terminal working. Every time I started the terminal, here's what I see:
And then it hangs in that stage. I can still debug, start, step in, step out..., but I cannot view my variable or run any expression.
My VSCode is using powershell x64 here:
"terminal.integrated.shell.windows": "C:\\WINDOWS\\Sysnative\\WindowsPowerShell\\v1.0\\powershell.exe"
So this is a known issue with this version of windows 10. Workaround here: https://github.com/PowerShell/vscode-powershell/issues/742
It's possible it's getting stuck on something while loading your profile(s). Try adding this to your settings to skip this:
"powershell.enableProfileLoading": false
I have had a similar problem, it seems. I cannot be sure it is the same, but when I would "load a file with VSCode" (user installer confirmed, system installer unconfirmed), it would hang. The following avenues tested:
Double-clicking on a PS1 file (the association to Code being made)
Starting VsCode empty and then loading the file
Starting VsCode from the command-line with a file-designation parameter
Using the --verbose switch, I got a listing which lead me to believe that VsCode seemed to be checking on updates using NPM (I could be wrong here).
Whatever the underlying problem, I did a lot of prodding and probing, and the cure I found was this.
Delete the directory called C:\Users\YourUserId\.vscode.
This directory is rather large, is not wiped by software removal, and may be corrupted apparently. After deleting it, the problem disappeared.
Does anyone know if there's an option (or a suggested hack) to make IPython notebooks save automatically before executing a cell?
Many times I've been working on something without saving for quite some time, then I execute a stupid command that prints so much crap to the console that my browser becomes unresponsive, leading to me losing all my work.
A timed autosave might also do the trick.
The development version has that feature fully implemented. Install it by following the instructions on the ipython github.
Instructions form the repo:
If you want to hack on certain parts, e.g. the IPython notebook, in a
clean environment (such as a virtualenv) you can use pip to grab the
necessary dependencies quickly:
$ git clone --recursive https://github.com/ipython/ipython.git
$ cd ipython
$ pip install -e ".[notebook]"
This installs the necessary
packages and symlinks IPython into your current environment so that
you can work on your local repo copy and run it from anywhere:
$ ipython notebook
Updating iPython Notebook solved several problems I had with iPython Notebook; for instance, it autosaves, or auto-correction is disabled, or %matplotlib inline works now (before updating, I had to use --pylab inline in the command line when I was running $ipython notebook).
As I use coda on my mac, I updated iPython Notebook via conda:
$conda update ipython
You could simply set a lower interval for autosave feature using the following magic command:
%autosave 60
in order to save automatically your notebook every 60 seconds.
Whats an efficient workflow for my IPython projects?
Requirements:
easily open notebooks from anywhere
easily shift between many notebooks in different locations
support the rest of my workflow (ie. version control, manipulating project files outside of IPython
Motivation:
If you’re like me, you often work in IPython notebooks, continually open and close many different notebooks as you wind through your work day. Its often suggested to launch the IPYNBs from the command line with something like ipython notebook --pylab=inline but navigating back and forth between deeply nested dirs gets old fast. What’s the best way to get around this?
Use a .bat file!
An example of how to construct one for easy launching of IPython notebooks is shown below. Save the file as go.bat and then from the command line you can execute go “ipython_notebook’s name” to easily launch it from anywhere. (you can name it anything, go is just convenient.)
Because your working dir can now be easily pointed to your project dir: The project workflow conveniently supports some helpful operations from the command line.
Easy git commands -- push, pull, and version the crap out of the project
Easy project inspection – use start . to open your projects directory an easily manipulate files outside of IPython
Easy starting of an IPython cluster by adding pcluster start -n 4 to the start ipython notebook line in the batch file
Know of way to improve the workflow or a better way to do this? Let me know!
batch file:
#echo off
GOTO %1
:titanic
cd C:\Users\Andrew\Documents\Kaggle\Titanic\Dups\Kaggel-Titanic
start ipython notebook --pylab=inline
GOTO END
: NB
cd C:\Users\Andrew\Documents\IPython NoteBooks
start ipython notebook --pylab=inline
GOTO END
:END
I quite satisfied of how GNU tools run in my Cygwin on Windows Seven. I think it's easier just to use GNU/Linux, but my company here has the policy of using Windows Seven for the Programmer programming environment. So, the solution is Cygwin. And I use Emacs intensively for my programming purpose.
But, it seems that Emacs running in Cygwin create a consistent (phrew) crash dump that printed on the console. I had to refresh it using C-l, but that makes me wonder : what is the problem anyway?
Does anyone has the same problem here? And what is the solution.
This is my example of running org-googlecl.
Process googlecl-list finished
* List of blogs with in the * List of blogs with in the title :gblog:
12719501 [main] emacs-X11 1168 exception::handle: Exception: STATUS_ACCESS_VIOLATION
12720164 [main] emacs-X11 1168 open_stackdumpfile: Dumping stack trace to emacs-X11.exe.stackdump
12889237 [main] emacs-X11 764 exception::handle: Exception: STATUS_ACCESS_VIOLATION
12889852 [main] emacs-X11 764 open_stackdumpfile: Dumping stack trace to emacs-X11.exe.stackdump
And it always create emacs-X11.exe.stackdump. It always happen when I run another process from within emacs, that is if I run a batch file from Emacs.
Thank you
I recently ran into this issue when upgrading my version of Cygwin to 1.7.9-1. pserice's solution looked promising but did not work for me. The solution that worked for me was to run rebaseall:
Close ALL Cygwin processes (use Process Explorer to make sure that nothing has cygwin1.dll loaded in it)
Start > Run > Cmd.exe
cd \cygwin\bin
ash
PATH=.
rebaseall -v
After that, emacs stopped crashing every time it tried to run a subprocess.
Win7 aborts processes that overwrite parts of the stack. If you trust cygwin executables, you can selectively exclude them as follows:
Computer -> Properties
-> Advanced System Settings
-> Performance
-> Settings...
-> Data Execution Prevention
I excluded the following:
C:\cygwin\bin\bash.exe
C:\cygwin\bin\emacs.exe
C:\cygwin\bin\emacs-nox.exe
C:\cygwin\bin\emacs-X11.exe
C:\cygwin\bin\startxwin.exe
I have had this same problem in running console emacs through cygwin on Windows 7.
My solution to this was to install the native GNU Emacs Windows client: http://ftp.gnu.org/gnu/emacs/windows/ and set cygwin's bash.exe as my shell.
You can see my emacs.d/init.el at https://github.com/tildedave/init.el/blob/master/init.el: here is the part relevant to making sure that the Windows 7 Emacs plays well with cygwin --
(if is-windows
(progn
(add-hook 'comint-output-filter-functions
'shell-strip-ctrl-m nil t)
(add-hook 'comint-output-filter-functions
'comint-watch-for-password-prompt nil t)
(setq explicit-shell-file-name "bash.exe")
(setq shell-file-name explicit-shell-file-name)))
For light-weight in-console editing I use nano, which does not core dump.
I can't help with the specific issue, but as a possible alternative you could look at running Emacs in a Linux VM hosted on your Windows box. You can use Cygwin's X.org server as the display, so the end result is largely the same as using Cygwin's Emacs.
It means jumping through a few more hoops, but I find it a good solution, and it will hopefully avoid the crashes.
I'm using VirtualBox to host my VM.