I am pretty much vendor-locked with Jupyter at work, and while I enjoy some of its' perks (load data once & experiment with it, more structured than append-only REPLs), I find it quite big, easy to break, diffcult to install & manage, and inconvenient (editor is literally an HTML textarea).

I started working on a simple replacement in C which would only do 3 things:

1. open a background interactive process
2. pipe stdin to it from a named pipe
3. pipe stdout from it to another named pipe

So similar design to suckless ii. This has some advantages:

- you can now work from $EDITOR and just send lines / blocks to the interpreter of choice
- no more "Jupyter kernels", as it should work with any process

The issue is, only steps 2 and 3 are working (through the fork / exec / dup2 magic!); I have been stuck at keeping the process running -- the interpreters exit immediately after the first command is executed.

I suppose I could use /proc filesystem API, but I'd rather make it Unix, not just Linux friendly.

Does anyone know if something similar has been done before? And do you have any tips on how to proceed?

Here is all 40 lines of it: http://0x0.st/z2C3.c, runs with "./z2C3 bc" (or sh, or python, etc…).

EDIT: you'll need to mkfifo {in,out} before running

What's jupyter? Some sort of online wiki?

Ah sorry -- it's quite popular in my line of work so I forgot it needs introduction.

Jupyter is a notebook-interface to a scripting language. It has a frontend (usually a browser interface) and a backend (an interpreter process), linked by some message queue. It is similar to a REPL, but it is not append-only -- you can insert code into separate "cells", and then edit & re-run them.

For emacs lovers, there is Org Mode, that could come close (permits to run code snippets).

But the UNIX-style ubiquitous notebook is sh(1) :)

It is about taking the approach of having various helper programs communicating by simple common formats (with glue to adapt between them), scripting them in whatever lang you want...

The biggest itch for me is keeping a clean history. I could appreciate a shell that make a good distinction between the program output/input and the rest: I could benefit by having each output piped onto some pager/buffer so that I can select a past buffer and copy the raw content for instance...

This permits to run the command, and then only consider that you want to do something else with the output, like piping it even though it is already out...

That thing might pretty much be called emacs (yet a different approach), but emacs is way too harsh to me.

Maybe you could give acme or UNIX-only derivatives a try, which blurs the border between buffers, shell, editing, running command input...

(12-01-2020, 08:39 PM)josuah Wrote: Maybe you could give acme or UNIX-only derivatives a try, which blurs the border between buffers, shell, editing, running command input...

I personally use dvtm for this purpose. You can edit your scrollback buffer in $EDITOR, edit/save it and then paste it elsewhere.
Not as integrated as what you have in acme, but still a good candidate.