similar to: problem with png() and large dimensions on some 32-bit Windows machines

Hello, I have come across two separate packages that have a Makefile in inst/doc which use the R_HOME variable. In both cases, the path to R_HOME gets munged in such a way that commands that include R_HOME fail on Windows: For example, one Makefile, for the xmapcore package ( https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/xmapcore/username/password: readonly) has this:

Hi, > url <- "ftp://ftp.ncbi.nlm.nih.gov/genomes/ASSEMBLY_REPORTS/All/GCF_000001405.13.assembly.txt" > download.file(url, tempfile()) trying URL 'ftp://ftp.ncbi.nlm.nih.gov/genomes/ASSEMBLY_REPORTS/All/GCF_000001405.13.assembly.txt' Error in download.file(url, tempfile()) : cannot open URL

----- Original Message ----- > From: "Uwe Ligges" <ligges at statistik.tu-dortmund.de> > To: "Dan Tenenbaum" <dtenenba at fredhutch.org>, "R-devel at r-project.org" <r-devel at r-project.org> > Sent: Saturday, August 8, 2015 3:57:34 PM > Subject: Re: [Rd] download.file() on ftp URL fails in windows with default download method > >

Hi, in Section 'Writing package vignettes' of 'Writing R Extensions' it says: "Whenever a Makefile is found, then R CMD build will try to run make after the Sweave runs, so PDF manuals can be created from arbitrary source formats (plain LaTeX files, ...). [...] Note that the make step is executed even if there are no files in Sweave format, [...]". In my package,

We were also able to reproduce the issue on Windows Server 2012. If there's anything we can do to help please let me know; Elliot Waingold (CC'd here) can provide access to the VM we used for testing if that's of any help. # David Smith -- David M Smith <davidsmi at microsoft.com> R Community Lead, Revolution Analytics (a Microsoft company)? Tel: +1 (312) 9205766 (Chicago IL,

Sorry, I should have been more clear -- if I write the contents of that script to a file called 'encoding.R' and source that, then I see the reported behavior. Here's something standalone that you should hopefully be able to copy + paste into RGui to reproduce: code <- ' x <- 1 print(list()) save(x, file = tempfile()) output <- encodeString("apple")

Hi, One of the functions I use needs to write to a temporary file, in the directory given by tempdir(). I want to change this from the standard one, as the file is too large for the drive. However, tempfile() doesnt seem to respect the environment variables when I change them with Sys.setenv(). In a fresh R-session: > Sys.getenv("TMP") [1]

Fixed in R-devel and R-patched, Tomas On 07/18/2018 12:03 PM, Tomas Kalibera wrote: > Thanks, I can now reproduce and it is a bug that is easy to fix, I > will do so shortly. > > Fyi it can be reproduced simply by running these two lines in Rgui: > > list() > encodeString("apple") > > Best > Tomas > > On 07/17/2018 05:16 PM, Kevin Ushey wrote:

hello, the last line of the code below causes a segfault for me on 3.4.1. i think i should submit to https://bugs.r-project.org/ unless others have advice? thanks install.packages( "devtools" ) devtools::install_github("ajdamico/lodown") devtools::install_github("jimhester/archive") file_folder <- file.path( tempdir() , "file_folder" ) tf <-

Hello, I think there is a problem in recent devel builds of R on Windows with various devices from the grDevices package. For example: > capabilities() jpeg png tiff tcltk X11 aqua http/ftp sockets TRUE TRUE TRUE TRUE FALSE FALSE TRUE TRUE libxml fifo cledit iconv NLS profmem cairo TRUE FALSE TRUE TRUE

hi, thanks again for taking the time. since corrupted compression prompted the segfault for me in the first place, i've just posted the text file as-is. it's a 2.4GB file so to be avoided on a metered internet connection. i've updated the bugzilla report at https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17311 with more relevant info. these lines of code crash both windows R

On 15/07/2017 7:35 AM, Anthony Damico wrote: > hello, the last line of the code below causes a segfault for me on 3.4.1. > i think i should submit to https://bugs.r-project.org/ unless others have > advice? thanks Segfaults are usually worth reporting as bugs. Try to come up with a self-contained example, not using the lodown and archive packages. I imagine you can do this by

hi, thanks Dr. Murdoch i'd appreciate if anyone on r-help could help me narrow this down? i believe the segfault occurs because there's a single line with 4GB and also embedded nuls, but i am not sure how to artificially construct that? the lodown package can be removed from my example.. it is just for file download cacheing, so `lodown::cachaca` can be replaced with `download.file`

Hi, FYI, I just notice that on Windows (but not Linux) it is orders of magnitude (below it's 50x) faster to serialize() and object to a temporary file and then read it back, than to serialize to an object directly. This has for instance impact on how fast digest::digest() can provide a checksum. Example: x <- 1:1e7; t1 <- system.time(raw1 <- serialize(x, connection=NULL));

hi, i realized that the segfault happens on the text file in a new R session. so, creating the segfault-generating text file requires a contributed package, but prompting the actual segfault does not -- pretty sure that means this is a base R bug? submitted here: https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17311 hopefully i am not doing something remarkably stupid. the text file

The original file had a lot of trailing null bytes so I tried making a similar file with: tf <- tempfile(); file <- file(tf, "wb") for(i in 1:(2^15-1))writeBin(rep(as.raw(32:127), len=2^16), file) for(i in 1:(2^15-1))writeBin(rep(as.raw(0L), len=2^16), file) close(file) log2(file.size(tf)) #[1] 31.99996 Reading this with readLines() caused R-3.4.0 to segfault in Rf_con_pushback

I am not able to reproduce your segfault on a Windows 7 platform either: ########################## fn1 <- "d:/DADOS_ENEM_2009.txt" sessionInfo() ## R version 3.4.1 (2017-06-30) ## Platform: x86_64-w64-mingw32/x64 (64-bit) ## Running under: Windows 7 x64 (build 7601) Service Pack 1 ## ## Matrix products: default ## ## locale: ## [1] LC_COLLATE=English_United States.1252 ## [2]

I am stuck. The archive package won't compile for me on Ubuntu, and the CRANextra repo seems to be down so I cannot install packages on Windows right now. Perhaps you can zip the corrupt text file and put it online somewhere? Don't use the archive package to pack it since there seem to be issues with that tool on your machine. I would discourage you from harassing the Brazilian

hi, thank you for attempting this. it looks like your unix machine unzipped the txt file without corruption -- if you copied over the same txt file to windows 7, i don't think that would reproduce the problem? i think it needs to be the corrupted text file where R.utils::countLines( txtfile ) gives 809367. i am able to reproduce on two distinct windows machines but no guarantee i'm

hi, yep, there are two problems -- but i think only the segfault is within the scope of a base R issue? i need to look closer at the corrupted decompression and figure out whether i should talk to the brazilian government agency that creates that .rar file or open an issue with the archive package maintainer. my goal in this thread is only to figure out how to replicate the goofy text file so