91–100 of 100 posts
As an example I love jupyterlab's "open console for notebook" but can't find a way of sending copied text to it, or switching focus with a keyboard shortcut
It's a big reason I can't do vscode Jupiters implementation
It's probably an unrelated post (apologies in advance) but I wanted to shoutout to the Marimo ( https://marimo.io ), it's the only Jupyter alternative that really got me excited, it's like Streamlit and Jupyter had a kid (and the kid took the best genes from both).
marimo is really cool, albeit "pure python" is only true insofar as the diff is concerned. other than that, it's an unconnected group of functions that need the marimo runtime to stitch together. would be cool if marimo could "unroll" the compute graph into a standalone python script that doesn't need the marimo library
Earlier quoted context omitted.
Hello and thank you for making this! Can I sway you to take this into a ... certain direction? From my POV any browser based editor will be inferior to emacs (and to lesser extent vim) simply because it won't run my elisp code. While a fresh and snappier UI compared to eg jupyter would be nice, I would love to see something that integrates well with emacs out of the box. So, perhaps it would be really nice if the bac…
I'm curious what your thoughts on are on emacs-jupyter[0] which seems to integrate reasonably well with Org mode. I have some complaints about how it has to handle output blocks, but otherwise it seems like a great way for Emacs to act as a frontend to a Jupyter kernel. [0]: https://github.com/emacs-jupyter/jupyter
To refresh my memory I just started it and tried using it with a julia kernel on a remote jupyter. To start, it wouldn't connect to https endpoint. Maybe because it's signed by a private CA? idk, but the mac trusts it for eg the browser and curl. Well anyway, let's forward the http port and try connecting to localhost.
Great, that works, and I'm offered some uuid as a "choice of kernel to connect to". I don't recall having one running before I connected, so it probably was started for me. How do I name it? Ah, there's `jupyter-server-kernel-list-name-kernel`, and now I'm recalling that whatever you name it as, will disappear if you quit emacs. Let's try.
Meanwhile, I import PlotlyJS and try to create a plot. I get complaints about WebIO (julia package that facilitates interaction with browser) like I do in jupyter (the package is old and doesn't work with current jupyter), except in the browser only the back communication (browser->kernel) is broken, for interactivity. Showing plots works. Anyway, PlotlyJS displays nothing. `Plots`, which renders to a png, somehow produces the axes but not data. Eventually I get PlotlyJS to display an image using explicit image mime types.
Still no interactivity - I would need node for that, to compile widget support for whatever reason - but it does display. I should retest widget support. Sending code to repl works, although at this point I'm used to seeing an overlay over variables that get set.
Ok. Close emacs, restart, go to session list (`jupyter-server-list-kernels`). Name has been cleared. I can reassociate the buffer to the kernel, but, if I have two, open kernels, how do I tell which buffers is associates with which kernel?
Overall it mostly works although there's room for polish. However, interactivity or any kind of bidirectional communication remains somewhat difficult.
Earlier quoted context omitted.
Yes, I'm aware of EIN. To start, it's been abandoned by it's author/maintainer as of April 2024 IIRC. Further, I do not need a kernel to execute emacs code - I have one and it's called emacs. The point regarding executing elisp code was a cheeky way to state that I am not looking forward to finding replacement and/or porting of all the custom code - mine and others' - that my editor runs, and that no amount of "featu…
I'm guessing you already looked at org-mode code blocks which basically do the same thing as a juypter notebook without a web protocol, webUI and anything else if you wanted an experience that is easier to commit to a git repo and has a notion of cells which is the magic sauce for juypter (it was originally derived from ipython which is a command line interface). I am also a emacs user :) Juypter has an interface and…
I think it can be very suitable eg when you are preparing a presentation, report, a paper or a repeatable analysis/process. Especially - as with most of those examples - if you want to interleave narrative and code/results. It is less suitable for doing exploratory analysis, for any kind of interactivity, for connecting to remote sessions (it's possible but clunky), for showing a chart that you can zoom into. For displaying a table with 10,000 rows, for displaying a large plot. Or multiple plots. For being able to zoom into a plot. It's not great at integrating with LSP and similar tools. Could be better at managing code blocks, though one could write additional helpers and bindings fairly easily.
And, finally, it is quite a pain in the ass to have the code stored in a document rather than as code since it does tie me down even to my beloved emacs. I develop most of my code as library code which I can directly import/run. During the development it is still helpful to see the results of running defined functions and to be able to interact with the dataset. I currently do have a solution and a workflow but the tools aren't ideal for it.
I want to be able to have my codebase run inside a docker container, to be able to `git pull` to update it on the remote without involving emacs on the remote end, without having duplicate versions of the code in the repo (ie one in the org document and one tangled) for me to manage, and I also want to be able to make a small change in vim and push it back without involving emacs.
> Juypter has an interface and API built in. What Zasper is the reimplementation of the juypter protocol. You can see this at [1].Juypter kernels are very different from Mathematica notebooks. Mathematica notebooks aren't related to juypter.
Thank you for the explanation. Up until this very moment I thought mathematica and jupyter were exactly the same. Just to make sure, when you say they are very different and unrelated, do you mean like matlab is unrelated to numpy+ecosystem, like how Honda cars are unrelated to Ford cars, or like how pandas is unrelated to excel?
It helps when you are actually familiar with the technologies before making any - especially contradictory - claims. Mathematica for all it's faults - primary of them being proprietary - has a quite finely polished product and jupyter notebook interface draws heavily from it. I'f I'm not mistaken it is the OG notebook interface, though I'm not making a strong claim here.
Mathematica also has an interface and an API built in. You can run mathematica (or is it "wolfram" these days?) code on a headless kernel, you can connect your notebook frontend to a remote kernel, and you can make your own completely independent UI using the APIs in the language. Alternatively, you can connect the notebook interface to a kernel in another language using J/Link MathLink or C/++Link APIs. Or you can embed the mathematica kernel into jupyter - an existing project/duct and run mathematica code in jupyter/Zasper/whatever. Or run it in their webui for the past .. decade at this point?
I'll give you the benefit of doubt and not assume that you are a trollbot but I sincerely don't understand your need to offer "first page of google" suggestions when you clearly don't use the technologies you're commenting on.
Earlier quoted context omitted.
Yes, I'm aware of EIN. To start, it's been abandoned by it's author/maintainer as of April 2024 IIRC. Further, I do not need a kernel to execute emacs code - I have one and it's called emacs. The point regarding executing elisp code was a cheeky way to state that I am not looking forward to finding replacement and/or porting of all the custom code - mine and others' - that my editor runs, and that no amount of "featu…
I'm guessing you already looked at org-mode code blocks which basically do the same thing as a juypter notebook without a web protocol, webUI and anything else if you wanted an experience that is easier to commit to a git repo and has a notion of cells which is the magic sauce for juypter (it was originally derived from ipython which is a command line interface). I am also a emacs user :) Juypter has an interface and…
I don't think that's fair. Rather, IPython, and later Jupyter, explicitly (successfully) sought to create a Mathematica-like notebook experience for Python.
Earlier quoted context omitted.
Sagemath offers a different purpose which is scientific computing in order to compete with Mathematica and MATLAB. It offered a good interactive notebook interface which went on till about 2016, and later on was migrated to using the jupyter backend. It currently isn't well supported in Windows which is what you might have meant by the complexity. However it works pretty well with linux systems.
> Sagemath offers a different purpose which is scientific computing in order to compete with Mathematica and MATLAB. Yes, that was its goal, when Python wasn't as evolved as it is now. More recently I've come to rely on Python libraries like sympy for symbolic processing. For these kinds of results Sage relies on a rather old environment called Maxima, and I think current sympy does pretty much everything that Maxima…
Earlier quoted context omitted.
marimo is really cool, albeit "pure python" is only true insofar as the diff is concerned. other than that, it's an unconnected group of functions that need the marimo runtime to stitch together. would be cool if marimo could "unroll" the compute graph into a standalone python script that doesn't need the marimo library
it’s already possible to do this: marimo export script nb.py Pure-python also helps to work with existing tools out of the box: formatting, linting, pytest, importing notebooks as modules, composition, PEP 723 inline metadata
Earlier quoted context omitted.
jupyter-server/enterprise_gateway: https://github.com/jupyter-server/enterprise_gateway JupyterLab supports Lumino and React widgets. Jupyter Notebook was built on jQuery, but Notebook is now forked from JupyterLab and there's NbClassic. Breaking the notebook extension API from Notebook to Lab unfortunately caused re-work for progress, as I recall. jupyter-xeus/xeus is an "Implementation of the Jupyter kernel protoco…
At this stage, notebooks should be a GUI powered docker-like image format you download and then click to run. Non programmers using notebooks are usually the least qualified to make them reproducible, so better just ship the whole thing.
Docker Desktop and Podman Desktop are GUIs for running containers on Windows, Mac, and Linux.
containers become out of date quickly.
If programmer or non-programmer notebook authors do not keep versions specified in a requirements.txt upgraded, what will notify other users that they are installing old versions of software?
Are there CVEs in any of the software listed in the SBOM for a container?
There should be tests to run after upgrading notebook and notebook server dependencies.
Notes re: notebooks, reproducibility, and something better than MHTML/ZIP; https://news.ycombinator.com/item?id=35896192 , https://news.ycombinator.com/item?id=35810320
From a JEP proposing "Markdown based notebooks" https://github.com/jupyter/enhancement-proposals/pull/103#is... :
> Any new package format must support cryptographic signatures and ideally WoT identity
Any new package format for jupyter must support multiple languages, because polyglot notebooks may require multiple jupyter kernels.
Existing methods for packaging notebooks as containers and/or as WASM: jupyter-docker-stacks, repo2docker / repo2podman, jupyterlite, container2wasm
You can sign and upload a container image built with repo2docker to any OCI image registry like Docker, Quay, GitHub, GitLab, Gitea; but because Jupyter runs a command execution shell on a TCP port, users should upgrade jupyter to limit the potential for remote exploitation of security vulnerabilities.
> Non programmers using notebooks are usually the least qualified to make them reproducible, so better just ship the whole thing.
Programs should teach idempotency, testing, isolation of sources of variance, and reproducibility.
What should the UI explain to the user?
If you want your code to be more likely to run in the future, you need to add a "package" or a "package==version" string in a requirements.txt (or pyproject.toml, or an environment.yml) for each `import` statement in the code.
If you do not specify the exact versions with `package==version` or similar, when users try to install the requirements to run your notebook, they could get a newer or a different version of a package for a different operating system.
If you want to prevent MITM of package installs, you need to specify a hash for the package for this platform in the requirements.txt or similar; `package==version#sha256=adc123`.
If you want to further limit software supply chain compromise, you must check the cryptographic signatures on packages to install, and verify that you trust that key to sign that package. (This is challenging even for expert users.)
WASM containers that run jupyter but don't expose it on a TCP port may be less of a risk, but there is a performance penalty to WASM.
If you want users to be able to verify that your code runs and has the same output (is "reproducible"), you should include tests to run after upgrading notebook and notebook server dependencies.
Earlier quoted context omitted.
I'm guessing you already looked at org-mode code blocks which basically do the same thing as a juypter notebook without a web protocol, webUI and anything else if you wanted an experience that is easier to commit to a git repo and has a notion of cells which is the magic sauce for juypter (it was originally derived from ipython which is a command line interface). I am also a emacs user :) Juypter has an interface and…
> Mathematica notebooks aren't related to juypter. I don't think that's fair. Rather, IPython, and later Jupyter, explicitly (successfully) sought to create a Mathematica-like notebook experience for Python.
Earlier quoted context omitted.
it’s already possible to do this: marimo export script nb.py Pure-python also helps to work with existing tools out of the box: formatting, linting, pytest, importing notebooks as modules, composition, PEP 723 inline metadata
If you are going to do that, you could stick with Jupyter + nbconvert. I rarely use notebooks directly anymore unless I require the output to be stored. Do most everything in VSCode with interactive .py files. Gets you the same notebook-y experience + all of the Python tooling.