[Bioc-devel] converting character vector to DNAStringSetList
Hi all, There is a non-exported function in VariantAnnotation called .toDNAStringSetList that converts a vector of comma-separated character strings to a DNAStringSetList. I'd like to use this code in a package I'm working on. Would it make sense to export this from Biostrings? If not, what is the proper way to attribute code if I borrow a few lines from .toDNAStringSetList? thanks, Stephanie ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] converting character vector to DNAStringSetList
why not just use VariantAnnotation:::.toDNAStringSetList() ? On Fri, Apr 19, 2013 at 11:55 AM, Stephanie M. Gogarten sdmor...@u.washington.edu wrote: Hi all, There is a non-exported function in VariantAnnotation called .toDNAStringSetList that converts a vector of comma-separated character strings to a DNAStringSetList. I'd like to use this code in a package I'm working on. Would it make sense to export this from Biostrings? If not, what is the proper way to attribute code if I borrow a few lines from .toDNAStringSetList? thanks, Stephanie __**_ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/**listinfo/bioc-develhttps://stat.ethz.ch/mailman/listinfo/bioc-devel -- *A model is a lie that helps you see the truth.* * * Howard Skipperhttp://cancerres.aacrjournals.org/content/31/9/1173.full.pdf [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] converting character vector to DNAStringSetList
Hi Stephanie, On 04/19/2013 11:55 AM, Stephanie M. Gogarten wrote: Hi all, There is a non-exported function in VariantAnnotation called .toDNAStringSetList that converts a vector of comma-separated character strings to a DNAStringSetList. I'd like to use this code in a package I'm working on. Would it make sense to export this from Biostrings? If not, what is the proper way to attribute code if I borrow a few lines from .toDNAStringSetList? This should be a 1-liner but the 1-liner fails at the moment because the DNAStringSetList() constructor doesn't work on a list: comma_sep_strings - c(AA,TT, ACGT, , TT,A,,TAG) DNAStringSetList(strsplit(comma_sep_strings, ,, fixed=TRUE)) Error in strsplit(comma_sep_strings, ,) : non-character argument Of course this should work (and it will work tomorrow after you run biocLite()). In the mean time the workaround is to use do.call(): do.call(DNAStringSetList, strsplit(comma_sep_strings, ,, fixed=TRUE)) DNAStringSetList of length 4 [[1]] AA TT [[2]] ACGT [[3]] A DNAStringSet instance of length 0 [[4]] TT A TAG Cheers, H. PS: Calling strsplit() with 'fixed=TRUE' makes it about 4x faster :-) thanks, Stephanie ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] DESeq2 and miscTranformsation(s)
Greetings, I'm kicking tires on the new DESeq2 package -- very nicely done, btw, thanks!. I have a quick question about the use of the variance and rlog transformations. It seems that both functions prefer to receive a DESeqDataSet with a design set to formula(~ 1). I say prefer because while rlogTransformation will error-out when the incoming dds has a different formula, the varianceStablizingTransform walks through it. If this in fact is the case, would it make sense to simply ensure this to be true by specifically hammering the design() of the dds to be as such from within the function itself? Unless I am missing something (if so, feel free to point it out), it seems like it would make the end-user's life easier w/o sacrificing much (anything) as the user wouldn't be forced to make a copy of the dds to pass to the function before it is called (and perhaps firing off a warning() when the incoming dds need to be changed as such). Thanks again, -steve -- Steve Lianoglou Computational Biologist Department of Bioinformatics and Computational Biology Genentech [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] converting character vector to DNAStringSetList
Thanks, Herve! To answer Tim's question (though it has become irrelevant after Herve's solution): because I'd rather not add VariantAnnotation to my dependency tree for only a couple of lines of code. It also seemed like the sort of thing that should be possible with a DNAStringSetList constructor, so I'm glad it will be starting tomorrow. Stephanie On 4/19/13 12:35 PM, Hervé Pagès wrote: Hi Stephanie, On 04/19/2013 11:55 AM, Stephanie M. Gogarten wrote: Hi all, There is a non-exported function in VariantAnnotation called .toDNAStringSetList that converts a vector of comma-separated character strings to a DNAStringSetList. I'd like to use this code in a package I'm working on. Would it make sense to export this from Biostrings? If not, what is the proper way to attribute code if I borrow a few lines from .toDNAStringSetList? This should be a 1-liner but the 1-liner fails at the moment because the DNAStringSetList() constructor doesn't work on a list: comma_sep_strings - c(AA,TT, ACGT, , TT,A,,TAG) DNAStringSetList(strsplit(comma_sep_strings, ,, fixed=TRUE)) Error in strsplit(comma_sep_strings, ,) : non-character argument Of course this should work (and it will work tomorrow after you run biocLite()). In the mean time the workaround is to use do.call(): do.call(DNAStringSetList, strsplit(comma_sep_strings, ,, fixed=TRUE)) DNAStringSetList of length 4 [[1]] AA TT [[2]] ACGT [[3]] A DNAStringSet instance of length 0 [[4]] TT A TAG Cheers, H. PS: Calling strsplit() with 'fixed=TRUE' makes it about 4x faster :-) thanks, Stephanie ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] how to control the environment of a formula
On 13-04-19 8:41 AM, Therneau, Terry M., Ph.D. wrote:
I went through the same problem and discovery process 2 years ago with the
survival package. With pspline() terms the return object from coxph includes
a simple 6 line function for enhanced printout, which by default carried along
another 30 irrelevant things some of which were huge.
I personally think that setting environment(f) - .Globalenv is the clearest
and most simple solution.
Note that R does not save the environment of functions defined at the top level; the
prior line says to treat your function as one of those. It works very well
as long as your function is an actual function, i.e. It depends only on its input
arguments.
\begin {opinion}
S started out as a pure functional language. That is, a function depends
ONLY on its arguments. Many of the strengths of S/R flow directly from the
simplicity and rigor that this gives.
There is an adage in programming, going back to at least the earliest Fortran
compilers, that all successful languages have a way to break their own rules;
and S indeed had some hidden workarounds. Formalizing these non-functional
back doors as R has done with environments is a good thing.
However, the back doors should be used only with extreme reluctance. I cringe at each
new how to be sneaky discussion on the mailing lists. The 'solution' is
rarely worth the long term price.
\end{opinion}
Hmmm, it seems to me that your first paragraph contradicts your opinion.
If you set the environment of a formula to .GlobalEnv then suddenly
the way that formula acts depends on all sorts of things that weren't
there when it was created.
Attaching the formula at the time of creation of a formula means that
the names within it refer to data that is currently in scope. That's
generally a good thing. It means that code will act the same when you
run it at the top level or in a function.
For example, consider this:
f - function() {
x - 1:10
x2 - x^2
y - rnorm(10, mean=x2)
formula - y ~ x + x2
formula
}
fit - lm(f())
update(fit, . ~ . - x)
This code works fine, all because the formula keeps the environment
where it was created. If I modify it like this:
f - function() {
x - 1:10
x2 - x^2
y - rnorm(10, mean=x2)
formula - y ~ x + x2
environment(formula) - .GlobalEnv
formula
}
fit - lm(f())
update(fit, . ~ . - x)
then I really have no idea what it will produce, because it depends on
global variables y, x and x2, not the local ones created in the
function. If I'm lucky, I'll get an object not found error; if I'm
not lucky, it'll just go find some other variables and use those.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Linux distribution with gcc 4.8 and AddressSanitizer ?
On 18.04.2013 18:05, José Matos wrote: On Thursday 18 April 2013 17:38:06 Thomas Petzoldt wrote: Dear R developers, I've got an information from Prof. Ripley regarding a bug found with AdressSanitizer in one of our packages. It is now fixed, thank you for this information. Now, I would like to run AddressSanitizer myself before submitting the patched package to CRAN. Is there a recommendation of a suitable Linux distribution with gcc 4.8, ideally an ISO image or (even better) a virtual appliance for VMware or VirtalBox? My Debian Wheezy machines have only 4.7.2. Thank you Thomas Petzoldt I am not sure about all the requisites above (regarding the virtual appliances although I know that they are available) but Fedora 19 (Alpha) that will be released today has gcc 4.8. Even although it has the Alpha moniker, and the corresponding stage, it is relatively stable and thus suitable for your requirements. Regards, Thank you for the hint to use Fedora 19 Alpha. I have it now running, together with R 3.0.0. and gcc 4.8.0 20120412 (Red Hat 4.8.0-2). Compilation and installation of packages (without ASAN) workes out of the box. Then I've set: export PKG_CFLAGS=-fsanitize=address -fno-omit-frame-pointer ... and compilation runs and I see that gcc uses the flags, but package installation still fails: ** testing if installed package can be loaded Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared object '/home/user/packages/deSolve.Rcheck/deSolve/libs/deSolve.so': /home/user/packages/deSolve.Rcheck/deSolve/libs/deSolve.so: undefined symbol: __asan_report_load8 Error: loading failed Execution halted ERROR: loading failed I see that the address sanitizer cannot work yet (__asan_report_load8) and that I missed something important, but what? Thomas Petzoldt -- Thomas Petzoldt Technische Universitaet Dresden Faculty of Environmental Sciences Institute of Hydrobiology 01062 Dresden, Germany E-Mail: thomas.petzo...@tu-dresden.de http://tu-dresden.de/Members/thomas.petzoldt __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to control the environment of a formula
Duncan,
I stand by all my comments. Well behaved function -- those that look
only at their input arguments -- do just fine with a simple env.
Now as to formulas --- the part of R that has most aggressively messed
with normal evaluation rules. It is quite possible that there is/was no
other way to implement their functionality set, so I'm not throwing rocks
at that. However, as soon as they enter the scene the consequences
multiply like rabbits and I feel like I've fallen into a hall of mirrors.
Nothing else has caused me as much ongoing confusion and wonderment in the
survival package.
As soon as you introduced them all my arguments are irrelevant.
Terry T
On 4/19/13 9:05 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote:
On 13-04-19 8:41 AM, Therneau, Terry M., Ph.D. wrote:
I went through the same problem and discovery process 2 years ago
with the survival package. With pspline() terms the return object from
coxph includes a simple 6 line function for enhanced printout, which by
default carried along another 30 irrelevant things some of which were
huge.
I personally think that setting environment(f) - .Globalenv is the
clearest and most simple solution.
Note that R does not save the environment of functions defined at the
top level; the prior line says to treat your function as one of those.
It works very well as long as your function is an actual function,
i.e. It depends only on its input arguments.
\begin {opinion}
S started out as a pure functional language. That is, a function
depends ONLY on its arguments. Many of the strengths of S/R flow
directly from the simplicity and rigor that this gives.
There is an adage in programming, going back to at least the earliest
Fortran compilers, that all successful languages have a way to break
their own rules; and S indeed had some hidden workarounds. Formalizing
these non-functional back doors as R has done with environments is a
good thing.
However, the back doors should be used only with extreme reluctance. I
cringe at each new how to be sneaky discussion on the mailing lists.
The 'solution' is rarely worth the long term price.
\end{opinion}
Hmmm, it seems to me that your first paragraph contradicts your opinion.
If you set the environment of a formula to .GlobalEnv then suddenly
the way that formula acts depends on all sorts of things that weren't
there when it was created.
Attaching the formula at the time of creation of a formula means that
the names within it refer to data that is currently in scope. That's
generally a good thing. It means that code will act the same when you
run it at the top level or in a function.
For example, consider this:
f - function() {
x - 1:10
x2 - x^2
y - rnorm(10, mean=x2)
formula - y ~ x + x2
formula
}
fit - lm(f())
update(fit, . ~ . - x)
This code works fine, all because the formula keeps the environment
where it was created. If I modify it like this:
f - function() {
x - 1:10
x2 - x^2
y - rnorm(10, mean=x2)
formula - y ~ x + x2
environment(formula) - .GlobalEnv
formula
}
fit - lm(f())
update(fit, . ~ . - x)
then I really have no idea what it will produce, because it depends on
global variables y, x and x2, not the local ones created in the
function. If I'm lucky, I'll get an object not found error; if I'm
not lucky, it'll just go find some other variables and use those.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Linux distribution with gcc 4.8 and AddressSanitizer ?
On 19/04/2013 18:22, Thomas Petzoldt wrote: On 18.04.2013 18:05, José Matos wrote: On Thursday 18 April 2013 17:38:06 Thomas Petzoldt wrote: Dear R developers, I've got an information from Prof. Ripley regarding a bug found with AdressSanitizer in one of our packages. It is now fixed, thank you for this information. Now, I would like to run AddressSanitizer myself before submitting the patched package to CRAN. Is there a recommendation of a suitable Linux distribution with gcc 4.8, ideally an ISO image or (even better) a virtual appliance for VMware or VirtalBox? My Debian Wheezy machines have only 4.7.2. Thank you Thomas Petzoldt I am not sure about all the requisites above (regarding the virtual appliances although I know that they are available) but Fedora 19 (Alpha) that will be released today has gcc 4.8. Even although it has the Alpha moniker, and the corresponding stage, it is relatively stable and thus suitable for your requirements. Regards, Thank you for the hint to use Fedora 19 Alpha. I have it now running, together with R 3.0.0. and gcc 4.8.0 20120412 (Red Hat 4.8.0-2). Compilation and installation of packages (without ASAN) workes out of the box. Then I've set: export PKG_CFLAGS=-fsanitize=address -fno-omit-frame-pointer ... and compilation runs and I see that gcc uses the flags, but package installation still fails: ** testing if installed package can be loaded Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared object '/home/user/packages/deSolve.Rcheck/deSolve/libs/deSolve.so': /home/user/packages/deSolve.Rcheck/deSolve/libs/deSolve.so: undefined symbol: __asan_report_load8 Error: loading failed Execution halted ERROR: loading failed I see that the address sanitizer cannot work yet (__asan_report_load8) and that I missed something important, but what? The manual said 'It requires code to have been compiled and linked with -fsanitize=address' I don't see that you linked with it ... I have (in ~/.R/Makevars) CC=gcc -std=gnu99 -fsanitize=address -fno-omit-frame-pointer and similar for F77, CXX I guess PKG_LIBS=-fsanitize=address might work. ' Thomas Petzoldt -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to control the environment of a formula
hmm. I have tested a bit more, and found this perhaps more difficult
solve situation. even though I delete x, since x is part of the output
of the formula, the size of the object is twice as much as it should be:
test - function(x){
x - rnorm(100)
out - list(x=x)
rm(x)
out$f - as.formula(a~b)
out
}
v - test(1)
x - rnorm(100)
save(v,file=~/tmp/v.rda)
save(x,file=~/tmp/x.rda)
system(ls -lah ~/tmp/*.rda)
-rw-rw-r-- 1 tag tag 15M Apr 19 20:52 /home/tag/tmp/v.rda
-rw-rw-r-- 1 tag tag 7,4M Apr 19 20:52 /home/tag/tmp/x.rda
can you solve this as well?
thanks!
thomas
Duncan Murdoch murdoch.dun...@gmail.com writes:
On 13-04-18 11:39 AM, Thomas Alexander Gerds wrote:
Dear Duncan
thank you for taking the time to answer my questions! It will be
quite some work to delete all the objects generated inside the
function ... but if there is no other way to avoid a large
environment then this is what I will do.
It's not really that hard. Use names - ls() in the function to get a
list of all of them; remove the names of variables that might be
needed in the formula (and the name of the formula itself); then use
rm(list=names) to delete everything else just before returning it.
Duncan Murdoch
--
Thomas A. Gerds -- Assoc. Prof. Department of Biostatistics Copenhagen
University of Copenhagen, Oester Farimagsgade 5, 1014 Copenhagen, Denmark
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Linux distribution with gcc 4.8 and AddressSanitizer ?
On Apr 19, 2013, at 2:19 PM, Prof Brian Ripley wrote: On 19/04/2013 18:22, Thomas Petzoldt wrote: On 18.04.2013 18:05, José Matos wrote: On Thursday 18 April 2013 17:38:06 Thomas Petzoldt wrote: Dear R developers, I've got an information from Prof. Ripley regarding a bug found with AdressSanitizer in one of our packages. It is now fixed, thank you for this information. Now, I would like to run AddressSanitizer myself before submitting the patched package to CRAN. Is there a recommendation of a suitable Linux distribution with gcc 4.8, ideally an ISO image or (even better) a virtual appliance for VMware or VirtalBox? My Debian Wheezy machines have only 4.7.2. Thank you Thomas Petzoldt I am not sure about all the requisites above (regarding the virtual appliances although I know that they are available) but Fedora 19 (Alpha) that will be released today has gcc 4.8. Even although it has the Alpha moniker, and the corresponding stage, it is relatively stable and thus suitable for your requirements. Regards, Thank you for the hint to use Fedora 19 Alpha. I have it now running, together with R 3.0.0. and gcc 4.8.0 20120412 (Red Hat 4.8.0-2). Compilation and installation of packages (without ASAN) workes out of the box. Then I've set: export PKG_CFLAGS=-fsanitize=address -fno-omit-frame-pointer ... and compilation runs and I see that gcc uses the flags, but package installation still fails: ** testing if installed package can be loaded Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared object '/home/user/packages/deSolve.Rcheck/deSolve/libs/deSolve.so': /home/user/packages/deSolve.Rcheck/deSolve/libs/deSolve.so: undefined symbol: __asan_report_load8 Error: loading failed Execution halted ERROR: loading failed I see that the address sanitizer cannot work yet (__asan_report_load8) and that I missed something important, but what? The manual said 'It requires code to have been compiled and linked with -fsanitize=address' I don't see that you linked with it ... I have (in ~/.R/Makevars) CC=gcc -std=gnu99 -fsanitize=address -fno-omit-frame-pointer and similar for F77, CXX I guess PKG_LIBS=-fsanitize=address might work. Just a data point: that didn't work for me on OS X using clang. I had to compile R with clang + asan, because clang seems to embed the run-time only in executables, not shared objects and when linking the .so to the runtime manually it broke. But building R with clang 3.3 from trunk and gfortran from CRAN did work with some tweaking - this is what I used: CC=/opt/clang/bin/clang CXX=/opt/clang/bin/clang++ 'CFLAGS=-fsanitize=address -O1 -fno-omit-frame-pointer -g -Wall' 'CXXFLAGS=-fsanitize=address -O1 -fno-omit-frame-pointer -g -Wall' 'LDFLAGS=-fsanitize=address -L/usr/local/lib -lgfortran' 'FC=gfortran-4.2 -m64' 'F77=gfortran-4.2 -m64' Another data point is that R segfaulted on start for me when compiled with gcc 4.8.0-3 from Debian experimental (amd64) with asan enabled (and I gave up when I couldn't get gfortran-4.8 to mix with clang-3.2 to try that route). Those are all very fragile tools, so it's not unexpected, but essentially it seems that it's not trivial to get a working set of tools... Cheers, Simon ' Thomas Petzoldt -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
Having finally found some free time, I was going to use it to update a bunch of R packages from 2.15 to 3.0. I am running Windows 7, 64-bit professional. This is on a brand-new laptop using vanilla settings when installing the operating system. Problem 1: I installed R3.0 to the default location (C:\Program FIles\R\R-3.0.0). The first thing I tried to do was install BioConductor. This failed (permission denied). Thinking that this might be a BioConductor problem, I then tried to install a (semirandom) package from CRAN. This also failed. In both cases, when using the GUI, the error message is almost incomprehensible. You get a pop-up window that *only* says Do you want to use a private library instead? Since this wasn't what I wanted to do I said no. Only after the pop-up closes does the command window print the error message telling me that permission was denied for R to write to its own library location. Dumb Fix to Problem 1: So, I uninstalled R and then reinstalled to a nonstandard location (C:\R\R-3.0.0). Now I can successfully install packages from CRAN and BioConductor (hooray!). But I run directly into: Problem 2: Emacs Speaks Statistics (ESS) can no longer find the R binary. When R was installed in the default location, ESS worked. When R 2.15 (or earlier) was installed in the same nonstandard location, I could get ESS to find the R binaries by including (setq ess-directory-containing-r C:) in my .emacs file, but that no longer works. Dumb Fix to Problem 2: Hack into ess-site.el and put the complete, explicit path to the correct binary into (setq-default inferior-R-program-name 'FULLPATHHERE) which will break as soon as I upgrade R (assuming I am foolish enough to ever do that again). Now I am ready to rebuild my R packages. I have this nice perl script that goes through the following procedure: 1. Set the path to include the correct Rtools directory. (For reasons that Gabor Grothendieck has pointed out previously, this is not a permanent part of the path since doing so would override some built-in Windows commands.) 2. Build a source tarball via R CMD build $package 3. Build a Windows binary version (as a zip file) via R CMD INSTALL --build $tarball 4. Check the package via R CMD check --as-cran $tarball 5. Install the package via R CMD INSTALL $tarball Problem 3: Step 3 fails, withe the error message Running 'zip' failed. Dumb Fix to Problem 3: Install the GnbuWin32 version of zip, and make sure that its location is earlier in ter path than the version that comes with Rtools. Problem 4: Step 4 fails when running the test scripts that accompany the package. The error message is the semicryptic cannot open file 'c:\Users\krc\AppData\Local\Temp\Rtmp' Permission denied Dumb Fix to Problem 4: Write this email message and hope someone with even more patience than I have has already found a better way to get all this stuff to work. Tired of spinning my wheels, Kevin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On 13-04-19 5:37 PM, Kevin Coombes wrote: Having finally found some free time, I was going to use it to update a bunch of R packages from 2.15 to 3.0. I am running Windows 7, 64-bit professional. This is on a brand-new laptop using vanilla settings when installing the operating system. Problem 1: I installed R3.0 to the default location (C:\Program FIles\R\R-3.0.0). The first thing I tried to do was install BioConductor. This failed (permission denied). Thinking that this might be a BioConductor problem, I then tried to install a (semirandom) package from CRAN. This also failed. In both cases, when using the GUI, the error message is almost incomprehensible. You get a pop-up window that *only* says Do you want to use a private library instead? Since this wasn't what I wanted to do I said no. Only after the pop-up closes does the command window print the error message telling me that permission was denied for R to write to its own library location. This is a standard Windows problem, to stop viruses from modifying installed programs. The standard Windows solution to it is to run the installer as an administrator, taking personal responsibility for installing the package/virus. Since this is a laptop, you could probably do this, but it's possible that you are not the administrator on your system. If that's the case, you should ask your administrator to do the install. Dumb Fix to Problem 1: So, I uninstalled R and then reinstalled to a nonstandard location (C:\R\R-3.0.0). Now I can successfully install packages from CRAN and BioConductor (hooray!). But I run directly into: That's another solution, and a third solution is to accept the offer R made, to install your packages somewhere where you as a user have write permission. Problem 2: Emacs Speaks Statistics (ESS) can no longer find the R binary. When R was installed in the default location, ESS worked. When R 2.15 (or earlier) was installed in the same nonstandard location, I could get ESS to find the R binaries by including (setq ess-directory-containing-r C:) in my .emacs file, but that no longer works. Dumb Fix to Problem 2: Hack into ess-site.el and put the complete, explicit path to the correct binary into (setq-default inferior-R-program-name 'FULLPATHHERE) which will break as soon as I upgrade R (assuming I am foolish enough to ever do that again). I can't help you with ESS. Now I am ready to rebuild my R packages. I have this nice perl script that goes through the following procedure: 1. Set the path to include the correct Rtools directory. (For reasons that Gabor Grothendieck has pointed out previously, this is not a permanent part of the path since doing so would override some built-in Windows commands.) Just curious: how often do you use the Windows find command? We have put instructions in place for people to run the install process with a renamed Rtools find command (which I think is the only conflict). The issue is that more users who want to use the command line commands are familiar with the Unix variant (which came first, by the way) than the Windows one, so renaming the Rtools one would cause trouble for more people. 2. Build a source tarball via R CMD build $package 3. Build a Windows binary version (as a zip file) via R CMD INSTALL --build $tarball 4. Check the package via R CMD check --as-cran $tarball 5. Install the package via R CMD INSTALL $tarball Problem 3: Step 3 fails, withe the error message Running 'zip' failed. Dumb Fix to Problem 3: Install the GnbuWin32 version of zip, and make sure that its location is earlier in ter path than the version that comes with Rtools. I have no idea about this one. Problem 4: Step 4 fails when running the test scripts that accompany the package. The error message is the semicryptic cannot open file 'c:\Users\krc\AppData\Local\Temp\Rtmp' Permission denied That's Windows permissions biting you again. Run as administrator. Duncan Murdoch Dumb Fix to Problem 4: Write this email message and hope someone with even more patience than I have has already found a better way to get all this stuff to work. Tired of spinning my wheels, Kevin __ 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] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On Fri, Apr 19, 2013 at 8:47 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-04-19 5:37 PM, Kevin Coombes wrote: Having finally found some free time, I was going to use it to update a bunch of R packages from 2.15 to 3.0. I am running Windows 7, 64-bit professional. This is on a brand-new laptop using vanilla settings when installing the operating system. Problem 1: I installed R3.0 to the default location (C:\Program FIles\R\R-3.0.0). The first thing I tried to do was install BioConductor. This failed (permission denied). Thinking that this might be a BioConductor problem, I then tried to install a (semirandom) package from CRAN. This also failed. In both cases, when using the GUI, the error message is almost incomprehensible. You get a pop-up window that *only* says Do you want to use a private library instead? Since this wasn't what I wanted to do I said no. Only after the pop-up closes does the command window print the error message telling me that permission was denied for R to write to its own library location. This is a standard Windows problem, to stop viruses from modifying installed programs. The standard Windows solution to it is to run the installer as an administrator, taking personal responsibility for installing the package/virus. Since this is a laptop, you could probably do this, but it's possible that you are not the administrator on your system. If that's the case, you should ask your administrator to do the install. Dumb Fix to Problem 1: So, I uninstalled R and then reinstalled to a nonstandard location (C:\R\R-3.0.0). Now I can successfully install packages from CRAN and BioConductor (hooray!). But I run directly into: That's another solution, and a third solution is to accept the offer R made, to install your packages somewhere where you as a user have write permission. Problem 2: Emacs Speaks Statistics (ESS) can no longer find the R binary. When R was installed in the default location, ESS worked. When R 2.15 (or earlier) was installed in the same nonstandard location, I could get ESS to find the R binaries by including (setq ess-directory-containing-r C:) in my .emacs file, but that no longer works. Dumb Fix to Problem 2: Hack into ess-site.el and put the complete, explicit path to the correct binary into (setq-default inferior-R-program-name 'FULLPATHHERE) which will break as soon as I upgrade R (assuming I am foolish enough to ever do that again). I can't help you with ESS. Now I am ready to rebuild my R packages. I have this nice perl script that goes through the following procedure: 1. Set the path to include the correct Rtools directory. (For reasons that Gabor Grothendieck has pointed out previously, this is not a permanent part of the path since doing so would override some built-in Windows commands.) Just curious: how often do you use the Windows find command? We have put instructions in place for people to run the install process with a renamed Rtools find command (which I think is the only conflict). The issue is that more users who want to use the command line commands are familiar with the Unix variant (which came first, by the way) than the Windows one, so renaming the Rtools one would cause trouble for more people. Its not just find - its also sort. And really R has no business clobbering built in Windows commands. This is just wrong and really causes anyone who does any significant amount of Windows batch programming (or uses batch programs of any complexity) endless problems. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
