similar to: [LLVMdev] RuntimeDyld bug in resolving addresses with offset?

On Oct 12, 2012, at 11:14 AM, Baris Aktemur <baris.aktemur at ozyegin.edu.tr> wrote: > > On 12 Eki 2012, at 20:00, Jim Grosbach wrote: > >> >> On Oct 12, 2012, at 7:07 AM, Baris Aktemur <baris.aktemur at ozyegin.edu.tr> wrote: >> >>> Dear Tim, >>> >>>> >>>> The JIT sounds like it does almost exactly what you

Dear Jim, On 12 Eki 2012, at 21:17, Jim Grosbach wrote: > > On Oct 12, 2012, at 11:14 AM, Baris Aktemur <baris.aktemur at ozyegin.edu.tr> wrote: > >> >> On 12 Eki 2012, at 20:00, Jim Grosbach wrote: >> >>> >>> On Oct 12, 2012, at 7:07 AM, Baris Aktemur <baris.aktemur at ozyegin.edu.tr> wrote: >>> >>>> Dear Tim,

On 12 Eki 2012, at 20:00, Jim Grosbach wrote: > > On Oct 12, 2012, at 7:07 AM, Baris Aktemur <baris.aktemur at ozyegin.edu.tr> wrote: > >> Dear Tim, >> >>> >>> The JIT sounds like it does almost exactly what you want. LLVM's JIT >>> isn't a classical lightweight, dynamic one like you'd see for >>> JavaScript or Java.

On Oct 12, 2012, at 7:07 AM, Baris Aktemur <baris.aktemur at ozyegin.edu.tr> wrote: > Dear Tim, > >> >> The JIT sounds like it does almost exactly what you want. LLVM's JIT >> isn't a classical lightweight, dynamic one like you'd see for >> JavaScript or Java. All it really does is produce a native .o file in >> memory, take care of the

On Thu, Sep 20, 2012 at 2:42 AM, Baris Aktemur <baris.aktemur at ozyegin.edu.tr> wrote: > I am generating LLVM IR code and I would like to convert this IR code to > native code using the LLVM C++ API. This would be very similar to what's > done in the Kaleidoscope tutorial, but instead of relying on JIT > compilation, I'd like to emit native code -- the same native code

I am generating LLVM IR code and I would like to convert this IR code to native code using the LLVM C++ API. This would be very similar to what's done in the Kaleidoscope tutorial, but instead of relying on JIT compilation, I'd like to emit native code -- the same native code that's produced by llc, for instance. I'm sure this is possible, but I wasn't able to find the

Dear Tim, > > The JIT sounds like it does almost exactly what you want. LLVM's JIT > isn't a classical lightweight, dynamic one like you'd see for > JavaScript or Java. All it really does is produce a native .o file in > memory, take care of the relocations for you and then jump into it (or > provide you with a function-pointer). Is there any other reason you >

This is a correction to my previous message, I forgot to swap two lines in the body of setMakeGenericMethod. Sorry about that. The correct (full message) reads like this: Hi, This works > setGeneric("clear", function(obj) standardGeneric("clear")) [1] "clear" but this doesn't. Why? > funName <- "clear" > setGeneric(funName,

From: Sergei Golovan <sgolovan@gmail.com> Replace the use of liberl_interface, which is removed in Erlang 23, by libei. The implementation uses the ei_decode_iodata() function which has been introduces only for Erlang 23, so it doesnt work with earlier Erlang versions. --- erlang/Makefile.am | 1 - erlang/main.c | 312 +++++++++++++++++++++++++-------------------

Dear R-devel I have a function in a package that essentially provides a wrapper for a group of functions in another Suggested package (it sets appropriate defaults for the context, transforms output, etc). I've implemented this by verifying that the package was loaded with require(sna) and then do.call(snaFunName, args = args) The rDevel check is requesting that I use

It's not possible to define an action which takes a parameter called 'message' because the Erlang bindings use that as the name of an internal variable. Solve this by renaming the Erlang internal variable. Fixes commit 84763d7fca3668c62ee3fe53d0e00a5a672f687b. --- generator/erlang.ml | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git

do.call(sna::snaFunName, args = args) ? Hadley On Tue, Feb 24, 2015 at 1:29 PM, Skye Bender-deMoll <skyebend at skyeome.net> wrote: > Dear R-devel > > I have a function in a package that essentially provides a wrapper for a > group of functions in another Suggested package (it sets appropriate > defaults for the context, transforms output, etc). I've implemented this

I added a couple of static probes to Firefox to measure actual work done. I could have used a pid$target probe with a function name but work is done within an if statement, which is where I placed the static probes. I''m wondering about my use, though. Is the following significantly more efficient than pid$target::FunName:entry and return? I heard somewhere that $target does not

I'm not sure I understand your use case, but MCJIT (as opposed to the legacy JIT) does almost exactly what you're asking for. It generates an in-memory object file image (using addPassesToEmitMC) and then loads and links it for execution. If there's some particular detail you don't like in the way this is happening, you might be able to generate a file as you have and then use

This is was something like a request for your comments, thoughts on the topic... Many of you will know that the "..." (aka \dots) argument is very useful for passing ``further graphical parameters'', but can be a pain when itself is passed to too many plotting functions inside your own function. An artificial example being myplot <- function(x,y, ...) { plot(0:1, 0:1,

Hadley, Overall seems like a cool and potentially really idea. I do have some thoughts/feedback, which I've put in-line below On Thu, Aug 23, 2018 at 11:31 AM, Hadley Wickham <h.wickham at gmail.com> wrote: > > <snip> > > conflicted applies a few heuristics to minimise false positives (at the > cost of introducing a few false negatives). The overarching goal is

Take a look at the MCJIT unit tests under unittests/ExecutionEngine/MCJIT The MCJITTestBase class does the majority of the interactions with the LLVM API you're referring to. Good luck, Dan On 2012-10-13, at 4:57 AM, "Armin Steinhoff" <as at steinhoff-automation.com> wrote: > > Kaylor, > > do you have some good documented example code which shows the usage of

It's definitely there. It was added in r165246 recently so you probably have an older version. Amara On 13 October 2012 23:02, Armin Steinhoff <as at steinhoff-automation.com> wrote: > Daniel, > > I didn't find the MCJIT directory under unitests/ExecutionEngine ... there > is only a directory called JIT. > You mean this directory ? > > Many thanks > >

Kaylor, do you have some good documented example code which shows the usage of the MCJIT ? This would help a lot ... the sematic of lots of API calls are not intuitively understandable. Best Regards --Armin Kaylor, Andrew wrote: > I'm not sure I understand your use case, but MCJIT (as opposed to the legacy JIT) does almost exactly what you're asking for. It generates an

Daniel, I didn't find the MCJIT directory under unitests/ExecutionEngine ... there is only a directory called JIT. You mean this directory ? Many thanks --Armin Malea, Daniel wrote: > Take a look at the MCJIT unit tests under unittests/ExecutionEngine/MCJIT > > The MCJITTestBase class does the majority of the interactions with the LLVM API you're referring to. > >