A perfect use case for unicode plotting [1] (shameless plug)
http://tamivox.org/dave/boxchar/index.html
Unless I'm wrong about your demo, it seems like you are using some of these? There's a 2x2 pixel grid, and some characters that would be good for bar charts, both horizontal and vertical, and also with negative numbers. That's better than I thought we had, but not a big palette to work with.
Are you aware of any proposals to expand the pixel art capabilities of Unicode? Grids have the problem of requiring 2^(X x Y) characters to represent all states, but diacritical marks don't have that scaling problem. For example it would take 64 characters to represent a 2x3 grid of all on/off states, whereas a 6x8 grid of rectangular diacritical marks would only take 48 glyphs.
Note aware of Unicode expansions, though more and more fonts seem to support the above.
Sparklines in the terminal sounds very cool, did you end up coding something?
Note that one other popular alternative (see for example the Unicode plotting lib for Julia) is using Braille characters, which probably have an even better support across fonts
The closest thing that we've found has been to use the notebook percent format in a simple .py file [0][1]. It plays with git much nicer than an .ipynb and it is still interactive enough for rapid prototyping. However, it would be nice to have some first-class support from Jupyter on this.
[0] https://jupytext.readthedocs.io/en/latest/formats.html?highl...
[1] https://code.visualstudio.com/docs/python/jupyter-support-py
However, I recently started using VSCode Insiders the preview release of VSCode, which has amazing support for Jupyter notebooks in the editor. You can use your normally configured linters, auto-formatters, vi-mode keyboard shortcuts (major selling point for me). You even get legible, cell-aware diffs when comparing in git. Now, the edit/git workflow for .ipynb files is so close to parity I've stopped caring whether code is in a proper Python module or not, and I almost never run Jupyter Notebook or Jupyter Lab in the browser.
In some ways this is a loss, because it's nice to have project-wide linting and other tooling that only work with .py files, but using `%run` was always an imperfect abstraction. By default, `%run` executes modules in a new module namespace which is then copied over, so it's not exactly "paste into Jupyter" unless you do `%run -i`. Even then, it's limited by running all at once. Every cell in a typical Notebook is effectively a button that runs an `exec()` statement, and you can't achieve those semantics by calling Python functions.
That's an interesting solution. I believe this is similar to what Joel Grus does [0], except %s/jupyter/ipython.
Pity Emacs is not the best on-boarding experience.
[0] https://github.com/mwouts/jupytext/blob/master/docs/paired-n...
Real, working code gets checked in to a repository. The only reason to go back to an old notebook after that point is maybe to see how you may have experimented with or poked at some data.
And apart from that, we have a normal github component to load your code from a github repository: https://nextjournal.com/help/github
FWIW my team uses bitbucket and the PR experience is significantly worse than github/gitlab unfortunately.
If you use emacs, ein is also a good choice: https://github.com/millejoh/emacs-ipython-notebook
How have Hy been treating you?
Ok I'm stuck, let's at least get 1+1 to work. So entering 1+1 and .. hitting Enter? Shift Enter? No. Ok, command mode, Ctrl E.. aaaaand it's stuck.
Looks nice but I just don't seem to get it to work using anaconda on macos..
Edit: The issue is using a new environment without ipykernel installed (not a dependency of the conda package). With ipykernel, I can exit nbterm and even evaluate cells
I used to use a matplotlib backend that worked with ITerm2 for coding in a remote server (standard technique, that I also cover in my Hy language book). Adding Nbterm would also be useful. Off topic, but it is sometimes just (much) better to do development on a remote server with much more compute and faster Internet connections.
Which brings me to the question whether I can edit the code in a text editor as well or I have to write it as shown in the animation. It would be really helpful if there was a shortcut to open the current (code) section in $EDITOR, kind of like Git and other tools do it.
The motivation behind this was to have some basic interaction with existing ipynb files on a remote server without having to run the jupyter server (and set up port forwarding etc.) It's worth noting that the `jupytext.vim plugin is most useful if you're actually not running `jupytext` within jupyter; If you are, you could just directly open the .py or .md files linked to any .ipynb in your editor.
I've used `jupytext.vim` to edit existing notebooks and then run them through `jupyter nbconvert --to notebook --execute`. It's also great for refactoring: moving code from a notebook files into a module, between notebooks, or to create a new notebook as a variation of an existing one.
It also unfortunately uses shortcuts that are native on Mac (ctrl+up and down do "mission control" things).
IPython was in the beginning Python specific, though its heritage lives on in the new name (the 'py').
I would love early HN feedback on Notebook Ninja, which is (pre-)alpha here: https://notebook.ninja
nbterm is "notebooks in the terminal", Ninja is "materialized notebook executions". So, for example, whereas nbterm will display cell outputs, ninja will materialize them to disk and make them available via (eg) HTTP.
Whereas nbterm is a CLI-based notebook development environment, Ninja is a notebook production execution environment.
Ninja continues the thought from "how do I build notebooks better" to "how do I get into production".
