Re: [Rd] Multivariate time series in R 3 vs R 2
On Wed, Oct 23, 2013 at 2:56 PM, Андрей Парамонов cmr.p...@gmail.com wrote: Hello! Recently I got report that my package mar1s doesn't pass checks any more on R 3.0.2. I started to investigate and found the following difference in multivariate time series handling in R 3.0.2 compared to R 2 (I've checked on 2.14.0). Suppose I wish to calculate seasonal component for time series. In case of multivariate time series, I wish to process each column independently. Let f be a simple (trivial) model of seasonal component: f - function(x) return(ts(rep(0, length(x)), start = 0, frequency = frequency(x))) In previous versions of R, I used the following compact and efficient expression to calculate seasonal component: y - do.call(cbind, lapply(x, f)) It worked equally good for univariate and multivariate time series: R.Version()$version.string [1] R version 2.14.0 (2011-10-31) t - ts(1:10, start = 100, frequency = 10) x - t y - do.call(cbind, lapply(x, f)) y Time Series: Start = c(0, 1) End = c(0, 10) Frequency = 10 [1] 0 0 0 0 0 0 0 0 0 0 x - cbind(t, t) y - do.call(cbind, lapply(x, f)) y Time Series: Start = c(0, 1) End = c(0, 10) Frequency = 10 t t 0.0 0 0 0.1 0 0 0.2 0 0 0.3 0 0 0.4 0 0 0.5 0 0 0.6 0 0 0.7 0 0 0.8 0 0 0.9 0 0 But in version 3, I get some frustrating results: R.Version()$version.string [1] R version 3.0.2 (2013-09-25) t - ts(1:10, start = 100, frequency = 10) x - t y - do.call(cbind, lapply(x, f)) y Time Series: Start = 0 End = 0 Frequency = 1 structure(0, .Tsp = c(0, 0, 1), class = ts) 0 0 structure(0, .Tsp = c(0, 0, 1), class = ts) 0 0 structure(0, .Tsp = c(0, 0, 1), class = ts) 0 0 structure(0, .Tsp = c(0, 0, 1), class = ts) 0 0 structure(0, .Tsp = c(0, 0, 1), class = ts) 0 0 structure(0, .Tsp = c(0, 0, 1), class = ts) 0 0 structure(0, .Tsp = c(0, 0, 1), class = ts) 0 0 structure(0, .Tsp = c(0, 0, 1), class = ts) 0 0 structure(0, .Tsp = c(0, 0, 1), class = ts) 0 0 structure(0, .Tsp = c(0, 0, 1), class = ts) 0 0 I get the same results in R-2.14.0 and R-3.02. They both give the result shown above with the structures in the output. I used R version 2.14.0 (2011-10-31). Try starting a clean session in R 2.14.0 using: R --vanilla and try it again. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about selective importing of package functions...
On Sun, Oct 20, 2013 at 4:49 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-10-20 4:43 PM, Jonathan Greenberg wrote: I'm working on an update for my CRAN package spatial.tools and I noticed a new warning when running R CMD CHECK --as-cran: * checking CRAN incoming feasibility ... NOTE Maintainer: 'Jonathan Asher Greenberg spatial-to...@estarcion.net' Depends: includes the non-default packages: 'sp' 'raster' 'rgdal' 'mmap' 'abind' 'parallel' 'foreach' 'doParallel' 'rgeos' Adding so many packages to the search path is excessive and importing selectively is preferable. Is this a warning that would need to be fixed pre-CRAN (not really sure how, since I need functions from all of those packages)? Is there a way to import only a single function from a package, if that function is a dependency? You really want to use imports. Those are defined in the NAMESPACE file; you can import everything from a package if you want, but the best style is in fact to just import exactly what you need. This is more robust than using Depends, and it doesn't add so much to the user's search path, so it's less likely to break something else (e.g. by putting a package on the path that masks some function the user already had there.) That may answer the specific case of the poster but how does one handle the case where one wants the user to be able to access the functions in the dependent package. For example, sqldf depends on gsubfn which provides fn which is used with sqldf to perform substitutions in the SQL string. library(sqldf) tt - 3 fn$sqldf(select * from BOD where Time $tt) I don't want to ask the user to tediously issue a library(gsubfn) too since fn is frequently needed and for literally years this has not been necessary. Also I don't want to duplicate fn's code in sqldf since that makes the whole thing less modular -- it would imply having to change fn in two places if anything in fn changed. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
If ::: is disallowed then its likely that package developers will need to export more functions to satisfy the consumers of those otherwise hidden functions but if more functions are exported then there will be a greater likelihood of conflicts among packages. The problem seems to be that there are potentially three sorts of functions here: 1. a function is hidden 2. a function is accessible via ::: but is not on the search path 3. a function is on the search path The problem arises in attempting to force fit these three concepts into only two categories either by removing the first category (as was done previously) or by removing the second category (which seems to be the new approach). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On Thu, Aug 22, 2013 at 6:41 PM, Uwe Ligges lig...@statistik.tu-dortmund.de wrote: On 23.08.2013 00:36, Brian Lee Yung Rowe wrote: You raise an interesting point that I've mulled over a bit: namespace collisions. How many of these issues would go away if there were a better mechanism for managing namespaces? eg in other languages you can control which objects/modules you wish to import from a library. Under this regime I think package developers would be less concerned about exposing functions that otherwise would be private. Exactly, the corresponding NAMESPACE directive is importFrom() and it should be used. On Aug 22, 2013, at 6:27 PM, Gabor Grothendieck ggrothendi...@gmail.com wrote: If ::: is disallowed then its likely that package developers will need to export more functions to satisfy the consumers of those otherwise hidden functions but if more functions are exported then there will be a greater likelihood of conflicts among packages. The problem seems to be that there are potentially three sorts of functions here: 1. a function is hidden 2. a function is accessible via ::: but is not on the search path 3. a function is on the search path Not entirely right: If the package or only parts of it are imported via importFrom by another package, the package is not loaded, hence not on the search path. OK but it is still true that under the new rules to use importFrom(B, f) in package A that f must be exported by B. That implies that f could cause a conflict when B is placed on the search path via library(B) by some other package (package C) or by the user. f is either exported by B or not. If f is exported by B then f will be placed on the search path whenever B is placed on the search path and if f is not exported then A can't import it. That is there is no way for B to declare a function to be importable by another package without having that function also placed on the search path whenever B is loaded by a library(B)l or a Depends: B from another package. on the search path -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On Thu, Aug 22, 2013 at 7:57 PM, Gabriel Becker gmbec...@ucdavis.edu wrote: My understanding is that lookup happens in the imports before moving on to the search path, so if I understand you correctly I don't think that is an issue. If A also *exported* f, that would be a problem... A can only import f from B if f has been exported from B so while its not a problem for A, whenever anyone issues a library(B) f will be visible on the search path -- the problem of potential conflicts with f remains. B really only exported f so that A could import it but a side effect of that is that anyone who puts B on the search path makes f visible. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Extending suggestion for stopifnot
On Tue, Aug 20, 2013 at 6:00 PM, ivo welch ivo.we...@gmail.com wrote: character string at the end of an existing function, stopifnot(). (2) I think estrings (that behave like characters but are interpolated before printout) are useful in the same way perl interpolated strings are useful. The gsubfn package has string interpolation somewhat like perl. Preface a function call with fn$ and then back ticks and $ are interpolated. library(gsubfn) fn$identity(pi is $pi) library(sqldf) fn$sqldf(select * from BOD where Time $pi) fn$stop(class is `class(pi)`) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Redirect system2 stdout to a file on windows
On Sun, Jul 14, 2013 at 1:18 PM, Jeroen Ooms jeroen.o...@stat.ucla.edu wrote: According to the manual, the `stdout` argument of the `system2` function can redirect output to a file. This seems to work on unix, however I can't get it to work on windows. The toy example below, no `out.txt` or `err.txt` files are created. I tried sending it to an existing file, or expand the full file path, but with no success: setwd(tempdir()) system2(whoami, stdout=out.txt, stderr=err.txt) file.exists(out.txt) Am I doing something wrong or is this not supported on windows? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Try: out.txt - normalizePath(./out.txt, mustWork = FALSE) -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Redirect system2 stdout to a file on windows
On Sun, Jul 14, 2013 at 5:20 PM, Jeroen Ooms jeroen.o...@stat.ucla.edu wrote: On Sun, Jul 14, 2013 at 10:24 PM, Gabor Grothendieck wrote: Try: out.txt - normalizePath(./out.txt, mustWork = FALSE) Doesn't work either, neither on Win7 nor WinXP. sessionInfo() R version 3.0.1 (2013-05-16) Platform: x86_64-w64-mingw32/x64 (64-bit) Not sure what happened but I tried it again and it did not work on my system either. If a workaround is ok then this works on my system: shell(paste(whoami, , out.txt)) -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ 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 Mon, Apr 22, 2013 at 10:27 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 21/04/2013 6:57 PM, Hadley Wickham wrote: PS. Hadley, is this what you meant when you wrote Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *., or those approaches are only when you call 'R CMD' from the R prompt? I believe the latter, but I just want to make sure I didn't miss something. Well both devtools and RStudio allow you to do package development without leaving R, so neither do anything to your path when you're not using them. In teaching windows users to develop R packages, I found the use of the command line to be a substantial road-block, and if you can develop packages without leaving R, why not? The idea of temporary additions to the path during the INSTALL/build/check code sounds reasonable. R could probably do it more accurately than devtools or RStudio can (since we know the requirements, and you have to guess at them), but could hopefully do it in a way that isn't incompatible with those. The code called by install.packages() and related functions within R is essentially the same code as called by R CMD INSTALL etc from the command line, so this would help both cases. I would like to comment on this as I have had to implement similar facilities myself as part R.bat in the batchfiles. There is an issue of keeping R and Rtools in sync. Currently different Rtools versions will work with the same R version. For example, I have used both Rtools 1927 and 1930 with the current version of R. Its necessary to determine the relative paths that the version of Rtools in use requires since in principle the relative Rtools paths can vary from one version of Rtools to the next if the gcc version changes, say. Ideally the system would be able to figure this out even if registry entries and environment variables are not set by looking in standard locations for the Rtools root and finding the relative paths by querying some file in the Rtools installation itself. devtools does this by querying the Rtools version and uss an internal database of relative paths keyed by version. R.bat in batchfiles does it by scanning the Rtools unins000.dat file and extracting the relative paths directly from it. This has the advantage that no database need be maintained and it also automatically adapts to new versions of Rtools without any foreknowledge of them. Of course since you have control of both ends you alternately could add the relative paths to an expanded version of the VERSION file or add some additional text file into Rtools for the purpose of identifying he relative paths.. Another possibility if significant changes were to be considered would be to make Rtools into an R package thereby leveraging existing facilities and much simplifying any synchronization. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ 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 Sun, Apr 21, 2013 at 8:18 AM, Hadley Wickham h.wick...@gmail.com wrote: The problem is that if you don't just use the PC for running R but use it to run other programs too then any program and that utilizes Windows batch scripts making use of find.exe or sort.exe likely won't work if Rtools is on your path. The fact that devtools, batchfiles and Rcpp have workarounds mitigates it somewhat but the problem should be fixed so it works out-of-the-box once and for all. I guess I don't see the advantage of that approach (except perhaps for simplicity), compared to using the registry to store path information and then using environmental variables to set it when needed. It would be nice if Rtools didn't override existing windows executables, in the same way it would be nice if windows worked like linux out of the box. But since it doesn't, and since in general adding more and more directories to the path makes it more and more likely for some conflict to arise, I think Rtools current approach is very reasonable. Because it can conflict with other Windows software unless you add a layer over it. What other popular software that runs on Windows has these problems? I can't think of any. The closest I can come up with was that for a short time after git was ported to Windows it would change the font of the Windows console but there was an immediate hue and cry about it having no business messing with the rest of Windows and it was quickly rectified. Accepting these infelicities just gets one onto a slippery slope. For example, as far as I know devtools and Rcpp don't have any current problems but that could easily change in the future since they keep databases of Rtools configurations which must be manually updated by their developers as Rtools evolves -- if Rtools changes they could stop working for periods of time until new versions are produced. R.bat in batchfiles was just re-written this year so it is a bit more robust to such changes but even it would have to be modified if the changes in Rtools were of sufficient magnitude. I don't blame these tools for this but surely this is a symptom that something is fundamentally wrong with the entire approach since the tight coupling of what should be independent modules results in the need for ongoing maintenance. Some good work was done to rid R and Rtools of dependence on perl but this effort should not stop there and needs to continue in order to reduce and eliminate the dependence on third party tools that cause problems. (By the way, regarding registry values and environment variables, R.bat in batchfiles will look at the registry and at environment variables but it will work even if no registry values or environment variables have been set by the user provided one uses standard locations for R and Rtools. That is, in fact, how I run my own configuration on Windows.) -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ 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 Sun, Apr 21, 2013 at 9:49 AM, Hadley Wickham h.wick...@gmail.com wrote: Because it can conflict with other Windows software unless you add a layer over it. What other popular software that runs on Windows has these problems? I can't think of any. The closest I can come up with was that for a short time after git was ported to Windows it would change the font of the Windows console but there was an immediate hue and cry about it having no business messing with the rest of Windows and it was quickly rectified. I don't understand: unless you modify settings in the default install, Rtools *does not* affect other windows software in any way. If its the case that it now works from the cmd line without setting the Rtools path before issuing R CMD ... that would be great. If so it must have occurred silently at some point since I have spent hours in past years trying to track down why another program I was using did not work only to discover that it was Rtools. Surely this was also your own understanding since devtools, maintains an Rtools path database which ought to be unnecessary if R is able to find Rtools itself. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ 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 Sun, Apr 21, 2013 at 12:57 PM, Hadley Wickham h.wick...@gmail.com wrote: Because it can conflict with other Windows software unless you add a layer over it. What other popular software that runs on Windows has these problems? I can't think of any. The closest I can come up with was that for a short time after git was ported to Windows it would change the font of the Windows console but there was an immediate hue and cry about it having no business messing with the rest of Windows and it was quickly rectified. I don't understand: unless you modify settings in the default install, Rtools *does not* affect other windows software in any way. If its the case that it now works from the cmd line without setting the Rtools path before issuing R CMD ... that would be great. If so it must have occurred silently at some point since I have spent hours in past years trying to track down why another program I was using did not work only to discover that it was Rtools. Surely this was also your own understanding since devtools, maintains an Rtools path database which ought to be unnecessary if R is able to find Rtools itself. I think we are having a failure of communication: Rtools does not set the path, so that you must do so, every time you use it. There is no other way to prevent it from interfering from some other windows software, except by tightly confining the scope in which it enters the path. When I first starting working with Rtools, I thought this was a terribly frustrating decision - why didn't the default installer always put rtools on the path? But now I see it's the only way - it avoids conflicts with other software, and without that default there'd be no way to have multiple versions of rtools installed. That said, I think the logic that Rstudio and devtools uses to find rtools would have been helpful to include in base R, but that's not so important now that it's available in a package. (And if any big change was made, I'd probably argue it'd be better just to always bundle rtools with R on windows - I think it's a key part of the philosophy of R that users can easily become developers. But there are obviously other considerations.) To clarify, the rtools database in devtools does not contain a list of locations of rtools, but the directories inside of an rtools installation that need to be available on the path. This list has changed over time as the tools needed by R have changed. I don't see any way of avoiding that (except perhaps by storing those in the registry, but regardless there's no way to go back in time and fix old decisions). Devtools (following the logic of rstudio) looks in a number of places to find rtools, first looking in the path and then in the registry, and takes considerable care to ensure that the versions of R and rtools match (another reason why the database is necessary). Yes, that is what I thought until you seemed to be saying otherwise but it seems we just misunderstood each other and, in fact, no one disputes the need to put Rtools on the path nor that it conflicts with other Windows programs and potentially causes other programs on your PC not to work. In fact that was one of the motivations I had for developing the batchfiles as I once spent hours tracking down a problem due to Rtools. Also I understand that the devtools database uses relative paths and wasn't faulting devtools for this but only pointing out that the database's existence was a consequence of the need to set up the paths in the first place which is what we were discussing - not devtools. __ 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 Sun, Apr 21, 2013 at 6:17 PM, Henrik Bengtsson h...@biostat.ucsf.edu wrote:
I (as well) keep a specific Rsetup.bat file for launching Windows
cmd.exe with the proper PATH etc setup for build R packages etc. It's
only after this thread I gave it a second thought; you can indeed
temporarily set the PATH via ~/.Rprofile or ~/.Renviron, which *are*
processed at the very beginning when calling 'R CMD ...'.
EXAMPLE WITH .Rprofile:
## ~/.Rprofile (e.g. C:/User/foo/.Rprofile):
path - unlist(strsplit(Sys.getenv(PATH), ;));
path - c(C:\\Rtools\\bin, C:\\Rtools\\gcc-4.6.3\\bin, path);
Sys.setenv(PATH=paste(unique(path), collapse=;));
## DISABLED:
x:\ R --no-init-file CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
ERROR: compilation failed for package 'matrixStats'
* removing 'C:/Users/hb/R/win-library/3.0/matrixStats'
## ENABLED:
x:\ R CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
gcc -m32 -IC:/PROGRA~1/R/R-3.0.0patched/include -DNDEBUG [...]
[...]
* DONE (matrixStats)
EXAMPLE WITH .Renviron:
## ~/.Renviron (e.g. C:/User/foo/.Renviron):
# Backslashes are preserved iff put within quotes
PATH=C:\Rtools\bin;C:\Rtools\gcc-4.6.3\bin;${PATH}
x:\ R --no-environ CMD INSTALL matrixStats_0.6.2.tar.gz
= fails
x:\ R CMD INSTALL matrixStats_0.6.2.tar.gz
= works
As long as R is on the PATH, the above either of the approaches
removes the need to add Rtools to the PATH via a BAT file and it won't
clutter up your PATH. This begs the question (as somewhat already
proposed), instead of users/developers doing this manually, would it
be possible to have 'R CMD ...' to locate add Rtools to the PATH
internally. That would certainly lower the barriers for newcomers to
install packages from source that need compilation. Obviously, this
doesn't make the tools (e.g. make) in Rtools available outside of R,
it does not allow you to build R itself from source, but it does cover
the very common use cases of calling 'R CMD build/INSTALL/check/...'.
/Henrik
PS. Hadley, is this what you meant when you wrote Better solutions
(e.g. Rstudio and devtools) temporarily set the path on when you're
calling R CMD *., or those approaches are only when you call 'R CMD'
from the R prompt? I believe the latter, but I just want to make sure
I didn't miss something.
That seems like a reasonable approach although the code shown does
entail more setup and ongoing maintenance by the user than R.bat which
does not require that the user edit any files and additionally locates
R itself and has many other features. Also, because R.bat locates R
itself it can be useful even if you are not doing development. On the
other hand if you are looking to do development strictly from within R
then devtools is already developed.
__
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 Sat, Apr 20, 2013 at 10:45 AM, Hadley Wickham h.wick...@gmail.com wrote: 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. Which is presumably why Rtools doesn't modify the path by default. Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *. I am well aware of the various kludges to address this including my own batchfiles ( http://batchfiles.googlecode.com ) which handles this by temporarily changing the path as well; however, the real problem is that Rtools does not play nice with Windows and that needs to be addressed directly. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ 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 Sat, Apr 20, 2013 at 11:49 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-04-20 11:09 AM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 10:45 AM, Hadley Wickham h.wick...@gmail.com wrote: 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. Which is presumably why Rtools doesn't modify the path by default. Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *. I am well aware of the various kludges to address this including my own batchfiles ( http://batchfiles.googlecode.com ) which handles this by temporarily changing the path as well; however, the real problem is that Rtools does not play nice with Windows and that needs to be addressed directly. It has been. You ignored it. Duncan Murdoch If some change to address this has been made that would be great but there is no mention of it on the Rtools page in the change history section (the only documented change relates to the png/tiff/jpeg libraries), there was no announcement that I saw and Rtools\bin still contains find and sort so what specifically is the change? -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ 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 Sat, Apr 20, 2013 at 1:54 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-04-20 12:30 PM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 11:49 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-04-20 11:09 AM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 10:45 AM, Hadley Wickham h.wick...@gmail.com wrote: 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. Which is presumably why Rtools doesn't modify the path by default. Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *. I am well aware of the various kludges to address this including my own batchfiles ( http://batchfiles.googlecode.com ) which handles this by temporarily changing the path as well; however, the real problem is that Rtools does not play nice with Windows and that needs to be addressed directly. It has been. You ignored it. Duncan Murdoch If some change to address this has been made that would be great but there is no mention of it on the Rtools page in the change history section (the only documented change relates to the png/tiff/jpeg libraries), there was no announcement that I saw and Rtools\bin still contains find and sort so what specifically is the change? It's not a change to Rtools, it's a change is to the build system in R: it allows you to rename sort or find in your own copy of Rtools, and R will use whatever you specify. You were informed of this when I did it in 2007, and I've mentioned it when the topic comes up here, most recently in the message quoted above. That's a long time ago, so I don't remember if you tried it then, but I've never heard a complaint from anyone else that it doesn't work. I certainly was not aware of this and posts in this thread suggest that others were not aware of it either. Perhaps you could provide some details and links. I am sure many people would be interested. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ 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
On Sat, Apr 20, 2013 at 1:44 PM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
On 13-04-19 2:57 PM, Thomas Alexander Gerds wrote:
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?
Yes, this is tricky. The problem is that out is in the environment of
out$f, so you get two copies when you save it. (I think you won't have two
copies in memory, because R only makes a copy when it needs to, but I
haven't traced this.)
Here are two solutions, both have some problems.
1. Don't put out in the environment:
test - function(x) {
x - rnorm(100)
out$x - list(x=x)
out$f - a ~ b# the as.formula() was never needed
# temporarily create a new environment
local({
# get a copy of what you want to keep
out - out
# remove everything that you don't need from the formula
rm(list=c(x, out), envir=environment(out$f))
# return the local copy
out
})
}
I don't like this because it is too tricky, but you could probably wrap the
tricky bits into a little function (a variant on return() that cleans out
the environment first), so it's probably what I would use if I was desperate
to save space in saved copies.
2. Never evaluate the formula in the first place, so it doesn't pick up the
environment:
test - function(x) {
x - rnorm(100)
out$x - list(x=x)
out$f - quote(a ~ b)
out
}
This is a lot simpler, but it might not work with some modelling functions,
which would be confused by receiving the model formula unevaluated. It also
has the problems that you get with using .GlobalEnv as the environment of
the formula, but maybe to a slightly lesser extent: rather than having what
is possibly the wrong environment, it doesn't have one at all.
An approach along the lines of Duncan's last solution that works with
lm but may or may not work with other regression-style functions is to
use a character string:
fit - lm(demand ~ Time, BOD)
As long as you are only saving the input you should be OK but if you
are saving the output of lm then you are back to the same problem
since the lm object will contain a formula.
class(formula(fit))
[1] formula
__
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 Sat, Apr 20, 2013 at 2:21 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-04-20 2:02 PM, Kevin Coombes wrote: On 4/20/2013 12:54 PM, Duncan Murdoch wrote: On 13-04-20 12:30 PM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 11:49 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-04-20 11:09 AM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 10:45 AM, Hadley Wickham h.wick...@gmail.com wrote: 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. Which is presumably why Rtools doesn't modify the path by default. Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *. I am well aware of the various kludges to address this including my own batchfiles ( http://batchfiles.googlecode.com ) which handles this by temporarily changing the path as well; however, the real problem is that Rtools does not play nice with Windows and that needs to be addressed directly. It has been. You ignored it. Duncan Murdoch If some change to address this has been made that would be great but there is no mention of it on the Rtools page in the change history section (the only documented change relates to the png/tiff/jpeg libraries), there was no announcement that I saw and Rtools\bin still contains find and sort so what specifically is the change? It's not a change to Rtools, it's a change is to the build system in R: it allows you to rename sort or find in your own copy of Rtools, and R will use whatever you specify. You were informed of this when I did it in 2007, and I've mentioned it when the topic comes up here, most recently in the message quoted above. That's a long time ago, so I don't remember if you tried it then, but I've never heard a complaint from anyone else that it doesn't work. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel How do you do that? (More explicitly, what steps would I have to take to redefine things like find.exe and sort.exe in Rtools so that R would know how to find them and use them? I can't figure that out from the earlier parts of these messages.) Rename them to whatever you want in the Rtools install, then edit the definitions. I think currently they are in src/gnuwin32/Makefile and src/gnuwin32/MkRules (one in each), but I'd suggest you just search files named M* for the strings sort and find, in case I've got it wrong, or it has changed since the last time I looked. If you try to build R itself rather than just packages, you may need to do more edits, because some of the makefiles for things like the jpeg libraries weren't written by us, and may have these commands hard-coded. Are you suggesting that R itself be rebuild? Rtools be rebuilt? Some clarity on this and the process to do it would be helpful. I was really looking for a way to do this with an out of the box R installation since from a practical viewpoint few are going to want to build their own software. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ 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 Sat, Apr 20, 2013 at 9:13 PM, Hadley Wickham h.wick...@gmail.com wrote: As far as I can tell, the steps you are recommending take place in an earlier build step. This would require the user who wants to do this to rebuild Rtools in its entirety, which is more trouble than it is likely to be worth. Especially when you can avoid the problem by using your own batch script or perl script to reset the path on those relatively rare occasions when you need to use Rtools. Since buiilding Rtools for a Windows machine is something than CRAN does on a regular basis, why can't they just change the names there (and not bother the UNIX users, and probably not even bother the UNIX users who find themselves banished to the Windows wilderness). Just call them unixfind and unixsort and everyone will be able to figure it out Because the point of Rtools is to make windows more like linux, rather than less? I really don't understand the complaints in this thread - I have regularly had classes of 10-20 windows users build a package with no prior experience, and simply downloading and installing Rtools. In my opinion Rtools uses the right defaults, and with a bit of extra scripting work (painful at first, but only needs to be done once, e.g. https://github.com/hadley/devtools/blob/master/R/rtools.r) it's painless to use from R. The problem is that if you don't just use the PC for running R but use it to run other programs too then any program and that utilizes Windows batch scripts making use of find.exe or sort.exe likely won't work if Rtools is on your path. The fact that devtools, batchfiles and Rcpp have workarounds mitigates it somewhat but the problem should be fixed so it works out-of-the-box once and for all. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ 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
Re: [Rd] Documentation error in subsitute
On Wed, Apr 3, 2013 at 10:38 AM, Hadley Wickham h.wick...@gmail.com wrote:
Hi all,
The documentation for substitute currently reads:
Substitution takes place by examining each component of the parse
tree as follows: If it is not a bound symbol in ‘env’, it is
unchanged. If it is a promise object, i.e., a formal argument to
a function or explicitly created using ‘delayedAssign()’, the
expression slot of the promise replaces the symbol. If it is an
ordinary variable, its value is substituted, unless ‘env’ is
‘.GlobalEnv’ in which case the symbol is left unchanged.
Since the clause referring to the globalenv() is attached to the
discussion of ordinary variables, I thought that it implied that
delayedAssign(a, test)
substitute(a)
would return test (but actually it returns quote(a))
I'd suggest rewording this paragraph to:
Substitution takes place by examining each component of the parse
tree as follows: If it is not a bound symbol in ‘env’, it is
unchanged. If it is a promise object, i.e., a formal argument to
a function or explicitly created using ‘delayedAssign()’, the
expression slot of the promise replaces the symbol. If it is an
ordinary variable, its value is substituted. There's one important
exception to these rules: If 'env' is the ‘.GlobalEnv’, then no
substitution occurs.
It acts differently in the global environment. Try this:
f - function() { delayedAssign(a, test); substitute(a) }
f()
[1] test
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Return value of S4 validity function
On Thu, Feb 28, 2013 at 3:44 PM, Gabor Grothendieck
ggrothendi...@gmail.com wrote:
This issues a message about a needing to be non-negative as expected:
setClass(A,
representation = list(a = numeric),
prototype = list(a = 0),
validity = function(object) {
out - if (object@a 0) a must be non-negative
if (is.null(out)) TRUE else out ##
})
new(A, a = -1)
but it also works if the ## line is omitted so it appears that one can
use NULL in place of TRUE. I wonder if the use of NULL as an
alternative to TRUE could be officially supported as it would allow
one to write validity methods in a more concise manner. It appears
that this would only require a change to the documentation.
Pressed return too quickly. This should have continued on to give this example:
new(A)
with and without the ## line both of which work since it appears that
NULL can be used in place of TRUE.
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Return value of S4 validity function
This issues a message about a needing to be non-negative as expected:
setClass(A,
representation = list(a = numeric),
prototype = list(a = 0),
validity = function(object) {
out - if (object@a 0) a must be non-negative
if (is.null(out)) TRUE else out ##
})
new(A, a = -1)
but it also works if the ## line is omitted so it appears that one can
use NULL in place of TRUE. I wonder if the use of NULL as an
alternative to TRUE could be officially supported as it would allow
one to write validity methods in a more concise manner. It appears
that this would only require a change to the documentation.
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RSetReg.exe
R.exe, Rgui.exe, Rcmd.exe and Rscript.exe all support the --help argument but RSetReg.exe --help ignores the argument and attempts to set the registry key. Since one might try this as a first attempt to figure out what the command is all about this seems a bit dangerous. It would be nice if it responded to --help as the other R*.exe commands do. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Creating ref class with same name as S4 class results in error
It seems that if one overwrites an S4 class with a Reference Class of the same name that one gets an error in the situation below. I would have expected that the Reference Class would replace the S4 class in such a way that one could now use the Reference Class. A - setClass(A, representation(x = ANY)) x - A() A - setRefClass(A, fields = a) x - A$new(a = 1) Error in initialize(value, ...) : invalid names for slots of class A: a R.version.string [1] R version 2.15.2 Patched (2013-01-17 r61672) I got the same result on: R Under development (unstable) (2013-01-25 r61745) Both were run under Windows 8 64 bit. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Tricking Promises into Sending Info Via Args into Caller
The is.pos function below results in the variable, out, being set to
TRUE if the first argument to is.pos is positive and to FALSE
otherwise.
It does this without using the return value or using scoping tricks to
reach into the caller. Instead it tricks the promise into
communicating one bit of information upwardly from the function to its
caller via the second argument.
One would have thought this to be impossible. Is this intended behavior?
is.pos - function(i, x) { if (i 0) x; NULL }
# in this example actual arg1 of is.pos is positive
out - FALSE
is.pos(1, out - TRUE)
out # TRUE
# in this example actual arg1 of is.pos is negative
out - FALSE
is.pos(-1, out - TRUE)
out # FALSE
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] weird bug with parallel, RSQlite and tcltk
On Thu, Jan 3, 2013 at 7:45 AM, peter dalgaard pda...@gmail.com wrote: On Jan 3, 2013, at 12:20 , Gabor Grothendieck wrote: On Thu, Jan 3, 2013 at 5:59 AM, peter dalgaard pda...@gmail.com wrote: On Jan 3, 2013, at 10:32 , Karl Forner wrote: Hello, The point is that I do not use tcltk, it gets loaded probably as a dependency of a dependency of a package. When I unload it all work perfectly fine. I just found it because one of my computer did not have tk8.5 installed, and did not exhibit the mentioned bug. So I really think something should be done about this. Maybe the gui loop should not be run a the the loading of the tcltk package, but at the first function ran, or something like this. Doesn't sound doable. It would be tricky to do and wouldn't help in the cases where people actually want to use the GUI - plus, it would leave a time bomb if you directly or indirectly fire up a Tk window (say, the CRAN menu from install.packages()). Would it be possible to separate the tk and tcl portions of tcltk into two packages so that the tcltk package would be dependent on a new tcl package ? From the viewpoint of a user of tcltk there would be no change but it would allow packages that only use tcl to declare a dependency only on that. Not sure that actually solves much. We do this already if the DISPLAY is unset for X11, so the logic should not be too hard to extend, but the event loop belongs to Tcl, Tk events are just a special type of events. OK. I had assumed the event loop was to process the GUI events only and therefore would be in tk. Another possibility might be just to have a standard option that users or other packages could set to indicate that they don't have or don't want to use tcltk so packages that do use tcltk could examine that option and act accordingly (e.g. use alternate code or issue a meaningful error). I already use options(gsubfn.engine = R) for that purpose but that only works for my packages and if something were standardized in tcltk then it could be more broadly applicable and more visible. As far as tcltk this is basically just a matter of documentation to set the standard but for the parallel package, say, the option could be automatically set in the workers. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rtools216.exe on Windows
1. If your PATH is very long then on the Select Additional Tasks screen in the Rtools installer the two check box titles (Edit the system PATH and Save version number) will be obscured (i.e. you won't be able to see them at all) making the screen very confusing. One just sees two boxes on the left and a long path on the right and has no idea what it all means. Also even with a short path the first box will not be aligned with the Edit system PATH phrase making it unclear what it refers to. Either this should be fixed or if Inno Setup makes it difficult to change then some verbiage should be placed at the top of the screen explaining what its all about. 2. It would be useful if Rtools placed the paths it uses in the registry and possibly also in a batch file too such as: set RTOOLS_PATH=c:\Rtools\bin;c:\Rtools\gcc-4.6.3\bin so that other software can readily access it or those not wishing to permanently change their path have other options. 3. Its not clear from the http://cran.r-project.org/bin/windows/Rtools/ page where the Rtools installer source is located. In the Download section of the http://cran.r-project.org/bin/windows/Rtools page is a link to http://cran.r-project.org/bin/windows/Rtools/installer.html but the source-tools link on that page is broken. 4. Rtools puts find.exe on your PATH which can cause existing software using the built in find.exe in Windows to malfunction. As a result its dangerous to permanently add the Rtools paths to your PATH. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] library(tcltk) v. SIGPIPE BUG (?!?)
On Tue, Dec 11, 2012 at 3:14 PM, Cook, Malcolm m...@stowers.org wrote: Hi R-devel, tcltk devel, and sqldf devel, The transcript below shows how loading the tcl/tk library in under R causes subprocesses to ignore SIGPIPE. I am including the developer of the (wonderful) sqldf package since it requires tcltk and you might like to make this dependence optional to the user (at least until this is fixed in tcltk). Am I mistaken in calling this a 'bug'? Any insights appreciated! Thanks, Malcolm Cook Computational Biology - Stowers Institute for Medical Research system(intern=TRUE,'yes | head ') [1] y y y y y y y y y y library(tcltk) Loading Tcl/Tk interface ... done system(intern=TRUE,'yes | head ') ### this now does not return to the prompt and Looking at 'top' shows that 'yes' is running until I hit ctrl-c, after which it returns. C-c C-c [1] y y y y y y y y y y sessionInfo() R version 2.15.1 (2012-06-22) Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) locale: [1] C attached base packages: [1] tcltk stats graphics grDevices utils datasets methods base As a workaround specify the R engine instead of the tcl engine in wihch case gsubfn (which is called by sqldf) won't try to use the tcltk package: options(gsubfn.engine = R) library(sqldf) -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Capturing environment associated with a promise
On Mon, Oct 8, 2012 at 9:22 AM, Hadley Wickham h.wick...@gmail.com wrote: Hi all, It's possible to capture the expression associated with a promise (using substitute). Is there any way to capture the environment associated with a promise? Similarly, is there any way to tell if something is a promise without accidentally evaluating it? Both of these are possible in C. See: https://stat.ethz.ch/pipermail/r-devel/2007-September/046943.html It shows how to query an object to see if its a promise and but rather than extract the environment it shows how to copy a promise without evaluating it; however, it was also my experience that these two were what was actually needed rather than being able to extract the environment. I would also recommend you do some testing since I found that adding promises did not always make as big a difference in performance as I had hoped and the added complexity may not be worth it in all cases. For example, I had a version of proto that supported promises but ggplot2 only ran slightly faster with it so I did not pursue it any further. On the other hand if you are doing it to support self-referential structures then that is a different matter. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tcltk capability
On Thu, Sep 27, 2012 at 2:18 PM, Paul Johnson pauljoh...@gmail.com wrote: Sorry I did not see this sooner. Response below: On Thu, Aug 30, 2012 at 2:48 PM, Gabor Grothendieck ggrothendi...@gmail.com wrote: There are quite a few packages that make use of tcltk and although - most R distributions have tcltk capability - its possible to query this via capabilities()[[tcltk]] - attempting to build a package that needs it on such an R distribution will give a message letting one know users still seem to have problems with this. I agree that packages are using tcltk, but users do so at their peril. Just loading tcltk breaks multicore functions like mclapply. I don't understand why, you might be able to explain it to me. http://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15040 tcltk is discouraged, at least to some in R core. I would really appreciate some guidance on what graphics library I should use to develop GUI for R programs. There's no future in tcltk, apparently, but I don't know what to work with. R aside, tcl/tk itself is far from dead. Although not as popular as in its heyday there is still a core group that works on it and keeps issuing new versions. The versions are quite a few years apart but on the other hand they tend to have major improvements to them which would seem to justify a longer cycle. In terms of the tcl/tk community, new or updated packages for tcl/tk keep coming out. Looking at some of the tcl/tk packages that I have used in the last year I notice that several of them have a last release date of this year. Also at least some books on tcl/tk keep coming out, the tcltk mailing list is active, there continues to be tcl/tk conferences and there is a very active tcl/tk wiki. The above was for the tcl/tk language only but if we look at the tcltk R package then its bundled with most versions of R so its the easiest way to have a GUI with minimal installation hassle on most platforms. On Windows and most Linux distributions just issue library(tcltk) in your session and you have it with nothing else to do in terms of installation. Furthermore there is a reasonably large infrastructure of R packages either built on tcltk or that can use tcltk as well as a number of addon R packages that can ease development. If you can't decide on which GUI toolkit to use have a look at gWidgets. It provides a common layer over multiple GUI toolkits which subject to some limitations based on which features were used lets the user switch at will among the various toolkits. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] tcltk capability
There are quite a few packages that make use of tcltk and although - most R distributions have tcltk capability - its possible to query this via capabilities()[[tcltk]] - attempting to build a package that needs it on such an R distribution will give a message letting one know users still seem to have problems with this. There was recently an R bug report submitted that likely stemmed from the user having such a build of R and recently there was also an R help post that seemed to be related to this as well. As more and more packages add GUI capability these incidents are bound to increase. The best situation would be to arrange that every distribution of R have tcltk capability but if this is difficult to arrange then I suggest there be a message at start up similar to the existing locale message letting the user know that the R distribution they are running lacks tcltk capability. Preferably the message would be somewhat menacing so that users are encouraged to get a different distribution of R right from the start. This might reduce such problem reports somewhat. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rep fails on pairlist
On Thu, Jul 26, 2012 at 4:24 PM, Dirk Eddelbuettel e...@debian.org wrote:
On 26 July 2012 at 15:55, Gabor Grothendieck wrote:
| This code which has worked for years in R but fails under R-devel:
|
| R.version.string
| [1] R Under development (unstable) (2012-07-25 r59963)
|
| n - 3
| f - function(x) {}
| formals(f) - rep(formals(f), n) ##
| Error in rep(formals(f), n) : replication of pairlists is defunct
|
| The message suggests that the change was intentional.
| Why was this functionality removed?
| What code should be used in its place?
FWIW there are changes happening right now to rep() so that may be spillage
from code under development. To keep abreast of these changes, I follow the
RSS feed Duncan set up a few years ago -- it is also as html at
http://developer.r-project.org/blosxom.cgi/R-devel
and summarizes changes committed to the NEWS file, ie high-level changes
worth knowing about.
That page says:
Calling ‘rep()’ or ‘rep.int()’ on a pairlist or other non-vector
object is now an error.
so it again seems to be intentional.
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rep fails on pairlist
On Thu, Jul 26, 2012 at 7:29 PM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
On 12-07-26 3:55 PM, Gabor Grothendieck wrote:
This code which has worked for years in R but fails under R-devel:
R.version.string
[1] R Under development (unstable) (2012-07-25 r59963)
n - 3
f - function(x) {}
formals(f) - rep(formals(f), n) ##
Error in rep(formals(f), n) : replication of pairlists is defunct
The message suggests that the change was intentional.
Why was this functionality removed?
What code should be used in its place?
rep() on a pairlist didn't return a pairlist, it coerced to a list and then
rep'd that. So you could do the same explicitly if that's what you really
want:
formals(f) - rep(as.list(formals(f)), n)
This works because the formals- code is forgiving; other uses of pairlists
would not accept the result of rep on a pairlist.
Thanks. I will use that instead.
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Finding dynamic shared libraries loaded with a package
On Mon, Jul 23, 2012 at 8:29 PM, Winston Chang winstoncha...@gmail.com wrote: Is there a way to query a package to see what dynamic shared libraries are loaded with it? This gives a DLLInfoList class object whose components are info associated with the loaded dll's DLLInfoList - library.dynam() and this gives the components associated with package stats DLLInfoList[sapply(DLLInfoList, [[, name) == stats] -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] extractAIC.nls
On Sat, Jul 14, 2012 at 6:53 PM, Spencer Graves spencer.gra...@prodsyse.com wrote: Hello: Does extractAIC.nls exist anywhere? If no, is there some reason it should not be used? I'm planning to add it to the fda package, but before I do, I felt a need to ask if there is some reason I shouldn't or if there are caveats I should include in the help page for it. AIC in stats works on nls objects. It calls AIC.default which calls logLik.nls . -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] extractAIC.nls
On Sat, Jul 14, 2012 at 8:48 PM, Spencer Graves
spencer.gra...@prodsyse.com wrote:
On 7/14/2012 4:11 PM, Gabor Grothendieck wrote:
On Sat, Jul 14, 2012 at 6:53 PM, Spencer Graves
spencer.gra...@prodsyse.com wrote:
Hello:
Does extractAIC.nls exist anywhere? If no, is there some reason
it
should not be used?
I'm planning to add it to the fda package, but before I do, I felt
a
need to ask if there is some reason I shouldn't or if there are caveats I
should include in the help page for it.
AIC in stats works on nls objects. It calls AIC.default which calls
logLik.nls .
Thanks for the reply. Unfortunately, it fails for me in the following
modification of the first example in help('nls'):
You tried it with extractAIC but my post suggested you use AIC which
is a different function.
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Curry: proposed new functional programming, er, function.
On Sat, May 26, 2012 at 12:30 PM, Yike Lu yikelu.h...@gmail.com wrote: On 5/25/12 5:23 PM, Hadley Wickham wrote: On Fri, May 25, 2012 at 3:14 PM, Yike Luyikelu.h...@gmail.com wrote: So here's the way I'm reading this: Original: curry_call is the function body you're constructing, which is itself just a one liner which calls the symbol FUN with the appropriate substitutions. Yup. With a bit more infrastructure you could probably modify it so that multiple curries collapsed into the equivalent single curry. Yes I could see how one would do that - if the match.call detects a Curry as the first function being called, we would short circuit the usual evaluation into a different path which properly collapses all the nesting. It's interesting how R offers these facilities to override the usual evaluation order, but if one does that too much it could easily become confusing. I was looking at Rpipe the other day (https://github.com/slycoder/Rpipe) and the way he implements it is by defining his own Eval. The proto package does currying on proto methods by defining $.proto appropriately: library(proto) p - proto(a = 1, b = 2) # same as ls(p) - output is c(a, b) p$ls() Here ls() is _not_ a special proto method but is just the ordinary ls() provided by R. $.proto calls ls() sticking in p as the first argument. A proto object is an environment and ls with a first argument that is an environment lists the names of the objects in that environment. Similarly: p$as.list() p$str() p$parent.env() p$print() p$eapply(length) are the same as as.list(p), str(p), parent.env(p), print(p) and eapply(p, length). Although this might seem like its just syntax in proto it does allow one to override the method. For example, p2 - proto(a = 1, b = 2, print = function(.) with(., cat(a:, a, b:, b, \n)) ) p2$print() # uses p2's print print(p2) # uses R's print etc. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Best way to locate R executable from within R?
On Tue, May 22, 2012 at 1:34 PM, Henrik Bengtsson h...@biostat.ucsf.edu wrote: Hi, I'd like to spawn of a new R process from within R using system(), e.g. system(R -f myScript.R). However, just specifying R as in that example is not guaranteed to work, because R may not be on the OS's search path. What is the best way, from within a running R, to infer the command (basename or full path) for launching R in way that it works on any OS? I came up with the following alternatives, but I'm not sure if they'll work everywhere or not: 1. Rbin - commandArgs()[1]; 2. Rbin - file.path(R.home(), bin, R); Other suggestions that are better? At least on Windows one could run R via R.exe, Rterm.exe or Rgui.exe amd #2 would not pick up the differences. On the other hand if I do this on the Windows command line on my Vista system with R 2.15.0 patched: cd \program files\R\R-2.15.x\bin\i386 Rterm.exe and then enter commandArgs() into R, the output is Rterm.exe with no path. The fact that one can have 32 bit and 64 bit R executables on the same system complicates things too. Thus, on Windows something like this might work: file.path(R.home(bin), R.version$arch, basename(commandArgs()[[1]])) If there are cases that I missed then this might pick up those too: R - commandArgs()[[1]] if (R == basename(R)) R - file.path(R.home(bin), R.version$arch, R) -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Best way to locate R executable from within R?
On Tue, May 22, 2012 at 3:05 PM, Henrik Bengtsson h...@biostat.ucsf.edu wrote: On Tue, May 22, 2012 at 11:39 AM, Gabor Grothendieck ggrothendi...@gmail.com wrote: On Tue, May 22, 2012 at 1:34 PM, Henrik Bengtsson h...@biostat.ucsf.edu wrote: Hi, I'd like to spawn of a new R process from within R using system(), e.g. system(R -f myScript.R). However, just specifying R as in that example is not guaranteed to work, because R may not be on the OS's search path. What is the best way, from within a running R, to infer the command (basename or full path) for launching R in way that it works on any OS? I came up with the following alternatives, but I'm not sure if they'll work everywhere or not: 1. Rbin - commandArgs()[1]; 2. Rbin - file.path(R.home(), bin, R); Other suggestions that are better? At least on Windows one could run R via R.exe, Rterm.exe or Rgui.exe amd #2 would not pick up the differences. On the other hand if I do this on the Windows command line on my Vista system with R 2.15.0 patched: cd \program files\R\R-2.15.x\bin\i386 Rterm.exe and then enter commandArgs() into R, the output is Rterm.exe with no path. Thanks, I overlooked this need. For my particular use case, I'm interested in launching R in batch mode, so R will do (but not Rgui). The fact that one can have 32 bit and 64 bit R executables on the same system complicates things too. Thus, on Windows something like this might work: file.path(R.home(bin), R.version$arch, basename(commandArgs()[[1]])) If there are cases that I missed then this might pick up those too: R - commandArgs()[[1]] if (R == basename(R)) R - file.path(R.home(bin), R.version$arch, R) FYI, R.home(bin) is not the same as file.path(R.home(), bin), cf. help(R.home). R.home(bin) will pick up the current architecture directory (by using .Platform$r_arch), e.g. R.home(bin) [1] C:/PROGRA~1/R/R-2.15.0patched/bin/x64 /Henrik Then perhaps something like this which is still not 100% foolproof but should work most of the time: Find(file.exists, c( commandArgs()[[1]], file.path(R.home(bin), commandArgs()[[1]]), file.path(R.home(bin), R) )) -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Best way to locate R executable from within R?
On Tue, May 22, 2012 at 3:28 PM, Gabor Grothendieck ggrothendi...@gmail.com wrote: On Tue, May 22, 2012 at 3:05 PM, Henrik Bengtsson h...@biostat.ucsf.edu wrote: On Tue, May 22, 2012 at 11:39 AM, Gabor Grothendieck ggrothendi...@gmail.com wrote: On Tue, May 22, 2012 at 1:34 PM, Henrik Bengtsson h...@biostat.ucsf.edu wrote: Hi, I'd like to spawn of a new R process from within R using system(), e.g. system(R -f myScript.R). However, just specifying R as in that example is not guaranteed to work, because R may not be on the OS's search path. What is the best way, from within a running R, to infer the command (basename or full path) for launching R in way that it works on any OS? I came up with the following alternatives, but I'm not sure if they'll work everywhere or not: 1. Rbin - commandArgs()[1]; 2. Rbin - file.path(R.home(), bin, R); Other suggestions that are better? At least on Windows one could run R via R.exe, Rterm.exe or Rgui.exe amd #2 would not pick up the differences. On the other hand if I do this on the Windows command line on my Vista system with R 2.15.0 patched: cd \program files\R\R-2.15.x\bin\i386 Rterm.exe and then enter commandArgs() into R, the output is Rterm.exe with no path. Thanks, I overlooked this need. For my particular use case, I'm interested in launching R in batch mode, so R will do (but not Rgui). The fact that one can have 32 bit and 64 bit R executables on the same system complicates things too. Thus, on Windows something like this might work: file.path(R.home(bin), R.version$arch, basename(commandArgs()[[1]])) If there are cases that I missed then this might pick up those too: R - commandArgs()[[1]] if (R == basename(R)) R - file.path(R.home(bin), R.version$arch, R) FYI, R.home(bin) is not the same as file.path(R.home(), bin), cf. help(R.home). R.home(bin) will pick up the current architecture directory (by using .Platform$r_arch), e.g. R.home(bin) [1] C:/PROGRA~1/R/R-2.15.0patched/bin/x64 /Henrik Then perhaps something like this which is still not 100% foolproof but should work most of the time: Find(file.exists, c( commandArgs()[[1]], file.path(R.home(bin), commandArgs()[[1]]), file.path(R.home(bin), R) )) So that the last one tried works on Windows too it should be: Find(file.exists, c( commandArgs()[[1]], file.path(R.home(bin), commandArgs()[[1]]), file.path(R.home(bin), R), file.path(R.home(bin), R.exe) )) -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Best way to locate R executable from within R?
On Tue, May 22, 2012 at 6:04 PM, Simon Urbanek simon.urba...@r-project.org wrote: On May 22, 2012, at 3:34 PM, Gabor Grothendieck wrote: On Tue, May 22, 2012 at 3:28 PM, Gabor Grothendieck ggrothendi...@gmail.com wrote: On Tue, May 22, 2012 at 3:05 PM, Henrik Bengtsson h...@biostat.ucsf.edu wrote: On Tue, May 22, 2012 at 11:39 AM, Gabor Grothendieck ggrothendi...@gmail.com wrote: On Tue, May 22, 2012 at 1:34 PM, Henrik Bengtsson h...@biostat.ucsf.edu wrote: Hi, I'd like to spawn of a new R process from within R using system(), e.g. system(R -f myScript.R). However, just specifying R as in that example is not guaranteed to work, because R may not be on the OS's search path. What is the best way, from within a running R, to infer the command (basename or full path) for launching R in way that it works on any OS? I came up with the following alternatives, but I'm not sure if they'll work everywhere or not: 1. Rbin - commandArgs()[1]; 2. Rbin - file.path(R.home(), bin, R); Other suggestions that are better? At least on Windows one could run R via R.exe, Rterm.exe or Rgui.exe amd #2 would not pick up the differences. On the other hand if I do this on the Windows command line on my Vista system with R 2.15.0 patched: cd \program files\R\R-2.15.x\bin\i386 Rterm.exe and then enter commandArgs() into R, the output is Rterm.exe with no path. Thanks, I overlooked this need. For my particular use case, I'm interested in launching R in batch mode, so R will do (but not Rgui). The fact that one can have 32 bit and 64 bit R executables on the same system complicates things too. Thus, on Windows something like this might work: file.path(R.home(bin), R.version$arch, basename(commandArgs()[[1]])) If there are cases that I missed then this might pick up those too: R - commandArgs()[[1]] if (R == basename(R)) R - file.path(R.home(bin), R.version$arch, R) FYI, R.home(bin) is not the same as file.path(R.home(), bin), cf. help(R.home). R.home(bin) will pick up the current architecture directory (by using .Platform$r_arch), e.g. R.home(bin) [1] C:/PROGRA~1/R/R-2.15.0patched/bin/x64 /Henrik Then perhaps something like this which is still not 100% foolproof but should work most of the time: Find(file.exists, c( commandArgs()[[1]], file.path(R.home(bin), commandArgs()[[1]]), file.path(R.home(bin), R) )) So that the last one tried works on Windows too it should be: Find(file.exists, c( commandArgs()[[1]], file.path(R.home(bin), commandArgs()[[1]]), file.path(R.home(bin), R), file.path(R.home(bin), R.exe) )) Obviously, you don't want to do that for reasons discussed previously. In most cases with a link the complete path would be passed in which case the first arg of Find would be chosen and be correct. If not it would fail through to further choices one of which would likely be correct and if none of them are then its likely that file.path(R.home(bin), R) isn't either since that is already one of the choices. While its not 100% foolproof the cases where it does not work are quite pathological whereas the cases where file.path(R.home(bin), R) fails to use the same executable include common cases such as R being called as Rterm or Rscript. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Best way to locate R executable from within R?
On Tue, May 22, 2012 at 7:50 PM, Simon Urbanek simon.urba...@r-project.org wrote: On May 22, 2012, at 7:37 PM, Gabor Grothendieck wrote: On Tue, May 22, 2012 at 6:04 PM, Simon Urbanek simon.urba...@r-project.org wrote: On May 22, 2012, at 3:34 PM, Gabor Grothendieck wrote: On Tue, May 22, 2012 at 3:28 PM, Gabor Grothendieck ggrothendi...@gmail.com wrote: On Tue, May 22, 2012 at 3:05 PM, Henrik Bengtsson h...@biostat.ucsf.edu wrote: On Tue, May 22, 2012 at 11:39 AM, Gabor Grothendieck ggrothendi...@gmail.com wrote: On Tue, May 22, 2012 at 1:34 PM, Henrik Bengtsson h...@biostat.ucsf.edu wrote: Hi, I'd like to spawn of a new R process from within R using system(), e.g. system(R -f myScript.R). However, just specifying R as in that example is not guaranteed to work, because R may not be on the OS's search path. What is the best way, from within a running R, to infer the command (basename or full path) for launching R in way that it works on any OS? I came up with the following alternatives, but I'm not sure if they'll work everywhere or not: 1. Rbin - commandArgs()[1]; 2. Rbin - file.path(R.home(), bin, R); Other suggestions that are better? At least on Windows one could run R via R.exe, Rterm.exe or Rgui.exe amd #2 would not pick up the differences. On the other hand if I do this on the Windows command line on my Vista system with R 2.15.0 patched: cd \program files\R\R-2.15.x\bin\i386 Rterm.exe and then enter commandArgs() into R, the output is Rterm.exe with no path. Thanks, I overlooked this need. For my particular use case, I'm interested in launching R in batch mode, so R will do (but not Rgui). The fact that one can have 32 bit and 64 bit R executables on the same system complicates things too. Thus, on Windows something like this might work: file.path(R.home(bin), R.version$arch, basename(commandArgs()[[1]])) If there are cases that I missed then this might pick up those too: R - commandArgs()[[1]] if (R == basename(R)) R - file.path(R.home(bin), R.version$arch, R) FYI, R.home(bin) is not the same as file.path(R.home(), bin), cf. help(R.home). R.home(bin) will pick up the current architecture directory (by using .Platform$r_arch), e.g. R.home(bin) [1] C:/PROGRA~1/R/R-2.15.0patched/bin/x64 /Henrik Then perhaps something like this which is still not 100% foolproof but should work most of the time: Find(file.exists, c( commandArgs()[[1]], file.path(R.home(bin), commandArgs()[[1]]), file.path(R.home(bin), R) )) So that the last one tried works on Windows too it should be: Find(file.exists, c( commandArgs()[[1]], file.path(R.home(bin), commandArgs()[[1]]), file.path(R.home(bin), R), file.path(R.home(bin), R.exe) )) Obviously, you don't want to do that for reasons discussed previously. In most cases with a link the complete path would be passed in which case the first arg of Find would be chosen and be correct. If not it would fail through to further choices one of which would likely be correct and if none of them are then its likely that file.path(R.home(bin), R) isn't either since that is already one of the choices. While its not 100% foolproof the cases where it does not work are quite pathological whereas the cases where file.path(R.home(bin), R) fails to use the same executable include common cases such as R being called as Rterm or Rscript. Except that you may not have noticed that no one asked about that since that makes no sense (arguments differ etc.). The question was how to start R and your suggestions make it only worse and unusable - fortunately Henrik asked about better solutions so we can safely close this discussion. Cheers, Simon So far he has excluded Rgui but that still leaves Rterm, Rscript and R (and littler on UNIX) -- all of which are valid ways to launch R. If its sufficient to always launch it as R then your solution is briefer but it is subsumed in the one I posted which handles it in full generality. Its really a matter of usage case at this point. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] loading multiple CSV files into a single data frame
On Thu, May 3, 2012 at 2:07 PM, victor jimenez betaband...@gmail.com wrote: Sometimes I have hundreds of CSV files scattered in a directory tree, resulting from experiments' executions. For instance, giving an example from my field, I may want to collect the performance of a processor for several design parameters such as cache size (possible values: 2, 4, 8 and 16) and cache associativity (possible values: direct-mapped, 4-way, fully-associative). The results of all these experiments will be stored in a directory tree like: results |-- direct-mapped | |-- 2 -- data.csv | |-- 4 -- data.csv | |-- 8 -- data.csv | |-- 16 -- data.csv |-- 4-way | |-- 2 -- data.csv | |-- 4 -- data.csv ... |-- fully-associative | |-- 2 -- data.csv | |-- 4 -- data.csv ... I am developing a package that would allow me to gather all those CSV into a single data frame. Currently, I just need to execute the following statement: dframe - gather(results/@ASSOC@/@SIZE@/data.csv) and this command returns a data frame containing the columns ASSOC, SIZE and all the remaining columns inside the CSV files (in my case the processor performance), effectively loading all the CSV files into a single data frame. So, I would get something like: ASSOC, SIZE, PERF direct-mapped, 2, 1.4 direct-mapped, 4, 1.6 direct-mapped, 8, 1.7 direct-mapped, 16, 1.7 4-way, 2, 1.4 4-way, 4, 1.5 ... I would like to ask whether there is any similar functionality already implemented in R. If so, there is no need to reinvent the wheel :) If it is not implemented and the R community believes that this feature would be useful, I would be glad to contribute my code. If your csv files all have the same columns and represent time series then read.zoo in the zoo package can read multiple csv files in at once using a single read.zoo command producing a single zoo object. library(zoo) ?read.zoo vignette(zoo-read) Also see the other zoo vignettes and help files. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with args
On Sat, Apr 21, 2012 at 1:38 PM, Simon Urbanek
simon.urba...@r-project.org wrote:
On Apr 21, 2012, at 1:03 PM, Gabor Grothendieck wrote:
args ought to check that its argument is a function:
max - 3
args(max)
NULL
e.g.
args - function(name) {
+ name - match.fun(name)
+ base::args(name)
+ }
args(max)
function (..., na.rm = FALSE)
NULL
You may want to read the docs in the first place:
Value:
[...]
'NULL' in case of a non-function.
My post wasn't about the return value -- it was about the fact that
the function name can be masked. Try the example I posted. I also
posted a solution.
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with args
On Sat, Apr 21, 2012 at 2:10 PM, Simon Urbanek
simon.urba...@r-project.org wrote:
On Apr 21, 2012, at 1:45 PM, Gabor Grothendieck wrote:
On Sat, Apr 21, 2012 at 1:38 PM, Simon Urbanek
simon.urba...@r-project.org wrote:
On Apr 21, 2012, at 1:03 PM, Gabor Grothendieck wrote:
args ought to check that its argument is a function:
max - 3
args(max)
NULL
e.g.
args - function(name) {
+ name - match.fun(name)
+ base::args(name)
+ }
args(max)
function (..., na.rm = FALSE)
NULL
You may want to read the docs in the first place:
Value:
[...]
'NULL' in case of a non-function.
My post wasn't about the return value -- it was about the fact that the
function name can be masked. Try the example I posted. I also posted a
solution.
You're passing a non-function (the value of 3) so, obviously you get NULL. I
think you're confusing function calls with values. What you probably intended
was
That's only a workaround but it does not address the problem that args
ought not to work that way. args can gather all the information
needed to fetch the correct object but doesn't. The second example
shows how it should work.
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
On Sat, Mar 31, 2012 at 9:57 AM, Paul Gilbert pgilbert...@gmail.com wrote: Mark I would like to clarify two specific points. On 12-03-31 04:41 AM, mark.braving...@csiro.au wrote: ... Someone has subsequently decided that code should look a certain way, and has added a check that isn't in the language itself-- but they haven't thought of everything, and of course they never could. There is a large overlap between people writing the checks and people writing the interpreter. Even though your code may have been working, if your understanding of the language definition is not consistent with that of the people writing the interpreter, there is no guarantee that it will continue to work, and in some cases the way in which it fails could be that it produces spurious results. I am inclined to think of code checks as an additional way to be sure my understanding of the R language is close to that of the people writing the interpreter. The point is that it has been historically possible to push R in different directions even without the blessing of the core team but if its locked down too tightly then we lose that facility and its that loss or potential loss that is worrying. The idea of the package system is that it should be possible to extend R without having to modify the core of R itself. It depends on how Notes are being interpreted, which from this thread is no longer clear. The R-core line used to be Notes are just notes but now we seem to have significant Notes and ... My understanding, and I think that of a few other people, was incorrect, in I don't think so. I think it was changed on us and I think it ought to be changed back. Some people on this thread seem to be framing this as a quality issue but its nothing of the sort. The specifics cited make it clear that the current handling of Notes is not improving the quality of any package but is potentially causing thousands of package developers needless work on packages that have been working for years. If the Notes are just there to be helpful that is one thing but changing the idea of Notes so that an undefined subset of them are arbitrarily imposed at the whim of the R core group is what is objectionable. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
On Wed, Mar 28, 2012 at 11:52 PM, Thomas Lumley tlum...@uw.edu wrote: On Thu, Mar 29, 2012 at 3:30 AM, Gabor Grothendieck ggrothendi...@gmail.com wrote: 2012/3/28 Uwe Ligges lig...@statistik.tu-dortmund.de: On 27.03.2012 20:33, Jeffrey Ryan wrote: Thanks Uwe for the clarification on what goes and what stays. Still fuzzy on the notion of significant though. Do you have an example or two for the list? We have to look at those notes again and again in order to find if something important is noted, hence please always try to avoid all notes unless the effect is really intended! Consider the Note No visible binding for global variable We cannot know if your code intends to use such a global variable (which is undesirable in most cases), hence would let is pass if it seems to be sensible. Another Note such as empty section or partial argument match can quickly be fixed, hence just do it and don't waste our time. Best, Uwe Ligges What is the point of notes vs warnings if you have to get rid of both of them? Furthermore, if there are notes that you don't have to get rid of its not fair that package developers should have to waste their time on things that are actually acceptable. Finally, it makes the whole system arbitrary since packages can be rejected based on undefined rules. The notes are precisely the things for which clear rules can't be written. They are reported by CMD check because they are usually signs of coding errors, but are not warnings because their use is sometimes justified. The 'No visible binding for global variable is a good example. This found some bugs in my 'survey' package, which I removed. There is still one note of this type, which arises when I have to handle two different versions of the hexbin package with different internal structures. The note is a false positive because the use is guarded by an if(), but CMD check can't tell this. So, it's a good idea to remove all Notes that can be removed without introducing other code problems, which is nearly all of them, but occasionally there may be a good reason for code that produces a Note. But if you want a simple, unambiguous, mechanical rule for *your* packages, just eliminate all Notes. I think it would be more objective and also easiest for everyone if notes were accepted. It might be that over time some notes could be split into multiple cases some of which are warnings and others continue to be notes. That way package developers don't have to waste their time on getting rid of notes which don't matter and the CRAN maintainers can turn the task of reviewing notes over to the computer. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
2012/3/28 Uwe Ligges lig...@statistik.tu-dortmund.de: On 27.03.2012 20:33, Jeffrey Ryan wrote: Thanks Uwe for the clarification on what goes and what stays. Still fuzzy on the notion of significant though. Do you have an example or two for the list? We have to look at those notes again and again in order to find if something important is noted, hence please always try to avoid all notes unless the effect is really intended! Consider the Note No visible binding for global variable We cannot know if your code intends to use such a global variable (which is undesirable in most cases), hence would let is pass if it seems to be sensible. Another Note such as empty section or partial argument match can quickly be fixed, hence just do it and don't waste our time. Best, Uwe Ligges What is the point of notes vs warnings if you have to get rid of both of them? Furthermore, if there are notes that you don't have to get rid of its not fair that package developers should have to waste their time on things that are actually acceptable. Finally, it makes the whole system arbitrary since packages can be rejected based on undefined rules. Either divide notes into significant notes and ordinary notes and clearly label them as such in the output of R CMD check or else make the significant notes warnings so one can know in advance whether the package passes R CMD check or not. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
On Tue, Mar 27, 2012 at 7:52 AM, Prof Brian Ripley rip...@stats.ox.ac.uk wrote: CRAN has for some time had a policies page at http://cran.r-project.org/web/packages/policies.html and we would like to draw this to the attention of package maintainers. In particular, please - always send a submission email to c...@r-project.org with the package name and version on the subject line. Emails sent to individual members of the team will result in delays at best. - run R CMD check --as-cran on the tarball before you submit it. Do this with the latest version of R possible: definitely R 2.14.2, preferably R 2.15.0 RC or a recent R-devel. (Later versions of R are able to give better diagnostics, e.g. for compiled code and especially on Windows. They may also have extra checks for recently uncovered problems.) Also, please note that CRAN has a very heavy workload (186 packages were published last week) and to remain viable needs package maintainers to make its life as easy as possible. Regarding the part about warnings or significant notes in that page, its impossible to know which notes are significant and which ones are not significant except by trial and error. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
2012/3/27 Uwe Ligges lig...@statistik.tu-dortmund.de: On 27.03.2012 17:09, Gabor Grothendieck wrote: On Tue, Mar 27, 2012 at 7:52 AM, Prof Brian Ripley rip...@stats.ox.ac.uk wrote: CRAN has for some time had a policies page at http://cran.r-project.org/web/packages/policies.html and we would like to draw this to the attention of package maintainers. In particular, please - always send a submission email to c...@r-project.org with the package name and version on the subject line. Emails sent to individual members of the team will result in delays at best. - run R CMD check --as-cran on the tarball before you submit it. Do this with the latest version of R possible: definitely R 2.14.2, preferably R 2.15.0 RC or a recent R-devel. (Later versions of R are able to give better diagnostics, e.g. for compiled code and especially on Windows. They may also have extra checks for recently uncovered problems.) Also, please note that CRAN has a very heavy workload (186 packages were published last week) and to remain viable needs package maintainers to make its life as easy as possible. Regarding the part about warnings or significant notes in that page, its impossible to know which notes are significant and which ones are not significant except by trial and error. Right, it needs human inspection to identify false positives. We believe most package maintainers are able to see if he or she is hit by such a false positive. The problem is that a note is generated and the note is correct. Its not a false positive. But that does not tell you whether its significant or not. There is no way to know. One can either try to remove all notes (which may not be feasible) or just upload it and by trial and error find out if its accepted or not. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
2012/3/27 Uwe Ligges lig...@statistik.tu-dortmund.de: On 27.03.2012 19:10, Jeffrey Ryan wrote: Is there a distinction as to NOTE vs. WARNING that is documented? I've always assumed (wrongly?) that NOTES weren't an issue with publishing on CRAN, but that they may change to WARNINGS at some point. We won't kick packages off CRAN for Notes (but we will if Warnings are not fixed), but we may not accept new submissions with significant Notes. Yes, I understand that but that does not really address the problem that one has no idea of whether a Note is significant or not so the only way to determine its significance is to submit your package and see if its accepted or not. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why is there no within.environment function?
On Wed, Mar 21, 2012 at 5:51 PM, Richard Cotton richiero...@gmail.com wrote:
If I want to assign some variables into an environment, it seems
natural to do something like
e - new.env()
within(e,
{
x - 1:5
y - runif(5)
}
)
This throws an error, since within.environment doesn't exist. I
realise I can work around it using
'with' already does that:
e - new.env()
with(e, {
x - 1.5
y - runif(5)
})
ls(e) # lists x and y
Also since proto objects are environments this works:
library(proto)
p - proto(x = 1.5, y = runif(5))
p$ls() # lists x and y
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] hash table clean-up
On Sun, Mar 4, 2012 at 4:19 PM, luke-tier...@uiowa.edu wrote:
On Sun, 4 Mar 2012, Florent D. wrote:
Hello,
I have noticed that the memory usage inside an R session increases as
more and more objects with unique names are created, even after they
are removed. Here is a small reproducible example:
gc()
used (Mb) gc trigger (Mb) max used (Mb)
Ncells 531720 14.2 899071 24.1 818163 21.9
Vcells 247949 1.9 786432 6.0 641735 4.9
for (i in 1:10) {
+ name - paste(x, runif(1), sep=)
+ assign(name, NULL)
+ rm(list=name)
+ rm(name)
}
gc()
used (Mb) gc trigger (Mb) max used (Mb)
Ncells 831714 22.3 1368491 36.6 1265230 33.8
Vcells 680551 5.2 1300721 10.0 969572 7.4
It appears the increase in memory usage is due to the way R's
environment hash table operates
(http://cran.r-project.org/doc/manuals/R-ints.html#Hash-table): as
objects with new names are created, new entries are made in the hash
table; but when the objects are removed from the environment, the
corresponding entries are not deleted.
Your analysis is incorrect. What you are seeing is the fact that thea
symbol or name objects used as keys are being added to the global
symbol table and that is not garbage collected. I believe that too
many internals rely on this for it to be changed any time soon. It
may be possible to have some symbols GC protected and others not, but
again that would require very careful throught and implementation and
isn't likely to be a priority anty time soon as far as I can see.
There may be some value in having hash tables that use some form of
uninterned symbols as keys at some point but that is a larger project
that might be better provided by a contributed package, at least
initially.
Does this apply to lists too or just environments?
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tcltk GUIs (was need gui matrix editor: does R Core team have advice on how?)
On Sun, Jan 29, 2012 at 7:10 AM, Prof Brian Ripley rip...@stats.ox.ac.uk wrote: On 28/01/2012 22:04, John Fox wrote: Dear Paul and Gabor, The Rcmdr GUI uses the tcltk package, so I have some experience with providing an R tcltk-based GUI for various platforms. As Gabor says, everything works very smoothly on Windows because the R Windows binary includes Tcl/Tk. Maybe, but getting it there was very far from smooth. Tcl/Tk compiled under the compilers we used, but the resulting DLLs crashed R. No one has ever found the cause and I used the system SDK (essentiallly a version of VC++) to build them. And that puts us in a bind since the current system SDKs generate code depending on DLLs that are not part of the minimal OS versions we support (e.g. Windows XP and Server 2003, and the machine used to build was retired 2 years ago). On Mac OS X, it's necessary for the user to install Tcl/Tk for X Windows and to insure that X Windows is installed (as it typically is in recent releases of Mac OS X). In my experience, most Linux users already have Tcl/Tk and X Windows (or if they don't, they're familiar with how to install software on their systems), so that things work smoothly there as well. The upshot of this is that Mac OS X is the platform that seems to generate the most problems for naive users, although installing Tcl/Tk for X Windows isn't that difficult. Take a look, e.g., at the Rcmdr installation notes http://socserv.socsci.mcmaster.ca/jfox/Misc/Rcmdr/installation-notes.html. If this were really a problem it could be resolved with far less effort than was needed on Windows. The X11 version of Tk is only needed to get R's tcltk to play under R.app. For those wanting a Tk-based front end for command-line R, it is easy to build R against the Tcl/Tk which ships with OS X (or an update of it) and get fully Aqua-themed widgets. If I want to show Rcmdr to a Mac user, that is what I use. As various recent threads on R-sig-mac show, some useRs are capable of misconfiguring their Macs so that X11 does not work, does not find any fonts ... but maybe they could manage the same on any other Unix-alike. Although it would be ideal if the tcltk package just worked out of the box on every platform so that cross platform GUIs just worked if that is too difficult to manage it would still be helpful if tcl without tk just worked on every platform out of the box for other applications not involving GUIs but still involving tcl. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] need gui matrix editor: does R Core team have advice on how?
On Sat, Jan 28, 2012 at 2:59 PM, Paul Johnson pauljoh...@gmail.com wrote: Dear R-devel: Would R core team consider endorsing a graphical toolkit and trying to facilitate development of little GUI tools? I need a gui matrix editor for users that want to be able to write matrices that are later used to simulate data. Instead of teaching them to write a covariance matrix (for example, for mvtnorm), I want to tell them run a function that pops up a table they can fill in. The users need to be able to enter variable names in the matrix, so something that would accept a 0 0 0 b 0 c d e would be great. Something that would accept formulae like this would be even more great. a 0 0 0 b a^2 c d e I want this gui matrix editor to just work on Windows, Mac, Linux. I don't mind building this on top of some widget set, but it is important that the widget set be easily installable on the user end. That's why I wish R core would offer us some guidance or advice. I'm not a programmer, but I can learn to program with a library, as long as it is not a waste of time. I've been searching R archives and here's what I found so far. 1. tcl/tk Building on R tcltk2, for people that have the Tcl addon widget TkTable installed, there are several packages. in tcltk2 itself, there is a function tk2edit, and there are others that try to embellish. I've tried several of these, they seem to be not-quite done yet, one can't copy a rectangle, for example. But maybe I could learn how to fix them up and make yet another tktable based editor. Problem: requires user to have enough understanding to install the Tcl widget TkTable. And, for platforms like Windows, user has to install tcl/tk itself. Regarding Windows, both the tcltk R package and tcl/tk itself are included with R for Windows and work out of the box without doing anything special. You can use addTclPath(libdir) to add additional locations to the tcl library search path so you can include additional tcl/tk packages in your R package and in conjunction with system.file(..., package = myPackage) you can have them automatically accessed without the user having to do anything special. Also you can use all or nearly all of tcl's facilities including sourcing your own tcl code and you can issue tcl commands one by one from R too using the facilities of the tcltk package. There are also various other R packages that build on top of tcltk. I too think that a standard R installation should ensure that tcltk just works out of the box but that seems not to be the case for every R distribution although it is true for some (possibly most) including the standard Windows distribution. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN link broken
On Fri, Dec 30, 2011 at 4:32 PM, Paul Gilbert pgilbert...@gmail.com wrote: The packages link on CRAN (http://cran.at.r-project.org/) seems to be broken. Paul Object not found! The requested URL was not found on this server. The link on the referring pagehttp://cran.at.r-project.org/navbar.html seems to be wrong or outdated. Please inform the author of that page http://cran.at.r-project.org/navbar.html about the error. If you think this is a server error, please contact the webmaster mailto:%5bno%20address%20given%5d. Error 404 cran.at.r-project.orghttp://cran.at.r-project.org/ Fri Dec 30 22:20:48 2011 Apache/2.2.21 (Debian) Presumably this will propagate to the mirrors shortly, as well, if it has not happened already. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Standardizing included packages
It seems that R is mostly distributed with the tcltk package but not always. Is there some reason for this inconsistency? It would be nice if one could count on those packages that are distributed on the Windows version of R being distributed on all other platforms too. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to deal with package conflicts
On Fri, Nov 25, 2011 at 10:37 AM, Terry Therneau thern...@mayo.edu wrote: On Fri, 2011-11-25 at 09:50 -0500, Duncan Murdoch wrote: I think the general idea in formulas is that it is up to the user to define the meaning of functions used in them. Normally the user has attached the package that is working on the formula, so the package author can provide useful things like s(), but if a user wanted to redefine s() to their own function, that should be possible. Formulas do have environments attached, so both variables and functions should be looked up there. I don't agree that this is the best way. A function like coxph could easily have in its documentation a list of the formula specials that it defines internally. If the user want something of their own they can easily use a different word. In fact, I would strongly recommend that they don't use one of these key names. For things that work across mutiple packages like ns(), what user in his right mind would redefine it? So I re-raise the question. Is there a reasonably simple way to make the survival ridge() function specific to survival formulas? It sets up structures that have no meaning anywhere else, and its global definition stands in the way of other sensible uses. Having it be not exported + obey namespace type sematics would be a plus all around. Philosophical aside: I have discovered to my dismay that formulas do have environments attached, and that variables/functions are looked up there. This made sensible semantics for predict() within a function impossible for some of the survival functions, unless I were to change all the routines to a model=TRUE default. (And a change of that magnitude to survival, with its long list of dependencies, is not fun to contemplate. A very quick survey reveals several dependent packages will break.) So I don't agree nearly so fully with the should part of your last sentence. The out of context evaluations allowed by environments are, I find, always tricky and often lead to intricate special cases. Thus, moving back and forth between how it seems that a formula should work, and how it actually does work, sometimes leaves my head spinning. The dynlm package uses formula functions which are specific to it. Look at its code. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] extending the colClasses argument in read.table
2011/11/21 Romain François rom...@r-enthusiasts.com:
Hello,
We've released the int64 package to CRAN a few days ago. The package
provides S4 classes int64 and uint64 that represent signed and unsigned
64 bit integer vectors.
One further development of the package is to facilitate reading 64 bit
integer data from csv, etc ... files.
I have this function that wraps a call to read.csv to:
- read the int64 and uint64 columns as character
- converts them afterwards to the appropriate type
Try this:
library(int64)
Lines - A\n12\n
setAs(character, int64, function(from) as.int64(from))
DF - read.csv(textConnection(Lines), colClasses = int64)
str(DF)
'data.frame': 1 obs. of 1 variable:
$ A:Formal class 'int64' [package int64] with 2 slots
.. ..@ .Data:List of 1
.. .. ..$ : int 0 12
.. ..@ NAMES: NULL
To convince ourselves that its translating from character to int64:
setAs(character, int64, function(from) {print(class(from));
as.int64(from)})
DF - read.csv(textConnection(Lines), colClasses = int64)
[1] character
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] One step way to create data frame with variable variable names?
On Fri, Nov 11, 2011 at 10:25 AM, Paul Johnson pauljoh...@gmail.com wrote: Suppose plotx - someName modx - otherName plotxRange - c(10,20) modxVals - c(1,2,3) It often happens I want to create a dataframe or object with plotx or modx as the variable names. But can't understand syntax to do that. I can get this done in 2 steps, creating the data frame and then assigning names, as in newdf - data.frame( c(1, 2, 3, 4), c(4, 4, 4, 4)) colnames(newdf) - c(plotx, modx) I was trying to hit this in one step, but can't find how. If I could get this in one step, it would simplify some book keeping, because this current method requires me to build up the name vector to match newdf, and sometimes I make mistakes. After the data.frame already exists, I understand I can insert new variables using the variable names with syntax like newdf[[plotx]] - c(23, 23, 23, 23) Try this: newdf - setNames(data.frame( c(1, 2, 3, 4), c(4, 4, 4, 4)), c(plotx, modx)) -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAMESPACE file generation issue R 2.14.0 on Debian Squeeze
2011/11/8 Uwe Ligges lig...@statistik.tu-dortmund.de: On 08.11.2011 19:08, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 17:56, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 17:04, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 16:31, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: I think many people like to help, but we cannot: You say you are under R-2.14.0 and whn you R CMD INSTALL a package with that version of R, it does not have a NAMESPACE in the end? Then - your R installation is broken or - you are looking into a library where you have old versios of the packages or - you belive you are using R-2.14.0 but you are actually using an older version. This is even reproduced on CRAN. All platforms work except one: http://cran.r-project.org/web/checks/check_results_sqldf.html No, that one is completely unrelated (and already solved, but not yet synced to CRAN master) to the original question you have removed in your reply. OK. One would have thought that the checks on CRAN would be consistent with the package pages which link to them. I only see consistent information on that page. If you go to: http://cran.r-project.org/web/packages/sqldf/index.html then the tar.gz file was created using R-2.14.0 but if you then click on the check results link on the same page it takes you to this: Yes. the tar.gz was created with R-2.14.0. http://cran.r-project.org/web/checks/check_results_sqldf.html On the last link on that page it says ERROR and if click on that it takes you to the output of the check which reveals that it was run with R 2.13.2. Yes, ince it is checked with different flavors of R, R-oldrelease, R-release, R-devel. See the first column! A source package can be created with an version of R and checked under another version. There is onlyone source package on CRAN, but - just as an exmaple - binaries for R-2.13.x and R-2.14.x. Of course, the checks are applied with the versions stated on the check page. I think you haven't got the whole point of checking with different versions of R. The Version column on check_results_sqldf.html page refers to the package's version, not the R version. To get the R version you must know to click on each link. No, no, no, no! See the first column! It definitely states if R-olrelease, R-release, R-pacthed or R-devel is used! OK. That wasn't clear. It would be better if it actually identified the release as R 2.13.2, etc. We do not want to change those fields daily: R-devel and R-patched typically change from day to day - and then things will really become inconsistent in some place. The inconsistencies are less important if they are obvious but more important if they are not. How about indicating R-2.14.0 but not the (2011-09-30 r57179) part. That only changes a few times a year. Also it would be helpful if the R version number that was used to build the .tar.gz file and the .zip file were shown right on the package's CRAN page. This entire discussion and all the associated confusion probably would not have occurred since it would be much clearer which versions were involved. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAMESPACE file generation issue R 2.14.0 on Debian Squeeze
2011/11/9 Uwe Ligges lig...@statistik.tu-dortmund.de: On 09.11.2011 13:52, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 19:08, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 17:56, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 17:04, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 16:31, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: I think many people like to help, but we cannot: You say you are under R-2.14.0 and whn you R CMD INSTALL a package with that version of R, it does not have a NAMESPACE in the end? Then - your R installation is broken or - you are looking into a library where you have old versios of the packages or - you belive you are using R-2.14.0 but you are actually using an older version. This is even reproduced on CRAN. All platforms work except one: http://cran.r-project.org/web/checks/check_results_sqldf.html No, that one is completely unrelated (and already solved, but not yet synced to CRAN master) to the original question you have removed in your reply. OK. One would have thought that the checks on CRAN would be consistent with the package pages which link to them. I only see consistent information on that page. If you go to: http://cran.r-project.org/web/packages/sqldf/index.html then the tar.gz file was created using R-2.14.0 but if you then click on the check results link on the same page it takes you to this: Yes. the tar.gz was created with R-2.14.0. http://cran.r-project.org/web/checks/check_results_sqldf.html On the last link on that page it says ERROR and if click on that it takes you to the output of the check which reveals that it was run with R 2.13.2. Yes, ince it is checked with different flavors of R, R-oldrelease, R-release, R-devel. See the first column! A source package can be created with an version of R and checked under another version. There is onlyone source package on CRAN, but - just as an exmaple - binaries for R-2.13.x and R-2.14.x. Of course, the checks are applied with the versions stated on the check page. I think you haven't got the whole point of checking with different versions of R. The Version column on check_results_sqldf.html page refers to the package's version, not the R version. To get the R version you must know to click on each link. No, no, no, no! See the first column! It definitely states if R-olrelease, R-release, R-pacthed or R-devel is used! OK. That wasn't clear. It would be better if it actually identified the release as R 2.13.2, etc. We do not want to change those fields daily: R-devel and R-patched typically change from day to day - and then things will really become inconsistent in some place. The inconsistencies are less important if they are obvious but more important if they are not. How about indicating R-2.14.0 but not the (2011-09-30 r57179) part. Honestly, that (svn revision) is the only part that we do not have on the front pages but they are given in the log files. The R version is not on the package's CRAN page, e.g. http://cran.r-project.org/web/packages/sqldf/index.html I was thinking of something like this for the Package source line: Package built source:sqldf_0.4-3.tar.gz (built with R version 2.14.0 Patched (2011-10-10 r12345) This seems important since that line truly is not the source but is the built source. The actual source is not uploaded to CRAN or shown. A transformation has been applied to it so rightfully that should be tracked back via the R version. This would make it very clear not only which version of the R package you are dealing with but which version of R built it and that can in certain circumstances be important for precisely identifying it. This could also be done for the .zip file, etc. shown on that page. If that level of detail is not feasible then this would be next best (just showing the R x.y.z version): Package built source: sqldf_0.4-3.tar.gz (built with R version 2.14.0) -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAMESPACE file generation issue R 2.14.0 on Debian Squeeze
2011/11/9 Uwe Ligges lig...@statistik.tu-dortmund.de: Honestly, that (svn revision) is the only part that we do not have on the front pages but they are given in the log files. The R version is not on the package's CRAN page, e.g. http://cran.r-project.org/web/packages/sqldf/index.html I was thinking of something like this for the Package source line: Package built source: sqldf_0.4-3.tar.gz (built with R version 2.14.0 Patched (2011-10-10 r12345) Not relevant for the majority of cases. Version number of the package is relevant, not the R used to build it (well, there are cornercases, e.g. for knowing which version was used to generate the vignette). The point is that the answer to the poster's question does not really resolve it except for that one person. To really solve the problem the process needs to be changed so that its unlikely to occur again. And in addition, we to not have the information. Where do you think we can get that from? Even if we change R to provide the information now, we'd only know if it was built with R = 2.14.0 or later. Yes, I realize that but it would have to be added during the build process in the same way that certain other information is added already. This seems important since that line truly is not the source but is the built source. The actual source is not uploaded to CRAN or shown. He? What is the difference between the source and the built source? A source package has always undergone R CMD build on the submitters machine. We do only have only one kind of source packages on CRAN. The built source has been processed by R CMD build and the true source has not. What CRAN labels the source is not the true source but is really the built source. There has been a transformation applied to the true source to get the built source and some version of R was used to do that. Furthermore, what the result looks like can depend on what version of R was used for this. That its different for different versions of R was one of the things that precipitated this entire thread. A transformation has been applied to it Where and why do you want to apply transformations? By transformation I am referring to the existing process of transforming the true source to the built source. I was not suggesting other transformations (other than the fact that it implies that it would be necessary to identify the R version that built any given built source in the built source itself). so rightfully that should be tracked back via the R version. This would make it very clear not only which version of the R package you are dealing with but which version of R built it and that can in certain circumstances be important for precisely identifying it. This could also be done for the .zip file, etc. shown on that page. The zip file shown *there* is always R-release or R-patched (hence currently R-2.14.0 given your request) for ALL packages. We do not list zip files for non R-release *there*. I thought you were still talking about the check page. Originally I was referring to the check page but then expanded it to the main page as well since it seemed relevant in both places. I find this whole area is confusing (and clearly I am not the only one hence this thread) and it could use some clarification right on the web pages themselves to avoid these sorts of problems. I think the most desirable from a user's viewpoint is to actually stick the R version right there but if its not feasible some other way of addressing this would be nice. If that level of detail is not feasible then this would be next best (just showing the R x.y.z version): Package built source: sqldf_0.4-3.tar.gz (built with R version 2.14.0) I give up. uwe -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAMESPACE file generation issue R 2.14.0 on Debian Squeeze
2011/11/8 Uwe Ligges lig...@statistik.tu-dortmund.de: I think many people like to help, but we cannot: You say you are under R-2.14.0 and whn you R CMD INSTALL a package with that version of R, it does not have a NAMESPACE in the end? Then - your R installation is broken or - you are looking into a library where you have old versios of the packages or - you belive you are using R-2.14.0 but you are actually using an older version. This is even reproduced on CRAN. All platforms work except one: http://cran.r-project.org/web/checks/check_results_sqldf.html -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAMESPACE file generation issue R 2.14.0 on Debian Squeeze
On Tue, Nov 8, 2011 at 10:31 AM, Gabor Grothendieck ggrothendi...@gmail.com wrote: 2011/11/8 Uwe Ligges lig...@statistik.tu-dortmund.de: I think many people like to help, but we cannot: You say you are under R-2.14.0 and whn you R CMD INSTALL a package with that version of R, it does not have a NAMESPACE in the end? Then - your R installation is broken or - you are looking into a library where you have old versios of the packages or - you belive you are using R-2.14.0 but you are actually using an older version. This is even reproduced on CRAN. All platforms work except one: http://cran.r-project.org/web/checks/check_results_sqldf.html HIt send by mistake. I understand that its being fixed already on CRAN for that platform. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAMESPACE file generation issue R 2.14.0 on Debian Squeeze
2011/11/8 Uwe Ligges lig...@statistik.tu-dortmund.de: On 08.11.2011 16:31, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: I think many people like to help, but we cannot: You say you are under R-2.14.0 and whn you R CMD INSTALL a package with that version of R, it does not have a NAMESPACE in the end? Then - your R installation is broken or - you are looking into a library where you have old versios of the packages or - you belive you are using R-2.14.0 but you are actually using an older version. This is even reproduced on CRAN. All platforms work except one: http://cran.r-project.org/web/checks/check_results_sqldf.html No, that one is completely unrelated (and already solved, but not yet synced to CRAN master) to the original question you have removed in your reply. OK. One would have thought that the checks on CRAN would be consistent with the package pages which link to them. The summary table at check_results_sqldf.html does not actually give the version that is being tested so its only by clicking each of the links on the summary table that one would uncover this inconsistency. Regarding quoting, the mail server seems to reject posts from gmail for all sorts of unknown reasons and quoting large posts very well might be one of them so one has to be extremely careful. For a while (this is some time ago) I was unable to post at all but over time learned that if I was sure to bottom rather than top post and not quote too much then it would get through. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAMESPACE file generation issue R 2.14.0 on Debian Squeeze
2011/11/8 Uwe Ligges lig...@statistik.tu-dortmund.de: On 08.11.2011 17:04, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 16:31, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: I think many people like to help, but we cannot: You say you are under R-2.14.0 and whn you R CMD INSTALL a package with that version of R, it does not have a NAMESPACE in the end? Then - your R installation is broken or - you are looking into a library where you have old versios of the packages or - you belive you are using R-2.14.0 but you are actually using an older version. This is even reproduced on CRAN. All platforms work except one: http://cran.r-project.org/web/checks/check_results_sqldf.html No, that one is completely unrelated (and already solved, but not yet synced to CRAN master) to the original question you have removed in your reply. OK. One would have thought that the checks on CRAN would be consistent with the package pages which link to them. I only see consistent information on that page. If you go to: http://cran.r-project.org/web/packages/sqldf/index.html then the tar.gz file was created using R-2.14.0 but if you then click on the check results link on the same page it takes you to this: http://cran.r-project.org/web/checks/check_results_sqldf.html On the last link on that page it says ERROR and if click on that it takes you to the output of the check which reveals that it was run with R 2.13.2. The Version column on check_results_sqldf.html page refers to the package's version, not the R version. To get the R version you must know to click on each link. If its feasible in terms of effort and run time to add the R version used in a column on the check_results_sqldf.html page then that would make the summary page more useful since it would be immediately apparent not only what version of the package is being used but also what version of R is being used in each case. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAMESPACE file generation issue R 2.14.0 on Debian Squeeze
2011/11/8 Uwe Ligges lig...@statistik.tu-dortmund.de: On 08.11.2011 17:56, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 17:04, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 16:31, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: I think many people like to help, but we cannot: You say you are under R-2.14.0 and whn you R CMD INSTALL a package with that version of R, it does not have a NAMESPACE in the end? Then - your R installation is broken or - you are looking into a library where you have old versios of the packages or - you belive you are using R-2.14.0 but you are actually using an older version. This is even reproduced on CRAN. All platforms work except one: http://cran.r-project.org/web/checks/check_results_sqldf.html No, that one is completely unrelated (and already solved, but not yet synced to CRAN master) to the original question you have removed in your reply. OK. One would have thought that the checks on CRAN would be consistent with the package pages which link to them. I only see consistent information on that page. If you go to: http://cran.r-project.org/web/packages/sqldf/index.html then the tar.gz file was created using R-2.14.0 but if you then click on the check results link on the same page it takes you to this: Yes. the tar.gz was created with R-2.14.0. http://cran.r-project.org/web/checks/check_results_sqldf.html On the last link on that page it says ERROR and if click on that it takes you to the output of the check which reveals that it was run with R 2.13.2. Yes, ince it is checked with different flavors of R, R-oldrelease, R-release, R-devel. See the first column! A source package can be created with an version of R and checked under another version. There is onlyone source package on CRAN, but - just as an exmaple - binaries for R-2.13.x and R-2.14.x. Of course, the checks are applied with the versions stated on the check page. I think you haven't got the whole point of checking with different versions of R. The Version column on check_results_sqldf.html page refers to the package's version, not the R version. To get the R version you must know to click on each link. No, no, no, no! See the first column! It definitely states if R-olrelease, R-release, R-pacthed or R-devel is used! OK. That wasn't clear. It would be better if it actually identified the release as R 2.13.2, etc. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error message library()
On Fri, Oct 28, 2011 at 6:49 AM, Renaud Gaujoux ren...@mancala.cbio.uct.ac.za wrote: BTW: an ever more intuitive solution (IMHO) would be to auto-complete package names in library( ... Deepayan?;) That is non-intrusive and in line with the general use of R. (Simon) This is indeed a long wanted feature and to my surprise it actually already exists!!! (seems that Deepayan did not tell anybody about it ;) ) The help page ?completion in the utils package explains how to enable it: utils::rc.settings(ipck=TRUE) It simply worked on my Ubuntu box -- and directly went in my .Rprofile :) Hope this helps. Also in terms of what exists now, on Windows the Packages Load Package menu on Rgui provides a gui interface to library() from which one chooses the package from a list so one can't ask for one that does not exist. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error message library()
On Wed, Oct 26, 2011 at 5:46 AM, ONKELINX, Thierry thierry.onkel...@inbo.be wrote: Dear all, When one tries to load a non-installed package you get the error: Error in library(xyz) : there is no package called 'xyz' I noticed on several occasions that this puzzles beginners. Therefore I suggest to change the error description in: Error in library(xyz) : there is no package called 'xyz' installed on this machine. Check the name of the package or use install.packages(xyz) to install it. Best regards, Perhaps it could report where it looked and couldn't find it: There is no package called 'xyz' in C:/R/win-library/2.13 and C:/R/R-2.13.2/library -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error message library()
On Thu, Oct 27, 2011 at 2:10 PM, Milan Bouchet-Valat nalimi...@club.fr wrote: Le jeudi 27 octobre 2011 à 13:45 -0400, Gabor Grothendieck a écrit : Perhaps it could report where it looked and couldn't find it: There is no package called 'xyz' in C:/R/win-library/2.13 and C:/R/R-2.13.2/library I think it would be even more scary for beginners, and advanced users probably know how to find their library path. Many beginners are advanced but just don't know R. Its better to give them the information they need. With this they can discover what is there even without knowing the relevant R commands. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] control list gotcha
On Sat, Sep 10, 2011 at 12:31 PM, John C Nash nas...@uottawa.ca wrote: This is mainly a reminder to others developing R packages to be careful not to supply control list items that are not used by the called package. Optimx is a wrapper package that aims to provide a common syntax to a number of existing optimization packages. Recently in extending optimx package I inadvertently introduced a new control for optimx which is NOT in any of the wrapped optimization packages. There are probably other methods of keeping things tidy, but I copy the control list and null out unwanted elements for each of the called packages. I missed this in a couple of places in the R-forge development version of optimx (Iam working on fixing these, but they are still there at the moment). The nasty here was that the package mostly works, with plausible but not very good results for some of the optimizers. If it crashed and burned, it would have been noticed sooner. There is also a potential interaction with a use of the dot-dot-dot variable to pass scaling information. If there are ideas on how to quickly reveal errors related to calling sequences involving control lists and ..., I'd welcome them (off-list?), and be prepared to summarize findings in a vignette. Suppose we wish to call f with the control.list components plus those in the default.args not already specified in the control.list. If any such arg is not an arg of f exclude it: # test data - f, default.args and control.list f - function(a, b, c = 0, d = 1) print(match.call()) default.args - list(a = 2, b = 1) control.list - list(a = 1, d = 2, e = 3) # override default.args with control.list use.args - modifyList(default.args, control.list) # exclude components of use.args that are not args of f sel - names(use.args) %in% names(as.list(args(f))) final.args - use.args[sel] # run f do.call(f, final.args) The last line gives: do.call(f, final.args) f(a = 1, b = 1, d = 2) -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is xtable still being maintained?
On Sat, Sep 10, 2011 at 1:19 PM, oliver oli...@first.in-berlin.de wrote: On Sat, Sep 10, 2011 at 07:40:24AM -0700, Spencer Graves wrote: On 9/10/2011 6:06 AM, Uwe Ligges wrote: On 10.09.2011 13:26, Alastair wrote: Hi, I wonder if anyone knows if the xtable package is still actively being maintained? The last update to the CRAN was about 2 years ago. Earlier in the year I found I wanted to use the short caption option of LaTeX tables to display an abridged title in my table of contents. It was a relatively simple change to get xtable to support this. I bundled up my changes and sent the maintainer David B. Dahl an email and I got absolutely no response? Try to ping - at least I do so in this case. No response would be unfortunate, of course. David B. Dahl still has a web site as an Associate Professor at Texas AM U. What's the etiquette for this kind of situation? I think he's done a sterling job maintaining a really useful package; I wanted to help and contribute to the community but if he's not doing it anymore how can anyone get their improvements / bug fixes into circulation? xtable's DESCRIPTION file says License: GPL (= 2) so go ahead in case you do not get a response. Best, Uwe Ligges xtable has a long list of reverse depends, imports, suggests and enhances, so many people clearly think it's useful. My preference is to encourage the maintainer(s) to migrate the project to R-Forge where others can help maintain it and add [...] AFAIK xtable was also there available, but looking it up via search function it seems not to be the case. So I may have mixed up it with a different package... hmhhh ah, I think it was zoo-package. Hmhh, yes, I think zoo... and the r-forge zoo-package allows rollapply() also on any data type, wheras the older r-cran zoo only allowed rollapply() to zoo-dataytpe (at lkeast at that time when I compared both packages). That has since become the CRAN version of zoo: library(zoo) rollapply(1:10, 3, sum) [1] 6 9 12 15 18 21 24 27 packageVersion(zoo) [1] ‘1.7.4’ -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problems with r-help
I am getting messages like this whenever I try to post to r-help. The message seems to say that the problem is with on the r-help end (the recipient domain). Delivery to the following recipient failed permanently: r-h...@r-project.org Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550-Callout verification failed: 550 550 5.7.1 Mail from 129.132.202.242 refused - see http://www.orbitrbl.com/ (state 14). -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems with r-help
On Tue, Aug 30, 2011 at 11:42 AM, Gabor Grothendieck ggrothendi...@gmail.com wrote: I am getting messages like this whenever I try to post to r-help. The message seems to say that the problem is with on the r-help end (the recipient domain). Delivery to the following recipient failed permanently: r-h...@r-project.org Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550-Callout verification failed: 550 550 5.7.1 Mail from 129.132.202.242 refused - see http://www.orbitrbl.com/ (state 14). It seems this was temporary since I was just able to post a test message and an actual message to r-help. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAMESPACE
On Sun, Jul 17, 2011 at 7:58 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 11-07-16 10:13 PM, Gabor Grothendieck wrote: Packages without explicit ‘NAMESPACE’ files will have a default one created at build or INSTALL time, so all packages will have namespaces. A consequence of this is that ‘.First.lib’ functions need to be renamed, usually as ‘.onLoad’ but sometimes as ‘.onAttach’. Couldn't R simply regard .First.lib as the appropriate function to save many packages from being needlessly changed? It is doing that (see today's version of the NEWS), but the problem is that it may choose the wrong one. If your package requires initialization then yourpkg::somefun only works if the initialization happens in .onLoad. But some packages only work if the initialization happens when the package is attached. It's better for the author to make the choice than for R to do it automatically. OK. Thanks. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] NAMESPACE
Packages without explicit ‘NAMESPACE’ files will have a default one created at build or INSTALL time, so all packages will have namespaces. A consequence of this is that ‘.First.lib’ functions need to be renamed, usually as ‘.onLoad’ but sometimes as ‘.onAttach’. Couldn't R simply regard .First.lib as the appropriate function to save many packages from being needlessly changed? -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Default values in control list of function
On Sat, Jun 25, 2011 at 9:21 PM, Prof. John C Nash nas...@uottawa.ca wrote:
In building a function for a package, I'd like to set the defaults in a
control list,
e.g.,
makeg-function(parameters, eps = 1.0e-7, control=list(showwork=TRUE,
rubbish=1.0e+101)){
etc.
}
This does not provide showwork or rubbish within the function if control() is
not fully
specified. Copying others, I've previously set the control defaults within
the function
then matched names, and that certainly works. I'm happy to keep using that
approach, but
would like to have a pointer to good practice for doing this (I'm prepared to
write or
help write a short tutorial if none exists).
I can understand that trying to do the default replacement at a second or
greater level
could give problems. A search through the language definition and some
googling didn't
show up any obvious warning about this, but I'm sure there are some comments
somewhere.
Can anyone suggest some URLs?
One gets used to the nicety of being able to specify defaults and forgets
that even R has
some limits.
See ?modifyList
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Require of gWidgetsRGtk2 fails: RGtk2.dll can't be found, but it's there
On Fri, Jun 10, 2011 at 6:04 AM, Janko Thyson janko.thyson.rst...@googlemail.com wrote: Dear list, I've been trying to get gWidgets/gWidgetsRGtk2 to run every other month for a while, but somehow I simply can't figure out what's going wrong. 1. Use the automatically installed GTk2, not some other version. 2. Note that the automatically installed one will be at ...\GTk2-runtime\bin and that will be put at the *end* of your PATH. Change it so that its at the beginning of your PATH to be sure its not picking up something else. 3. If you are changing the path through the control panel and starting R from the command line note that your new path won't be picked up in old command line sessions so start a new command line session to start R. 4. When you start a new R session double check that the automatically installed ...\GTk2-runtime\bin is at the beginning of your path: strsplit(Sys.getenv(PATH), ;)[[1]] -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Require of gWidgetsRGtk2 fails: RGtk2.dll can't be found, but it's there
On Fri, Jun 10, 2011 at 8:31 AM, Janko Thyson janko.thyson.rst...@googlemail.com wrote: On 10.06.2011 13:00, Gabor Grothendieck wrote: On Fri, Jun 10, 2011 at 6:04 AM, Janko Thyson janko.thyson.rst...@googlemail.com wrote: Dear list, I've been trying to get gWidgets/gWidgetsRGtk2 to run every other month for a while, but somehow I simply can't figure out what's going wrong. 1. Use the automatically installed GTk2, not some other version. Thanks for answering. I didn't even know there GTk2 already ships with R. Prof. Brian Ripley linked me to the readme file with recommendations with respect to an GTK2 distribution to use: What it means is that RGtk2.dll or one of the DLLs it depends on cannot be found. See the instructions at http://cran.r-project.org/bin/windows/contrib/2.13/@ReadMe 2. Note that the automatically installed one will be at ...\GTk2-runtime\bin and that will be put at the *end* of your PATH. Change it so that its at the beginning of your PATH to be sure its not picking up something else. My R distribution does not seem to have such a directory (standard windows R-2.13.0 installer from CRAN) How do I manage to have this ...\GTk2-runtime\bin directory available? #1 is referring to the fact that when you run RGTk2 it will ask you if you want it to install GTk2. Say yes and let it install that version to be sure you are using the right one. If you install it yourself manually instead you could very easily install the wrong version. The only problem with the automatic installation is that it puts the GTk2 dll's at the end of your PATH so you can't be sure that something else on your path (such as graphviz which has its own potentially conflicting dll's) won't interfere. To fix that change the PATH so that GTk2 is at the beginning (or at least before anything else that could interere). Thanks a lot, Janko 3. If you are changing the path through the control panel and starting R from the command line note that your new path won't be picked up in old command line sessions so start a new command line session to start R. 4. When you start a new R session double check that the automatically installed ...\GTk2-runtime\bin is at the beginning of your path: strsplit(Sys.getenv(PATH), ;)[[1]] -- Janko Thyson janko.thy...@googlemail.com Jesuitenstraße 3 D-85049 Ingolstadt Mobile: +49 (0)176 83294257 This e-mail and any attachment is for authorized use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Packages for R-CRAN (organizing aspects)
On Tue, Jun 7, 2011 at 9:03 AM, oliver oli...@first.in-berlin.de wrote: Hello, I have some ideas for packages that I want to provide on R-CRAN. One package alreads is working, but I have some warnings in when compiling. Also I don't know if the libraries in use are only working on Unix/Linux. So I have some general questions: - If I'm not sure if the code would also work on windows (needing some ceratain libraries or tools), would it be better to mark it as Unix-like only? Would other people, who are interested in using the package on Windows, then look for the other issues? (I'm just interested in providing the functionality, and I don't use Windows, so compatibility would not be my main goal, if it's using certain libraries; but if the code is not relying on certain libs or tools I of course write code ANSI-conform, so that it *should* compile on windows too.) I mean: I just want to have the work for Unix/Linux, but in general like the platform-independent approach. I just have no interest, looking at the windows side too much. Are there people from R-CRAN team, who help at that point to make things available on many platforms? - I have in mind packages for reading a lot of different files / fileformat. How to name them? it would be consequent to name them read.fileformat but I'm not sure if this naming style is reserved for OO-methods only, and that topic I will learn later in detail, so that at the moment I just would provide the raw functionality. Maybe the name of the reading function should then better be named readfilefomat or fileformatread ? - There are a lot of different fileformats that I want to read in. Would it be better to make for each format one different package, or rather put them all together as a package Readmisc? For example the following formats I have in mind: - jpeg (libjpeg62) = already working, I want to clean up the code and documentation soon and then provide on R-CRAN Note existence of read.jpeg in the rimage package, read.gif in the caTools package and readPNG in the png package. - bvh (maybe (f)lex or yacc or pcre) = want to start this soon - apachelogfile /maybe using pcre) = starting date not planned - some other formats also - Other package ideas: rolling application (which uses R's built in types, not like zoo() using special types) rollapply and related functions in the development version of zoo do work with ordinary vectors and matrices: # install development version of zoo install.packages(zoo, repos = http://r-forge.r-project.org;) library(zoo) rollmean(1:10, 2) [1] 1.5 2.5 3.5 4.5 5.5 6.5 7.5 8.5 9.5 rollapply(1:10, 2, sum) [1] 3 5 7 9 11 13 15 17 19 rollmean(1:10, 2) [1] 1.5 2.5 3.5 4.5 5.5 6.5 7.5 8.5 9.5 rollapply(cbind(a = 1:10, b = 11:20), 3, sum) a b [1,] 6 36 [2,] 9 39 [3,] 12 42 [4,] 15 45 [5,] 18 48 [6,] 21 51 [7,] 24 54 [8,] 27 57 -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Packages for R-CRAN (organizing aspects)
On Tue, Jun 7, 2011 at 12:00 PM, oliver oli...@first.in-berlin.de wrote: What about the documentation. if I look for it on r-cran, but the module is form r-forge there will be a mismatch. ?, vignette(...) and library(help=...) will give help that corresponds to the package you installed. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
On Wed, May 4, 2011 at 8:11 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 11-05-03 11:25 PM, Yihui Xie wrote: 1. Few Windows users use these commands does not imply they are not useful, and I have no idea how many Windows users really use them. How do you run R CMD build when you build R packages under Windows? You don't write C:/Program Files/R/R-2.13.0/bin/i386/R.exe CMD build, do you? I have unusual needs, because I use 2 or 3 different versions of R every day. But if you're interested, the way I do it is to set up shell commands that reset the PATH appropriate to the version of R I want to use. A more usual user who always wants to use just one version from the command line could modify the PATH appropriately. I don't object to that, I just object to having R do it to unsuspecting users, because as Simon said, messing with the PATH can cause problems, and it's difficult for the R installer to know if messing with yours will cause trouble for you. In another message you asked about using Sweave. I almost never use Sweave() in R or R CMD Sweave at the command line; I have an appropriate command configured into my editors, and I run it from there. The PATH does not need to be involved. I think the reason we have to mess with the PATH variable for each single software package is that Windows is Not Unix, so you may hate Windows instead of a package that modifies your PATH variable. For the choice of i386 and x64, you can let the user decide which bin path to use. I believe the number of users who frequently switch back and forth is fairly small. I already pointed out why that is inappropriate for a lot of users. The batchfiles handle this using Rversions.bat. Without arguments it lists the available R versions and with an argument it makes that the current version of R so that Rgui.bat, R.bat, invoke that version. Rversions.bat works by running the appropriate RSetReg.exe utility (which is a utility that is included in every R distribution). Of course if you just want to run a specific version of Rgui each version has a separate icon on the desktop so one can select the version of interest that way too. I personally keep about half a dozen back versions of R for the reasons others have mentioned and these would include one R-13.x version, one R-12.x version, etc. I literally use x in the name since only the most recent version in any such series is stored. That is, when a new R-2.13.x comes out I just install it over the existing R-2.13.x: Directory of C:\Program Files\R 31/03/2010 02:37 PMDIR R-2.10.x 01/06/2010 01:03 PMDIR R-2.11.x 22/03/2011 03:25 PMDIR R-2.12.x 26/04/2011 01:45 PMDIR R-2.13.x -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Curry: proposed new functional programming, er, function.
On Wed, May 4, 2011 at 10:40 AM, Ravi Varadhan rvarad...@jhmi.edu wrote:
I too would like this (being an Indian!).
Here is an example that came up just yesterday with regards to solving a
quadrature problem using the cubature package. The adaptIntegrate function
does not allow additional arguments via ...
Uwe suggested a work around, but `Curry' would solve it nicely (and it also
tastes better!):
Curry = function(FUN,...) {
.orig = list(...)
function(...) do.call(FUN,c(.orig, list(...)))
}
require(cubature)
f - function(x, a) cos(2*pi*x*a) # a simple test function
# this works
a - 0.2
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2)
# but this doesn't work
rm(a)
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2, a=0.2)
# Use of Curry
adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)
Here is another approach. If we preface any function with gsubfn's fn$
then it will turn formulas (subject to certain rules to determine
which to pay attention to) into functions.
1. Here it is applied to the cubature example
library(cubature)
library(gsubfn)
Loading required package: proto
fn$adaptIntegrate(~ f(x, 0.2), lower=0, upper=2)
$integral
[1] 0.4677446
$error
[1] 1.247382e-14
$functionEvaluations
[1] 15
$returnCode
[1] 0
2. and here is the heatmap example redone. The example line is to
compute x so that the code is self contained:
library(gsubfn)
example(heatmap)
fn$heatmap(x, hclustfun = ~ hclust(x, method=average))
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
On Wed, May 4, 2011 at 11:15 AM, Yihui Xie x...@yihui.name wrote: If I am already able to open R, there is no need to post the request here. I want to be able to run R without knowing where it is from another software package. Your batch files fit in this purpose, and the only problem is it is a little bit slower since it takes time to look for R in the system via several approaches. Not on my laptop (which is not particularly powerful). Rgui.bat brings up R nearly instantaneously. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
On Wed, May 4, 2011 at 10:53 AM, Ted Byers r.ted.by...@gmail.com wrote: -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r- project.org] On Behalf Of Gabor Grothendieck Sent: May-04-11 10:35 AM To: Duncan Murdoch Cc: R-devel Subject: Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows [snip] I personally keep about half a dozen back versions of R for the reasons others have mentioned and these would include one R-13.x version, one R- 12.x version, etc. I literally use x in the name since only the most recent version in any such series is stored. That is, when a new R-2.13.x comes out I just install it over the existing R-2.13.x: Directory of C:\Program Files\R 31/03/2010 02:37 PM DIR R-2.10.x 01/06/2010 01:03 PM DIR R-2.11.x 22/03/2011 03:25 PM DIR R-2.12.x 26/04/2011 01:45 PM DIR R-2.13.x Do you keep the RTools version specific to each version of R installed too? If so, how do you manage that so that each version of R finds the right version of RTools when it needs it? I don't use RTools much, but I need it to install some fo the packages I use from source since there are no binary distributions for them (for 64 bit Windows). I don't typically keep any more than two versions of R on my machine at any one time, but I don't remove an older version until I have verified that my R scripts work fine in the latest release. So usually there is only one version on my machine, but there will be two for a short while after a new release. But, my normal practice, as I describe here, would be disrupted if R's installer wrote R's bin path to my system path (in fact, I hate that for any software I use, even though in some cases there's no way to avoid it). Thanks Ted Typically I do my development on the latest version of R so I only need one version of Rtools. The older versions of R are just for checking older software. There is a program RtoolsVersion.bat in the batchfiles that will tell you which version of Rtools you have (which it finds by first looking in the registry and if not found there looks for an R_TOOLS environment variable and if still not found looks for C:\Rtools): C:\tmp2RtoolsVersion RtoolsVersion.bat: Rtools found at: c:\Rtools Rtools version 2.13.0.1901 (There is also Rtools.bat that will temporarily add Rtools to your path (although if you use Rcmd.bat, R.bat, etc. then they can find Rtools without it being on the path so mostly one does not need to use Rtools.bat). If people wanted to have multiple versions of Rtools, Rtools would ideally have a tool similar to R's own RSetReg.exe . Another possibility would be to turn Rtools into an R package so that R's library mechanism handled the versioning. Regarding permanently putting R on the path, I agree that it would be annoying having R permanently there and for that reason the batchfiles do not do that. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Curry: proposed new functional programming, er, function.
On Wed, May 4, 2011 at 1:11 PM, Sharpie ch...@sharpsteen.net wrote: Currently, the only Curry implementation I know of is in the roxygen package which is kind of a weird dependency to install just for this one function. Not entirely comparable but the proto package supports currying of proto arguments. For example, p$ls returns an instantiatedProtoMethod which is an S3 subclass of function that is like the original method but with the first argument filled in: library(proto) p - proto(x = 1) p$ls() [1] x -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
On Tue, May 3, 2011 at 7:44 PM, Yihui Xie x...@yihui.name wrote: Hi, I guess this issue must have been brought forward long time ago, but I still hope you can consider under Windows (during installation): 1. put R's bin path in the PATH variable of the system so that we can use the commands R and Rscript more easily; 2. remove the version string like R-2.13.0 in the default installation directory, e.g. only use a directory like C:/Program Files/R/ instead of C:/Program Files/R/R-2.13.0/; I know many people just follow the default setting when installing R, and this version string will often lead to many (unnecessary) copies of R in the system and brings difficulty to the first issue (several possible bin directories); I'm aware of some existing efforts in overcoming the difficulty of calling R under Windows like the R batch files project (http://code.google.com/p/batchfiles/), but I believe this is better to be solved in R directly. The above seems very awkward. If you want to do it temporarily each time you use R its going to be MUCH slower than using batch files since you will have to start up R and then run an R program. To do it permanently implies mucking with your system settings and leaving it in a changed state and that seems worse than the batch file approach which requires no such permanent change. Your (2) is unnecessary using the batch files since they automatically find R regardless of what you name the directory. In other situations if you want to set the path using R you already need to know the path to R in order to run R in the first place and if you know the path to R in order to run it why do you need to set the path? -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
On Tue, May 3, 2011 at 7:44 PM, Yihui Xie x...@yihui.name wrote: Hi, I guess this issue must have been brought forward long time ago, but I still hope you can consider under Windows (during installation): 1. put R's bin path in the PATH variable of the system so that we can use the commands R and Rscript more easily; 2. remove the version string like R-2.13.0 in the default installation directory, e.g. only use a directory like C:/Program Files/R/ instead of C:/Program Files/R/R-2.13.0/; I know many people just follow the default setting when installing R, and this version string will often lead to many (unnecessary) copies of R in the system and brings difficulty to the first issue (several possible bin directories); I'm aware of some existing efforts in overcoming the difficulty of calling R under Windows like the R batch files project (http://code.google.com/p/batchfiles/), but I believe this is better to be solved in R directly. Although I have some misgivings about this just to be sure we have all based covered I have placed an R package called cmd in the batchfiles download area (go to http://batchfiles.googlecode.com and click on download tab). Install the package and then every time you wish to use R.exe, Rscript.exe, etc. start up R and run library(cmd) cmd32() # or cmd64() and it will spawn a Windows console session with the appropriate path variable set. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
On Wed, May 4, 2011 at 1:04 AM, Yihui Xie x...@yihui.name wrote: Thanks! But I'm sorry this is not what I wanted. I just hope we can call R as a command like we do under *nix -- this will make it easier for *other* software packages to find R. You asked for an R program that gives the ability to run R.exe, Rscript.exe, etc. from the command line and that indeed is what it enables in the spawned session. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using substitute to access the expression related to a promise
On Mon, May 2, 2011 at 9:53 AM, Hadley Wickham had...@rice.edu wrote:
Hi all,
The help for delayedAssign suggests that you can use substitute to
access the expression associated with a promise, and the help for
substitute says: If it is a promise object, i.e., a formal argument
to a function or explicitly created using ‘delayedAssign()’, the
expression slot of the promise replaces the symbol.
But this doesn't seem to work:
a - 1
b - 2
delayedAssign(x, {message(assigning...); a + b})
substitute(x)
x
x
[1] 3
Is this a bug in substitute?
sessionInfo()
R version 2.13.0 (2011-04-13)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
It works differently if the assign environment is the global
environment or not. This is actually mentioned on the help page for
substitute though its precise meaning may not be completely clear from
the wording.
Try this:
e - new.env()
delayedAssign(x, {message(assigning...); a + b},, e)
substitute(x, e)
{
message(assigning...)
a + b
}
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using substitute to access the expression related to a promise
On Mon, May 2, 2011 at 10:10 AM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
On 02/05/2011 9:53 AM, Hadley Wickham wrote:
Hi all,
The help for delayedAssign suggests that you can use substitute to
access the expression associated with a promise, and the help for
substitute says: If it is a promise object, i.e., a formal argument
to a function or explicitly created using ‘delayedAssign()’, the
expression slot of the promise replaces the symbol.
But this doesn't seem to work:
a- 1
b- 2
delayedAssign(x, {message(assigning...); a + b})
substitute(x)
x
x
[1] 3
Is this a bug in substitute?
I think it is a design flaw rather than a bug: the global environment is
handled specially. If you put those lines into a function you'll see
different behaviour. I think if you really carefully read the documentation
you'll find it says this.
I suggested regularizing this several years ago, but there were worries that
it would break some common usage.
Duncan Murdoch
Perhaps an argument could be added to indicate whether the global
environment was treated specially or not. If it defaulted to the
current behavior it would still be backwardly compatible.
The other limitation that I have come across here is the asymmetry of
being able to extract the data of the promise but not the environment.
Being able to copy a promise without evaluating it is another
operation that would be nice. Currently one can only do these two
things at the C level.
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Capturing the expression representing the body of a function
On Mon, May 2, 2011 at 4:11 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote:
On 02/05/2011 3:21 PM, Hadley Wickham wrote:
Hi all,
What's the preferred way of capturing the expression representing the
contents of a function?
* body(write.csv) gives me a braced expression
* body(write.csv)[-1] gives me a mangled call
* as.list(body(write.csv)[-1]) gives me a list of calls
* as.expression(as.list(body(write.csv)[-1])) is what I want but seems
like too much work
Any suggestions?
The body of a function isn't an expression, it's a language object. A
language object is represented internally as a pairlist, while an expression
is represented as a generic vector, i.e. the thing that list() gives.
Your 1st try gives you the language object.
The other ones only work when the body consists of a call to `{`, as the
body of most complex functions does, but not for simple ones like
f - function(x) 2*x
So I would say your question should be: What's the best way to construct
an expression vector s.t. evaluating its elements in order is like
evaluating the body of a function?
And the answer to that is something like
body2expr - function(f) {
body - body(f)
if (typeof(body) == language identical(body[[1]], quote(`{`)))
as.expression(as.list(body[-1]))
else as.expression(body)
}
Also try as.expression(as.list(f)[[3]])
e.g.
f - function(x, y) { x + y }
as.expression(as.list(f)[[3]])
expression({
x + y
})
g - function(x, y) x + y
as.expression(as.list(g)[[3]])
expression(x + y)
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] error while checking package size during Rcmd check
I am receiving this message during
Rcmd check proto-3.9.2.tar.gz
using R version 2.13.0 Patched (2011-04-25 r55638)
* checking installed package size ...Error in if (total 1024 * 5) { : missing
value where TRUE/FALSE needed
Execution halted
I don't get this under R.2.12.x. The size of the tar.gz file is under
600K. What causes this or if its too hard to tell from the message
how can I investigate it further?
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] error while checking package size during Rcmd check
On Thu, Apr 28, 2011 at 9:01 PM, Gabor Grothendieck
ggrothendi...@gmail.com wrote:
I am receiving this message during
Rcmd check proto-3.9.2.tar.gz
using R version 2.13.0 Patched (2011-04-25 r55638)
* checking installed package size ...Error in if (total 1024 * 5) { :
missing
value where TRUE/FALSE needed
Execution halted
I don't get this under R.2.12.x. The size of the tar.gz file is under
600K. What causes this or if its too hard to tell from the message
how can I investigate it further?
Also I am using Windows Vista; however, I just found that by upgrading
to the latest Rtools the problem disappears.
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish R Core had a standard format (or generic function) for newdata objects
On Wed, Apr 27, 2011 at 3:55 AM, peter dalgaard pda...@gmail.com wrote: On Apr 27, 2011, at 02:39 , Duncan Murdoch wrote: On 26/04/2011 11:13 AM, Paul Johnson wrote: Is anybody working on a way to standardize the creation of newdata objects for predict methods? [snip] I think it is time the R Core Team would look at this tell us what is the right way to do this. I think the interface to setx in Zelig is pretty easy to understand, at least for numeric variables. If you don't like the way this was done in my three lines above, or by Frank Harrell, or the Zelig group, or John Fox, why don't you do it yourself, and get it right this time? It's pretty rude to complain about things that others have given you for free, and demand they do it better. Er... No, I don't think Paul is being particularly rude here (and he has been doing us some substantial favors in the past, notably his useful Rtips page). I know the kind of functionality he is looking for; e.g., SAS JMP has some rather nice interactive displays of regression effects for which you'll need to fill in something for the other variables. However, that being said, I agree with Duncan that we probably do not want to canonicalize any particular method of filling in average values for data frame variables. Whatever you do will be statistically dubious (in particular, using the mode of a factor variable gives me the creeps: Do a subgroup analysis and your average person switches from male to female?), so I think it is one of those cases where it is best to provide mechanism, not policy. That could be satisfied by defining a generic in the core of R without any methods. Then individual packages or analyses could provide those in the way they see fit. As long as the packages or analyses are working with objects of different classes they would not conflict. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD Sweave versus Sweave() on Windows
On Thu, Apr 21, 2011 at 6:44 AM, Pfaff, Bernhard Dr.
bernhard_pf...@fra.invesco.com wrote:
Dear list subscriber,
I am quite puzzled by the behaviour of processing Sweave files within an R
session, i.e.
Sweave(foo.Rnw) versus R CMD Sweave foo.Rnw
In the former the environmental variable 'SWEAVE_STYLEPATH_DEFAULT = TRUE' is
obeyed (this is set in etc/Renviron.site as well as under the users home
directory in .Renviron). That is the hard-coded path to Sweave.sty is
included in the resultant tex-file, whereas if the Sweave file is processed
from cmd.exe as R CMD Sweave foo.Rnw, only \usepackage{Sweave} is included.
Any pointers are much appreciated.
Best,
Bernhard
Output of sessionInfo():
sessionInfo()
R version 2.13.0 (2011-04-13)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=German_Germany.1252 LC_CTYPE=German_Germany.1252
[3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C
[5] LC_TIME=German_Germany.1252
attached base packages:
[1] stats graphics datasets grDevices utils methods base
other attached packages:
[1] fortunes_1.4-1
SWEAVE_STYLEPATH_DEFAULT is automatically set in Sweave.bat found here
(its part of the batchfiles distribution but does not require any
other batch file in order to run it):
http://batchfiles.googlecode.com/svn/trunk/Sweave.bat
This was only just added and has not been tested yet but if anyone
would like to try it just put it anywhere on your Windows PATH (or
current directory) and issue a command like this from the Windows
console:
Sweave myfile.Rnw
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] help with eval()
On Mon, Apr 18, 2011 at 5:51 PM, Terry Therneau thern...@mayo.edu wrote:
I've narrowed my scope problems with predict.coxph further.
Here is a condensed example:
fcall3 - as.formula(time ~ age)
dfun3 - function(dcall) {
fit - lm(dcall, data=lung, model=FALSE)
model.frame(fit)
}
dfun3(fcall3)
The final call fails: it can't find 'dcall'.
The relevant code in model.frame.lm is:
env - environment(formula$terms)
if (is.null(env))
env - parent.frame()
eval(fcall, env, parent.frame())
If the environment of the formula is .Globalenv, as it is here, the
contents of parent.frame() are ignored. Adding a
print(ls(parent.frame()))
statement just above the final call shows that it isn't a scope issue:
the variables we want are there.
I don't understand the logic behind looking for variables in the place
the formula was first typed (this is not a complaint). The inability to
look elsewhere however has stymied my efforts to fix the scoping problem
in predict.coxph, unless I drop the env(formula) argument alltogether.
But I assume there must be good reasons for it's inclusion and am
reluctant to do so.
Try using do.call. Using the built in BOD to illustrate, we first try
the posted code to view the error:
fcall3 - as.formula(demand ~ Time)
dfun3 - function(dcall) {
+ fit - lm(dcall, data=BOD, model=FALSE)
+ model.frame(fit)
+ }
dfun3(fcall3)
Error in model.frame(formula = dcall, data = BOD, drop.unused.levels = TRUE) :
object 'dcall' not found
# now replace the lm call with a do.call(lm ...)
# so that dcall gets substituted before the call to lm:
fcall3 - as.formula(demand ~ Time)
dfun3 - function(dcall) {
+ fit - do.call(lm, list(dcall, data = BOD, model = FALSE))
+ model.frame(fit)
+ }
dfun3(fcall3)
demand Time
18.31
2 10.32
3 19.03
4 16.04
5 15.65
6 19.87
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rtools questions
On Sat, Apr 9, 2011 at 4:40 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 11-04-06 2:45 PM, Henrik Bengtsson wrote: On Wed, Apr 6, 2011 at 4:54 AM, Duncan Murdochmurdoch.dun...@gmail.com wrote: On 11-04-05 7:51 PM, Henrik Bengtsson wrote: On Tue, Apr 5, 2011 at 3:44 PM, Duncan Murdochmurdoch.dun...@gmail.com wrote: On 11-04-05 6:22 PM, Spencer Graves wrote: Hello: 1. How can I tell when the development version of Rtools has changed? I don't make announcements of the changes, you just need to check the web site. There are online tools that can do this for you automatically, but I don't know which one to recommend. Google suggests lots of them. I also asked myself this before and I must admit it took me a while to interpret the contents of the webpage. There are multiple sections, e.g. 'Changes since R 2.12.2', 'Changes since R 2.11.1', 'Changes since R 2.11.0', and so on. Then within each section there are some dates mentioned. Given my current R version (say R 2.13.0 beta) and Rtools (Rtools213.exe), it not fully clear to me which section to look at, e.g. 'Changes since R 2.12.2'? Well, that depends on when you downloaded it. I use the R version releases as bookmarks. If you last downloaded Rtools after the release of R 2.12.2, then you only need to look at the last section. The problem with collecting changes into those that apply to each Rtools version is just that the change lists would be longer: Rtools212 will get changes through several R releases. When there are compiler changes, RtoolsXYZ generally comes out during the previous R version, because the compiler may only work with the R-devel version. For instance, Rtools212 was introduced between R 2.11.0 and 2.11.1 and was updated a number of times up to quite recently. (It is now frozen, so if you download it now and are working with the R versions it supports you never need to worry about updates to it.) I understand, and I suspected this was the reason too. However, if you want to reformat the page, go ahead, and send me the new version. It's a hand edited HTML page so I'd be happy to incorporate changes that make it more readable, as long as it's still easy to edit by hand. Gabor asked how to know which version was downloaded. If you have the installer file you can tell: right click on it, choose Properties, look at the Version tab. If you didn't keep the installer, I don't know a way to find out, but it might be recorded in the unins000.dat file that the uninstaller uses. Of course, without downloading the new one you can't find out its version: so back to my original suggestion to monitor changes to the web page. I'll see if there's a way to automatically include the revision number in the filename. This is useful - I didn't know about this version number of InnoSetup. I've browsed the online InnoSetup help, but I couldn't locate what the version parameter is called. With it, would it be possible to use a [Code] block having InnoSetup write the version number to a VERSION file in the Rtools installation directory? That would make it possible to compare what's online and what's installed. Another alternative for figuring out if Rtools have changed would be to compare the timestamp of the installed Rtools directory (because you typically install immediately after download) and the Rtools213.exe timestamp on the web server. This could be achieved by moving the files to, say, http://www.murdoch-sutherland.com/Rtools/download/ and enable indexing of files in that directory. Either way, know about the version number is certainly good enough for me. After installing Rtools, I can simply put the installer file in the Rtools directory to allow me to compare to it later. (I kind of did this before by comparing file sizes.) I've just uploaded a small change: now Rtools.txt records the version number (and if I remember to update it, you can download only that file to see if you are up to date). There's also a VERSION.txt file that contains the version number, which is likely to maintain its format more consistently, so if you want an automatic check, you should look at that file. It's also on the web site. Thanks. I have added a batch file to the batchfiles distribution (http://batchfiles.googlecode.com) which locates Rtools and then displays VERSION.txt . If placed on the Windows PATH then issuing this command from the Windows console with no arguments will display the VERSION.txt file: RtoolsVersion A direct link is to the file is here: http://batchfiles.googlecode.com/svn/trunk/RtoolsVersion.bat It finds Rtools from the registry or if not found there looks in C:\Rtools . -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list
