[Rd] Use of PACKAGE= argument in .C etc calls
As from R 2.0.0, R CMD check has not flagged .C etc calls without a
PACKAGE argument in packages with a namespace. Unfortunately that was
based on too optimistic assumptions.
1) The mechanism to find the DLL from the namespace only works if the DLL
is declared via a useDynLib declaration in NAMESPACE (and only if there is
one such declaration). This is checked in R-devel.
2) In 2.1.1, the mechanism only finds the DLL correctly for functions
defined at the top level in a namespace, and not for example for functions
defined inside functions or as S4 methods. There is an enhanced
mechanism in R-devel.
3) Prior to 2.1.1, a bug meant that the mechanism often found the
incorrect namespace, and there was not mechanism at all prior to 2.0.0 (I
believe).
For compatibility with 2.1.x and earlier a PACKAGE= argument is needed in
many more calls than are flagged by R-devel's 'check'. To check this,
use
> library(tools)
> checkFF("my_package", verbose=TRUE)
for example:
> checkFF("mgcv", verbose=TRUE)
.C("construct_cr", ...): OK
.C("predict_tprs", ...): OK
.C("MinimumSeparation", ...): OK
.C("update_beta", ...): MISSING but in a function in a namespace
.C("update_beta", ...): MISSING but in a function in a namespace
.C("magic", ...): OK
.C("mgcv", ...): OK
.C("RMonoCon", ...): OK
.C("RPCLS", ...): OK
.C("construct_cr", ...): OK
.C("construct_tprs", ...): OK
.C("RuniqueCombs", ...): OK
where the qualified MISSING reports need attention.
Botton line: always use a PACKAGE= argument unless you are only intending
your package to be used with (pre-)2.2.0 or later.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] capabilities() and non-catchable messages
Just for the record (not a request for fix) and an ad hoc workaround if
anyone needs it:
REASON:
Running an R script as a plugin on a remote Suse Linux 8.2 with R v2.1.0
(2005-04-18), I have noticed that capabilities() generates (to standard
error)
Xlib: connection to "base:0.0" refused by server
Xlib: Client is not authorized to connect to Server
which cannot be caught by tryCatch();
tryCatch({
print(capabilities());
}, condition=function(c) {
cat("Condition caught:\n");
str(c);
})
because it is not a 'condition' (error or warning).
CONTEXT:
Since source() calls capabilities("iconv") this messages always show up.
My R plugin loads custom code using source() and since the standard
error from the plugin is checked for messages, the host system
interprets this as if something problematic has occured.
WORKAROUND:
The workaround that I use now is to redefine capabilities() temporarily
(since I do not need "iconv" support):
orgCapabilities <- base::capabilities;
basePos <- which(search() == "package:base"));
assign("capabilities", function(...) FALSE, pos=basePos);
source()
basePos <- which(search() == "package:base"));
assign("capabilities", orgCapabilities, pos=basePos);
rm(orgCapabilities)
Cheers
Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] capabilities() and non-catchable messages
Would using 'capture.output()' work for you in this case?
-roger
Henrik Bengtsson wrote:
> Just for the record (not a request for fix) and an ad hoc workaround if
> anyone needs it:
>
> REASON:
> Running an R script as a plugin on a remote Suse Linux 8.2 with R v2.1.0
> (2005-04-18), I have noticed that capabilities() generates (to standard
> error)
>
>Xlib: connection to "base:0.0" refused by server
>Xlib: Client is not authorized to connect to Server
>
> which cannot be caught by tryCatch();
>
>tryCatch({
> print(capabilities());
>}, condition=function(c) {
> cat("Condition caught:\n");
> str(c);
>})
>
> because it is not a 'condition' (error or warning).
>
> CONTEXT:
> Since source() calls capabilities("iconv") this messages always show up.
> My R plugin loads custom code using source() and since the standard
> error from the plugin is checked for messages, the host system
> interprets this as if something problematic has occured.
>
> WORKAROUND:
> The workaround that I use now is to redefine capabilities() temporarily
> (since I do not need "iconv" support):
>
> orgCapabilities <- base::capabilities;
> basePos <- which(search() == "package:base"));
> assign("capabilities", function(...) FALSE, pos=basePos);
>
> source()
>
> basePos <- which(search() == "package:base"));
> assign("capabilities", orgCapabilities, pos=basePos);
> rm(orgCapabilities)
>
> Cheers
>
> Henrik
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Craving for Rolexes or omegas? (PR#7959)
Don't extract every cent from youraccount just to gget one brandname vvatch. Flnd affordableones from Rolexes, Cartiers, Bvlgaries, FrankMullers, Harry Winstons, Breguets, Jaeger-lecoultre, Brietilings, Tag Heuers and Tudors. See our convincing beauties that have logos and SerialNumber. We are artists that make ccheaper ones l00k including the classics. Can't vvait to see the picture of our vvatch? Pop into our zone right novv. http://ywed.1.arealleader.com/jwc/ Our goods might take only one third or even one tenth of the prototypes. They are waterproof and madefrom stainlessteel. Gget the vvatches with durable stainlesssteel substance. Take a ccheck at our vvatches with diverse energies. Pur-chase either battery&quartz ones or ant0-matic mechanics. Our vvatches l00k and operate great as the classics. They have sophisticated features like HACK mechanism and stainlesssteelback. ated five shillings, all in should have been seen by Anne; but she had staid at home, `Ah, do but listen. Recently I went to make peace between them.' halfpence, aunder the mixed plea of a headache of her own, and some return Atop him... she straddles his chest... her breasts in hisface. He cups her breasts. She leans down, kisses him... nd twopencJOHNNY BOZ is in his late 40's, slim, good-looking. We don'tsee the woman's face. She has long blonde hair. The CAMERASTAYS BEHIND and to the side of them. e halfpenny short - as it took a `Well, and what was the upshot?' n immense time and a great waste of arithmetic, to e `That's the most interesting part. This couple turned out to be a most happy one - a government clerk and his lady. The government clerk lodges a complaint, whereupon I become a mediator - and what a mediator!... I assure you Talleyrand was a nobody compared to me.' ndeavour with out any e __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] capabilities() and non-catchable messages
No; I've tried/do that too.
/Henrik
Roger D. Peng wrote:
> Would using 'capture.output()' work for you in this case?
>
> -roger
>
> Henrik Bengtsson wrote:
>
>>Just for the record (not a request for fix) and an ad hoc workaround if
>>anyone needs it:
>>
>>REASON:
>>Running an R script as a plugin on a remote Suse Linux 8.2 with R v2.1.0
>>(2005-04-18), I have noticed that capabilities() generates (to standard
>>error)
>>
>> Xlib: connection to "base:0.0" refused by server
>> Xlib: Client is not authorized to connect to Server
>>
>>which cannot be caught by tryCatch();
>>
>> tryCatch({
>> print(capabilities());
>> }, condition=function(c) {
>> cat("Condition caught:\n");
>> str(c);
>> })
>>
>>because it is not a 'condition' (error or warning).
>>
>>CONTEXT:
>>Since source() calls capabilities("iconv") this messages always show up.
>>My R plugin loads custom code using source() and since the standard
>>error from the plugin is checked for messages, the host system
>>interprets this as if something problematic has occured.
>>
>>WORKAROUND:
>>The workaround that I use now is to redefine capabilities() temporarily
>>(since I do not need "iconv" support):
>>
>> orgCapabilities <- base::capabilities;
>> basePos <- which(search() == "package:base"));
>> assign("capabilities", function(...) FALSE, pos=basePos);
>>
>> source()
>>
>> basePos <- which(search() == "package:base"));
>> assign("capabilities", orgCapabilities, pos=basePos);
>> rm(orgCapabilities)
>>
>>Cheers
>>
>>Henrik
>>
>>__
>>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] Revised scatter.smooth using xy.coords
Hi
Thanks for these suggestions Kevin.
These are now in the development version of R.
Paul
[EMAIL PROTECTED] wrote:
> This started when I discovered that scatter.smooth (R 2.1.0) has an
> undocumented ability to use a formula as the first argument. Then I
> discovered the xy.coords function, which seems like a natural fit and a
> way to unify scatter.smooth with other plotting functions, so I offer here
> a revised version of scatter.smooth that uses the xy.coords function.
>
>
> scatter.smooth <- function (x, y=NULL, span = 2/3, degree = 1,
> family = c("symmetric", "gaussian"),
> xlab = NULL,
> ylab = NULL,
> ylim = range(y, prediction$y, na.rm = TRUE),
> evaluation = 50, ...) {
> xlabel <- if (!missing(x))
> deparse(substitute(x))
> ylabel <- if (!missing(y))
> deparse(substitute(y))
> xy <- xy.coords(x, y, xlabel, ylabel)
>
> x <- xy$x
> y <- xy$y
> xlab <- if(is.null(xlab)) xy$xlab
> else xlab
> ylab <- if(is.null(ylab)) xy$ylab
> else ylab
>
> # if (inherits(x, "formula")) {
> #if (length(x) < 3)
> # stop("need response in formula")
> #thiscall <- match.call()
> #thiscall$x <- x[[3]]
> #thiscall$y <- x[[2]]
> #return(invisible(eval(thiscall, sys.parent(
> # }
> prediction <- loess.smooth(x, y, span, degree, family, evaluation)
> plot(x, y, ylim = ylim, xlab = xlab, ylab = ylab, ...)
> lines(prediction)
> invisible()
> }
>
> 1. I commented out some existing code and my revisions appear before the
> commented block.
>
> 2. The argument list has changed slightly. The original arguments were:
> y
> xlab=deparse(substitute(x))
> ylab=deparse(substitute(y))
>
> 3. With the suggested change, the following examples now work as one
> would expect
>
> attach(cars)
> scatter.smooth(speed,dist,main="dist,speed")
> scatter.smooth(speed,dist,main="dist,speed",xlab="",ylab="")
> scatter.smooth(cars,main="cars")
> scatter.smooth(cars,main="cars",xlab="Speed",ylab="Distance")
> scatter.smooth(dist~speed,main="dist~speed")
> scatter.smooth(dist~speed,main="dist~speed",xlab="")
> scatter.smooth(dist~speed,main="dist~speed",ylab="")
>
> 4. If this revision is accepted, the help page for scatter.smooth should
> probably be updated, perhaps using the same definition of the x,y
> arguments in the plot.default help page.
>
> Best,
>
> Kevin Wright
>
> __
> R-devel@stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
[EMAIL PROTECTED]
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
