similar to: make error for R 2.13.0 (and 2.12.0)

Hi dear all It's the first time for me to install a developmental version of R, I came across following errors, my system is DISTRIB_ID=Ubuntu DISTRIB_RELEASE=10.04 DISTRIB_CODENAME=lucid DISTRIB_DESCRIPTION="Ubuntu 10.04.1 LTS" I downloaded the dev version of R in cran R source, and downloaded the recommended packages by using wget as described in R manual, and run

I had installed R from source on Fedora Core 3. Then I upgraded to Fedora Core 4, but left R alone. R worked fine, until I trued to update.packages(). Even then, many packages updated just fine, but two of them, cluster and mgcv, failed with the following error message (using cluster as an example): gcc -shared -L/usr/local/lib -o cluster.so clara.o daisy.o dysta.o fanny.o meet.o mona.o pam.o

Please cc me when replying to the list. With Version 2.1.1 (2005-06-20) on Power Mac G5 running Mac OS X 10.4.2 (8C46): Some compilations work (e.g., MatchIt, RGraphics, Zelig), and some don't, e.g., mgcv, spatstat, and the following (Matrix, cluster): trying URL 'http://www.ibiblio.org/pub/languages/R/CRAN/src/contrib/ Matrix_0.98-3.tar.gz' Content type

I am having trouble installing cluster from R-1.5.0-recommended : R CMD INSTALL *.tar.gz ... g77 -fPIC -g -O2 -c pam.f -o pam.o g77 -fPIC -g -O2 -c spannel.f -o spannel.o g77 -fPIC -g -O2 -c twins.f -o twins.o cp: cannot access *.so ERROR: compilation failed for package 'cluster' [34] /home/com1/gilp/Rlibs/R-1.5.0-recommended : This is with R-1.5.0 on Solaris 5.8 using gcc

I have a factor vector of subject races (Asian, Black, Hispanic, White; n=30) that I want to plot with a Cleveland dotplot or dotchart. I tried the following in R2.12.1 : > dotchart(table(school$Race)) Error in plot.xy(xy.coords(x, y), type = type, ...) : invalid plot type Using the same data set in R2.11.1 the operation succeeded (I tried several variations to be sure): >

Hi all, The last e-mails about beginners gave me the courage to post a question; from a beginner's perspective, there are a lot of questions that I'm tempted to ask. But I'm trying to find the answers either in the documentation, either in the about 15 free books I have, either in the help archives (I often found many similar questions posted in the past). Being an (still actual)

> Then the question would be if this test could be replaced with a new > argument to sample, e.g. expandSingle, which has TRUE as default for > backward compatibility, but FALSE if you dont want population to be > expanded to 1:population. It could certainly be useful in some cases, > but you still need to know about the expansion to use it. I think most > of these bugs

Is there an R function to generate a radar or spider graph from a table - e.g. radar(table(x)) or some such? ================================================== Isaac T. Van Patten, Ph.D. Professor Department of Criminal Justice Box 6934, Radford University Radford, VA 24142 540-831-6148 ivanpatt@radford.edu <mailto:ivanpatt@radford.edu> http://ivanpatt.asp.radford.edu

The current R release candidate has a lack of protect bug (of very long standing) with respect to the R_print.na_string and R_print.na_string_noquote fields of the static R_print structure declared in Print.h. This shows up very occassionally as incorrect output from the following lines in reg-tests-2.R: x <- c("a", NA, "b") factor(x) factor(x, exclude="")

Hugh, (Note I speak for myself only and not for R-core) Thanks for looking into this. I think it's great to have community members that are interested in contributing to R and helping it continue to get better. And I think, and my local experiments bear out, that using anyNA as a fastpass condition does allow us to get a significant speedup over what's in there now. To do so, though, I

I've been getting pqR to work on windows systems, and in the process have discovered various problems with R core versions of R and with Rtools. One is with the implementation of OpenMP in 64-bit Rtools. This problem is in Rtools215 and Rtools33, and presumably all the ones in between. You can see the problem with the following test program: #include <stdio.h> #include <omp.h>

Doing the normal build process [1] for a first time with a R 2.0.0 snapshot -- the Sep 21 version I uploaded to Debian's 'experimental' section two days ago, ended in failure. The package in question is cluster 1.9.6 which should be 2.0.0-ready. The (partial) log follows: ----------------------------------------------------------------------------- [...] g77 -mieee-fp -fPIC -g -O2

> > The current R release candidate has a lack of protect bug > > (of very long standing) > > [ but not really reported, right ? ] It's "long standing" because it exists in versions of R going back many years. > but the R 3.2.1 release candidate probably really cannot be > touched now, with something non-trivial like this. > > We'd be

Michael Lawrence (as last in long series of posters)... > Yes, it would bind the language object to the environment, like an > R-level promise (but "promise" of course refers specifically to just > _lazy_ evaluation). > > For the uqs() thing, expanding calls like that is somewhat orthogonal > to NSE. It would be nice in general to be able to write something like >

> Radford Nea: > > So it may make more sense to move towards consistency in the > > permissive direction, rather than the restrictive direction. > > > That would mean allowing matrix(1,1,1) < (1:2), and maybe also things > > like matrix(1,2,2)+(1:8). > > Martin Maechler: > That is an interesting idea. Yes, in my view that would >

On Tue, Jul 14, 2015 at 07:52:56PM -0400, Duncan Murdoch wrote: > On 14/07/2015 6:08 PM, Radford Neal wrote: > > In testing pqR on Solaris SPARC systems, I have found two bugs that > > are also present in recent R Core versions. You can see the bugs and > > fixes at the following URLs: > > > >

> I propose a patch to ifelse that leverages anyNA(test) to achieve an > improvement in performance. For a test vector of length 10, the change > nearly halves the time taken and for a test of length 1 million, there > is a tenfold increase in speed. Even for small vectors, the > distributions of timings between the old and the proposed ifelse do > not intersect. For smaller

Hello, I'm using R 1.40 on MacOS X X.1.2 (installed via the fink package manager). To upgrade my installed packages, I tried to use update.packages() today. All went well for most packages, with the exception of KernSmooth and cluster. In both cases, libraries were not found although I think they are present. Here's what happened: ---------------------------------- >

In testing pqR on Solaris SPARC systems, I have found two bugs that are also present in recent R Core versions. You can see the bugs and fixes at the following URLs: https://github.com/radfordneal/pqR/commit/739a4960a4d8f3a3b20cfc311518369576689f37 https://github.com/radfordneal/pqR/commit/339b7286c7b43dcc6b00e51515772f1d7dce7858 The first bug, in nls, is most likely to occur on a 64-bit

> > But isn't the intent to make it an error later? So I assume we're > > debating making it an error, not just a warning. > > Yes, that's correct. > But if we have a longish deprecation period (i.e. where there's > only a warning) all important code should have been adapted > before it turns to an error That might be true for