search for: bytecompil

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&...

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

.../ 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 file , rpmbuild tried to optimize the python byte coded files , which i can see from ( i guess macros ) " + /usr/lib/rpm/brp-python-bytecompile" , and fails after that . http://pastie.org/1236040 please help me about controlling this behaviour so that I can skip the "brp-python-bytecompile" section . Thanks in advance , Saurabh Verma -------------- next part -------------- An HTML attachment was scrubbed... URL: <http...

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

...ple that provided some usable evidence. > > Duncan Murdoch > > > I don't have Windows so am not able to test unfortunately. > data.table makes no calls to .Internal(). Such calls are caught and > prevented by R CMD check. > Both data.table and copula contain "ByteCompile: yes" in their > DESCRIPTION files. Does the toy package break with that setting? > Matt > That's it. With "ByteCompile: yes" I get the same error. I don't know if there's anything we can do about this now, but we should be able to avoid it in the future....

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

...Terry T. -------------- Title: Survival Analysis Maintainer: Terry M Therneau <therneau.terry at mayo.edu> Priority: recommended Package: survival Version: 3.2-6 Date: 2020-09-24 Depends: R (>= 3.4.0) Imports: graphics, Matrix, methods, splines, stats, utils LazyData: Yes LazyLoad: Yes ByteCompile: Yes Authors at R: c(person(c("Terry", "M"), "Therneau", email="therneau.terry at mayo.edu", role=c("aut", "cre")), person("Thomas", "Lumley", role=c("ctb", &...

...'d > welcome an example that provided some usable evidence. > > Duncan Murdoch > > I don't have Windows so am not able to test unfortunately. data.table makes no calls to .Internal(). Such calls are caught and prevented by R CMD check. Both data.table and copula contain "ByteCompile: yes" in their DESCRIPTION files. Does the toy package break with that setting? Matt [[alternative HTML version deleted]]

...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? -...

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

...(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 entir...

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

...erhead in each call, but still a 25-50% speedup compared to '::'. (c) is a smarter version of (b) that does the look up only ones, and managed to reduce the overhead to 10% of '::'. It's still 50 times the overhead of a direct dim(x) call. Since one can byte compile packages (ByteCompile: TRUE in DESCRIPTION), I've also played around with compiler::cmpfun() and that prunes off about 10% of the non-compiled ditto. I was somewhat/naively hoping that the compiler would be able to compile base::dim into a "constant", but that doesn't seem to be the case. BTW, is t...

...(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 entir...

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(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...

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

...000000 --dwz-max-die-limit 110000000 /root/rpmbuild/BUILD/strictures-2.000006 /usr/lib/rpm/sepdebugcrcfix: Updated 0 CRC32s, 0 CRC32s did match. + /usr/lib/rpm/check-buildroot + /usr/lib/rpm/redhat/brp-compress + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip + /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1 + /usr/lib/rpm/redhat/brp-python-hardlink + /usr/lib/rpm/redhat/brp-java-repack-jars Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.RIav4H + umask 022 + cd /root/rpmbuild/BUILD + cd strictures-2.000006 + make test PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM&quot...