Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nbterm: Jupyter Notebooks in the Terminal

blog.jupyter.org

Post reply on HN
Print view View original

41–50 of 76 posts

Re: Nbterm: Jupyter Notebooks in the Terminal

#41

Post by whitten »

olavolav wrote: post #36
whitten wrote: post #32

Earlier quoted context omitted.

Do you know if Uniplot is able to handle pediatric growth charts ? ( https://www.cdc.gov/growthcharts/index.htm ) or generally, being able to plot on a background that is always used, instead of the (default) of a blank page ? such as : https://www.cdc.gov/growthcharts/data/who/GrChrt_Boys_24HdCi... Thanks ! PS: Is the general case of a background image handled by Uniplot, and does Uniplot allow for the idea of takin…

Thanks for the question! So the labels only depend on the limits of the plotting window, which you can supply as a keyword option. In that sense, and together with using the same gridlines options, you could have the same background in some sense. What uniplot cannot do today is to have multiple vertical axis (like weight and head circumference in your example). Hope this helps! P.S.: Regarding your PDF question, for…

So, the question isn't really about the axes. The question is about the curved lines that are part of the background. These lines allow a medical person to know what the "normal" curves are for a child, and then the plotted points are compared to how well they match the curves (by observation) This tells the medical person if the child is growing normally, or if they are malnourished or have some other problem that should be watched to explain the unusual lack or presence of growth.

Since the data points may be gathered at any time, the possible creation of a combined PDF will allow the medical record to include which chart was used and when, so that folks in the future have a better handle on the history of that child.

Re: Nbterm: Jupyter Notebooks in the Terminal

#42

Post by whitten »

alfl wrote: post #38
whitten wrote: post #37

Earlier quoted context omitted.

What features does Noteback Ninja have that aren't present in the nbterm system ?

Great question. Right now Ninja is web-only for the public. Internally it's a CLI (releasing soon). 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 executi…

So Notebook Ninja has a flag that means write the notebook and its calculated cells to an html page or some other form that would capture a snapshot at a particular step in the process, and thus be suitable to be served by a web server without being "re-executed" ?

Why doesn't nbterm allow for production execution of code ? I thought that was the point of its existence, just that they are done in an terminal window rather than a web window.

Re: Nbterm: Jupyter Notebooks in the Terminal

#43

Post by kenward »

Slightly tangent, but has anyone figured out a good solution for version controlling jupyter notebooks?

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

Re: Nbterm: Jupyter Notebooks in the Terminal

#44

Post by hinkley »

olavolav wrote: post #18

Very cool to see this – but will only be successful with great terminal plotting tools. The ones the author mentions like the matplotlib interface clearly won't do[0] due to lack of resolution A perfect use case for unicode plotting [1] (shameless plug) [0] https://github.com/domitry/matascii [1] https://github.com/olavolav/uniplot

I spent a hot second last year thinking about sparklines in a terminal, and it seemed to me that unicode could use some more glyphs to improve this situation of treating a single glyph as a modest array of pixels. I don't know what I googled for, but for some reason I found only about 1/3rd of the characters listed in the final two lines of

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.

Re: Nbterm: Jupyter Notebooks in the Terminal

#45

Post by dokem »

kenward wrote: post #43

Slightly tangent, but has anyone figured out a good solution for version controlling jupyter notebooks? 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.read…

You can configure so they don't save their output, then the ipynb diffs will be readable.

Re: Nbterm: Jupyter Notebooks in the Terminal

#46

Post by slaymaker1907 »

kenward wrote: post #43

Slightly tangent, but has anyone figured out a good solution for version controlling jupyter notebooks? 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.read…

You could try a preprocessing step of converting them to markdown with Pandoc or nbconvert. In Git, you can configure custom diff tools for certain file formats.

Re: Nbterm: Jupyter Notebooks in the Terminal

#47

Post by alfl »

whitten wrote: post #42
alfl wrote: post #38

Earlier quoted context omitted.

Great question. Right now Ninja is web-only for the public. Internally it's a CLI (releasing soon). 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 executi…

So Notebook Ninja has a flag that means write the notebook and its calculated cells to an html page or some other form that would capture a snapshot at a particular step in the process, and thus be suitable to be served by a web server without being "re-executed" ? Why doesn't nbterm allow for production execution of code ? I thought that was the point of its existence, just that they are done in an terminal window r…

In essence, yes. Ninja is based around the idea of reproducable science: a given execution of a notebook is immutable and accessible consistently. It writes out cell outputs depending on their mimetype (this is included in Jupyter Notebook metadata).

It writes out all declared variables, per-cell, and makes them accessible in several formats (for pre-alpha, as JSON objects).

It then exposes all of these via our web servers, so it's really easy to connect them to other services.

Or, for example, generate a permanent link to the execution of a particular cell.

Re: Nbterm: Jupyter Notebooks in the Terminal

#48

Post by IlyaOrson »

olavolav wrote: post #18

Very cool to see this – but will only be successful with great terminal plotting tools. The ones the author mentions like the matplotlib interface clearly won't do[0] due to lack of resolution A perfect use case for unicode plotting [1] (shameless plug) [0] https://github.com/domitry/matascii [1] https://github.com/olavolav/uniplot

I am a big fan of https://github.com/Evizero/UnicodePlots.jl . It is unexpected how useful these tools can be to track the evolution of numerical experiments/developments right on the terminal.

Re: Nbterm: Jupyter Notebooks in the Terminal

#49

Post by lazzlazzlazz »

kenward wrote: post #43

Slightly tangent, but has anyone figured out a good solution for version controlling jupyter notebooks? 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.read…

Here[0] is a guide that explains syncing ipynb py files with Jupytext. I also add ipynb to `.gitignore`. It works well, although the file browser in Jupyter becomes cluttered with every notebook file being doubled. It'd be great to hide the underlying py files.

[0] https://github.com/mwouts/jupytext/blob/master/docs/paired-n...

Re: Nbterm: Jupyter Notebooks in the Terminal

#50

Post by zokier »

alpaca128 wrote: post #2

The web interface was the main reason I never really used the tool for more than a few test runs. Writing code in the browser combines bad usability and performance with a lack of useful dev tools. 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…

There is the %edit magic
Post reply on HN