Jupyter C Kernel | Hacker News Reader

Jupyter C Kernel

github.com

97 pointsbrendanrius27 comments

This looks like it doesn't share any context between cells, am I right? So I can't use functions defined in one cell in another.

There exists a jupyter kernel for cling, which allows this (also this is C++ not C)

Yes, and it is quite good: https://github.com/root-project/cling#jupyter

I find it invaluable

Here is another one in development: https://github.com/QuantStack/xeus-cling

It does not yet :)

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.

If you protect it appropriately, you've basically re-implemented exec.

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

Huh, a README that doesn't even attempt to explain what the project is.

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.

[1] https://jupyter.org

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.

As much as I love Jupyter, for C/C++, I've found using Org Babel in Emacs much more effective.

Do you have a way to handle the fact that emacs locks up while evaluating code?

I love org+babel until my entire emacs session hangs because I kicked off an operation that takes time.

>Do you have a way to handle the fact that emacs locks up while evaluating code?

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.

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.

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 recently built a complete node.js Jupyter server on top off https://github.com/nteract/spawnteract (also used by nteract). There is no Python involved at all unless you connect to a Python kernel. Some of the code of what I wrote: https://github.com/sagemathinc/cocalc/tree/master/src/smc-pr...

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 makes this a kernel? It appears to be not much more than a wrapper around gcc.

It's a Jupyter kernel, so that you can run C code from a Jupyter Notebook in your browser, like you can with Python, R, etc.

Aha, thanks!

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.

Reply on news.ycombinator.com