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.
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.
Sadly the tool was never merged into mainline, so the feature branch has probaly rotten away by now.
Maybe it's just me, but this is exactly why I'm not a fan of feature branches.
I do like to have local branches which sometimes serve as feature branches. But those are short-lived, so these either make it into mainline within a few days, or are deliberately marked as dead ends. (Or developed into a separate project, but this is very seldom and even then quickly moved into a new repository.)
As an aside, do you know if it is possible to use this to JIT C++ for CUDA kernels?
If no, it is probably doable if a bit hard to generate kernels on the fly.
Can't you achieve that with plain old dlopen etc? I suppose name mangling can be bit of pita if you want to have truly c++ interfaces instead of extern c ones.
I'm totally planning to do something like this for some bulk data processing I have in mind.
Are you aware of NVRTC?
I've used Visual Studio before, and it's an impressive technical achievement, but for personal productivity, I'll take a good REPL any day -- as long as the language supports it.
That said, good REPLs contain a debugger, and good symbolic debuggers contain a REPL, so they're not entirely exclusive.
How does Inspector differentiate itself from embedding cling to an application? It's very interesting to me because I've been trying to get something like an IPython console / IPdb prompt inside Java using Jython for a long time, and I'd very much like to read more about some design decisions in that area.
I'm thinking about to try to use SWIG to create a JNI wrapper for it.
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?