5 ms·

Cling – An interactive C++ interpreter built on top of LLVM and Clang

91 points by philonoist 9y ago

fooker 9y ago
How does it differ from using a debugger and evaluating statements on the fly?
- kzrdude 9y ago
  You can load in new code interactively, it has a JIT compiler, and physicists can use it.
- KenoFischer 9y ago
  It's the same kind of technology, though here they actually always load the interpreter into the process even when not used interactively, to allow things like dynamically loading additional code. They also use it to automatically compute file format layouts from C++ struct definitions, and it provides a C++ equivalent of eval(). One thing that I think is under-appreciated in this kind of thing is that a proper C++ repl is significantly less frustrating than a debugger. GDB's C++ mode is at best a poor emulation of the C++ language. LLDB does better because it reconstructs an actual C++ AST and runs it through clang but there's still a ton of limitation (e.g. you can't call any templates or inline functions from header files). Interactive C++ is pretty fun, especially for prototyping. The biggest problem I generally run into is that APIs in C++ are not really designed to be used in that way (esp in libraries whose user's don't use these kinds of tools). Libraries in languages with interactive prompts tend to have APIs designed in such a way that you can get the simple thing done with very little code (one call, only the arguments you need, etc), while in C++ it's a lot more common to expect user's to copy/paste a snippet from the doc and adjust all the options they want to change. That works fine in an editor, but is pretty annoying in a prompt. The other thing I often run into is error handling. A lot of C++ libraries' error handling is to just call abort() (at best) or segfault, which again is mostly fine for a compiled problem, but is annoying in an interactive setting. You can work around that of course by catching the error/resetting state, but even then you often leave libraries in the wrong state.
- saboot 9y ago
  It provides a similar environment to a Jupyter notebook. Building a program as you go and playing around in data. In fact cling provides a Jupyter kernel so you can write C++ in a Jupyter notebook as well.
microcolonel 9y ago
I wish they wouldn't use the word interpreter, because as far as I'm aware this is not an interpreter. REPL would be the correct term, to my knowledge.
- MereInterest 9y ago
  Agreed. As far as I can tell, it compiles each statement into machine code, then executes it. Not at all interpreting. This leads to some interesting bugs, such as a period when it was incompatible with gcc 5 or higher, because the clang backend couldn't yet output code compatible with gcc's new ABI.
smueller1234 9y ago
Having had to deal with the insanity of its predecessor, CINT, a lot, I'm just really happy for all the particle physicists out there who depend on this (and ROOT)! In fact, those of you that are into slightly bizarre code archaeology, have a look at the CINT and pre ROOT code prior to ROOT 6. We used to joke that ROOT was the then primary developer's learning project for migrating from FORTRAN to C++... Despite that, virtually every major contemporary particle physics experiment/analysis relies on ROOT!
- harry8 9y ago
  I've never heard this before. Why? What is it they need from it?
  - ddavis 9y ago
    The development was heavily influenced by what particle physics experiments required (developed at CERN and Fermilab so that makes sense), so the field naturally uses it essentially exclusively. It makes it easy to store C++ classes on disk, so after C++ was adopted as the language of the field post-Fortran, it became the natural tool. The event processing, fitting, and plotting tools were part of that “what particle physics experiments required” line too.
  - tempay 9y ago
    ROOT is very old (older than the first C++ specification) and being able to analyse data interactively and then compile the same for very performance sensitive applications was wonderful. Unfortunately the previous interpreter (CINT) was a unpredictable mess of hacks with vast code bases dependent upon it. Cling has now taken over for most experiments and is much better. For interactive work more and more people are using alternatives like python, but C++ and ROOT are deeply ingrained. Almost all data is stored in the ROOT file format and can only be read using ROOT. The library itself supports many common tasks which don’t have mature alternatives. Both of these points are slowly improving and benefiting from the wider data science community but ROOT will continue to be used for decades to come (the LHC experiments will run until at least mid 2030 with data being analysed for many years after).
Mic92 9y ago
I once started a prototype to integrate cling into a compiled project (like pry in ruby or import pdb; pdb.set_trace() in python). I currently work on different projects, but I would love to see, if somebody else could pick up the idea: https://github.com/inspector-repl/inspector https://github.com/inspector-repl/inspector
deleted 9y ago
[deleted]
ChickeNES 9y ago
There's also ccons: https://github.com/asvitkine/ccons https://github.com/asvitkine/ccons which as far as I can tell is C only, but I find the codebase much easier to follow.
MereInterest 9y ago
Last I checked, it still leaks memory anytime a statement is evaluated [1], which isn't exactly desired behavior for an interpreter. It is much better than its predecessor, CINT, but I still wouldn't use it for anything in production. [1] https://root-forum.cern.ch/t/memory-leak-using-interpreter/23616 https://root-forum.cern.ch/t/memory-leak-using-interpreter/2...
superbatfish 9y ago
One easy way to see it in action is to try it in your browser via the xeus-cling project. [1] The live demo is here: https://mybinder.org/v2/gh/QuantStack/xeus-cling/0.0.7?filepath=notebooks%2Fxcpp.ipynb https://mybinder.org/v2/gh/QuantStack/xeus-cling/0.0.7?filep... [1]: https://github.com/QuantStack/xeus-cling https://github.com/QuantStack/xeus-cling

91 points by philonoist 9y ago

fooker 9y ago

How does it differ from using a debugger and evaluating statements on the fly?

kzrdude 9y ago
You can load in new code interactively, it has a JIT compiler, and physicists can use it.
KenoFischer 9y ago
It's the same kind of technology, though here they actually always load the interpreter into the process even when not used interactively, to allow things like dynamically loading additional code. They also use it to automatically compute file format layouts from C++ struct definitions, and it provides a C++ equivalent of eval(). One thing that I think is under-appreciated in this kind of thing is that a proper C++ repl is significantly less frustrating than a debugger. GDB's C++ mode is at best a poor emulation of the C++ language. LLDB does better because it reconstructs an actual C++ AST and runs it through clang but there's still a ton of limitation (e.g. you can't call any templates or inline functions from header files). Interactive C++ is pretty fun, especially for prototyping. The biggest problem I generally run into is that APIs in C++ are not really designed to be used in that way (esp in libraries whose user's don't use these kinds of tools). Libraries in languages with interactive prompts tend to have APIs designed in such a way that you can get the simple thing done with very little code (one call, only the arguments you need, etc), while in C++ it's a lot more common to expect user's to copy/paste a snippet from the doc and adjust all the options they want to change. That works fine in an editor, but is pretty annoying in a prompt. The other thing I often run into is error handling. A lot of C++ libraries' error handling is to just call abort() (at best) or segfault, which again is mostly fine for a compiled problem, but is annoying in an interactive setting. You can work around that of course by catching the error/resetting state, but even then you often leave libraries in the wrong state.
saboot 9y ago
It provides a similar environment to a Jupyter notebook. Building a program as you go and playing around in data. In fact cling provides a Jupyter kernel so you can write C++ in a Jupyter notebook as well.

microcolonel 9y ago

I wish they wouldn't use the word interpreter, because as far as I'm aware this is not an interpreter. REPL would be the correct term, to my knowledge.

MereInterest 9y ago
Agreed. As far as I can tell, it compiles each statement into machine code, then executes it. Not at all interpreting. This leads to some interesting bugs, such as a period when it was incompatible with gcc 5 or higher, because the clang backend couldn't yet output code compatible with gcc's new ABI.

smueller1234 9y ago

Having had to deal with the insanity of its predecessor, CINT, a lot, I'm just really happy for all the particle physicists out there who depend on this (and ROOT)! In fact, those of you that are into slightly bizarre code archaeology, have a look at the CINT and pre ROOT code prior to ROOT 6. We used to joke that ROOT was the then primary developer's learning project for migrating from FORTRAN to C++... Despite that, virtually every major contemporary particle physics experiment/analysis relies on ROOT!

harry8 9y ago
I've never heard this before. Why? What is it they need from it?
- ddavis 9y ago
  The development was heavily influenced by what particle physics experiments required (developed at CERN and Fermilab so that makes sense), so the field naturally uses it essentially exclusively. It makes it easy to store C++ classes on disk, so after C++ was adopted as the language of the field post-Fortran, it became the natural tool. The event processing, fitting, and plotting tools were part of that “what particle physics experiments required” line too.
- tempay 9y ago
  ROOT is very old (older than the first C++ specification) and being able to analyse data interactively and then compile the same for very performance sensitive applications was wonderful. Unfortunately the previous interpreter (CINT) was a unpredictable mess of hacks with vast code bases dependent upon it. Cling has now taken over for most experiments and is much better. For interactive work more and more people are using alternatives like python, but C++ and ROOT are deeply ingrained. Almost all data is stored in the ROOT file format and can only be read using ROOT. The library itself supports many common tasks which don’t have mature alternatives. Both of these points are slowly improving and benefiting from the wider data science community but ROOT will continue to be used for decades to come (the LHC experiments will run until at least mid 2030 with data being analysed for many years after).

Mic92 9y ago

I once started a prototype to integrate cling into a compiled project (like pry in ruby or import pdb; pdb.set_trace() in python). I currently work on different projects, but I would love to see, if somebody else could pick up the idea: https://github.com/inspector-repl/inspector https://github.com/inspector-repl/inspector

deleted 9y ago

[deleted]

ChickeNES 9y ago

There's also ccons: https://github.com/asvitkine/ccons https://github.com/asvitkine/ccons which as far as I can tell is C only, but I find the codebase much easier to follow.

MereInterest 9y ago

Last I checked, it still leaks memory anytime a statement is evaluated [1], which isn't exactly desired behavior for an interpreter. It is much better than its predecessor, CINT, but I still wouldn't use it for anything in production. [1] https://root-forum.cern.ch/t/memory-leak-using-interpreter/23616 https://root-forum.cern.ch/t/memory-leak-using-interpreter/2...

superbatfish 9y ago

One easy way to see it in action is to try it in your browser via the xeus-cling project. [1] The live demo is here: https://mybinder.org/v2/gh/QuantStack/xeus-cling/0.0.7?filepath=notebooks%2Fxcpp.ipynb https://mybinder.org/v2/gh/QuantStack/xeus-cling/0.0.7?filep... [1]: https://github.com/QuantStack/xeus-cling https://github.com/QuantStack/xeus-cling