I agree it is a good idea, but a new name seems justified to avoid
confusion.
On Wed, 4 Nov 2009, Duncan Murdoch wrote:
On 11/4/2009 12:15 PM, William Dunlap wrote:
-----Original Message-----
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org]
On Behalf Of Duncan Murdoch
Sent: Wednesday, November 04, 2009 8:47 AM
To: michael.m.spie...@gmail.com
Cc: r-b...@r-project.org; r-de...@stat.math.ethz.ch
Subject: Re: [Rd] error in install.packages() (PR#14042)
On 11/4/2009 11:05 AM, michael.m.spie...@gmail.com wrote:
> Full_Name: Michael Spiegel
> Version: 2.10
> OS: Windows Vista
> Submission from: (NULL) (76.104.24.156)
> > > The following error is produced when attempting to call
install.packages. Here
> is the results of the traceback:
> >> source('http://openmx.psyc.virginia.edu/getOpenMx.R')
> Error in f(res) : invalid subscript type 'list'
>> traceback()
> 7: f(res)
> 6: available.packages(contriburl = contriburl, method = method)
> 5: .install.winbinary(pkgs = pkgs, lib = lib, contriburl = contriburl, >
method = method, available = available, destdir = destdir, >
dependencies = dependencies, ...)
> 4: install.packages(pkgs = c("OpenMx"), repos = repos)
> 3: eval.with.vis(expr, envir, enclos)
> 2: eval.with.vis(ei, envir)
> 1: source("http://openmx.psyc.virginia.edu/getOpenMx.R";)
> > I've tracked the error down to somewhere in available.packages defined
in
> src\library\utils\R\packages.R. I am guessing that the error in version
2.10
> has something to do with the change: "available.packages() gains a
'filters'
> argument for specifying the filtering operations performed on the
packages found
> in the repositories."
I've found the error, and will fix and commit to R-devel and R-patched.
For future reference: the problem was that it assigned the result of
sapply() to a subset of a vector. Normally sapply() simplifies its result
to a vector, but in this case the result was empty, so sapply() returned
an empty list; assigning a list to a vector coerced the vector to a list,
and then the "invalid subscript type 'list'" came soon after.
I've run into this sort of problem a lot (0-long input to sapply
causes it to return list()). A related problem is that when sapply's
FUN doesn't always return the type of value you expect for some
corner case then sapply won't do the expected simplication. If
sapply had an argument that gave the expected form of FUN's output
then sapply could (a) die if some call to FUN didn't return something
of that form and (b) return a 0-long object of the correct form
if sapply's X has length zero so FUN is never called. E.g.,
sapply(2:0, function(i)(11:20)[i], FUN.VALUE=integer(1)) # die on
third iteration
sapply(integer(0), function(i)i>0, FUN.VALUE=logical(1)) # return
logical(0)
Another benefit of sapply knowing the type of FUN's return value is
that it wouldn't have to waste space creating a list of FUN's return
values but could stuff them directly into the final output structure.
A list of n scalar doubles is 4.5 times bigger than double(n) and the
factor is 9.0 for integers and logicals.
That sounds like a good idea. It would be a bit of work, because the current
sapply depends on lapply while this would need its own internal
implementation: but it would probably be worthwhile.
Duncan Murdoch
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
