Re: [Rd] CRAN Server download statistics (Was: R Usage Statistics)
Hi! Nice work! But keep in mind, that for example the opensuse packages are no longer kept up to date on CRAN, but in openSUSE's Build Service. So the stats are biased towards windows and mac. It seems you only count binary downloads of contributed packages? Introduces some nice bias, too. Nevertheless, a nice starting point. Good luck! Detlef On Sun, 22 Nov 2009 16:18:11 -0800 "Fellows, Ian" wrote: > Hi All, > > It seems that the question of how may people use (or download) R, and it's > packages is one that comes up on a fairly regular basis in a variety of > forums (There was also recent thread on the subject on Stack Overflow). A > couple of students at UCLA (including myself), wanted to address the issue, > so we set up a system to get and parse the cran.stat.ucla.edu APACHE logs > every night, and display some basic statistics. Right now, we have a working > sketch of a site based on one week of observations. > > http://neolab.stat.ucla.edu/cranstats/ > > We would very much like to incorporate data from all CRAN mirrors, including > cran.r-project.org. We would also like to set this up in a way that is > minimally invasive for the site administrators. Internally, our administrator > has set up a protected directory with the last couple days of cran activity. > We then pull that down using curl. > > What would be the best and easiest way for the CRAN mirrors to share their > data? Is the contact information for the administrators available anywhere? > > > Thank you, > Ian Fellows > > > > > From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf > Of Steven McKinney [smckin...@bccrc.ca] > Sent: Thursday, November 19, 2009 2:21 PM > To: Kevin R. Coombes; r-devel@r-project.org > Subject: Re: [Rd] R Usage Statistics > > Hi Kevin, > > What a surprising comment from a reviewer for BMC Bioinformatics. > > I just did a PubMed search for "limma" and "aroma.affymetrix", > just two methods for which I use R software regularly. > "limma" yields 28 hits, several of which are published > in BMC Bioinformatics. Bengtsson's aroma.affymetrix paper > "Estimation and assessment of raw copy numbers at the single locus level." > is already cited by 6 others. > > It almost seems too easy to work up lists of usage of R packages. > > Spotfire is an application built around S-Plus that has widespread use > in the biopharmaceutical industry at a minimum. Vivek Ranadive's > TIBCO company just purchased Insightful, the S-Plus company. > (They bought Spotfire previously.) > Mr. Ranadive does not spend money on environments that are > not appropriate for deploying applications. > > You could easily cull a list of corporation names from the > various R email listservs as well. > > Press back with the reviewer. Reviewers can learn new things > and will respond to arguments with good evidence behind them. > Good luck! > > > Steven McKinney > > > > From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf > Of Kevin R. Coombes [krcoom...@mdacc.tmc.edu] > Sent: November 19, 2009 10:47 AM > To: r-devel@r-project.org > Subject: [Rd] R Usage Statistics > > Hi, > > I got the following comment from the reviewer of a paper (describing an > algorithm implemented in R) that I submitted to BMC Bioinformatics: > > "Finally, which useful for exploratory work and some prototyping, > neither R nor S-Plus are appropriate environments for deploying user > applications that would receive much use." > > I can certainly respond by pointing out that CRAN contains more than > 2000 packages and Bioconductor contains more than 350. However, does > anyone have statistics on how often R (and possibly some R packages) are > downloaded, or on how many people actually use R? > > Thanks, > Kevin > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] CRAN Server download statistics (Was: R Usage Statistics)
Hi All, It seems that the question of how may people use (or download) R, and it's packages is one that comes up on a fairly regular basis in a variety of forums (There was also recent thread on the subject on Stack Overflow). A couple of students at UCLA (including myself), wanted to address the issue, so we set up a system to get and parse the cran.stat.ucla.edu APACHE logs every night, and display some basic statistics. Right now, we have a working sketch of a site based on one week of observations. http://neolab.stat.ucla.edu/cranstats/ We would very much like to incorporate data from all CRAN mirrors, including cran.r-project.org. We would also like to set this up in a way that is minimally invasive for the site administrators. Internally, our administrator has set up a protected directory with the last couple days of cran activity. We then pull that down using curl. What would be the best and easiest way for the CRAN mirrors to share their data? Is the contact information for the administrators available anywhere? Thank you, Ian Fellows From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf Of Steven McKinney [smckin...@bccrc.ca] Sent: Thursday, November 19, 2009 2:21 PM To: Kevin R. Coombes; r-devel@r-project.org Subject: Re: [Rd] R Usage Statistics Hi Kevin, What a surprising comment from a reviewer for BMC Bioinformatics. I just did a PubMed search for "limma" and "aroma.affymetrix", just two methods for which I use R software regularly. "limma" yields 28 hits, several of which are published in BMC Bioinformatics. Bengtsson's aroma.affymetrix paper "Estimation and assessment of raw copy numbers at the single locus level." is already cited by 6 others. It almost seems too easy to work up lists of usage of R packages. Spotfire is an application built around S-Plus that has widespread use in the biopharmaceutical industry at a minimum. Vivek Ranadive's TIBCO company just purchased Insightful, the S-Plus company. (They bought Spotfire previously.) Mr. Ranadive does not spend money on environments that are not appropriate for deploying applications. You could easily cull a list of corporation names from the various R email listservs as well. Press back with the reviewer. Reviewers can learn new things and will respond to arguments with good evidence behind them. Good luck! Steven McKinney From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf Of Kevin R. Coombes [krcoom...@mdacc.tmc.edu] Sent: November 19, 2009 10:47 AM To: r-devel@r-project.org Subject: [Rd] R Usage Statistics Hi, I got the following comment from the reviewer of a paper (describing an algorithm implemented in R) that I submitted to BMC Bioinformatics: "Finally, which useful for exploratory work and some prototyping, neither R nor S-Plus are appropriate environments for deploying user applications that would receive much use." I can certainly respond by pointing out that CRAN contains more than 2000 packages and Bioconductor contains more than 350. However, does anyone have statistics on how often R (and possibly some R packages) are downloaded, or on how many people actually use R? Thanks, Kevin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Dead link in Nile help documentation (PR#14079)
When doing ?Nile, the url for the data source is dead. It says http://www.= ssfpack.com/dkbook/ but this has changed to=20 http://www.ssfpack.com/DKbook.html Version: platform =3D i386-redhat-linux-gnu arch =3D i386 os =3D linux-gnu system =3D i386, linux-gnu status =3D major =3D 2 minor =3D 10.0 year =3D 2009 month =3D 10 day =3D 26 svn rev =3D 50208 language =3D R version.string =3D R version 2.10.0 (2009-10-26) Locale: LC_CTYPE=3Den_US.UTF-8;LC_NUMERIC=3DC;LC_TIME=3Den_US.UTF-8;LC_COLLATE=3Den= _US.UTF-8;LC_MONETARY=3DC;LC_MESSAGES=3Den_US.UTF-8;LC_PAPER=3Den_US.UTF-8;= LC_NAME=3DC;LC_ADDRESS=3DC;LC_TELEPHONE=3DC;LC_MEASUREMENT=3Den_US.UTF-8;LC= _IDENTIFICATION=3DC Search Path: .GlobalEnv, package:stats, package:graphics, package:grDevices, package:ut= ils, package:datasets, package:methods, Autoloads, package:base Thanks, Maarten -- | Dr. Maarten Blaauw | | School of Geography, Archaeology & Palaeoecology | Queen's University Belfast, UK | | www http://www.chrono.qub.ac.uk/blaauw | tel +44 (0)28 9097 3895 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] file_path_as_absolute duplicates "/" (PR#14078)
Full_Name: Jens Oehlschlägel
Version: 2.10.0
OS: Windows XP
Submission from: (NULL) (85.181.157.36)
file_path_as_absolute duplicates "/" for files in the root path,
which goes back to the fact that file.path(dirname(x), basename(x))
currently is not guaranteed to restore x
> x <- "d:/x.RDAta"
> file_path_as_absolute(x)
[1] "d://x.RData"
> file.path(dirname(x), basename(x))
[1] "d://x.RData"
> dirname(x)
[1] "d:/"
> x <- "/"
> file.path(dirname(x), basename(x))
[1] "//"
a possible fix would be to use gsub in file.path before returning, as in
gsub("/+","/","d://x.RData")
This would
- standardize the path returned, e.g. help searching for this path in another
one
- make sure we can use that path in setwd(), because
> setwd("//")
Error in setwd("//") : cannot change working directory
> file.create("//a.txt")
[1] FALSE
Warning message:
In file.create("//a.txt") :
cannot create file '//a.txt', reason 'Invalid argument'
Also note that the help on basename says
"
basename removes all of the path up to the last path separator (if any).
dirname returns the part of the path up to (but excluding) the last path
separator, or "." if there is no path separator.
"
but obviously there is an undocumented exception for the root path (I guess to
have dirname always return a valid path that we can use in e.g. setwd())
> basename("/")
[1] ""
> dirname("/")
[1] "/"
It is not easy to understand that dirname/basename
- neither always split a string into a path and a file component (since in
"/a/b/" it avoids empty basename and "b" goes to basename)
- nor always split a string into the last token in basename and the rest in
dirname (since it avoids empty rest in "/")
So whatever the rules are, it would be helpful to find them in the help,
because
- not everyone knows what basename / dirname usually do under unix (IEEE Std
1003.1)
- R is not following IEEE Std 1003.1 (since basename("/")=="" while IEEE
requires "/")
Help should also explain why and what happens to "servername", is that
dirname, is that basename? Currently we have
> dirname(x)
[1] "."
> basename(x)
[1] "asdfasdf"
> file.path(dirname(x), basename(x))
[1] "./asdfasdf"
> version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 10.0
year 2009
month 10
day26
svn rev50208
language R
version.string R version 2.10.0 (2009-10-26)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)
maech...@stat.math.ethz.ch wrote:
"PD" == Peter Dalgaard
on Fri, 20 Nov 2009 09:54:34 +0100 writes:
PD> m...@celos.net wrote:
>> Arrays of POSIXlt dates always return a length of 9. This
>> is correct (they're really lists of vectors of seconds,
>> hours, and so forth), but other methods disguise them as
>> flat vectors, giving superficially surprising behaviour:
>>
>> strings <- paste('2009-1-', 1:31, sep='')
>> dates <- strptime(strings, format="%Y-%m-%d")
>>
>> print(dates)
>> # [1] "2009-01-01" "2009-01-02" "2009-01-03" "2009-01-04" "2009-01-05"
>> # [6] "2009-01-06" "2009-01-07" "2009-01-08" "2009-01-09" "2009-01-10"
>> # [11] "2009-01-11" "2009-01-12" "2009-01-13" "2009-01-14" "2009-01-15"
>> # [16] "2009-01-16" "2009-01-17" "2009-01-18" "2009-01-19" "2009-01-20"
>> # [21] "2009-01-21" "2009-01-22" "2009-01-23" "2009-01-24" "2009-01-25"
>> # [26] "2009-01-26" "2009-01-27" "2009-01-28" "2009-01-29" "2009-01-30"
>> # [31] "2009-01-31"
>>
>> print(length(dates))
>> # [1] 9
>>
>> str(dates)
>> # POSIXlt[1:9], format: "2009-01-01" "2009-01-02" "2009-01-03"
"2009-01-04" ...
>>
>> print(dates[20])
>> # [1] "2009-01-20"
>>
>> print(length(dates[20]))
>> # [1] 9
>>
>> I've since realised that POSIXct makes date vectors easier,
>> but could we also have something like:
>>
>> length.POSIXlt <- function(x) { length(x$sec) }
>>
>> in datetime.R, to avoid breaking functions (like the
>> str.POSIXt method) which use length() in this way?
PD> [You need "wishlist" in the title for this sort of stuff.]
PD> I'd be wary of this. Just the other day we found that identical() broke
PD> on some objects because a package had length() redefined as a class
PD> method. I.e. the danger is that something wants to use length() with its
PD> original low-level interpretation.
Yes, of course.
and Romain mentioned str(). Note that we have needed to define
a "POSIXt" method for str(), partly just *because* of the
current anomaly:
As Tony Plate, e.g., has argued, entirely correctly in my view,
the anomaly is thatlength() and "[" are not compatible;
and while I think no R language definition says that they should
be, I still believe that you need very good reasons for them to
be incompatible, as they are for POSIXlt.
In the current case, for me the only good reason is backwards
compatibility.
My personal taste would be to change it and see what happens.
I would be willing to clean up after that change within R 'base'
and all packages I am coauthoring (quite a few), but of course
there are still a thousand more R packages..
My strong bet would be that less than 1% would be affected,
and my point guess for the percentage affected would be
rather in the order of 1/1000.
The question is if we (you too!), the R community, are willing to
bear the load of cleanup, after such a change which would really
*improve* consistency of that small corner of R.
For me, as I indicated above, I am willing to bear my share
(and actually have got it ready for R-devel)
Would be great to see this change! Surely the right way to do things is
that functions that wish to examine the low level structure of S3
objects should use unclass() before looking at length and elements, so
there's no reason for a class such as POSIXlt to not provide a
logical-level length method.
At a broader level, when I've designed vector/array classes, I've
wondered what methods I should define, but have been unable to find any
specification of a set of methods. When one thinks about it, there are
actually quite a set of strongly-connected methods with quite a lot a
behaviors to implement, e.g., length, '[' (with logical, numeric &
character indicies, including 0 and NA possibilities), '[[', 'c', and
then optionally 'names', and then for multi-dim objects, 'dim',
'dimnames', etc. Consequently, last time this discussion on length and
'[' methods POSIXlt came up, I wrote a function that automatically
tested behavior of all these methods on a specified class and summarizes
the behavior. If anyone is interested in such a thing, I'd be happy to
dig it up and distribute it (I'd attach it to this message, but I'm on
vacation and don't have access to the compute that I think it's on.)
-- Tony Plate
Martin Maechler, ETH Zurich (and R Core Team)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] error message when running news()
> Duncan Murdoch writes: > On 22/11/2009 7:34 AM, Gabor Grothendieck wrote: >> When running news() in I get this error message from print.news_db: >> >>> news() >> Error: invalid version specification 2.0.12.0.1 patched2.1.02.1.12.1.1 >> patched2.10.02.10.0 patched2.2.02.2.12.2.1 patched2.3.02.3.12.3.1 >> patched2.4.02.4.12.4.1 patched2.5.02.5.12.5.1 >> patched2.6.02.6.12.6.22.6.2 patched2.7.02.7.12.7.22.7.2 >> patched2.8.02.8.12.8.1 patched2.9.02.9.12.9.22.9.2 patched >>> R.version.string >> [1] "R version 2.10.0 Patched (2009-11-21 r50532)" > This is also present in R-devel. It's an error in utils:::print.news_db. > The problem is that versions like "2.0.1 patched" can't be converted to > numeric versions, but print.news_db tries to do it to sort the entries. > The repetitive message is just a bad error message from > .make_numeric_version. > Presumably the intention is that "2.0.1 patched" should compare bigger > than "2.0.1" and less than "2.0.2", but I don't know the best fix for this. > Duncan Murdoch I'll have a look. -k __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Including local dynamic libraries
Thank you all so much! It seems that using dyn.load() fixes the
problem.
On Nov 20, 2009, at 8:16 PM, Simon Urbanek wrote:
On Nov 20, 2009, at 3:07 PM, Romain Francois wrote:
On 11/20/2009 08:43 PM, Elana Fertig wrote:
Hi All,
I am trying to install the package rjags into a local library on a
machine for which I do not have root permissions.
Using the command: R CMD INSTALL
--configure-args="--with-jags-include=${JAGSBIN}/include/JAGS
--with-jags-lib=${JAGSBIN}/lib/
--with-jags-modules=${JAGSBIN}/lib/JAGS/modules" CMD INSTALL -l
${JAGSBIN}/lib/ ../rjags_1.0.3-12.tar.gz
Where ${JAGSBIN} is defined as a local directory, the installation
seems
to be working fine. Then, I go into R and type the following
commands:
.libPaths("${JAGSBIN}/lib/")
Maybe this :
.libPaths( file.path( Sys.getenv("JAGSBIN", "lib" ) ) )
Unlikely - it's probably just a matter of setting LD_LIBRARY_PATH
correctly .. not really an R issue at all ...
Cheers,
S
library("rjags")
I get the following error
Loading required package: coda
Loading required package: lattice
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared library '${JAGSBIN}/lib/rjags/libs/rjags.so':
libjags.so.1: cannot open shared object file: No such file or
directory
Error : .onLoad failed in 'loadNamespace' for 'rjags'
Error: package/namespace load failed for 'rjags'
Ideally, I would fix this problem by adding the appropriate
libraries to
/user/local/lib64 . However, since I do not have root permissions I
am
not able to make this addition. How can I have R recognize c++
libraries
from my local path?
Thanks so much in advance for your help.
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/EAD5 : LondonR slides
|- http://tr.im/BcPw : celebrating R commit #5
`- http://tr.im/ztCu : RGG #158:161: examples of package IDPmisc
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] error message when running news()
On 22/11/2009 7:34 AM, Gabor Grothendieck wrote: When running news() in I get this error message from print.news_db: news() Error: invalid version specification 2.0.12.0.1 patched2.1.02.1.12.1.1 patched2.10.02.10.0 patched2.2.02.2.12.2.1 patched2.3.02.3.12.3.1 patched2.4.02.4.12.4.1 patched2.5.02.5.12.5.1 patched2.6.02.6.12.6.22.6.2 patched2.7.02.7.12.7.22.7.2 patched2.8.02.8.12.8.1 patched2.9.02.9.12.9.22.9.2 patched R.version.string [1] "R version 2.10.0 Patched (2009-11-21 r50532)" This is also present in R-devel. It's an error in utils:::print.news_db. The problem is that versions like "2.0.1 patched" can't be converted to numeric versions, but print.news_db tries to do it to sort the entries. The repetitive message is just a bad error message from .make_numeric_version. Presumably the intention is that "2.0.1 patched" should compare bigger than "2.0.1" and less than "2.0.2", but I don't know the best fix for this. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] error message when running news()
When running news() in I get this error message from print.news_db: > news() Error: invalid version specification 2.0.12.0.1 patched2.1.02.1.12.1.1 patched2.10.02.10.0 patched2.2.02.2.12.2.1 patched2.3.02.3.12.3.1 patched2.4.02.4.12.4.1 patched2.5.02.5.12.5.1 patched2.6.02.6.12.6.22.6.2 patched2.7.02.7.12.7.22.7.2 patched2.8.02.8.12.8.1 patched2.9.02.9.12.9.22.9.2 patched > R.version.string [1] "R version 2.10.0 Patched (2009-11-21 r50532)" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
