search for: cling

Hi Richard, On 7/10/20 11:10 PM, Richard Smith wrote: > Hi Vassil, > > This is a very exciting proposal that I can imagine bringing important > benefits to the existing cling users and also to the clang user and > developer community. Thank you for all the work you and your team have > done on cling so far and for offering to bring that work under the > LLVM umbrella! > > Are you imagining cling being part of the clang repository, or a > separate L...

Motivation === Over the last decade we have developed an interactive, interpretative C++ (aka REPL) as part of the high-energy physics (HEP) data analysis project -- ROOT [1-2]. We invested a significant  effort to replace the CINT C++ interpreter with a newly implemented REPL based on llvm -- cling [3]. The cling infrastructure is a core component of the data analysis framework of ROOT and runs in production for approximately 5 years. Cling is also  a standalone tool, which has a growing community outside of our field. Cling’s user community includes users in finance, biology and in a fe...

I like cling, and having it integrated with the rest of the project would be neat. I agree with Hal’s suggestion to explain the design of what remains. It sounds like a pretty small amount of code. > On Jul 9, 2020, at 7:25 PM, Hal Finkel via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > I th...

On 7/10/20 1:57 PM, Vassil Vassilev wrote: > On 7/10/20 6:43 AM, JF Bastien wrote: >> I like cling, and having it integrated with the rest of the project >> would be neat. I agree with Hal’s suggestion to explain the design of >> what remains. It sounds like a pretty small amount of code. > > >   JF, Hal, did you mean you want a design document of how cling in > genera...

I do not know enough about cling, but I like what you describe very much, am particularly intrigued about how your approach could also be appropriated to do ahead-of-time constexpr metaprogramming as well, which also involves incrementally adding declarations to the translation unit. Dave > On Jul 9, 2020, at 11:43 PM, JF Bas...

...al months of reflections we think we can get around this problem  by using a C interpreter. Instead of compiling it to machine code, we would pass the generated C program to  a C interpreter that would interpret the C program. After looking at several interpreters, we think that the llvm based CLING interpreter could do the job. To test these ideas, we have recompiled the llvm/Clang system in a small linux/ARM64 based machine. Our preliminary tests seem to work and cling is able to load the generated program. There are several possible problems that we see. The first and most obvious one...

Jun 14 07:35:20 cling imap-login: Login: tallison [192.168.1.10] Jun 14 07:35:21 cling dovecot: child 17755 (imap) killed with signal 11 --- I run into this when I try to enter one folder. The rest are fine.

Dear LLVM-Developers and Vinod Grover, we are trying to extend the cling C++ interpreter (https://github.com/root-project/cling) with CUDA functionality for Nvidia GPUs. I already developed a prototype based on OrcJIT and am seeking for feedback. I am currently a stuck with a runtime issue, on which my interpreter prototype fails to execute kernels with a CUDA runtime...

...e: > > Compilation of "SmallPtrSet.cpp" seems to be broken ... > Solved by removing the conditional compile by > > #ifdef LLVM_HAS_RVALUE_REDERENCE for method "SmallPtrSetImplBase" > > Hope it doesn't break anything :) > > > BTW .. is "cling" now integral part of LLVM ? > > Regards > > --Armin > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

...this helps! > > Cheers, > Lang. > > > On Wed, Sep 27, 2017 at 10:32 AM, Simeon Ehrig via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Dear LLVM-Developers and Vinod Grover, > > we are trying to extend the cling C++ interpreter > (https://github.com/root-project/cling > <https://github.com/root-project/cling>) with CUDA functionality > for Nvidia GPUs. > > I already developed a prototype based on OrcJIT and am seeking for > feedback. I am currently a stuck with a...

Hi, I ran into a problem migrating cling (finally!) to MCJIT: When an ("outer") MCJIT's finalization / llvm::RuntimeDyldImpl::resolveExternalSymbols() is called and a symbol is not known, cling can help by loading the suitable library and providing the symbol. It compiles the relevant C++ header as part of loading the libra...

...ther than DEBUG. The issue of clutter and excess wrapping is a secondary issue as much of the code in LLVM already is excessively wrapped and, to my eyes, borderline unreadable. At the risk of starting a major thread that has surely been covered many times before: Is there a reason to still cling to the 80 column limit and not consider expanding it to a controversial 100 columns? Dominic

Indeed ld does link it. The reason I am using llvm-ld, is for its unique functionality. I intend to link to object files together (created by cling), and link them with llvm-ld. The main feature that I am currently interested in is the ability to have "inline functions" between two object files. This was basically impossible with gcc. Is there any way to make the raw binary with llvm? Thank you, Ven Török Edwin wrote: > >...

...drop support for Python older than 2.6. I would encourage requiring 2.7 (preferably the latest available release - 2.7.3 at this time) at the earliest convenience, but I'm not explicitly asking for it. While continued support for older Pythons is a noble goal and may continue to support people clinging to ancient Python releases, this will only make the path forward more difficult, as it puts an additional burden on those maintaining Python in the tree. That is all well and good, but please be reminded there are zillions of Red Hat (or CentOS) users out there, stuck with either Python 2.5 or...

LGTM. I will commit. On Oct 10, 2012, at 1:20 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > Hi, > > The attached is the fix to radar://11663049. The optimization can be outlined by following rules: > > (select (x != c), e, c) -> select (x != c), e, x), > (select (x == c), c, e) -> select (x == c), x, e) > where the <c> is an integer

...2.6. >> I would encourage requiring 2.7 (preferably the latest available release - >> 2.7.3 at this time) at the earliest convenience, but I'm not explicitly >> asking for it. While continued support for older Pythons is a noble goal and >> may continue to support people clinging to ancient Python releases, this >> will only make the path forward more difficult, as it puts an additional >> burden on those maintaining Python in the tree. > > > That is all well and good, but please be reminded there are zillions of Red > Hat (or CentOS) users out th...

Hello: I am told that compile cling, from CERN, I need revision 165095. HOW do I check out that version? When going through the /tags directory, all version are 17xxxx. I tried svn checkout -r 165095 http://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx llvm but it will not work with either /truck or /tags I tried svn checkout http://xxxxxxxxxxxx...

Hi, I don't know if this is the correct term. Let me elaborate. From time to time, I want to expunge (?) the mail folder so that users' Trash'd mails don't occupy space. So, here are my questions: 1. Is this the correct term? 2. Is it a Good Idea? to do it? Thanks, -- mto

Hi, I'm finally moving cling to MCJIT - and MCJIT is wonderful! So far I only ran into this issue: $ cat linkonceodr.cxx extern "C" int printf(const char*,...); template <class T> struct StaticStuff { static T s_data; }; template <class T> T StaticStuff<T>::s_data = 42; int compareAddr(int* mcj...

...drop support for Python older than 2.6. I would encourage requiring 2.7 (preferably the latest available release - 2.7.3 at this time) at the earliest convenience, but I'm not explicitly asking for it. While continued support for older Pythons is a noble goal and may continue to support people clinging to ancient Python releases, this will only make the path forward more difficult, as it puts an additional burden on those maintaining Python in the tree. FWIW, I've been pushing this same argument at Mozilla for the Firefox tree [1], where so far it has been winning. We dropped Python 2.5 a...