Hacker News Reader

Comment by xvilka | Hacker News Reader

Similar to Cling[1] from ROOT.

[1] https://github.com/root-project/cling

The odd part is that this is not just for fun. For many physicists when I was at CERN, a C++ REPL was a commonly used tool to interactively debug analyses to such a degree that many never compiled their code. Back then, I believe, it was some custom implementation included in ROOT (https://root.cern/). I even went out of my way to write C++ code compatible to it just so it could run in that custom C++ REPL implementation, otherwise some colleagues weren't interested in collaborating at all.

As CERN alummi I can attest the same for ATLAS TDAQ folks already in 2003.

Yes, before CLING there was CINT!

Cling has been largely upstreamed as `clang-repl`. All distributions of clang+tools has it now, and unlike Cling this supports the latest Clang features. However Cling still has some special features for GPGPU that `clang-repl` doesn't.

Great to hear, I had to build cling myself a some years before the pandemic for a classroom and each and every time it was a race with A/V software starting to trigger everything when X number of people started running a "new" executable.

Interesting to see that I had a C++ REPL on my system, installed with clang by default, all along.

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 :)

I use it on occasion.

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.

Nice! TIL.

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...

I have a vague sense that in the era of ML/AI hype and the complex Python/C++ stack that makes it all possible, Cling and the ROOT project should somehow be more visible? Is the project missing some VC driven marketing?

People who hype things use Python for coordination and most gruntwork is done by the GPU or C++ libraries anyhow so C++ doesn't help that much in the big picture. (And hype-people probably often aren't technical enough for C++)

I think there is a causality chain that goes something like this: hype people get attracted to where they see popularity, popularity requires exciting usability and results without much investment and such usability requires smart management of complexity (as there is no free lunch).

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 :-)

> People have tried inventing a new paradigm (julia) that combines usability with performance but it has not struck a chord

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).

Julia main focus is scientific computing, and they aren't doing that bad,

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...

Lucid was never developing for Lisp Machines. Their product was a portable Common Lisp system for UNIX machines.

Later they developed a C++ development environment (C++ compiler, IDE with XEmacs and code infos in an object database).

Sure, it is a common error I do referring to all those CL environments as "Lisp Machines".

Lucid CL ran on top of a UNIX/C machine. A Lisp Machine is a whole machine itself.

Being pedantic, I already mentioned that is a common way I wrongly refer to them, hence the quotes.

And then there's cppyy, also with ROOT heritage... https://cppyy.readthedocs.io/en/latest/history.html

Discussions for Cling: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

I used to use Cling on macOS back in 2018 or so. It was really cool for the time.

Xeus-cling is a Jupyter Kernel for C/C++: https://github.com/jupyter-xeus/xeus-cling#a-c-notebook

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 in JupyterLab

"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...

Reply on news.ycombinator.com