Interactive GCC (igcc) is a read-eval-print loop (REPL) for C/C++
github.com
github.com
It works by compiling and re-running the whole session each time and assuming that it only printed `n` bytes last time but printed `n+m` bytes this time, that it should only show the user the newest `m` bytes.
From the documentation, it seems this is primarily aimed at incremental compilation on demand via Compiler As A Service.
Indeed, for an end-user, calling this a REPL seems to be a stretch. There's no auto-completion or special commands like showing docs or the checking the type of things, you even have to #include <iostream> to manually print the results of simple expressions.
So I guess read-eval-loop would be more fitting :)
Invoking it with rlwrap makes it a little nicer by giving it readline support.
I think there is a lot of low-hanging fruit for someone to make an IPython-inspired repl around it.
Exciting to see this upstream - something I didn't get around to with ccons which was one of the early prototypes of this built on top of clang (2009). Back then clang C++ support was still being worked on, so ccons targetted C. Later, I collaborated a bit with the Cling folks who I think did take some inspiration from some of my approaches (and likely some of the clang/llvm changes that I landed upstream for supporting functionality / bug fixes). Exiting to see this in the tree now!
https://raw.githubusercontent.com/asvitkine/ccons/master/doc...
In our context Python became popular because it has smartly hidden the complexity via C++ libraries. But while that approach is powerful it is not very flexible (you need to work within the rails of these libraries).
People have tried inventing a new paradigm (julia) that combines usability with performance but it has not struck a chord (yet?). The latest effort being hyped is to double-down on python semantics and build a performant C-like superset (mojo).
The interesting question regarding the ROOT project is whether you can stick close to the C++ universe yet build powerful tools that hide complexity. Its not trivial, e.g. would it automatically make good use of heterogeneous CPU's/GPU'?
But its amusing to think that after CERN taught the world how to share data with the WWW project it might teach us next how to actually work with that data :-)
For any non-scientific purpose, Julia is not attractive, so I doubt it will gain much more traction.
> whether you can stick close to the C++ universe yet build powerful tools that hide complexity. Its not trivial, e.g. would it automatically make good use of heterogeneous CPU's/GPU
That's where we are going. Technically being generic over CPU/GPU (for defined set of operations) is not hard, just takes work (and leaders in this domain are interested in keeping thing proprietary), but that's already work in progress.
In general terms, copying Python usability (or 90% of it) is also simple and other languages head that way. Rust or Nim can come very close (when you have good set of libraries and pass the boilerplate).
https://juliahub.com/case-studies
There have been other interactive environments for C++ that predate ROOT, but they were too resource intensive and the market killed them.
Namely, Energize C++, which came out from Lucid as they pivoted away from Lisp Machines, applying the same kind of technology to C++, based on XEmacs.
https://www.youtube.com/watch?v=pQQTScuApWk
https://dreamsongs.com/Cadillac.html
And the last version of Visual Age for C++, based on the Smalltalk development experience.
http://www.edm2.com/index.php/VisualAge_C%2B%2B_4.0_Review
https://books.google.de/books?id=ZwHxz0UaB54C&pg=PA206&redir...
Later they developed a C++ development environment (C++ compiler, IDE with XEmacs and code infos in an object database).
With the xeus-cling Jupyter Kernel for C/C++, variable redefinitions in subsequent notebook input cells do not raise a compiler warning or error.
There's JsRoot, which may already work with JupyterLite in WASM in a browser tab?
There's a ROOT kernel for Jupyter, too: https://github.com/root-project/root/tree/master/bindings/ju...
Instead of the ROOT Jupyter Kernel, you can just call into ROOT from Python with PyRoot (from a notebook that specifies e.g. ipykernel, xeus-python, or pyodide Jupyter kernels).
"ROOT has its Jupyter Kernel!" (2015) https://root.cern/blog/root-has-its-jupyter-kernel/
IDK if there are Apache Arrow bindings for ROOT?; though there certainly are for C/C++, Python, and other languages
You must install jupyter_console to use Jupyter kernels from the CLI like IPython with ipykernel.
In addition to IPython/Jupyter notebook, jupyterlab, vscode, and vscode.dev+devpod;
awesome-cpp#debug: https://github.com/fffaraz/awesome-cpp#debug
"Debugging a Mixed Python and C Language Stack" (2023) https://news.ycombinator.com/item?id=35710350
ROOT: https://en.wikipedia.org/wiki/ROOT
"Root: CERN's scientific data analysis framework for C++" (2019) because if PyRoot to C++ https://news.ycombinator.com/item?id=20691614 :
`conda install -c conda-forge -y root jupyterlab jupyter_console xeus-cling jupyterlite`
SymPy's lambdify() doesn't support ROOT but does support many other ML and NN frameworks; From "Stem formulas" (2023) https://news.ycombinator.com/item?id=36839748 :
> sympy.utilities.lambdify.lambdify() https://github.com/sympy/sympy/blob/a76b02fcd3a8b7f79b3a88df... :
>> """Convert a SymPy expression into a function that allows for fast numeric evaluation [e.g. the CPython math module, mpmath, NumPy, SciPy, CuPy, JAX, TensorFlow, SymPy, numexpr,]
"jsroot and JupyterLab" https://github.com/root-project/jsroot/issues/166
JupyterLite docs > Create a custom kernel: https://jupyterlite.readthedocs.io/en/stable/howto/extension...
`jupyter lite` builds a set of packages into WASM WebAssembly with emscripten empack.
JupyterLite docs > Configuring the pyodide kernel > Adding wheels https://jupyterlite.readthedocs.io/en/stable/howto/index.htm...
Vscode.dev also supports the pyodide kernel.
Does `pip install root` work in JupyterLite (in the pyodide Python kernel)? Probably not because root is not a plain python package.
- [ ] Create emscripten-forge recipes for JsRoot and root, so that root is usable with the pyodide kernel supported by JupyterLite and pyodide
emscripten-forge recipes are compiled, packaged, and hosted.
emscripten-forge/recipes//recipes/recipes_emscripten/picomamba/recipe.yaml: https://github.com/emscripten-forge/recipes/blob/main/recipe...
It's not that rare that my REPL sessions e.g. in Node are
> perform expensive computation
... result ...
> transform result
... transformed result ...
With this approach, the REPL slows down quadratically with session length, and any expensive command at the beginning is executed over and over again.
Also, better don't do any file I/O and then continue the session unless you're prepared for the consequences.
(Wrong as in "murdering puppies" wrong, not as in "here are the downsides of X" which I believe exist for every X.)
Good enough for your arbitrary standard? I would have thought the fact that all preceding side effects will be re-executed each time a new line is written is bad enough, but whatever.
Are we able to live ethically ?
(Which leads to "What is ethics ?", which eventually leads to " Ethics is nonsensical".)
You'll waste more electricity trying to solve it correctly than it will ever waste.
The real problem to solve would be: how to make GCC, Clang, etc. fast. Or how to make C++'s syntax easy and fast to work with.
Or how to convince people to switch to Rust? ;)
Why nothing at all, of course. A REPL need not be more than a way to test and explore syntax, functions, and logical structures.
> the user experience is REPL-ish and it can help some people learn the _basics_ of the language
PREPLISH exists for Perl ^_^
Huh, that's not really great. You kind of want (1) the REPL to be syntax-aware, and not feed loops into the compiler until they're syntactically complete (with a multi-line editor) and (2) to reject input that causes the overall program to fail to compile.
So a compile wouldn't be attempted if there are obvious unbalanced braces.
Good god.
For your personal project maybe it isn't. On shared or reusable code it's quite problematic.
There are far less distinctive names than those in namespace std. Have you seen remove(), erase(), move(), search(), apply(), hash, format(), etc.?
Not to mention std::operator overloads like == and < that you suddenly drag into overload resolution needlessly, which can bring their own fun into the mix.
> if you are using an IDE, you can check easily
Lots of people don't. And even those who do, don't immediately have the symbol available to go to its definition. It's quite normal to have to wait O(minutes) for semantic analysis to become ready.
> You are basically implying that anything short of full names are a problem which is just not true.
No, very much not so. If you use it on something that's unlikely to collide (like std::cerr), `using std::foo;` is generally fine outside of headers. `using namespace std;` is the one that's problematic.
If they did they wouldn't have these problems of wondering where functions are defined.
Who are these people not using an IDE when working professionally with a team of people? That's a much bigger red flag than putting using namespace std; inside a compilation unit.
If there is ambiguity, then you can just add a std:: in front of a function. This is all within a single compilation unit anyway.
You seem to have completely ignored what I wrote after "even those who do..."? Like I explained, you're not immune to these issues just because you use an IDE.
And to answer your question, it's lots of people at companies whose C++ talent you would (or should) appreciate. And many people use both IDEs and text editors, depending on lots of factors, like the size of the task.
> If there is ambiguity, then you can just add a std:: in front of a function. This is all within a single compilation unit anyway.
Just because it's in a single TU that doesn't mean it won't be somebody else's problem.
First, someone who modifies a header you include will now potentially break your code simply via a name collision. You're making it harder for them to change their code without breaking yours. And you're probably not their only consumer.
Second, you're now doing ADL lookups instead of regular lookups. This can add a ridiculous amount of noise to error messages for widely used identifiers, which will make life much harder for everyone.
Third, not everything results in an ambiguity. The moment someone introduces an overload that happens to be a better match for your lookup, this can silently cause your code to misbehave. It might not be the most common problem but it's sure as heck one of the most painful when you or your teammates eventually get bitten.
That would mean that they are writing their own global functions that collide with the standard library which is a pretty big mistake itself.
Part of knowing the standard library is knowing not to make some function called end() in the global namespace. This really isn't a big deal. It's one of those group think ideas that permeates and lots of these jihads in programming have been totally wrong. This one I think is just blown out of proportion. There is a lot of simplicity in not having huge long lines for every type. Part of this can be done with auto, part of it can be done with aliasing, but an isolated namespace declaration isn't the end of the world.
For end(), sure. But I listed a bunch more names that are way more likely to collide though... remove(), erase(), move(), search(), apply(), hash, format() are way more likely to collide. The fact that you have to pick the most implausible names to make your argument should be enough evidence that it's a strawman.
> That would mean that they are writing their own global functions that collide with the standard library which is a pretty big mistake itself.
No. It just means you're in the same namespace, or a sub-namespace of theirs.
You're also ignoring ADL effects and silent overload resolution changes, which I mentioned already.
> It's one of those group think ideas that permeates and lots of these jihads in programming have been totally wrong.
You've made factual mistakes in a bunch of your arguments -- most recently your misconception that such collisions only happen with the global namespace. Calling this "group think" and "totally wrong" when your arguments rest on incorrect assumptions is not really warranted.
> There is a lot of simplicity in not having huge long lines for every type.
You're arguing as if we don't understand that... despite the fact that I evidently did, as I explained earlier how you could achieve that simplicity by doing "using std::foo;" instead of "using namespace std;", while avoiding the vast majority of the downsides I'm pointing out.
OTOH, what you don't seem to be considering (and which I've been trying to point out) is the various types of friction you're introducing for your coworkers and future maintainers.
> an isolated namespace declaration isn't the end of the world.
"Not end of the world" is a... low bar. Just because a practice isn't the end of the world, that doesn't mean avoiding it isn't a better idea. I've pointed out several reasons why: unintended ADL lookups, ridiculous error message noise, silent misbehavior, name collisions, difficulty of changing dependent code without breakages, etc. And I've pointed out how you can still achieve your goal while mitigating these considerably.
I don't have anything else to add.
Actually I just picked one as an example.
Calling this "group think" and "totally wrong"
I didn't actually say this was 'totally wrong'
what you don't seem to be considering (and which I've been trying to point out) is the various types of friction you're introducing for your coworkers and future maintainers.
I do and it's not that bad. I didn't even say that I do this, just that it isn't the problem that some people think it is. You are having a meltdown over nothing.
You've made factual mistakes
Nope
most recently your misconception that such collisions only happen with the global namespace
I didn't actually say that.
I don't have anything else to add.
That's for the best, because this really isn't worth getting upset about.