similar to: Segmentation fault when options(max.print = .Machine$integer.max)

Hi Martin, It is really a 'PATH' problem. After adding C:\Program Files\Graphviz2.20\bin to the 'PATH' environment variable, the Rgraphviz package can be loaded without any error messages. Sorry that I ONLY set my 'PATH' environment variable correctly for R but not for Graphviz. Thank you and Duncan so much for your great help. Howard On Tue Mar 30 18:12:54

Hi Gabor, I just used your R code below and the code worked properly without any error messages. Attached is the output graph, which may be the one you expected. library("Rgraphviz") set.seed(123) V <- letters[1:10] M <- 1:4 g1 <- randomGraph(V, M, 0.2) g1 plot(g1) Thanks. Howard On Wed Mar 31 11:18:25 EDT 2010, Gabor Grothendieck <ggrothendieck at

On 08/25/2015 01:30 PM, Kevin Ushey wrote: > Hi Martin, > > Indeed it does (and I should have confirmed myself with R-patched and R-devel > before posting...) actually I don't know that it does -- it addresses the symptom but I think there should be an error from libcurl on the 403 / 404 rather than from read.dcf on error page... Martin > > Thanks, and sorry for the

as.factor / as.ordered is not written as a generic. This differs from as.numeric, as.matrix, and other as.*. The following seems to address this and does not break make check-all. FWIW, the patch is against r55563, because with r55564 I see /home/mtmorgan/src/R-devel/src/main/dounzip.c:75:15: error: storage size of ?dt? isn?t known /home/mtmorgan/src/R-devel/src/main/dounzip.c:88:5: warning:

>>>>> Martin Morgan <mtmorgan at fredhutch.org> >>>>> on Mon, 11 May 2015 10:18:07 -0700 writes: > On 05/10/2015 08:19 AM, Martin Morgan wrote: >> Loading an S4 object from a file without first loading the library sometimes (?, >> the example below and actual example involves a virtual base class and the show >> generic)

Loading an S4 object from a file without first loading the library sometimes (?, the example below and actual example involves a virtual base class and the show generic) leads to incorrect dispatch (to the base class method). The attached package reproduces the problem. It has setClass("A") setClass("B", contains="A") setMethod("show", "A",

In fact, this does reproduce on R-devel: > options(download.file.method = "libcurl") > options(repos = c(CRAN = "https://cran.rstudio.com/", CRANextra = + "http://www.stats.ox.ac.uk/pub/RWin")) > install.packages("lattice") ## could be any package Installing package into ?/Users/kevinushey/Library/R/3.3/library? (as ?lib? is

A post on the Bioconductor mailing list https://stat.ethz.ch/pipermail/bioconductor/2009-May/027700.html suggests that install.packages now references .Rprofile (?), whereas in R-2-8 it did not. Is this intentional? The example is, in .Rprofile library(utils) install.packages("Biobase", repos="http://bioconductor.org/packages/2.4/bioc") then

This bug appears intermittently in R CMD check when reference classes have finalize methods. The problem is that garbage collection can be run after the methods package is no longer available. It affects (periodically) the Bioconductor AnnotationDbi package as well as packages that contain Rcpp classes. To reproduce: library(methods) a = setRefClass("A",

PkgA has a single R/binding.R file containing .A <- setRefClass("A", methods=list(initialize=function(...) {})) .onLoad <- function(...) .A() A NAMESPACE with import(methods) exportClasses("A") and DESCRIPTION Package: PkgA Type: Package Title: Documenting reference classes Version: 0.0.1 Date: 2012-08-05 Author: Martin

In pvec(list(1, 2), FUN, mc.cores=2) FUN sees integer() arguments whereas pvec(list(1, 2, 3), FUN, mc.cores=2) FUN sees list() arguments; the latter seems consistent with pvec's description. This came up in a complicated Bioconductor thread about generics and parallel evaluation https://stat.ethz.ch/pipermail/bioc-devel/2012-October/003745.html One relevant point is that a

Hello, Since people have whisperred about Rcpp, I'd like to play too. > On 11/15/2010 07:45 AM, Patrick Leyshock wrote: >> Very helpful, thank you. >> >> A couple other questions, please: >> >> 1. I've got a function written in C, named "my_c_function". In my R >> code I call this function, passing to it an INTSXP and a STRSXP, >>

It would be convenient if, under R-devel r56422, packages that require re-installation because they do not have a NAMESPACE were marked as old.packages, so their lack of functionality can be discovered more easily. > "snow" %in% row.names(old.packages()) [1] FALSE > library(snow) Error in library(snow) : package 'snow' does not have a NAMESPACE and should be

Hi Martin, Indeed it does (and I should have confirmed myself with R-patched and R-devel before posting...) Thanks, and sorry for the noise. Kevin On Tue, Aug 25, 2015, 13:11 Martin Morgan <mtmorgan at fredhutch.org> wrote: > On 08/25/2015 12:54 PM, Kevin Ushey wrote: > > Hi all, > > > > The following fails for me (on OS X, although I imagine it's the same >

--- On Sun, 13/2/11, Shing Hing Man <matmsh at yahoo.com> wrote: > From: Shing Hing Man <matmsh at yahoo.com> > Subject: Re: [R] Linked List in R > To: "Martin Morgan" <mtmorgan at fhcrc.org> > Date: Sunday, 13 February, 2011, 4:49 > Hi Martin, > ? Thanks for the pointer ! It seems quite involved to > create a > a linked list in the oo way. I

R-devel r69197 returns appropriate errors for the cases below; I know of a few rough edges - ftp error codes are not reported correctly - download.file creates destfile before discovering that http fails, leaving an empty file on disk and am happy to hear of more. Martin On 08/27/2015 08:46 AM, Jeroen Ooms wrote: > On Thu, Aug 27, 2015 at 5:16 PM, Martin Maechler > <maechler at

> And in general a developer would avoid masking a function > in a base package, so as not to require the user to distinguish > between stats::density() and igraph::density(). Maybe the > example is not meant literally. The 'filter' function in the popular 'dplyr' package masks the one that has been in the stats package forever, and they have nothing in common, so that

While trying to install a package, I received this error ** preparing package for lazy loading Error in matchSignature(signature, fdef, where) : more elements in the method signature (2) than in the generic signature (1) A more helpful variant is Error in matchSignature(signature, fdef, where) : more elements in the method signature (2) than in the generic signature (1) for function

On 05/10/2015 08:19 AM, Martin Morgan wrote: > Loading an S4 object from a file without first loading the library sometimes (?, > the example below and actual example involves a virtual base class and the show > generic) leads to incorrect dispatch (to the base class method). > > The attached package reproduces the problem. It has The package was attached but stripped; a version is

In the context of installing a Bioconductor package using our biocLite() function, install.packages() warns > install.packages("RUVSeq", repos="http://bioconductor.org/packages/2.14/bioc") Installing package into '/home/mtmorgan/R/x86_64-unknown-linux-gnu-library/3.1-2.14' (as 'lib' is unspecified) Warning message: package 'RUVSeq' is not available