similar to: Bug in read.dcf(all = TRUE)?

BIll, Thanks. I am seeing some problems here, for example when all the fields are missing, or all the fields in a row are missing. I've fixes for those, and will commit to R-devel shortly. On Tue, 17 Jul 2007, bill at insightful.com wrote: > Full_Name: Bill Dunlap > Version: 2.5.0 > OS: Red Hat Enterprise Linux WS release 3 (Taroon Update 6) > Submission from: (NULL)

The change in r42731 eliminating the final blank line when writing DCF files changes the way 'append' can be used in 'write.dcf' and I was wondering if this is intentional. Basically, I want to write a data frame to DCF format one row at a time, so I make use of repeated calls to 'write.dcf(append = TRUE)'. However, in R 2.6.0RC the resulting DCF file is not formatted

Full_Name: charles blundell Version: 2.7.0 OS: Debian GNU/Linux Submission from: (NULL) (217.37.73.202) The Debian Policy Manual says concerning lines in a Description field: * Those containing a space, a full stop and some more characters. These are for future expansion. Do not use them. (section 5.6.13, http://www.debian.org/doc/debian-policy/ch-controlfields.html) But for example: >

Hi, on all my systems update.packages() and install.packages() fails now. I get the following message: root at orca:/root(28)# R R version 2.10.1 (2009-12-14) Copyright (C) 2009 The R Foundation for Statistical Computing ISBN 3-900051-07-0 R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or

Dear R devs, I would like to raise a request for a simple helper function. Utility function to extract package dependencies from DESCRIPTION file. I do think that tools package is better place, for such a fundamental functionality, than community packages. tools pkg seems perfect fit (having already great function write_PACKAGES). Functionality I am asking for is already in R svn repository

I'm seeing a segfault on x86_64 Linux with the following code: desc = read.dcf("BAD") con = gzfile("test.gz", "wt") write.dcf(desc, file=con) close(con) where BAD has a long field (see below for example). The crash happens inside dummy_vfprintf. I think the issue is that the va_list ap is modified by the first vsnprintf call

Thank you Gabriel, Just for future readers. Below is a base R way to address this common problem, as instructed by you (+stopifnot to suppress print). Rscript -e 'stopifnot(file.copy("DESCRIPTION", file.path(tdir<-tempdir(), "PACKAGES"))); db<-available.packages(paste0("file://", tdir));

Dear R-Users, I'm trying to setup a personal repository for a few packages I'm working on. I am on R-Forge but I still need to have various versions of my package that R-Forge does not build (for R 2.8.1 for example). So I followed the instructions in this document: Hhttp:// cran.r-project.org/doc/manuals/R-admin.html#Setting-up-a-package-repository and used this function as

Was looking at what was output for <pkgname>-package.Rd and wondered if any there was any means (via macro, etc) to merge some of the same information with a template for my package manpage? As much (all?) of the generated information was already provided in the DESCRIPTION, I'd prefer not to have to update the information in multiple places. I'm thinking here that I could provide a

On RedHat Enterprise Linux 6, the test below fails (this is using the stock GCC 4.4.7) from R-devel r72707. LC_CTYPE is unset when I run it, but LANG=en_US.UTF-8 It also failed "yesterday" where as far as I recall the test code looked a bit different. Best, Kasper > ## Results differed by platform, but some gave incorrect results on string 10. > > > ## str() on large

>>>>> Kasper Daniel Hansen <kasperdanielhansen at gmail.com> >>>>> on Fri, 19 May 2017 20:09:24 -0400 writes: > I rebuilt R with > export LC_CTYPE=en_US.UTF-8 > and the test still fail. Surprisingly, when I run R from the bin directory > and execute the test code, it runs without error: >> oloc <-

Full_Name: Bill Dunlap Version: 2.5.0 OS: Red Hat Enterprise Linux WS release 3 (Taroon Update 6) Submission from: (NULL) (24.17.60.30) If you read a dcf file with read.dcf(file,fields=c("Field",...)) and the file does not contain the desired field "Field", read.dcf puts a character NA for that entry in its output matrix. If you then call write.dcf, passing it the output of

Yes, collation is a strange thing, and? Collation order will depend on locale settings, and there are quite a few cases where the collation order of two items is not defined. To add to the confusion, on OSX Mavericks, I see > x <- "\u0663" > y <- 3 > > x == y [1] FALSE > rank(c(x, y)) [1] 2 1 > x [1] "?" > x == y [1] FALSE > x > y [1] TRUE

I don't know if this is a bug per se, but an undesired behavior in read.dcf. read.dcf takes a file argument and passes it to gzfile if it's a character: if (is.character(file)) { file <- gzfile(file) on.exit(close(file)) } This gzfile connection is passed to readLines (line #39): lines <- readLines(file) If no newline is at the end of the file, readLines

On Mon, Sep 21, 2015 at 2:48 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 21/09/2015 4:50 PM, Herv? Pag?s wrote: >> Hi, >> >> Note that one significant change to read.dcf() that happened since R >> 3.0.2 is the addition of support for arbitrary long lines (commit >> 63281), which never worked: >> >> dcf <- paste(c("aa:

write.dcf(list('my-field' = 1L), tmp <- tempfile()) cat(readLines(tmp)) # my.field: 1 However there's nothing wrong with hyphenated fields per the Debian standard: https://www.debian.org/doc/debian-policy/ch-controlfields.html And in fact we see them using hyphenated fields there, and indeed read.dcf handles this just fine: writeLines(gsub('.', '-',

Hi, I am new to R and I'm looking to perform some method comparison analysis and would be grateful for some help regarding package installation. There is a package 'MethComp' that I want to use (http://staff.pubhealth.ku.dk/~bxc/MethComp/Courses/Sthm.2007/.) Unfortunately I am unable to install it. I have tried numerous approaches but to no avail. this is the first time I have tried to

Diverted from ESS-help. It is really about R's LANGUAGE, locales and then a wish for sessionInfo() : >>>>> Sparapani, Rodney <rsparapa at mcw.edu> >>>>> on Thu, 20 Feb 2014 19:39:33 +0000 writes: >> Just guessing: perhaps this is something that is set when >> R is initialized and not queried every time something is >>

Hi, Note that one significant change to read.dcf() that happened since R 3.0.2 is the addition of support for arbitrary long lines (commit 63281), which never worked: dcf <- paste(c("aa: ", rep(letters, length.out=10000)), collapse="") writeLines(dcf, "test.dcf") nchar(read.dcf("test.dcf")) # aa # [1,] 8186 The culprit being line

Recently I was trying to cite a package where the authors have ? and ? in their names. I found that on Windows the citation() function did not return the authors' names at all, but on Linux there was no problem (sessionInfos at the bottom): On Windows, no author names are returned: #--------------- > citation("readr") To cite package ?readr? in publications use: (2017).