[Rd] Building R v2.1.1 for Windows
Recently, I notice strange things when I try to build R 2.1.1 on Windows XP. I downloaded and unpacked. R-2.1.1.tar.gz. All the tools are in place. I get as far as building the installer, and then the following happens: perl JRins.pl rw2011 rw2011 "C:/Program Files/Inno Setup 5/iscc" R.iss > rw2011.log 2>&1 make[2]: Leaving directory `/cygdrive/c/devel/R/R-2.1.1/src/gnuwin32/installer' make[2]: Entering directory `/cygdrive/c/devel/R/R-2.1.1/src/gnuwin32/installer' rm -rf R.iss Rsmall.iss *.log rw2011 rm: cannot remove directory `rw2011/library/base/html': Directory not empty rm: cannot remove directory `rw2011/library/tcltk/Meta': Directory not empty make[2]: *** [clean] Error 1 make[2]: Leaving directory `/cygdrive/c/devel/R/R-2.1.1/src/gnuwin32/installer' make[1]: *** [rinstaller] Error 2 make[1]: Leaving directory `/cygdrive/c/devel/R/R-2.1.1/src/gnuwin32' make: *** [distribution] Error 2 Looking into the two supposedly nonempty directories I see that in fact that are empty. Of course, I only can look a little bit later, so this might be a timing issue. Has anyone experienced similar problems? This effect is somewhat random. The supposedly nonempty directories change from build attempt to build attempt. So far, this has not happened when I build R-patched and R-devel which I update from SVN. Erich Neuwirth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] weigths in boxplot
In R 2.2.0 density now can work with weighted obesrvations. It would be nice if boxplot also would accept a weight parameter, then one could produce consistent density estimators and boxplots. Could the developers consider adding this feature? -- Erich Neuwirth, Didactic Center for Computer Science University of Vienna Visit our SunSITE at http://sunsite.univie.ac.at Phone: +43-1-4277-39902 Fax: +43-1-4277-9399 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] boxplot.formula and questions about calls and formulas
I am trying to adapt boxplot.formula (in graphics) to accept an
additional parameter, weights.
I already managed to adapt boxplot.default to do this.
boxplot.formula prepares the data for a call to boxplot.default and to
achieve that does the following: It takes a formula like
x~g*h
as the first argument, and then by using
m <- match.call(expand.dots = FALSE)
saves the call. It transforms the call
m$na.action <- na.action # force use of default for this method
m[[1]] <- as.name("model.frame")
and then evaluates the modified call
mf <- eval(m, parent.frame())
print(m)
gives
model.frame(formula = x ~ g * h)
Then it uses components of mf for the call to boxplot.default.
m has a component m$formula containing the parsed model formula.
mode(m$formula) is "call".
In our case, deparse(m$formula) gives a string representation of the
formula: "x~g*h".
I want to replace the response variable (in our case x) by the weights
variable, which in the string expression can be done easily with
strsplit and paste. Then I need to reconvert the modified string to a call.
So I create newmodelstring<-"weights~g*h" and try
m$formula<-as.call(parse(newmodelstring))
print(m)
gives
model.frame(formula = weights ~ g * h())
When I try to evaluate the modified m this does not work. When I try to
evaluate m with this modification I get
Error in model.frame(formula = weights ~ g * h()) :
attempt to apply non-function
Is there a way to get rid of the empty parentheses at the
end of the formula? I think then my code could work.
--
Erich Neuwirth, Didactic Center for Computer Science
University of Vienna
Visit our SunSITE at http://sunsite.univie.ac.at
Phone: +43-1-4277-39902 Fax: +43-1-4277-9399
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Questions about calls and formulas
I am trying to adapt boxplot.formula (in graphics) to accept an
additional parameter, weights.
I already managed to adapt boxplot.default to do this.
boxplot.formula prepares the data for a call to boxplot.default and to
achieve that does the following: It takes a formula like
x~g*h
as the first argument, and then by using
m <- match.call(expand.dots = FALSE)
saves the call. It transforms the call
m$na.action <- na.action # force use of default for this method
m[[1]] <- as.name("model.frame")
and then evaluates the modified call
mf <- eval(m, parent.frame())
print(m)
gives
model.frame(formula = x ~ g * h)
Then it uses components of mf for the call to boxplot.default.
m has a component m$formula containing the parsed model formula.
mode(m$formula) is "call".
In our case, deparse(m$formula) gives a string representation of the
formula: "x~g*h".
I want to replace the response variable (in our case x) by the weights
variable, which in the string expression can be done easily with
strsplit and paste. Then I need to reconvert the modified string to a call.
So I create newmodelstring<-"weights~g*h" and try
m$formula<-as.call(parse(newmodelstring))
print(m)
gives
model.frame(formula = weights ~ g * h())
When I try to evaluate the modified m this does not work. When I try to
evaluate m with this modification I get
Error in model.frame(formula = weights ~ g * h()) :
attempt to apply non-function
Is there a way to get rid of the empty parentheses at the
end of the formula? I think then my code could work.
--
Erich Neuwirth, Didactic Center for Computer Science
University of Vienna
Visit our SunSITE at http://sunsite.univie.ac.at
Phone: +43-1-4277-39902 Fax: +43-1-4277-9399
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Questions about calls and formulas
>
>>(foo <- eval(substitute(x ~ g * h, list(x = as.name("weights")
>
> weights ~ g * h
>
>>class(foo)
>
> [1] "formula"
>
>
ff<-formula("x~g*h")
(foo<-eval(substitute(ff,list(x=as.name("weights")
gives
x ~ g * h
what needs to be done to ff for the substitution to work?
I found a way of doing it using string substitution
and applying formula (instead of as.call) to the string,
but I would like to be able to do it using substitution.
This is what I currently do:
myexpr<-paste("weights ~",strsplit(deparse(m$formula),"~")[[1]][2])
m$formula<-formula(myexpr)
--
Erich Neuwirth, Didactic Center for Computer Science
University of Vienna
Visit our SunSITE at http://sunsite.univie.ac.at
Phone: +43-1-4277-39902 Fax: +43-1-4277-9399
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Questions about calls and formulas
> Try do.call like this:
>
> ff <- x ~ g*h
> do.call("substitute", list(ff, list(x = as.name("weight"
>
It is even more complicated.
All I know is that ff is a formula with an expression on the left hand
side. This expression needs to be replaced by "weights".
According to the documentation, substitute only handles
replacement of variables by something else,
and that is not enough in my case.
--
Erich Neuwirth, Didactic Center for Computer Science
University of Vienna
Visit our SunSITE at http://sunsite.univie.ac.at
Phone: +43-1-4277-39902 Fax: +43-1-4277-9399
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] weigths in boxplot
Martin, Frank Harrell's Hmisc has weigthed variants of quite a few statistical estimators, including quantiles. I never have look at how efficiently this is implemented, but as far as I know it works. Erich Martin Maechler wrote: >>>>>>"Erich" == Erich Neuwirth <[EMAIL PROTECTED]> >>>>>>on Sun, 21 Aug 2005 18:51:20 +0200 writes: > > > Erich> In R 2.2.0 density now can work with weighted > Erich> obesrvations. It would be nice if boxplot also would > Erich> accept a weight parameter, then one could produce > Erich> consistent density estimators and boxplots. > > Erich> Could the developers consider adding this feature? > > The first thing I'd want is quantile() with weights --- which I > personally find quite interesting and have wanted several times > in the past --- not wanted enough to implement though. > > I'm interested to hear of (or even see C or R implementations of) > fast algorithms for "weight quantiles". > Code contributions are welcome too.. > > (And yes, I do know that boxplots are base on "hinges" rather than > quartiles but that's less interesting here.) > > Martin Maechler <[EMAIL PROTECTED]> http://stat.ethz.ch/~maechler/ > Seminar fuer Statistik, ETH-Zentrum LEO C16 Leonhardstr. 27 > ETH (Federal Inst. Technology)8092 Zurich SWITZERLAND > phone: +41-44-632-3408fax: ...-1228 <>< > -- Erich Neuwirth, Didactic Center for Computer Science University of Vienna Visit our SunSITE at http://sunsite.univie.ac.at Phone: +43-1-4277-39902 Fax: +43-1-4277-9399 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] tapply
compared to by tapply has the nice property that the output is a
multidimensional array. But in its standard form it only accepts one
vector, a list of factors, and a function of one argument.
Then it splits the vector according to the factor(s) and
applies the function to each of subsets created by the split.
Therefore, it can not be used to compute weighted means
with one vector containing the data and another vector containing
the weights.
There are other ways of computing groupwise weighted means,
but they do not return multidimensional arrays, but lists.
Therefore, I rewrote tapply to handle a list of vectors as its first
argument. If the list contains n vectors, the function argument has to
be a function of n arguments. Then, all the vectors are split according
to the factor list, and the function is applied to each of the subsets
defined this way.
Following is the code for mtapply doing this.
It could be used as a replacement for tapply, since it
handles vector arguments just like the current implementation of tapply
does.
Perhaps other list members are interested in testing this function,
and perhaps there is even interest in including this extended version of
tapply in the R distribution.
###
mtapply<-function (X, INDEX, FUN = NULL, ..., simplify = TRUE)
{
FUN <- if (!is.null(FUN))
match.fun(FUN)
if (!is.list(INDEX))
INDEX <- list(INDEX)
nI <- length(INDEX)
namelist <- vector("list", nI)
names(namelist) <- names(INDEX)
extent <- integer(nI)
nx <- ifelse(is.list(X),length(X[[1]]),length(X))
one <- as.integer(1)
group <- rep.int(one, nx)
ngroup <- one
for (i in seq(INDEX)) {
index <- as.factor(INDEX[[i]])
if (length(index) != nx)
stop("arguments must have same length")
namelist[[i]] <- levels(index)
extent[i] <- nlevels(index)
group <- group + ngroup * (as.integer(index) - one)
ngroup <- ngroup * nlevels(index)
}
if (is.null(FUN))
return(group)
if (!is.list(X)) {
ans <- lapply(split(X, group), FUN, ...)
index <- as.numeric(names(ans))
}
else {
myargs<-vector("list",length(X)+1)
for (i in 1:length(X)) myargs[[i+1]]<-split(X[[i]],group)
myargs[[1]]<-FUN
ans<-do.call(mapply,myargs)
ansx <- lapply(myargs[[2]],length)
index <- as.numeric(names(ansx))
}
if (simplify && all(unlist(lapply(ans,length)) == 1)) {
ansmat <- array(dim = extent, dimnames = namelist)
if (is.list(ans)) ans <- unlist(ans, recursive = FALSE)
}
else {
ansmat <- array(vector("list", prod(extent)), dim = extent,
dimnames = namelist)
}
names(ans) <- NULL
ansmat[index] <- ans
ansmat
}
###
--
Erich Neuwirth, Didactic Center for Computer Science
University of Vienna
Visit our SunSITE at http://sunsite.univie.ac.at
Phone: +43-1-4277-39902 Fax: +43-1-4277-9399
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Question about colnames behavior
The following code zzz<-1:10 dim(zzz)<-10 rownames(zzz) colnames(zzz) yields NULL for the rownames and colnames calls. Let us set rownames rownames(zzz)<-1:10 Now rownames(zzz) returns the expected result, but colnames(zzz) produces an error: Error in dn[[2]] : subscript out of bounds So given a onedimensional structure the return behavior of colnames is different depending on the fact if rownames are set or not. Should the behavior of colnames be changed to make the result independent from this fact? -- Erich Neuwirth, Didactic Center for Computer Science University of Vienna Visit our SunSITE at http://sunsite.univie.ac.at Phone: +43-1-4277-39902 Fax: +43-1-4277-9399 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Use of R in C#
Please discuss statconnDCOM related problems on its dedicated mailing list. You can subscribe at rcom.univie.ac.at On 5/22/2011 2:31 PM, Andra wrote: > > Jeff Abrams microsoft.com> writes: > >> >> I have a C# program that requires the run of a logistic regression. I have > downloaded the R 2.11 package, and >> have added the following references to my code: __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Use of R in C#
statconnDCOM (and RExcel) have their own mailing list. Please subscribe at rcom.univie.ac.at and post your questions on that list. On Jun 5, 2011, at 5:53 AM, notoriousnoah wrote: > Everyone refs 3 names spaces. I can ref STATCONNECTORCLNTLib and > StatConnectorCommonLib but > > I don't have the DLL to ref STATCONNECTORSRVLib?? > > > Can you let me know where I cann download StatConnectorCommonLib.DLL? > > I tried R_SCILab_DCom3.0-1B.exe, and statConnDCom.lastest.exe and > RAndFriendsSetup213.EXE. Not one of these has this DLL. > > Best, > Noah > > > -- > View this message in context: > http://r.789695.n4.nabble.com/Use-of-R-in-C-tp2165189p3574601.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 > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Typo in NEWS file for R-devel
From the first page of the NEWS file: (2016-04-29 r70564) isSymmetrix(m) is much faster for large asymmetric matrices m via pre-tests and a new option tol1 (with which strict back compatibility is possible but not the default). It probably should be isSymmetric signature.asc Description: Message signed with OpenPGP using GPGMail __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] source and textConnection
Is this warning given on purpose?
> myconn<-textConnection("print(11*11)")
> source(myconn)
[1] 121
Warning message:
In source(myconn) : argument 'encoding = "native.enc"' will be ignored
Could it be omitted, since the docs state that encoding is only use if
the corresponding argument is a file name or url?
--
Erich Neuwirth, University of Vienna
Faculty of Computer Science
Computer Supported Didactics Working Group
Visit our SunSITE at http://sunsite.univie.ac.at
Phone: +43-1-4277-39464 Fax: +43-1-4277-39459
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] source and textConnection
Using todays freshly downloaded compiled version of R-2.10.0 beta
let me pose this question once again:
>> myconn<-textConnection("print(11*11)")
>> source(myconn)
produces
> [1] 121
> Warning message:
> In source(myconn) : argument 'encoding = "native.enc"' will be ignored
So I get a warning about a default parameter value I did not use myself.
This is somewhat strange.
Up to 2.9.2 this warning did not show up,
and 2.9.2 also has the encoding parameter.
source(myconn,encoding="unknown")
does not produce a warning.
Will it remain like this?
I am asking because then I have to adapt a certain mechanism in RExcel.
--
Erich Neuwirth, University of Vienna
Faculty of Computer Science
Computer Supported Didactics Working Group
Visit our SunSITE at http://sunsite.univie.ac.at
Phone: +43-1-4277-39464 Fax: +43-1-4277-39459
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] exmaple problems
I do not know if this has been reported already (I searched the headers of the recent messages to r-devel) It seems that 'example' in R 2.11.0 has a problem when the help file does not contain any example. This is what happens on R 2.11.0 on Windows XP. > library(tools) > example(Rdiff) Error in file(con, "r") : cannot open the connection In addition: Warning message: In file(con, "r") : cannot open file 'C:\DOCUME~1\neuwirth\LOCALS~1\Temp\RtmpmknOJe\Rex678418be': No such file or directory The error does not occur when there is an example marked #Not Run: The problem does not appear in R 2.10.1 > library(tools) > example(Rdiff) Warning message: In example(Rdiff) : 'Rdiff' has a help file but no examples > -- Erich Neuwirth, University of Vienna Faculty of Computer Science Center for Computer Science Didactics and Learning Research Visit our SunSITE at http://sunsite.univie.ac.at Phone: +43-1-4277-39902 Fax: +43-1-4277-39459 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] exmaple problems
The problem still exists in the beta of R 2.11.1 I just build from the sources. (WinXP) R version 2.11.1 beta (2006-00-00 r0) On 5/22/2010 4:08 PM, Erich Neuwirth wrote: > I do not know if this has been reported already > (I searched the headers of the recent messages to r-devel) > It seems that 'example' in R 2.11.0 has a problem when the help file > does not contain any example. > This is what happens on R 2.11.0 on Windows XP. > >> library(tools) >> example(Rdiff) > Error in file(con, "r") : cannot open the connection > In addition: Warning message: > In file(con, "r") : > cannot open file > 'C:\DOCUME~1\neuwirth\LOCALS~1\Temp\RtmpmknOJe\Rex678418be': No such > file or directory > > The error does not occur when there is an example marked #Not Run: > > The problem does not appear in R 2.10.1 >> library(tools) >> example(Rdiff) > Warning message: > In example(Rdiff) : 'Rdiff' has a help file but no examples >> > > -- Erich Neuwirth, University of Vienna Faculty of Computer Science Center for Computer Science Didactics and Learning Research Visit our SunSITE at http://sunsite.univie.ac.at Phone: +43-1-4277-39902 Fax: +43-1-4277-39459 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bridging R to OpenOffice
Since I implemented the RExcel interface I also would like this
discussion to be continued on r-devel or some other list where
I can follow it.
Let me add some thoughts:
As Leonhard Mada suggested, probably the most needed connection
between R and a spreadsheet program is a way to transfer
dataframes easily from the spreadsheet to R and analysis
results back from R to Excel. To do this, one needs to have a
mechanism to transfer large amounts of data of different types.
An additional complication for the way back fro R to the
spreadsheet is that R results quite often have data types not
supported by the spreadsheet program (complex numbers for
example).
The convenience tool that people really want in the first place
is an item on the menu which allows to transfer a range with
data from the spreadsheet to R.
The question then is: should the users see the R command line?
There has to be a way of telling R what kind of analysis to
perform. Using a menu like the one supplied by RCommander is a
sensible option. Using this also would reuse all the work
invested in designing a good menu structure for end users.
Getting results back into the spreadsheet is more difficult.
Not technically, but from the design point of view. Analysis
results in R usually are not arrays, but lists, i.e. compounds
of compounds of data of different basic types, and of different
sizes. There is no clear general rule how to put R results into
spreadsheet ranges. The basic compound data type in
spreadsheets are arrays, and the data types in R are much more
complicated, and the conceptual mapping of result lists to
spreadsheet ranges has to be designed differently for different
types of analyses and results. Of course, a brute force method
(implemented for example by the connection mechanism between
NAG and Excel) would be to "just print" the results into the
spreadsheet as strings. This way, spreadsheet rows become
printed lines without further structure, and numbers in the
results are not easily accessible for further computations on
the spreadsheet.
Such a "transfer data frame and get results" connection,
however, is not really using the spreadsheet program as a
spreadsheet program, but as a data grid and output formatting
machinery, since it is completely independent of the
spreadsheet program's most important feature, automatic
recalculation triggered by changes of cell values.
A really tight integration of R and a spreadsheet can extend
the spreadsheet program's computational engine by the complete
R engine. It could allow spreadsheet formulas like
RApply("pchisq",A1,A2)
which would have R compute the value of the chi-squared
distribution with arguments in cells A1 and A2 of the
spreadsheet. Changing the value in A1 would trigger R to
recalculate the chi-square value.
In this case, the connection between R and the spreadsheet
program has to be very fast, since the spreadsheet program
essentially is using R as a dynamically linked library. The
problem of incompatible data types also becomes much harder to
deal with. The results of R computations are directly put into
spreadsheet ranges, so having R results consisting of lists
makes things really difficult.
Thomas Baier and I recently published a paper in Computational
Statistics which discusses different models of integration
between R and spreadsheets. Excel is used as an example, but
the concepts are independent from the concrete implementation.
It is accessible at http://dx.doi.org/10.1007/s00180-007-0023-6
If you cannot access it, write to me, I will send you a copy.
Currently, we are working on a cross-platform alternative to using
COM to connect the spread-sheet to R. The platforms in mind are
(at least) Windows, Linux and MacOS (X). The spreadsheet program
of choice for our next integration will be Gnumeric, where the
integration is already worked on by students.
--
Erich Neuwirth, Didactic Center for Computer Science
University of Vienna
Visit our SunSITE at http://sunsite.univie.ac.at
Phone: +43-1-4277-39464 Fax: +43-1-4277-9394
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Windows version make installer
I stumbled upon a minor problem when creating a customized installer using make myR IMAGEDIR=x in src/gnuwin32/installer In IMAGEDIR i have a complete installation with many additional directories with packages in the directory site-library. Since the libraries are not in library, help.start, when run, creates a file "fixedHTMLLinks" in each of the package directories. These files are included in the installer created with make. Since the version installed from this installer may live in a different directories, the fixedHTMLLinks point to incorrect places after such an install. So it might make sense that make myR IMAGEDIR=x does not include all these fixedHTMLLinks in the installer. Erich Neuwirth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rprofile.site in Windows version
I think Rprofile.site as installed with R-2.6.2
contains some misleading information.
It contains the following lines
# set a CRAN mirror
# local({r <- getOption("repos")
# r["CRAN"] <- "http://my.local.cran";
# options(repos=r)})'.
Uncommenting these lines and changing the URL
will not work.
'. at the end of the last line will break the execution.
Furthermore
library(tools)
needs to be run before these lines can be run.
--
Erich Neuwirth, University of Vienna
Faculty of Computer Science
Computer Supported Didactics Working Group
Visit our SunSITE at http://sunsite.univie.ac.at
Phone: +43-1-4277-39464 Fax: +43-1-4277-39459
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rprofile.site in Windows version
You are of course right, library(tools) is not necessary.
Duncan Murdoch wrote:
> On 09/02/2008 6:44 PM, Erich Neuwirth wrote:
>> I think Rprofile.site as installed with R-2.6.2
>> contains some misleading information.
>> It contains the following lines
>>
>> # set a CRAN mirror
>> # local({r <- getOption("repos")
>> # r["CRAN"] <- "http://my.local.cran";
>> # options(repos=r)})'.
>>
>> Uncommenting these lines and changing the URL
>> will not work.
>>
>> '. at the end of the last line will break the execution.
>
> Yes, those shouldn't be there.
>
>> Furthermore
>> library(tools)
>> needs to be run before these lines can be run.
>
> Why? local, getOption, and options are all in the base package.
>
> Duncan Murdoch
>
>
--
Erich Neuwirth, University of Vienna
Faculty of Computer Science
Computer Supported Didactics Working Group
Visit our SunSITE at http://sunsite.univie.ac.at
Phone: +43-1-4277-39464 Fax: +43-1-4277-39459
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Possible uninstall problem on windows.
I just uninstalled R 2.7.2 on Windows XP after having installed R 2.8.0 The uninstaller removed the String values HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R\Current Version HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R\InstallPath despite the fact that they pointed to R 2.8.0 The uninstaller did not remove the key HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R\2.7.2 (and all the values in that key) I think the uninstaller should only remove the Current Version entry if it points to its own version. In a second attempt, the 2.7.2 uninstaller removed the key HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R\2.7.2 (which is what it should do) but it still removed the HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R\Current Version HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R\InstallPath values. It should not have removed these keys. Sometimes this does not happen, and I have not found a consistent explanation when it happens and when not. Sometimes also running RSetReg.exe creates a second entry like HKEY_LOCAL_MACHINE\SOFTWARE\R-core\R\2.7.2 which has identical content with the first one. The registry really looks like having 2 identical entries. Is this something which I should file as a bug? -- Erich Neuwirth, University of Vienna Faculty of Computer Science Computer Supported Didactics Working Group Visit our SunSITE at http://sunsite.univie.ac.at Phone: +43-1-4277-39464 Fax: +43-1-4277-39459 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rscproxy version conflict
We found out about this problem only a few days ago.
The reason is that the official binary packages were compiled with
2.8.1, but the distributed Windows binary of R was still 2.8.0.
rscproxy needs to be compiled for the correct version of R.
Now with R 2.8.1 being release officially the problem should disappear,
but we (which is mostly Thomas Baier, the mastermind behind rcom and
R(D)COM server) will try to find a way to avoid this problem with the
next R update.
Before R 2.8.0, rproxy.dll distributed with R itself was
supplying the underlying mechanism for the rcom package and R(D)COM
server. rproxy.dll was removed from R itself, and rscproxy is the
current substitute. rproxy.dll, being part of R itself, always matched
the R version to the very last digit. With rscproxy, it is more
difficult to stay in sync.
meerman wrote:
> After installing the package 'rscproxy' downloaded from the CRAN server, I
> get the following error message from R 2.8.0 about a version conflict :
>
>
>
>
>
> package 'rscproxy' successfully unpacked and MD5 sums checked
>
>
>
> The downloaded packages are in
>
> C:\Documents and Settings\John Meerman\Local
>
> Settings\Temp\RtmpbK9mxN\downloaded_packages
>
> updating HTML package descriptions
>
>> local({pkg <- select.list(sort(.packages(all.available = TRUE)))
>
> + if(nchar(pkg)) library(pkg, character.only=TRUE)})
>
> *Warning message:
>
> package 'rscproxy' was built under R version 2.8.1 *>
>
>
>
> This prevents me e.g. to use the R (D)COM 3.0 server.
>
>
>
>
>
>
>
>
>
> John Meerman
>
>
>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
> --------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.176 / Virus Database: 270.9.19/1854 - Release Date: 12/17/2008
> 7:21 PM
>
--
Erich Neuwirth, University of Vienna
Faculty of Computer Science
Computer Supported Didactics Working Group
Visit our SunSITE at http://sunsite.univie.ac.at
Phone: +43-1-4277-39464 Fax: +43-1-4277-39459
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rscproxy version conflict
Simon Urbanek wrote: > > It's ok to use a package built for 2.8.0 in 2.8.1 but not vice versa. It > is rare, but it has happened before that a bugfix or visibility change > adds a symbol in x.y.1 that was not there in x.y.0. Then if your package > checks for that particular feature and uses it you cannot use that > binary with x.y.0. Again, this is rather rare and you as the package > author know about it, but to be on the safe side I was recommending > against that. However, as Brian pointed out this happens far more often > on the R function level than on the C API level. > > (I know about this DLL version check because it was the first change I > made to JRI since I wasn't willing to release Windows binary some five > times a year ;)). > What happened recently was that R still officially was at 2.8.0, but the binary Windows packages already were compiled with RC1 of 2.8.1. So by downloading the official versions of R and then some packages from CRAN one had a mixture of old R and new packages which is what you describe as "this should not be done". -- Erich Neuwirth, University of Vienna Faculty of Computer Science Computer Supported Didactics Working Group Visit our SunSITE at http://sunsite.univie.ac.at Phone: +43-1-4277-39464 Fax: +43-1-4277-39459 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] fonts in postscript device
I humbly suggest adding the fonts argument to the list of arguments recognized and processed by ps.options. Here is my argument: Currently, in Sweave it seems to be impossible to use multiple font families in <> code chunks without additional moderately inconvenient coding. The problem is that it is possible to use par(family="xxx") in postscript and pdf devices (which are the devices used by Sweave), but the fonts used in par statements also have to be included in the fonts argument of the postscript or pdf device when the device is opened. In normal mode, Sweave opens the device all by itself, therefore in this mode it seems not possible to change the fonts used by the postscript or pdf device. Instead, one has to explicitly open the device in one's own code chunk. That is possible, but then one has to manually take care of including the generated postscript and/or pdf files also. The easiest solution would be that ps.options accepts the fonts parameter, which it currently does not. That way, one could set the fonts available by default when Sweave uses the postscript device. -- Erich Neuwirth, Didactic Center for Computer Science University of Vienna Visit our SunSITE at http://sunsite.univie.ac.at Phone: +43-1-4277-39464 Fax: +43-1-4277-9394 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Date and time problems
I am running R 2.3.1 on Windows XP. My machine is set (via the Windows Control Panel) to Central European time (Amsterdam, Berlin, Rome, Stockholm, Vienna) and automatically has DST set, so I am 2 hours ahead of GMT. No TZ variable is set. > Sys.timezone() [1] "W. Europe Standard Time" > Sys.Date() [1] "2006-08-15" > as.POSIXlt(Sys.Date()) [1] "2006-08-15" > as.POSIXct(Sys.Date()) [1] "2006-08-15 02:00:00 W. Europe Standard Time" > as.POSIXct(as.POSIXlt(Sys.Date())) [1] "2006-08-15 01:00:00 W. Europe Standard Time" Converting to POSIXct and converting to POSIXlt and then to POSIXct produces different results, which is rather strange. When I do > Sys.time() [1] "2006-08-16 00:12:40 W. Europe Standard Time" I get my clock time with numerically correct time for my location, but with an incorrect timezone stamp. If I set TZ=CET, something else happens. It is just past midnight, my Windows system clock shows 12:33 AM, and the date is Aug 16 (here in Austria) With TZ=CET, > Sys.Date() [1] "2006-08-15" > Sys.time() [1] "2006-08-15 22:33:30 CET" So I get current GMT time (my time - 2 hours) and date, but with a CET time stamp. When TZ does not have a value, > Sys.Date() [1] "2006-08-16" > Sys.time() [1] "2006-08-16 00:32:37 W. Europe Standard Time" This is numerically correct time and date, but with an incorrect timezone stamp. So I never get completely correct information, even when Windows timezone information is correct and TZ has the correct value. Is this something which should be corrected? -- Erich Neuwirth, University of Vienna Faculty of Computer Science Computer Supported Didactics Working Group Visit our SunSITE at http://sunsite.univie.ac.at Phone: +43-1-4277-39464 Fax: +43-1-4277-39459 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Date conversion with as.POSIXct and as.POSIXlt (PR#9196)
Full_Name: Erich Neuwirth Version: 2.3.1 OS: Windows XP, Linux Submission from: (NULL) (131.130.135.167) Converting Sys.Date() to a POSIX compliant time type in different ways produces inconsistent results: > Sys.date() [1] "2006-09-01" > as.POSIXct(Sys.Date()) [1] "2006-09-01 02:00:00 CEST" > as.POSIXlt(Sys.Date()) [1] "2006-09-01" > as.POSIXct(as.POSIXlt(Sys.Date())) [1] "2006-09-01 01:00:00 CEST" Applying as.POSIXct directly or first applying as.POSIXlt and then applying as.POSIXct produces different results. This happens on Linux with timezone "CEST" > Sys.time() [1] "2006-09-01 11:03:36 CEST" and on Windows with timezone "W. Europe Daylight Time" > Sys.time() [1] "2006-09-01 11:11:15 W. Europe Daylight Time" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Date conversion with as.POSIXct and as.POSIXlt
After the discussions which really helped me understanding
the issues involved let me summarize some possibly surprising
behavior of as.POSIXlt and as.POSIXct and the print method of
class POSIXlt (the print method problem seems to be a Windows
only problem) in R 2.3.1
- as.POSIXlt and as.POSIXct accept but ignore tz parameters
when the argument object is of class Date. They do react to
tz parameters when the argument object is a string representing
a date.
> as.POSIXct(firstjan)
[1] "2006-01-01 01:00:00 CET"
> as.POSIXct(firstjan,tz="HST10")
[1] "2006-01-01 01:00:00 CET"
> as.POSIXlt(firstjan)
[1] "2006-01-01"
> as.POSIXlt(firstjan,tz="HST10")
[1] "2006-01-01"
> as.POSIXct(as.character(firstjan))
[1] "2006-01-01 CET"
> as.POSIXct(as.character(firstjan),tz="HST10")
[1] "2006-01-01 HST"
> as.POSIXlt(as.character(firstjan))
[1] "2006-01-01"
> as.POSIXlt(as.character(firstjan),tz="HST10")
[1] "2006-01-01 HST10"
Furthermore, for string arguments the timezone label for as.POSIXct
and as.POSIXlt is different in the example above ("HST" and "HST10")
- as.POSIXlt in R 2.4.0alpha (I could test this only on Windows)
seems to behave slightly differently, it attaches timezone UTC
for inputs of class Date.
> as.POSIXlt(firstjan)
[1] "2006-01-01 UTC"
> as.POSIXlt(firstjan,tz="HST10")
[1] "2006-01-01 UTC"
It still does not attach a timezone if the input is a string
representing a date (like in the first example).
- as.POSIXct will give different results for Date objects
and their string representations in non-UTC timezones
(the first example illustrates this fact)
- the print method for POSIXlt objects on Windows in some cases
will not display the correct timezone label, it will convert it
to a sometimes somewhat strange 3 letter string. The docs state
that timezone labels have to have a standardized format,
but (at least for me) it is unexpected that using Sys.timezone()
as tz argument gives a very strange timezone label.
See the following example
> Sys.time()
[1] "2006-09-05 23:05:48 W. Europe Daylight Time"
> as.POSIXct(Sys.time(),tz=Sys.timezone())
[1] "2006-09-05 23:06:06 W. Europe Daylight Time"
> as.POSIXlt(Sys.time(),tz=Sys.timezone())
[1] "2006-09-05 22:06:11 Eur"
--
Erich Neuwirth, University of Vienna
Faculty of Computer Science
Computer Supported Didactics Working Group
Visit our SunSITE at http://sunsite.univie.ac.at
Phone: +43-1-4277-39464 Fax: +43-1-4277-39459
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
