search for: compiledcode

Hi, I have reported a bug on codeplex: http://ironruby.codeplex.com/workitem/6353 Will it be fixed in next release? Thank you, Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20110802/78a24916/attachment.html>

Dear list The deSolve package allows you to specify the model code in C or Fortran. Thanks to the excellent vignette this works fine. However I have not yet managed to use forcing functions in C code. In pure R code this works very well with approxfun() specified outside the model: ############################################### #Model lvml <- function(t, x, parms) {

...cerg [mailto:spencer.graves at prodsyse.com] Envoy? : vendredi 15 mai 2009 05:28 ? : Benoit Boulinguiez Cc : dieter.menne at menne-biomed.de; r-help at r-project.org Objet : Re: [R] ode first step Have you looked at the vignette in the deSolve package? (deS <- vignette('compiledCode')) # opens a "pdf" file Stangle(deS$file) # writes an R script file to "getwd()" In spite of the name, this vignette includes an example entirely in R. By comparing it with your code, I see that you do NOT provide a connection between y, parms, K1, C0, m,...

...d simply be associated to a FnState with <null, List<>, stubForG>. After f's compilation, it could be something like that <null, List<RelocationTable-of-module-f>, stubForG>. And after the compilation of g, something like <moduleOfG, List<Reloc-f, Reloc-g>, compiledCode-of-g> with the relocation entries updated? Otherwise, for safepoints, and for exception tables, it could be also really useful to install call backs to let VMKit manages them itself (but it's maybe provided by the safepoint/patchpoint patch?)? (with something that can make the association...

...d simply be associated to a FnState with <null, List<>, stubForG>. After f's compilation, it could be something like that <null, List<RelocationTable-of-module-f>, stubForG>. And after the compilation of g, something like <moduleOfG, List<Reloc-f, Reloc-g>, compiledCode-of-g> with the relocation entries updated? Otherwise, for safepoints, and for exception tables, it could be also really useful to install call backs to let VMKit manages them itself (but it's maybe provided by the safepoint/patchpoint patch?)? (with something that can make the association...

...> <null, List<>, stubForG>. > > After f's compilation, it could be something like that > > <null, List<RelocationTable-of-module-f>, stubForG>. > > And after the compilation of g, something like > > <moduleOfG, List<Reloc-f, Reloc-g>, compiledCode-of-g> > > with the relocation entries updated? > > Otherwise, for safepoints, and for exception tables, it could be also really useful to install call backs to let VMKit manages them itself (but it's maybe provided by the safepoint/patchpoint patch?)? (with something that can mak...

...> <null, List<>, stubForG>. > > After f's compilation, it could be something like that > > <null, List<RelocationTable-of-module-f>, stubForG>. > > And after the compilation of g, something like > > <moduleOfG, List<Reloc-f, Reloc-g>, compiledCode-of-g> > > with the relocation entries updated? > > Otherwise, for safepoints, and for exception tables, it could be also > really useful to install call backs to let VMKit manages them itself > (but it's maybe provided by the safepoint/patchpoint patch?)? (with > some...

...ubForG>. >> >> After f's compilation, it could be something like that >> >> <null, List<RelocationTable-of-module-f>, stubForG>. >> >> And after the compilation of g, something like >> >> <moduleOfG, List<Reloc-f, Reloc-g>, compiledCode-of-g> >> >> with the relocation entries updated? >> >> Otherwise, for safepoints, and for exception tables, it could be also >> really useful to install call backs to let VMKit manages them itself >> (but it's maybe provided by the safepoint/patchpoint pat...

...;> After f's compilation, it could be something like that >>> >>> <null, List<RelocationTable-of-module-f>, stubForG>. >>> >>> And after the compilation of g, something like >>> >>> <moduleOfG, List<Reloc-f, Reloc-g>, compiledCode-of-g> >>> >>> with the relocation entries updated? >>> >>> Otherwise, for safepoints, and for exception tables, it could be also >>> really useful to install call backs to let VMKit manages them itself >>> (but it's maybe provided by the...

Hi Andy, We had previous discussions about this, I'd like to state more exactly what features would make MCJIT a replacement for the JIT. After putting significant effort trying to move to MCJIT, I'm currently back with the JIT. This is in a REPL environment where functions are added and removed dynamically and response time is important. The issue is the legacy JIT provides great

...;> After f's compilation, it could be something like that >>> >>> <null, List<RelocationTable-of-module-f>, stubForG>. >>> >>> And after the compilation of g, something like >>> >>> <moduleOfG, List<Reloc-f, Reloc-g>, compiledCode-of-g> >>> >>> with the relocation entries updated? >>> >>> Otherwise, for safepoints, and for exception tables, it could be >>> also really useful to install call backs to let VMKit manages them >>> itself (but it's maybe provided by th...

...ilation, it could be something like that >>>> >>>> <null, List<RelocationTable-of-module-f>, stubForG>. >>>> >>>> And after the compilation of g, something like >>>> >>>> <moduleOfG, List<Reloc-f, Reloc-g>, compiledCode-of-g> >>>> >>>> with the relocation entries updated? >>>> >>>> Otherwise, for safepoints, and for exception tables, it could be >>>> also really useful to install call backs to let VMKit manages them >>>> itself (but it'...

...ilation, it could be something like that >>>> >>>> <null, List<RelocationTable-of-module-f>, stubForG>. >>>> >>>> And after the compilation of g, something like >>>> >>>> <moduleOfG, List<Reloc-f, Reloc-g>, compiledCode-of-g> >>>> >>>> with the relocation entries updated? >>>> >>>> Otherwise, for safepoints, and for exception tables, it could be >>>> also really useful to install call backs to let VMKit manages them >>>> itself (but it...

Hi Gaël, I'm not familiar enough with the details of the old JIT engine and its event interface to comment on whether or not your changes are appropriate, but I'm not sure anyone is so the patch is probably OK as is. I don't see any obvious problems with it. However, your description of the changes raises a bigger issue in my mind. I'm not sure if you are aware of this, but