search for: symnames

...) eval(expr) I would like the next similar example to evaluate to the list('5', '6', '7'), but instead it evaluates to the list(foo, bar, baz) where the type of foo, bar, and baz are all symbols. For the purposes of finding a solution assume that the length and contents of symnames are unknown ahead of time (symname is not a constant, assume it is some parameter to a function). symnames <- c('foo', 'bar', 'baz') foo <- 5 bar <- 6 baz <- 7 expr <- substitute(expr, list(expr = lapply(symnames, as.symbol))) eval(expr) Thanks! --Michael

On Thu, 2008-03-27 at 07:44 -0400, Gordon Henriksen wrote: > In the context of a static compiler, I would recommend that you > implement your own “on the side” symbol table in order to track this > state and perform on-demand instantiation as required. It is > worthwhile to consider the LLVM module to be a passive output sink, > not an active object. I think I understand what you

"Jonathan S. Shapiro" <shap at eros-os.com> writes: [snip] > if (!(sym = llvm_resolve_global(GlobalScope, symName))) > some_failure_action(); > > it would now look something like: > > sym = llvm_resolve_global(GlobalScope, symName); > if (!sym && frontend_has_symbol_generator > && frontend_generate_symbol(symname)) >

Hi, On 2020-09-25 16:38:41 -0700, Andres Freund via llvm-dev wrote: > On 2020-09-24 16:34:30 -0700, Lang Hames wrote: > > If anyone wants to check out the OrcV1 removal branch and provide feedback > > now is the time. Otherwise I will aim to land the work in the mainline > > early next week. > > I'm trying to get it to work with postgres. Unfortunately this week

I've stumbled upon a small bug/inconsitency in do_External and do_dotcall: Here's an example: % LC_ALL=C R --vanilla < symname-bug.R R version 2.8.0 (2008-10-20) *snip* > options(error=expression(0)) > ## Call 'R_GD_nullDevice' with incorrect parameter count: > .Call("R_GD_nullDevice", 1) Error in .Call("R_GD_nullDevice", 1) :

Hi, Not sure whether this matches your use case, but the Orc-based JIT used in LLI appears to be using `llvm::orc::LocalCXXRuntimeOverrides` (http://llvm.org/doxygen/classllvm_1_1orc_1_1LocalCXXRuntimeOverrides.html) to override `__cxa_atexit`: https://github.com/llvm-mirror/llvm/blob/release_50/tools/lli/OrcLazyJIT.h#L74

Change the assembly code to use the new _ASM_MOVABS macro which get a symbol reference while being PIE compatible. Adapt the relocation tool to ignore 32-bit Xen code. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas Garnier <thgarnie at google.com> --- arch/x86/tools/relocs.c | 16

Hi Jonathan, In the context of a static compiler, I would recommend that you implement your own “on the side” symbol table in order to track this state and perform on-demand instantiation as required. It is worthwhile to consider the LLVM module to be a passive output sink, not an active object. The JIT compiler, by contrast, is an active object, cooperating with its environment via

Hi R Developers, Greg is helping me with debugging R on Solaris 10 x64. Please let us know if you have any thoughts or tips that can help us debug this. Thanks, David ************ Using default transfer plist in vector_io: permuting About to write *** caught segfault *** address e8554000, cause 'memory not mapped' Traceback: 1: .External("do_hdf5save", call,

Okay, we're starting to dig in, and I've hit a question that will no doubt seem strange. Context: BitC is a polymorphic language. Since it has unboxed value types, our approach to compiling a polymorphic function is to polyinstantate it -- once for each signature. The name mangling scheme is both stable and reversible. At the site of the use occurrence, we can fully determine the mangled

plain text document attachment (lguest64-debug-utils.patch) This patch contains some nice features used to debug the lguest64 guest. It has a way to print page tables for either the host or the guest. It incorporates kallsyms, and can do a nice back trace of a guest when it crashes. The guest needs kallsyms obviously compiled in. Note: This code needs to be fixed to be more secure! Implements

plain text document attachment (lguest64-debug-utils.patch) This patch contains some nice features used to debug the lguest64 guest. It has a way to print page tables for either the host or the guest. It incorporates kallsyms, and can do a nice back trace of a guest when it crashes. The guest needs kallsyms obviously compiled in. Note: This code needs to be fixed to be more secure! Implements

Hi All, The Kaleidoscope tutorials have now been updated on the orcv1-removal branch. I will try to summarise the state of the work and provide some examples in the ORC JIT Weekly mailout tomorrow. The short version is that I think this is ready to land on the mainline. If anyone wants to check out the OrcV1 removal branch and provide feedback now is the time. Otherwise I will aim to land the

This is taken from the work I did on lguest64. When killing a guest, we read the guest stack to do a nice back trace of the guest and send it via printk to the host. So instead of just getting an error message from the lguest launcher of: lguest: bad read address 537012178 len 1 I also get in my dmesg: called from [<c0405f30>] show_trace_log_lvl+0x1a/0x2f [<c04069aa>]

This is taken from the work I did on lguest64. When killing a guest, we read the guest stack to do a nice back trace of the guest and send it via printk to the host. So instead of just getting an error message from the lguest launcher of: lguest: bad read address 537012178 len 1 I also get in my dmesg: called from [<c0405f30>] show_trace_log_lvl+0x1a/0x2f [<c04069aa>]

Hi, I am not sure how widespread this problem is, but definitely occurs for me on 64 bit Win 7 with a 64 bit R. I think I have isolated the issue (to a certain extent) in the attached Test.cpp file. Basically, I think linking with boost serialization is causing the plugin to fail. If I compile Test.cpp with line 43 (Dummy* Read() ...) commented out, I get the expected output in R: >

Hi all, Reading the wikipedia page on R, I stumbled across the following: http://fluff.info/blog/arch/00000172.htm It does seem interesting that the C execution is that much slower from R than from a native C program. Could any of the more technically knowledgeable people explain why this is so? The author also have some thought-provoking opinions on R being no-good and that you should write

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to