similar to: The ByteCompile & LazyLoading fields

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

Dear all, I am using the CRAN_package_db function to determine whether the head versions of certain packages match those I need. The parallel package though, is missing from the database: > pdb <- tools:::CRAN_package_db() > pdb[pdb$Package=="parallel",]["Package"] [1] Package <0 rows> (or 0-length row.names) Is this a bug that needs to be reported (where?) ?

Hi Lu?s, The parallel package is built-in, and so is not distributed via cran. You'll see the same thing for all the built in packages, e.g., > pdb[pdb$Package=="stats",]["Package"] [1] Package <0 rows> (or 0-length row.names) > pdb[pdb$Package=="splines",]["Package"] [1] Package <0 rows> (or 0-length row.names) >

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

Hi, I tried compiling the latest pre-release for R 3.3.3 for the NixOS Linux distribution [1], but the build fails during the "make check" phase because of the following 2 issues: 1) The "tools" test in "tests/Examples" requires network access, which it doesn't have in our build environment. Therefore, it fails as follows according to

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,

Hi Folks, I have a question regarding LLD support for ld64 mach-o linker synthesised symbols. I did a quick search of the LLD source and I can not find support for them so before I start trying to use lld I thought I would ask. I have found a couple of cases where they are essential. i.e. where there is no other way to get the required information, such as getting the address of the mach-o

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,

Hi Rui, The motivation would be primarily that LLVM/Clang/LLD are community projects such that if I or someone in the community added support for e.g. symbol aliases, then it could be reviewed and potentially merged. ld64 on the other hand does not have a community process for patch submission and code review that I am aware of so its unlikely that if someone from the community came up with a

I'm not trying to create a mirror of the CRAN. I also do not want to create a "subset" of CRAN packages. Sorry if my explanation was confusing. There are internal proprietary R packages that I would like to host on a private repo. I like the CRAN web pages that allow a user to browse the various packages from a browser without having to first install them. I want to duplicate the

>>>>> Peter Simons <simons at nospf.cryp.to> >>>>> on Mon, 27 Feb 2017 10:30:39 +0100 writes: > Hi, I tried compiling the latest pre-release for R 3.3.3 > for the NixOS Linux distribution [1], but the build fails > during the "make check" phase because of the following 2 > issues: > 1) The "tools" test

On 27/02/2017 09:30, Peter Simons wrote: > Hi, > > I tried compiling the latest pre-release for R 3.3.3 for the NixOS Linux > distribution [1], but the build fails during the "make check" phase > because of the following 2 issues: Hmm, R-devel (your subject line) is not a pre-release of R 3.3.3: it is 'R Under development' for what is planned as R 3.4.0.

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

Hola! I got past the problems I asked about two days ago, thanks. No I am updating CRAN package asypow (the daily package check on CRAN gave warnings due to .Rd problems, fixed). Now it PASSED Rcmd check (WindowsXP home edition, rw2000dev, on a new toshiba laptop, if that matters.) but then Rcmd build --binary gives problems: . . . preparing package asypow for lazy loading Error in

Is there a global option somewhere that can completely disable the LazyLoad option? I want all my packages in source format for searching purposes, crippled by the conversion to database format. ---------------------------------------------------------- SIGSIG -- signature too long (core dumped)

On Tue, Jun 6, 2017 at 11:14 PM, Michael Clark via llvm-dev < llvm-dev at lists.llvm.org> wrote: > OK. I see that the Mach-O linker is not even built when LLD is enabled in > Release_40, only the PE/COFF and ELF linkers are built. > > From looking at reviews it appears that Clang was able to be linked with > LLD on Darwin about 2 years ago, so Mach-O support seems to have

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:

> I'm surprised this wasn't captured by the url checker on CRAN. As was I > Are you suggesting a new check on package descriptions for the urls present? Yes - but more fixing edge cases than a new check > In that case I guess it could be part of the standard R CMD check. Yep. Kurt's message suggests that these were edge cases that missed the check. Thanks > > Llu?s

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