[Rd] Fwd: Does not run under Mac OS X 10.3.9 (PR#7975)
Begin forwarded message: > From: Matthias Wahl <[EMAIL PROTECTED]> > Date: 28 giugno 2005 18:05:54 GMT+02:00 > To: stefano iacus <[EMAIL PROTECTED]> > Subject: Re: [Rd] Does not run under Mac OS X 10.3.9 (PR#7975) > > > I don' have a folder 'Utilities' in applications, however here is > what I get when I chose > 'send error report to Apple'. Maybe that helps you, too. > > Date/Time: 2005-06-28 18:03:45 +0200 > OS Version: 10.3.9 (Build 7W98) > Report Version: 2 > > Command: R > Path:/Applications/R.app/Contents/MacOS/R > Version: 1.11 (1.11) > PID: 374 > Thread: 0 > > Exception: EXC_BAD_ACCESS (0x0001) > Codes: KERN_INVALID_ADDRESS (0x0001) at 0x8006 > > Thread 0 Crashed: > 0 com.apple.CoreFoundation 0x901c0f74 CFRetain + 0x20 > 1 com.apple.CoreFoundation 0x901dcc74 CFArrayCreate + 0x144 > 2 com.apple.Foundation 0x90a6c5e4 -[NSArray > initWithObjects:] + 0xbc > 3 org.R-project.R 0x32e4 -[RController init] + > 0x174 > 4 com.apple.AppKit 0x92f6bca8 -[NSCustomObject > nibInstantiate] + 0x10c > 5 com.apple.AppKit 0x92e9ae54 -[NSIBObjectData > instantiateObject:] + 0xbc > 6 com.apple.AppKit 0x92ea1e80 -[NSIBObjectData > nibInstantiateWithOwner:topLevelObjects:] + 0x88 > 7 com.apple.AppKit 0x92f93c2c loadNib + 0xfc > 8 com.apple.AppKit 0x92eeae24 +[NSBundle > (NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] + 0x2e8 > 9 com.apple.AppKit 0x92f69d28 +[NSBundle > (NSNibLoading) loadNibFile:externalNameTable:withZone:] + 0x9c > 10 com.apple.AppKit 0x92f7b51c +[NSBundle > (NSNibLoading) loadNibNamed:owner:] + 0x174 > 11 com.apple.AppKit 0x92f69b90 NSApplicationMain + 0x174 > 12 org.R-project.R 0x2ba0 _start + 0x188 (crt.c:267) > 13 dyld 0x8fe1a278 _dyld_start + 0x64 > > PPC Thread State: > srr0: 0x901c0f74 srr1: 0x0200f030vrsave: 0x > cr: 0x22000448 xer: 0x0002 lr: 0x901c0f6c ctr: 0x901c5acc > r0: 0x901dcc74 r1: 0xb5f0 r2: 0x22000448 r3: 0x8000 > r4: 0x8000 r5: 0xb584 r6: 0x0003a348 r7: 0x0003a348 > r8: 0x0003a348 r9: 0x0008 r10: 0x r11: 0xa0a21114 >r12: 0x901c5acc r13: 0x r14: 0x r15: 0x >r16: 0x00311f50 r17: 0xa2eaab3c r18: 0xa2e9ab3c r19: 0xa2eaab3c >r20: 0xa2eaab3c r21: 0x0003bf18 r22: 0x r23: 0x0009 >r24: 0xb720 r25: 0xb724 r26: 0x003a14c0 r27: 0xa01c2e94 >r28: 0x0009 r29: 0x003a1490 r30: 0x003a14bc r31: 0x901c0f6c > > Binary Images Description: > 0x1000 -0x38fff org.R-project.R 1.11/Applications/R.app/ > Contents/MacOS/R > 0x205000 - 0x226fff libreadline.5.0.dylib /Library/ > Frameworks/R.framework/Resources/lib/libreadline.5.0.dylib > 0x1008000 - 0x1195fff libR.dylib /Library/Frameworks/ > R.framework/Resources/lib/libR.dylib > 0x806c - 0x806e9fff libxslt.1.dylib /usr/lib/libxslt.1.dylib > 0x8083 - 0x8090efff libxml2.2.dylib /usr/lib/libxml2.2.dylib > 0x8ed6 - 0x8ed62fff com.apple.ExceptionHandling 1.2 (???)/ > System/Library/Frameworks/ExceptionHandling.framework/Versions/A/ > ExceptionHandling > 0x8fe0 - 0x8fe4 dyld /usr/lib/dyld > 0x9000 - 0x9014 libSystem.B.dylib /usr/lib/ > libSystem.B.dylib > 0x901c - 0x9026dfff com.apple.CoreFoundation 6.3.7 (299.35)/ > System/Library/Frameworks/CoreFoundation.framework/Versions/A/ > CoreFoundation > 0x902b - 0x90529fff com.apple.CoreServices.CarbonCore > 10.3.7/System/Library/Frameworks/CoreServices.framework/ > Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore > 0x90584000 - 0x905f3fff com.apple.framework.IOKit 1.3.6 (???)/ > System/Library/Frameworks/IOKit.framework/Versions/A/IOKit > 0x9061 - 0x9069afff com.apple.CoreServices.OSServices 3.0.1/ > System/Library/Frameworks/CoreServices.framework/Versions/A/ > Frameworks/OSServices.framework/Versions/A/OSServices > 0x9070 - 0x90700fff com.apple.CoreServices 10.3 (???)/ > System/Library/Frameworks/CoreServices.framework/Versions/A/ > CoreServices > 0x907c7000 - 0x907d2fff libCSync.A.dylib /System/Library/ > Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ > CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib > 0x907f - 0x907f9fff com.apple.DiskArbitration 2.0.5/System/ > Library/PrivateFrameworks/DiskArbitration.framework/Versions/A/ > DiskArbitration > 0x9081 - 0x90810fff com.apple.ApplicationServices 1.0 (???)/ > System/Library/Frameworks/ApplicationServices.framework/Versions/A/ > ApplicationServices > 0x9083 - 0x9089 libobjc.A.dylib /usr/lib/libobjc.A.dylib > 0x9094 - 0x909b3fff com.apple.DesktopServices 1.2.5/System/ > Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/
Re: [Rd] Failed "make check" under Fedora Core 4 (PR#7979)
On Wed, 2005-06-29 at 19:55 +0200, [EMAIL PROTECTED] wrote:
> I downloaded R v2.1.1 earlier this morning to compile under Fedora Core
> 4. It compiled without incident, but 'make check' failed. Below is the
> relevant part of its report. Is this a known problem?
It is known that gcc 4.0.0 is buggy. The current recommendation, from
Brian Ripley, is to use gcc 3.4.4 instead. We are awaiting the bug-fix
release gcc 4.0.1.
R compiled with the gcc 4.0.0 provided on FC4 does pass "make check-
all". My guess is that your locally compiled version does not have the
patches applied by Red Hat.
Martyn
> I used a locally compiled version of GCC v4.0.0 that reports
>
> [EMAIL PROTECTED] R-2.1.1]$ gcc -v
> Using built-in specs.
> Target: i686-pc-linux-gnu
> Configured with: ../gcc-4.0.0/configure --enable-languages=c,c++,f95,java
> Thread model: posix
> gcc version 4.0.0
> [EMAIL PROTECTED] R-2.1.1]$
>
> Kent Holsinger
> [EMAIL PROTECTED]
>
> make[3]: Entering directory `/home/kent/source-arc/R-2.1.1/tests'
> running code in 'eval-etc.R' ... OK
> comparing 'eval-etc.Rout' to './eval-etc.Rout.save' ...2a3,157
> > > eval / parse / deparse / substitute etc
> > >
> > > ##- From: Peter Dalgaard BSA <[EMAIL PROTECTED]>
> > > ##- Subject: Re: source() / eval() bug ??? (PR#96)
> > > ##- Date: 20 Jan 1999 14:56:24 +0100
> > > e1 <- parse(text='c(F=(f <- .3), "Tail area" = 2 * if(f < 1) 30
> else 90)')[[1]]
> > > e1
> > c(F = (f <- 0.3), "Tail area" = 2 * if (f < 1) 30 else 90)
> > > str(eval(e1))
> > Named num [1:2] 0.3 60
> > - attr(*, "names")= chr [1:2] "F" "Tail area"
> > > mode(e1)
> > [1] "call"
> > >
> > > ( e2 <- quote(c(a=1,b=2)) )
> > c(a = 1, b = 2)
> > > names(e2)[2] <- "a b c"
> > > e2
> > c("a b c" = 1, b = 2)
> > > parse(text=deparse(e2))
> > expression(c("a b c" = 1, b = 2))
> > >
> > > ##- From: Peter Dalgaard BSA <[EMAIL PROTECTED]>
> > > ##- Date: 22 Jan 1999 11:47
> > >
> > > ( e3 <- quote(c(F=1,"tail area"=pf(1,1,1))) )
> > c(F = 1, "tail area" = pf(1, 1, 1))
> > > eval(e3)
> > F tail area
> > 1.0 0.5
> > > names(e3)
> > [1] "" "F" "tail area"
> > >
> > > names(e3)[2] <- "Variance ratio"
> > > e3
> > c("Variance ratio" = 1, "tail area" = pf(1, 1, 1))
> > > eval(e3)
> > Variance ratio tail area
> >1.00.5
> > >
> > >
> > > ##- From: Peter Dalgaard BSA <[EMAIL PROTECTED]>
> > > ##- Date: 2 Sep 1999
> > >
> > > ## The first failed in 0.65.0 :
> > > attach(list(x=1))
> > > evalq(dim(x) <- 1,as.environment(2))
> > > dput(get("x", env=as.environment(2)), control="all")
> > structure(1, .Dim = as.integer(1))
> > >
> > > e <- local({x <- 1;environment()})
> > > evalq(dim(x) <- 1,e)
> > > dput(get("x",env=e), control="all")
> > structure(1, .Dim = as.integer(1))
> > >
> > > ### Substitute, Eval, Parse, etc
> > >
> > > ## PR#3 : "..." matching
> > > ## Revised March 7 2001 -pd
> > > A <- function(x, y, ...) {
> > + B <- function(a, b, ...) { match.call() }
> > + B(x+y, ...)
> > + }
> > > (aa <- A(1,2,3))
> > B(a = x + y, b = 3)
> > > all.equal(as.list(aa),
> > + list(as.name("B"), a = expression(x+y)[[1]], b = 3))
> > [1] TRUE
> > > (a2 <- A(1,2, named = 3)) #A(1,2, named = 3)
> > B(a = x + y, named = 3)
> > > all.equal(as.list(a2),
> > + list(as.name("B"), a = expression(x+y)[[1]], named = 3))
> > [1] TRUE
> > >
> > > CC <- function(...) match.call()
> > > DD <- function(...) CC(...)
> > > a3 <- DD(1,2,3)
> > > all.equal(as.list(a3),
> > + list(as.name("CC"), 1, 2, 3))
> > [1] TRUE
> > >
> > > ## More dots issues: March 19 2001 -pd
> > > ## Didn't work up to and including 1.2.2
> > >
> > > f <- function(...) {
> > + val <- match.call(expand.dots=F)$...
> > + x <- val[[1]]
> > + eval.parent(substitute(missing(x)))
> > + }
> > > g <- function(...) h(f(...))
> > > h <- function(...) list(...)
> > > k <- function(...) g(...)
> > > X <- k(a=)
> > > all.equal(X, list(TRUE))
> > [1] TRUE
> > >
> > > ## Bug PR#24
> > > f <- function(x,...) substitute(list(x,...))
> > > deparse(f(a, b)) == "list(a, b)" &&
> > + deparse(f(b, a)) == "list(b, a)" &&
> > + deparse(f(x, y)) == "list(x, y)" &&
> > + deparse(f(y, x)) == "list(y, x)"
> > [1] TRUE
> > >
> > > tt <- function(x) { is.vector(x); deparse(substitute(x)) }
> > > a <- list(b=3); tt(a$b) == "a$b" # tends to break when ...
> > [1] TRUE
> > >
> > >
> > > ## Parser:
> > > 1 <
> > + 2
> > [1] TRUE
> > > 2 <=
> > + 3
> > [1] TRUE
> > > 4 >=
> > + 3
> > [1] TRUE
> > > 3 >
> > + 2
> > [1] TRUE
> > > 2 ==
> > + 2
> > [1] TRUE
> > > ## bug till ...
> > > 1 !=
> > + 3
> > [1] TRUE
> > >
> > > all(NULL == NULL)
> > [1] TRUE
> > >
> > > ## PR #656 (related)
> > > u <- runif(1); length(find(".Random.seed")) == 1
> > [1] TRUE
> > >
> > > MyVaR <<- "val";length(find("MyVaR")) == 1
> > [1]
[Rd] Bartlett test problem (PR#7980)
Full_Name: Leslie Corbett Version: R 2.1.1 OS: Windows 2000 Professional Submission from: (NULL) (142.161.169.185) Every time I try to use the Bartlett.test command, I get a non-responding system. Can someone help? How to reproduce: Easiest way: 1. load Rcmdr; 2. import data set (one where you would do an ANOVA); 3. manage variables in data set (choose at least one variable as a factor). 4. in Rcmdr choose Statistics , variances, Bartlett's test. 5. This is where my computer stops, my laptop stops and collegues' computers stop. (Of course all this can be done directly in the R Gui window, yet the same result occurs). Thanks, Leslie __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bartlett test problem (PR#7980)
what does example(bartlett.test) do for you? Both that and doing that example in Rcmdr work for me. On Thu, 30 Jun 2005 [EMAIL PROTECTED] wrote: > Full_Name: Leslie Corbett > Version: R 2.1.1 > OS: Windows 2000 Professional > Submission from: (NULL) (142.161.169.185) > > > Every time I try to use the Bartlett.test command, I get a non-responding > system. Can someone help? > > How to reproduce: > Easiest way: 1. load Rcmdr; 2. import data set (one where you would do an > ANOVA); 3. manage variables in data set (choose at least one variable as a > factor). 4. in Rcmdr choose Statistics , variances, Bartlett's test. 5. > This > is where my computer stops, my laptop stops and collegues' computers stop. > > (Of course all this can be done directly in the R Gui window, yet the same > result occurs). We really want something here we can reproduce. It might well only happen with your dataset. -- 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
[Rd] upgrading an R installation to next versoin
When I install a new version of R (Windows XP) I have to: 1. copy my rw\etc\Rprofile.site file to the new installation 2. copy the rw\share\texmf files to the tex subfolder of the miktex root directory and then refresh the miktex name database (I have a batch file that does this for me which I run whenever I install a new version of R.) 3. setup the shortcut key using 'properties' on my R desktop icon so that ctrl-alt-R brings up the new rather than the old R. (This one really had me confused once since I did not realize I was still using the old version of R after installing the new one.) 4. reinstall the packages I use or else setup etc\Renviron.site with an R_LIBS to point to include the old library or perhaps one can copy the libraries over being careful not to overwrite new versions of the standard libraries. Many other windows program automatically transfer the settings when you upgrade them. I wonder if the installation process could optionally transfer such settings from an old installation to a new one to make it easier to install R. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] upgrading an R installation to next versoin
On 6/30/2005 8:10 AM, Gabor Grothendieck wrote: > When I install a new version of R (Windows XP) I have to: > > 1. copy my rw\etc\Rprofile.site file to the new installation > > 2. copy the rw\share\texmf files to the tex subfolder of the >miktex root directory and then refresh the miktex name database >(I have a batch file that does this for me which I run >whenever I install a new version of R.) > > 3. setup the shortcut key using 'properties' on my R desktop icon so >that ctrl-alt-R brings up the new rather than the old R. (This one >really had me confused once since I did not realize I was still >using the old version of R after installing the new one.) > > 4. reinstall the packages I use or else setup etc\Renviron.site with >an R_LIBS to point to include the old library or perhaps one can >copy the libraries over being careful not to overwrite new versions >of the standard libraries. > > Many other windows program automatically transfer the settings when > you upgrade them. > > I wonder if the installation process could optionally transfer > such settings from an old installation to a new one to make it > easier to install R. I think a couple of these could be handled by not applying so many modifications to the R installation, do more locally. For example, #1 needn't be copied, you can just use the R_ENVIRON environment variable to point to it and both versions will see it. I'd call #2 a bug in MikTeX, but it's probably one we'll have to work around one of these days. (The bug is dropping support for the environment variable specification of extra include directories.) #3 might be something we could do, but I don't see how. The installer could know what hotkey you used the last time you installed R, but if you changed it in the meantime, how would it know about that? And how would it remove the hotkey from the old shortcut? (A little experimentation suggests that XP is buggy in handling multiple shortcuts with the same hotkey. I'd rather stay away from this.) #4 is another case where you can put your libraries outside R_HOME. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] write.csv suggestion
I've changed this in R-devel so row.names = FALSE is allowed in write.csv[2], but changing col.names, dec, sep and qmethod are not allowed. (col.names is set depending on the setting of row.names.) So far attempts to change col.names, dec, sep and qmethod are silently ignored but I may add some warnings. On Wed, 29 Jun 2005, McGehee, Robert wrote: > I didn't want to use a different separator, I wanted to remove > row.names, as in this example: OK, but the documentation did explicitly say it was a wrapper for row.names = TRUE. >> data(USArrests) >> write.csv(USArrests, file = "~/test.csv", row.names = FALSE, col.names > = TRUE) > Error in if (col.names) d[[2]] else NULL : > missing value where TRUE/FALSE needed > > I only mentioned this suggestion because the above syntax seemed > reasonable (and self-documenting), but by making the options > unchangeable, I received an unhelpful error message. > > After checking the code, I rewrote the line to this: >> write.table(USArrests, file = "~/test.csv", sep = ",", row.names = > FALSE, col.names = TRUE) > > This only seemed suboptimal (to me) because one would have to read the > code to know that the col.names = TRUE option was not being passed along > to write.table (as I expected). > > Best, > Robert > > -Original Message- > From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 29, 2005 4:16 PM > To: McGehee, Robert > Cc: r-devel@stat.math.ethz.ch > Subject: Re: [Rd] write.csv suggestion > > > The help page says > > By default there is no column name for a column of row names. If > 'col.names = NA' and 'row.names = TRUE' a blank column name is > added. This can be used to write CSV files for input to > spreadsheets. 'write.csv' and 'write.csv2' provide convenience > wrappers for doing so. > > and they are set up to disallow the options they set to be changed. > > If you get the option wrong to read a file, you will know soon enough, > but > these are to ensure a suitable CSV file gets written (which will not be > so > immediately apparent). > > Please define `optimal': doing what it was designed for and is > documented > to do is according to you not `optimal'. > > Why would anyone want to use write.csv to write files with something > other > than a comma/semicolon as separator, rather than use write.table? > > > On Wed, 29 Jun 2005, McGehee, Robert wrote: > >> Hello all, >> I had some trouble recently with write.csv because I couldn't change > one >> of the default options. A quick view of the code showed that the >> function was not defined in the most optimal way. >> >> Currently, >> write.csv <- function (..., col.names = NA, sep = ",", qmethod = >> "double") >> write.table(..., col.names = NA, sep = ",", qmethod = "double") >> >> Thus, the options passed along to write.csv are ignored by the > function >> (unless in the ...). >> >> Perhaps a better way to define the function is as such (similar to >> read.csv): >> >> write.csv <- function (..., col.names = NA, sep = ",", qmethod = >> "double") >> write.table(..., col.names = col.names, sep = sep, qmethod = >> qmethod) >> >> The same also applies to write.csv2 >> >> Best, >> Robert >> >> >>> version >> _ >> platform i386-pc-mingw32 >> arch i386 >> os mingw32 >> system i386, mingw32 >> status >> major2 >> minor1.1 >> year 2005 >> month06 >> day 20 >> language R >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > > -- > 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 > > -- 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] upgrading an R installation to next versoin
On 6/30/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 6/30/2005 8:10 AM, Gabor Grothendieck wrote: > > When I install a new version of R (Windows XP) I have to: > > > > 1. copy my rw\etc\Rprofile.site file to the new installation > > > > 2. copy the rw\share\texmf files to the tex subfolder of the > >miktex root directory and then refresh the miktex name database > >(I have a batch file that does this for me which I run > >whenever I install a new version of R.) > > > > 3. setup the shortcut key using 'properties' on my R desktop icon so > >that ctrl-alt-R brings up the new rather than the old R. (This one > >really had me confused once since I did not realize I was still > >using the old version of R after installing the new one.) > > > > 4. reinstall the packages I use or else setup etc\Renviron.site with > >an R_LIBS to point to include the old library or perhaps one can > >copy the libraries over being careful not to overwrite new versions > >of the standard libraries. > > > > Many other windows program automatically transfer the settings when > > you upgrade them. > > > > I wonder if the installation process could optionally transfer > > such settings from an old installation to a new one to make it > > easier to install R. > > I think a couple of these could be handled by not applying so many > modifications to the R installation, do more locally. For example, #1 > needn't be copied, you can just use the R_ENVIRON environment variable > to point to it and both versions will see it. > > I'd call #2 a bug in MikTeX, but it's probably one we'll have to work > around one of these days. (The bug is dropping support for the > environment variable specification of extra include directories.) > > #3 might be something we could do, but I don't see how. The installer > could know what hotkey you used the last time you installed R, but if > you changed it in the meantime, how would it know about that? And how > would it remove the hotkey from the old shortcut? (A little > experimentation suggests that XP is buggy in handling multiple shortcuts > with the same hotkey. I'd rather stay away from this.) > > #4 is another case where you can put your libraries outside R_HOME. > > Duncan Murdoch > I am not too fond of cluttering up my system with environment variables but do have an idea for one one partial measure that might be considered. If the installation kept track of the previous installation by putting the installation path of the previous installation somewhere (probably the registry but maybe a file or an environment variable) then it would be possible for the user to write a batch file or even an R routine that copied information from the previous installation to the current one. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] upgrading an R installation to next versoin
Gabor Grothendieck wrote: > When I install a new version of R (Windows XP) I have to: > > 1. copy my rw\etc\Rprofile.site file to the new installation > > 2. copy the rw\share\texmf files to the tex subfolder of the >miktex root directory and then refresh the miktex name database >(I have a batch file that does this for me which I run >whenever I install a new version of R.) > > 3. setup the shortcut key using 'properties' on my R desktop icon so >that ctrl-alt-R brings up the new rather than the old R. (This one >really had me confused once since I did not realize I was still >using the old version of R after installing the new one.) > > 4. reinstall the packages I use or else setup etc\Renviron.site with >an R_LIBS to point to include the old library or perhaps one can >copy the libraries over being careful not to overwrite new versions >of the standard libraries. > > Many other windows program automatically transfer the settings when > you upgrade them. > > I wonder if the installation process could optionally transfer > such settings from an old installation to a new one to make it > easier to install R. I install each new version of R to a directory ...\R\rcurrent (first renaming the previous rcurrent directory to its "official" name rw). Having set up the shortcut key one time, on subsequent installations I tick the installer's checkbox "Don't create a Start Menu folder". I keep a separate directory ...\R\library for nonstandard packages, with environment variable R_LIBS set to the directory name. My miktex.ini file specifies ...\R\rcurrent\share\texmf as a place to look for input files. That should take care of your points 3, 4, and 2, respectively. Duncan's suggestion of an R_ENVIRON environment variable (which I didn't know about; thanks, Duncan) should take care of point 1. Jon Hosking __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] upgrading an R installation to next versoin
On 6/30/05, J. Hosking <[EMAIL PROTECTED]> wrote: > Gabor Grothendieck wrote: > > When I install a new version of R (Windows XP) I have to: > > > > 1. copy my rw\etc\Rprofile.site file to the new installation > > > > 2. copy the rw\share\texmf files to the tex subfolder of the > >miktex root directory and then refresh the miktex name database > >(I have a batch file that does this for me which I run > >whenever I install a new version of R.) > > > > 3. setup the shortcut key using 'properties' on my R desktop icon so > >that ctrl-alt-R brings up the new rather than the old R. (This one > >really had me confused once since I did not realize I was still > >using the old version of R after installing the new one.) > > > > 4. reinstall the packages I use or else setup etc\Renviron.site with > >an R_LIBS to point to include the old library or perhaps one can > >copy the libraries over being careful not to overwrite new versions > >of the standard libraries. > > > > Many other windows program automatically transfer the settings when > > you upgrade them. > > > > I wonder if the installation process could optionally transfer > > such settings from an old installation to a new one to make it > > easier to install R. > > I install each new version of R to a directory ...\R\rcurrent (first > renaming the previous rcurrent directory to its "official" name rw). That's a good idea -- always using the same folder name for R. > Having set up the shortcut key one time, on subsequent installations > I tick the installer's checkbox "Don't create a Start Menu folder". > > I keep a separate directory ...\R\library for nonstandard packages, > with environment variable R_LIBS set to the directory name. Do you mean your R_LIBS has two components: one to look in ..\R\rcurrent\library and a second to look in ..\R\library? What does it look like exactly? When you do install.packages(whatever) does it install to the ..\R\library rather than ..\R\rcurrent\library ? Also, does updates.packages() work as expected for you? > > My miktex.ini file specifies ...\R\rcurrent\share\texmf as a place > to look for input files. I think its necessary to rebuild the name data base in miktex too initexmf -u although ignoring that step may work as long as the filenames have not changed. I was hoping to continue using a vanilla miktex installation as I do now rather than having a custom miktex.ini file. At any rate my batch file would continue to work even with your setup so I think I should be ok here. > > That should take care of your points 3, 4, and 2, respectively. > Duncan's suggestion of an R_ENVIRON environment variable (which > I didn't know about; thanks, Duncan) should take care of point 1. > > Jon Hosking It occurs to me in reading this that I could keep the *.site files in ..\R and then have my miktex update batch file also copy them to the appropriate etc folder. Thus keeping an R\library folder and running the batch file after each new installation would address 1, 2 and 4 even without using the same name for the rw... folder. This still does not handle the shortcut key which I would have to handle manually or determine if there is a way I could also add that to my batch file. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] upgrading an R installation to next versoin
Gabor Grothendieck wrote: > On 6/30/05, J. Hosking <[EMAIL PROTECTED]> wrote: > ... >> I keep a separate directory ...\R\library for nonstandard packages, >> with environment variable R_LIBS set to the directory name. > > > Do you mean your R_LIBS has two components: one to look in > ..\R\rcurrent\library and a second to look in ..\R\library? What does > it look like exactly? > > When you do install.packages(whatever) does it install to the > ..\R\library rather than ..\R\rcurrent\library ? Also, does > updates.packages() work as expected for you? > My R_LIBS environment variable is just R_LIBS=C:\progs\r\library and within R I see > .libPaths() [1] "C:/progs/r/library" "C:/progs/r/rcurrent/library" i.e., the default library is automatically appended. The help for .libPaths explains this. And yes, install.packages() installs to C:\progs\R\library and update.packages() works as expected. > >>My miktex.ini file specifies ...\R\rcurrent\share\texmf as a place >>to look for input files. > > > I think its necessary to rebuild the name data base in miktex too > initexmf -u > although ignoring that step may work as long as the filenames > have not changed. You are probably correct, though I have not yet encountered any problems that I could attribute to not running initexmf -- no doubt the filenames have not changed recently. > I was hoping to continue using a vanilla > miktex installation as I do now rather than having a custom miktex.ini > file. At any rate my batch file would continue to work even with your setup > so I think I should be ok here. > > >>That should take care of your points 3, 4, and 2, respectively. >>Duncan's suggestion of an R_ENVIRON environment variable (which >>I didn't know about; thanks, Duncan) should take care of point 1. >> >>Jon Hosking > > > It occurs to me in reading this that I could keep the *.site files in > ..\R and then have my miktex update batch file also copy them > to the appropriate etc folder. Thus keeping an R\library folder > and running the batch file after each new installation would > address 1, 2 and 4 even without using the same name for the > rw... folder. This still does not handle the shortcut key which > I would have to handle manually or determine if there is a way > I could also add that to my batch file. > Jon Hosking __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] upgrading an R installation to next versoin
On 6/30/05, J. Hosking <[EMAIL PROTECTED]> wrote: > Gabor Grothendieck wrote: > > On 6/30/05, J. Hosking <[EMAIL PROTECTED]> wrote: > > > ... > > >> I keep a separate directory ...\R\library for nonstandard packages, > >> with environment variable R_LIBS set to the directory name. > > > > > > Do you mean your R_LIBS has two components: one to look in > > ..\R\rcurrent\library and a second to look in ..\R\library? What does > > it look like exactly? > > > > When you do install.packages(whatever) does it install to the > > ..\R\library rather than ..\R\rcurrent\library ? Also, does > > updates.packages() work as expected for you? > > > My R_LIBS environment variable is just > > R_LIBS=C:\progs\r\library > > and within R I see > > > .libPaths() > [1] "C:/progs/r/library" "C:/progs/r/rcurrent/library" > > i.e., the default library is automatically appended. The help for > .libPaths explains this. And yes, install.packages() installs to > C:\progs\R\library and update.packages() works as expected. > > > > >>My miktex.ini file specifies ...\R\rcurrent\share\texmf as a place > >>to look for input files. > > > > > > I think its necessary to rebuild the name data base in miktex too > > initexmf -u > > although ignoring that step may work as long as the filenames > > have not changed. > > You are probably correct, though I have not yet encountered any problems > that I could attribute to not running initexmf -- no doubt the filenames > have not changed recently. > > > I was hoping to continue using a vanilla > > miktex installation as I do now rather than having a custom miktex.ini > > file. At any rate my batch file would continue to work even with your setup > > so I think I should be ok here. > > > > > >>That should take care of your points 3, 4, and 2, respectively. > >>Duncan's suggestion of an R_ENVIRON environment variable (which > >>I didn't know about; thanks, Duncan) should take care of point 1. > >> > >>Jon Hosking > > > > > > It occurs to me in reading this that I could keep the *.site files in > > ..\R and then have my miktex update batch file also copy them > > to the appropriate etc folder. Thus keeping an R\library folder > > and running the batch file after each new installation would > > address 1, 2 and 4 even without using the same name for the > > rw... folder. This still does not handle the shortcut key which > > I would have to handle manually or determine if there is a way > > I could also add that to my batch file. > > > > Jon Hosking > > __ > 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] upgrading an R installation to next versoin
On 6/30/05, J. Hosking <[EMAIL PROTECTED]> wrote: > Gabor Grothendieck wrote: > > On 6/30/05, J. Hosking <[EMAIL PROTECTED]> wrote: > > > ... > > >> I keep a separate directory ...\R\library for nonstandard packages, > >> with environment variable R_LIBS set to the directory name. > > > > > > Do you mean your R_LIBS has two components: one to look in > > ..\R\rcurrent\library and a second to look in ..\R\library? What does > > it look like exactly? > > > > When you do install.packages(whatever) does it install to the > > ..\R\library rather than ..\R\rcurrent\library ? Also, does > > updates.packages() work as expected for you? > > > My R_LIBS environment variable is just > > R_LIBS=C:\progs\r\library > > and within R I see > > > .libPaths() > [1] "C:/progs/r/library" "C:/progs/r/rcurrent/library" > > i.e., the default library is automatically appended. The help for > .libPaths explains this. And yes, install.packages() installs to > C:\progs\R\library and update.packages() works as expected. > > > > >>My miktex.ini file specifies ...\R\rcurrent\share\texmf as a place > >>to look for input files. > > > > > > I think its necessary to rebuild the name data base in miktex too > > initexmf -u > > although ignoring that step may work as long as the filenames > > have not changed. > > You are probably correct, though I have not yet encountered any problems > that I could attribute to not running initexmf -- no doubt the filenames > have not changed recently. > > > I was hoping to continue using a vanilla > > miktex installation as I do now rather than having a custom miktex.ini > > file. At any rate my batch file would continue to work even with your setup > > so I think I should be ok here. > > > > > >>That should take care of your points 3, 4, and 2, respectively. > >>Duncan's suggestion of an R_ENVIRON environment variable (which > >>I didn't know about; thanks, Duncan) should take care of point 1. > >> > >>Jon Hosking > > > > > > It occurs to me in reading this that I could keep the *.site files in > > ..\R and then have my miktex update batch file also copy them > > to the appropriate etc folder. Thus keeping an R\library folder > > and running the batch file after each new installation would > > address 1, 2 and 4 even without using the same name for the > > rw... folder. This still does not handle the shortcut key which > > I would have to handle manually or determine if there is a way > > I could also add that to my batch file. > > Thanks. I think I have it now. I have: - placed my *.site files and library folder in C:\Program Files\R and have set the R_LIBS variable in Renviron.site to point to C:\Program Files\R\library . - I have a batch file which I placed on my desktop which runs rgui.exe from the bin subfolder of the current version of R (using the registry entry to find it). That desktop shortcut has the Alt+Ctrl+R shortcut key associated with it since the batch file itself does not change even when I install new versions of R. - each time I install a new version of R I run a batch file which -- copies the R miktex files to the appropriate miktex folder -- refreshes the miktex file name data base -- copies the *.site files in \Program Files\R to the etc subfolder of the current version of R (using the registry entry to find it) Getting this right is something I have been putting off for some time now since I was very concerned that I screw up my entire R installation but with the advice of the two of you I think I have it now. If any of this functionality could be taken over by the standard R installation procedure that would be great but in any case I think I have a solution that works for me now. Thanks. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] upgrading an R installation to next versoin
Duncan Murdoch stats.uwo.ca> writes: > On 6/30/2005 8:10 AM, Gabor Grothendieck wrote: > > When I install a new version of R (Windows XP) I have to: > > > > 1. copy my rw\etc\Rprofile.site file to the new installation Same here, and I also change one or two things in etc/Rconsole. It would be nice if we could tell to keep 'site-wide' config files outside of $R_HOME (which is always version-number challenged, ie. the path changes four times a year [ assuming two regular releases with one patch releases each, as has been the norm lately ] ). So just as I can set R_LIBS in ~/.Renviron to point to my library directory, would it make sense to add, say, R_ETC ? > > 2. copy the rw\share\texmf files to the tex subfolder of the > >miktex root directory and then refresh the miktex name database > >(I have a batch file that does this for me which I run > >whenever I install a new version of R.) I have no issues with the tetex installation in Cygwin. > > 3. setup the shortcut key using 'properties' on my R desktop icon so > >that ctrl-alt-R brings up the new rather than the old R. (This one > >really had me confused once since I did not realize I was still > >using the old version of R after installing the new one.) I ignore the icons, so I don't care. But I always need to update my softlink farm in /usr/local/bin for R, Rgui, Rterm, Rcmd. > > 4. reinstall the packages I use or else setup etc\Renviron.site with > >an R_LIBS to point to include the old library or perhaps one can > >copy the libraries over being careful not to overwrite new versions > >of the standard libraries. > > > > Many other windows program automatically transfer the settings when > > you upgrade them. > > > > I wonder if the installation process could optionally transfer > > such settings from an old installation to a new one to make it > > easier to install R. As Duncan mentioned, this one is easy to take care of. I use R_LIBS="c:/opt/R/lib" in ~/.Renviron, and that directory is outside of / parallel to where I install the different R versions. One idea I had was if we could ask the installer to (optionally) adopt a scheme different from rw/ and to simple use something like Rcurrent/, with an optional renaming of the previous R installation to Rprevious. That way, Gabor's desktop icon doesn't need to change, nor do my softlinks in /usr/local/bin have to be adapted, as they always point into Rcurrent/bin/ . I am probably overlooking something. But in case I don't, would anybody else see merit in this scheme? Regards, Dirk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
