[Rd] R 2.4.0 @ R-project.org
R-project.org' News section still has R version 2.4.0 has been released on 2006-10-03. Best wishes, Torsten __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mingw-cross with R 2.4.x Re: wine and build difference between R.2.4.0 and R 2.4.1 windows binaries?
Hin-Tak Leung wrote: > Hin-Tak Leung wrote: > > - I needed to copy R/src/intl and R/src/extra/pcre from 2.4.1 to 2.4.0 > to get the older R 2.4.0 to build against newer mingw. Since I had to copy a few files from 2.4.1 to 2.4.0 for the older version of build, I thought I need to be 100% sure that the wine crash is due to mingw rather than those few files. So previously, both 2.4.0/2.4.1 Rgui binaries from this set crash wine: > binutils-2.17.50-20060824-1-src.tar.gz > gcc-ada-3.4.5-20060117-1-src.tar.gz > gcc-core-3.4.5-20060117-1-src.tar.gz > gcc-g++-3.4.5-20060117-1-src.tar.gz > gcc-g77-3.4.5-20060117-1-src.tar.gz > gcc-java-3.4.5-20060117-1-src.tar.gz > gcc-objc-3.4.5-20060117-1-src.tar.gz > mingw-runtime-3.11-20061202-1-src.tar.gz > w32api-3.8-src.tar.gz I tried some other combos of mingw-cross. Both 2.4.0/2.4.1 Rgui binaries from this set works OK-ish with wine (by that I mean I can so Sys.info() and sessionInfo() - obviously somebody requires 3.11 for 2.4.1 for a reason): gcc-core-3.4.5-20060117-1-src.tar.gz gcc-ada-3.4.5-20060117-1-src.tar.gz gcc-g++-3.4.5-20060117-1-src.tar.gz gcc-g77-3.4.5-20060117-1-src.tar.gz gcc-java-3.4.5-20060117-1-src.tar.gz gcc-objc-3.4.5-20060117-1-src.tar.gz binutils-2.17.50-20060716-1-src.tar.gz mingw-runtime-3.10-20060909-1-src.tar.gz w32api-3.7-src.tar.gz This set produces 2.4.0/2.4.1 Rgui binaries which crash wine: gcc-core-3.4.5-20060117-1-src.tar.gz gcc-ada-3.4.5-20060117-1-src.tar.gz gcc-g++-3.4.5-20060117-1-src.tar.gz gcc-g77-3.4.5-20060117-1-src.tar.gz gcc-java-3.4.5-20060117-1-src.tar.gz gcc-objc-3.4.5-20060117-1-src.tar.gz binutils-2.17.50-20060716-1-src.tar.gz mingw-runtime-3.11-20061202-1-src.tar.gz w32api-3.7-src.tar.gz As can be seen, the difference is only mingw-runtime-3.10-20060909-1-src.tar.gz versus mingw-runtime-3.11-20061202-1-src.tar.gz . The issue is filed as http://bugs.winehq.org/show_bug.cgi?id=7181 HTL __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: Sweave: allow line breaks after forward slashes (PR#9444)
On Tuesday 16 January 2007 05:22, Duncan Murdoch wrote:
> On 1/15/2007 5:43 PM, Arne Henningsen wrote:
> > On Monday, 15. January 2007 18:44, Duncan Murdoch wrote:
> >> On 1/15/2007 11:23 AM, Arne Henningsen wrote:
> >>> [...]
> >>> I prefer to use "keep.source=FALSE", because I generally like that
> >>> Sweave takes the job to format the code chunks. Therefore, it would be
> >>> great if Sweave is allowed to introduce line breaks after forward
> >>> slashes, e.g. if deparse() adds a blank after a forward slash.
> >>> Please move this wish from "wishlst-fulfilled" to "wishlst".
> >>
> >> I don't think so. If I thought it was a reasonable request, I'd do
> >> that, but it's not. You have a perfectly general solution to your
> >> problem.
> >
> > However, setting "keep.source = FALSE" has (IMHO) one major advantage:
> > I can easily (and globally) change the width of the code chunks by
> > "options( width = XXX )", e.g. if I change the paper size, the margins or
> > the font size. With "keep.source = TRUE", I would have to reformat all
> > code chunks by hand and I generally prefer that my software (LaTeX,
> > Sweave) does this task for me. Hence, "keep.source = TRUE" is not a
> > "perfectly general solution" (at least) for me.
>
> No, you would only have to reformat the one code chunk where you set
> keep.source = TRUE. It doesn't need to be a global option.
Okay, that's true, but I have more than one code chunk that is not nicely
formatted because of "/" signs. (And I generally don't like manual
formatting ;-)).
Is there any reason for deparse() to add spaces around "+", "-", and "*"
operators but not around "/" operators?
R> deparse(parse( text = "a+b-c*d/e" ))
[1] "expression(a + b - c * d/e)"
> >> The fact that it isn't the one you want doesn't mean it needs
> >> to be listed as an outstanding issue in the bug reporting system.
> >
> > Okay. Where can I list "minor" wishes?
>
> On your to-do list?
Yes, that's a good idea!
This is my patch of /src/main/names.c:
--- names.c.orig2007-01-16 11:03:24.0 +0100
+++ names.c 2007-01-16 10:30:43.0 +0100
@@ -149,7 +149,7 @@
{"+", do_arith, PLUSOP, 1, 2, {PP_BINARY, PREC_SUM,0}},
{"-", do_arith, MINUSOP,1, 2, {PP_BINARY, PREC_SUM,0}},
{"*", do_arith, TIMESOP,1, 2, {PP_BINARY, PREC_PROD, 0}},
-{"/", do_arith, DIVOP, 1, 2, {PP_BINARY2, PREC_PROD, 0}},
+{"/", do_arith, DIVOP, 1, 2, {PP_BINARY, PREC_PROD, 0}},
{"^", do_arith, POWOP, 1, 2, {PP_BINARY2, PREC_POWER, 1}},
{"%%", do_arith, MODOP, 1, 2, {PP_BINARY2, PREC_PERCENT,0}},
{"%/%", do_arith, IDIVOP, 1, 2, {PP_BINARY2, PREC_PERCENT,0}},
(I have removed some blanks so that each line fits in a single line)
Now I get:
R> deparse(parse( text = "a+b-c*d/e" ))
[1] "expression(a + b - c * d / e)"
Does this patch has any negative side effects?
"make check" fails, but AFAIK this is just because of different positions of
line breaks:
[...]
running code in 'reg-tests-2.R' ... OK
comparing 'reg-tests-2.Rout'
to './reg-tests-2.Rout.save' ...3639,3640c3639,3640
< aov(formula = dep.variable ~ f1 * f2 + Error(subject / (f1 +
< f2)), data = sample.df)
---
> aov(formula = dep.variable ~ f1 * f2 + Error(subject/(f1 + f2)),
> data = sample.df)
3693,3694c3693,3694
< aov(formula = dep.variable ~ f1 * f2 + Error(subject / (f2 +
< f1)), data = sample.df)
---
> aov(formula = dep.variable ~ f1 * f2 + Error(subject/(f2 + f1)),
> data = sample.df)
make[3]: *** [reg-tests-2.Rout] Fehler 1
[...]
> Duncan Murdoch
Thank you for all your hints,
Arne
--
Arne Henningsen
Department of Agricultural Economics
University of Kiel
Olshausenstr. 40
D-24098 Kiel (Germany)
Tel: +49-431-880 4445
Fax: +49-431-880 1397
[EMAIL PROTECTED]
http://www.uni-kiel.de/agrarpol/ahenningsen/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: Sweave: allow line breaks after forward slashes (PR#9444)
On 1/16/2007 5:26 AM, Arne Henningsen wrote:
> On Tuesday 16 January 2007 05:22, Duncan Murdoch wrote:
>> On 1/15/2007 5:43 PM, Arne Henningsen wrote:
>>> On Monday, 15. January 2007 18:44, Duncan Murdoch wrote:
On 1/15/2007 11:23 AM, Arne Henningsen wrote:
> [...]
> I prefer to use "keep.source=FALSE", because I generally like that
> Sweave takes the job to format the code chunks. Therefore, it would be
> great if Sweave is allowed to introduce line breaks after forward
> slashes, e.g. if deparse() adds a blank after a forward slash.
> Please move this wish from "wishlst-fulfilled" to "wishlst".
I don't think so. If I thought it was a reasonable request, I'd do
that, but it's not. You have a perfectly general solution to your
problem.
>>> However, setting "keep.source = FALSE" has (IMHO) one major advantage:
>>> I can easily (and globally) change the width of the code chunks by
>>> "options( width = XXX )", e.g. if I change the paper size, the margins or
>>> the font size. With "keep.source = TRUE", I would have to reformat all
>>> code chunks by hand and I generally prefer that my software (LaTeX,
>>> Sweave) does this task for me. Hence, "keep.source = TRUE" is not a
>>> "perfectly general solution" (at least) for me.
>> No, you would only have to reformat the one code chunk where you set
>> keep.source = TRUE. It doesn't need to be a global option.
>
> Okay, that's true, but I have more than one code chunk that is not nicely
> formatted because of "/" signs. (And I generally don't like manual
> formatting ;-)).
>
> Is there any reason for deparse() to add spaces around "+", "-", and "*"
> operators but not around "/" operators?
> R> deparse(parse( text = "a+b-c*d/e" ))
> [1] "expression(a + b - c * d/e)"
I don't know, but it has been like that for the complete history of the
source code in the repository (almost 10 years). I suppose someone thought
a + b - c * d /
e
would look ugly (even though they were happy to put one of the other
operators at the end of the line). This makes me quite reluctant to
change it: people get upset about changes to the look of their old
scripts, because they trigger spurious check errors.
Duncan Murdoch
>
The fact that it isn't the one you want doesn't mean it needs
to be listed as an outstanding issue in the bug reporting system.
>>> Okay. Where can I list "minor" wishes?
>> On your to-do list?
>
> Yes, that's a good idea!
> This is my patch of /src/main/names.c:
>
> --- names.c.orig2007-01-16 11:03:24.0 +0100
> +++ names.c 2007-01-16 10:30:43.0 +0100
> @@ -149,7 +149,7 @@
> {"+", do_arith, PLUSOP, 1, 2, {PP_BINARY, PREC_SUM,0}},
> {"-", do_arith, MINUSOP,1, 2, {PP_BINARY, PREC_SUM,0}},
> {"*", do_arith, TIMESOP,1, 2, {PP_BINARY, PREC_PROD, 0}},
> -{"/", do_arith, DIVOP, 1, 2, {PP_BINARY2, PREC_PROD, 0}},
> +{"/", do_arith, DIVOP, 1, 2, {PP_BINARY, PREC_PROD, 0}},
> {"^", do_arith, POWOP, 1, 2, {PP_BINARY2, PREC_POWER, 1}},
> {"%%", do_arith, MODOP, 1, 2, {PP_BINARY2, PREC_PERCENT,0}},
> {"%/%", do_arith, IDIVOP, 1, 2, {PP_BINARY2, PREC_PERCENT,0}},
>
> (I have removed some blanks so that each line fits in a single line)
>
> Now I get:
> R> deparse(parse( text = "a+b-c*d/e" ))
> [1] "expression(a + b - c * d / e)"
>
> Does this patch has any negative side effects?
>
> "make check" fails, but AFAIK this is just because of different positions of
> line breaks:
> [...]
> running code in 'reg-tests-2.R' ... OK
> comparing 'reg-tests-2.Rout'
> to './reg-tests-2.Rout.save' ...3639,3640c3639,3640
> < aov(formula = dep.variable ~ f1 * f2 + Error(subject / (f1 +
> < f2)), data = sample.df)
> ---
>> aov(formula = dep.variable ~ f1 * f2 + Error(subject/(f1 + f2)),
>> data = sample.df)
> 3693,3694c3693,3694
> < aov(formula = dep.variable ~ f1 * f2 + Error(subject / (f2 +
> < f1)), data = sample.df)
> ---
>> aov(formula = dep.variable ~ f1 * f2 + Error(subject/(f2 + f1)),
>> data = sample.df)
> make[3]: *** [reg-tests-2.Rout] Fehler 1
> [...]
>
>> Duncan Murdoch
>
> Thank you for all your hints,
> Arne
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mingw-cross with R 2.4.x Re: wine and build difference between R.2.4.0 and R 2.4.1 windows binaries?
Hin-Tak Leung wrote: > The issue is filed as http://bugs.winehq.org/show_bug.cgi?id=7181 One of the main wine developers, Alexandre Julliard, closed the bug with a patch. I'll patch my wine and see... pretty good going to resolve a bug within a day...(if the patch works). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mingw-cross with R 2.4.x Re: wine and build difference between R.2.4.0 and R 2.4.1 windows binaries?
On Tue, 16 Jan 2007, Hin-Tak Leung wrote: > Hin-Tak Leung wrote: > >> The issue is filed as http://bugs.winehq.org/show_bug.cgi?id=7181 > > One of the main wine developers, Alexandre Julliard, closed the bug > with a patch. I'll patch my wine and see... pretty good going to resolve > a bug within a day...(if the patch works). I suspect R's median bug resolution time is about that. (For non-spam reported bugs it certainly is, as around 50% are not bugs in R.) -- Brian D. Ripley, [EMAIL PROTECTED] 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] mingw-cross with R 2.4.x Re: wine and build difference between R.2.4.0 and R 2.4.1 windows binaries?
Prof Brian Ripley wrote: > On Tue, 16 Jan 2007, Hin-Tak Leung wrote: > >> Hin-Tak Leung wrote: >> >>> The issue is filed as http://bugs.winehq.org/show_bug.cgi?id=7181 >> >> One of the main wine developers, Alexandre Julliard, closed the bug >> with a patch. I'll patch my wine and see... pretty good going to resolve >> a bug within a day...(if the patch works). > > I suspect R's median bug resolution time is about that. (For non-spam > reported bugs it certainly is, as around 50% are not bugs in R.) Possibly - but then, most bugs in most medium size software are shallow (wine's code base is 11MB bz'ed, while R is 15GB gz'ed, so they are probably comparable in size/complexity, other than wine is a bit harder having to imitate a "black-box operation") - the upper quantile or something further up might be a more interesting measure :-). My patched wine rpm build has finished, and I can confirm that I can now launch 2.4.1 and 2.5dev with it. Thanks. Hin-Tak __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] histbackback function code needs a change with R 2.4.1 version (PR#9456)
Dear Author and Maintainer of Hmisc contributed package, Dear R developers, i noticed a problem with histbackback routine when i installed the last version of R (2.4.1) (With my previous version, 2.3.1, there was no such a problem) If, e.g., you simply edit the command > histbackback(rnorm(20), rnorm(30)) a warning message is printed on the console. Warning messages: 1: argument 'probability' is not made use of in: hist.default(x, breaks = brks, plot = FALSE, probability = probability) 2: argument 'probability' is not made use of in: hist.default(y, breaks = brks, plot = FALSE, probability = probability) To fix this problem I simply REPLACE lines 26-27 of histbackback() code: ll <- hist(x, breaks = brks, plot = FALSE,probability=probability) rr <- hist(y, breaks = brks, plot = FALSE,probability=probability) with: ll <- hist(x, breaks = brks, plot = FALSE) rr <- hist(y, breaks = brks, plot = FALSE) The problem -- i guess -- is generated by the call to hist() which judges "incompatible" setting plot = FALSE and contemporarily specifying the probability argument. In fact, the description of plot argument in hist() function is as follows: plot logical. If TRUE (default), a histogram is plotted, otherwise a list of breaks and counts is returned. In the latter case, a warning is used if (typically graphical) arguments are specified that only apply to the plot = TRUE case. Hence, another correction could be to REMOVE probability argument from the list of "(typically graphical)" arguments that only apply to the plot = TRUE case. Then, it becomes a basic matter of R package. Hope to be of some help and of course I would be very grateful ro receive any comment about. Sincerely, Matilde Trevisani __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Why does not the command 'length(a <- 1:5) <- 4' not work?
when running the command > length(a <- 1:5) <- 4 there are two responses. If 'a' does not exist then the response is Error in length(a <- 1:5) <- 4 : object "a" not found If 'a' does exist then the response is Error in length(a <- 1:5) <- 4 : could not find function "<-<-" I would assume that 'length(a <- 1:5) <- 4' should work because 'length(a <- 1:5)' does work. Thank you for your help. Charles Dupont -- Charles Dupont Computer System Analyst School of Medicine Department of Biostatistics Vanderbilt University __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] histbackback function code needs a change with R 2.4.1 (PR#9457)
On Tue, 16 Jan 2007, [EMAIL PROTECTED] wrote: > Dear Author and Maintainer of Hmisc contributed package, Wromg address, wrong bug repository. Both the R posting guide and the R FAQ warn you that what you have just done is a waste of resources. [...] -- Brian D. Ripley, [EMAIL PROTECTED] 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] incorrect result of deriv (PR#9449)
This is as documented in help(deriv)
The internal code knows about the arithmetic operators '+', '-',
'*', '/' and '^', and the single-variable functions 'exp', 'log',
'sin', 'cos', 'tan', 'sinh', 'cosh', 'sqrt', 'pnorm', 'dnorm',
'asin', 'acos', 'atan', 'gamma' and 'lgamma'. (Note that only the
standard normal distribution is considered.)
-thomas
On Fri, 12 Jan 2007, [EMAIL PROTECTED] wrote:
> Full_Name: Joerg Polzehl
> Version: 2.3.1
> OS: x86_64, linux-gnu
> Submission from: (NULL) (62.141.176.22)
>
>
> I observed an incorrect behavior of function deriv when evaluating arguments
> of
> dnorm
>
> deriv(~dnorm(z,0,s),"z")
> expression({
>.value <- dnorm(z, 0, s)
>.grad <- array(0, c(length(.value), 1), list(NULL, c("z")))
>.grad[, "z"] <- -(z * dnorm(z))
>attr(.value, "gradient") <- .grad
>.value
> })
>
> deriv(~exp(-z^2/(2*s^2))/s/sqrt(2*pi),"z")
> expression({
>.expr4 <- 2 * s^2
>.expr6 <- exp(-z^2/.expr4)
>.expr9 <- sqrt(2 * pi)
>.value <- .expr6/s/.expr9
>.grad <- array(0, c(length(.value), 1), list(NULL, c("z")))
>.grad[, "z"] <- -(.expr6 * (2 * z/.expr4)/s/.expr9)
>attr(.value, "gradient") <- .grad
>.value
> })
>
> should provide the same expression but
>
>> eval(deriv(~exp(-z^2/(2*s^2))/s/sqrt(2*pi),"z"),list(z=1,s=2))
> [1] 0.1760327
> attr(,"gradient")
> z
> [1,] -0.04400817
>
>> eval(deriv(~dnorm(z,0,s),"z"),list(z=1,s=2))
> [1] 0.1760327
> attr(,"gradient")
> z
> [1,] -0.2419707
>
> provide different gradients ...
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
Thomas Lumley Assoc. Professor, Biostatistics
[EMAIL PROTECTED] University of Washington, Seattle
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why does not the command 'length(a <- 1:5) <- 4' not work?
On 1/16/2007 1:24 PM, Charles Dupont wrote:
> when running the command
> > length(a <- 1:5) <- 4
>
> there are two responses.
>
> If 'a' does not exist then the response is
>
> Error in length(a <- 1:5) <- 4 : object "a" not found
>
> If 'a' does exist then the response is
>
> Error in length(a <- 1:5) <- 4 : could not find function "<-<-"
>
> I would assume that 'length(a <- 1:5) <- 4' should work because
> 'length(a <- 1:5)' does work.
I'm guessing you are assuming it would mean the same as
a <- 1:5
length(a) <- 4
But how would R know the name of the variable whose length is set in the
second line? In "a <- 1:5" the "a" is just part of a larger expression,
it's not special as in some other languages, i.e. R sees that as
"<-"(a, 1:5)
So if you rewrote your original as
length("<-"(a, 1:5)) <- 4
it is a lot less clear that you really mean to create and then change "a".
In general things like
foo(a) <- b
are evaluated as "foo<-"(a, b), where "foo<-" is a function that expects
a variable reference as its first argument. There's some magic going on
to allow things like
a <- matrix(1:4, 2,2)
names(dim(a)) <- letters[1:2]
and I think the parser is trying to set things up for that kind of magic
in your expression, though I haven't traced through the execution path
to explain exactly why you saw the error messages you saw.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why does not the command 'length(a <- 1:5) <- 4' not work?
On Tue, 16 Jan 2007, Charles Dupont wrote:
> I would assume that 'length(a <- 1:5) <- 4' should work because
> 'length(a <- 1:5)' does work.
Appearances can be deceptive.
length(a <- 1:5) evaluates a <- 1:5 and then passes its value to length(),
in ordinary call-by-value semantics.
That can't be how complex assignment functions work, though.
Consider
length(names(a))<-5
and suppose names(a) is c("A","B"). This code doesn't just evaluate
names(a) and pass the result on, since
length(c("A","B"))<-5
would be silly (and invalid). It must be doing something more
complicated to make sure that "a", buried deep inside the call, gets
updated.
What actually happens is that
f(x) <- y
is rewritten in terms of the assignment function "f<-" as
x <- "f<-"(x, y)
so
length(names(a))<-5
is
names(a) <- "length<-"(names(a), 5)
which in turn is
a <- "names<-"(a, "length<-"(names(a), 5))
This requires the assignment function "f<-" to exist, of course.
In your case
length(a <- 1:5) <- 4
is rewritten as
(a<-1:5) <- "length<-"(a<-1:5, 5)
and then as
a <- "<-<-"(a, "length<-"(a<-1:5, 5))
which gives the error you report -- there is no function "<-<-".
You might think the last stage of rewriting could just be avoided, but
(a<-1:5) <- "length<-"(a<-1:5, 5)
is invalid if not rewritten, since it tries to modify 1:5, which is not a
variable.
If you want to compute
a <- 1:5
length(a)<-4
then just do it like that.
-thomas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] on.exit called on loading ?
I just found out that an .onLoad() function such as this stylized one (where
I just renamed some identifiers)
.onLoad <- function(lib, pkg) {
require(zoo, quiet=TRUE, warn.conflicts=FALSE)
library.dynam("foolib", pkg, lib )
if (.Platform$OS.type != "windows") {
initSomeServices()
}
if (.Platform$OS.type != "windows") {
on.exit(closeSomeServices())
}
}
actually triggers a call of 'closeSomeServices()'. I am probably
misunderstanding something here -- but I thought on.exit() would only be
called on, well, exit ?
Dirk
--
Hell, there are no rules here - we're trying to accomplish something.
-- Thomas A. Edison
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] on.exit called on loading ?
On 1/16/2007 4:02 PM, Dirk Eddelbuettel wrote:
> I just found out that an .onLoad() function such as this stylized one (where
> I just renamed some identifiers)
>
>
> .onLoad <- function(lib, pkg) {
> require(zoo, quiet=TRUE, warn.conflicts=FALSE)
> library.dynam("foolib", pkg, lib )
> if (.Platform$OS.type != "windows") {
> initSomeServices()
> }
> if (.Platform$OS.type != "windows") {
> on.exit(closeSomeServices())
> }
> }
>
> actually triggers a call of 'closeSomeServices()'. I am probably
> misunderstanding something here -- but I thought on.exit() would only be
> called on, well, exit ?
It's the exit from the function, not the exit from the package (which
isn't really all that well defined -- do you mean unloading, exit from
R, detaching??
It's not very easy to have something be guaranteed to execute "when
you're done". The RODBC package does it using an external pointer,
which has a hook that is called when R shuts down. If it's good enough
to execute on unloading but skip execution on shutdown, then .onUnload
is available.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] on.exit called on loading ?
on.exit() applies to the function where it was called, i.e.
closeSomeServices() is called when .onLoad() exits, or whatever
function it is defined in. You're looking for .onUnload(). Make sure
to read the help for details.
Cheers
Henrik
On 1/17/07, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote:
>
> I just found out that an .onLoad() function such as this stylized one (where
> I just renamed some identifiers)
>
>
> .onLoad <- function(lib, pkg) {
> require(zoo, quiet=TRUE, warn.conflicts=FALSE)
> library.dynam("foolib", pkg, lib )
> if (.Platform$OS.type != "windows") {
> initSomeServices()
> }
> if (.Platform$OS.type != "windows") {
> on.exit(closeSomeServices())
> }
> }
>
> actually triggers a call of 'closeSomeServices()'. I am probably
> misunderstanding something here -- but I thought on.exit() would only be
> called on, well, exit ?
>
> Dirk
>
> --
> Hell, there are no rules here - we're trying to accomplish something.
> -- Thomas A. Edison
>
> __
> 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] Problems with checking documentation vs data, and a proposal
I have a single data file inputs.RData that contains 3 objects. I
generated an Rd page for each object using prompt().
When I run R CMD check I get
* checking for code/documentation mismatches ... WARNING
Warning in utils::data(list = al, envir = data_env) :
data set 'gold' not found
(gold is one of the objects).
This appears to be coming from the codocData function defined in
src/library/tools/R/QC.R (this is in the Debianised source 2.4.1, so the
path might be a little different).
According to the help on this function, it will only attempt a match
when there is a single alias in the documentation file, although I'm not
sure that's what the code does (it seems to check only if there is more
than one format section). At any rate, the central logic appears to
gather up names of data objects and then to load them with
## Try loading the data set into data_env.
utils::data(list = al, envir = data_env)
if(exists(al, envir = data_env, mode = "list",
inherits = FALSE)) {
al <- get(al, envir = data_env, mode = "list")
}
Since there is no gold.RData, this is failing.
This leads to 2 issues: what should I do now, and how might this work
better in the future.
Taking the future first, how about having the code first load all the
data files that it finds somewhere near the beginning? If it did so,
the code
## Try finding the variable or data set given by the alias.
al <- aliases[i]
if(exists(al, envir = code_env, mode = "list",
inherits = FALSE)) {
which precedes the earlier snippet, would find the symbol was defined
and be happy. I suppose the data could be loaded into code_env,
although using it seems to risk deciding that a data symbol is defined
when the symbol refers to a code object.
I'm not sure if attempting to load the data objects individually should
still be attempted under this scenario, if the symbol is not already
present.
What can I do in the short run, particularly since I would like to have
the code pass R CMD check with versions of R that don't include this
possible enhancement, what can I do? I see several options, none of
them beautiful:
1) Delete inputs.RData and create 3 separate data objects. However, I
have code that relies on inputs being present, and the 3 data items go
together naturally.
2) Make a single document describing inputs.RData. First problem: the
page would be awkward combining all 3 things. Second, it looks as if
codocData might still try loading the individual data objects, since it
tries to pull data names out of the documentation, even out of
individual item inside \describe.
3) Attempt to disable the checks by adding multiple aliases or something
else to be revealed by closer inspection of the code. This is a hack
that bypasses the checking altogether (unless it turns out I still get a
complaint about missing documentation).
4) Create gold.RData and others as symlinks to inputs.RData. Fragile
across operating systems, version control systems, and versions of tar.
Might get errors about multiple data definitions.
Usual caveats: this is all based on my imperfect understanding of the
code.
So, any comments on the possible modification to codocData or the
work-arounds?
--
Ross Boylan wk: (415) 514-8146
185 Berry St #5700 [EMAIL PROTECTED]
Dept of Epidemiology and Biostatistics fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739 hm: (415) 550-1062
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] on.exit called on loading ?
On 16 January 2007 at 16:39, Duncan Murdoch wrote:
| On 1/16/2007 4:02 PM, Dirk Eddelbuettel wrote:
| > I just found out that an .onLoad() function such as this stylized one (where
| > I just renamed some identifiers)
| >
| >
| > .onLoad <- function(lib, pkg) {
| > require(zoo, quiet=TRUE, warn.conflicts=FALSE)
| > library.dynam("foolib", pkg, lib )
| > if (.Platform$OS.type != "windows") {
| > initSomeServices()
| > }
| > if (.Platform$OS.type != "windows") {
| > on.exit(closeSomeServices())
| > }
| > }
| >
| > actually triggers a call of 'closeSomeServices()'. I am probably
| > misunderstanding something here -- but I thought on.exit() would only be
| > called on, well, exit ?
|
| It's the exit from the function, not the exit from the package (which
| isn't really all that well defined -- do you mean unloading, exit from
| R, detaching??
Thanks to Robert (off-list), Henrik and Duncan -- I had indeed forgotten /
confused what on.exit() is for. Works as advertised here, but that wasn't
what I wanted at the time. Entirely my bad.
| It's not very easy to have something be guaranteed to execute "when
| you're done". The RODBC package does it using an external pointer,
| which has a hook that is called when R shuts down. If it's good enough
| to execute on unloading but skip execution on shutdown, then .onUnload
| is available.
Yes, I am dealing with a moderately more complicated situation (of
subscribing to some stateful internal 'services') and had not found
.onUnload to be as reliable as I had hoped. But that's another issue.
Thanks again, Dirk
--
Hell, there are no rules here - we're trying to accomplish something.
-- Thomas A. Edison
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems with checking documentation vs data, and a proposal
On Tue, 2007-01-16 at 14:03 -0800, Ross Boylan wrote: > I have a single data file inputs.RData that contains 3 objects. I > generated an Rd page for each object using prompt(). > When I run R CMD check I get > * checking for code/documentation mismatches ... WARNING > Warning in utils::data(list = al, envir = data_env) : >data set 'gold' not found > (gold is one of the objects). . > What can I do in the short run, particularly since I would like to have > the code pass R CMD check with versions of R that don't include this > possible enhancement, what can I do? I see several options, none of > them beautiful: ... > 4) Create gold.RData and others as symlinks to inputs.RData. Fragile > across operating systems, version control systems, and versions of tar. > Might get errors about multiple data definitions. Option 4 worked, though the symlinks were converted to regular files by R CMD check. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] file.copy
Hi,
Copying a non-existing file with file.copy creates an empty file
> r <- file.copy("non-existing-file", ".")
> r
[1] TRUE
... and returns TRUE!
Now, when used in "vectorized" mode
> r <- file.copy(c("toto1", "toto2"), c("dest1", "dest2"))
[1] FALSE FALSE
file.copy looks much more reasonable, except that files "dest1"
and "dest2" are still created (despite the fact that "toto1" and
"toto2" don't exist).
If the 'to' argument is not a dir:
> r <- file.copy(c("toto3", "toto4"), ".")
> r
[1] TRUE TRUE
!!?!?
May be those are (undocumented) features, but I bet 99.9% of the users would
expect something different...
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] file.copy
FYI: I reported this to r-devel on July 23, 2006:
http://tolstoy.newcastle.edu.au/R/devel/06/07/6220.html
There was no follow up.
/Henrik
On 1/17/07, Herve Pages <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Copying a non-existing file with file.copy creates an empty file
>
> > r <- file.copy("non-existing-file", ".")
> > r
> [1] TRUE
>
> ... and returns TRUE!
>
> Now, when used in "vectorized" mode
>
> > r <- file.copy(c("toto1", "toto2"), c("dest1", "dest2"))
> [1] FALSE FALSE
>
> file.copy looks much more reasonable, except that files "dest1"
> and "dest2" are still created (despite the fact that "toto1" and
> "toto2" don't exist).
>
> If the 'to' argument is not a dir:
>
> > r <- file.copy(c("toto3", "toto4"), ".")
> > r
> [1] TRUE TRUE
>
> !!?!?
>
> May be those are (undocumented) features, but I bet 99.9% of the users would
> expect something different...
>
> Cheers,
> H.
>
> __
> 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
