Re: [Rd] particulars of importing/loading libraries
Simon Urbanek writes:
> Oleg,
>
> On Jan 13, 2009, at 11:00 , Sklyar, Oleg (London) wrote:
>
>> Dear List:
>>
>> Sorry for posting maybe a trivial question, but I have a basic
>> understanding problem. If I have say pack1 and pack2, two R packages,
>> and pack2 depends on and imports pack1 fully (as in the code below),
>> is
>> there a way to make all the functionality of pack1 available for the
>> global and other environments (not only for the functions called from
>> withing pack2) by loading pack2 only? I thought if pack2 depends on
>> and
>> imports pack1 and essentially reexports everything, one should get the
>> full functionality simply by loading pack2. This does not seem to be
>> the
>> case or I am missing something trivial in my NAMESPACE/DESCRIPTION
>> files?
>>
>> If this is documented in Writing R Extensions, I would be thankful
>> for a
>> page number and maybe a quick fix in my example below as so far I have
>> not been able to find a clear explanation.
>>
>> The problem can be illustrated by the following simple example (this
>> is
>> a simple code for 2 packages, pack1 and pack2; plus an example).
>>
>
> if you bothered to use R CMD check you would find your bug right away:
> * checking package dependencies ... ERROR
> Namespace dependencies not required:
>pack1
>
> You simply forgot to add pack1 to the Depends: line - that's all. Once
> you fix that, you'll see what happens:
Imports: rather than Depends: seems like the norm -- the package then
controls its search path, rather than relying on the search path
constructed by the user, and avoids cluttering the user name space and
search path with unnecessary symbols. This would be especially true
for an infrastructure package with many symbols (e.g., RGtk2?) that
might well be irrelevant to an end user.
With Oleg's example, using Imports: allows the package to pass R CMD
check but results in the same error
> packageDescription("pack2")[c("Imports", "Depends")]
$Imports
[1] "pack1"
$Depends
[1] "R (>= 2.7.1), methods"
> as.POSIXct(pack1::testPosixVal)
Error in as.POSIXct.default(pack1::testPosixVal) :
do not know how to convert 'pack1::testPosixVal' to class "POSIXlt"
This can be remedied by adding exports(as.POSIXct) to the NAMESPACE
file of pack2.
I said above that the Imports: gives the package control of its search
path. This is true for regular symbols
> testPosixValue = "not a posix value"
> testPosix() # finds pack1's testPosixValue
[1] "2009-01-14 03:55:25 UTC"
[1] "POSIXt" "POSIXct"
[1] "2009-01-14 03:55:25 UTC"
so one might hope that if pack2 Imports: pack1, pack2 would always get
pack1's as.POSIXct methods. Alas, the user writing a method
setMethod("as.POSIXct", signature(x="posixTime"),
function(x, tz, ...) stop('oops'))
clobers pack2's efforts
> testPosix()
Error in as.POSIXct(testPosixVal) : oops
This occurs even when pack2 does not export as.POSIXct (niether method
nor generic), and would seem to be an unfortunate interaction between
methods and name spaces.
Martin
> > library(pack2)
> Loading required package: pack1
> > as.POSIXct(pack1::testPosixVal)
> [1] "2009-01-14 01:38:08 UTC"
>
> Cheers,
> S
>
>
>> Thank you for your replies.
>>
>> Dr Oleg Sklyar
>> Research Technologist
>> AHL / Man Investments Ltd
>> +44 (0)20 7144 3107
>> oskl...@maninvestments.com
>>
>> --- pack1: DESCRIPTION --
>> Package: pack1
>> Version: 0.0.1
>> Date: 12 Jan 2009
>> Title: pack1 to test S3/S4 methods compatibility
>> Author: Oleg Sklyar
>> Depends: R (>= 2.7.1), methods
>> Maintainer: Oleg Sklyar
>> Description: pack1
>> LazyLoad: yes
>> License: Proprietary
>> URL: http://www.maninvestments.com
>> LazyLoad: no
>>
>> --- pack1: NAMESPACE --
>> import(methods)
>> exportPattern("^[^\\.]")
>> exportClasses(posixTime)
>> exportMethods(as.POSIXct)
>>
>> --- pack1: posix.R --
>> setClass("posixTime", "numeric")
>>
>> setGeneric("as.POSIXct")
>> setMethod("as.POSIXct", signature(x="posixTime"),
>>function(x, tz) {
>>z = x...@.data
>>attr(z,"class") = c("POSIXt", "POSIXct")
>>attr(z,"tzone") = "UTC"
>>z
>>}
>> )
>>
>> testPosixVal = new("posixTime", as.numeric(Sys.time()))
>>
>> --- pack2: DESCRIPTION
>> Package: pack2
>> Version: 0.0.1
>> Date: 12 Jan 2009
>> Title: pack2 to test S3/S4 methods compatibility
>> Author: Oleg Sklyar
>> Depends: R (>= 2.7.1), methods
>> Maintainer: Oleg Sklyar
>> Description: pack2
>> LazyLoad: yes
>> License: Proprietary
>> URL: http://www.maninvestments.com
>> LazyLoad: no
>>
>> --- pack2: NAMESPACE --
>> import(pack1)
>> exportPattern("^[^\\.]")
>>
>> --- pack2: posix.R --
>> testPosix = function() {
>>z = as.POSIXct(testPosixVal)
>>print(z)
>>print(class(z))
>>z
>> }
>>
>> -- test code to run from global env, showing problems ---
>> require(pack2)
>>
>> ## use as.POSIXct imported into pack2 from pack1 to do the
>> conversion in
>> the fun
>> testPosix()
>> #~ [1] "2009-01-13 15:29:50 UTC"
>> #
Re: [Rd] particulars of importing/loading libraries
Oleg,
On Jan 13, 2009, at 11:00 , Sklyar, Oleg (London) wrote:
Dear List:
Sorry for posting maybe a trivial question, but I have a basic
understanding problem. If I have say pack1 and pack2, two R packages,
and pack2 depends on and imports pack1 fully (as in the code below),
is
there a way to make all the functionality of pack1 available for the
global and other environments (not only for the functions called from
withing pack2) by loading pack2 only? I thought if pack2 depends on
and
imports pack1 and essentially reexports everything, one should get the
full functionality simply by loading pack2. This does not seem to be
the
case or I am missing something trivial in my NAMESPACE/DESCRIPTION
files?
If this is documented in Writing R Extensions, I would be thankful
for a
page number and maybe a quick fix in my example below as so far I have
not been able to find a clear explanation.
The problem can be illustrated by the following simple example (this
is
a simple code for 2 packages, pack1 and pack2; plus an example).
if you bothered to use R CMD check you would find your bug right away:
* checking package dependencies ... ERROR
Namespace dependencies not required:
pack1
You simply forgot to add pack1 to the Depends: line - that's all. Once
you fix that, you'll see what happens:
> library(pack2)
Loading required package: pack1
> as.POSIXct(pack1::testPosixVal)
[1] "2009-01-14 01:38:08 UTC"
Cheers,
S
Thank you for your replies.
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
--- pack1: DESCRIPTION --
Package: pack1
Version: 0.0.1
Date: 12 Jan 2009
Title: pack1 to test S3/S4 methods compatibility
Author: Oleg Sklyar
Depends: R (>= 2.7.1), methods
Maintainer: Oleg Sklyar
Description: pack1
LazyLoad: yes
License: Proprietary
URL: http://www.maninvestments.com
LazyLoad: no
--- pack1: NAMESPACE --
import(methods)
exportPattern("^[^\\.]")
exportClasses(posixTime)
exportMethods(as.POSIXct)
--- pack1: posix.R --
setClass("posixTime", "numeric")
setGeneric("as.POSIXct")
setMethod("as.POSIXct", signature(x="posixTime"),
function(x, tz) {
z = x...@.data
attr(z,"class") = c("POSIXt", "POSIXct")
attr(z,"tzone") = "UTC"
z
}
)
testPosixVal = new("posixTime", as.numeric(Sys.time()))
--- pack2: DESCRIPTION
Package: pack2
Version: 0.0.1
Date: 12 Jan 2009
Title: pack2 to test S3/S4 methods compatibility
Author: Oleg Sklyar
Depends: R (>= 2.7.1), methods
Maintainer: Oleg Sklyar
Description: pack2
LazyLoad: yes
License: Proprietary
URL: http://www.maninvestments.com
LazyLoad: no
--- pack2: NAMESPACE --
import(pack1)
exportPattern("^[^\\.]")
--- pack2: posix.R --
testPosix = function() {
z = as.POSIXct(testPosixVal)
print(z)
print(class(z))
z
}
-- test code to run from global env, showing problems ---
require(pack2)
## use as.POSIXct imported into pack2 from pack1 to do the
conversion in
the fun
testPosix()
#~ [1] "2009-01-13 15:29:50 UTC"
#~ [1] "POSIXt" "POSIXct"
#~ [1] "2009-01-13 15:29:50 UTC"
## now try using it directly from the global env (pack1 was not
explicitly loaded)
as.POSIXct(pack1::testPosixVal)
#~ Error in as.POSIXct.default(pack1::testPosixVal) :
#~ do not know how to convert 'pack1::testPosixVal' to class
"POSIXlt"
## now require pack1 explicitly and try again
require(pack1)
as.POSIXct(pack1::testPosixVal)
#~ [1] "2009-01-13 15:29:50 UTC"
**
Please consider the environment before printing this email or its
attachments.
The contents of this email are for the named addressees ...{{dropped:
19}}
__
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] particulars of importing/loading libraries
I will give it a try with .onLoad, but I am not sure why this should be
required. I do not think this is the solution for the problem as at the
times when there were no namespaces, adding a library in Depends of the
Description file was sufficient.
As for the second point I am aware of that, but this just highlights the
problem: pack1 was not made available to the global namespace and
therefore that construction was required.
Best,
Oleg
Paul Gilbert wrote:
Maybe I'm missing something (it wouldn't be the first time), but I think
your problem is that pack2 needs a function
.onLoad <- function(library, section) {require("pack1")}
since you actually want the functions from pack1 available, and not just
its namespace.
( And you will need the "pack1::" in pack1::testPosixVal only if
testPosixVal is not exported from pack1. )
Paul
Sklyar, Oleg (London) wrote:
I was thinking of this, but this is going to be a pain if a package
imports 5 packs, is being imported by another one, which itself is
imported by yet another one and the only one one would like to load
explicitly is the last down the line. If I do not find a better solution
this is what I probably will have to do, reexport everything.
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
-Original Message-
From: Martin Morgan [mailto:mtmor...@fhcrc.org] Sent: 13 January 2009
16:31
To: Sklyar, Oleg (London)
Cc: r-devel@r-project.org
Subject: Re: [Rd] particulars of importing/loading libraries
Hi Oleg --
"Sklyar, Oleg (London)" writes:
Dear List:
Sorry for posting maybe a trivial question, but I have a basic
understanding problem. If I have say pack1 and pack2, two R
packages,
and pack2 depends on and imports pack1 fully (as in the
code below), is
there a way to make all the functionality of pack1 available for the
global and other environments (not only for the functions
called from
withing pack2) by loading pack2 only? I thought if pack2
depends on and
imports pack1 and essentially reexports everything, one
should get the
full functionality simply by loading pack2. This does not
seem to be the
case or I am missing something trivial in my NAMESPACE/DESCRIPTION
files?
I think that exportPattern does a simple ls() on the environment of
the package name space. The imported symbols are not defined in that
environment, but (I think) in a variable .__NAMESPACE__. and so are
not discovered. Arguably, exportPattern (and friends) should be
smarter. Pragmatically, you need to re-export imported symbols
explicitly. I haven't worked this through entirely, and could be
wrong...
Martin
If this is documented in Writing R Extensions, I would be
thankful for a
page number and maybe a quick fix in my example below as so
far I have
not been able to find a clear explanation.
The problem can be illustrated by the following simple
example (this is
a simple code for 2 packages, pack1 and pack2; plus an example).
Thank you for your replies.
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
--- pack1: DESCRIPTION --
Package: pack1
Version: 0.0.1
Date: 12 Jan 2009
Title: pack1 to test S3/S4 methods compatibility
Author: Oleg Sklyar
Depends: R (>= 2.7.1), methods
Maintainer: Oleg Sklyar
Description: pack1
LazyLoad: yes
License: Proprietary
URL: http://www.maninvestments.com
LazyLoad: no
--- pack1: NAMESPACE --
import(methods)
exportPattern("^[^\\.]")
exportClasses(posixTime)
exportMethods(as.POSIXct)
--- pack1: posix.R --
setClass("posixTime", "numeric")
setGeneric("as.POSIXct")
setMethod("as.POSIXct", signature(x="posixTime"),
function(x, tz) {
z = x...@.data
attr(z,"class") = c("POSIXt", "POSIXct")
attr(z,"tzone") = "UTC"
z
}
)
testPosixVal = new("posixTime", as.numeric(Sys.time()))
--- pack2: DESCRIPTION Package: pack2
Version: 0.0.1
Date: 12 Jan 2009
Title: pack2 to test S3/S4 methods compatibility
Author: Oleg Sklyar
Depends: R (>= 2.7.1), methods
Maintainer: Oleg Sklyar
Description: pack2
LazyLoad: yes
License: Proprietary
URL: http://www.maninvestments.com
LazyLoad: no
--- pack2: NAMESPACE --
import(pack1)
exportPattern("^[^\\.]")
--- pack2: posix.R --
testPosix = function() {
z = as.POSIXct(testPosixVal)
print(z)
print(class(z))
z
}
-- test code to run from global env, showing problems ---
require(pack2)
## use as.POSIXct imported into pack2 from pack1 to do the
conversion in
the fun
testPosix()
#~ [1] "2009-01-13 15:29:50 UTC"
#~ [1] "POSIXt" "POSIXct"
#~ [1] "2009-01-13 15:29:50 UTC"
## now try using it directly from the global env (pack1 was not
explicitly loaded)
as.POSIXct(pack1::testPosixVal)
#~ Error in as.POSIXct.default(pack1::testPosixVal) : #~ do not
know how to convert 'pack1::testPosixVal' to
class "POSIXlt"
## now require pack1 explicitly and try again
require(pack1)
as.POS
Re: [Rd] R as a scripting engine
Just to bore everyone but Simon and me to tears, here is 'fair' timing2.sh variant using an r version that does not autoload(). e...@ron:/tmp$ ./timing3.sh --- our r calling summary() 20 times real0m3.375s user0m3.100s sys 0m0.268s --- GNU R's Rscript calling summary() 20 times real0m4.328s user0m3.880s sys 0m0.412s --- our (empty) r calling summary() 20 times real0m2.517s user0m2.284s sys 0m0.204s --- GNU R's (empty) Rscript calling summary() 20 times real0m2.756s user0m2.340s sys 0m0.356s --- GNU R calling summary() 20 times real0m8.401s user0m7.812s sys 0m0.528s e...@ron:/tmp$ It's back to where we were, but Simon's point on library() taking a good chunk of time is acknowledge. I'll add a new switch to littler, which is due for a new release anyway providing the new tempdir option that suggested by Paul Gilbert a while back. Cheers, Dirk -- Three out of two people have difficulties with fractions. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R as a scripting engine
Hi Simon,
On 13 January 2009 at 12:36, Simon Urbanek wrote:
| Oh, well, now that the post count is growing I guess I have to
| respond ;).
|
| On Jan 11, 2009, at 15:50 , Dirk Eddelbuettel wrote:
|
| >
| > On 11 January 2009 at 20:18, Prof Brian Ripley wrote:
| > | Those of you tracking R development will have noticed that we are
| > | moving towards using R as a scripting engine.
| > [...]
| > | Reasons:
| > |
| > | - it is platform-independent and needs no other tools installed.
| > [...]
| > | - it is fast.
| > [...]
| >
| > Indeed. I really like working with r scripts.
| >
| > And littler by Horner and Eddelbuettel is faster than Rscript -- see
| > eg the
| > scripts tests/timing.sh and tests/timing2.sh in the SVN archive /
| > littler
| > tarballs (and the results below for illustration).
| >
|
| Well, if we enter that territory then rcmd from Rserve is much faster
| than littler:
|
| --- GNU bc doing the addition 10 times
| real 0m0.029s
| user 0m0.009s
| sys 0m0.028s
|
| --- rcmd doing the addition 10 times
| real 0m0.090s
| user 0m0.010s
| sys 0m0.022s
|
| --- our r doing the addition 10 times
| real 0m0.294s
| user 0m0.199s
| sys 0m0.091s
|
| --- GNU R's Rscript doing the addition 10 times
| real 0m1.626s
| user 0m1.241s
| sys 0m0.357s
|
| --- GNU R doing the addition 10 times
| real 0m2.883s
| user 0m2.424s
| sys 0m0.426s
|
| (littler and timig.sh script from http://littler.googlecode.com/svn/trunk
| with loopRcmd added)
|
|
| Yes, the comparison is unfair, but that applies to littler and Rscript
| as well.
It's a fair point. The test in timing.sh skews towards startup and
initialization costs, and Rserve ought to win against others starting
repeatedly times if it only starts once :)
| Once you start making direct comparisons the story is a bit
| different:
|
| --- our r doing the addition 10 times
| real 0m0.297s
| user 0m0.200s
| sys 0m0.091s
|
| --- GNU R's Rscript doing the addition 10 times
| real 0m0.390s
| user 0m0.219s
| sys 0m0.163s
|
| (Rscript is now run with R_DEFAULT_PACKAGES=NULL since that is what
| littler really does).
I think that is incorrect. For littler, the code is shared between autoloads.R /
autoloads.h and littler.c. We always load
dp <- getOption("defaultPackages")
and hence currently (from autoloads.h in your build directory, data read by
autoloads() in littler.c)
char *pack[] = {
"datasets",
"utils",
"grDevices",
"graphics",
"stats",
"methods"
};
so I believe the following results could be 'improved' on littler's side as
well if I chose to ignore load of default packages.
| .. and for timing2.sh (again, comparing Rcmd is technically a bit
| unfair, but the net effect for the user is good):
|
| --- rcmd calling summary() 20 times
| real 0m0.439s
| user 0m0.019s
| sys 0m0.045s
|
| --- our r calling summary() 20 times
| real 0m2.619s
| user 0m2.089s
| sys 0m0.476s
|
| --- GNU R's Rscript calling summary() 20 times
| real 0m2.435s
| user 0m1.793s
| sys 0m0.590s
|
| --- GNU R calling summary() 20 times
| real 0m5.789s
| user 0m4.892s
| sys 0m0.829s
|
| so in fact Rscript is here faster than littleR!
|
| (R 2.8.1 32-bit, Mac OS X 10.5.6, bash shell (due to echo bug), Quad
| 2.66GHz Xeon, littler from SVN, rcmd from SVN, Rserve 0.5-2)
|
|
| > We should still appreciate it you could finally acknowledge
| > existence of littler it in the R / Rscript documentation. You are
| > not doing users any service by pretending it doesn't exist.
| >
|
| I don't think anyone is pretending anything. If users want littler
| specifically, they will find it, but I don't see why it should have
| anything to do with the R documentation - it's not part of R ...
All I suggested in the past was a nod towards littler's existence. Littler
did come first, and (under an 'apples to apples' comparison) still starts
faster (as it does its work differently making it e.g. less easily portable
to Windows).
It is after all fairly common to credit previous related work.
| Cheers,
| S
|
| PS: No, I'm not advertising Rserve here - it has its own place, but I
| wouldn't really use it for running random scripts. I have added it to
| the mix just to show that there is always a tradeoff, so it's
| important to know what is compared in benchmarks...
I have gotten really used to always letting emacs run and to start client
session without delay (besides being able to continue working remotely in
existing sessions). In that sense a hybrid command-line version of something
like little that talks to an Rserve instance is not a bad idea at all -- in
particular if speed was everything.
Dirk
|
|
| > That said, we are not (yet ?) building r for Windows, and I
| > appreciate that Rscript is available there. Maintenance and use of
| > R will be easier with a consistent set of tools. This is a good move.
| >
| > Dirk
| >
| >
| > e...@ron:~/svn/li
Re: [Rd] particulars of importing/loading libraries
Maybe I'm missing something (it wouldn't be the first time), but I think
your problem is that pack2 needs a function
.onLoad <- function(library, section) {require("pack1")}
since you actually want the functions from pack1 available, and not just
its namespace.
( And you will need the "pack1::" in pack1::testPosixVal only if
testPosixVal is not exported from pack1. )
Paul
Sklyar, Oleg (London) wrote:
I was thinking of this, but this is going to be a pain if a package
imports 5 packs, is being imported by another one, which itself is
imported by yet another one and the only one one would like to load
explicitly is the last down the line. If I do not find a better solution
this is what I probably will have to do, reexport everything.
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
-Original Message-
From: Martin Morgan [mailto:mtmor...@fhcrc.org]
Sent: 13 January 2009 16:31
To: Sklyar, Oleg (London)
Cc: r-devel@r-project.org
Subject: Re: [Rd] particulars of importing/loading libraries
Hi Oleg --
"Sklyar, Oleg (London)" writes:
Dear List:
Sorry for posting maybe a trivial question, but I have a basic
understanding problem. If I have say pack1 and pack2, two R
packages,
and pack2 depends on and imports pack1 fully (as in the
code below), is
there a way to make all the functionality of pack1 available for the
global and other environments (not only for the functions
called from
withing pack2) by loading pack2 only? I thought if pack2
depends on and
imports pack1 and essentially reexports everything, one
should get the
full functionality simply by loading pack2. This does not
seem to be the
case or I am missing something trivial in my NAMESPACE/DESCRIPTION
files?
I think that exportPattern does a simple ls() on the environment of
the package name space. The imported symbols are not defined in that
environment, but (I think) in a variable .__NAMESPACE__. and so are
not discovered. Arguably, exportPattern (and friends) should be
smarter. Pragmatically, you need to re-export imported symbols
explicitly. I haven't worked this through entirely, and could be
wrong...
Martin
If this is documented in Writing R Extensions, I would be
thankful for a
page number and maybe a quick fix in my example below as so
far I have
not been able to find a clear explanation.
The problem can be illustrated by the following simple
example (this is
a simple code for 2 packages, pack1 and pack2; plus an example).
Thank you for your replies.
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
--- pack1: DESCRIPTION --
Package: pack1
Version: 0.0.1
Date: 12 Jan 2009
Title: pack1 to test S3/S4 methods compatibility
Author: Oleg Sklyar
Depends: R (>= 2.7.1), methods
Maintainer: Oleg Sklyar
Description: pack1
LazyLoad: yes
License: Proprietary
URL: http://www.maninvestments.com
LazyLoad: no
--- pack1: NAMESPACE --
import(methods)
exportPattern("^[^\\.]")
exportClasses(posixTime)
exportMethods(as.POSIXct)
--- pack1: posix.R --
setClass("posixTime", "numeric")
setGeneric("as.POSIXct")
setMethod("as.POSIXct", signature(x="posixTime"),
function(x, tz) {
z = x...@.data
attr(z,"class") = c("POSIXt", "POSIXct")
attr(z,"tzone") = "UTC"
z
}
)
testPosixVal = new("posixTime", as.numeric(Sys.time()))
--- pack2: DESCRIPTION
Package: pack2
Version: 0.0.1
Date: 12 Jan 2009
Title: pack2 to test S3/S4 methods compatibility
Author: Oleg Sklyar
Depends: R (>= 2.7.1), methods
Maintainer: Oleg Sklyar
Description: pack2
LazyLoad: yes
License: Proprietary
URL: http://www.maninvestments.com
LazyLoad: no
--- pack2: NAMESPACE --
import(pack1)
exportPattern("^[^\\.]")
--- pack2: posix.R --
testPosix = function() {
z = as.POSIXct(testPosixVal)
print(z)
print(class(z))
z
}
-- test code to run from global env, showing problems ---
require(pack2)
## use as.POSIXct imported into pack2 from pack1 to do the
conversion in
the fun
testPosix()
#~ [1] "2009-01-13 15:29:50 UTC"
#~ [1] "POSIXt" "POSIXct"
#~ [1] "2009-01-13 15:29:50 UTC"
## now try using it directly from the global env (pack1 was not
explicitly loaded)
as.POSIXct(pack1::testPosixVal)
#~ Error in as.POSIXct.default(pack1::testPosixVal) :
#~ do not know how to convert 'pack1::testPosixVal' to
class "POSIXlt"
## now require pack1 explicitly and try again
require(pack1)
as.POSIXct(pack1::testPosixVal)
#~ [1] "2009-01-13 15:29:50 UTC"
**
Please consider the environment before printing this email
or its attachments.
The contents of this email are for the named addressees
...{{dropped:19}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Martin Morgan
Computational Biology / Fr
Re: [Rd] R as a scripting engine
Oh, well, now that the post count is growing I guess I have to respond ;). On Jan 11, 2009, at 15:50 , Dirk Eddelbuettel wrote: On 11 January 2009 at 20:18, Prof Brian Ripley wrote: | Those of you tracking R development will have noticed that we are | moving towards using R as a scripting engine. [...] | Reasons: | | - it is platform-independent and needs no other tools installed. [...] | - it is fast. [...] Indeed. I really like working with r scripts. And littler by Horner and Eddelbuettel is faster than Rscript -- see eg the scripts tests/timing.sh and tests/timing2.sh in the SVN archive / littler tarballs (and the results below for illustration). Well, if we enter that territory then rcmd from Rserve is much faster than littler: --- GNU bc doing the addition 10 times real0m0.029s user0m0.009s sys 0m0.028s --- rcmd doing the addition 10 times real0m0.090s user0m0.010s sys 0m0.022s --- our r doing the addition 10 times real0m0.294s user0m0.199s sys 0m0.091s --- GNU R's Rscript doing the addition 10 times real0m1.626s user0m1.241s sys 0m0.357s --- GNU R doing the addition 10 times real0m2.883s user0m2.424s sys 0m0.426s (littler and timig.sh script from http://littler.googlecode.com/svn/trunk with loopRcmd added) Yes, the comparison is unfair, but that applies to littler and Rscript as well. Once you start making direct comparisons the story is a bit different: --- our r doing the addition 10 times real0m0.297s user0m0.200s sys 0m0.091s --- GNU R's Rscript doing the addition 10 times real0m0.390s user0m0.219s sys 0m0.163s (Rscript is now run with R_DEFAULT_PACKAGES=NULL since that is what littler really does). .. and for timing2.sh (again, comparing Rcmd is technically a bit unfair, but the net effect for the user is good): --- rcmd calling summary() 20 times real0m0.439s user0m0.019s sys 0m0.045s --- our r calling summary() 20 times real0m2.619s user0m2.089s sys 0m0.476s --- GNU R's Rscript calling summary() 20 times real0m2.435s user0m1.793s sys 0m0.590s --- GNU R calling summary() 20 times real0m5.789s user0m4.892s sys 0m0.829s so in fact Rscript is here faster than littleR! (R 2.8.1 32-bit, Mac OS X 10.5.6, bash shell (due to echo bug), Quad 2.66GHz Xeon, littler from SVN, rcmd from SVN, Rserve 0.5-2) We should still appreciate it you could finally acknowledge existence of littler it in the R / Rscript documentation. You are not doing users any service by pretending it doesn't exist. I don't think anyone is pretending anything. If users want littler specifically, they will find it, but I don't see why it should have anything to do with the R documentation - it's not part of R ... Cheers, S PS: No, I'm not advertising Rserve here - it has its own place, but I wouldn't really use it for running random scripts. I have added it to the mix just to show that there is always a tradeoff, so it's important to know what is compared in benchmarks... That said, we are not (yet ?) building r for Windows, and I appreciate that Rscript is available there. Maintenance and use of R will be easier with a consistent set of tools. This is a good move. Dirk e...@ron:~/svn/littler/tests> ./timing.sh --- GNU bc doing the addition 10 times real0m0.028s user0m0.004s sys 0m0.012s --- our r doing the addition 10 times real0m0.400s user0m0.308s sys 0m0.052s --- GNU R's Rscript doing the addition 10 times real0m2.077s user0m1.832s sys 0m0.204s --- GNU R doing the addition 10 times real0m3.974s user0m3.728s sys 0m0.228s e...@ron:~/svn/littler/tests> ./timing2.sh --- our r calling summary() 20 times real0m3.261s user0m2.976s sys 0m0.240s --- GNU R's Rscript calling summary() 20 times real0m4.164s user0m3.624s sys 0m0.548s --- GNU R calling summary() 20 times real0m8.087s user0m7.552s sys 0m0.492s e...@ron:~/svn/littler/tests> -- Three out of two people have difficulties with fractions. __ 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] particulars of importing/loading libraries
So essentially I guess it would be nice to have a way of reexporting
everything in
get("imports",env=pack2:::.__NAMESPACE__.)
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
> -Original Message-
> From: Martin Morgan [mailto:mtmor...@fhcrc.org]
> Sent: 13 January 2009 16:31
> To: Sklyar, Oleg (London)
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] particulars of importing/loading libraries
>
> Hi Oleg --
>
> "Sklyar, Oleg (London)" writes:
>
> > Dear List:
> >
> > Sorry for posting maybe a trivial question, but I have a basic
> > understanding problem. If I have say pack1 and pack2, two R
> packages,
> > and pack2 depends on and imports pack1 fully (as in the
> code below), is
> > there a way to make all the functionality of pack1 available for the
> > global and other environments (not only for the functions
> called from
> > withing pack2) by loading pack2 only? I thought if pack2
> depends on and
> > imports pack1 and essentially reexports everything, one
> should get the
> > full functionality simply by loading pack2. This does not
> seem to be the
> > case or I am missing something trivial in my NAMESPACE/DESCRIPTION
> > files?
>
> I think that exportPattern does a simple ls() on the environment of
> the package name space. The imported symbols are not defined in that
> environment, but (I think) in a variable .__NAMESPACE__. and so are
> not discovered. Arguably, exportPattern (and friends) should be
> smarter. Pragmatically, you need to re-export imported symbols
> explicitly. I haven't worked this through entirely, and could be
> wrong...
>
> Martin
>
> > If this is documented in Writing R Extensions, I would be
> thankful for a
> > page number and maybe a quick fix in my example below as so
> far I have
> > not been able to find a clear explanation.
> >
> > The problem can be illustrated by the following simple
> example (this is
> > a simple code for 2 packages, pack1 and pack2; plus an example).
> >
> > Thank you for your replies.
> >
> > Dr Oleg Sklyar
> > Research Technologist
> > AHL / Man Investments Ltd
> > +44 (0)20 7144 3107
> > oskl...@maninvestments.com
> >
> > --- pack1: DESCRIPTION --
> > Package: pack1
> > Version: 0.0.1
> > Date: 12 Jan 2009
> > Title: pack1 to test S3/S4 methods compatibility
> > Author: Oleg Sklyar
> > Depends: R (>= 2.7.1), methods
> > Maintainer: Oleg Sklyar
> > Description: pack1
> > LazyLoad: yes
> > License: Proprietary
> > URL: http://www.maninvestments.com
> > LazyLoad: no
> >
> > --- pack1: NAMESPACE --
> > import(methods)
> > exportPattern("^[^\\.]")
> > exportClasses(posixTime)
> > exportMethods(as.POSIXct)
> >
> > --- pack1: posix.R --
> > setClass("posixTime", "numeric")
> >
> > setGeneric("as.POSIXct")
> > setMethod("as.POSIXct", signature(x="posixTime"),
> > function(x, tz) {
> > z = x...@.data
> > attr(z,"class") = c("POSIXt", "POSIXct")
> > attr(z,"tzone") = "UTC"
> > z
> > }
> > )
> >
> > testPosixVal = new("posixTime", as.numeric(Sys.time()))
> >
> > --- pack2: DESCRIPTION
> > Package: pack2
> > Version: 0.0.1
> > Date: 12 Jan 2009
> > Title: pack2 to test S3/S4 methods compatibility
> > Author: Oleg Sklyar
> > Depends: R (>= 2.7.1), methods
> > Maintainer: Oleg Sklyar
> > Description: pack2
> > LazyLoad: yes
> > License: Proprietary
> > URL: http://www.maninvestments.com
> > LazyLoad: no
> >
> > --- pack2: NAMESPACE --
> > import(pack1)
> > exportPattern("^[^\\.]")
> >
> > --- pack2: posix.R --
> > testPosix = function() {
> > z = as.POSIXct(testPosixVal)
> > print(z)
> > print(class(z))
> > z
> > }
> >
> > -- test code to run from global env, showing problems ---
> > require(pack2)
> >
> > ## use as.POSIXct imported into pack2 from pack1 to do the
> conversion in
> > the fun
> > testPosix()
> > #~ [1] "2009-01-13 15:29:50 UTC"
> > #~ [1] "POSIXt" "POSIXct"
> > #~ [1] "2009-01-13 15:29:50 UTC"
> >
> > ## now try using it directly from the global env (pack1 was not
> > explicitly loaded)
> > as.POSIXct(pack1::testPosixVal)
> > #~ Error in as.POSIXct.default(pack1::testPosixVal) :
> > #~ do not know how to convert 'pack1::testPosixVal' to
> class "POSIXlt"
> >
> > ## now require pack1 explicitly and try again
> > require(pack1)
> > as.POSIXct(pack1::testPosixVal)
> > #~ [1] "2009-01-13 15:29:50 UTC"
> >
> >
> >
> **
> > Please consider the environment before printing this email
> or its attachments.
> > The contents of this email are for the named addressees
> ...{{dropped:19}}
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Martin Morgan
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
>
> Location: Arnold Buildin
Re: [Rd] particulars of importing/loading libraries
I was thinking of this, but this is going to be a pain if a package
imports 5 packs, is being imported by another one, which itself is
imported by yet another one and the only one one would like to load
explicitly is the last down the line. If I do not find a better solution
this is what I probably will have to do, reexport everything.
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
> -Original Message-
> From: Martin Morgan [mailto:mtmor...@fhcrc.org]
> Sent: 13 January 2009 16:31
> To: Sklyar, Oleg (London)
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] particulars of importing/loading libraries
>
> Hi Oleg --
>
> "Sklyar, Oleg (London)" writes:
>
> > Dear List:
> >
> > Sorry for posting maybe a trivial question, but I have a basic
> > understanding problem. If I have say pack1 and pack2, two R
> packages,
> > and pack2 depends on and imports pack1 fully (as in the
> code below), is
> > there a way to make all the functionality of pack1 available for the
> > global and other environments (not only for the functions
> called from
> > withing pack2) by loading pack2 only? I thought if pack2
> depends on and
> > imports pack1 and essentially reexports everything, one
> should get the
> > full functionality simply by loading pack2. This does not
> seem to be the
> > case or I am missing something trivial in my NAMESPACE/DESCRIPTION
> > files?
>
> I think that exportPattern does a simple ls() on the environment of
> the package name space. The imported symbols are not defined in that
> environment, but (I think) in a variable .__NAMESPACE__. and so are
> not discovered. Arguably, exportPattern (and friends) should be
> smarter. Pragmatically, you need to re-export imported symbols
> explicitly. I haven't worked this through entirely, and could be
> wrong...
>
> Martin
>
> > If this is documented in Writing R Extensions, I would be
> thankful for a
> > page number and maybe a quick fix in my example below as so
> far I have
> > not been able to find a clear explanation.
> >
> > The problem can be illustrated by the following simple
> example (this is
> > a simple code for 2 packages, pack1 and pack2; plus an example).
> >
> > Thank you for your replies.
> >
> > Dr Oleg Sklyar
> > Research Technologist
> > AHL / Man Investments Ltd
> > +44 (0)20 7144 3107
> > oskl...@maninvestments.com
> >
> > --- pack1: DESCRIPTION --
> > Package: pack1
> > Version: 0.0.1
> > Date: 12 Jan 2009
> > Title: pack1 to test S3/S4 methods compatibility
> > Author: Oleg Sklyar
> > Depends: R (>= 2.7.1), methods
> > Maintainer: Oleg Sklyar
> > Description: pack1
> > LazyLoad: yes
> > License: Proprietary
> > URL: http://www.maninvestments.com
> > LazyLoad: no
> >
> > --- pack1: NAMESPACE --
> > import(methods)
> > exportPattern("^[^\\.]")
> > exportClasses(posixTime)
> > exportMethods(as.POSIXct)
> >
> > --- pack1: posix.R --
> > setClass("posixTime", "numeric")
> >
> > setGeneric("as.POSIXct")
> > setMethod("as.POSIXct", signature(x="posixTime"),
> > function(x, tz) {
> > z = x...@.data
> > attr(z,"class") = c("POSIXt", "POSIXct")
> > attr(z,"tzone") = "UTC"
> > z
> > }
> > )
> >
> > testPosixVal = new("posixTime", as.numeric(Sys.time()))
> >
> > --- pack2: DESCRIPTION
> > Package: pack2
> > Version: 0.0.1
> > Date: 12 Jan 2009
> > Title: pack2 to test S3/S4 methods compatibility
> > Author: Oleg Sklyar
> > Depends: R (>= 2.7.1), methods
> > Maintainer: Oleg Sklyar
> > Description: pack2
> > LazyLoad: yes
> > License: Proprietary
> > URL: http://www.maninvestments.com
> > LazyLoad: no
> >
> > --- pack2: NAMESPACE --
> > import(pack1)
> > exportPattern("^[^\\.]")
> >
> > --- pack2: posix.R --
> > testPosix = function() {
> > z = as.POSIXct(testPosixVal)
> > print(z)
> > print(class(z))
> > z
> > }
> >
> > -- test code to run from global env, showing problems ---
> > require(pack2)
> >
> > ## use as.POSIXct imported into pack2 from pack1 to do the
> conversion in
> > the fun
> > testPosix()
> > #~ [1] "2009-01-13 15:29:50 UTC"
> > #~ [1] "POSIXt" "POSIXct"
> > #~ [1] "2009-01-13 15:29:50 UTC"
> >
> > ## now try using it directly from the global env (pack1 was not
> > explicitly loaded)
> > as.POSIXct(pack1::testPosixVal)
> > #~ Error in as.POSIXct.default(pack1::testPosixVal) :
> > #~ do not know how to convert 'pack1::testPosixVal' to
> class "POSIXlt"
> >
> > ## now require pack1 explicitly and try again
> > require(pack1)
> > as.POSIXct(pack1::testPosixVal)
> > #~ [1] "2009-01-13 15:29:50 UTC"
> >
> >
> >
> **
> > Please consider the environment before printing this email
> or its attachments.
> > The contents of this email are for the named addressees
> ...{{dropped:19}}
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat
Re: [Rd] x <- 1:2; dim(x) <- 2? A vector or not?
Henrik Bengtsson wrote: Hi. On Mon, Jan 12, 2009 at 11:58 PM, Prof Brian Ripley wrote: What you have is a one-dimensional array: they crop up in R most often from table() in my experience. f <- table(rpois(100, 4)) str(f) 'table' int [, 1:10] 2 6 18 21 13 16 13 4 3 4 - attr(*, "dimnames")=List of 1 ..$ : chr [1:10] "0" "1" "2" "3" ... and yes, f is an atmoic vector and yes, str()'s notation is confusing here but if it did [1:10] you would not know it was an array. I recall discussing this with Martin Maechler (str's author) last century, and I've just checked that R 2.0.0 did the same. The place in which one-dimensional arrays differ from normal vectors is how names are handled: notice that my example has dimnames not names, and ?names says For a one-dimensional array the 'names' attribute really is 'dimnames[[1]]'. Thanks for this explanation. One could then argue that [1:10,] is somewhat better than [,1:10], but that is just polish. Perhaps it could be: [1:10(,)] That is weird enough that it should not lead people to believe that it is a matrix. But might prompt them a bit in that direction. Patrick Burns patr...@burns-stat.com +44 (0)20 8525 0696 http://www.burns-stat.com (home of "The R Inferno" and "A Guide for the Unwilling S User") /Henrik I think these days we have enough internal glue in place that an end user would not notice the difference (but those working at C level with R objects may need to know). On Mon, 12 Jan 2009, Henrik Bengtsson wrote: Ran into the follow intermediate case in an external package (w/ recent R v2.8.1 patched and R v2.9.0 devel): x <- 1:2 dim(x) <- 2 dim(x) [1] 2 x [1] 1 2 str(x) int [, 1:2] 1 2 nrow(x) [1] 2 ncol(x) [1] NA is.vector(x) [1] FALSE is.matrix(x) [1] FALSE is.array(x) [1] TRUE x[1] [1] 1 x[,1] Error in x[, 1] : incorrect number of dimensions x[1,] Error in x[1, ] : incorrect number of dimensions Is str() treating single-dimension arrays incorrectly? What does it mean to have a single dimension this way? Should it equal a vector? I am aware of "is.vector returns FALSE if x has any attributes except names". /Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] particulars of importing/loading libraries
Hi Oleg --
"Sklyar, Oleg (London)" writes:
> Dear List:
>
> Sorry for posting maybe a trivial question, but I have a basic
> understanding problem. If I have say pack1 and pack2, two R packages,
> and pack2 depends on and imports pack1 fully (as in the code below), is
> there a way to make all the functionality of pack1 available for the
> global and other environments (not only for the functions called from
> withing pack2) by loading pack2 only? I thought if pack2 depends on and
> imports pack1 and essentially reexports everything, one should get the
> full functionality simply by loading pack2. This does not seem to be the
> case or I am missing something trivial in my NAMESPACE/DESCRIPTION
> files?
I think that exportPattern does a simple ls() on the environment of
the package name space. The imported symbols are not defined in that
environment, but (I think) in a variable .__NAMESPACE__. and so are
not discovered. Arguably, exportPattern (and friends) should be
smarter. Pragmatically, you need to re-export imported symbols
explicitly. I haven't worked this through entirely, and could be
wrong...
Martin
> If this is documented in Writing R Extensions, I would be thankful for a
> page number and maybe a quick fix in my example below as so far I have
> not been able to find a clear explanation.
>
> The problem can be illustrated by the following simple example (this is
> a simple code for 2 packages, pack1 and pack2; plus an example).
>
> Thank you for your replies.
>
> Dr Oleg Sklyar
> Research Technologist
> AHL / Man Investments Ltd
> +44 (0)20 7144 3107
> oskl...@maninvestments.com
>
> --- pack1: DESCRIPTION --
> Package: pack1
> Version: 0.0.1
> Date: 12 Jan 2009
> Title: pack1 to test S3/S4 methods compatibility
> Author: Oleg Sklyar
> Depends: R (>= 2.7.1), methods
> Maintainer: Oleg Sklyar
> Description: pack1
> LazyLoad: yes
> License: Proprietary
> URL: http://www.maninvestments.com
> LazyLoad: no
>
> --- pack1: NAMESPACE --
> import(methods)
> exportPattern("^[^\\.]")
> exportClasses(posixTime)
> exportMethods(as.POSIXct)
>
> --- pack1: posix.R --
> setClass("posixTime", "numeric")
>
> setGeneric("as.POSIXct")
> setMethod("as.POSIXct", signature(x="posixTime"),
> function(x, tz) {
> z = x...@.data
> attr(z,"class") = c("POSIXt", "POSIXct")
> attr(z,"tzone") = "UTC"
> z
> }
> )
>
> testPosixVal = new("posixTime", as.numeric(Sys.time()))
>
> --- pack2: DESCRIPTION
> Package: pack2
> Version: 0.0.1
> Date: 12 Jan 2009
> Title: pack2 to test S3/S4 methods compatibility
> Author: Oleg Sklyar
> Depends: R (>= 2.7.1), methods
> Maintainer: Oleg Sklyar
> Description: pack2
> LazyLoad: yes
> License: Proprietary
> URL: http://www.maninvestments.com
> LazyLoad: no
>
> --- pack2: NAMESPACE --
> import(pack1)
> exportPattern("^[^\\.]")
>
> --- pack2: posix.R --
> testPosix = function() {
> z = as.POSIXct(testPosixVal)
> print(z)
> print(class(z))
> z
> }
>
> -- test code to run from global env, showing problems ---
> require(pack2)
>
> ## use as.POSIXct imported into pack2 from pack1 to do the conversion in
> the fun
> testPosix()
> #~ [1] "2009-01-13 15:29:50 UTC"
> #~ [1] "POSIXt" "POSIXct"
> #~ [1] "2009-01-13 15:29:50 UTC"
>
> ## now try using it directly from the global env (pack1 was not
> explicitly loaded)
> as.POSIXct(pack1::testPosixVal)
> #~ Error in as.POSIXct.default(pack1::testPosixVal) :
> #~ do not know how to convert 'pack1::testPosixVal' to class "POSIXlt"
>
> ## now require pack1 explicitly and try again
> require(pack1)
> as.POSIXct(pack1::testPosixVal)
> #~ [1] "2009-01-13 15:29:50 UTC"
>
>
> **
> Please consider the environment before printing this email or its attachments.
> The contents of this email are for the named addressees ...{{dropped:19}}
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M2 B169
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] particulars of importing/loading libraries
Dear List:
Sorry for posting maybe a trivial question, but I have a basic
understanding problem. If I have say pack1 and pack2, two R packages,
and pack2 depends on and imports pack1 fully (as in the code below), is
there a way to make all the functionality of pack1 available for the
global and other environments (not only for the functions called from
withing pack2) by loading pack2 only? I thought if pack2 depends on and
imports pack1 and essentially reexports everything, one should get the
full functionality simply by loading pack2. This does not seem to be the
case or I am missing something trivial in my NAMESPACE/DESCRIPTION
files?
If this is documented in Writing R Extensions, I would be thankful for a
page number and maybe a quick fix in my example below as so far I have
not been able to find a clear explanation.
The problem can be illustrated by the following simple example (this is
a simple code for 2 packages, pack1 and pack2; plus an example).
Thank you for your replies.
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
--- pack1: DESCRIPTION --
Package: pack1
Version: 0.0.1
Date: 12 Jan 2009
Title: pack1 to test S3/S4 methods compatibility
Author: Oleg Sklyar
Depends: R (>= 2.7.1), methods
Maintainer: Oleg Sklyar
Description: pack1
LazyLoad: yes
License: Proprietary
URL: http://www.maninvestments.com
LazyLoad: no
--- pack1: NAMESPACE --
import(methods)
exportPattern("^[^\\.]")
exportClasses(posixTime)
exportMethods(as.POSIXct)
--- pack1: posix.R --
setClass("posixTime", "numeric")
setGeneric("as.POSIXct")
setMethod("as.POSIXct", signature(x="posixTime"),
function(x, tz) {
z = x...@.data
attr(z,"class") = c("POSIXt", "POSIXct")
attr(z,"tzone") = "UTC"
z
}
)
testPosixVal = new("posixTime", as.numeric(Sys.time()))
--- pack2: DESCRIPTION
Package: pack2
Version: 0.0.1
Date: 12 Jan 2009
Title: pack2 to test S3/S4 methods compatibility
Author: Oleg Sklyar
Depends: R (>= 2.7.1), methods
Maintainer: Oleg Sklyar
Description: pack2
LazyLoad: yes
License: Proprietary
URL: http://www.maninvestments.com
LazyLoad: no
--- pack2: NAMESPACE --
import(pack1)
exportPattern("^[^\\.]")
--- pack2: posix.R --
testPosix = function() {
z = as.POSIXct(testPosixVal)
print(z)
print(class(z))
z
}
-- test code to run from global env, showing problems ---
require(pack2)
## use as.POSIXct imported into pack2 from pack1 to do the conversion in
the fun
testPosix()
#~ [1] "2009-01-13 15:29:50 UTC"
#~ [1] "POSIXt" "POSIXct"
#~ [1] "2009-01-13 15:29:50 UTC"
## now try using it directly from the global env (pack1 was not
explicitly loaded)
as.POSIXct(pack1::testPosixVal)
#~ Error in as.POSIXct.default(pack1::testPosixVal) :
#~ do not know how to convert 'pack1::testPosixVal' to class "POSIXlt"
## now require pack1 explicitly and try again
require(pack1)
as.POSIXct(pack1::testPosixVal)
#~ [1] "2009-01-13 15:29:50 UTC"
**
Please consider the environment before printing this email or its attachments.
The contents of this email are for the named addressees ...{{dropped:19}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] x <- 1:2; dim(x) <- 2? A vector or not?
Hi. On Mon, Jan 12, 2009 at 11:58 PM, Prof Brian Ripley wrote: > What you have is a one-dimensional array: they crop up in R most often from > table() in my experience. > >> f <- table(rpois(100, 4)) >> str(f) > > 'table' int [, 1:10] 2 6 18 21 13 16 13 4 3 4 > - attr(*, "dimnames")=List of 1 > ..$ : chr [1:10] "0" "1" "2" "3" ... > > and yes, f is an atmoic vector and yes, str()'s notation is confusing here > but if it did [1:10] you would not know it was an array. I recall > discussing this with Martin Maechler (str's author) last century, and I've > just checked that R 2.0.0 did the same. > > The place in which one-dimensional arrays differ from normal vectors is how > names are handled: notice that my example has dimnames not names, and ?names > says > > For a one-dimensional array the 'names' attribute really is > 'dimnames[[1]]'. Thanks for this explanation. One could then argue that [1:10,] is somewhat better than [,1:10], but that is just polish. /Henrik > > I think these days we have enough internal glue in place that an end user > would not notice the difference (but those working at C level with R objects > may need to know). > > On Mon, 12 Jan 2009, Henrik Bengtsson wrote: > >> Ran into the follow intermediate case in an external package (w/ >> recent R v2.8.1 patched and R v2.9.0 devel): >> >>> x <- 1:2 >>> dim(x) <- 2 >>> dim(x) >> >> [1] 2 >>> >>> x >> >> [1] 1 2 >>> >>> str(x) >> >> int [, 1:2] 1 2 >>> >>> nrow(x) >> >> [1] 2 >>> >>> ncol(x) >> >> [1] NA >>> >>> is.vector(x) >> >> [1] FALSE >>> >>> is.matrix(x) >> >> [1] FALSE >>> >>> is.array(x) >> >> [1] TRUE >>> >>> x[1] >> >> [1] 1 >>> >>> x[,1] >> >> Error in x[, 1] : incorrect number of dimensions >>> >>> x[1,] >> >> Error in x[1, ] : incorrect number of dimensions >> >> Is str() treating single-dimension arrays incorrectly? >> >> What does it mean to have a single dimension this way? Should it >> equal a vector? I am aware of "is.vector returns FALSE if x has any >> attributes except names". >> >> /Henrik >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- > Brian D. Ripley, rip...@stats.ox.ac.uk > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UKFax: +44 1865 272595 > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R as a scripting engine
On 1/13/2009 4:33 AM, Wacek Kusnierczyk wrote: Dirk Eddelbuettel wrote: On 11 January 2009 at 20:18, Prof Brian Ripley wrote: | Those of you tracking R development will have noticed that we are | moving towards using R as a scripting engine. [...] | Reasons: | | - it is platform-independent and needs no other tools installed. [...] | - it is fast. [...] Indeed. I really like working with r scripts. And littler by Horner and Eddelbuettel is faster than Rscript -- see eg the scripts tests/timing.sh and tests/timing2.sh in the SVN archive / littler tarballs (and the results below for illustration). We should still appreciate it you could finally acknowledge existence of littler it in the R / Rscript documentation. You are not doing users any service by pretending it doesn't exist. will anyone ever bother to answer? is silence to be taken as acknowledgement, or rather a7e? You answered, so the naive answer to your first question is yes. Another naive response is that there probably won't be another answer. But I don't think your question is really a question, I think it's a demand, implying you think you are entitled to an answer. There isn't really a polite response to that. You're entitled to demand answers from companies that you are paying for services (and you often won't get any useful ones), but you aren't entitled to demand anything from anyone on this list. So live with it. Your second question doesn't make any sense to me: obviously silence is a7s. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] irrelevant warning message
On Tue, Jan 13, 2009 at 8:28 AM, Terry Therneau wrote: > Thanks for the replies: > > Duncan: >> and got a warning in all R versions I tried back to 2.4.1. In 2.3.1 >> this was an error. > > It seems I have egg on my face wrt this point. A more true synopsis of what > I > saw should have been that 1. I've never noticed this in R before and 2. Until > recently I did all my modeling in Splus or Bell S, and character vectors > always > worked there. (My survival routines were always more up to date in Splus > because that's what I use for the source code. But conversion from a local > cvs > archive to Rforge is nearly done -- just a survexp.us ratetable issue remains > -- > so R will become my most current version in another day or two.) Possibly I > don't have any character variables as covariates in the survival test suite. > > > Hadley: >> I think R's handling of character vectors has progressed to the point >> where they should be the norm, not the exception. Maybe others will >> have different views. > > Factors are very useful when there is a small discrete number of levels, and > I > use them moderately often. For that case, most of the default behavior of > factors makes perfect sense, e.g., retention of levels. I'm very sure that > adding stringsAsFactors to the system options was a good thing, not as sure > that > defaulting it to FALSE is the best thing for all users. > In my world most of the data comes from formal processes: clinical trials, > data bases, large studies that use dedicated keyed entry, etc. The most > common > character variables are things like id, name, and address for which the factor > paradym doesn't work, and most of the variables I get that are actually > 'factors' come to me as small integers; I turn them into factors using both > the > levels and labels arguments. Thus autoconversion is just a PITA. But my world > is not everyone's. > My main complaint with factors has always been the assumption that > everything > should be turned into one. I fought that battle with Splus. Defaults > behavior See the stringsAsFactors option in ?options to change the global default. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] irrelevant warning message
Thanks for the replies: Duncan: > and got a warning in all R versions I tried back to 2.4.1. In 2.3.1 > this was an error. It seems I have egg on my face wrt this point. A more true synopsis of what I saw should have been that 1. I've never noticed this in R before and 2. Until recently I did all my modeling in Splus or Bell S, and character vectors always worked there. (My survival routines were always more up to date in Splus because that's what I use for the source code. But conversion from a local cvs archive to Rforge is nearly done -- just a survexp.us ratetable issue remains -- so R will become my most current version in another day or two.) Possibly I don't have any character variables as covariates in the survival test suite. Hadley: > I think R's handling of character vectors has progressed to the point > where they should be the norm, not the exception. Maybe others will > have different views. Factors are very useful when there is a small discrete number of levels, and I use them moderately often. For that case, most of the default behavior of factors makes perfect sense, e.g., retention of levels. I'm very sure that adding stringsAsFactors to the system options was a good thing, not as sure that defaulting it to FALSE is the best thing for all users. In my world most of the data comes from formal processes: clinical trials, data bases, large studies that use dedicated keyed entry, etc. The most common character variables are things like id, name, and address for which the factor paradym doesn't work, and most of the variables I get that are actually 'factors' come to me as small integers; I turn them into factors using both the levels and labels arguments. Thus autoconversion is just a PITA. But my world is not everyone's. My main complaint with factors has always been the assumption that everything should be turned into one. I fought that battle with Splus. Defaults behavior is often a reflection of the data sets being analysed at the time the code was written, and factors reflect the data sets in Chambers & Hastie book. But then, my survival code has some defaults with exactly the same origin... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Missing links on Windows and \link[bar]{foo}; clarification
On Tue, 13 Jan 2009, Gavin Simpson wrote:
On Tue, 2009-01-13 at 11:12 +, Prof Brian Ripley wrote:
You would expect to see issues on Windows whilst checking, as
cross-library links do not work on Windows (unless fixed up, which
install.packages() does for some standard packages, not including
lattice which is 'recommended' not 'standard'). And, depending where
you install, perhaps during installation.
Thank you for your reply Prof. Ripley.
Note that specifying \code{\link[lattice]{panel.xyplot}} just avoids
the warnings: it still does not make a cross-library link work.
That covers Windows and I'm happy to leave those warnings in place. Is
the simpler form sufficient to make the required links on Linux (and
MacOSX...?); that seems the intention of R-exts.pdf, to me at least.
Yes, the simpler form works on OSes where we can assume symbolic
links (and before someone tells me Windows has them -- not in Windows
2000, our minimum requirement still).
As for R-devel: very likely processing of help will have changed
completely before release, so that is one area where we do not want
to know about problems as yet, and anything in the NEWS file is
provisional (some of the changes mentioned there may be reverted).
Yes, I realised that R-devel was changing considerably in this regard;
one of the reasons I was going through my Rd files was to fix-up some
problems with the mark-up that the new parser identified. Some changes I
made (not related to the parser version 2 warnings) triggered these
warnings on R-Forge.
All the best,
Gavin
On Tue, 13 Jan 2009, Gavin Simpson wrote:
Dear List,
In one of my packages on R-Forge I have a custom panel function for
Lattice graphics. In the Rd file for this panel function I want to
provide links to some lattice functions (in package lattice). My first
instinct was to use:
\code{\link[lattice]{panel.xyplot}}
for example. However, I missed a few references to lattice functions and
just marked them up as \code{\link{panel.xyplot}}.
For the latter, I am getting warnings about missing links during package
check and installation *only* on Windows and *only* on R patched
(R-Forge version: R version 2.8.1 Patched (2009-01-12 r47554)).
With R Devel (R-Forge version: 2.9.0 Under development (unstable)
(2009-01-10 r47538)) under Windows no warnings are issued.
The R-exts manual mentions that the first style is rarely needed, yet
the warnings on R-patched suggest that [currently] it is, for CHM help
only, which is where I presume the warnings are being generated.
Is the change in R Devel intentional or a side-effect of other changes
that is yet to be fixed? (I appreciate that this version of R is still
under development and unstable.) Is this difference between versions
related to (from NEWS)?:
o HTML links will be resolved first to the standard packages: this
avoids other installed packages diverting help on e.g. qr()
and plot() to themselves.
No, as lattice is not a 'standard' package.
So can I proceed under the assumption that \code{\link{panel.xyplot}} is
the correct methodology for linking to a functions in
another /recommended/ package?
Is this different when referring to a function in another,
non-recommended package (i.e. that \code{\link{panel.xyplot}} is
preferred in most situations)?
Thanks in advance,
Gavin
--
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Dr. Gavin Simpson [t] +44 (0)20 7679 0522
ECRC, UCL Geography, [f] +44 (0)20 7679 0565
Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/
UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
--
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Dr. Gavin Simpson [t] +44 (0)20 7679 0522
ECRC, UCL Geography, [f] +44 (0)20 7679 0565
Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/
UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Missing links on Windows and \link[bar]{foo}; clarification
On Tue, 2009-01-13 at 11:12 +, Prof Brian Ripley wrote:
> You would expect to see issues on Windows whilst checking, as
> cross-library links do not work on Windows (unless fixed up, which
> install.packages() does for some standard packages, not including
> lattice which is 'recommended' not 'standard'). And, depending where
> you install, perhaps during installation.
Thank you for your reply Prof. Ripley.
>
> Note that specifying \code{\link[lattice]{panel.xyplot}} just avoids
> the warnings: it still does not make a cross-library link work.
That covers Windows and I'm happy to leave those warnings in place. Is
the simpler form sufficient to make the required links on Linux (and
MacOSX...?); that seems the intention of R-exts.pdf, to me at least.
>
> As for R-devel: very likely processing of help will have changed
> completely before release, so that is one area where we do not want
> to know about problems as yet, and anything in the NEWS file is
> provisional (some of the changes mentioned there may be reverted).
Yes, I realised that R-devel was changing considerably in this regard;
one of the reasons I was going through my Rd files was to fix-up some
problems with the mark-up that the new parser identified. Some changes I
made (not related to the parser version 2 warnings) triggered these
warnings on R-Forge.
All the best,
Gavin
>
> On Tue, 13 Jan 2009, Gavin Simpson wrote:
>
> > Dear List,
> >
> > In one of my packages on R-Forge I have a custom panel function for
> > Lattice graphics. In the Rd file for this panel function I want to
> > provide links to some lattice functions (in package lattice). My first
> > instinct was to use:
> >
> > \code{\link[lattice]{panel.xyplot}}
> >
> > for example. However, I missed a few references to lattice functions and
> > just marked them up as \code{\link{panel.xyplot}}.
> >
> > For the latter, I am getting warnings about missing links during package
> > check and installation *only* on Windows and *only* on R patched
> > (R-Forge version: R version 2.8.1 Patched (2009-01-12 r47554)).
> >
> > With R Devel (R-Forge version: 2.9.0 Under development (unstable)
> > (2009-01-10 r47538)) under Windows no warnings are issued.
> >
> > The R-exts manual mentions that the first style is rarely needed, yet
> > the warnings on R-patched suggest that [currently] it is, for CHM help
> > only, which is where I presume the warnings are being generated.
> >
> > Is the change in R Devel intentional or a side-effect of other changes
> > that is yet to be fixed? (I appreciate that this version of R is still
> > under development and unstable.) Is this difference between versions
> > related to (from NEWS)?:
> >
> > o HTML links will be resolved first to the standard packages: this
> > avoids other installed packages diverting help on e.g. qr()
> > and plot() to themselves.
>
> No, as lattice is not a 'standard' package.
>
> > So can I proceed under the assumption that \code{\link{panel.xyplot}} is
> > the correct methodology for linking to a functions in
> > another /recommended/ package?
> >
> > Is this different when referring to a function in another,
> > non-recommended package (i.e. that \code{\link{panel.xyplot}} is
> > preferred in most situations)?
> >
> > Thanks in advance,
> >
> > Gavin
> > --
> > %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
> > Dr. Gavin Simpson [t] +44 (0)20 7679 0522
> > ECRC, UCL Geography, [f] +44 (0)20 7679 0565
> > Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
> > Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/
> > UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
> > %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
> >
> >
>
--
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Dr. Gavin Simpson [t] +44 (0)20 7679 0522
ECRC, UCL Geography, [f] +44 (0)20 7679 0565
Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/
UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package Matrix does not compile in R-devel_2009-01-10
I've discovered that Mac OS still has a FreeBSD make with which I can reproduce this. So I am working with Martin on a patch for the next Matrix update. Meanwhile, if there is an issue with building R-devel with GNU make under FreeBSD (e.g. env MAKE=gmake ./configure env MAKE=gmake make ) we would like to know what it is (see the inline comment in my first reply). On Mon, 12 Jan 2009, Rainer Hurling wrote: Thank you Brian, for this detailed answer. I think you are right with the new rules. Before contacting the maintainers I will try to collect some more information about the observed failure. Without setting the environment variable MAKE to gmake, I get excatly the same break when installing Matrix under R-2.8.1. So I can test it under 2.8.1. Rainer On 11.01.2009 23:42 (UTC+1), Prof Brian Ripley wrote: You need to take this up with the package maintainers: although recommended packages are distributed with R, they are still contributed packages with separate maintainers. At one point Matrix did work with a non-GNU make (the Solaris one) after suggestions from R-core members on how to remove the obvious GNUisms. It would cetainly be helpful to let the package maintainers know what changes do work. (I presume the issue is amd_i_%.o: amd_%.c $(INC) $(CC) $(ALL_CPPFLAGS) $(ALL_CFLAGS) -I../Include -DDINT -c $< -o $@ amd_l_%.o: amd_%.c $(INC) $(CC) $(ALL_CPPFLAGS) $(ALL_CFLAGS) -I../Include -DDLONG -c $< -o $@ which are new rules since I was able to test.) Unfortunately I can no longer build Matrix (and hence R-devel) on Solaris, as the Sun Studio compilers say some of the C++ code is invalid (and it looks so to me, and I reported it a while back): the file is spqr_front.cpp, so it has not got as far as the point that is giving you trouble. On Sun, 11 Jan 2009, Rainer Hurling wrote: Dear developers, today I tried to build and install R-devel_2009-01-10 on FreeBSD 8.0-CURRENT (i386) for testing purposes. All went well until compiling the now recommended (integrated) Matrix package. At this point the following break occured: begin installing recommended package Matrix * Installing *source* package 'Matrix' ... ** libs gcc -std=gnu99 -I/usr/local/R-devel/include -I./UFconfig -I/usr/local/include -fpic -g -O2 -c CHMfactor.c -o CHMfactor.o [..snip..] gcc -std=gnu99 -I/usr/local/R-devel/include -I../Include -I../../UFconfig -I/usr/local/include-fpic -g -O2 -c colamd_global.c -o colamd_global.o gcc -std=gnu99 -I/usr/local/R-devel/include -I../Include -I../../UFconfig -I/usr/local/include-fpic -g -O2 -I../Include -DDLONG -c colamd.c -o colamd_l.o ar -rucs ../../COLAMD.a colamd_global.o colamd_l.o # colamd.o ( cd Source ; make lib ) gcc -std=gnu99 -I/usr/local/R-devel/include -I../Include -I../../UFconfig -I/usr/local/include-fpic -g -O2 -c amd_global.c -o amd_global.o make: don't know how to make amd_l_1.o. Stop *** Error code 2 Stop in /tmp/Rtmpx5nUS8/R.INSTALL10d63af1/Matrix/src/AMD. *** Error code 1 Stop in /tmp/Rtmpx5nUS8/R.INSTALL10d63af1/Matrix/src. ERROR: compilation failed for package 'Matrix' * Removing '/usr/local/R-devel/library/Matrix' *** Error code 1 Stop in /usr/local/R-devel/src/library/Recommended. *** Error code 1 Stop in /usr/local/R-devel/src/library/Recommended. *** Error code 1 Stop in /usr/local/R-devel. Please note, that on FreeBSD there is a BSD 'make' as default. If I want to use gmake instead, I explicitly have to set it. Unfortunately this does not work within building the whole R-devel system. It would be helpful to know why not. AFAIK GNU make works on other platforms with their own make. With R-2.8.1 I have no problems installing and using R. When I want to build the (external) Matrix package I have to set an environment variable to gmake, found at /usr/local/bin/gmake and all works well. Now my question: Is it possible to change the configure/build of the integrated Matrix package on R-devel? For all other packages there is no need to do so (at least for FreeBSD ;-) Please let me know if I can help. Thanks in advance, Rainer Hurling -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Missing links on Windows and \link[bar]{foo}; clarification
You would expect to see issues on Windows whilst checking, as
cross-library links do not work on Windows (unless fixed up, which
install.packages() does for some standard packages, not including
lattice which is 'recommended' not 'standard'). And, depending where
you install, perhaps during installation.
Note that specifying \code{\link[lattice]{panel.xyplot}} just avoids
the warnings: it still does not make a cross-library link work.
As for R-devel: very likely processing of help will have changed
completely before release, so that is one area where we do not want
to know about problems as yet, and anything in the NEWS file is
provisional (some of the changes mentioned there may be reverted).
On Tue, 13 Jan 2009, Gavin Simpson wrote:
Dear List,
In one of my packages on R-Forge I have a custom panel function for
Lattice graphics. In the Rd file for this panel function I want to
provide links to some lattice functions (in package lattice). My first
instinct was to use:
\code{\link[lattice]{panel.xyplot}}
for example. However, I missed a few references to lattice functions and
just marked them up as \code{\link{panel.xyplot}}.
For the latter, I am getting warnings about missing links during package
check and installation *only* on Windows and *only* on R patched
(R-Forge version: R version 2.8.1 Patched (2009-01-12 r47554)).
With R Devel (R-Forge version: 2.9.0 Under development (unstable)
(2009-01-10 r47538)) under Windows no warnings are issued.
The R-exts manual mentions that the first style is rarely needed, yet
the warnings on R-patched suggest that [currently] it is, for CHM help
only, which is where I presume the warnings are being generated.
Is the change in R Devel intentional or a side-effect of other changes
that is yet to be fixed? (I appreciate that this version of R is still
under development and unstable.) Is this difference between versions
related to (from NEWS)?:
o HTML links will be resolved first to the standard packages: this
avoids other installed packages diverting help on e.g. qr()
and plot() to themselves.
No, as lattice is not a 'standard' package.
So can I proceed under the assumption that \code{\link{panel.xyplot}} is
the correct methodology for linking to a functions in
another /recommended/ package?
Is this different when referring to a function in another,
non-recommended package (i.e. that \code{\link{panel.xyplot}} is
preferred in most situations)?
Thanks in advance,
Gavin
--
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Dr. Gavin Simpson [t] +44 (0)20 7679 0522
ECRC, UCL Geography, [f] +44 (0)20 7679 0565
Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/
UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Missing links on Windows and \link[bar]{foo}; clarification
Dear List,
In one of my packages on R-Forge I have a custom panel function for
Lattice graphics. In the Rd file for this panel function I want to
provide links to some lattice functions (in package lattice). My first
instinct was to use:
\code{\link[lattice]{panel.xyplot}}
for example. However, I missed a few references to lattice functions and
just marked them up as \code{\link{panel.xyplot}}.
For the latter, I am getting warnings about missing links during package
check and installation *only* on Windows and *only* on R patched
(R-Forge version: R version 2.8.1 Patched (2009-01-12 r47554)).
With R Devel (R-Forge version: 2.9.0 Under development (unstable)
(2009-01-10 r47538)) under Windows no warnings are issued.
The R-exts manual mentions that the first style is rarely needed, yet
the warnings on R-patched suggest that [currently] it is, for CHM help
only, which is where I presume the warnings are being generated.
Is the change in R Devel intentional or a side-effect of other changes
that is yet to be fixed? (I appreciate that this version of R is still
under development and unstable.) Is this difference between versions
related to (from NEWS)?:
o HTML links will be resolved first to the standard packages: this
avoids other installed packages diverting help on e.g. qr()
and plot() to themselves.
So can I proceed under the assumption that \code{\link{panel.xyplot}} is
the correct methodology for linking to a functions in
another /recommended/ package?
Is this different when referring to a function in another,
non-recommended package (i.e. that \code{\link{panel.xyplot}} is
preferred in most situations)?
Thanks in advance,
Gavin
--
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Dr. Gavin Simpson [t] +44 (0)20 7679 0522
ECRC, UCL Geography, [f] +44 (0)20 7679 0565
Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/
UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
signature.asc
Description: This is a digitally signed message part
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R as a scripting engine
Dirk Eddelbuettel wrote: > On 11 January 2009 at 20:18, Prof Brian Ripley wrote: > | Those of you tracking R development will have noticed that we are > | moving towards using R as a scripting engine. > [...] > | Reasons: > | > | - it is platform-independent and needs no other tools installed. > [...] > | - it is fast. > [...] > > Indeed. I really like working with r scripts. > > And littler by Horner and Eddelbuettel is faster than Rscript -- see eg the > scripts tests/timing.sh and tests/timing2.sh in the SVN archive / littler > tarballs (and the results below for illustration). > > We should still appreciate it you could finally acknowledge existence of > littler it in the R / Rscript documentation. You are not doing users any > service by pretending it doesn't exist. > > will anyone ever bother to answer? is silence to be taken as acknowledgement, or rather a7e? vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] x <- 1:2; dim(x) <- 2? A vector or not?
What you have is a one-dimensional array: they crop up in R most often from table() in my experience. f <- table(rpois(100, 4)) str(f) 'table' int [, 1:10] 2 6 18 21 13 16 13 4 3 4 - attr(*, "dimnames")=List of 1 ..$ : chr [1:10] "0" "1" "2" "3" ... and yes, f is an atmoic vector and yes, str()'s notation is confusing here but if it did [1:10] you would not know it was an array. I recall discussing this with Martin Maechler (str's author) last century, and I've just checked that R 2.0.0 did the same. The place in which one-dimensional arrays differ from normal vectors is how names are handled: notice that my example has dimnames not names, and ?names says For a one-dimensional array the 'names' attribute really is 'dimnames[[1]]'. I think these days we have enough internal glue in place that an end user would not notice the difference (but those working at C level with R objects may need to know). On Mon, 12 Jan 2009, Henrik Bengtsson wrote: Ran into the follow intermediate case in an external package (w/ recent R v2.8.1 patched and R v2.9.0 devel): x <- 1:2 dim(x) <- 2 dim(x) [1] 2 x [1] 1 2 str(x) int [, 1:2] 1 2 nrow(x) [1] 2 ncol(x) [1] NA is.vector(x) [1] FALSE is.matrix(x) [1] FALSE is.array(x) [1] TRUE x[1] [1] 1 x[,1] Error in x[, 1] : incorrect number of dimensions x[1,] Error in x[1, ] : incorrect number of dimensions Is str() treating single-dimension arrays incorrectly? What does it mean to have a single dimension this way? Should it equal a vector? I am aware of "is.vector returns FALSE if x has any attributes except names". /Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
