[Rd] guidelines on "depends" versus "suggests" and R versions
On the topic of when to use "suggests" and "depends" and on R version requirements. I have cc'd this message to R-devel because I am curious about what senior developpers think about these issues. The problem arises because we are using some functions from the package "matchit" in a new version of our package "portfolio". We are listing the matchit in "suggests" rather than "depends" becuase much of the package works without it. If a user wants the functionality which requires matchit functions, we prompt them to install it. Our problem is that when a user loads up matchit, it requires MASS and Zelig via depends. Moreover, Zelig itself requires MASS and boot. So, just to use our package portfolio, a user is now required to load up three packages even though, I think, only a single function from one of these packages it actually required. Kosuke Imai writes: > We have MASS and Zelig in there because some functions are borrowed from > those packages. The right way to handle this is only to make these packages as "suggests" rather than "depends" and then install them if needed, as you do correctly with optmatch. Note that Writing R Extensions says: "Packages that need to be attached to successfully load the package using library(pkgname) must be listed in the Depends field." Although this is not directlty on point, my interpretation is that you need a "good reason" to list a package in Depends rather than Suggests. > MASS is a standard package, and so i don't think it's a > big problem to require it. True. But is there some reason that this could not just be a suggest? > And, some of us including myself hope that > Zelig will become a standard package in the future! :) But it isn't yet. Moreover, if you really want this to happen there is a lot you should be doing with the code base, like test cases and S-4 classes and . . . . > As for the requirement of R 2.2.0, we do it simply because we only > test it against the most recent version of R. I do not *think* that this is the way cool package authors do things. (Nor do you yourself do it for Zelig.) It is easy to check (if you have test cases!) that a package works with the current version of R since checks are run on CRAN each day. > Some functions are not backward compatible because R is not > generally not backward compatible. R is amazingly backward compatible, I would say. I do not *think* that there is any reason why matchit requires anything prior to 2.0.0. By having a 2.2.0 requiremnt, you make it impossible for people using earlier versions of R to use the package. This is a problem for me because, if I want to use matchit, the same constraint will apply to *my* package. I think that the cool people handle this by ensuring that the package works with version X and then leaving that as constraint in depends. Since R automates the testing of packages, one can easily check that the package still works (if you have test cases!) as more versions of R come out. Now, there is a dilemma in that, as you fix/improve the package, you may not *know* for a fact that it *still* works with version X but the vast majority of things will. Major changes are highlighted in the release notes. Why does any of this whining matter to you? Well, if all of the above gets annoying enough, then other package authors like me will not bother to include matchit. We will just copy and paste the subset of the code that we want to use into our own package. This is not desirable but is allowed. We would prefer not to do this with our portfolio package, but we have users who are running R 2.1.0 that we want our package to work for . . . In any event, thanks for your time and for a useful piece of open source software. I am a big fan of matchit (and Zelig). The point of all the above is to make some suggestions that I *think* will result in wider use of the program. But, again, I am curious about what more senior/experienced R developpers think. Dave Kane __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (not just!) Windows R CMD build leftovers
Perhaps this earlier post slipped through the cracks? My apologies if
it's still 'in process', or I missed a response, or if the
contribution isn't helpful.
At any rate, I realized that the problem is not windows-specific.
Also, generating $libdir by calling (a sligthly modified) R_tempfile
might give installation more of a fighting chance in a cluttered TMPDIR.
Index: src/scripts/build.in
===
--- src/scripts/build.in(revision 36565)
+++ src/scripts/build.in(working copy)
@@ -76,7 +76,7 @@
my $R_platform = R_getenv("R_PLATFORM", "unknown-binary");
my $gzip = R_getenv("R_GZIPCMD", "gzip");
my $tar = R_getenv("TAR", "tar");
-my $libdir = &file_path(${R::Vars::TMPDIR}, "Rinst.$$");
+my $libdir = R_tempfile("Rinst.");
my $INSTALL_opts = "";
$INSTALL_opts .= " --use-zip" if $opt_use_zip;
@@ -434,6 +434,8 @@
if($doit && R_system($cmd)) {
$log->error();
$log->print("Installation failed.\n");
+ $log->print("Removing '$libdir'\n");
+ rmtree($libdir);
exit(1);
}
my $R_LIBS = $ENV{'R_LIBS'};
Index: share/perl/R/Utils.pm
===
--- share/perl/R/Utils.pm (revision 36565)
+++ share/perl/R/Utils.pm (working copy)
@@ -75,7 +75,7 @@
$pat . $$ . sprintf("%05d", rand(10**5)));
my $n=0;
-while(-f $retval){
+while(-e $retval){
$retval = file_path($R::Vars::TMPDIR,
$pat . $$ . sprintf("%05d", rand(10**5)));
croak "Cannot find unused name for temporary file"
Martin Morgan <[EMAIL PROTECTED]> writes:
> A command
>
> R CMD build
>
> that fails, e.g., because of C code compilation errors, leaves a
> directory %TMPDIR%/Rinst.xxx containing the file R.css. Although R
> CMD INSTALL --build cleans up after itself, build does not. A fix is
> below. Also, build.in references Rcmd.exe, which I thought was no
> longer necessary?
>
> Index: build.in
> ===
> --- build.in (revision 36450)
> +++ build.in (working copy)
> @@ -434,6 +434,8 @@
> if($doit && R_system($cmd)) {
> $log->error();
> $log->print("Installation failed.\n");
> + $log->print("Removing '$libdir'\n");
> + rmtree($libdir);
> exit(1);
> }
> my $R_LIBS = $ENV{'R_LIBS'};
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] import of Namespaces
My understanding is of your questions is below:
Matthias Kohl wrote:
> Dear R devels,
>
> let's say I have three packages "pkg1", "pkg2" and "pkg3" which all
> contain new S4 classes and methods. Where "pkg3" depends on "pkg2" and
> "pkg2" depends on "pkg1". Moreover, all three packages have namespaces.
>
> 1) I use ".onLoad <- function(lib, pkg) require(methods)". Do I also
> have to import the namespace of "methods" package?
No.
>
> 2) If I use import("pkg1") in the namespace of "pkg2", does this also
> (correctly) import the S4 classes and methods of "pkg1"? Or do I
> explicitly have to use importClassesFrom resp. importMethodsFrom?
Importing an entire package namespace will import all of the exported
classes/methods from "pkg1".
>
> 3) If I import the Namespace of "pkg2" in "pkg3", where the namespace of
> "pkg2" has import("pkg1") (or maybe importClassesFrom,
> importMethodsFrom) and I also want to use S4 classes and methods of
> "pkg1" in "pkg3". Is it sufficient to have import("pkg2") in the
> Namespace of "pkg3" or do I need import("pkg1") and import("pkg2")?
I believe you need to import each separately since the S4
classes/methods from "pkg1" will not be available to you simple because
you imported "pgk2" (i.e. I don't think the chain rule applies here).
>
> Many thanks for your help and advice
> Matthias
>
--
Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] tuned BLAS
I've been updating the information on tuned BLAS for R-admin in R-patched and R-devel. We have ATLAS (widely available, including for Windows) MKL (licensed on ix86 and x86_64 Linux and Windows) ACML(by AMD, but for all ix86 and x86_64 chips, Linux and Windows. Now available for gfortran.) Goto(academic use only, only some chips, only Linux) MKL and ACML provide full LAPACK, the other two some optimized LAPACK routines. (We have an MKL licence with our icc/ifort licences but it has not been delivered yet so I used a non-commercial Linux-only download. Hence I have not tried Windows.) On 32-bit Linux I used my dual Athlon 2600 MP desktop (about to be replaced). Goto no longer supports that chip, and ACML is not threaded (for gcc). ACML was a little faster than ATLAS, which was faster than MKL. However, MKL exploited the two processors to halve the elapsed time. MKL on that chip is poor on complex linear algehra. On 64-bit Linux I used a dual Athlon 248. Here the Goto BLAS was the fastest, but only just faster than ACML when using one CPU. ATLAS was slightly slower, and MKL perhaps 20% slower but good at exploiting 2 CPUs. This time it was not relatively slower at complex algebra. On Windows ACML is effective. I tested my laptop, a 2GHz Pentium M (such chips are far faster than their GHz would suggest). ACML outperformed ATLAS by 10-25%. These comparisons are biased as I have not compared MKL on Intel processors. That's lack of interest as all our current compute servers are AMD. The revelation was ACML: fast, easy to use even on Windows and completely gcc-compatible. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
