[Rd] model.frame error with formula=~1 and na.action=na.fail (PR#14066)
Full_Name: Sebastian Meyer Version: 2.10.0 OS: x86_64-pc-linux-gnu Submission from: (NULL) (77.135.124.96) When using model.frame (model.frame.default) on an intercept-only model and with na.action=na.fail SPECIFIED, i.e. data(iris) model.frame( ~ 1, data = iris, na.action = na.fail) one gets the following error: Error in complete.cases(object) : negative length vectors are not allowed There is no error if the na.action argument is left UNSPECIFIED (though the default value also is na.fail!): model.frame( ~ 1, data = iris) In either case, there should be no error. Specifing other na.action functions (na.omit, na.pass, na.exclude) works. If there is at least one (non-intercept) variable in the formula, e.g. model.frame( ~ 1 + Species, data = iris, na.action = na.fail) there is obviously no issue. Best regards, Sebastian Meyer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] (Date + difftime) and (POSIXt + difftime) does not use date/time arithmetics (PR#14067)
Full_Name: Suharto Anggono
Version: 2.8.1
OS: Windows
Submission from: (NULL) (125.165.81.48)
There is already PR#13369. But, the problem is not just the warning.
C:\Program Files\R\R-2.8.1\bin>R --vanilla
R version 2.8.1 (2008-12-22)
Copyright (C) 2008 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 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> as.Date("2009-09-15") + as.difftime(8, units="weeks")
[1] "2009-09-23"
Warning message:
Incompatible methods ("+.Date", "Ops.difftime") for "+"
I expect to get the date 8 weeks after 2009-09-15, but I get 8 days after
2009-09-15.
To get the date 8 weeks after 2009-09-15, I have to call '+.Date' directly, or
convert weeks to days.
> `+.Date`(as.Date("2009-09-15"), as.difftime(8, units="weeks"))
[1] "2009-11-10"
The problem is the same for class "POSIXt".
> as.POSIXct("2009-09-09 09:09:09") + as.difftime(1, units="hours")
[1] "2009-09-09 09:09:10 ICT"
Warning message:
Incompatible methods ("+.POSIXt", "Ops.difftime") for "+"
I inspect the function definition for '+.Date' and 'Ops.difftime'.
> `+.Date`
function (e1, e2)
{
coerceTimeUnit <- function(x) {
round(switch(attr(x, "units"), secs = x/86400, mins = x/1440,
hours = x/24, days = x, weeks = 7 * x))
}
if (nargs() == 1)
return(e1)
if (inherits(e1, "Date") && inherits(e2, "Date"))
stop("binary + is not defined for Date objects")
if (inherits(e1, "difftime"))
e1 <- coerceTimeUnit(e1)
if (inherits(e2, "difftime"))
e2 <- coerceTimeUnit(e2)
structure(unclass(e1) + unclass(e2), class = "Date")
}
> Ops.difftime
function (e1, e2)
{
coerceTimeUnit <- function(x) {
switch(attr(x, "units"), secs = x, mins = 60 * x, hours = 60 *
60 * x, days = 60 * 60 * 24 * x, weeks = 60 * 60 *
24 * 7 * x)
}
if (nargs() == 1) {
switch(.Generic, `+` = {
}, `-` = {
e1[] <- -unclass(e1)
}, stop(gettextf("unary '%s' not defined for \"difftime\" objects",
.Generic), domain = NA, call. = FALSE))
return(e1)
}
boolean <- switch(.Generic, `<` = , `>` = , `==` = , `!=` = ,
`<=` = , `>=` = TRUE, FALSE)
if (boolean) {
if (inherits(e1, "difftime") && inherits(e2, "difftime")) {
e1 <- coerceTimeUnit(e1)
e2 <- coerceTimeUnit(e2)
}
NextMethod(.Generic)
}
else if (.Generic == "+" || .Generic == "-") {
if (inherits(e1, "difftime") && !inherits(e2, "difftime"))
return(structure(NextMethod(.Generic), units = attr(e1,
"units"), class = "difftime"))
if (!inherits(e1, "difftime") && inherits(e2, "difftime"))
return(structure(NextMethod(.Generic), units = attr(e2,
"units"), class = "difftime"))
u1 <- attr(e1, "units")
if (attr(e2, "units") == u1) {
structure(NextMethod(.Generic), units = u1, class = "difftime")
}
else {
e1 <- coerceTimeUnit(e1)
e2 <- coerceTimeUnit(e2)
structure(NextMethod(.Generic), units = "secs", class = "difftime")
}
}
else {
stop(gettextf("'%s' not defined for \"difftime\" objects",
.Generic), domain = NA)
}
}
I can see the conflict. In '+.Date', the result of operating "Date" and
"difftime" is of class "Date". In 'Ops.difftime', the result of '+' when one of
its operand is "difftime" is of class "difftime". So, maybe, both are not used;
what is used is the usual '+'.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#14066) model.frame error with formula=~1 and na.action=na.fail
Thank you for the report -- but a bit more investigation of the root cause would have been even more helpful: this is not 'model.frame error', nor even reported by R as such. The issue was that complete.cases() did not know how to find the number of rows of a 0-column data frame (it knew nothing about data frames). That has been changed in R-patched and R-devel, together with a more informative error message in other cases where the number of rows is unspecified. On Sun, 15 Nov 2009, sebastian.wastl.me...@campus.lmu.de wrote: Full_Name: Sebastian Meyer Version: 2.10.0 OS: x86_64-pc-linux-gnu Submission from: (NULL) (77.135.124.96) When using model.frame (model.frame.default) on an intercept-only model and with na.action=na.fail SPECIFIED, i.e. data(iris) That line is unnecessary: 'iris' is a visible object in package 'datasets'. model.frame( ~ 1, data = iris, na.action = na.fail) one gets the following error: Error in complete.cases(object) : negative length vectors are not allowed There is no error if the na.action argument is left UNSPECIFIED (though the default value also is na.fail!): model.frame( ~ 1, data = iris) In either case, there should be no error. Specifing other na.action functions (na.omit, na.pass, na.exclude) works. If there is at least one (non-intercept) variable in the formula, e.g. model.frame( ~ 1 + Species, data = iris, na.action = na.fail) there is obviously no issue. Best regards, Sebastian Meyer __ 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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem building package for R 2.10.0 on Mac OS X
Thanks, Brian, I was away traveling/away from Internet and all hell
breaks lose :) [more precisely Fortran broke for some reason].
Stephen,
in the case of rioja it is really a bug in your code - you have to
check the result of require() or "depend" on vegan. "Suggests" means
that your package works without those packages but can have improved
functionality with them. In your case the example breaks if you don't
have vegan - thus the package doesn't really work without vegan. (As
of why vegan is not there that is my problem ;)) Thanks for the
report, though.
Cheers,
Simon
On Nov 15, 2009, at 15:04 , Prof Brian Ripley wrote:
Please ask such questions on R-sig-mac, or directly to the Mac
package builder (Simon Urbanek).
As you will see from
http://cran.r-project.org/web/checks/check_summary.html
at least 150 packages are in the same boat (not building because
dependencies are missing), so something has gone wrong on the build
machine. There seem to be results for 'vegan', but they are for a
pre-release (2.10.0 alpha), not the released version.
Perhaps related, there have been no R-patched builds on
r.research.att.com for 'leopard' (the main R build for R 2.10.0)
since Nov 4.
Simon has been travelling, and will no doubt get to this when he has
time. Meanwhile, Mac users can fairly easily build packages from
the sources (provided they have installed Xcode), so this is not
something to fret about.
One point specific to Mac is that the distributed packages are tri-
architecture (i386, x86_64, ppc) and so need to work on all three
archs to get distributed (at least in principle). There have been
quite a few packages (including earlier versions of yours) that
failed on 64-bit platforms.
On Sun, 15 Nov 2009, Stephen Juggins wrote:
Hi
I have submitted a package (rioja) to CRAN. It checks OK for all R
versions and OS's except r-release-macosx-ix86 where it fails when
checking the examples. Specifically, it fails because R can't find
the package vegan which is needed in a function. Here is the
snippet from the check results:
### Begin snippet
checking examples ... ERROR
Running examples in 'rioja-Ex.R' failed.
The error most likely occurred in:
### * chclust
flush(stderr()); flush(stdout())
### Name: chclust
### Title: Constrained hierarchical clustering
### Aliases: chclust plot.chclust bstick.chclust
### Keywords: cluster hplot
### ** Examples
data(RLGH)
diss <- dist(sqrt(RLGH$spec/100)^2)
clust <- chclust(diss)
bstick.chclust(clust, 10)
Loading required package: vegan
Warning in library(package, lib.loc = lib.loc, character.only =
TRUE, logical.return = TRUE, :
there is no package called 'vegan'
Error in bstick.chclust(clust, 10) : could not find function "bstick"
Execution halted
### End snippet
The function bstick.chclust listed below loads the package vegan
which contains bstick.default.
bstick.chclust <- function(n, ng=10, plot=TRUE, ...) {
if (n$method != "coniss")
stop("bstick cannot display conslink results")
require(vegan)
disp <- rev(n$height)
tot.disp <- disp[1]
disp <- abs(diff(disp))
nobj <- length(n$height)
bs <- bstick(nobj, tot.disp)
yR <- range(disp[1:(ng-1)], bs[1:(ng-1)])
if (plot) {
plot(2:ng, disp[1:(ng-1)], type="o", ylim=yR, ylab="Sum of
Squares", xlab = "Number of groups")
lines(2:ng, bs[1:(ng-1)], col="red", type="o")
}
invisible(data.frame(nGroups = 2:(ng), dispersion=disp[1:(ng-1)],
bstick = bs[1:(ng-1)]))
}
vegan is included as a Suggests in the DESCRIPTION file and the
package checks OK on r-oldrel-macosx-ix86. It also checks OK with
R 2.10.0 on OS X on my own Mac. My code could be improved and I
should probably trap the warning issued by require, but I don't
understand why vegan is not loading when checking on CRAN. Any
help will be gratefully received!
Many thanks, Steve
Steve Juggins
School of Geography, Politics & Sociology
Newcastle University Tel: +44 (0)191 222 8799
Newcastle upon TyneFax: +44 (0)191 222 5421
NE1 7RU, UKMobile: +44 (0)7740054905
http://www.staff.ncl.ac.uk/staff/stephen.juggins/
__
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, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] n=1 default for random number generators
One tiny thing that would be very nice to have is a default value of n=1 in the random number generator functions, enabling, e.g., runif() instead of runif(1). This won't break anyone's existing code and ought to be relatively straightforward to do. Is there anyone in the core team who would be willing to include this change? - Regards, Richie. Mathematical Sciences Unit HSL -- View this message in context: http://old.nabble.com/n%3D1-default-for-random-number-generators-tp26374371p26374371.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] n=1 default for random number generators
On 11/16/2009 11:00 AM, Richard Cotton wrote: One tiny thing that would be very nice to have is a default value of n=1 in the random number generator functions, enabling, e.g., runif() instead of runif(1). This won't break anyone's existing code and ought to be relatively straightforward to do. Is there anyone in the core team who would be willing to include this change? I doubt it. Even if you put together the patch (and I didn't see an offer to do so), merging it into the trunk code would take more work than you'd save in several years of typing the "1". Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] n=1 default for random number generators
> -Original Message- > From: r-devel-boun...@r-project.org > [mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch > Sent: Monday, November 16, 2009 8:28 AM > To: Richard Cotton > Cc: r-devel@r-project.org > Subject: Re: [Rd] n=1 default for random number generators > > On 11/16/2009 11:00 AM, Richard Cotton wrote: > > One tiny thing that would be very nice to have is a default > value of n=1 in > > the random number generator functions, enabling, e.g., > runif() instead of > > runif(1). This won't break anyone's existing code and ought to be > > relatively straightforward to do. > > > > Is there anyone in the core team who would be willing to > include this > > change? > > I doubt it. Even if you put together the patch (and I didn't see an > offer to do so), merging it into the trunk code would take more work > than you'd save in several years of typing the "1". Also, you would probably hear complaints that n=1 is not a common value for the argument in 'well-written' (really, vectorized cpu-efficient) R code. Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com > Duncan Murdoch > > __ > 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] n=1 default for random number generators
Duncan Murdoch wrote: On 11/16/2009 11:00 AM, Richard Cotton wrote: One tiny thing that would be very nice to have is a default value of n=1 in the random number generator functions, enabling, e.g., runif() instead of runif(1). This won't break anyone's existing code and ought to be relatively straightforward to do. Is there anyone in the core team who would be willing to include this change? I doubt it. Even if you put together the patch (and I didn't see an offer to do so), merging it into the trunk code would take more work than you'd save in several years of typing the "1". Duncan Murdoch In the spirit of sour grapes, the proposed default might discourage some users from vectorizing their thinking. Patrick Burns patr...@burns-stat.com +44 (0)20 8525 0696 http://www.burns-stat.com (home of "The R Inferno" and "A Guide for the Unwilling S User") __ 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] n=1 default for random number generators
On Mon, 16 Nov 2009, Richard Cotton wrote: One tiny thing that would be very nice to have is a default value of n=1 in the random number generator functions, enabling, e.g., runif() instead of runif(1). This won't break anyone's existing code and ought to be relatively straightforward to do. Is there anyone in the core team who would be willing to include this change? For those in base R (not all are, of course), if someone makes a persuasive case (not just says 'would be very nice to have': e.g. produces statistics of usage by a wide group of users showing that is a commonly used value of 'n') and supplies a complete patch (to the help as well as the code). - Regards, Richie. Mathematical Sciences Unit HSL -- 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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The default behaviour of a missing entry in an environment
Hi,
On Fri, Nov 13, 2009 at 4:55 PM, Duncan Murdoch wrote:
> On 13/11/2009 7:26 PM, Gabor Grothendieck wrote:
>>
>> On Fri, Nov 13, 2009 at 7:21 PM, Duncan Murdoch
>> wrote:
>>>
>>> On 13/11/2009 6:39 PM, Gabor Grothendieck wrote:
Note that one should use inherits = FALSE argument on get and exists
to avoid returning objects from the parent, the parent of the parent,
etc.
>>>
>>> I disagree. Normally you would want to receive those objects. If you
>>> didn't, why didn't you set the parent of the environment to emptyenv()
>>> when
>>> you created it?
>>>
>>
>> $ does not look into the parent so if you are trying to get those
>> semantics you must use inherits = FALSE.
>
> Whoops, yes. That's another complaint about $ on environments.
That was an intentional choice. AFAIR neither $ nor [[ on
environments was not meant to mimic get, but rather to work on the
current environment as if it were a hash-like object. One can always
get the inherits semantics by simple programming, but under the model
you seem to be suggesting, preventing such behavior when you don't own
the environments in question is problematic.
Robert
>
> Duncan Murdoch
>
>>
>>> x <- 3
>>> e <- new.env()
>>> "x" %in% names(e)
>>
>> [1] FALSE
>>>
>>> get("x", e) # oops
>>
>> [1] 3
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Robert Gentleman
rgent...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The default behaviour of a missing entry in an environment
On 11/16/2009 12:07 PM, Robert Gentleman wrote: Hi, On Fri, Nov 13, 2009 at 4:55 PM, Duncan Murdoch wrote: On 13/11/2009 7:26 PM, Gabor Grothendieck wrote: On Fri, Nov 13, 2009 at 7:21 PM, Duncan Murdoch wrote: On 13/11/2009 6:39 PM, Gabor Grothendieck wrote: Note that one should use inherits = FALSE argument on get and exists to avoid returning objects from the parent, the parent of the parent, etc. I disagree. Normally you would want to receive those objects. If you didn't, why didn't you set the parent of the environment to emptyenv() when you created it? $ does not look into the parent so if you are trying to get those semantics you must use inherits = FALSE. Whoops, yes. That's another complaint about $ on environments. That was an intentional choice. AFAIR neither $ nor [[ on environments was not meant to mimic get, but rather to work on the current environment as if it were a hash-like object. One can always get the inherits semantics by simple programming, but under the model you seem to be suggesting, preventing such behavior when you don't own the environments in question is problematic. Sure, I agree with how you did that; I'm not sure you had any choice at the time (didn't all environments have base as a parent then?). Even now, you do want both inherits=TRUE and inherits=FALSE behaviour in different circumstances, and $ has to pick just one. Probably my wording should have been "That's another gotcha about $ on environments." Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The default behaviour of a missing entry in an environment
Robert Gentleman wrote: Hi, On Fri, Nov 13, 2009 at 4:55 PM, Duncan Murdoch wrote: On 13/11/2009 7:26 PM, Gabor Grothendieck wrote: On Fri, Nov 13, 2009 at 7:21 PM, Duncan Murdoch wrote: On 13/11/2009 6:39 PM, Gabor Grothendieck wrote: Note that one should use inherits = FALSE argument on get and exists to avoid returning objects from the parent, the parent of the parent, etc. I disagree. Normally you would want to receive those objects. If you didn't, why didn't you set the parent of the environment to emptyenv() when you created it? $ does not look into the parent so if you are trying to get those semantics you must use inherits = FALSE. Whoops, yes. That's another complaint about $ on environments. That was an intentional choice. AFAIR neither $ nor [[ on environments was not meant to mimic get, but rather to work on the current environment as if it were a hash-like object. One can always get the inherits semantics by simple programming, but under the model you seem to be suggesting, preventing such behavior when you don't own the environments in question is problematic. Robert Yes. Also, AFAIR, emptyenv() came later. At the time you couldn't go deeper than baseenv(). And at any rate, some of the intended applications are dataframe-like, and I don't think you want to preclude use of with() and other forms of evaluation in the environment, as in > e <- evalq(environment(),airquality) > ls(e) [1] "Day" "Month" "Ozone" "Solar.R" "Temp""Wind" > evalq(logO3 <- log(Ozone), e) # works fine > lm(Ozone~Wind, data=e) # ditto ... > parent.env(e) <- emptyenv() > evalq(logO3 <- log(Ozone), e) Error in eval(substitute(expr), envir, enclos) : could not find function "<-" > lm(Ozone~Wind, data=e) Error in eval(expr, envir, enclos) : could not find function "list" -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R crash with intToUtf8 on huge vectors (PR#14068)
Full_Name: George Russell Version: 2.10.0 OS: Windows XP Professional Version 2002 Service Pack 2 Submission from: (NULL) (217.111.3.131) Typing the following command into R --vanilla causes R to crash: k <- intToUtf8(rep(1e3,1e7)) This is the output of sessionInfo(): R version 2.10.0 (2009-10-26) i386-pc-mingw32 locale: [1] LC_COLLATE=German_Germany.1252 LC_CTYPE=German_Germany.1252 [3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C [5] LC_TIME=German_Germany.1252 attached base packages: [1] stats graphics grDevices datasets utils methods base other attached packages: [1] RODBC_1.3-1 Many thanks for your help and best wishes, George Russell __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#14066) model.frame error with formula=~1 and na.action=na.fail
Thank you for your rapid bug fix and for your instructive comments on my bug report. > this is not 'model.frame error', nor even reported by R as such. Of course you are right, but I thought that a bug report on model.frame would probably reach more attention further providing a more motivating frame for the bug than just writing that complete.cases(as.data.frame(matrix(,150,0))) would not work, and I was absolutely sure that you would be able to track down the source of the problem. >> data(iris) > > That line is unnecessary: 'iris' is a visible object in package > 'datasets'. Ok. I was not sure about this and just wanted to be on the save side to offer a reproducible example working in a maximum variety of R sessions. Best regards and thank you very much for your intense development of R, Sebastian Meyer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R crash with intToUtf8 on huge vectors (PR#14068)
On 11/16/2009 8:10 AM, g.russ...@eos-solutions.com wrote: Full_Name: George Russell Version: 2.10.0 OS: Windows XP Professional Version 2002 Service Pack 2 Submission from: (NULL) (217.111.3.131) Typing the following command into R --vanilla causes R to crash: k <- intToUtf8(rep(1e3,1e7)) Thanks, I see this in R-patched and R-devel. Will try to track it down. This is the output of sessionInfo(): R version 2.10.0 (2009-10-26) i386-pc-mingw32 locale: [1] LC_COLLATE=German_Germany.1252 LC_CTYPE=German_Germany.1252 [3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C [5] LC_TIME=German_Germany.1252 attached base packages: [1] stats graphics grDevices datasets utils methods base other attached packages: [1] RODBC_1.3-1 I didn't have RODBC present, and was working in an English_United States.1252 locale. Duncan Murdoch Many thanks for your help and best wishes, George Russell __ 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] Suggestion: Add links to NEWS and CHANGES on help.start() page
On Mon, Nov 16, 2009 at 4:06 AM, Duncan Murdoch wrote:
> On 13/11/2009 7:39 AM, Gabor Grothendieck wrote:
>>
>> Its also difficult to know about demos unless you specifically issue a
>> demo(package = "mypackage") command. It would be nice if these were
>> listed too.
>
> This is in R-devel now.
I just got the Windows version. For others information, the main HTML
help page - help.start() - now ends with sections:
-- Miscellaneous Material --
About R \t Authors \t Resources
License \t Frequently Asked Questions \t Thanks
\t NEWS
-- Material specific to the Windows port --
CHANGES \t Windows FAQ
The links to the NEWS and the CHANGES are new.
Thanks a bunch Duncan - beautiful and useful.
/Henrik
>
>> Note that the NEWS and/or ChangeLog file are listed on the package's
>> CRAN page such as:
>>
>> http://cran.r-project.org/package=zoo
>>
>> but the demos are not listed even there.
>
> The structure is in place for displaying package news, but it doesn't
> display yet. I think Kurt Hornik is working on the actual display.
>
> Duncan Murdoch
>
>>
>> On Fri, Nov 13, 2009 at 3:37 AM, Henrik Bengtsson
>> wrote:
>>>
>>> Hi,
>>>
>>> right now it is actually a bit tricky to locate and view the NEWS and
>>> the CHANGES files, especially if you are a beginning and don't even
>>> know that you are supposed to look for them.
>>>
>>> I'd like to recommend that links to (local) NEWS and CHANGES are added
>>> to the help.start() overview pages. help("NEWS")/help("CHANGE LOG")
>>> and help("CHANGES") could display/refer to them as well.
>>>
>>> /Henrik
>>>
>>> __
>>> 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
Re: [Rd] How to generate dependency file that can be used by gnu make?
On Sun, Nov 15, 2009 at 8:45 PM, Peng Yu wrote:
> gcc has options like -MM, which can generate the dependence files for
> a C/C++ file that I can be used by gnu make. I'm wondering if there is
> a tool that can generate dependence file for an R script.
>
> For example, I have an R script test.R
>
> #test.R
> load('input.RData')
> save.image('output.RData')
>
>
> I want to generate a dependence file like the following. Is there a
> tool to do so?
>
> output.RData:test.R input.RData
Is there a way to automatically generate the output files that depends
on an R script and the input files and sourced files that are depended
by an R script? I don't see this option in R. But I wish this can be
implemented in future version of R.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
