It would be interesting exercise to compile cells into object files as they are entered and load them dynamically into a persistent process, doing needed linking etc on the fly in-memory. You'd also need to generate a header file from the current in-memory symbol table and implicitly include that in compilation.
That might actually work relatively well for simple cases. But I imagine there would be a ton of problematic edge cases, considering that with C you can end up with all sorts of weird stuff.
The %cython mode for Sage notebooks (which I wrote in I think 2008??) does precisely that by generating a random-named Python shared object libary and importing it into the runnig Python process after each evaluation. There's a similar (%%cython?) mode for Jupyter notebooks.
However, every cell would need a main() function or it wouldn't do anything. Or you hold onto a main function from previous cells, perhaps overriding it, and make the notebook confusing as hell, defeating the point of notebooks
Not to nitpick, but "[...] running C code in your browser" is a little bit of an exaggeration as there is no state-sharing between cells.
It's similar to a webpage that posts C code to a web service and returns the output of its stdout (so like CGI). Not that this is a bad thing, but when I read about stuff running in the browser, I suppose the code to be run by the browser itself, and not just visualizing the output of a program run on some remote server.
Being generous, there is state sharing between cells via (1) the filesystem and shared memory (e.g., /dev/shm), and (2) the C code in cells could link in some common code. Since C starts up quickly, this could still be pretty useful.
Looks like a good way of playing around with ideas. Having context between cells would make it way more useful again.
One thing I'm not sure about is the advice to 'Create branches named issue-X where X is the number of the issue'. Doesn't that make it very difficult to, at a glance, realise which branch implements what feature? I understand the rational of including the issue number, but it seems a shame not to give any other description.
You are right, naming branches this way is not really important and I will probably remove that part. I do not want to add friction to people who want to contribute since I know how painful it is to contribute on certain projects.
I frequently wish the Jupyter notebook server were a C library instead of requiring Python. Would make deployment and installation of notebooks for non-Python languages easier. That's kind of the opposite of this though.
https://github.com/QuantStack/xeus is an (in-development) implementation of the Jupyter protocol in C++, which lets you do kernel computation in any number of libraries that expose an API you can use from C++. Is that the sort of thing you are looking for?
Kind of, though C++ is a difficult language to use from anything other than C++ given there's no standard ABI. Either you need C++ glue-code wrappers around whatever language's FFI you actually want to use, or you embed Clang.
I'm not suggesting you use what I wrote. I'm just pointing out that there exist alternatives to the Python-based Jupyter server that accomplish the same goal. And I strongly agree with you -- it would be great to have even more implementations of the server part of the Jupyter stack!
What is the state of the art concerning security of Jupyter? As it provides in essence a remote shell it's vulnerable to local privilege escalation.
Some people "sandbox" it in Docker (and this is controversial AFAIK), but although I like the notebook UI, I don't want to give people a "native" shell just to do some data exploration.
Most recentlyv they generate a token on startup, which you need to interact with anything. It's fairly seamless on a client computer as the browser that is launched will get that token added automatically.
This is an extension for the Jupyter Notebook [1]. Jupyter Notebook is a tool that allows you to combine runnable computer code, Markdown text, TeX equations and (generated) figures in a single document. It's quite popular in education and data analysis fields in my experience. Most often it is used with Python. This extension allows you to embed and run C code in a notebook document.
29 comments
[ 2.5 ms ] story [ 81.8 ms ] threadI find it invaluable
That might actually work relatively well for simple cases. But I imagine there would be a ton of problematic edge cases, considering that with C you can end up with all sorts of weird stuff.
It's similar to a webpage that posts C code to a web service and returns the output of its stdout (so like CGI). Not that this is a bad thing, but when I read about stuff running in the browser, I suppose the code to be run by the browser itself, and not just visualizing the output of a program run on some remote server.
One thing I'm not sure about is the advice to 'Create branches named issue-X where X is the number of the issue'. Doesn't that make it very difficult to, at a glance, realise which branch implements what feature? I understand the rational of including the issue number, but it seems a shame not to give any other description.
I love org+babel until my entire emacs session hangs because I kicked off an operation that takes time.
Nope.
For C++ I use it for "toy" code. Usually experimenting with some syntax or behavior that is confusing. They tend to be small programs.
I'm not suggesting you use what I wrote. I'm just pointing out that there exist alternatives to the Python-based Jupyter server that accomplish the same goal. And I strongly agree with you -- it would be great to have even more implementations of the server part of the Jupyter stack!
Some people "sandbox" it in Docker (and this is controversial AFAIK), but although I like the notebook UI, I don't want to give people a "native" shell just to do some data exploration.
[1] https://jupyter.org