automatically clear notebook output on close in Jupyter Lab? - python-3.x

Is there a default setting in Jupyter Lab to clear output for an entire notebook upon file closure?
Or a bit of code I could run early in the NB with import statements or similar. (I have some NBs where I don't run every cell every time I open).
My current workflow is to manually clear before save and exit, but I just encountered a repo commit where I'd forgotten to do that and I had a bit of an adrenaline spike as I flashed back to a corrupted notebook last year.
My interest is preventing potential problems and minimizing user-executable steps to do so. I'm not interested in stripping from the command line post-hoc.
This thread just clears individual cells.
I'm somewhat intrigued by this one but, without spending more time on it, not clear how much effort it would take to incorporate into my GitKraken flow.
This also seems promising, but again is on the back side of things.
Figured I'd check if I'm missing something much more fundamental.

I'm using jupytext and convert my notebooks to markdown format, so whenever I close them, the outputs are cleared automatically.
https://jupytext.readthedocs.io/en/latest/

Related

How to properly prevent multiple instances of my AutoHotKey script from running at the same time?

I have made this AutoHotKey script after reading the manual, searching and troubleshooting for endless hours in the last few weeks:
#Persistent
#SingleInstance force
if A_Args[1] > 0
{
Menu, Tray, Icon, C:\blablabla\new notifications.png
}
else
{
Menu, Tray, Icon, C:\blablabla\no new notifications.png
}
This, I have compiled into test.exe. Then I call it like this from a terminal: test.exe 1, test.exe 0, test.exe 2, test.exe 3, etc.
If I do it slowly/manually, it works: it only ever keeps one instance of the script, showing visually as a nice little icon in the Notification area (as intended), never launching multiple instances.
However, when I started actually using it for real, by calling the same terminal command from my scripts, it often opens two or more instances, which are kept open and just make the Notification area longer and longer, ignoring the rule that it only can run as one instance ever.
I was able to "solve" it by introducing a short "sleep" in my script after each such command call, so that the same script never calls it too quickly in succession. However, today, I realized that multiple different scripts of mine often call it at the same time, or nearly at the same time. This means that my "clever" solution of sleeping falls short.
I then thought that I can use the database to keep track of when the last time a script called this, and don't do it if it's too soon, but if I did that, the whole point would be lost since I can no longer trust the icon to accurately tell me whether or not there are new notifications in my system. I'd constantly be wondering if there had been such a "race condition" and manually go and check anyway, defeating the point of this visual indication which is supposed to let me always know "at a glance" whether or not there are new notifications in my system.
Maybe I could have a loop in my scripts and repeatedly re-try if it detects that a notification has been sent too recently, but that means my scripts will potentially stall for a long time as they all send notifications (especially in the morning, when I wake up and kickstart my system). It just seems like the wrong solution.
Is there really no way to properly handle this in the script itself? As is obvious from my description, the #Persistent and #SingleInstance force rules aren't respected.
(I've had similar problems in the past with programs being unable to "handle" running commands too quickly, and I never know what to do about it except to introduce sleep. But even then, it often glitches out. For example, Notepad++ requires me to first open a document and then open it again with a specified line number, sleeping in between, or else it doesn't go to the specified line.)

Excel automatic calculation crashes, but manual calculation works

I have a relatively large (7MB) but more importantly formula and macro heavy excel file that I have been developing recently.
For the end user it must be able to be used in Automatic Calculation mode.
While calculating the whole sheet in Manual Calculation mode using F9 (Calculate Now) will work and calculate in ~10 seconds, but when I turn it onto Automatic mode, it will calculate repeatedly (i.e reaches 100% and then immediately starts again from 0%) and so freezes indefinitely.
So far I have tried:
Putting break points in all the VBA macros to see if it is hanging inside a macro
Removing all of the macros from the file (I was worried one of them was being triggered to run repeatedly in automatic mode)
but neither has worked leading me to wonder if the issue is not in fact VBA related.
Does anyone have any ideas about:
What might be causing this?
How I might diagnose the cause?
Happy to give more context if helpful. I am a relatively experienced excel user, and while generally don't write VBA macros from scratch am pretty confident at re-purposing code I inherit / find online. I am using a relatively powerful 6 core machine, but have tested it on others to the same results.
The issue turned out to be a volatile action that a macro was triggering. I had a macro that looped through hiding empty rows, but hiding a row is volatile, so then triggers a new calculation before the next run through the loop. The loop itself was 500 iterations, so that meant 500 sets of 3 second calculations!
See this link for more on volatile actions:
https://msdn.microsoft.com/en-us/library/bb687891(v=office.15).aspx

python program using Glade, GObject, runs fine for days, then suddenly all windows are blank

I have a large data acquisition and control program written in Python3.4.2 using GUI mostly developed on Glade 3.18.3, Gtk3.0 GObject running Debian 8 with XFCE.
There are timers that keep doing things, and these work fine. After startup, the program runs for some 3 - 7 days, then suddenly, all of the windows go blank and stay blank. Other applications are not affected. Memory and CPU usage is modest.
There are no indications of problems prior to the windows going blank. The windows show their title bars and respond normally to minimize, restore, move to another Workspace, etc. It looks like they are not getting repainted - no widgets are visible at all. The code is way too large to post here, and I am not able to isolate a specific problem area for lack of obvious symptoms other than the blank screens. There are no error messages or warnings.
The timers continue to run, acquire data and control things. This happens whether the program is run from the command line or under PyDev in Eclipse.
Things I have tried:
In the main timer loop, I put code to look for a file, and then exec the command in it, printing the results, so I have been able to mess with the program in real time:
Replace the usual Gtk.main() with a while loop whose variable, if not made false, will re-execute the Gtk.main(). Executing Gtk.main.quit() stops Gtk.main and starts it again. Windows still blank. Did this repeatedly to no avail.
Experimented with garbage collection with GC. Collecting garbage makes no different. Windows still blank.
Put in code to print percent of time consumed by the timer loops. Fairly steady around 18 - 20% of available CPU time, so nothing is hogging the CPU preventing re-paint.
I have a button that clears a label. I read the label, then executed a builder.get_object(...).activate command to the button. I re-read the label and it was now properly blank. So events and widgets appear to be working normally, at least to some extent.
Finally, if I click on the close X on the title bar, XFCE asks me if I want to wait or close now. So it seems as though there may be a disconnection or problem with signals and the OS, even though XXX.activate() works.
Web searching is in vain. Does anybody have ideas of what might be happening, useful diagnostics, or other suggestions? Many thanks!
April 27, 2017 Update:
I have taken two substantial steps to mostly work around problems. First, partly in response to a couple of Gtk crashes over the last few months, instead of ending the main program with:
Gtk.main()
I end with:
while wannalive:
try:
Gtk.main()
except:
pass
wannalive is True until user does a quit, so recovery is instant.
Second, I grouped all of the code for each window setup and initial population of static items into two functions. I also made another function for closing a window. These functions propagate to children, grandchildren windows. A function in the top window first, closes, then re-creates all windows, with one call. In operation, there are overlaps in what windows exist, but that is not a problem.
Above, I describe that I can inject code with an external program. The external program has a button that injects a call to that third function. In about five seconds or less, the result of a single button click is to replace all blank windows with functional windows. For my purposes in a controlled environment with a trained operator, this is acceptable.
Next, let me address the relationship between the timer loops and GUI events processing. I do use GObject.timeout_add(ms, somefunction). Experiment shows that a button that calls time.sleep(5) stalls the timer. Experiment shows that injecting time.sleep(5) in the timer loop stalls the GUI. This is consistent with my belief (correct me if I am wrong) that Python runs on a single thread. Therefore, bad code caught in an infinite loop should stall both the GUI and the timer loop. (The program has one timeout_add call.)

Is there a way to jump to start of output in Cygwin?

I am running some unit tests by calling a script in Cygwin. My issue is that I apparently broke something in my code, and now the unit test output is many hundreds of lines. I need to jump to the start of the output in order to figure out what it going on. Scrolling is taking forever, and it is entirely too easy to scroll right past the start of the output.
Is there a shortcut to jump to the start of the output? Google gave me nothing, so I'm hoping someone here knows.

How to avoid sublime text 2 freezing

Sublime text 2 is freezing from time to time, when I have many selections in large files. After a while it continues. I am on windows 2008.
For example it happens when I hit ctrl-d many times or even keep it pressed to add many selections. It adds selections, then stops, and after a while continues adding selections.
I suspect this is due to garbage collection.
Is there a way to avoid this or make the freeze period shorter? Maybe give it more memory, or even better less memory so gc is more frequent but much shorter.
Or maybe this is some sort of swapping or missing or wrong temp file config.
What is the reason and is there a good solution for it?
Sublime Text 3 may freeze too. Plugins can cause that.
First thing
...you may want to do is run command CTRL + SHIFT + P -> Plugin Development: Profile Events. You will get a list of events which different plugins are listening to and time it taken for them to process the event.
Give special attention to on_modified event. Quote from sublime docs:
Expensive operations in event listeners can cause Sublime Text to
become unresponsive, especially in events triggered frequently, like
on_modified() and on_selection_modified(). Be careful of how much work
is done in these and don’t implement events you don’t need, even if
they just pass.
This was my case: a plugin was meticulously processing every on_modified event which resulted in overflowing the thread queue and freezing ST.
Also
... don't forget that Sublime Text has a console where you sometimes can find useful messages and tracebacks. To reveal console use a key binding CTRL+`. Working for a while with your eye on the console may help you get the idea if something is going on wrong.
It recently starting freezing for me too, each time I'd re-focus on code in a Sublime window, whether that be alt-tabbing or even searching the command palette!
What fixed it up quickly for me was Reverting to a Freshly Installed State, then restoring those folders.
Update: It turned out to be Git Conflict Resolver
, perfectly responsive after disabling.
This question is old, and the issue did not occur with later versions anymore.
So I suspect it was fixed at some point.
If you still experience freezing in sublime text try the following:
Find out what version you are running and try switching to the latest stable version.
See if the freezing could be an operating system issue. This could be indicated by not only sublime text but at the same time all other applications freezing.
If you have a different solution or explanation why not add it here for reference.
I still believe the underlying reason could have been a garbage colletion (read at wikipedia about garbage collection) within the application.

Resources