root-project / cling Goto Github PK

So, I have embedded cling in to my app. Everything is working well. In particular, I can compile this class:

class MyClass : public LogicComponent
{

public:
	float mTotalTime;

	MyClass(Context* context) : LogicComponent(context),
	mTotalTime(0.0f)
	{
		printf("Hello from Fields!");
	}

	~MyClass(){};	
	static void RegisterComponent(Context* context)

	{
	    context->RegisterFactory<MyClass>();
	}

	virtual void Update (float timeStep) {
		mTotalTime += timeStep;
		GetNode()->SetScale(0.5f * Sin(20.0f * mTotalTime));
	}
};

I now need to register this class with my host application (in particular the Context*). To do this, I would like to call RegisterComponent using something like:

void* addr = mInterpreter->getAddressOfGlobal("RegisterComponent");
using func_t = void(Context*);
func_t* pFunc = cling::utils::VoidToFunctionPtr<func_t*>(addr);

However, this doesn't work because RegisterComponent is a not a global. Can I get the address of such a function?

Having the interpreter exit on an exception, while it makes sense, is very inconvenient when exploring an API, or doign some trial and error work.

It would be nice if there was a way to effectively wrap every line in a try catch block (perhaps with a custom handler, or simply a print out).

Hello @Axel-Naumann ,

(Update: more elaborate example + error msg)

It seems that c++17 structured bindings do not yet work in cling.
Is this indeed the case, or did I setup cling incorrectly ?

#include<iostream>
#include<tuple>

auto t = make_tuple("hi",3);
auto [a,b] = t;
std::cout << a;

input_line_21:2:15: error: use of undeclared identifier 'a'
std::cout << a;

best regards,
niek

"python cpt.py -c" gives me error:

Cling Packaging Tool (CPT)
Arguments vector: ['cpt.py', '-c']

╔══════════════════════════════════════════════════════════════════════════════╗
║ cling (x86_64)                               Tue, 19 Apr 2016 18:32:48 +0800 ║
╚══════════════════════════════════════════════════════════════════════════════╝
Thread Model: POSIX
Operating System: Linux
Distribution: Ubuntu
Release: trusty
Revision: 14.04
Architecture: x86_64

┌──────────────────────────────────────────────────────────────────────────────┐
│ Check availability of required softwares                                     │
└──────────────────────────────────────────────────────────────────────────────┘
git                 [OK]                          
gcc                 [OK]                          
g++                 [OK]                          
debhelper           [OK]                          
subprocess.CalledProcessError: Command 'dpkg-query -W -f='${Status}' devscripts 2>/dev/null | grep -c 'ok installed'' returned non-zero exit status 1



┌──────────────────────────────────────────────────────────────────────────────┐
│ Clean up                                                                     │
└──────────────────────────────────────────────────────────────────────────────┘
Remove directory: /tmp/cling-obj/
Traceback (most recent call last):
  File "cpt.py", line 1390, in <module>
    check_ubuntu('devscripts')
  File "cpt.py", line 452, in check_ubuntu
    elif exec_subprocess_check_output("dpkg-query -W -f='${Status}' %s 2>/dev/null | grep -c 'ok installed'"%(pkg), '/').strip() == '0':
  File "cpt.py", line 89, in exec_subprocess_check_output
    return out
UnboundLocalError: local variable 'out' referenced before assignment

and I ignored this and run,

python cpt.py --current-dev deb

After a long long time compilation,I got:

llvm[4]: Compiling MetaProcessor.cpp for Release+Asserts build
llvm[4]: Compiling DeclCollector.cpp for Release+Asserts build
llvm[4]: Compiling MetaSema.cpp for Release+Asserts build
In file included from /home/alex/ec/build/cling-src/tools/cling/lib/Interpreter/DeclCollector.cpp:10:
/home/alex/ec/build/cling-src/tools/cling/lib/Interpreter/DeclCollector.h:132:18: warning: 
      'cling::DeclCollector::HandleVTable' hides overloaded virtual function [-Woverloaded-virtual]
    virtual void HandleVTable(clang::CXXRecordDecl* RD);
                 ^
/home/alex/ec/build/cling-src/tools/cling/lib/Interpreter/../../../clang/include/clang/AST/ASTConsumer.h:136:16: note: 
      hidden overloaded virtual function 'clang::ASTConsumer::HandleVTable' declared here: different number of
      parameters (2 vs 1)
  virtual void HandleVTable(CXXRecordDecl *RD, bool DefinitionRequired) {}
               ^
llvm[4]: Compiling DeclExtractor.cpp for Release+Asserts build
/home/alex/ec/build/cling-src/tools/cling/lib/Interpreter/DeclCollector.cpp:201:19: error: no member named
      'HandleInvalidTagDeclDefinition' in 'clang::ASTConsumer'; did you mean 'HandleTagDeclDefinition'?
      m_Consumer->HandleInvalidTagDeclDefinition(TD);
                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                  HandleTagDeclDefinition
/home/alex/ec/build/cling-src/tools/cling/lib/Interpreter/../../../clang/include/clang/AST/ASTConsumer.h:75:16: note: 
      'HandleTagDeclDefinition' declared here
  virtual void HandleTagDeclDefinition(TagDecl *D) {}
               ^
/home/alex/ec/build/cling-src/tools/cling/lib/Interpreter/DeclCollector.cpp:212:34: error: too few arguments to
      function call, expected 2, have 1
      m_Consumer->HandleVTable(RD);
      ~~~~~~~~~~~~~~~~~~~~~~~~   ^
/home/alex/ec/build/cling-src/tools/cling/lib/Interpreter/../../../clang/include/clang/AST/ASTConsumer.h:136:3: note: 
      'HandleVTable' declared here
  virtual void HandleVTable(CXXRecordDecl *RD, bool DefinitionRequired) {}
  ^
1 warning and 2 errors generated.
make[4]: *** [/home/alex/ec/build/builddir/tools/cling/lib/Interpreter/Release+Asserts/DeclCollector.o] Error 1
make[4]: *** Waiting for unfinished jobs....
llvm[4]: Building Release+Asserts Archive Library libclingMetaProcessor.a
make[4]: Leaving directory `/home/alex/ec/build/builddir/tools/cling/lib/MetaProcessor'
make[4]: Leaving directory `/home/alex/ec/build/builddir/tools/cling/lib/Interpreter'
make[3]: *** [Interpreter/.makeall] Error 2
make[3]: Leaving directory `/home/alex/ec/build/builddir/tools/cling/lib'
make[2]: *** [all] Error 1
make[2]: Leaving directory `/home/alex/ec/build/builddir/tools/cling'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/alex/ec/build/builddir/tools'
make: *** [all] Error 1
subprocess.CalledProcessError: Command 'make -j4' returned non-zero exit status 2



┌──────────────────────────────────────────────────────────────────────────────┐
│ Clean up                                                                     │
└──────────────────────────────────────────────────────────────────────────────┘
Remove directory: /home/alex/ec/build/builddir
Remove directory: /tmp/cling-obj/
Create output directory: /home/alex/ec/build/cling-0.2~dev-bb7b609-1

And I have below gcc and llvm installed

gcc version 4.8.5
llvm-3.9
clang-3.9

I installed cling using the Scientific Linux binary in CentOS 7 and I am getting the following error in my Jupyter Notebook when I try a simple include. Does anyone have any ideas what might be the cause? Am I missing an environmental variable of some sort? I have glibc-devel and glibc-devel.i686 installed. Any help would be greatly appreciated, thanks!

In file included from input_line_3:1:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/iostream:39:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/ostream:38:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/ios:38:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/iosfwd:39:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stringfwd.h:40:
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/memoryfwd.h:52:1: error: unknown type name '_GLIBCXX_BEGIN_NAMESPACE_VERSION'
_GLIBCXX_BEGIN_NAMESPACE_VERSION
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/memoryfwd.h:63:3: error: expected unqualified-id
template
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/memoryfwd.h:67:11: error: explicit specialization of non-template class 'allocator'
class allocator;
^ ~~~~~~
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/memoryfwd.h:75:1: error: unknown type name '_GLIBCXX_END_NAMESPACE_VERSION'
_GLIBCXX_END_NAMESPACE_VERSION
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/memoryfwd.h:76:1: error: expected unqualified-id
} // namespace std
^
In file included from input_line_3:1:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/iostream:39:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/ostream:38:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/ios:38:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/iosfwd:39:
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stringfwd.h:44:1: error: unknown type name '_GLIBCXX_BEGIN_NAMESPACE_VERSION'
_GLIBCXX_BEGIN_NAMESPACE_VERSION
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stringfwd.h:52:3: error: expected unqualified-id
template
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stringfwd.h:55:48: error: unknown type name 'char_traits'
template<typename _CharT, typename _Traits = char_traits<_CharT>,
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stringfwd.h:55:59: error: expected ',' or '>' in template-parameter-list
template<typename _CharT, typename _Traits = char_traits<_CharT>,
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stringfwd.h:55:67: error: expected unqualified-id
template<typename _CharT, typename _Traits = char_traits<_CharT>,
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stringfwd.h:59:21: error: explicit specialization of non-template struct 'char_traits'
template<> struct char_traits;
^ ~~~~~~
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stringfwd.h:62:11: error: unknown type name 'basic_string'
typedef basic_string string;
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stringfwd.h:62:23: error: expected unqualified-id
typedef basic_string string;
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stringfwd.h:65:21: error: explicit specialization of non-template struct 'char_traits'
template<> struct char_traits<wchar_t>;
^ ~~~~~~~~~
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stringfwd.h:68:11: error: unknown type name 'basic_string'
typedef basic_string<wchar_t> wstring;
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stringfwd.h:68:23: error: expected unqualified-id
typedef basic_string<wchar_t> wstring;
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stringfwd.h:86:1: error: unknown type name '_GLIBCXX_END_NAMESPACE_VERSION'
_GLIBCXX_END_NAMESPACE_VERSION
^
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/stringfwd.h:87:1: error: expected unqualified-id
} // namespace std
^
In file included from input_line_3:1:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/iostream:39:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/ostream:38:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/ios:38:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/iosfwd:40:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/postypes.h:40:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/cwchar:44:
In file included from /usr/include/wchar.h:51:
/opt/lib/clang/3.7.0/include/stddef.h:62:9: error: unknown type name 'SIZE_TYPE'
typedef SIZE_TYPE size_t;
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]

So, when using the cling interpreter from the command line, I can run the following commands with no problem:

[cling]$ .L C:/Dev/Urho3D/Build/shared/bin/Urho3D.dll
[cling]$ .I C:/Dev/Urho3D/Build/shared/include
[cling]$ .I C:/Dev/Urho3D/Build/shared/include/Urho3D/ThirdParty
[cling]$ #include <Urho3D/Urho3DAll.h>

I have also successfully embedded cling in to my own exe (by following the example code). However, when I create the Interpreter and run those same commands like this:

	cling::Interpreter interp(argc, argv, LLVMDIR);
	interp.AddIncludePath(".");
	//load urho dll
	interp.loadLibrary("C:/Dev/Urho3D/Build/shared/bin/Urho3D.dll");
	interp.AddIncludePath("C:/Dev/Urho3D/Build/shared/include");
	interp.AddIncludePath("C:/Dev/Urho3D/Build/shared/include/Urho3D/ThirdParty");
	interp.loadHeader("Urho3D/Urho3DAll.h");

I get a bunch of type redefinition errors....

Any thoughts on this? I feel like I'm missing some preprocessor/compile flags.

Moving suggestion from another issue here: #12 (comment)

The idea is to document the following steps:

1. Choose a C++ project that uses CMake as its build system
2. Adjust build scripts to generate precompiled headers as suggested here: #12 (comment)
3. Show how to run cling with these headers
4. Do something simple in cling to demonstrate that it's working.

This should allow new users of cling to start using it faster and easier.

So, I have successfully compiled and tested cling on windows (Windows 10 x64). Writing some code works and it all seems fine. However, when I try to include a library:

cling .L C:/path/to/mylib.lib

I get a bunch of errors. There seem to by two main kinds. Initially, it outputs:

C:\Dev\cling-test\build\Release\api-test.lib:1:1: error: expected unqualified-id
!<arch>
^

and then I get many many lines of:

C:\Dev\cling-test\build\Release\api-test.lib:7:36: warning: null character ignored [-Wnull-character]

Any hints?

Hello,
first of all, great project, thanks for all the amazing work you've done.

Now, I get some issues with cling on jupyter.
In all the issues described below, the kernel crashes after running a cell.

I've installed the 3 kernels c++11, c++14 and c++17.
C++17 gives out the error

error: invalid value 'c++17' in '-std=c++17'
[ClingKernelApp] ERROR | UNKNOWN MESSAGE TYPE: 'comm_open'
[ClingKernelApp] ERROR | UNKNOWN MESSAGE TYPE: 'comm_open'

I guess this is related to mac's LLVM version, or c++17 support. Any workarounds to support c++17?

Using the other kernels results in:

$jupyter notebook
[I 13:01:34.197 NotebookApp] Serving notebooks from local directory: 
...
[I 13:01:34.197 NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
[C 13:01:34.216 NotebookApp] 
    
    Copy/paste this URL into your browser when you connect for the first time,
    to login with a token:
        http://localhost:8888/?token=760e2f222b86ee6e84814c1c6f712d8568f0f32d6ab5d037
[I 13:01:35.696 NotebookApp] Accepting one-time-token-authenticated connection from ::1
[I 13:02:04.864 NotebookApp] Kernel started: b186650d-400c-424f-afc8-63ccb6c88286
[W 13:02:05.054 NotebookApp] 404 GET /nbextensions/canopy/training/exercise.js?v=20170319130129 (::1) 138.25ms referer=http://localhost:8888/notebooks/cpp_katas/Untitled.ipynb
[W 13:02:05.803 NotebookApp] 404 GET /nbextensions/widgets/notebook/js/extension.js?v=20170319130129 (::1) 3.02ms referer=http://localhost:8888/notebooks/cpp_katas/Untitled.ipynb
[ClingKernelApp] ERROR | UNKNOWN MESSAGE TYPE: 'comm_open'
[ClingKernelApp] ERROR | UNKNOWN MESSAGE TYPE: 'comm_open'
Assertion failed: nbytes == sizeof dummy (bundled/zeromq/src/signaler.cpp:196)
[I 13:02:25.866 NotebookApp] KernelRestarter: restarting kernel (1/5)
WARNING:root:kernel b186650d-400c-424f-afc8-63ccb6c88286 restarted

Where a simple function, with includes divided in a previous cell

#include <iostream>
#include <vector>

using namespace std;
int min(vector<int> list) {
  return *(min_element(list.begin(), list.end()));
}

Gives this error on the notebook

input_line_4:4:27: error: function definition is not allowed here
int min(vector<int> list) {
                          ^

Also, I've noticed this on the console

[ClingKernelApp] ERROR | UNKNOWN MESSAGE TYPE: 'comm_open'
Assertion failed: nbytes == sizeof dummy (bundled/zeromq/src/signaler.cpp:196)

Several function definitions give this out. Sometimes one that was working, so it's a bit random I think.

As said in the beginning, running a cell, maybe two, crashes the kernel abruptly.

Any ideas?

Thanks!

can I install cling via conda?

I'm comparing cling vs xeus-cling and the latter has conda installation which is really convenient.

Thanks,

C++ types can become rather long, which tends, when displaying outputs in cling, to bury down the actual value:

[cling]$ #include <vector>
[cling]$ using namespace std;
[cling]$ vector<vector<int>> v = {{1,2},{3,4}};
[cling]$ v[0]
(__gnu_cxx::__alloc_traits<std::allocator<std::vector<int, std::allocator<int> > > >::value_type &) { 1, 2 }

Is this something that could be improved or made configurable?

Just thinking out loud, here are some potential strategies:

• display the value first and then the type. So if one only cares about the value one can skip reading the type entirely
• In an environment like Jupyter+xeus-cling: visually highlight the type on one hand and the output on the other hand
• Shorten long types with ...
• (when the type is long), write the type and the output on two
  different lines; possibly with the value raged left and the type
  ragged right

I am not sure whether this is a question for cling in general, or
cling in Jupyter in particular.

cc: @gouarin, @SylvainCorlay

Context: see #187 for the teaching context. One reason we chose C++
over, e.g., Python is that we believe being explicit with types helps
our students better understand what they are calculating with. That in
addition clings displays the type of the outputs is quite a killer
feature for them. This also help teach them the distinction between
printing a value and returning a value.

However long types as above, which naturally pop up in C++ without
relating straightforwardly (for a beginner) to the input types, are
just confusing to them. The current display makes it hard for them to
skip them and focus on the value itself, which is the only piece of
information they actually can grasp at this stage.

After troubleshooting the following:

Traceback (most recent call last):
  File "/usr/local/bin/jupyter-cling-kernel", line 6, in <module>
    exec(compile(open(__file__).read(), __file__, 'exec'))
  File "/Users/browneej/workspace/cling/src/tools/cling/tools/Jupyter/kernel/scripts/jupyter-cling-kernel", line 4, in <module>
    main()
  File "/Users/browneej/workspace/cling/src/tools/cling/tools/Jupyter/kernel/clingkernel.py", line 290, in main
    ClingKernelApp.launch_instance()
  File "/usr/local/lib/python3.5/site-packages/traitlets/config/application.py", line 588, in launch_instance
    app.initialize(argv)
  File "<decorator-gen-122>", line 2, in initialize
  File "/usr/local/lib/python3.5/site-packages/traitlets/config/application.py", line 74, in catch_config_error
    return method(app, *args, **kwargs)
  File "/usr/local/lib/python3.5/site-packages/ipykernel/kernelapp.py", line 421, in initialize
    self.init_kernel()
  File "/usr/local/lib/python3.5/site-packages/ipykernel/kernelapp.py", line 360, in init_kernel
    user_ns=self.user_ns,
  File "/usr/local/lib/python3.5/site-packages/traitlets/config/configurable.py", line 404, in instance
    inst = cls(*args, **kwargs)
  File "/Users/browneej/workspace/cling/src/tools/cling/tools/Jupyter/kernel/clingkernel.py", line 87, in __init__
    if not self.libclingJupyter:
AttributeError: 'ClingKernel' object has no attribute 'libclingJupyter'

I found libclingJupyter.dylib in /usr/local/lib/clang/lib/ instead of /usr/local/lib/cling/lib, where the system expected it:

def __init__(self, **kwargs):
        super(ClingKernel, self).__init__(**kwargs)
        whichCling = shutil.which('cling')
        if whichCling:
            clingInstDir = os.path.dirname(os.path.dirname(whichCling))
            llvmResourceDir = clingInstDir
        else:
            raise RuntimeError('Cannot find cling in $PATH. No cling, no fun.')

        for ext in ['so', 'dylib', 'dll']:
            libFilename = clingInstDir + "/lib/libclingJupyter." + ext
            if os.access(libFilename, os.X_OK):
                self.libclingJupyter = ctypes.CDLL(clingInstDir + "/lib/libclingJupyter." + ext,
                                                   mode = ctypes.RTLD_GLOBAL)
                break

        if not self.libclingJupyter:
            raise RuntimeError('Cannot find ' + clingInstDir + '/lib/libclingJupyter.{so,dylib,dll}')

https://github.com/root-mirror/cling/blob/master/tools/Jupyter/kernel/clingkernel.py
cc2ca03

for me, either which cling in bash or whichCling = shutil.which('cling') in python return /usr/local/lib/cling.

I installed using cmake:

cmake -DCMAKE_INSTALL_PREFIX=/usr/local/lib/cling -DLLVM_TARGETS_TO_BUILD=CppBackend\;X86 -DCMAKE_BUILD_TYPE=Debug ../src

after removing CBackend\;

I get the error below when i build cling with cmake and dynamic libs

root@c41441cfa637:/srv/jupyterhub# cling                                
cling::IncrementalExecutor: unable to find target:
Unable to find target for this triple (no targets are registered)Segmentation fault (core dumped)
root@c41441cfa637:/srv/jupyterhub# ldd /usr/local/bin/cling 
    linux-vdso.so.1 (0x00007ffd1fb80000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f8d3b085000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8d3ae81000)
    libatomic.so.1 => /usr/lib/x86_64-linux-gnu/libatomic.so.1 (0x00007f8d3ac79000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8d3aa5c000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f8d3a841000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8d3a535000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8d3a234000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8d3a01e000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8d39c72000)
    /lib64/ld-linux-x86-64.so.2 (0x000055d6c82cf000)
root@c41441cfa637:/srv/jupyterhub# ls /usr/local/lib/*.so               
/usr/local/lib/BugpointPasses.so  /usr/local/lib/libLTO.so    /usr/local/lib/libclingJupyter.so
/usr/local/lib/LLVMHello.so   /usr/local/lib/libclang.so
root@c41441cfa637:/srv/jupyterhub# cling                                
cling::IncrementalExecutor: unable to find target:
Unable to find target for this triple (no targets are registered)Segmentation fault (core dumped)
root@c41441cfa637:/srv/jupyterhub# ldd /usr/local/bin/cling 
    linux-vdso.so.1 (0x00007ffd1fb80000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f8d3b085000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8d3ae81000)
    libatomic.so.1 => /usr/lib/x86_64-linux-gnu/libatomic.so.1 (0x00007f8d3ac79000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8d3aa5c000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f8d3a841000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8d3a535000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8d3a234000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8d3a01e000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8d39c72000)
    /lib64/ld-linux-x86-64.so.2 (0x000055d6c82cf000)
root@c41441cfa637:/srv/jupyterhub# ls /usr/local/lib/*.so               
/usr/local/lib/BugpointPasses.so  /usr/local/lib/libLTO.so    /usr/local/lib/libclingJupyter.so
/usr/local/lib/LLVMHello.so   /usr/local/lib/libclang.so

Installed cling from https://root.cern.ch/download/cling/cling_2016-05-01_mac1011.tar.bz2 to ~/.local
and kernel from https://root.cern.ch/download/cling/cling_2016-05-01_sources.tar.bz2/src/tools/cling/tools/Jupyter/kernel with python3 -m pip install -e .

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.11.4

$ jupyter --version
4.1.0

Cling works just fine
Tried to run kernel and got error

Warning in cling::IncrementalParser::CheckABICompatibility():
  C++ ABI mismatch, compiled with _LIBCPP_VERSION v1101 running with v3700
input_line_2:1:10: fatal error: 'cling/Interpreter/RuntimeUniverse.h' file not found
#include "cling/Interpreter/RuntimeUniverse.h"
         ^
[ClingKernelApp] ERROR | UNKNOWN MESSAGE TYPE: 'comm_open'

-DLLVM_TARGETS_TO_BUILD=CBackend\;CppBackend\;X86 \
->

-- Constructing LLVMBuild project information
CMake Error at CMakeLists.txt:414 (message):
  Unexpected failure executing llvm-build: Usage: llvm-build [options]



  llvm-build: error: invalid target to enable: 'CBackend' (not in project)

When I open a c++17 notebook in jupyter, the kernel died immediately.

The kernel has died, and the automatic restart has failed. It is possible the kernel cannot be restarted. If you are not able to restart the kernel, you will still be able to save the notebook, but running code will no longer work until the notebook is reopened.

The installation steps that I follow is: https://github.com/root-project/cling/tree/master/tools/Jupyter

both ./cpt.py --last-stable=pkg and ./cpt.py --current-dev=pkg fail on Ubuntu 14.04 (LXC user-space container) with the following error:

adam@testy:~/tmp/cling/tools/packaging$ ./cpt.py --last-stable=pkg
Cling Packaging Tool (CPT)
Arguments vector: ['./cpt.py', '--last-stable=pkg']

╔══════════════════════════════════════════════════════════════════════════════╗
║ cling (x86_64)                               Sun, 17 Jul 2016 11:27:55 +0000 ║
╚══════════════════════════════════════════════════════════════════════════════╝
Thread Model: POSIX
Operating System: Linux
Distribution: Ubuntu
Release: trusty
Revision: 14.04
Architecture: x86_64

┌──────────────────────────────────────────────────────────────────────────────┐
│ Fetch source files                                                           │
└──────────────────────────────────────────────────────────────────────────────┘
Last known good LLVM revision is: 272382
Current working directory is: /home/adam/ec/build

Fetching LLVM ...
  HTTP request sent, awaiting response ... 
  Connected to https://github.com/vgvassilev/llvm/archive/cling-patches-r272382.tar.gz [200 OK]
  Downloading: cling-patches-r272382.tar.gz Bytes: 25738031
   25738031  [100.00%]
Extracting: /home/adam/ec/build/cling-patches-r272382.tar.gz
Remove file: /home/adam/ec/build/cling-patches-r272382.tar.gz

Fetching Clang ...
  HTTP request sent, awaiting response ... 
  Connected to https://github.com/vgvassilev/clang/archive/cling-patches-r272382.tar.gz [200 OK]
  Downloading: cling-patches-r272382.tar.gz Bytes: 14134271
   14134271  [100.00%]
Extracting: /home/adam/ec/build/cling-patches-r272382.tar.gz
Remove file: /home/adam/ec/build/cling-patches-r272382.tar.gz

Last stable Cling release detected:  v0.2
Cloning into 'cling'...
remote: Counting objects: 21035, done.
remote: Total 21035 (delta 0), reused 0 (delta 0), pack-reused 21035
Receiving objects: 100% (21035/21035), 15.32 MiB | 1.82 MiB/s, done.
Resolving deltas: 100% (15502/15502), done.
Checking connectivity... done.
Note: checking out 'v0.2'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 2b41279... Prepare to release cling v0.2

┌──────────────────────────────────────────────────────────────────────────────┐
│ Set Cling version                                                            │
└──────────────────────────────────────────────────────────────────────────────┘
Version: 0.2
Revision: 2b4127974452e1999c8fa6c99fe82147098065e9

┌──────────────────────────────────────────────────────────────────────────────┐
│ Configure Cling with GNU Make                                                │
└──────────────────────────────────────────────────────────────────────────────┘
################################################################################
################################################################################
The LLVM project no longer supports building with configure & make.

Please migrate to the CMake-based build system.
For more information see: http://llvm.org/docs/CMake.html
################################################################################
################################################################################
subprocess.CalledProcessError: Command '/home/adam/ec/build/cling-src/configure --disable-compiler-version-checks --with-python=/usr/bin/python --enable-targets=host --prefix=/tmp/cling-obj/ --enable-optimized=yes --enable-cxx11' returned non-zero exit status 1



┌──────────────────────────────────────────────────────────────────────────────┐
│ Clean up                                                                     │
└──────────────────────────────────────────────────────────────────────────────┘
Remove directory: /home/adam/ec/build/builddir
Remove directory: /tmp/cling-obj/

When evaluating the first cell of a notebook, I get the following error:

Exception in thread Thread-3:
Traceback (most recent call last):
  File "/usr/lib/python3.5/threading.py", line 914, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.5/threading.py", line 862, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.5/site-packages/clingkernel.py", line 159, in publish_pipe_output
    data = self._recv_dict(self.output_pipe)
  File "/usr/lib/python3.5/site-packages/clingkernel.py", line 132, in _recv_dict
    value = os.read(pipe, len_value).decode('utf8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc2 in position 18: invalid continuation byte

The error only occurs when evaluating the first cell, the other cells do not show the message afterwards. Trying to dig a bit, modifying the code where the exception occurs as:

    def _recv_dict(self, pipe):
        """Receive a serialized dict on a pipe

        Returns the dictionary.
        """
        # Wire format:
        #   // Pipe sees (all numbers are longs, except for the first):
        #   // - num bytes in a long (sent as a single unsigned char!)
        #   // - num elements of the MIME dictionary; Jupyter selects one to display.
        #   // For each MIME dictionary element:
        #   //   - length of MIME type key
        #   //   - MIME type key
        #   //   - size of MIME data buffer (including the terminating 0 for
        #   //     0-terminated strings)
        #   //   - MIME data buffer
        data = {}
        b1 = os.read(pipe, 1)
        sizeof_long = struct.unpack('B', b1)[0]
        if sizeof_long == 8:
            fmt = 'Q'
        else:
            fmt = 'L'
        buf = os.read(pipe, sizeof_long)
        num_elements = struct.unpack(fmt, buf)[0]
        for i in range(num_elements):
            buf = os.read(pipe, sizeof_long)
            len_key = struct.unpack(fmt, buf)[0]
            key = os.read(pipe, len_key).decode('utf8')
            buf = os.read(pipe, sizeof_long)
            len_value = struct.unpack(fmt, buf)[0]
            #value = os.read(pipe, len_value).decode('utf8')
            #data[key] = value
            try:
                buf = os.read(pipe, len_value)
                value = buf.decode('utf8')
                data[key] = value
                break
            except :
                value = buf.decode('utf8','replace')
                self.session.send(self.iopub_socket, 'display_data',
                    content={
                        'data':{
                            key:"error reading value : %d/%d %s : %d %s" %(i, num_elements, key, len_value, value),
                        },
                        'metadata':{},
                    },
                    parent=self._parent_header,
                )
                raise
        return data

I have the following output in the notebook:

error reading value : 0/1 text/html : 7168 [<garbage characters>]

The garbage characters vary from run to run, but the other fields keep their value. It seems to me that when the kernel starts, the initial data sent to the pipe cannot be read properly. If I remove the raise, the message appears at each cell evaluation.

I installed jupyter and cling through archlinux user repository. Removing line 124 from tools/Jupyter/Kernel.cpp:

cling::Jupyter::pushOutput({{"text/html", "You just executed C++ code!"}});

It seems that I no longer have the error.

Hi,

When using find_package(cling) and linking with clingInterpreter, clingUtils and clingMetaProcessor, I got a lot of unresolved external symbol errors.

The workaround is to link with the following libraries: clangAnalysis, clangEdit and LLVMCoverage. On Windows, I also need to link with Version.

However, I guess these libraries should be added to the INTERFACE_LINK_LIBRARIES property of the cling targets.

For introducing students to vectors in C++ [1], it's a really nice feature that vectors get displayed nicely in Cling:

[cling]$ vector<int> v = { 4, 5, 6 }
[cling]$ v
(std::vector<int> &) { 4, 5, 6 }

This lets them manipulate their vectors interactively and easily monitor how they evolve.

Sadly, for vectors of vectors, which are one step above for them to grasp, that feature is not available anymore. Only the address of the inner vectors are printed out:

[cling]$ vector<vector<int>> v = {{1,2},{3,4}};
[cling]$ v
(std::vector<std::vector<int> > &) { @0x476e0f0, @0x476e108 }

So they have to inspect each subvector one by one; in addition their long type makes them harder to read:

[cling]$ v[0]
(__gnu_cxx::__alloc_traits<std::allocator<std::vector<int, std::allocator<int> > > >::value_type &) { 1, 2 }

Is there a specific reason to just display addresses, or is it just not implemented, and you would consider a change to something like:

(std::vector<std::vector<int> > &) { {1, 2}, {3, 4} }

(and I guess, in general, displaying vectors and possibly other containers recursively).

Thanks,

Cheers,
Nicolas

cc: @gouarin, @SylvainCorlay

[1] Context: we have been using cling (via Jupyter+xeus-cling) for our
300 students introductory C++ class
this Fall. This was a bit of bleeding edge technology, but altogether
we believe it's been a very nice and engaging learning environment for
our students. Next year will be even better when the various glitches
will be ironed out.

Hello, i hope someone can help.

I installed Cling using simply this script

https://raw.github.com/karies/cling-all-in-one/master/clone.sh

I also added Cling to my PATH variable (in .bashrc), and can run stuff like this

cling '#include <stdio.h>' 'printf("Hello World!\n")'

Next I open my activate my virtualenv with Python 3.5.0 where Jupyter is installed (There is no Jupyter in my operating systems python3). There is no problem with Jupyter/Python3 within a virtualenv bcoz I am using it everyday. There is also not a problem with PATH and cling within the virtualenv (I can call call "cling" within the virtualenv).

If i am trying to install cling in jupyter
source /locationofmyvirtualenv/bin/activate
jupyter kernelspec install cling

I get the following error message

...
(venv-3.5.0)username@hostname:~$ jupyter kernelspec install cling
Traceback (most recent call last):
  File "/locationofmyvirtualenv/bin/jupyter-kernelspec", line 11, in 
    sys.exit(KernelSpecApp.launch_instance())
  File "/locationofmyvirtualenv/lib/python3.5/site-packages/traitlets/config/application.py", line 589, in launch_instance
    app.start()
  File "/locationofmyvirtualenv/lib/python3.5/site-packages/jupyter_client/kernelspecapp.py", line 209, in start
    return self.subapp.start()
  File "/locationofmyvirtualenv/lib/python3.5/site-packages/jupyter_client/kernelspecapp.py", line 138, in start
    replace=self.replace,
  File "/locationofmyvirtualenv/lib/python3.5/site-packages/jupyter_client/kernelspec.py", line 208, in install_kernel_spec
    shutil.copytree(source_dir, destination)
  File "/locationofmyvirtualenv/lib/python3.5/shutil.py", line 303, in copytree
    names = os.listdir(src)
FileNotFoundError: [Errno 2] No such file or directory: 'cling'
... 

A user is not allowed to delete the src directroy after installation. In case he deletes the dir Jubpiter will
refuse to load the cling kernel.

1 FROM obiwahn/jupyterhub_notebook:latest
2
3 # install packages
4 RUN apt-get update &&
5 apt-get install -y vim groff cmake libboost-all-dev &&
6 apt-get clean
7
8 # build and install cling
9 RUN cd /srv &&
10 mkdir cling-build &&
11 git clone http://root.cern.ch/git/llvm.git cling-src &&
12 cd /srv/cling-src &&
13 git checkout cling-patches &&
14 cd /srv/cling-src/tools &&
15 git clone https://github.com/ObiWahn/cling.git &&
16 git clone http://root.cern.ch/git/clang.git &&
17 cd /srv/cling-src/tools/clang &&
18 git checkout cling-patches &&
19 cd /srv/cling-build &&
20 cmake -DCMAKE_INSTALL_PREFIX=/usr/local
21 -DLLVM_TARGETS_TO_BUILD=CppBackend;X86
22 -DCMAKE_BUILD_TYPE=Debug
23 ../cling-src &&
24 make -j $(nproc) &&
25 make install &&
26 cd /srv/cling-src/tools/cling/tools/Jupyter/kernel &&
27 pip install -e . &&
28 jupyter kernelspec install cling &&
29 rm -fr /srv/cling-build
30
31 # git clone http://root.cern.ch/git/cling.git &&
32
33 # After installing we must not delete the src folder if we
34 # want to use cling in jupyter
35 # &&
36 # rm -fr /srv/cling-src

I have been trying to integrate the cling interpreter into my project on Ubuntu 16.04 LTS.

After building and installing the LLVM tree. I successfully link my application. but on run-time I get the following error followed by a crash:

: CommandLine Error: Option 'help-list' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options

I followed the $Check out the sources$ step and after executing cmake (3.6.0) I've got the following error:

adam@testy:~/tmp/src$ cmake -DCMAKE_INSTALL_PREFIX=~/tmp/install           -DLLVM_TARGETS_TO_BUILD=host           -DCMAKE_BUILD_TYPE=Debug           ../src
CMake Error at CMakeLists.txt:164 (message):
  In-source builds are not allowed.

  CMake would overwrite the makefiles distributed with LLVM.

  Please create a directory and run cmake from there, passing the path

  to this source directory as the last argument.

  This process created the file `CMakeCache.txt' and the directory
  `CMakeFiles'.

  Please delete them.


-- Configuring incomplete, errors occurred!
See also "/home/adam/tmp/src/CMakeFiles/CMakeOutput.log".
adam@testy:~/tmp/src$ 

This following example doesn't work in cling (tested with cling 3.0 and cling 0.5-dev)

****************** CLING ******************
* Type C++ code and press enter to run it *
*             Type .q to exit             *
*******************************************
[cling]$ #include <iostream>
[cling]$ struct foo
[cling]$ {
[cling]$ ?       double x;
[cling]$ ?   };
[cling]$ std::ostream& operator<<(std::ostream &output, foo f){
[cling]$ ?       output << f.x;
[cling]$ ?       return output;
[cling]$ ?   }
input_line_6:2:55: error: function definition is not allowed here
 std::ostream& operator<<(std::ostream &output, foo f){

It would be nice to make it easy to print the type of an expression (e.g. std::remove_pointer<int*>::type). This would make it easy to experiment with meta-programming inside cling. Given that an expression just containing a type has no useful meaning (warning: declaration does not declare anything), it would be nice if that would print the type (instead or with the warning). Alternative some other syntax such as ".T type" or some helper function e.g. "printType()" would be nice.

I wrote such a helper function myself and noticed that

[cling]$ #include "cling/Utils/Platform.h"
[cling]$ cling::utils::platform::Demangle(typeid(int*).name())
(std::string) "int*\0"

The output contains the null at the end. This seems like a bug.
This is with 0.4~dev

Hi,

Maybe I'm just doing something wrong... But if I try to use metaprocessor commands in Jupyter like

.L libapophenia

I get an error

input_line_22:2:2: error: expected expression
 .L libapophenia

All works well in cling launched from command line.

Is it possible to setup Cling for C++17/experimental?

Hi,

I'm playing with lambdas inside cling interpreter and there are some of wrong behaviors which I report in this issue.

[cling]$ int i;
[cling]$ auto lambda = [i](double x){return i*x;};
input_line_4:2:17: error: 'i' cannot be captured because it does not have automatic storage duration
 auto lambda = [i](double x){return i*x;};
                ^
input_line_3:2:6: note: 'i' declared here
 int i;
     ^

I think that the variable i is not in the same scope of lambda and this is why it doesn't work. But it is a correct C++ code.

Now, if I use the operator =

[cling]$ int i;
[cling]$ auto lambda = [=](double x){return i*x;};
[cling]$ lambda(3)
(double) 0.000000
[cling]$ i = 2
(int) 2
[cling]$ lambda(3)
(double) 6.000000

There is no error but it is normally a copy capture, so if I change the value of i, the second call of lambda must be unchanged.

If I write the same examples in a scope, it works as expected.

{
    int i = 0;
    auto lambda = [i](double x){return x*i;};
    std::cout << lambda(3) << "\n";
    i = 3;
    std::cout << lambda(3) << "\n";
}

output:
0
0

{
    int i = 0;
    auto lambda = [=](double x){return x*i;};
    std::cout << lambda(3) << "\n";
    i = 3;
    std::cout << lambda(3) << "\n";
}

output:
0
0

After successfully building LLVM/Clang/Cling and playing around with the Cling driver, I tried out the embedding demo. It compiles successfully, and the Interpreter does get created, but a bunch of cling symbols are not found:

IncrementalExecutor::executeFunction: symbol '?setValueNoAlloc@internal@runtime@cling@@YAXPEAX00D_K@Z' unresolved while linking [cling interface function]!
You are probably missing the definition of void __cdecl cling::runtime::internal::setValueNoAlloc(void * __ptr64,void * __ptr64,void * __ptr64,char,unsigned __int64)
Maybe you need to load the corresponding shared library?
aGlobal is 1633814599152

I have been trying to figure this out for a couple days now, so any help would be most appreciated!

More errors here:

When using the regular cling interpreter, printing in the standard output, and not ending with a newline results in something like this:

[cling]$ std::cout << "foobar";
foobar[cling]$ 

I don't think that one should be required to end with a new line. If we do so, it would result in an empty line in the case of a jupyter notebook or console.

I saw the cling-demo and wondered if there is something, which prevents me from accessing local variables the the stack frame, where the interpreter was called.

My use case is the following:

I have a static compiled program, where I want to explore my program state in function foo().
There for I would insert ahead of execution a function called invokeCling() into my program:

void foo(int a) {
  int b;
  invokeCling();
}

invokeCling() would then figure out its caller and use debug symbols or consult an debugger to get more information about the call frame (to get the address of local variables and their types). These information could be then used to passed to cling to make accessible from within the repl.

Do you think this is possible? Can I use Interpreter::declare to get access to variables, which are not global symbols?

Similar approaches in other programming languages:

• pry in ruby
• python's pdb
• evaluate expressions in java

Hi,

I have a really simple test case which doesn't work in the cling interpreter (0.3 and 0.4) and I don't understand why ...

****************** CLING ******************
* Type C++ code and press enter to run it *
*             Type .q to exit             *
*******************************************
[cling]$ #include <vector>
[cling]$ std::vector<double> product_element_wise(const std::vector<double>& x, const std::vector<double>& y){
[cling]$ ?   std::vector<double> z(x.size());
[cling]$ ?   return z;
[cling]$ ?   }
input_line_4:2:102: error: function definition is not allowed here
 std::vector<double> product_element_wise(const std::vector<double>& x, const std::vector<double>& y){

It works if I change the return type to auto.

Is there a problem with <> characters ?

One rainy Wednesday evening I was looking for procrastination options and I found them in the form of setting up Cling. Let me tell you this story, hoping it may be useful to either someone planning to repeat this or to work on improving this process.

I started by searching precompiled Windows binaries. For some reason (why?) the official are not available, but I found the Anaconda cling package. So I tried installing it first:

• conda create -n cling cling

After the download was complete I found the cling binaries under Anaconda3\envs\cling\Library\bin, however cling.exe threw a bunch of warnings and crashed on any nontrivial command. OK, why not compile Cling myself, right? The night was young.

• git clone https://github.com/root-project/cling.git

• cd cling\tools\packaging

• Read the README, figure out I need Python 2, OK.

• conda create -n py27 python=2.7.13

• activate

• python cpt.py -c

  The program prints one error about not being able to read some registry key, but otherwise looks happy. Well, let's try building. Yes, I know it is written you need VS2012 but I only have 2017. Perhaps it will work?

• python cpt.py --last-stable=pkg

  The program starts preparing the environment and at some point attempts to download CMake. The download succeeds but then some exception is thrown on copying CMake. I look in the code. It turns out the cmakeDir variable is used but never declared.

• "Well, why don't I install CMake normally, I need it anyway, and if I have it installed the code won't even reach the place with cmakeDir". So I go to cmake.org, install CMake using the latest installer, and try again:

• python cpt.py --last-stable=pkg

  Nope, the program does not care about my newly installed cmake and still wants to download one of its own crashing on cmakeDir afterwards. I check that cmake is in the path, do set CMAKE=.... just in case. No help. After studying the code a bit more I see that that there's a line which checks CMake version as follows:

  vers = [int(v) for v in rslt.split()[2].split('.')]

  This assumes that the version is consisting of three dot-separated integers, whilst my CMake has version 3.10.0-rc1. Whatever, let's just comment that (and the following) line out and try again!

• python cpt.py --last-stable=pkg

  Now everything looks fine. CMake configures the project, a long-ish build starts, but fails with some message about an undefined identifier. Googling the error tells me I should not be building with VS2017, but VS2015 could work. Luckily I have the VS2015 build toolchain installed with VS2017 so I only need to let CMake know to use that one by passing the -G "Visual Studio 14 2015 Win64" parameter.

  After some failed attempts to pass it using --with-cmake-flags (apparently I'm not good at escaping quotes) I simply hard-code it in cpt.py (I've messed around already, so who cares, right?):

  EXTRA_CMAKE_FLAGS = args.get('with_cmake_flags') + ' -G "Visual Studio 14 2015 Win64"'

• Delete everything under c:\ci\build\builddir.

• python cpt.py --last-stable=pkg

  Bad luck. Now CMake cannot configure the project for some reason. After an hour or so of googling, I find out VC2017 comes with broken VC2015 build tools, and further hacks need to be done to fix this:

  • Changing a line in vcvarsall.bat.
  • Manually setting a VCTargetsPath variable.
  • Manually setting the build environment by calling vcvarsall.bat.

  Fine, on we go!

• python cpt.py --last-stable=pkg

  Now the build fails because of the line #error "Unsupported/Untested _MSC_VER" somewhere in PlatformWin.cpp. Well, we're fine with untested, so let's comment this out.

• python cpt.py --last-stable=pkg

  Yay, the build step passes now. The install fails.
  It turns out that in order to copy the correct files to make the package, cpt.py looks for the file dist-files.txt under c:/ci/build/cling-src/tools/cling/tools/packaging. There's only dist-files.json, however. Luckily, the dist-files.txt is available in my current directory (the one where I checked cling out), so I just copy it to c:/ci/build/....

• python cpt.py --last-stable=pkg

  OK, now the build and install steps pass, the test step fails. The reason seems to be the lack of cat command (presumably this would not be a problem if I had MSYS Git set up, but I really don't want to screw my current Git).
  I have cat in cygwin, so let's try this way:

• set PATH=%PATH%;C:\cygwin64\bin

• python cpt.py --last-stable=pkg

  Now I have 16 failing tests, but 98 are passing, so perhaps the failing ones are not that crucial (I won't be using Cling in production). Let's go on. Apparently I need to disable the test step to proceed, though:

• python cpt.py --last-stable=pkg --no-test

  Next problem comes up in the make_nsi step:

  UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 166: ordinal not in range(128)

  Hmmm... The only non-ASCII symbol in the whole file is ©. Let's replace it with (c) and try again.

• python cpt.py --last-stable=pkg --no-test

  New milestone:
  WindowsError: [Error 2] The system cannot find the file specified.
  However, at this point I actually saw all the necessary files being copied to c:\Windows\Temp\cling-obj, so perhaps I could go check out how these worked out.

• cd C:\Windows\Temp\cling-obj\bin

• cling.exe

  Just like in the Anaconda distribution, I get a bunch of warnings and the shell crashes on any input (except variable declarations and assignments).

At this point I gave up. Apparently it's easier to run cling in a docker container at the moment. But maybe I missed some very easy shortcut along the way?

Is it possible to consider to relicense Cling under a more commercial friendly license like ASL 2.0? Alternatively a license like BSD or MIT.

And also perhaps ROOT is this is an option.

$ ./cling
Warning in cling::IncrementalParser::CheckABICompatibility():
  C++ ABI mismatch, compiled with __GLIBCXX__ v20160609 running with v20160413

****************** CLING ******************
* Type C++ code and press enter to run it *
*             Type .q to exit             *
*******************************************
[cling]$ 

Seems like this conversation might be relevant, but might be out of date by now.

https://root.cern.ch/phpBB3/viewtopic.php?t=19882

--enable-shared had no effect on cling

It would be nice to have the same version on both servers. I found it confusing to see different code on github and in my docker image.

e.g: lline 84 in the clingkernel.py is today if not self.libclingJupyter: which should be something like: if not getattr(self,"libclingJupyter",None) and is something totally different on github (https://github.com/root-mirror/cling/blob/5c750a2c4c7ce02e6c5ba2787a34b9268cb66ae7/tools/Jupyter/kernel/clingkernel.py#L84)

When I run ./cpt.py --check-requirements I get error

subprocess.CalledProcessError: Command 'rpm -qa | grep -w ...' returned non-zero exit status 1

It prints the same thing for git, gcc, gcc-c++ and rpm-build even though they are all installed

However, when I run 'rpm -qa | grep ..' myself it finishes without a problem.

I didn't continue further, it is possible that even though requirement check fails, other parts might be working.

Edit: My python version is 2.7.12

python cpt.py -c

Cling Packaging Tool (CPT)
Arguments vector: ['cpt.py', '-c']

╔══════════════════════════════════════════════════════════════════════════════╗
║ cling (x86_64)                               Tue, 19 Apr 2016 18:32:48 +0800 ║
╚══════════════════════════════════════════════════════════════════════════════╝
Thread Model: POSIX
Operating System: Linux
Distribution: Ubuntu
Release: trusty
Revision: 14.04
Architecture: x86_64

┌──────────────────────────────────────────────────────────────────────────────┐
│ Check availability of required softwares                                     │
└──────────────────────────────────────────────────────────────────────────────┘
git                 [OK]                          
gcc                 [OK]                          
g++                 [OK]                          
debhelper           [OK]                          
subprocess.CalledProcessError: Command 'dpkg-query -W -f='${Status}' devscripts 2>/dev/null | grep -c 'ok installed'' returned non-zero exit status 1



┌──────────────────────────────────────────────────────────────────────────────┐
│ Clean up                                                                     │
└──────────────────────────────────────────────────────────────────────────────┘
Remove directory: /tmp/cling-obj/
Traceback (most recent call last):
  File "cpt.py", line 1390, in <module>
    check_ubuntu('devscripts')
  File "cpt.py", line 452, in check_ubuntu
    elif exec_subprocess_check_output("dpkg-query -W -f='${Status}' %s 2>/dev/null | grep -c 'ok installed'"%(pkg), '/').strip() == '0':
  File "cpt.py", line 89, in exec_subprocess_check_output
    return out
UnboundLocalError: local variable 'out' referenced before assignment

This creates integration problems, at least with Hydrogen Atom plugin.
See nteract/hydrogen#1129

It appears that cling will fail on include in some cases when it shouldn't.

Attempting to include a file that is not in the include path will prevent you from successfully including it later once the path has been correctly adjusted.

$ ./cling 
Warning in cling::IncrementalParser::CheckABICompatibility():
  C++ ABI mismatch, compiled with __GLIBCXX__ v20160609 running with v20160413

****************** CLING ******************
* Type C++ code and press enter to run it *
*             Type .q to exit             *
*******************************************
[cling]$ #include <Eigen/Core>
input_line_3:1:10: fatal error: 'Eigen/Core' file not found
#include <Eigen/Core>
         ^
[cling]$ #include <Eigen/Geometry>
input_line_4:1:10: fatal error: 'Eigen/Geometry' file not found
#include <Eigen/Geometry>
         ^
[cling]$ .I /usr/include/eigen3
[cling]$ #include <Eigen/Geometry>
input_line_5:1:10: fatal error: 'Eigen/Geometry' file not found
#include <Eigen/Geometry>
         ^
[cling]$ #include <Eigen/Core>
input_line_6:1:10: fatal error: 'Eigen/Core' file not found
#include <Eigen/Core>
         ^
[cling]$ 
[~/opt/cling_2016-08-02_ubuntu16/bin]
$ ./cling 
Warning in cling::IncrementalParser::CheckABICompatibility():
  C++ ABI mismatch, compiled with __GLIBCXX__ v20160609 running with v20160413

****************** CLING ******************
* Type C++ code and press enter to run it *
*             Type .q to exit             *
*******************************************
[cling]$ .I /usr/include/eigen3
[cling]$ #include <Eigen/Core>
[cling]$ #include <Eigen/Geometry>
[cling]$ 

I am running on Ubuntu 14.04 LTS, 64bit

Hi,

While trying to setup Jupyter notebooks with cling I ran into following issue (not the whole traceback):

  File "/usr/local/lib/python3.5/dist-packages/ipykernel/kernelapp.py", line 373, in init_kernel
    self.displayhook.get_execution_count = lambda: kernel.execution_count
AttributeError: 'ClingKernelApp' object has no attribute 'displayhook'

I have tracked down the error to be in the file clingkernel.py in the method init_io that is on line 284. This method overrides the method from the parent class and due to that it skips the initialisation of the displayhook attribute. Removing the init_io method seems to work.

Cheers,
Aleks

When I try to run the following simple command in cling,

#include <iostream>

it works fine.

However, running the same thing in a jupyter notebook with the cling kernel throws an error.

Any suggestions on how to solve this?

If I start jupyter-notebook from the parent of <my_cling_dir>, the kernel starts and runs fine.

If I start it anywhere else, I get:
RuntimeError: Cannot find cling_2017-05-23_mac1011/lib/libclingJupyter.{so,dylib,dll}

Maybe it is looking for the dylib relative to the launch directory?

FYI Since the 26th, the ubuntu 16 nightlies don't seem to be generated.

Since the last release, there was quite a bit of progress. Is it time for 0.4?

Hi ROOT team,

I am opening this issue to document and discuss our plan to add CUDA support to Cling. Maybe someone can open and link an issue on https://root.cern/bugs, I neither have a CERN nor an external account and the tracker is not public for people without registration :)

The discussion started after a post of mine in the cling-dev mailing list, where @Axel-Naumann picked me up and we spinned of a longer private discussion.

On 07.11.2016 10:34, Huebl, Axel wrote:
[...] I am trying to compile a simple CUDA program, which is supported by clang
already:

[...] internal include issues when starting cling via
./cling -x cuda --cuda-path=$CUDA_ROOT --cuda-gpu-arch=sm_35
-L$CUDA_ROOT/lib -lstdc++ -lcudart [...]

By now, @Axel-Naumann did already fix all issues during startup and we think we are now at the point where one could work on accessing clang's PTX emitter to generate PTX code and then pass it to the driver API.

$ cling -x cuda --cuda-gpu-arch=sm_35 -nocudainc
atexit not in Module!
at_quick_exit not in Module!

****************** CLING ******************
* Type C++ code and press enter to run it *
*             Type .q to exit             *
*******************************************
[cling]$ 

Clang currently translates CUDA code by linking the PTX code in a fat binary and passing it the CUDA driver during runtime, which generates SASS code (shader assembly) from it to execute. This is similar to what nvcc provides, besides that nvcc can additionally generate and link SASS code for a specific compute architecture directly, but that's not important here (see this page for further details).

From our discussions I understood, that cling already has similar functionality for e.g. PowerPC in place to target specific emitters and execute their assembler artifacts. Can you guide us how one could add the same functionality for PTX?

At GCoE Dresden, which is a collaboration of research groups in and around Dresden (Technical University, Max-Planck, Helmholtz-Zentrum Dresden-Rossendorf), we are currently discussing the possibilities for interactive simulations, RT profiling and tuning, teaching, rapid prototyping and interactive simulations and much more that one could get from a CUDA capable interpreter. Long story short: exciting possibilities!

From what I know about the routines in ROOT, there is no wide spread manycore or GPU acceleration available up to now. Adding CUDA support from cling will provide native CUDA support in your framework which is probably something that could be of interest from your side. Maybe you also want to build on that and directly add general manycore support in a more performance portable and abstract way, a topic on which we have experience, too.

We have currently one interested student that could work on the topic and any support and docs would be greatly appreciated. Two other groups from TU Dresden and Max-Planck also seemed interested and we might be able to contribute further resources (although that is not up to me). Due to our GCoE we also have a fruitful collaboration with Nvidia, which might be necessary, too.

CCing @harrism you might be interested in this thread.

I tried cmake on revision with label v0.5 and got the following error:

-- Found LLVM_CONFIG as /usr/bin/llvm-config
CMake Error at CMakeLists.txt:74 (message):
  Not found: /usr/lib/llvm-3.8/lib/cmake/llvm/LLVMConfig.cmake

After locating the file on my system, I could fix the CMakeList for me:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index bcc8e4be..bd1c4df9 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -65,7 +65,7 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR )
   find_program(LLVM_TABLEGEN_EXE "llvm-tblgen" ${LLVM_TOOLS_BINARY_DIR}
     NO_DEFAULT_PATH)
 
-  set(LLVM_CMAKE_PATH "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
+  set(LLVM_CMAKE_PATH "${LLVM_BINARY_DIR}/share/llvm/cmake${LLVM_LIBDIR_SUFFIX}")
   set(LLVMCONFIG_FILE "${LLVM_CMAKE_PATH}/LLVMConfig.cmake")
   if(EXISTS ${LLVMCONFIG_FILE})
     list(APPEND CMAKE_MODULE_PATH "${LLVM_CMAKE_PATH}")

I guess the correct path should be detected somehow or does Debian use a wrong location for LLVMConfig.cmake?