Earlier quoted context omitted.
There is cell magic to cache your long-running cells.
Didn't know about that one - thanks! Any thoughts on the infinite loop problem, though? I've seen tons of threads for it in stackoverflow/github and not much ever comes from them. Lots of dev he-said-she-saids, though. Pretty big problem for a lot of us.
JupyterLab: the next generation of the Jupyter Notebook
31–40 of 119 posts
Re: JupyterLab: the next generation of the Jupyter Notebook
#32It supports these languages: Python, Python3, R, JavaScript, SQL, C++, Scala/Spark, Lua/Torch, Java, Julia, Groovy, Node, Ruby, HTML, and Clojure.
It has an experimental native version: https://github.com/twosigma/beaker-notebook/wiki/Electron-Be...
Talk at SciPy 2015: https://www.youtube.com/watch?v=iMPfLz6kKv8
Re: JupyterLab: the next generation of the Jupyter Notebook
#33that said probably still probably a good system on balance..
Re: JupyterLab: the next generation of the Jupyter Notebook
#34Earlier quoted context omitted.
I use widgets for data exploration, model tuning, and interactive plots. Works great in practice! Have a look at bqplot from Bloomberg used in production.
I avoid widgets for data exploration, which should be written from the start in a well-tested and library-focused sort of way even when it's ad hoc. Model tuning absolutely should not be done with something like a widget. In fact, I could see how that could easily lead to unreported issues with multiplicity of testing when someone's just sliding around a slider and seeing what looks best, oblivious to the statistical…
Re: JupyterLab: the next generation of the Jupyter Notebook
#35Beaker Notebook (posted several times, but without much attention[0]) does something similar: http://beakernotebook.com/features It supports these languages: Python, Python3, R, JavaScript, SQL, C++, Scala/Spark, Lua/Torch, Java, Julia, Groovy, Node, Ruby, HTML, and Clojure. It has an experimental native version: https://github.com/twosigma/beaker-notebook/wiki/Electron-Be... Talk at SciPy 2015: https://www.youtube.c…
Re: JupyterLab: the next generation of the Jupyter Notebook
#36Earlier quoted context omitted.
I avoid widgets for data exploration, which should be written from the start in a well-tested and library-focused sort of way even when it's ad hoc. Model tuning absolutely should not be done with something like a widget. In fact, I could see how that could easily lead to unreported issues with multiplicity of testing when someone's just sliding around a slider and seeing what looks best, oblivious to the statistical…
Hey, Tufte also criticizes Excel, which is still most widely used tool for analyzing data and making plots that are not static. Engineers love it. Anyway I will stop here my replies.
Re: JupyterLab: the next generation of the Jupyter Notebook
#37Earlier quoted context omitted.
Totally agree. My larger notebooks get pretty ugly and I have to spend a fair bit of time cleaning them up. But that's probably because I am not the most organized person ever.
That is why it is better to keep a jupyter terminal or qtconsole around for quick and messy experimentation connected to the same kernel before pushing it to notebook
Re: JupyterLab: the next generation of the Jupyter Notebook
#38Beaker Notebook (posted several times, but without much attention[0]) does something similar: http://beakernotebook.com/features It supports these languages: Python, Python3, R, JavaScript, SQL, C++, Scala/Spark, Lua/Torch, Java, Julia, Groovy, Node, Ruby, HTML, and Clojure. It has an experimental native version: https://github.com/twosigma/beaker-notebook/wiki/Electron-Be... Talk at SciPy 2015: https://www.youtube.c…
Re: JupyterLab: the next generation of the Jupyter Notebook
#39Re: JupyterLab: the next generation of the Jupyter Notebook
#40It's been a couple of years since I played around with Jupyter notebooks, but then I got frustrated quite soon:
Stepping outside my preferred editor (vim) was annoying, likewise I had no idea if (how?) I could export the code out of notebook to a regular .py text file (without clumsily copypasting each cell). And the .ipynb files itself seem quite terrible to manage in Git: write something and if you want to 'git diff' the changes, sometimes what you see is okay, sometimes it's not very... easily decipherable. (Text encoded image/png's?!)
My preferred workflow with R is to open the files I'm working with in both RStudio (with vim keybindings) and vim. Maybe if I just strictly restricted the use of notebook cells just for calling scripts and functions written in external files, and use the notebook as a whole just for presentation purposes, but then it wouldn't be that much an improvement over regular IPython. Any thoughts?