search for: bytecompiler

Hi, In the DESCRIPTION file the ByteCompile and LazyLoading arguments appear to accept any value. >From the manual the field should be a "logical field". However, authors interpret this in a variety of ways: unique(tools::CRAN_package_db()$ByteCompile) # [1] NA "TRUE" "yes" "true" "Yes" "no" #

Hello, I would like to the use the 'ByteCompile' field in R 2.14. However, "Writing R Extensions" only describes this field, but does not say what value it should be set to. How should i use it? Do you have examples? Is it the same as "LazyData: yes"? Thank you, Slava

HI people , I am not sure whether this is right mailing list for this question , but i tried subscribing to redhat rpm list , failed to do so . I'm facing a issue while creating RPM for python punjab http://code.stanziq.com/punjab/ I've created a spec file which contains the list of files to packaged http://pastie.org/1236027 And when i try to run rpmbuild -ba command on this spec

I was trying to ByteCompile a package that I made. The package compiles successfully with byte compile set to FALSE. When I set ByteCompile to TRUE, I receive the following error message while doing R CMD INSTALL /usr/lib/R/bin/INSTALL: line 34: 9964 Done echo 'tools:::.install_packages()' 9965 Segmentation fault | R_DEFAULT_PACKAGES= LC_COLLATE=C "${R_HOME}/bin/R" $myArgs

On 05/10/2015 8:25 PM, Matt Dowle wrote: > > On Mon, Oct 5, 2015 at 4:57 PM, Duncan Murdoch <murdoch.duncan at gmail.com > <mailto:murdoch.duncan at gmail.com>> wrote: > > On 05/10/2015 7:24 PM, Matt Dowle wrote: > > Joris Meys <jorismeys <at> gmail.com <http://gmail.com>> writes: > > > >> > >> Hi all,

H, I was trying to ByteCompile a package that I made. The package compiles successfully with byte compile set to FALSE. When I set ByteCompile to TRUE, I receive the following error message while doing R CMD INSTALL /usr/lib/R/bin/INSTALL: line 34: 9964 Done echo 'tools:::.install_packages()' 9965 Segmentation fault | R_DEFAULT_PACKAGES= LC_COLLATE=C "${R_HOME}/bin/R" $myArgs

When I run R CMD check on the survival package I invariably get a note: ... * checking for file ?survival/DESCRIPTION? ... OK * this is package ?survival? version ?3.2-6? * checking CRAN incoming feasibility ... NOTE Maintainer: ?Terry M Therneau <therneau.terry at mayo.edu>? ... This is sufficient for the auto-check process to return the following failure message: Dear maintainer,

On Mon, Oct 5, 2015 at 4:57 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 05/10/2015 7:24 PM, Matt Dowle wrote: > > Joris Meys <jorismeys <at> gmail.com> writes: > > > >> > >> Hi all, > >> > >> I have a puzzling problem related to nchar. In R 3.2.1, the internal > > nchar > >> gained an extra

...e of the problem but haven't been > able find it. > > -Winston Apologies in advance if this is just stating the obvious, but let me try and put some general ideas on the table. - is anything non-deterministic involved? (Doesn't sound so, but...) - could it be something with the bytecompiler? - can you get something (_anything_) to trigger the bug (in any variant) when running R under gdb? I'm thinking gctorture() etc. - it is odd that you cannot immediately get the same behaviour with R -d gdb or valgrind. Are you sure you are actually running the same script in the same way? - if...

...een >> able find it. >> >> -Winston > > Apologies in advance if this is just stating the obvious, but let me try and put some general ideas on the table. > > - is anything non-deterministic involved? (Doesn't sound so, but...) > - could it be something with the bytecompiler? Also my suspicion, can you try without having JIT enabled? Best, Uwe Ligges > - can you get something (_anything_) to trigger the bug (in any variant) when running R under gdb? I'm thinking gctorture() etc. > - it is odd that you cannot immediately get the same behaviour with R -d g...

>>>>> Suharto Anggono Suharto Anggono via R-devel >>>>> on Sun, 31 Mar 2019 15:26:13 +0000 writes: > Ah, with R 3.5.0 or R 3.4.2, but not with R 3.3.1, 'eval' > inside 'for' makes compiled version behave like > non-compiled version. Ah.. ... thank you for detecting that " eval() inside for()" behaves specially

In DESCRIPTION if I set LazyLoad to 'yes' will data.table (for example) then be byte compiled for users who install the binary package from CRAN on Windows? This question is based on reading section 1.2 of this document : http://www.divms.uiowa.edu/~luke/R/compiler/compiler.pdf I've searched r-devel and Stack Overflow history and have found questions and answers relating to R CMD

On Sat, Nov 15, 2014 at 1:47 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > > On 14/11/2014, 9:06 PM, Henrik Bengtsson wrote: > > I've meant to ask the following for several years now. I understand why: > > > >> foo <- function(x, dim=dim) { dim } > >> foo(1) > > Error in foo(1) : > > promise already under evaluation:

With f <- function(x) for (i in 1) x fc <- cmpfun(f) (my previous example), error message of fc(is.numeric(y)) shows the originating call as well, while error message of f(is.numeric(y)) doesn't. Compiled version behaves differently. Even with f <- function(x) for (i in 1) {x; eval(expression(i))} fc <- cmpfun(f) , error message of fc(is.numeric(y)) shows the originating call in R

Hi, I think I've found a bug in R CMD INSTALL. When it tries to parse a DESCRIPTION file with an invalid LazyData field, it errors out while trying to print the correct error message: > R CMD INSTALL . * installing to library ?/home/example/R/x86_64-pc-linux-gnu-library/3.4? * installing *source* package ?samplepackage? ... ** data Error in errmsg("invalid value of ", field,

On 05/10/2015 7:24 PM, Matt Dowle wrote: > Joris Meys <jorismeys <at> gmail.com> writes: > >> >> Hi all, >> >> I have a puzzling problem related to nchar. In R 3.2.1, the internal > nchar >> gained an extra argument (see >> https://stat.ethz.ch/pipermail/r-announce/2015/000586.html) >> >> I've been testing code using the

On Mon, 1 Apr 2019, Martin Maechler wrote: >>>>>> Suharto Anggono Suharto Anggono via R-devel >>>>>> on Sun, 31 Mar 2019 15:26:13 +0000 writes: > > > Ah, with R 3.5.0 or R 3.4.2, but not with R 3.3.1, 'eval' > > inside 'for' makes compiled version behave like > > non-compiled version. > > Ah.. ... thank

Ah, with R 3.5.0 or R 3.4.2, but not with R 3.3.1, 'eval' inside 'for' makes compiled version behave like non-compiled version. options(error = expression(NULL)) library(compiler) enableJIT(0) f <- function(x) for (i in 1) {x; eval(expression(i))} f(is.numeric(y)) # Error: object 'y' not found fc <- cmpfun(f) fc(is.numeric(y)) # Error: object 'y' not found

) On Wed, Apr 5, 2017 at 2:59 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote: > > >>>>> Winston Chang <winstonchang1 at gmail.com> > >>>>> on Tue, 4 Apr 2017 15:29:40 -0500 writes: > > > I've done some more investigation into the problem, and it is very > > difficult to pin down. What it looks like is

On Monday 11 March 2019 14:28:38 Pete Biggs wrote: > > However, as I went for bigger modules, anything that had dependences > > were then failing as the dependencie were installed OK but then did not > > appear to be available. > A number of things you can do. The sort of recommended way is to > package the perl modules into an RPM and install them that way (so that >