search for: bytecompiled

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

> On 05 Apr 2017, at 20:40 , Winston Chang <winstonchang1 at gmail.com> wrote: > > I think there's a good chance that this is due to a bug in R. I have > been trying to track down the cause 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

On 05.04.2017 23:54, peter dalgaard wrote: > >> On 05 Apr 2017, at 20:40 , Winston Chang <winstonchang1 at gmail.com> wrote: >> >> I think there's a good chance that this is due to a bug in R. I have >> been trying to track down the cause of the problem but haven't been >> able find it. >> >> -Winston > > Apologies in advance if this

...(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 I've tried more examples and did not find any difference between simple interpreted and bytecompiled code {apart from "keep.source=TRUE" keeping source, sometimes visible}. So I don't understand yet why you think the byte compiler plays a role. Rather the crucial difference seems the error happens inside a loop which contains an explicit eval(.), and that eval() may even be entirel...

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:

...(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 I've tried more examples and did not find any difference between simple interpreted and bytecompiled code {apart from "keep.source=TRUE" keeping source, sometimes visible}. So I don't understand yet why you think the byte compiler plays a role. Rather the crucial difference seems the error happens inside a loop which contains an explicit eval(.), and that eval() may even be entirel...

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

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(i))} > > f(is.numeric(y)) > > # Error: object 'y' not found > > fc <- cmpfun(f) > > fc(is.numeric(y)) > > # Error: object 'y' not found > > I've tried more examples and did not find any difference > between simple interpreted and bytecompiled code {apart > from "keep.source=TRUE" keeping source, sometimes visible}. > So I don't understand yet why you think the byte compiler plays > a role. > > Rather the crucial difference seems the error happens inside a > loop which contains an explicit eval(.), and th...

) 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 >