
Inspector – A drop-anywhere C++ REPL - Mic92
https://github.com/inspector-repl/inspector
======
Dangeranger
Injecting a REPL into a given section of code is my favorite means of
debugging and interactively developing. I've gotten into the habit of building
up a class interactively within Emacs and re-evaluating files after they have
been changed.

It feels a bit like test driven development, but much more concrete. When I
don't really know what I want to build, or what is possible, it's a fun way to
spike out some functionality.

Then after you see what sort of path could exist from your interactive session
you can use the code as a scaffold and re-implement the functionality by
writing a test and implementing the code to satisfy it.

~~~
weavie
How well does it work with class redefinition? Do your instances created with
the old definition automatically update to become instances of the new
definition, or do you need to recreate them?

Common Lisp goes to a lot of trouble to ensure old instances automatically
become new instances - given the repl is a first class feature, the whole
language is built around this concept. But with C++ I can't quite picture how
it would work.

~~~
Dangeranger
The variables and references need to be re-initialized. It would be absolutely
amazing if instances updated themselves but I think only Lisps and Smalltalk
are capable of what you are saying. Correct me if I am wrong.

------
jclay
This comes at a good time as it's something I've been looking for. We have a
physics engine and we want to allow users to write custom c++ functions that
can be linked in at run-time. We'd like to allow our users to swap in their
own custom integration or timestep methods for example.

As an aside, do you know if it is possible to use this to JIT C++ for CUDA
kernels?

~~~
Mic92
You probably want to use libcling directly instead.

~~~
saagarjha
From the source code, it looks like that's what this program is using as well.

~~~
ska
Hence "directly", I read it as.

------
kyberias
Do people create stuff like this because they don't have access to good
interactive debuggers? Visual Studio user here.

~~~
Mic92
I tried visual studio once. It does not allow me to include all kinds of code
in the edit-and-compile feature. Also the code I enter in a REPL, I usually
don't want to see in my projects. Finally I miss the intermediate feedback of
printing the values, when I have entered an expression.

------
seletz
Hmm -- I wonder why they chose to not use Jupyter as an REPL "backend"
(Jupyter calls them "kernels").

~~~
bfelds
this exists! recently released: [https://github.com/QuantStack/xeus-
cling](https://github.com/QuantStack/xeus-cling)

~~~
seletz
Oh wow! Even a backend for Jupyter's interactive widgets!

~~~
SylvainCorlay
Check out our blog post on the C++ backend to Jupyter widgets:
[https://blog.jupyter.org/interactive-workflows-for-c-with-
ju...](https://blog.jupyter.org/interactive-workflows-for-c-with-jupyter-
fe9b54227d92)

------
Asooka
How is this better than just attaching GDB?

~~~
Mic92
1\. You can enter arbitrarily C++ code (gdb can only call some functions, it
cannot even instantiate c++ classes) 2\. Variables in Inspector's scope are
never optimized away by the compiler 3\. You can use it with default
optimizations flags (In gdb you often want `-O0 -g`)

~~~
Asooka
1\. GDB can instantiate classes, but it's a bit wonky, I agree. You have to
evaluate malloc manually and then cast the pointer to the right type and call
the constructor. You can write python scripts to automate this.

2\. That's good.

3\. You can generally compile with -Og -g for faster execution while
preserving enough of the program's structure to make sense of what's
happening.

I can see how it can be useful though. Do you have to prebuild every cpp file,
or just the one you put "#include INSPECTOR" in? Can you include inspector in
more than one file?

~~~
Mic92
You only need to prebuild files, where the include statement is included.
Ideally this task would be also automatically done in future by sneaking into
the build system.

------
therein
Very interesting. Does it require a C++17 compiler? Also is there any way to
simply use a different way of interacting with the REPL? For instance over
sockets rather than stdio.

~~~
Mic92
The REPL is a C++17 just-in-time compiler as a library. The project can use a
different compiler. Even C could be supported with some small modifications.
It uses TCP sockets + simple json messages for IPC. The REPL prompt runs in a
different process independent from the program running the REPL. That means,
there could be different frontends added. It also enables multi-process/multi-
threading support.

