[Rd] Principal Components Analysis (PR#8320)
Full_Name: Sahotra Sarkar Version: 2.2.0 OS: Windows XP Professional Submission from: (NULL) (146.6.130.180) The following two commands should give the same results for the eigenvectors but do not (there is a sign reversal for the first one): > summary(princomp(bumpus),loading = TRUE) Importance of components: Comp.1Comp.2 Comp.3 Comp.4 Comp.5 Standard deviation 6.2801653 2.4285636 1.13995042 0.560733747 0.03458915 Proportion of Variance 0.8399662 0.1256084 0.02767525 0.006696272 0.2548 Cumulative Proportion 0.8399662 0.9655746 0.99324988 0.46156 0.7164 Comp.6 Comp.7 Comp.8 Comp.9 Standard deviation 3.025628e-02 1.405339e-02 1.147326e-02 9.339938e-03 Proportion of Variance 1.949623e-05 4.206121e-06 2.803451e-06 1.857837e-06 Cumulative Proportion 9.11e-01 9.53e-01 9.81e-01 1.00e+00 Loadings: Comp.1 Comp.2 Comp.3 Comp.4 Comp.5 Comp.6 Comp.7 Comp.8 Comp.9 V1 0.497 0.851 0.171 V2 0.853 -0.515 V3 0.149 0.103 -0.965 0.189 V4 -0.180 -0.981 V5 -0.288 0.568 0.327 0.693 V6 -0.399 0.565 0.154 -0.705 V7 -0.867-0.475 -0.107 V80.352 -0.926 0.118 V9 0.994 > eigen(cov(bumpus)) $values [1] 3.973263e+01 5.941610e+00 1.309113e+00 3.167514e-01 1.205271e-03 9.33e-04 [7] 1.989606e-04 1.326107e-04 8.788062e-05 $vectors [,1] [,2] [,3] [,4] [,5] [1,] -0.496897319 0.8505093640 0.171388489 0.018744742 -0.0002708851 [2,] -0.852790441 -0.5152155401 0.081515933 0.025301353 0.0031275939 [3,] -0.149011771 0.1032588064 -0.965116017 0.188813583 0.0029039523 [4,] -0.059981091 0.0228574697 -0.180065518 -0.981007482 0.0301789269 [5,] -0.002474454 -0.0009781164 -0.003402721 -0.011404980 -0.2884751568 [6,] -0.002255070 -0.0003234929 -0.002776659 -0.014386855 -0.3990284747 [7,] -0.003505091 -0.0005603692 -0.006526439 -0.022328724 -0.8671382015 [8,] -0.001124313 0.0005858447 -0.003031985 -0.006957916 -0.0674635788 [9,] -0.003810707 0.0004531193 -0.006127501 -0.009908937 -0.0122192249 [,6] [,7] [,8] [,9] [1,] -0.001028476 1.638253e-06 0.0004887328 -0.0003561342 [2,] -0.002350593 -8.313864e-04 -0.0003929312 0.0005026715 [3,] -0.004636198 8.031165e-05 0.0015963693 0.0010649875 [4,] -0.011239114 -5.568762e-03 0.0035062479 0.0003785351 [5,] 0.083901242 5.675807e-01 0.3265320650 -0.6934139460 [6,] 0.032231827 5.646388e-01 0.1541661011 0.7049350072 [7,] -0.058318858 -4.748060e-01 -0.1070487286 -0.0849487969 [8,] 0.014813290 3.516922e-01 -0.9260185177 -0.1182046449 [9,] 0.994055719 -9.937481e-02 -0.0249932592 0.0324567705 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Chi-squared test (PR#9350)
Full_Name: Sahotra Sarkar Version: 2.2.0 OS: Windows XP Submission from: (NULL) (128.83.34.44) This is not a bug: I'm just wondering why chisq.test does not allow the specification of the degree of freedom (df). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] hist.default documentation
I think there are a couple of things in ?hist that are not quite as
clear as they could be.
(1)
freq: logical; if 'TRUE', the histogram graphic is a representation
of frequencies, the 'counts' component of the result; if
'FALSE', _relative_ frequencies ("probabilities"), component
'density', are plotted. Defaults to 'TRUE' _iff_ 'breaks'
are equidistant (and 'probability' is not specified).
Unless I'm missing something, the 'density' component is NOT relative
frequency or 'probability' in any reasonable sense, country-specific
biases notwithstanding, except in the very special case where
all(diff(breaks) == 1). Thus, the above description is confusing and
probably even wrong.
Also, it seems to me that hist cannot draw a relative frequency
histogram at all (which is not a bad thing, but it's of course very
important to the undergrads we're teaching intro stats and R to). This
should be explicitly mentioned.
(2)
breaks: one of:
...
* a single number giving the number of cells for the
histogram,
...
This is not quite true. 'breaks' is used in 'pretty', so it's more a
suggestion than an exact specification. I'm not sure whether or not
the behaviour should be changed (what's the point of having ``pretty''
breakpoints anyway?), but if not, the documentation should be
clarified.
I'll be happy to provide a patch if these changes are considered reasonable.
Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] hist.default documentation
On 6/17/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> On 6/17/2005 8:58 AM, Deepayan Sarkar wrote:
> > I think there are a couple of things in ?hist that are not quite as
> > clear as they could be.
> >
> > (1)
> >
> > freq: logical; if 'TRUE', the histogram graphic is a representation
> > of frequencies, the 'counts' component of the result; if
> > 'FALSE', _relative_ frequencies ("probabilities"), component
> > 'density', are plotted. Defaults to 'TRUE' _iff_ 'breaks'
> > are equidistant (and 'probability' is not specified).
> >
> > Unless I'm missing something, the 'density' component is NOT relative
> > frequency or 'probability' in any reasonable sense, country-specific
> > biases notwithstanding, except in the very special case where
> > all(diff(breaks) == 1). Thus, the above description is confusing and
> > probably even wrong.
>
> I agree.
>
> > Also, it seems to me that hist cannot draw a relative frequency
> > histogram at all (which is not a bad thing, but it's of course very
> > important to the undergrads we're teaching intro stats and R to). This
> > should be explicitly mentioned.
>
> I'm not sure about this. Is it really worth mentioning something if you
> can't do it? Are you thinking of just giving a reference to barplot?
Not mentioning it is fine.
> > (2)
> >
> > breaks: one of:
> >
> > ...
> > * a single number giving the number of cells for the
> > histogram,
> > ...
> >
> > This is not quite true. 'breaks' is used in 'pretty', so it's more a
> > suggestion than an exact specification. I'm not sure whether or not
> > the behaviour should be changed (what's the point of having ``pretty''
> > breakpoints anyway?), but if not, the documentation should be
> > clarified.
>
> I like the pretty breakpoints. It is good to label the breakpoints, and
> ugly to have labels at other than pretty points. I'd clarify by
> changing "giving" to "suggesting".
Actually, I missed the remark just below this:
In the last three cases the number is a suggestion only.
so this is fine as it is.
> > I'll be happy to provide a patch if these changes are considered reasonable.
>
> Please do.
Here's the output of svn diff. Is this a reasonable way of providing a patch?
Index: hist.Rd
===
--- hist.Rd (revision 34748)
+++ hist.Rd (working copy)
@@ -28,9 +28,9 @@
}
\item{freq}{logical; if \code{TRUE}, the histogram graphic is a
representation of frequencies, the \code{counts} component of
-the result; if \code{FALSE}, \emph{relative} frequencies
-(\dQuote{probabilities}), component \code{density},
-are plotted. Defaults to \code{TRUE} \emph{iff} \code{breaks} are
+the result; if \code{FALSE}, probability densities, component
+\code{density}, are plotted (so that the histogram has a total area
+of one). Defaults to \code{TRUE} \emph{iff} \code{breaks} are
equidistant (and \code{probability} is not specified).}
\item{probability}{an \emph{alias} for \code{!freq}, for S compatibility.}
\item{include.lowest}{logical; if \code{TRUE}, an \code{x[i]} equal to
Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD check failing to warn when it should
Hi, I recently made changes to lattice code which needed changes in many man pages as well. Before I made the appropriate changes, R CMD check was flagging most of the problems correctly, except for the man page for tmd. I have created a toy package that shows this, available at http://www.stat.wisc.edu/~deepayan/R/tmdprob_0.12-2.tar.gz This passes R CMD check on R 2.1.0 and r-devel from August 1, but it shouldn't because the code and documentation are inconsistent. Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] histogram method for S4 class.
On 8/24/05, ernesto <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm trying to develop an histogram method for a class called "FLQuant"
> which is used by the package FLCore (http://flr-project.org). FLQuant is
> an extension to "array". There is an as.data.frame method that coerces
> flquant into a data.frame suitable for lattice plotting. The problem is
> that when I coerce the object and plot it after it works but if the
> method is applied within the histogram method it does not work. See the
> code below (the FLCore package is here
> http://prdownloads.sourceforge.net/flr/FLCore_1.0-1.tar.gz?download)
>
> > library(FLCore)
> Loading required package: lattice
> > data(ple4)
> > histogram(~data|year, [EMAIL PROTECTED])
> Error in inherits(x, "factor") : Object "x" not found
> > histogram(~data|year, data=as.data.frame([EMAIL PROTECTED]))
>
> The catch.n slot is a FLQuant object and the code for histogram is the
> following
>
> setMethod("histogram", signature(formula="formula", data="FLQuant"),
> function (formula, data = parent.frame(), allow.multiple =
> is.null(groups) || outer,
> outer = FALSE, auto.key = FALSE, aspect = "fill", panel =
> "panel.histogram", prepanel = NULL,
> scales = list(), strip = TRUE, groups = NULL, xlab, xlim, ylab,
> ylim,
> type = c("percent", "count", "density"),
> nint = if (is.factor(x)) length(levels(x)) else
> round(log2(length(x)) + 1),
> endpoints = extend.limits(range(x[!is.na(x)]), prop = 0.04),
> breaks = if (is.factor(x)) seq(0.5, length = length(levels(x)) +
> 1) else do.breaks(endpoints, nint),
> equal.widths = TRUE, drop.unused.levels =
> lattice.getOption("drop.unused.levels"), ...,
> default.scales = list(), subscripts = !is.null(groups), subset =
> TRUE) {
>
> qdf <- as.data.frame(data)
>
> histogram(formula, data = qdf, allow.multiple = allow.multiple,
> outer = outer,
> auto.key = auto.key, aspect = aspect, panel = panel,
> prepanel = prepanel, scales = scales,
> strip = strip, groups = groups, xlab=xlab, xlim=xlim,
> ylab=ylab, ylim=ylim, type = type,
> nint = nint, endpoints = endpoints, breaks = breaks,
> equal.widths = equal.widths,
> drop.unused.levels = drop.unused.levels, ..., default.scales
> = default.scales,
> subscripts = subscripts, subset = subset)
> }
> )
>
>
> Any ideas ?
[I'm CC-ing to r-devel, please post follow-ups there]
What version of lattice are you using? Please use the latest one, in
which histogram is an S3 generic, with only one argument, formula. The
eventual solution to your problem may involve changing that, but the
first question to ask is whether any other formula makes sense in your
context (if not, I would rather keep one argument and dispatch on
signature(formula = "FLQuant").
Disclaimer: I haven't actually had time to check out FLCore yet, I
will as soon as I can.
Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fwd: segfault
On Monday 29 August 2005 03:35, Prof Brian Ripley wrote:
> It does not crash for me on either Windows or Linux, but it does take a
> long time and the plot is a mess, so there does seem to be a
> lattice-related problem (maybe a usage one).
It is improper (or at least unanticipated) usage. The example cited does not
crash X11 on GNU/Linux for me, but the following does:
wireframe(F ~ x * p, bt, groups = factor(p), shade=TRUE)
This involves some C code in lattice, which could well be the culprit. I'll
clarify the documentation, but I'm not sure how easy it would be to catch the
bug.
Deepayan
> However, I think the crash is a Mac (presumably quartz()) problem.
>
> On Mon, 29 Aug 2005, stefano iacus wrote:
> > This segfaults on OS X (10.4) on both X11 and quartz devices.
> > Seems a problem with lattice but I cannot test on other platforms
> > stefano
> >
> > Begin forwarded message:
> >> From: "G. Sawitzki" <[EMAIL PROTECTED]>
> >> Date: 28 agosto 2005 14:11:18 GMT+02:00
> >> To: [EMAIL PROTECTED]
> >>
> >>
> >> Dear Stefano,
> >>
> >> this small exaple leads to a crash of R. I did not try it on
> >> versions other than the Mac version. So I am sending it to you
> >> directly. If it is a littice problem, could you pass it to Deepayan
> >> Sarkar? Thank you.
> >>
> >> g.
> >>
> >> ==
> >> #pbinom
> >> library(grid)
> >> library(lattice)
> >>
> >> n<-20
> >> psteps<-50
> >> binomtable<- function (n,psteps){
> >> x<-(0:(10*n))/10
> >> p<- (0:psteps)/psteps
> >> dd<-expand.grid(x=x,p=p)
> >> dd$F<- pbinom(dd$x,n,dd$p)
> >> dd$x0<-trunc(dd$x)
> >> dd
> >> }
> >>
> >> bt<-binomtable(n=5,psteps=100)
> >> bt[bt$x-bt$x0>=0.9,]$F<-NA
> >> wireframe(bt$F~bt$x*bt$p,bt,groups=bt$x0,shade=TRUE) # leads to R
> >> crash
> >> #wireframe(bt$F~bt$x*bt$p,bt,shade=TRUE) #ok
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fwd: segfault
On 8/31/05, Byron Ellis <[EMAIL PROTECTED]> wrote:
> There's definitely something a bit strange going on. The arguments as
> passed to wireframePanelCalculations from the code snippet show only
> 6060 elements for the z vector (51,101,16 respectively for x,y,rot)
> while the function routinely tries to access at positions in the z
> vector >20,000... until it eventually falls over (how long this takes
> seems to depend on circumstances, I can actually get it to complete a
> run while running in gdb).
Thanks for tracking this down. It's unlikely that I'll be able to fix
this before R 2.2.0, but at least I know where to look when I do
tackle this.
> On Aug 30, 2005, at 10:12 AM, stefano iacus wrote:
>
> >
> > On 29/ago/05, at 10:35, Prof Brian Ripley wrote:
> >
> >
> >> It does not crash for me on either Windows or Linux, but it does
> >> take a
> >> long time and the plot is a mess, so there does seem to be a
> >> lattice-related problem (maybe a usage one).
> >>
> >> However, I think the crash is a Mac (presumably quartz()) problem.
> >>
> >>
> >
> > no, it also happens with the X11 device. BTW, it seems to be OS X
> > specific.
> > I'll try to debug
> > stefano
> >
> >
> >> On Mon, 29 Aug 2005, stefano iacus wrote:
> >>
> >>
> >>
> >>> This segfaults on OS X (10.4) on both X11 and quartz devices.
> >>> Seems a problem with lattice but I cannot test on other platforms
> >>> stefano
> >>>
> >>>
> >>> Begin forwarded message:
> >>>
> >>>
> >>>
> >>>> From: "G. Sawitzki" <[EMAIL PROTECTED]>
> >>>> Date: 28 agosto 2005 14:11:18 GMT+02:00
> >>>> To: [EMAIL PROTECTED]
> >>>>
> >>>>
> >>>> Dear Stefano,
> >>>>
> >>>> this small exaple leads to a crash of R. I did not try it on
> >>>> versions other than the Mac version. So I am sending it to you
> >>>> directly. If it is a littice problem, could you pass it to Deepayan
> >>>> Sarkar? Thank you.
> >>>>
> >>>> g.
> >>>>
> >>>> ==
> >>>> #pbinom
> >>>> library(grid)
> >>>> library(lattice)
> >>>>
> >>>> n<-20
> >>>> psteps<-50
> >>>> binomtable<- function (n,psteps){
> >>>> x<-(0:(10*n))/10
> >>>> p<- (0:psteps)/psteps
> >>>> dd<-expand.grid(x=x,p=p)
> >>>> dd$F<- pbinom(dd$x,n,dd$p)
> >>>> dd$x0<-trunc(dd$x)
> >>>> dd
> >>>> }
> >>>>
> >>>> bt<-binomtable(n=5,psteps=100)
> >>>> bt[bt$x-bt$x0>=0.9,]$F<-NA
> >>>> wireframe(bt$F~bt$x*bt$p,bt,groups=bt$x0,shade=TRUE) # leads to R
> >>>> crash
> >>>> #wireframe(bt$F~bt$x*bt$p,bt,shade=TRUE) #ok
> >>>>
> >>>>
> >>
> >> --
> >> 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
> >>
> >>
> >>
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> ---
> Byron Ellis ([EMAIL PROTECTED])
> "Oook" -- The Librarian
>
> __
> 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] more problems when using "installWithVers"
On Tuesday 04 October 2005 07:48, Prof Brian Ripley wrote:
> Tony,
>
> The problem is specific to your example:
> > install.packages("ash")
>
> ...
>
> > install.packages("ash", installWithVers=TRUE)
> > library("ash", version="1.0-9")
> > search()
>
> [1] ".GlobalEnv""package:ash_1.0-9" "package:methods"
> [4] "package:stats" "package:graphics" "package:grDevices"
> [7] "package:utils" "package:datasets" "Autoloads"
> [10] "package:base"
>
> and lies in lattice's .onLoad (as the message says, and hence the Cc: to
> Deepayan). That has
>
> .onLoad <- function(lib, pkg)
> {
> library.dynam(pkg, pkg, lib )
> lattice.options(.defaultLatticeOptions())
> lattice.setStatus(.defaultLatticeStatus())
> }
>
> which is incorrect: it should be library.dynam("lattice", pkg, lib)
> OTOH, 'ash' has it correctly and so works.
I'll upload a fixed version. There was a related discussion a while back about
having a PACKAGE= argument in .Call()'s, but I don't remember the details.
What's the current recommendation?
Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] extending lattice to S4 classes
On 10/18/05, ernesto <[EMAIL PROTECTED]> wrote:
> Prof Brian Ripley wrote:
>
> > I think you are confusing us: xyplot is an S3 generic with no 'data'
> > argument. It is xyplot.formula that you want to add dispatch on its
> > 'data' argument. I don't really see why you want to mix S3 and S4
> > systems, but you could make xyplot.formula an S3 or S4 generic and
> > dispatch on 'data', just as you did earlier with xyplot.
> >
> > Other xyplot methods need not (and probably do not) have a 'data'
> > argument.
> >
> > On Fri, 14 Oct 2005, ernesto wrote:
> >
> >> ernesto wrote:
> >>
> >>> Hi,
> >>>
> >>> I'm writing methods for a package called FLCore (see
> >>> http://flr-project.org/) in particular for a class called "FLQuant"
> >>> which extends array.
> >>>
> >>> Previously I was able to write methods based on the class of "data" but
> >>> now I can not do it due to the single parameter "x". Is there a way to
> >>> do this ?
> >>
> >
> >> I found an hack (see below) to make it work but it's terrible and hugly
> >> ... some suggestions are welcome. It simply tests if data belongs to
> >> class "FLQuant" and transforms it into a data.frame before ploting.
> >>
> >> Regards
> >>
> >> EJ
> >>
> >> if (!isGeneric("xyplot")) {
> >>setGeneric("xyplot", useAsDefault = xyplot)
> >> }
> >>
> >>
> >> setMethod("xyplot", signature("formula"), function(x, ...){
> >>
> >>dots <- list(...)
> >>if(class(dots$data)=="FLQuant") dots$data <- as.data.frame(dots$data)
> >>call.list <- c(x = x, dots)
> >>
> >> # needed this to avoid an infinite loop because xyplot is defined only
> >> for "x"
> >>xyplot <- lattice::xyplot
> >>ans <- do.call("xyplot", call.list)
> >>ans$call <- match.call()
> >>ans
> >>
> >> })
> >
> >
>
> Hi,
>
> Sorry to get back to this problem so late.
>
> I want to use lattice plots for an array. In this specific case this
> array is of class FLQuant which is defined by package FLCore.
>
> This array has 5 dimensions age, year, unit, season and area. My aim is
> to use formula to define what to plot and what to condition on. So
> procedures like used for barchart.table are not usefull for me because
> the user loses the option of defining the model to plot.
>
> With the previous version of lattice I was able to use formula and data
> to dispatch. So I defined S4 generic methods for most high level methods
> (bwplot, stripplot, dotplot, xyplot, histogram, etc) and simply
> transform FLQuant objects into dataframes that were passed to the
> lattice methods. No harm done to other data objects.
>
> With the new version only one object is available for dispatching "x" so
> if I define some xyplot.FLQuant I will miss the formula argument.
>
> My question is if there is a way of doing this or not.
Prof Ripley gave you one (redefine xyplot.formula etc). You could
always add new arguments to your methods, so you could have (the S4
equivalent of)
xyplot.FLQuant <- function(x, formula, ...)
{
xyplot(formula, data = as(x, "data.frame"), ...)
}
and then call
xyplot(flq.obj, formula = y ~ x, [...])
The cleanest solution would be to have a data argument in the xyplot
generic (with the expectation that it could be non-missing only for
methods where x is a formula). I'll try to implement that and see if
it causes any problems.
Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 'partial' in sort() inefficient?
I often need to work with large vectors whose distribution I want to
summarize by Q-Q plots. Since the vectors are large, I use a subset
of quantiles, e.g.
quantile(x, probs = ppoints(1000))
Unfortunately, this seemed to be taking too long for large x (much
longer than 'sort'). I initially thought maybe quantile was doing
something sophisticated (which I don't really need with a large data
set), so I would write something simple myself. I did, but then I
noticed that 'quantile' was doing essentially the same thing, with the
exception that it was calling 'sort' with a non-null 'partial'
argument.
?sort says:
If 'partial' is not 'NULL', it is taken to contain indices of
elements of 'x' which are to be placed in their correct positions
by partial sorting. After the sort, the values specified in
'partial' are in their correct position in the sorted array. Any
values smaller than these values are guaranteed to have a smaller
index in the sorted array and any values which are greater are
guaranteed to have a bigger index in the sorted array. This is
included for efficiency, and many of the options are not available
for partial sorting.
However, rather than being efficient, this seems to considerably slow
things down (I haven't checked memory efficiency). Consider the
following code (imitating what 'quantile' does by default):
probs <- ppoints(1000)
for (i in seq(5000, 5, 5000))
{
x <- rnorm(i)
n <- length(x)
index <- 1 + (n - 1) * probs
lo <- floor(index)
hi <- ceiling(index)
keep <- as.integer(unique(c(lo, hi)))
cat(system.time(y1 <- sort(x, partial = keep))[1])
cat("\t")
cat(system.time(y2 <- sort(x))[1])
cat("\t")
cat(round(max(abs( y1 - y2 )), digits = 3))
cat("\t")
cat(max(abs( y1[keep] - y2[keep] )))
cat("\n")
}
The first two columns in the output are timings for 'sort' with and
without 'partial', the last two columns are just a rough check that
partial sorting is doing what it claims. With R-2.2:
0.780 0.031 0
1.640.010.565 0
2.590.010.646 0
3.440.010.487 0
4.4 0.010.569 0
5.260.010.642 0
6.290.011.071 0
7.180.020.566 0
8.180.021.094 0
9.010.030.890
> version
_
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status Patched
major2
minor2.0
year 2005
month10
day 16
svn rev 35911
language R
This also holds on (a faster machine running) r-devel
0.390 0.176 0
0.850.010.620
1.320 0.193 0
1.8 0 0.949 0
2.290 0.730
2.770 1.185 0
3.250.010.813 0
3.750.011.171 0
4.210.010.827 0
4.740.010.372 0
> version
_
platform x86_64-unknown-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status Under development (unstable)
major2
minor3.0
year 2005
month11
day 25
svn rev 36468
language R
Speed improves when the number of 'partial' indices is small, but even
for 10 indices plain 'sort' is faster.
Am I missing something? I haven't checked if NA's make a difference
or if there might be memory usage issues, but even so, could
'quantile' at least have an option to disable partial sorting?
Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [ANN] bash completion for R
[This is of potential interest primarily to bash users and R package developers (hence the posting to r-devel only). Others, feel free to ignore.] I have been using bash's command completion features [1] for a while now, to the point where I expect everything to just work when I hit TAB. Since there was no bash completion for R (that I knew of), I took a stab at it myself last summer. This was my first major effort in bash programming, so it's far from perfect, but it mostly works. In case anyone's interested, the script is available at http://www.stat.wisc.edu/~deepayan/R/R.bash_completion which has more details on installation and use. Any feedback/improvements appreciated. -Deepayan [1] http://www.caliban.org/bash/#completion __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] defining a print method
On 1/4/06, Gabor Grothendieck <[EMAIL PROTECTED]> wrote:
> In the following session we define an xx class and a print method
> for it. If I invoke it with print then it prints as expected but if
> we just type xx at the R prompt then we get nothing back. How
> do we define the print method so that it works in the latter
> case too?
>
> > xx <- structure("abc", class = "xx")
> > print.xx <- function(x, ...) shQuote(x)
shQuote doesn't print anything, you probably want
print.xx <- function(x, ...) print(shQuote(x))
-Deepayan
> > print(xx) # ok
> [1] "\"abc\""
> > xx # no output
> >
> > sessionInfo()
> R version 2.2.1, 2005-12-20, i386-pc-mingw32
>
> attached base packages:
> [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
> [7] "base"
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] extending lattice to S4 classes
On 10/20/05, ernesto <[EMAIL PROTECTED]> wrote: [...] > Hi Deepayan, > > I see that there are alternatives, I found one my self that works and > it's transparent for the user. > > I don't want to implement solutions that force the user to use lattice > methods differently from your implementation. > > The cleanest solution as you say is to add a data argument to xyplot but > I can't do it so I would not propose it. FYI, I have added the 'data' argument to high level generics in lattice_0.13-1, available for r-devel (of course this causes the current version of FLCore to fail). Deepayan -- http://www.stat.wisc.edu/~deepayan/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug in rbind.data.frame: wrong rownames (PR#8506)
Hi,
there is a bug in the calculation of row names in rbind.data.frame.
When one of the arguments has 0 rows but is named in the call, this
mistakenly contributes an element in the "row.names" attribute of the
result, e.g.:
> foo <- data.frame(x = 1:10, y = rnorm(10))
> bar1 <- rbind.data.frame(foo[1:5,], foo[numeric(0),])
> dim(bar1)
[1] 5 2
> bar2 <- rbind.data.frame(a = foo[1:5,], b = foo[numeric(0),])
> dim(bar2)
[1] 6 2
> sessionInfo()
Version 2.3.0 Under development (unstable) (2006-01-17 r37109)
i686-pc-linux-gnu
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
[7] "base"
This happens because
> rownames(bar1)
[1] "1" "2" "3" "4" "5"
> rownames(bar2)
[1] "a.1" "a.2" "a.3" "a.4" "a.5" "b"
I think the following patch (to the 'Make.row.names' function defined
inside rbind.data.frame) fixes this:
-Deepayan
Index: src/library/base/R/dataframe.R
===
--- src/library/base/R/dataframe.R (revision 37109)
+++ src/library/base/R/dataframe.R (working copy)
@@ -886,7 +886,7 @@
if(nchar(nmi) > 0) {
if(ni > 1)
paste(nmi, ri, sep = ".")
- else nmi
+ else nmi[ri]
}
else if(nrow > 0 && identical(ri, 1:ni))
seq(from = nrow + 1, length = ni)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inappropriate warning in latticeExtra
On Fri, Mar 23, 2018 at 7:58 AM, Richard M. Heiberger wrote:
> The warning message in the last line of this email is incorrect.
> This is behavior which Duncan Murdoch labeled a bug in
>https://stat.ethz.ch/pipermail/r-help/2017-December/450494.html
Yes, sorry, this has been fixed in the r-forge sources for a while
now, but I haven't had the time to finish up some other fixes and push
an update to CRAN.
Hopefully over the summer break.
Regards,
-Deepayan
> This is a fresh install of R-devel (2018-03-21 r74436)
>
>
>
>
> R Under development (unstable) (2018-03-21 r74436) -- "Unsuffered
> Consequences"
> Copyright (C) 2018 The R Foundation for Statistical Computing
> Platform: x86_64-w64-mingw32/x64 (64-bit)
>
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
>
> Natural language support but running in an English locale
>
> R is a collaborative project with many contributors.
> Type 'contributors()' for more information and
> 'citation()' on how to cite R or R packages in publications.
>
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
>
>> library(latticeExtra)
> Error in library(latticeExtra) :
> there is no package called ‘latticeExtra’
>> install.packages("latticeExtra")
> Warning in install.packages("latticeExtra") :
> 'lib = "C:/Program Files/R/R-devel/library"' is not writable
> --- Please select a CRAN mirror for use in this session ---
> also installing the dependency ‘RColorBrewer’
>
> Warning: unable to access index for repository
> http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.5:
> cannot open URL
> 'http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.5/PACKAGES'
> trying URL
> 'https://cran.wu.ac.at/bin/windows/contrib/3.5/RColorBrewer_1.1-2.zip'
> Content type 'application/zip' length 55444 bytes (54 KB)
> downloaded 54 KB
>
> trying URL
> 'https://cran.wu.ac.at/bin/windows/contrib/3.5/latticeExtra_0.6-28.zip'
> Content type 'application/zip' length 2191524 bytes (2.1 MB)
> downloaded 2.1 MB
>
> package ‘RColorBrewer’ successfully unpacked and MD5 sums checked
> package ‘latticeExtra’ successfully unpacked and MD5 sums checked
>
> The downloaded binary packages are in
>
> C:\Users\rmh.DESKTOP-60G4CCO\AppData\Local\Temp\RtmpqA7Rqg\downloaded_packages
>> library(latticeExtra)
> Loading required package: lattice
> Loading required package: RColorBrewer
>> a <- xyplot(1 ~ 1)
>> c(a,a)
> Warning message:
> In formals(fun) : argument is not a function
>>
>
> __
> 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] apply with zero-row matrix
On Mon, Jul 30, 2018 at 6:08 PM, Martin Maechler wrote: >> David Hugh-Jones >> on Mon, 30 Jul 2018 10:12:24 +0100 writes: > > > Hi Martin, Fair enough for R functions in general. But the > > behaviour of apply violates the expectation that apply(m, > > 1, fun) calls fun n times when m has n rows. That seems > > pretty basic. > > Well, that expectation is obviously wrong ;-) see below > > > Also, I understand from your argument why it makes sense > > to call apply and return a special result (presumably > > NULL) for an empty argument; but why should apply call fun? > > > Cheers David > > The reason is seen e.g. in > > > apply(matrix(,0,3), 2, quantile) > [,1] [,2] [,3] > 0% NA NA NA > 25%NA NA NA > 50%NA NA NA > 75%NA NA NA > 100% NA NA NA > > I don't think this example is relevant to what David is saying: matrix(,0,3) has three columns, so he would expect quantile() to be called 3 times, as it is. I think his question is why quantile() is called at all when the input has 0 rows, as in apply(matrix(,0,3), 1, quantile) # named numeric(0) > and that is documented (+/-) in the first paragraph of the > 'Value:' section of help(apply) : > > > Value: > > > > If each call to ‘FUN’ returns a vector of length ‘n’, then ‘apply’ > > returns an array of dimension ‘c(n, dim(X)[MARGIN])’ if ‘n > 1’. > > If ‘n’ equals ‘1’, ‘apply’ returns a vector if ‘MARGIN’ has length > > 1 and an array of dimension ‘dim(X)[MARGIN]’ otherwise. If ‘n’ is > > ‘0’, the result has length 0 but not necessarily the ‘correct’ > > dimension. > > > To determine 'n', the function *is* called once even when > length(X) == 0 This part of the docs also doesn't seem applicable, and in fact seems incorrect: here we should have (according to the docs) n = length(quantile(logical(0))) # 5 but the result does not have dim == c(5, 0) as the docs suggest: dim(apply(matrix(,0,3), 1, quantile)) # NULL So the length of the result of calling FUN() seems to be ignored in this case, and as Emil points out, is only used to determine the mode of the result. I can't immediately think of an example where returning NULL instead would make a difference, but there may well be some. -Deepayan > It may indeed be would helpful to add this explicitly to the > help page ( /src/library/base/man/apply.Rd ). > Can you propose a wording (in *.Rd if possible) ? > > With regards, > Martin > > __ > 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] Bug : Autocorrelation in sample drawn from stats::rnorm (hmh)
On Fri, Oct 5, 2018 at 2:07 PM hmh wrote: > > On 05/10/2018 10:28, Annaert Jan wrote: > > you discard any time series structure; > But that is PRECISELY what a call a bug: > There should not be any "time series structure" in the output or rnorm, > runif and so on but there is one. > > rnorm(N,0,1) > should give on average the same output as > sample(rnorm(N,0,1)) Agreed, but that is not what your code is testing. You seem to think that something much more specific should be true; namely, X[1:10] ~ iid normal, then cor(X[1:9], X[2:10]) and cor(sample(X[-1]), sample(X[-10])) should have the same distribution. This is not at all obvious, and in fact not true. Please check the reference you have been pointed to. Here is a related article in the same volume: https://www.jstor.org/stable/2332719 -Deepayan > Which is not the case. rnorm(N,0,1) should draw INDEPENDENT samples i.e. > without time series structure ! > > > -- > - no title specified > > Hugo Mathé-Hubert > > ATER > > Laboratoire Interdisciplinaire des Environnements Continentaux (LIEC) > > UMR 7360 CNRS - Bât IBISE > > Université de Lorraine - UFR SciFA > > 8, Rue du Général Delestraint > > F-57070 METZ > > +33(0)9 77 21 66 66 > - - - - - - - - - - - - - - - - - - > Les réflexions naissent dans les doutes et meurent dans les certitudes. > Les doutes sont donc un signe de force et les certitudes un signe de > faiblesse. La plupart des gens sont pourtant certains du contraire. > - - - - - - - - - - - - - - - - - - > Thoughts appear from doubts and die in convictions. Therefore, doubts > are an indication of strength and convictions an indication of weakness. > Yet, most people believe the opposite. > > > [[alternative HTML version deleted]] > > __ > r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inappropriate warning in latticeExtra
On Fri, Jun 14, 2019 at 6:42 PM Richard M. Heiberger wrote:
>
> This is still not repaired in
> R version 3.6.0 Patched (2019-05-17 r76528)
> > library(latticeExtra)
> > a <- xyplot(1 ~ 1)
> > c(a,a)
> Warning message:
> In formals(fun) : argument is not a function
>
> Can we have it in R-3.6.1 that Peter just announced?
Sorry I have been neglecting this (and some lattice bugs as well). I
should get time to work on this after mid-July.
-Deepayan
>
> Rich
>
> On Mon, Apr 2, 2018 at 4:08 AM Deepayan Sarkar
> wrote:
> >
> > On Fri, Mar 23, 2018 at 7:58 AM, Richard M. Heiberger
> > wrote:
> > > The warning message in the last line of this email is incorrect.
> > > This is behavior which Duncan Murdoch labeled a bug in
> > >https://stat.ethz.ch/pipermail/r-help/2017-December/450494.html
> >
> > Yes, sorry, this has been fixed in the r-forge sources for a while
> > now, but I haven't had the time to finish up some other fixes and push
> > an update to CRAN.
> >
> > Hopefully over the summer break.
> >
> > Regards,
> > -Deepayan
> >
> >
> > > This is a fresh install of R-devel (2018-03-21 r74436)
> > >
> > >
> > >
> > >
> > > R Under development (unstable) (2018-03-21 r74436) -- "Unsuffered
> > > Consequences"
> > > Copyright (C) 2018 The R Foundation for Statistical Computing
> > > Platform: x86_64-w64-mingw32/x64 (64-bit)
> > >
> > > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > > You are welcome to redistribute it under certain conditions.
> > > Type 'license()' or 'licence()' for distribution details.
> > >
> > > Natural language support but running in an English locale
> > >
> > > R is a collaborative project with many contributors.
> > > Type 'contributors()' for more information and
> > > 'citation()' on how to cite R or R packages in publications.
> > >
> > > Type 'demo()' for some demos, 'help()' for on-line help, or
> > > 'help.start()' for an HTML browser interface to help.
> > > Type 'q()' to quit R.
> > >
> > >> library(latticeExtra)
> > > Error in library(latticeExtra) :
> > > there is no package called ‘latticeExtra’
> > >> install.packages("latticeExtra")
> > > Warning in install.packages("latticeExtra") :
> > > 'lib = "C:/Program Files/R/R-devel/library"' is not writable
> > > --- Please select a CRAN mirror for use in this session ---
> > > also installing the dependency ‘RColorBrewer’
> > >
> > > Warning: unable to access index for repository
> > > http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.5:
> > > cannot open URL
> > > 'http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.5/PACKAGES'
> > > trying URL
> > > 'https://cran.wu.ac.at/bin/windows/contrib/3.5/RColorBrewer_1.1-2.zip'
> > > Content type 'application/zip' length 55444 bytes (54 KB)
> > > downloaded 54 KB
> > >
> > > trying URL
> > > 'https://cran.wu.ac.at/bin/windows/contrib/3.5/latticeExtra_0.6-28.zip'
> > > Content type 'application/zip' length 2191524 bytes (2.1 MB)
> > > downloaded 2.1 MB
> > >
> > > package ‘RColorBrewer’ successfully unpacked and MD5 sums checked
> > > package ‘latticeExtra’ successfully unpacked and MD5 sums checked
> > >
> > > The downloaded binary packages are in
> > >
> > > C:\Users\rmh.DESKTOP-60G4CCO\AppData\Local\Temp\RtmpqA7Rqg\downloaded_packages
> > >> library(latticeExtra)
> > > Loading required package: lattice
> > > Loading required package: RColorBrewer
> > >> a <- xyplot(1 ~ 1)
> > >> c(a,a)
> > > Warning message:
> > > In formals(fun) : argument is not a function
> > >>
> > >
> > > __
> > > 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] inappropriate warning in latticeExtra
On Fri 6 Dec, 2019, 6:46 PM Richard M. Heiberger, wrote:
> This problem is still present in
>
Yes, my bad. I'm traveling till Monday, but will get an update out as soon
as possible after I'm back.
-Deepayan
> > version
>_
> platform x86_64-w64-mingw32
> arch x86_64
> os mingw32
> system x86_64, mingw32
> status Under development (unstable)
> major 4
> minor 0.0
> year 2019
> month 12
> day03
> svn rev77513
> language R
> version.string R Under development (unstable) (2019-12-03 r77513)
> nickname Unsuffered Consequences
>
> Rich
>
>
>
> On Sat, Jun 15, 2019 at 3:13 AM Deepayan Sarkar
> wrote:
> >
> > On Fri, Jun 14, 2019 at 6:42 PM Richard M. Heiberger
> wrote:
> > >
> > > This is still not repaired in
> > > R version 3.6.0 Patched (2019-05-17 r76528)
> > > > library(latticeExtra)
> > > > a <- xyplot(1 ~ 1)
> > > > c(a,a)
> > > Warning message:
> > > In formals(fun) : argument is not a function
> > >
> > > Can we have it in R-3.6.1 that Peter just announced?
> >
> > Sorry I have been neglecting this (and some lattice bugs as well). I
> > should get time to work on this after mid-July.
> >
> > -Deepayan
> >
> > >
> > > Rich
> > >
> > > On Mon, Apr 2, 2018 at 4:08 AM Deepayan Sarkar
> > > wrote:
> > > >
> > > > On Fri, Mar 23, 2018 at 7:58 AM, Richard M. Heiberger <
> r...@temple.edu> wrote:
> > > > > The warning message in the last line of this email is incorrect.
> > > > > This is behavior which Duncan Murdoch labeled a bug in
> > > > >https://stat.ethz.ch/pipermail/r-help/2017-December/450494.html
> > > >
> > > > Yes, sorry, this has been fixed in the r-forge sources for a while
> > > > now, but I haven't had the time to finish up some other fixes and
> push
> > > > an update to CRAN.
> > > >
> > > > Hopefully over the summer break.
> > > >
> > > > Regards,
> > > > -Deepayan
> > > >
> > > >
> > > > > This is a fresh install of R-devel (2018-03-21 r74436)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > R Under development (unstable) (2018-03-21 r74436) -- "Unsuffered
> Consequences"
> > > > > Copyright (C) 2018 The R Foundation for Statistical Computing
> > > > > Platform: x86_64-w64-mingw32/x64 (64-bit)
> > > > >
> > > > > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > > > > You are welcome to redistribute it under certain conditions.
> > > > > Type 'license()' or 'licence()' for distribution details.
> > > > >
> > > > > Natural language support but running in an English locale
> > > > >
> > > > > R is a collaborative project with many contributors.
> > > > > Type 'contributors()' for more information and
> > > > > 'citation()' on how to cite R or R packages in publications.
> > > > >
> > > > > Type 'demo()' for some demos, 'help()' for on-line help, or
> > > > > 'help.start()' for an HTML browser interface to help.
> > > > > Type 'q()' to quit R.
> > > > >
> > > > >> library(latticeExtra)
> > > > > Error in library(latticeExtra) :
> > > > > there is no package called ‘latticeExtra’
> > > > >> install.packages("latticeExtra")
> > > > > Warning in install.packages("latticeExtra") :
> > > > > 'lib = "C:/Program Files/R/R-devel/library"' is not writable
> > > > > --- Please select a CRAN mirror for use in this session ---
> > > > > also installing the dependency ‘RColorBrewer’
> > > > >
> > > > > Warning: unable to access index for repository
> > > > > http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.5:
> > > > > cannot open URL
> > > > > '
> http://www.stats.ox.ac.uk/pub/RWin/bin/windows/contrib/3.5/PACKAGES'
> > > > > trying URL '
> https://cran.wu.ac.at/bin/windows/contrib/3.5/RColorBrewer_1.1-2.zip'
> > > > > Content type 'application/zip' length 55444 bytes (54 KB)
> > > > > downloaded 54 KB
> > > > >
> > > > > trying URL '
> https://cran.wu.ac.at/bin/windows/contrib/3.5/latticeExtra_0.6-28.zip'
> > > > > Content type 'application/zip' length 2191524 bytes (2.1 MB)
> > > > > downloaded 2.1 MB
> > > > >
> > > > > package ‘RColorBrewer’ successfully unpacked and MD5 sums checked
> > > > > package ‘latticeExtra’ successfully unpacked and MD5 sums checked
> > > > >
> > > > > The downloaded binary packages are in
> > > > >
>
> C:\Users\rmh.DESKTOP-60G4CCO\AppData\Local\Temp\RtmpqA7Rqg\downloaded_packages
> > > > >> library(latticeExtra)
> > > > > Loading required package: lattice
> > > > > Loading required package: RColorBrewer
> > > > >> a <- xyplot(1 ~ 1)
> > > > >> c(a,a)
> > > > > Warning message:
> > > > > In formals(fun) : argument is not a function
> > > > >>
> > > > >
> > > > > __
> > > > > R-devel@r-project.org mailing list
> > > > > https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible documentation problem/bug?
On Thu, Apr 30, 2020 at 6:04 PM Dominic Littlewood
<11dlittlew...@gmail.com> wrote:
>
> It seems like there is no obvious way in the documentation to convert the
> expressions in the dots argument to a list without evaluating them. Say, if
> you want to have a function that prints all its arguments:
>
> > foo(abc$de, fg[h], i)
> abc$de
> fg[h]
> i
>
> ...then converting them to a list would be helpful.
> Using substitute(...) was the first thing I tried, but that only gives
> the *first* argument
Isn't that what you would expect anyway? substitute() takes two
arguments, the expression and an environment. You are giving it three.
Normally this should be an error:
foo <- function(a, b, c) substitute(a, b, c)
foo(abc$de, fg[h], i)
# Error in substitute(a, b, c) : unused argument (c)
Clearly ... is being handled in some special way so that we don't get
an error, but otherwise works as expected.
foo <- function(...) substitute(...)
foo(abc$de, fg[h], i)
# abc$de
I would consider this a side-effect of the implementation, and not
something you should rely on.
On the other hand, I would have expected the following to give
something sensible, and it does:
foo <- function(...) substitute({...})
foo(abc$de, fg[h], i)
# {
# abc$de
#fg[h]
#i
# }
as.character(foo(abc$de, fg[h], i))
# [1] "{" "abc$de" "fg[h]" "i"
> in dots. It turns out that there is a way to do this, using
> substitute(...()), but this does not appear to be in either the substitute or
> the dots help page.
There is no documented reason for this to work (AFAIK), so again, I
would guess this is a side-effect of the implementation, and not a API
feature you should rely on. This is somewhat borne out by the
following:
> foo <- function(...) substitute({...()})
> foo(abc$de, fg[h], i)
{
pairlist(abc$de, fg[h], i)
}
> foo(abc$de, fg[h], , i) # add a missing argument for extra fun
{
as.pairlist(alist(abc$de, fg[h], , i))
}
which is not something you would expect to see at the user level. So
my recommendation: don't use ...() and pretend that you never
discovered it in the first place. Use match.call() instead, as
suggested by Serguei.
[Disclaimer: I have no idea what is actually going on, so these are
just guesses. There are some hints at
https://cran.r-project.org/doc/manuals/r-devel/R-ints.html#Dot_002ddot_002ddot-arguments
if you want to folllow up.]
-Deepayan
> In fact, there is a clue how to do this in the documentation, if you look
> closely. Let me quote the substitute page:
>
> "Substituting and quoting often cause confusion when the argument is
> expression(...). The result is a call to the expression constructor
> function and needs to be evaluated with eval to give the actual expression
> object."
>
> So this appears to give a way to turn the arguments into a list -
> eval(substitute(expression(...))). But that's quite long, and hard to
> understand if you just come across it in some code - why are we using eval
> here? why are we substituting expression? - and would definitely require an
> explanatory comment. If the user just wants to iterate over the arguments,
> substitute(...()) is better. In fact, you can get exactly the same effect
> as the above code using as.expression(substitute(...())). Should the
> documentation be updated?
>
> [[alternative HTML version deleted]]
>
> __
> 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] Surpising behavior when using an active binding as loop index in R 4.0.0
A shorter reproducible example:
example(makeActiveBinding)
for (fred in 1:3) { 0 }
ls()
Both problems go away if you first do
compiler::enableJIT(2)
So looks like a bug in compiling the for loop.
-Deepayan
On Sat, May 23, 2020 at 5:45 PM Thomas Friedrichsmeier via R-devel
wrote:
>
> Possibly just a symptom of the earlier behavior, but I'll amend my
> example, below, with an even more disturbing observation:
>
> Am Sat, 23 May 2020 13:19:24 +0200
> schrieb Thomas Friedrichsmeier via R-devel :
> [...]
> > Consider the code below:
> >
> > makeActiveBinding("i",
> > function(value) {
> > if (missing(value)) {
> > x
> > } else {
> > print("set")
> > x <<- value
> > }
> > }, globalenv())
> >
> > i <- 1 # output "set"
> > print(i) # output [1] 1
> >
> > # Surprising behavior starts here:
> > for(i in 2:3) print(i) # output [1] "set"
> >#NULL
> >#NULL
> >
> > print(i) # output NULL
> > print(x) # output NULL
> >
> > i <- 4 # output "set"
> > print(i) # ouput [1] 4
> > print(x) # ouput [1] 4
>
> ls()
> # Error in ls() :
> # Value of SET_STRING_ELT() must be a 'CHARSXP' not a 'NULL'
>
> Regards
> Thomas
> __
> 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] Tips for debugging: R CMD check examples
On Wed, Jun 30, 2010 at 3:26 AM, Hadley Wickham wrote: > Hi all, > > Does anyone have any suggestions for debugging the execution of > examples by R CMD check? The examples work fine when I run them from > a live R prompt, but I get errors when they are run by R CMD check. 'R CMD check pkg' will produce a pkg.Rcheck/pkg-Ex.R file that collects the examples into a single file (and also does other things). You could try running that file interactively to see if the error is reproduced. -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange R object
On Fri, Jul 9, 2010 at 5:25 AM, Peter Dalgaard wrote:
> Gabor Grothendieck wrote:
>> On Fri, Jul 9, 2010 at 5:09 AM, Peter Dalgaard wrote:
>>> Gabor Grothendieck wrote:
I have *** attached *** an RData file containing an R object that
is acting strangely.
Try this in a fresh workspace. Do not load zoo or any other package.
We load the object, zz2, from the attached RData file. It is just
the number 1 with the class c("zooreg", "zoo").
Now create an S3 print routine that simply prints an X when given
an object of class "zoo".
If we use print on the object it produces an X but not if we just
enter it at the console. Also the object is not identical to its
dput output.
How can such an object exist? What is it about the object that is
different from structure(1, class = c("zoo", "zooreg")) ?
>>> There's a bit in the SEXP structure that is supposed to be turned on
>>> when an object has an S3 class. This is where implicit print looks,
>>> whereas explicit print looks, er, elsewhere. Notice that
>>>
is.object(zz2)
>>> [1] FALSE
class(zz2) <- class(zz2)
zz2
>>> X
is.object(zz2)
>>> [1] TRUE
>>>
>>> Whenever the same information is stored in two ways, there is a risk of
>>> inconsistency, so it is not too strange that you can have an ill-formed
>>> .Rdata file (if you save zz2 back out, after the above fixup, line 11
>>> changes from 526 to 782, corresponding to the bit being turned on).
>>>
>>> I don't think it is the job of load() to verify object structures, since
>>> there is no end to that task. Rather, we shouldn't create them in the
>>> first place, but you give us no clues as to how that object got made.
>>>
>>
>> This was originally a large object in a program that uses a variety of
>> packages and it took quite a long time just to narrow it down to the
>> point where I had an object sufficiently small to post. Its not even
>> clear at what point the object goes bad but your class(x) <- class(x)
>> trick helped a lot and I have now been able to recreate it in a simple
>> manner.
>>
>> Below we create a new S3 class "X" with an Ops.X and print.X method.
>> We then create an object x of that class which is just 1 with a class
>> of "X". When we multiply 1*x we get the bad object. 1*x and x have
>> the same dput output but compare as FALSE. 1*x is not printed by
>> print.X even though it is of class "X" while x is printed by print.X .
>> If we assign 1*x to xx and use your class assignment trick (class(xx)
>> <- class(xx)) then xx prints as expected even though it did not prior
>> to the class assignment.
>>
>>> Ops.X <- function(e1, e2) { print("Ops.X"); NextMethod(.Generic) }
>>> print.X <- function(x, ...) print("print.X")
>>> x <- structure(1, class = "X")
>>> dput(x)
>> structure(1, class = "X")
>>> dput(1*x)
>> [1] "Ops.X"
>> structure(1, class = "X")
>>> identical(x, 1*x)
>> [1] "Ops.X"
>> [1] FALSE
>>> 1*x
>> [1] "Ops.X"
>> [1] 1
>> attr(,"class")
>> [1] "X"
>>> x
>> [1] "print.X"
>>> xx <- 1*x
>> [1] "Ops.X"
>>> class(xx) <- class(xx)
>>> xx
>> [1] "print.X"
>
> Or, to minimize it further:
>
>> x <- structure(1, class="y")
>> is.object(x)
> [1] TRUE
>> is.object(x*1)
> [1] TRUE
>> is.object(1*x)
> [1] FALSE
>> class(x*1)
> [1] "y"
>> class(1*x)
> [1] "y"
>
> Yup, that looks like a bug.
I recently came across the following surprising behaviour which turns
out to be the same issue. I had been meaning to ask for an
explanation.
> x <- 1:20
> class(x)
[1] "integer"
> is.object(x)
[1] FALSE
> print.integer <- function(x) print(x %% 5)
> print(x)
[1] 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0
> x
[1] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange interaction between rasterImage and Grid graphics
On Fri, Oct 1, 2010 at 12:17 AM, baptiste auguie wrote: > Dear all, > > This may be specific to Mac, I haven't had a chance to test another > platform. Consider this, > > plot(1,1,t="n") > rasterImage(matrix(1),1,1,1,1) > library(grid) > grid.rect(gp=gpar(fill="grey")) > > The grid.rect covers the full device window as expected. However, when > I resize the window ever so slightly (interactive device) the rectGrob > is suddenly clipped to the previous plot window. I cannot understand > this behavior, and it doesn't happen if one removes the rasterImage() > call, so I suspect something iffy is going on with the display list or > something. I can reproduce the behaviour on GNU/Linux x11(type="cairo"), but this is inappropriate mixing of base and grid graphics, so officially I don't think you are allowed to expect anything at all. -Deepayan > > The only device I've tried is quartz(), x11() crashed with rasterImage, > > *** caught segfault *** > address 0x28, cause 'memory not mapped' > > Traceback: > 1: rasterImage(matrix(1), 1, 1, 1, 1) > > sessionInfo() > R version 2.11.1 (2010-05-31) > x86_64-apple-darwin9.8.0 > > locale: > [1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8 > > attached base packages: > [1] grid stats graphics grDevices utils datasets methods base > > __ > 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] strange interaction between rasterImage and Grid graphics
On Sat, Oct 2, 2010 at 4:35 PM, Paul Murrell wrote: > Hi > > baptiste auguie wrote: >> >> Dear all, >> >> This may be specific to Mac, I haven't had a chance to test another >> platform. Consider this, >> >> plot(1,1,t="n") >> rasterImage(matrix(1),1,1,1,1) >> library(grid) >> grid.rect(gp=gpar(fill="grey")) > >> >> >> The grid.rect covers the full device window as expected. However, when >> I resize the window ever so slightly (interactive device) the rectGrob >> is suddenly clipped to the previous plot window. I cannot understand >> this behavior, and it doesn't happen if one removes the rasterImage() >> call, so I suspect something iffy is going on with the display list or >> something. > > It happens like this: > > # 1. Clip to the device and draw axes and labels > plot(1,1,t="n") > # 2. Clip to the plot region and draw raster > rasterImage(matrix(1),1,1,1,1) > library(grid) > # Oooh! This is the first time any grid drawing > # has occurred on the device, so initialize grid > # stuff, including the top-level viewport, > # *which clips to the device* > # 3. Draw a rectangle > grid.rect(gp=gpar(fill="grey")) > > # Resize the window ... > # which triggers a redraw ... > # Oooh! There is grid output on this device so > # initialize grid stuff, including the top-level > # viewport *which clips to the device* ... > # 1. Clip to the device and draw axes and labels > # 2. Clip to the plot region and draw raster > # 3. Draw a rectangle > > A workaround is to explicitly do a clip before the grid.rect(), i.e., ... > > plot(1,1,t="n") > rasterImage(matrix(1),1,1,1,1) > library(grid) > grid.clip() > grid.rect(gp=gpar(fill="grey")) > > ... and I will add this example to the things I will look at when I am > trying to clean up the grid code a bit. > >> The only device I've tried is quartz(), x11() crashed with rasterImage, > > That is more serious. I have heard of a couple of others like this and I > think the common thread may be 64-bit MacOS X. I need to get access to such > a beast to take a look. Or maybe just 64 bit. I have (running Debian unstable) > sessionInfo() R version 2.12.0 Under development (unstable) (2010-09-02 r52864) Platform: x86_64-unknown-linux-gnu (64-bit) and I get reproducible crashes (same 'memory not mapped' segfault) with x11(type="Xlib") example(rasterImage) #or library(lattice) example(panel.levelplot.raster) [I noticed this a while back, but neglected to report.] -Deepayan > > Paul > >> *** caught segfault *** >> address 0x28, cause 'memory not mapped' >> >> Traceback: >> 1: rasterImage(matrix(1), 1, 1, 1, 1) >> >> sessionInfo() >> R version 2.11.1 (2010-05-31) >> x86_64-apple-darwin9.8.0 >> >> locale: >> [1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8 >> >> attached base packages: >> [1] grid stats graphics grDevices utils datasets methods >> base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Source for bash_completion.d/R?
On Tue, May 3, 2011 at 4:40 AM, Dirk Eddelbuettel wrote: > > On 2 May 2011 at 11:32, Sharpie wrote: > | Hello, I was just tweaking the R build for the Homebrew package manager and > I > | thought it would be nice to enable bash completion. I noticed that > | Debian-based systems install `/etc/bash_completion.d/R` but could not find a > | source for this file in the `etc` folder of the R source. > > Right. This started off via a suggestion by Deepayan and a quick install via > a local-to-Debian-package-sources file, and has never moved away from that. > > I am CCing Deepayan now; it may indeed be useful to commit this in the R svn > and to add it to the tarball as the feature is very, very useful if you > deplay bash completion. I vaguely remember a discussion on r-core where the consensus was that this was too shell-specific to belong in the R sources. It has been publicly available (for a long time) at http://code.google.com/p/rcompletion/source/browse/trunk/bash_completion/R (could use a little work now). -Deepayan > > Dirk > > -- > Gauss once played himself in a zero-sum game and won $50. > -- #11 at http://www.gaussfacts.com > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Cases of TAB-completion that hang Rterm
On Tue, Jun 7, 2011 at 1:49 PM, Henrik Bengtsson wrote:
> FYI,
>
> via a bug report of one of my packages, I discovered that the
> following cases will hang Rterm when using TAB completion:
>
> CASE #1:
> Adding an empty default function for tail() causes Rterm on Windows to
> hang if one press TAB at the prompt:
>
> % Rterm -vanilla
>> tail.default <- function(...) {}
>> [PRESS TAB]
> Error in specialOpLocs(text) :
> (list) object cannot be coerced to type 'double'
>
> After this Rterm becomes completely unresponsive. The same error
> message will show up with Rgui, but R remains responsive.
>
>
> CASE #2:
> While troubleshooting the above, I discovered that if one does:
>
>> debug(utils:::.guessTokenFromLine)
>> [PRESS TAB]
>
> or
>
>> debug(utils:::.win32consoleCompletion)
>> [PRESS TAB]
>
> then Rterm hangs too (not Rgui).
>
> This happens with R v2.13.0 patched (2011-05-30 r56020) and R v2.14.0
> devel (2011-05-30 r56020) on Windows.
This should now be fixed in both r-devel (for a few days now) and r-patched.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD BATCH vs R CMD batch
On Thu, Oct 29, 2015 at 2:09 PM, Rainer M Krug wrote: > Dirk Eddelbuettel writes: > >> On 28 October 2015 at 21:39, Marius Hofert wrote: >> | Out of laziness I just used "R CMD batch" instead of "R CMD BATCH". I >> | didn't get an error so didn't think about the consequences... One >> | consequence is (at least on Mac OS X 10.11 but probably in more >> | generality) that R_BATCH_OPTIONS are ignored, which was kind of fatal >> | in my case... I am thus wondering whether it makes sense to either a) >> | have R_BATCH_OPTIONS also be respected for "R CMD batch" or b) simply >> | not allow "R CMD batch" as a valid command (so requiring to use "R CMD >> | BATCH"). Both approaches might be delicate... just wanted to point >> | this issue out... >> >> Same reason we have 'R CMD INSTALL' as there often is /usr/bin/install with >> different options ... >> >> In general 'R CMD foo' will run for any 'foo' in the path: >> >>edd@max:~$ R CMD date >>Wed Oct 28 21:05:01 CDT 2015 >>edd@max:~$ > > So what is R CMD exactly doing in this example? The output is the same if > I say only the command (using pwd as otherwise the time has changed...): > > , > | 09:35:03 ~$ R CMD pwd > | /Users/rainerkrug > | 09:35:37 ~$ R CMD pwd > | /Users/rainerkrug > | 09:37:44 ~$ pwd > | /Users/rainerkrug > | 09:37:49 ~$ > ` > > And this happens, except in cases where the foo is defined as a CMD in R > (build, ...): > > , > | Commands: > | BATCH Run R in batch mode > | COMPILE Compile files for use with R > | SHLIB Build shared library for dynamic loading > | INSTALL Install add-on packages > | REMOVE Remove add-on packages > | build Build add-on packages > | check Check add-on packages > | LINKFront-end for creating executable programs > | Rprof Post-process R profiling files > | Rdconv Convert Rd format to various other formats > | Rd2pdf Convert Rd format to PDF > | Rd2txt Convert Rd format to pretty text > | Stangle Extract S/R code from Sweave documentation > | Sweave Process Sweave documentation > | Rdiff Diff R output ignoring headers etc > | config Obtain configuration information about R > | javareconf Update the Java configuration variables > | rtags Create Emacs-style tag files from C, R, and Rd files > ` > > Unless I miss something, is this is an inconsistency in R? One important difference (not sure if the only one) is that R CMD defines more environment variables. Compare env | grep -i tex R CMD env | grep -i tex So for example R CMD pdflatex will behave differently from plain pdflatex. -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unlicense
On Sat, Jan 14, 2017 at 5:49 AM, Duncan Murdoch wrote: > On 13/01/2017 3:21 PM, Charles Geyer wrote: >> >> I would like the unlicense (http://unlicense.org/) added to R >> licenses. Does anyone else think that worthwhile? >> > > That's a question for you to answer, not to ask. Who besides you thinks > that it's a good license for open source software? > > If it is recognized by the OSF or FSF or some other authority as a FOSS > license, then CRAN would probably also recognize it. If not, then CRAN > doesn't have the resources to evaluate it and so is unlikely to recognize > it. Unlicense is listed in https://spdx.org/licenses/ Debian does include software "licensed" like this, and seems to think this is one way (not the only one) of declaring something to be "public domain". The first two examples I found: https://tracker.debian.org/media/packages/r/rasqal/copyright-0.9.29-1 https://tracker.debian.org/media/packages/w/wiredtiger/copyright-2.6.1%2Bds-1 This follows the format explained in https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-specification, which does not explicitly include Unlicense, but does include CC0, which AFAICT is meant to formally license something so that it is equivalent to being in the public domain. R does include CC0 as a shorthand (e.g., geoknife). https://www.debian.org/legal/licenses/ says that Licenses currently found in Debian main include: - ... - ... - public domain (not a license, strictly speaking) The equivalent for CRAN would probably be something like "License: public-domain + file LICENSE". -Deepayan > Duncan Murdoch > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-3.3.3/R-3.4.0 change in sys.call(sys.parent())
On Wed, May 10, 2017 at 2:36 AM, William Dunlap via R-devel
wrote:
> Some formula methods for S3 generic functions use the idiom
> returnValue$call <- sys.call(sys.parent())
> to show how to recreate the returned object or to use as a label on a
> plot. It is often followed by
> returnValue$call[[1]] <- quote(myName)
> E.g., I see it in packages "latticeExtra" and "leaps", and I suspect it
> used in "lattice" as well.
>
> This idiom has not done good things for quite a while (ever?) but I noticed
> while running tests that it acts differently in R-3.4.0 than in R-3.3.3.
> Neither the old or new behavior is nice. E.g., in R-3.3.3 we get
>
>> parseEval <- function(text, envir) eval(parse(text=text), envir=envir)
>> parseEval('lattice::xyplot(mpg~hp, data=datasets::mtcars)$call',
> envir=new.env())
> xyplot(expr, envir, enclos)
>
> and
>
>> evalInEnvir <- function(call, envir) eval(call, envir=envir)
>> evalInEnvir(quote(lattice::xyplot(mpg~hp, data=datasets::mtcars)$call),
> envir=new.env())
> xyplot(expr, envir, enclos)
>
> while in R-3.4.0 we get
>> parseEval <- function(text, envir) eval(parse(text=text), envir=envir)
>> parseEval('lattice::xyplot(mpg~hp, data=datasets::mtcars)$call',
> envir=new.env())
> xyplot(parse(text = text), envir = envir)
>
> and
>
>> evalInEnvir <- function(call, envir) eval(call, envir=envir)
>> evalInEnvir(quote(lattice::xyplot(mpg~hp, data=datasets::mtcars)$call),
> envir=new.env())
> xyplot(call, envir = envir)
>
> Should these packages be be fixed up to use just sys.call()?
I admit to not understanding these things very well, but I'll try to
explain why I ended up with the usage I have. The main use of the
$call component within lattice is to use it in the summary method, as
in:
> summary(xyplot(mpg~hp, data=mtcars))
Call:
xyplot(mpg ~ hp, data = mtcars)
Number of observations:
[1] 32
Here is a minimal approximation to what I need: Here foo() and bar()
are generics producing objects of class "foobar", bar() calls foo()
with one argument changed, and the print() method for "foobar" is just
supposed to print the call that produced it:
foo <- function(x, ...) UseMethod("foo")
bar <- function(x, ...) UseMethod("bar")
print.foobar <- function(x, ...) print(x$call)
## Using plain sys.call():
foo.formula <- function(x, ...)
{
ans <- structure(list(), class = "foobar")
ans$call <- sys.call()
ans
}
bar.formula <- function(x, ..., panel)
{
foo.formula(x, ..., panel = panel.bar)
}
foo.table <- function(x, ...)
{
ans <- foo.formula(Freq ~ Var1,
as.data.frame.table(x), ...)
ans
}
## I would get
foo(y ~ x)
# foo.formula(y ~ x)
bar(y ~ x)
# foo.formula(x, ..., panel = panel.bar)
foo(as.table(1:10))
# foo.formula(Freq ~ Var1, as.data.frame.table(x), ...)
## The last two are improved by
foo.formula <- function(x, ...)
{
ans <- structure(list(), class = "foobar")
ans$call <- sys.call(sys.parent())
ans
}
bar(y ~ x)
## bar.formula(y ~ x)
foo(as.table(1:10))
## foo.table(as.table(1:10))
Adding
ans$call[[1]] <- quote(foo)
(or quote(bar) in bar.formula) is needed to replace the unexported
method name (foo.formula) with the generic name (foo), but that's
probably not the problem.
With this approach in lattice,
p <- some.function(...)
eval(p$call)
usually works, but not always, if I remember correctly.
I'm happy to consider more robust solutions. Maybe I just need to have a
...$call <- sys.call()
statement in every method?
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-3.3.3/R-3.4.0 change in sys.call(sys.parent())
On Thu, May 11, 2017 at 8:03 PM, William Dunlap wrote:
> Here is a case where the current scheme fails:
>
> > with(datasets::mtcars, xyplot(mpg~wt|gear)$call)
> xyplot(substitute(expr), data, enclos = parent.frame())
Right, thanks. So I guess I can't avoid setting $call inside every method.
-Deepayan
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
> On Thu, May 11, 2017 at 1:09 AM, Deepayan Sarkar
> wrote:
>>
>> On Wed, May 10, 2017 at 2:36 AM, William Dunlap via R-devel
>> wrote:
>> > Some formula methods for S3 generic functions use the idiom
>> > returnValue$call <- sys.call(sys.parent())
>> > to show how to recreate the returned object or to use as a label on a
>> > plot. It is often followed by
>> > returnValue$call[[1]] <- quote(myName)
>> > E.g., I see it in packages "latticeExtra" and "leaps", and I suspect it
>> > used in "lattice" as well.
>> >
>> > This idiom has not done good things for quite a while (ever?) but I
>> > noticed
>> > while running tests that it acts differently in R-3.4.0 than in R-3.3.3.
>> > Neither the old or new behavior is nice. E.g., in R-3.3.3 we get
>> >
>> >> parseEval <- function(text, envir) eval(parse(text=text), envir=envir)
>> >> parseEval('lattice::xyplot(mpg~hp, data=datasets::mtcars)$call',
>> > envir=new.env())
>> > xyplot(expr, envir, enclos)
>> >
>> > and
>> >
>> >> evalInEnvir <- function(call, envir) eval(call, envir=envir)
>> >> evalInEnvir(quote(lattice::xyplot(mpg~hp, data=datasets::mtcars)$call),
>> > envir=new.env())
>> > xyplot(expr, envir, enclos)
>> >
>> > while in R-3.4.0 we get
>> >> parseEval <- function(text, envir) eval(parse(text=text), envir=envir)
>> >> parseEval('lattice::xyplot(mpg~hp, data=datasets::mtcars)$call',
>> > envir=new.env())
>> > xyplot(parse(text = text), envir = envir)
>> >
>> > and
>> >
>> >> evalInEnvir <- function(call, envir) eval(call, envir=envir)
>> >> evalInEnvir(quote(lattice::xyplot(mpg~hp, data=datasets::mtcars)$call),
>> > envir=new.env())
>> > xyplot(call, envir = envir)
>> >
>> > Should these packages be be fixed up to use just sys.call()?
>>
>> I admit to not understanding these things very well, but I'll try to
>> explain why I ended up with the usage I have. The main use of the
>> $call component within lattice is to use it in the summary method, as
>> in:
>>
>> > summary(xyplot(mpg~hp, data=mtcars))
>>
>> Call:
>> xyplot(mpg ~ hp, data = mtcars)
>>
>> Number of observations:
>> [1] 32
>>
>> Here is a minimal approximation to what I need: Here foo() and bar()
>> are generics producing objects of class "foobar", bar() calls foo()
>> with one argument changed, and the print() method for "foobar" is just
>> supposed to print the call that produced it:
>>
>>
>>
>> foo <- function(x, ...) UseMethod("foo")
>> bar <- function(x, ...) UseMethod("bar")
>> print.foobar <- function(x, ...) print(x$call)
>>
>> ## Using plain sys.call():
>>
>> foo.formula <- function(x, ...)
>> {
>> ans <- structure(list(), class = "foobar")
>> ans$call <- sys.call()
>> ans
>> }
>>
>> bar.formula <- function(x, ..., panel)
>> {
>> foo.formula(x, ..., panel = panel.bar)
>> }
>>
>> foo.table <- function(x, ...)
>> {
>> ans <- foo.formula(Freq ~ Var1,
>>as.data.frame.table(x), ...)
>> ans
>> }
>>
>> ## I would get
>>
>> foo(y ~ x)
>> # foo.formula(y ~ x)
>>
>> bar(y ~ x)
>> # foo.formula(x, ..., panel = panel.bar)
>>
>> foo(as.table(1:10))
>> # foo.formula(Freq ~ Var1, as.data.frame.table(x), ...)
>>
>> ## The last two are improved by
>>
>> foo.formula <- function(x, ...)
>> {
>> ans <- structure(list(), class = "foobar")
>> ans$call <- sys.call(sys.parent())
>> ans
>> }
>>
>> bar(y ~ x)
>> ## bar.formula(y ~ x)
>>
>> foo(as.table(1:10))
>> ## foo.table(as.table(1:10))
>>
>>
>>
>> Adding
>>
>> ans$call[[1]] <- quote(foo)
>>
>> (or quote(bar) in bar.formula) is needed to replace the unexported
>> method name (foo.formula) with the generic name (foo), but that's
>> probably not the problem.
>>
>> With this approach in lattice,
>>
>> p <- some.function(...)
>> eval(p$call)
>>
>> usually works, but not always, if I remember correctly.
>>
>> I'm happy to consider more robust solutions. Maybe I just need to have a
>>
>> ...$call <- sys.call()
>>
>> statement in every method?
>>
>> -Deepayan
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel internal errors during check produce?
On Tue, Jun 30, 2020 at 1:32 PM Martin Maechler
wrote:
>
> > Kurt Hornik
> > on Tue, 30 Jun 2020 06:20:57 +0200 writes:
>
> > Jan Gorecki writes:
> >> Thank you both, You are absolutely correct that example
> >> should be minimal, so here it is.
>
> >> l = list(a=new.env(), b=new.env()) unique(l)
>
> >> Just for completeness, env_list during check that raises
> >> error
>
> >> env_list <- list(baseenv(),
> >> as.environment("package:graphics"),
> >> as.environment("package:stats"),
> >> as.environment("package:utils"),
> >> as.environment("package:methods") )
>
> >> unique(env_list)
>
> > Thanks ... but the above work fine for me. E.g.,
>
> R> l = list(a=new.env(), b=new.env())
> R> unique(l)
> > [[1]]
>
> > [[2]]
>
> > Best -k
>
> Ditto here; also your (Jan) 2nd example works fine.
>
> So, you must have loaded some (untidy) packages / code which redefine
> standard base R behavior ?
Looking inside Jan's Dockerfile, it turns out that he is configuring R with
./configure --with-recommended-packages --enable-strict-barrier
--disable-long-double
and with that I can reproduce:
> unique(list(new.env()))
Error in unique.default(list(new.env())) :
LENGTH or similar applied to environment object
--enable-strict-barrier is enough to reproduce the error.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New pipe operator
On Fri, Dec 4, 2020 at 7:35 PM Duncan Murdoch wrote: > > On 04/12/2020 8:13 a.m., Hiroaki Yutani wrote: > >> Error: function '::' not supported in RHS call of a pipe > > > > To me, this error looks much more friendly than magrittr's error. > > Some of them got too used to specify functions without (). This > > is OK until they use `::`, but when they need to use it, it takes > > hours to figure out why > > > > mtcars %>% base::head > > #> Error in .::base : unused argument (head) > > > > won't work but > > > > mtcars %>% head > > > > works. I think this is a too harsh lesson for ordinary R users to > > learn `::` is a function. I've been wanting for magrittr to drop the > > support for a function name without () to avoid this confusion, > > so I would very much welcome the new pipe operator's behavior. > > Thank you all the developers who implemented this! > > I agree, it's an improvement on the corresponding magrittr error. > > I think the semantics of not evaluating the RHS, but treating the pipe > as purely syntactical is a good decision. > > I'm not sure I like the recommended way to pipe into a particular argument: > >mtcars |> subset(cyl == 4) |> \(d) lm(mpg ~ disp, data = d) > > or > >mtcars |> subset(cyl == 4) |> function(d) lm(mpg ~ disp, data = d) > > both of which are equivalent to > >mtcars |> subset(cyl == 4) |> (function(d) lm(mpg ~ disp, data = d))() > > It's tempting to suggest it should allow something like > >mtcars |> subset(cyl == 4) |> lm(mpg ~ disp, data = .) Which is really not that far off from mtcars |> subset(cyl == 4) |> \(.) lm(mpg ~ disp, data = .) once you get used to it. One consequence of the implementation is that it's not clear how multiple occurrences of the placeholder would be interpreted. With magrittr, sort(runif(10)) %>% ecdf(.)(.) ## [1] 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 This is probably what you would expect, if you expect it to work at all, and not ecdf(sort(runif(10)))(sort(runif(10))) There would be no such ambiguity with anonymous functions sort(runif(10)) |> \(.) ecdf(.)(.) -Deepayan > which would be expanded to something equivalent to the other versions: > but that makes it quite a bit more complicated. (Maybe _ or \. should > be used instead of ., since those are not legal variable names.) > > I don't think there should be an attempt to copy magrittr's special > casing of how . is used in determining whether to also include the > previous value as first argument. > > Duncan Murdoch > > > > > > Best, > > Hiroaki Yutani > > > > 2020年12月4日(金) 20:51 Duncan Murdoch : > >> > >> Just saw this on the R-devel news: > >> > >> > >> R now provides a simple native pipe syntax ‘|>’ as well as a shorthand > >> notation for creating functions, e.g. ‘\(x) x + 1’ is parsed as > >> ‘function(x) x + 1’. The pipe implementation as a syntax transformation > >> was motivated by suggestions from Jim Hester and Lionel Henry. These > >> features are experimental and may change prior to release. > >> > >> > >> This is a good addition; by using "|>" instead of "%>%" there should be > >> a chance to get operator precedence right. That said, the ?Syntax help > >> topic hasn't been updated, so I'm not sure where it fits in. > >> > >> There are some choices that take a little getting used to: > >> > >> > mtcars |> head > >> Error: The pipe operator requires a function call or an anonymous > >> function expression as RHS > >> > >> (I need to say mtcars |> head() instead.) This sometimes leads to error > >> messages that are somewhat confusing: > >> > >> > mtcars |> magrittr::debug_pipe |> head > >> Error: function '::' not supported in RHS call of a pipe > >> > >> but > >> > >> mtcars |> magrittr::debug_pipe() |> head() > >> > >> works. > >> > >> Overall, I think this is a great addition, though it's going to be > >> disruptive for a while. > >> > >> Duncan Murdoch > >> > >> __ > >> 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New pipe operator
On Mon, Dec 7, 2020 at 6:53 PM Gabor Grothendieck wrote: > > On Mon, Dec 7, 2020 at 5:41 AM Duncan Murdoch > wrote: > > I agree it's all about call expressions, but they aren't all being > > treated equally: > > > > x |> f(...) > > > > expands to f(x, ...), while > > > > x |> `function`(...) > > > > expands to `function`(...)(x). This is an exception to the rule for > > other calls, but I think it's a justified one. > > This admitted inconsistency is justified by what? No argument has been > presented. The justification seems to be implicitly driven by implementation > concerns at the expense of usability and language consistency. Sorry if I have missed something, but is your consistency argument basically that if foo <- function(x) x + 1 then x |> foo x |> function(x) x + 1 should both work the same? Suppose it did. Would you then be OK if x |> foo() no longer worked as it does now, and produced foo()(x) instead of foo(x)? If you are not OK with that and want to retain the current behaviour, what would you want to happen with the following? bar <- function(x) function(n) rnorm(n, mean = x) 10 |> bar(runif(1))() # works 'as expected' ~ bar(runif(1))(10) 10 |> bar(runif(1)) # currently bar(10, runif(1)) both of which you probably want. But then baz <- bar(runif(1)) 10 |> baz (not currently allowed) will not be the same as what you would want from 10 |> bar(runif(1)) which leads to a different kind of inconsistency, doesn't it? -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New pipe operator
On Mon, Dec 7, 2020 at 9:23 PM Gabor Grothendieck wrote: > > One could examine how magrittr works as a reference implementation if > there is a question on how something should function. It's in > widespread use and seems to work well. Yes, but it has many inconsistencies (including for the example I gave). Do you want a magrittr clone, or do you want consistency? It's OK to want either, but I don't think you can get both. What we actually end up with is another matter, depending on many other factors. I was just trying to understand your consistency argument. -Deepayan > On Mon, Dec 7, 2020 at 10:20 AM Deepayan Sarkar > wrote: > > > > On Mon, Dec 7, 2020 at 6:53 PM Gabor Grothendieck > > wrote: > > > > > > On Mon, Dec 7, 2020 at 5:41 AM Duncan Murdoch > > > wrote: > > > > I agree it's all about call expressions, but they aren't all being > > > > treated equally: > > > > > > > > x |> f(...) > > > > > > > > expands to f(x, ...), while > > > > > > > > x |> `function`(...) > > > > > > > > expands to `function`(...)(x). This is an exception to the rule for > > > > other calls, but I think it's a justified one. > > > > > > This admitted inconsistency is justified by what? No argument has been > > > presented. The justification seems to be implicitly driven by > > > implementation > > > concerns at the expense of usability and language consistency. > > > > Sorry if I have missed something, but is your consistency argument > > basically that if > > > > foo <- function(x) x + 1 > > > > then > > > > x |> foo > > x |> function(x) x + 1 > > > > should both work the same? Suppose it did. Would you then be OK if > > > > x |> foo() > > > > no longer worked as it does now, and produced foo()(x) instead of foo(x)? > > > > If you are not OK with that and want to retain the current behaviour, > > what would you want to happen with the following? > > > > bar <- function(x) function(n) rnorm(n, mean = x) > > > > 10 |> bar(runif(1))() # works 'as expected' ~ bar(runif(1))(10) > > 10 |> bar(runif(1)) # currently bar(10, runif(1)) > > > > both of which you probably want. But then > > > > baz <- bar(runif(1)) > > 10 |> baz > > > > (not currently allowed) will not be the same as what you would want from > > > > 10 |> bar(runif(1)) > > > > which leads to a different kind of inconsistency, doesn't it? > > > > -Deepayan > > > > -- > Statistics & Software Consulting > GKX Group, GKX Associates Inc. > tel: 1-877-GKX-GROUP > email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] reshape documentation
On Wed, Mar 17, 2021 at 7:55 PM Michael Dewey wrote:
>
> Comments in line
>
> On 13/03/2021 09:50, SOEIRO Thomas wrote:
> > Dear list,
> >
> > I have some questions/suggestions about reshape.
> >
> > 1) I think a good amount of the popularity of base::reshape alternative is
> > due to the complexity of reshape documentation. It is quite hard (at least
> > it is for me) to figure out what argument is needed for respectively "long
> > to wide" and "wide to long", because reshapeWide and reshapeLong are
> > documented together.
> > - Do you agree with this?
> > - Would you consider a proposal to modify the documentation?
> > - If yes, what approach do you suggest? e.g. split in two pages?
>
> The current documentation is much clearer than it was when I first
> started using R but we should always strive for more.
>
> I would suggest leaving the documentation in one place but it might be
> helpful to add which direction is relevant for each parameter by placing
> (to wide) or (to long) as appropriate. I think having completely
> separate lists is not needed
I have just checked in some updates to the documentation (in R-devel)
which hopefully makes usage clearer. Any further suggestions are
welcome. We are planning to add a short vignette as well, hopefully in
time for R 4.1.0.
> > 2) I do not think the documentation indicates that we can use varying
> > argument to rename variables in reshapeWide.
> > - Is this worth documenting?
> > - Is the construct list(c()) really needed?
>
> Yes, because you may have more than one set of variables which need to
> correspond to a single variable in long format. So in your example if
> you also had 11 variables for the temperature as well as the
> concentration each would need specifying as a separate vector in the list.
That's a valid point, but on the other hand, direction="long" already
supports specifying 'varying' as a vector, and it does simplify the
single variable case. So we decided to be consistent and allow it for
direction="wide" too, hopefully with loud enough warnings in the
documentation about using the feature carelessly.
Best,
-Deepayan
> Michael
>
> >
> > reshape(Indometh,
> > v.names = "conc",
> > idvar = "Subject",
> > timevar = "time",
> > direction = "wide",
> > varying = list(c("conc_0.25hr",
> > "conc_0.5hr",
> > "conc.0.75hr",
> > "conc_1hr",
> > "conc_1.25hr",
> > "conc_2hr",
> > "conc_3hr",
> > "conc_4hr",
> > "conc_5hr",
> > "conc_6hr",
> > "conc_8hr")))
> >
> > Thanks,
> >
> > Thomas
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
> Michael
> http://www.dewey.myzen.co.uk/home.html
>
> __
> 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] reshape documentation
On Sat, Apr 17, 2021 at 7:07 PM SOEIRO Thomas wrote:
>
> Dear Deepayan,
>
> I do not have further suggestions, but I just wanted to thank you for taking
> the time to
> improve the documentation so much! (and for adding support for specifying
> "varying" as
> a vector)
>
> Both "Typical usage" and the details are useful additions. Adding a vignette
> also seems
> an excellent idea.
Thanks for checking. I have also finally added a vignette, do let me
know if you see anything that can be improved.
Best,
-Deepayan
>
> These changes will probably helps numerous users.
>
> Best,
>
> Thomas
>
>
>
>
> On Wed, Mar 17, 2021 at 7:55 PM Michael Dewey
> wrote:
> >
> > Comments in line
> >
> > On 13/03/2021 09:50, SOEIRO Thomas wrote:
> > > Dear list,
> > >
> > > I have some questions/suggestions about reshape.
> > >
> > > 1) I think a good amount of the popularity of base::reshape alternative
> > > is due to the complexity of reshape documentation. It is quite hard (at
> > > least it is for me) to figure out what argument is needed for
> > > respectively "long to wide" and "wide to long", because reshapeWide and
> > > reshapeLong are documented together.
> > > - Do you agree with this?
> > > - Would you consider a proposal to modify the documentation?
> > > - If yes, what approach do you suggest? e.g. split in two pages?
> >
> > The current documentation is much clearer than it was when I first
> > started using R but we should always strive for more.
> >
> > I would suggest leaving the documentation in one place but it might be
> > helpful to add which direction is relevant for each parameter by placing
> > (to wide) or (to long) as appropriate. I think having completely
> > separate lists is not needed
>
> I have just checked in some updates to the documentation (in R-devel)
> which hopefully makes usage clearer. Any further suggestions are
> welcome. We are planning to add a short vignette as well, hopefully in
> time for R 4.1.0.
>
> > > 2) I do not think the documentation indicates that we can use varying
> > > argument to rename variables in reshapeWide.
> > > - Is this worth documenting?
> > > - Is the construct list(c()) really needed?
> >
> > Yes, because you may have more than one set of variables which need to
> > correspond to a single variable in long format. So in your example if
> > you also had 11 variables for the temperature as well as the
> > concentration each would need specifying as a separate vector in the list.
>
> That's a valid point, but on the other hand, direction="long" already
> supports specifying 'varying' as a vector, and it does simplify the
> single variable case. So we decided to be consistent and allow it for
> direction="wide" too, hopefully with loud enough warnings in the
> documentation about using the feature carelessly.
>
> Best,
> -Deepayan
>
> > Michael
> >
> > >
> > > reshape(Indometh,
> > > v.names = "conc",
> > > idvar = "Subject",
> > > timevar = "time",
> > > direction = "wide",
> > > varying = list(c("conc_0.25hr",
> > > "conc_0.5hr",
> > > "conc.0.75hr",
> > > "conc_1hr",
> > > "conc_1.25hr",
> > > "conc_2hr",
> > > "conc_3hr",
> > > "conc_4hr",
> > > "conc_5hr",
> > > "conc_6hr",
> > > "conc_8hr")))
> > >
> > > Thanks,
> > >
> > > Thomas
> > > __
> > > R-devel using r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> >
> > --
> > Michael
> > http://www.dewey.myzen.co.uk/home.html
> >
> > __
> > R-devel using 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] Possible bug in help file name generation
On Thu, Jun 24, 2021 at 5:31 PM Iñaki Ucar wrote:
>
> Hi,
>
> I noticed that R 4.1 places html files into the packages' help
> directory, compared to previous versions, which used an RDS. I found a
> possible bug in the code that processes the aliases from the Rd files
> and generates the names for these html files (I haven't identified
> where this happens though).
>
> To reproduce this, install e.g. the 'caper' package from CRAN and
> inspect the help directory. I find the following file:
>
> 'pgls.confint'$'\n''.html'
>
> which contains a special character. This comes from the fact that the
> file caper/man/pgls.profile.Rd in caper's source code contains a
> newline in the corresponding alias:
>
> \name{pgls.profile}
> \alias{pgls.profile}
> \alias{plot.pgls.profile}
> \alias{pgls.confint
> }
>
> and this ends up in the file name.
Yes, the code should probably do a trimws() somewhere, but this also
looks like something that maybe R CMD check should identify and
complain about.
Best,
-Deepayan
> --
> Iñaki Úcar
>
> __
> 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] Bundling MathJax
On Sun, Mar 13, 2022 at 6:18 PM Ivan Krylov wrote:
>
> Hello R-devel,
>
> I appreciate the efforts devoted towards improving equation typography
> in HTML manuals. Since MathML lost its status as the way to express
> mathematics on the web after its removal from Google Chrome in 2013,
> MathJax and KaTeX are probably the best options left: both TtH [1] and
> HeVeA [2] don't render math quite as well and likely don't do anything
> about accessibility of the resulting equations (which seems to be the
> reason to focus on the HTML documentation in the first place).
>
> Having seen r81881 [3], I would like to suggest bundling MathJax
> together with R instead of loading it from the Internet. Every now and
> then, I work from places with spotty Internet connection (e.g. mobile
> network on a train). If R defaults to downloading a file every time
> Rd2HTML is called, that would be very inconvenient to me, especially
> since the requests for external JavaScript could intermittently fail
> or take a long time to load, resulting in partially failed renders.
Usually browser caching should avoid multiple downloads, shouldn't it?
> For now, R documentation can be viewed without access to external
> resources (admittedly, not counting the use of external \figure{} and
> other Rd macros by packages, which is rare). I think that's a major
> strength of R and I would like to help preserve it.
Bundling is something we considered (and is still a possibility), but
ended up not doing mainly because it's more than just a single file.
E.g., these are the files bundled by mathjaxr:
https://github.com/wviechtb/mathjaxr/tree/master/src/mathjax/es5
Would it be reasonable to use the installation provided by mathjaxr
instead, if it is available?
Best,
-Deepayan
> --
> Best regards,
> Ivan
>
> [1] http://hutchinson.belmont.ma.us/tth/in_action.html
>
> [2] http://hevea.inria.fr/examples/test/suite.html
>
> [3]
> https://github.com/r-devel/r-svn/commit/55e013251cbaf8942d34820f1854c9cfc38e097b
>
> __
> 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] running examples with enhanced help engine also requires mime package
On Fri, Mar 25, 2022 at 9:48 PM Duncan Murdoch wrote:
>
> On 25/03/2022 12:07 p.m., Kevin Ushey wrote:
> > Hi,
> >
> > The new enhanced help system is fantastic! I've been playing around
> > with the enhanced help system introduced recently in R 4.2.0, and I
> > noticed one minor issue. When attempting to run examples from within a
> > Help page (in HTML help), if the knitr package is not installed, one
> > sees:
> >
> > To view output in the browser, the knitr package must be installed.
> >
> > I think this is expected. However, after installing the 'knitr'
> > package and attempting to run examples again, I see:
> >
> > Error in loadNamespace(x) : there is no package called 'mime'
> >
> > as it looks like 'knitr' (or a dependency?) is trying to use 'mime'
> > behind the scenes in the Help server. Because 'mime' is not an
> > explicit dependency of 'knitr', running install.packages("knitr")
> > isn't sufficient to ensure 'mime' is also installed (which a user
> > might have expected).
> >
> > I'm not sure if this should be resolved in 'knitr' (e.g. via just
> > depending on the 'mime' package) or if this should be tweaked in R
> > itself.
Thanks for the report and diagnosis.
I guess the R-level workaround would be to write a replacement for
knitr::image_uri(). That would probably have been fine if we forced
png to be the only output format, but I see no reason to restrict to
specific formats, so the flexibility is useful.
So I'll just add mime to the message.
Best,
-Deepayan
> This is related:
>
> https://github.com/yihui/xfun/issues/63
>
> Duncan Murdoch
>
> __
> 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] Not documenting a function and not getting a check error?
On Fri, Jan 6, 2023 at 1:49 AM Duncan Murdoch wrote:
>
> I'm in the process of a fairly large overhaul of the exports from the
> rgl package, with an aim of simplifying maintenance of the package.
> During this work, I came across the reverse dependency geomorph that
> calls the rgl.primitive function.
>
> I had forgotten that rgl.primitive was still exported: I've been
> thinking of it as an internal function for a few years now. I was
> surprised geomorph was able to call it.
>
> Particularly surprising to me was the fact that it is not properly
> documented. One of the help topics lists it as an alias, but it
> contains no usage info, and is not mentioned in the .Rd file other than
> the alias. And yet "R CMD check rgl" has never complained about it.
>
> Is this intentional?
Does the Rd file that documents it have \keyword{internal}? These are
not checked fully (as I realized recently while working on the help
system), and I guess that's intentional.
Best,
-Deepayan
>
> Duncan Murdoch
>
> __
> 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] Recycling in arithmetic operations involving zero-length vectors
On Mon, Jan 16, 2023 at 7:28 PM Duncan Murdoch wrote: > > On 16/01/2023 6:55 a.m., David Winsemius wrote: > > > > > > Sent from my iPhone > > > >> On Jan 16, 2023, at 6:11 PM, Duncan Murdoch > >> wrote: > >> > >> On 16/01/2023 5:23 a.m., Roland Fuß wrote: > >>> Dear R-core, > >>> The language definition is very clear: > >>> "As from R 1.4.0, any arithmetic operation involving a zero-length > >>> vector has a zero-length result." > >>> Thus, `1 + numeric()` returns `numeric(0)`. However, I don't find this > >>> very intuitive because usually the shorter vector is recycled to the > >>> length of the longer vector. Would it be possible to throw at least a > >>> warning for such cases? I don't expect them to be intended by most users. > >>> Best regards, > >> > >> The previous paragraph says "If the length of the longer vector is not a > >> multiple of the shorter one, a warning is given." Since 1 is not a > >> multiple of 0, that implies a warning should be given here. > >> > >> However, R 1.4.0 was released more than 20 years ago, so I would guess > >> there are lots of packages intentionally using this. For example, it's a > >> way to propagate bad inputs through a long calculation that allows a > >> single test at the end. > >> > >> And even unintentional uses are unlikely to lead to problematic results: > >> numeric(0) is usually a pretty clear signal that something is wrong. > >> > >> So I'd suggest a documentation change: "As from R 1.4.0, any arithmetic > >> operation involving a zero-length vector has a zero-length result *without > >> a warning*." > > > > I doubt that a documentation change will help very much. Roland is > > responding here with his and my surprise at the lack of a warning after > > witnessing my answer to an R newb Q where the impression at seeing > > ’numeric(0) was understood as the value 0. I suggested that many > > interpretations were possible and that a warning was given for NA > > generation. I stand with Roland in thinking a warning is appropriate. > > I didn't see this exchange, but I don't understand "a warning was given > for NA generation". We don't get a warning for 1 + NA. Do you mean > you'd like to get one? > > In any case, I think your anecdote illustrates a different problem: > printing numeric() as numeric(0) confused a beginning user. I've also > seen people get confused by that. > > Perhaps the change should be to the way numeric(0) is printed, but that > would also have consequences, since some people test the way output is > printed. > > Or perhaps we should just recognize that it's in the nature of being a > beginning user to be confused sometimes, and just help them to grow out > of that stage. > > Before a change like one of these is made, someone should make it in a > local copy, then run R CMD check on every package on CRAN to see how > disruptive it is. Maybe adding a warning() will uncover so few > intentional uses that fixing them is worthwhile. To even do that, we would have to first decide which "cases" should produce a warning. Let's say `1 + x` should give a warning when x = numeric(0). Then should `x^2` also produce a warning? Should `x^0.5`? Should `sqrt(x)`? Should `log(x)`? -Deepayan > The trouble is, running checks across CRAN is a very resource-intensive > exercise, and analyzing the results is a very developer-intensive > exercise. I'm sure the doc change is easier. > > Duncan Murdoch > > __ > 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] tab-complete for non-syntactic names could attempt backtick-wrapping
On Thu, Mar 2, 2023 at 2:09 PM Ivan Krylov wrote: > > There turn out to be a few more things to fix. > > One problem is easy to solve: vapply() needs a third argument > specifying the type of the return value. (Can we have unit tests for > tab completion?) There are tests in src/library/utils/tests/completion.R which should get run by make check-devel (which runs R CMD check on all base packages). > The other problem is harder: `comps` defaults to an empty string, and > you can't have a symbol consisting of an empty string, because this > value is internally reserved for missing function arguments. I think > you can return(paste0(prefix, op)) if length(comps) == 0L, but this is > still somewhat worrying. R tries to prevent empty names, so I wouldn't > expect specialOpCompletionsHelper() to return an empty string, but I > can't prove it right now. > > On the other hand, x$'a string' is the same as x$`a string`. Could we > just drop as.name() and keep the return value being a string literal? > I'm not sure about this, either. See my just-posted response on bugzilla for other issues to look out for. Best, -Deepayan > -- > Best regards, > Ivan > > __ > 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] Autocompletion for the new S3 generic @ method?
Thanks, we are discussing the details, but we will definitely add
something along those lines before 4.3.0 is released.
Best,
-Deepayan
On Sun, Apr 2, 2023 at 6:39 PM Tomasz Kalinowski wrote:
>
> I agree, this is a good idea and would be very helpful in interactive
> contexts.
>
> I have a draft patch implementing this feature here:
> https://github.com/r-devel/r-svn/pull/122
> (Append “.patch” to the URL to get a raw patch.)
>
> Regards,
> Tomasz
>
> > On Mar 31, 2023, at 2:11 PM, Karolis K
> > wrote:
> >
> > Hello,
> >
> > In the current R-devel @ is S3 generic, so we can do things like - for
> > example - use it to extract matrix rows by name:
> >
> >.S3method("@", "mm", function(object, name) object[name,])
> >m <- structure(matrix(rnorm(20), ncol=2), dimnames=list(paste0("row",
> > 1:10), paste("col", 1:2)), class="mm")
> >
> >m@row1
> >
> > However, seems like currently it does not support autocompletion.
> >
> > Wouldn’t it make sense to add a method like .EtaNames() which would provide
> > tab autocompletions for x@ in the same way current .DollarNames() does
> > for x$?
> >
> > Regards,
> > Karolis K.
> > __
> > 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] Autocompletion for the new S3 generic @ method?
This should be enabled now in R-devel and R 4.3.0 by writing
.AtNames() methods.
findMatches() is also exported now; this is basically grep(), but will
do fuzzy matching if it's activated.
Best,
-Deepayan
On Mon, Apr 3, 2023 at 9:37 AM Deepayan Sarkar
wrote:
>
> Thanks, we are discussing the details, but we will definitely add
> something along those lines before 4.3.0 is released.
>
> Best,
> -Deepayan
>
> On Sun, Apr 2, 2023 at 6:39 PM Tomasz Kalinowski
> wrote:
> >
> > I agree, this is a good idea and would be very helpful in interactive
> > contexts.
> >
> > I have a draft patch implementing this feature here:
> > https://github.com/r-devel/r-svn/pull/122
> > (Append “.patch” to the URL to get a raw patch.)
> >
> > Regards,
> > Tomasz
> >
> > > On Mar 31, 2023, at 2:11 PM, Karolis K
> > > wrote:
> > >
> > > Hello,
> > >
> > > In the current R-devel @ is S3 generic, so we can do things like - for
> > > example - use it to extract matrix rows by name:
> > >
> > >.S3method("@", "mm", function(object, name) object[name,])
> > >m <- structure(matrix(rnorm(20), ncol=2), dimnames=list(paste0("row",
> > > 1:10), paste("col", 1:2)), class="mm")
> > >
> > >m@row1
> > >
> > > However, seems like currently it does not support autocompletion.
> > >
> > > Wouldn’t it make sense to add a method like .EtaNames() which would
> > > provide tab autocompletions for x@ in the same way current
> > > .DollarNames() does for x$?
> > >
> > > Regards,
> > > Karolis K.
> > > __
> > > 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] data.frame weirdness
They differ in whether the row names are "automatic": > .row_names_info(a1) [1] -3 > .row_names_info(a2) [1] 3 Best, -Deepayan On Tue, 14 Nov 2023 at 08:23, Gabor Grothendieck wrote: > > What is going on here? In the lines ending in the inputs and outputs > are identical yet one gives a warning and the other does not. > > a1 <- `rownames<-`(anscombe[1:3, ], NULL) > a2 <- anscombe[1:3, ] > > ix <- 5:8 > > # input arguments to are identical in both cases > > identical(stack(a1[ix]), stack(a2[ix])) > ## [1] TRUE > identical(a1[-ix], a2[-ix]) > ## [1] TRUE > > > res1 <- data.frame(stack(a1[ix]), a1[-ix]) > res2 <- data.frame(stack(a2[ix]), a2[-ix]) > ## Warning message: > ## In data.frame(stack(a2[ix]), a2[-ix]) : > ## row names were found from a short variable and have been discarded > > # results are identical > identical(res1, res2) > ## [1] TRUE > > > -- > Statistics & Software Consulting > GKX Group, GKX Associates Inc. > tel: 1-877-GKX-GROUP > email: ggrothendieck at gmail.com > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] data.frame weirdness
On Tue, 14 Nov 2023 at 09:41, Gabor Grothendieck
wrote:
>
> Also why should that difference result in different behavior?
That's justifiable, I think; consider:
> d1 = data.frame(a = 1:4)
> d2 = d3 = data.frame(b = 1:2)
> row.names(d3) = c("a", "b")
> data.frame(d1, d2)
a b
1 1 1
2 2 2
3 3 1
4 4 2
> data.frame(d1, d2)
a b
1 1 1
2 2 2
3 3 1
4 4 2
> data.frame(d1, d3)
a b
1 1 1
2 2 2
3 3 1
4 4 2
Warning message:
In data.frame(d1, d3) :
row names were found from a short variable and have been discarded
> data.frame(d2, d3)
b b.1
a 1 1
b 2 2
> On Tue, Nov 14, 2023 at 9:38 AM Gabor Grothendieck
> wrote:
> >
> > In that case identical should be FALSE but it is TRUE
Yes, or at least both cases should warn (or not warn). Certainly not
ideal, but one of the inevitable side effects of having two different
ways of storing row names that R tries to pretend should be
exchangeable, but are not (and some code not having caught up).
Part of the problem, I think, is that it's not clear what the ideal
behaviour should be in such cases (to warn or not to warn).
Best,
-Deepayan
> > identical(a1, a2)
> > ## [1] TRUE
> >
> >
> > On Tue, Nov 14, 2023 at 8:58 AM Deepayan Sarkar
> > wrote:
> > >
> > > They differ in whether the row names are "automatic":
> > >
> > > > .row_names_info(a1)
> > > [1] -3
> > > > .row_names_info(a2)
> > > [1] 3
> > >
> > > Best,
> > > -Deepayan
> > >
> > > On Tue, 14 Nov 2023 at 08:23, Gabor Grothendieck
> > > wrote:
> > > >
> > > > What is going on here? In the lines ending in the inputs and
> > > > outputs
> > > > are identical yet one gives a warning and the other does not.
> > > >
> > > > a1 <- `rownames<-`(anscombe[1:3, ], NULL)
> > > > a2 <- anscombe[1:3, ]
> > > >
> > > > ix <- 5:8
> > > >
> > > > # input arguments to are identical in both cases
> > > >
> > > > identical(stack(a1[ix]), stack(a2[ix]))
> > > > ## [1] TRUE
> > > > identical(a1[-ix], a2[-ix])
> > > > ## [1] TRUE
> > > >
> > > >
> > > > res1 <- data.frame(stack(a1[ix]), a1[-ix])
> > > > res2 <- data.frame(stack(a2[ix]), a2[-ix])
> > > > ## Warning message:
> > > > ## In data.frame(stack(a2[ix]), a2[-ix]) :
> > > > ## row names were found from a short variable and have been discarded
> > > >
> > > > # results are identical
> > > > identical(res1, res2)
> > > > ## [1] TRUE
> > > >
> > > >
> > > > --
> > > > Statistics & Software Consulting
> > > > GKX Group, GKX Associates Inc.
> > > > tel: 1-877-GKX-GROUP
> > > > email: ggrothendieck at gmail.com
> > > >
> > > > __
> > > > R-devel@r-project.org mailing list
> > > > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
> >
> > --
> > Statistics & Software Consulting
> > GKX Group, GKX Associates Inc.
> > tel: 1-877-GKX-GROUP
> > email: ggrothendieck at gmail.com
>
>
>
> --
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.
> tel: 1-877-GKX-GROUP
> email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'modifyList' drops (not adds) NULL components
On Thu, Jun 27, 2013 at 10:59 PM, Raubertas, Richard
wrote:
> Dear list,
>
> Utils::modifyList() drops NULL components in its second argument, instead of
> adding them to the first argument. Compare:
>> modifyList(x=list(A=1), val=list(B=2, C=3))
> $A
> [1] 1
>
> $B
> [1] 2
>
> $C
> [1] 3
>
>> modifyList(x=list(A=1), val=list(B=NULL, C=3))
> $A
> [1] 1
>
> $C
> [1] 3
>
> To me this seems inconsistent with the documentation ("Elements in 'val'
> which are missing from 'x' are added to 'x'."),
Agreed.
> and also with how I'd want the function to behave.
Note that you still get
> foo <- modifyList(x=list(A=1), val=list(B=NULL, C=3))
> foo$B
NULL
So is there a specific reason you want the NULL elements to be
explicitly listed?
-Deepayan
>
>> sessionInfo()
> R version 3.0.1 Patched (2013-06-16 r62969)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
>
> locale:
> [1] LC_COLLATE=English_United States.1252
> [2] LC_CTYPE=English_United States.1252
> [3] LC_MONETARY=English_United States.1252
> [4] LC_NUMERIC=C
> [5] LC_TIME=English_United States.1252
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
>
> Richard Raubertas
> Merck & Co.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Extending suggestion for stopifnot
On Wed, Aug 21, 2013 at 12:11 AM, ivo welch wrote:
> I am using a variant of stopifnot a lot. can I suggest that base R
> extends its functionality? I know how to do this for myself. this is
> a suggestion for beginners and students. I don't think it would break
> anything.
>
> first, I think it would be more useful if it had an optional character
> string, so users could write
>
> stopifnot( is.matrix(m), "m is not a matrix" )
How is this better/nicer/more preferable than, say,
if (!is.matrix(m)) stop("m is not a matrix")
?
I think stopifnot() is mostly meant for regression tests and sanity
checks, and should not be used instead of stop() if you want nicely
formatted error messages.
-Deepayan
> this would mean that stopifnot would have to detect whether the last
> argument is a string. (I think stopifnot should have had only one
> condition, and one should have used all() to test multiple conditions,
> but this is a bridge that was already crossed.) upon failure,
> stopifnot should print the character string. that's it.
>
>
> A second enhancement would be a "smart string", which knows that
> everything inside {{...}} should be evaluated.
>
> stopifnot( is.matrix(m), "m is not a matrix, but a {{class(m)}}" )
>
>
> my own programming variant looks even nicer,
>
>is.matrix(m) %or% "m is not a matrix but a {{class(m)}}"
>
> but requesting base R to add the %and% and %or% (or, better yet, 'and'
> and 'or') operators by default would be pushing my luck.
>
> /iaw
>
>
>
> Ivo Welch (ivo.we...@gmail.com)
>
> __
> 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] Extending suggestion for stopifnot
On Wed, Aug 21, 2013 at 3:30 AM, ivo welch wrote:
> thx, deepayan: how is stopifnot better than
> if (!all(...)) stop()
But I am not claiming that it is!
If you think it is not useful, then don't use stopifnot(), use stop()
instead, and tell your students to do so as well.
> given that we have stopifnot() and I have seen it used often, I think
> my two suggestions would make it better.
Maybe it will (in some specific use cases). But looking at your
suggestion purely from the point of view of "is it worth incorporating
into base R?", I don't see enough justification. The disadvantage is
that it will complicate a simple function. The supposed advantage is
only an advantage when you use stopifnot() in a way that was not
intended, whereas there is already an alternative that does almost
exactly what you want (at least you haven't yet explained why you are
not happy with stop()). Interpolated strings may be cool, but I don't
see a big readability advantage of
if (!is.matrix(m)) stop("m is not a matrix, but a {{class(m)}}")
over
if (!is.matrix(m)) stop("m is not a matrix, but a ", class(m))
Note that I'm not saying that stop() is perfect or anything, or that
there is no need for alternatives. Just that I'm not convinced that
the base R changes you want are justified.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Type annotations for R function parameters.
On Fri, Aug 30, 2013 at 2:49 PM, Оботуров Артем wrote: > Hello. > > One of my clients asked if it would be possible to have an IDE which could > use type discovery for R functions to make flow-like construction of an R > program. Something like a LabView graphical composition of processing > elements. > > They called this type of program composition a "workflow". > > I looked at some of this programs, like: > * Orange http://orange.biolab.si/ > * RedR http://www.red-r.org/ > * Rattle http://rattle.togaware.com/ > * Rpad https://code.google.com/p/rpad/ > > and all of them did type introspection (they made mapping between R > functions and their IDE's visual framework) by hand for each function of > supported packages which is time and resource consuming. > > So, to reduce an amount of code to be written for adapters between R and > IDE some kind of annotations could be introduced over parameters and return > values. Those could be optional and will help to discover type information > for support of dynamic composition of programs. > > Do you have any suggestions on the topic? See http://bioconductor.org/packages/2.12/bioc/html/TypeInfo.html -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] legitimate use of :::
On Wed, May 14, 2014 at 12:29 AM, Duncan Murdoch
wrote:
> On 13/05/2014 12:14 PM, Knut Krueger wrote:
>>
>> Is there another new solution for this issue?
>> especially I would like to use:
>>
>> utils:::.win32consoleCompletion
>> the use of this is suggested in the completion.r file of utils:
>>
>> ## test some typical completion attempts
>> library(utils)
>> testLine <- function(line, cursor = nchar(line))
>> {
>> str(utils:::.win32consoleCompletion(line, cursor))
>> }
>>
>> testLine("")
>>
>
> I think you are misunderstanding the comments in that file. It's an
> internal set of tests for the package, so "test some typical completion
> attempts" is a description of the tests that follow, it's not a suggestion
> that you should be able to run those lines
> from your package.
>
> If you do want access to the completion mechanism from a package, you should
> write to its author (Deepayan Sarkar) and explain the kinds of things you
> need to do. If you can convince him that giving you access is worth the
> trouble of exposing some of it to user-level code, then he'll export a
> function for you. (I think it's unlikely to be .win32consoleCompletion, but
> who knows.)
Yes, .win32consoleCompletion() was meant for use by the Windows GUI,
but I can see a use-case for something similar elsewhere (for example,
ESS defines something analogous).
But I don't immediately see why another R package should need this. If
you have a legitimate use, we can discuss off-list and come up with a
solution.
-Deepayan
>
> Duncan Murdoch
>
>
>> (full quote because of the age of the tread)
>>
>>
>> Kind regards Knut
>> Am 22.08.2013 20:57, schrieb Michael Friendly:
>> > On 8/22/2013 7:45 AM, Uwe Ligges wrote:
>> >>
>> >>
>> >> On 22.08.2013 07:45, Yihui Xie wrote:
>> >>> Hi,
>> >>>
>> >>> So now R CMD check starts to warn against :::, but I believe sometimes
>> >>> it is legitimate to use it when developing R packages. For example, I
>> >>> have some utils functions that are not exported but I want to share
>> >>> them across the packages that I maintain. I do not need to coordinate
>> >>> with other authors about these internal functions since I'm the only
>> >>> author and I know clearly what I'm doing, and I want to avoid copying
>> >>> and pasting the code across packages just to avoid the NOTE in R CMD
>> >>> check. What should I do in this case?
>> >>
>> >> Nothing. The way you describe above seems to be a reasonable usage, iff
>> >> you are the same maintainer who knows what is going on. Other
>> >> maintainers should not use one of your not exported (hence non API)
>> >> functions, of course.
>> >>
>> >> Uwe Ligges
>> >>
>> >>
>> >
>> > Related to this is the use of other-package unexported utility functions
>> > that don't pass Uwe's iff test, but I, as maintainer,
>> > want to use in my package.
>> >
>> > Cases in point: in heplots, I had used stats:::Pillai, stats:::Wilks,
>> > stats:::Roy and stats:::LH for calculation in one of my functions.
>> > Similarly, I had a need to use car:::df.terms, also unexported, but
>> > don't want to ask John Fox to export it just for my use. Uwe's
>> > reply suggests that I should not be using car:::df.terms, however.
>> >
>> > To avoid the NOTEs (which often triggers a 'pls fix' upon submission to
>> > CRAN), I simply copied/pasted these functions to my package, but this
>> > seems wasteful.
>> >
>> > -Michael
>> >
>> >
>>
>> __
>> 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] [patch] Add support for editor function in edit.default
On Sun, Aug 24, 2014 at 9:14 AM, Scott Kostyshak wrote: > On Tue, May 20, 2014 at 5:55 AM, Scott Kostyshak > wrote: >> Regarding the following extract of ?options: >> ‘editor’: a non-empty string, or a function that is called with a >> file path as argument. >> >> edit.default currently calls the function with three arguments: name, >> file, and title. For example, running the following > > To be clear with what I view as problematic, note in the above that > the documentation says the function is called with a file path as an > argument, suggesting one argument; but in practice it is called with > three arguments. > >> vimCmd <- 'vim -c "set ft=r"' >> vimEdit <- function(file_) system(paste(vimCmd, file_)) >> options(editor = vimEdit) >> myls <- edit(ls) >> >> gives "Error in editor(name, file, title) : unused arguments (file, title)". >> >> The attached patch changes edit.default to call the editor function >> with just the file path. There is at least one inconsistent behavior >> that this patch causes in its current form. It does not obey the >> following (from ?edit): >> Calling ‘edit()’, with no arguments, will result in the temporary >> file being reopened for further editing. >> >> I see two ways to address this: (1) add a getEdFile() function to >> utils/edit.R that calls a function getEd() defined in edit.c that >> returns DefaultFileName; or (2) this patch could be rewritten in C in >> a new function in edit.c. >> >> Is there any interest in this patch? >> If not, would there be interest in an update of the docs, either >> ?options (stating the possibility that if 'editor' is a function, it >> might be called with 'name', 'file', and 'title' arguments) or ?edit >> ? > > Any interest in this patch? If not, would a patch for the > documentation be considered? Given that edit() itself is called with the three arguments, it seems more general to pass them to the editor function, and I don't see the need for a special case. You can always write your function as vimEdit <- function(file_, ...) system(paste(vimCmd, file_)) I will clarify the documentation. Best, -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Command completion of the R binary / Ubuntu
On Wed, Jan 11, 2012 at 4:16 PM, Claudia Beleites wrote: > Dear Deepayan and dear list, > > I notice a small inconsistency with the command completion of the R CMD > check. --no-latex is deprecated sincs R 2.12.0 and defunct since 2.13.0 > but the command line completion still suggests it: > > cb@cbdesktop:~/r-devel$ bin/R CMD check --no- > --no-clean --no-examples --no-latex --no-vignettes > --no-codoc --no-install --no-tests > cb@cbdesktop:~/r-devel$ bin/R CMD check --no-latex > Fehler: '--no-latex' is defunct: use '--no-manual' instead > > I gather the command line options could be updated to current R CMD > check in file /etc/bash_completion.d/R: > > cb@cbdesktop:~/tmp$ diff R /etc/bash_completion.d/R > 244,247c244,245 > < --no-install --no-tests --no-vignettes --no-manual \ > < --no-rebuild-vignettes --install-args --check-subdirs \ > < --extra-arch --multiarch --no-multiarch --force-multiarch \ > < --timings --use-gct --use-valgrind --rcfile" > --- >> --no-install --no-tests --no-vignettes --no-latex \ >> --use-gct --use-valgrind --rcfile" > > I gather from the mailing list archives, that the original is available at > http://code.google.com/p/rcompletion/source/browse/trunk/bash_completion/R > > Should I suggest the patch there? Will changes propagate to the packaged > linux distributions from there or should the updated file be brought to > the attention somewhere else? Thanks for the patch. I believe only Debian/Ubuntu package it (and this would have been more appropriate for r-sig-debian). I'll coordinate with Dirk et al to update the relevant files. -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [ESS] completion in [] (R internal completion fails)
On Wed, Mar 14, 2012 at 3:27 PM, Vitalie Spinu wrote:
>
> Hello,
>
> I am forwarding this from ESS mailing list, as it's a failure of
> internal R completion system:
>
> This fails:
>
> utils:::.assignLinebuffer('iris[iris$Spec')
> utils:::.assignEnd(15)
> utils:::.guessTokenFromLine()
> utils:::.completeToken()
> utils:::.retrieveCompletions() ## -> [1] "iris[iris$Spec"
>
> This works
>
> utils:::.assignLinebuffer('iris[ iris$Spec') # note the space after [
> utils:::.assignEnd(15)
> utils:::.guessTokenFromLine()
> utils:::.completeToken()
> utils:::.retrieveCompletions() ## -> [1] "iris$Species"
This is controlled by
> getOption("rl_word_breaks")
[1] " \t\n\"\\'`><=%;,|&{()}"
Basically [ does not break words into tokens (space does). You can
change this to
options(rl_word_breaks = paste(getOption("rl_word_breaks"), "[]", sep = ""))
But then the following won't work:
> x = list(aaa = list(AAA = 1, BBB = 2))
> x[[1]]$A
-Deepayan
> Best,
> Vitalie.
>
> Andreas Leha
> on Wed, 14 Mar 2012 10:21:37 +0100 wrote:
>
> >> Hi all,
> >> I am seeing strange behaviour with completion inside [].
>
> >> Suppose I have
> >> ttt <- data.frame(aaa=1, bbb=1)
> >> and I want to run
> >> ttt$aaa[ttt$aaa == 1] <- 2
>
> >> then completion at this point fails:
> >> ttt$aaa[ttt$aa
>
> >> On the other hand, strangly enough, this works as expected:
> >> ttt$aaa[ ttt$aa
>
> >> Regards,
> >> Andreas
>
> >> __
> >> ess-h...@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/ess-help
>
> __
> 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] warning in lattice key function
On Thu, Aug 16, 2012 at 8:35 AM, Richard M. Heiberger wrote:
> ## this example shows a problem in key.
> tmp <- data.frame(y=rnorm(10), g=rep(ordered(c("A","B")), 5))
> bwplot(y ~ g, data=tmp,
>key=list(
> text=list(c("A","B"), col=c("blue","red")),
> points=list(pch=c(17, 16), col=c("blue","red")),
> space="top", columns=2, border=TRUE,
> title="Treatment", cex.title=.9
> )
>)
> ## The example works without warning messages in 2.15.1.
Thanks for the report. This is due to rep(NULL, length.out=...) now
giving a warning.
As Prof Ripley has mentioned, a similar bug was fixed elsewhere, but
this one still persists. I haven't yet found an easy way of fixing all
of these, so if you find more instances, please report them to me (or
file a bug at
https://r-forge.r-project.org/tracker/?func=browse&group_id=638&atid=2567),
and I'll take a look as soon as possible.
-Deepayan
> ## I first detected the problem in
> # R Under development (unstable) (2012-07-24 r59961) ## windows
> # R Under development (unstable) (2012-08-02 r60091) ## macintosh
> ## The problem still exists in
> ## R Under development (unstable) (2012-08-13 r60245) -- "Unsuffered
> Consequences"
> ## downloaded from lib.stat.cmu.edu Wed Aug 15 2012 11PM EST
>
>
>> tmp <- data.frame(y=rnorm(10), g=rep(ordered(c("A","B")), 5))
>> bwplot(y ~ g, data=tmp,
> +key=list(
> + text=list(c("A","B"), col=c("blue","red")),
> + points=list(pch=c(17, 16), col=c("blue","red")),
> + space="top", columns=2, border=TRUE,
> + title="Treatment", cex.title=.9
> + )
> +)
> Warning messages:
> 1: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
> 2: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
> 3: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
> 4: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
> 5: In FUN(X[[9L]], ...) : 'x' is NULL so the result will be NULL
>> version
>_
> platform i386-w64-mingw32
> arch i386
> os mingw32
> system i386, mingw32
> status Under development (unstable)
> major 2
> minor 16.0
> year 2012
> month 08
> day13
> svn rev60245
> language R
> version.string R Under development (unstable) (2012-08-13 r60245)
> nickname Unsuffered Consequences
>>
>
> [[alternative HTML version deleted]]
>
> __
> 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] if(--as-cran)?
On Wed, Sep 5, 2012 at 11:41 AM, Duncan Murdoch wrote: > On 12-09-04 8:19 PM, Kasper Daniel Hansen wrote: >> >> On Tue, Sep 4, 2012 at 6:02 PM, Duncan Murdoch >> wrote: >>> >>> On 04/09/2012 5:42 PM, Dirk Eddelbuettel wrote: On 4 September 2012 at 17:26, Duncan Murdoch wrote: | On 04/09/2012 5:14 PM, Dirk Eddelbuettel wrote: | > An add-on argument to the already established option --as-cran may be the | > best. | > | > And to iterate, what bugs me is that for _me_ on _my_ machine developing _my_ | > package I have remember how to enable what is now (as per CRAN's decree) | > "non-standard behaviour" of full testing. I fully agree with what Terry had | > said: more tests are better (when we develop). I want the full suite at my | > end; that is after all why we wrote it! | | You don't have to remember that, you need to figure it out once, write a | script that sets the environment variables that enable it, and then you | can forget it. "In theory, theory and practice are the same. In practice, they are not." The main test script long had exactly such a setting; I wrote what I wrote because it is _still the wrong way around_ and as I happen to have added to unit tests this weekend _having suffered through precisely this setting_. But we are on different wavelengths here and I evidently do not get my point across to you. And as you are the one who could make a change where it matters, I have no choice but to rest my case in frustration. >>> >>> >>> >>> If you want to give up, then give up, but then don't complain about the >>> current behaviour. If you want to fix it, then continue the discussion. >>> >>> You're right that we're on different wavelengths. If you want some tests >>> to >>> run at home but not on CRAN, then somewhere there has to be a >>> conditional. >>> I'm suggesting that the conditional should be "if there's a tight time >>> limit, skip this". >>> >>> I don't remember if this was your suggestion, but someone has suggested >>> "if >>> we're running with the --as-cran option, skip this" and others have >>> suggested "if we're running on CRAN, skip this". I don't see why you >>> find >>> my suggestion so objectionable. If you want, I'll repeat why I find the >>> other two suggestions objectionable. >> >> >> I agree with Duncan that having an option long/short makes more sense >> than with/without cran, as long as cran sets that option to be short. > >> >> >> I would also prefer a command line switch to R CMD check to an >> environment variable, but I'll be very happy with a standardized >> environment variable. > > > I honestly don't see the need for a standardized variable. I've told you > how to detect that you are running --as-cran; if that isn't sufficient > information, then you, the package author, need to set up something more > elaborate, and assume that if it's not set up, then someone else (maybe > CRAN) is running the test. So maybe documenting that (_R_CHECK_TIMINGS_) more formally in R-exts would be sufficient? -Deepayan > I asked the CRAN powers-that-be about the possibility of querying the amount > of time remaining before a timeout; since the different platforms all use > different mechanisms to enforce a timeout, that's not really practical. So > the best you could hope for is to know that a timeout is in effect. Before > I wrote any code, I'd need to hear why --as-cran detection isn't sufficient. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question lattice SplomT
On Mon, Sep 24, 2012 at 9:22 PM, Christian Hoffmann wrote: > Dear Deepayan Sarkar, > > I have (again) a question concerning "panel" and my function "SplomT", see > attachments. Some time ago you helped me to write this function, thanks > again. I have used it to great advantage in my statistics instructions. Now > the problem I encounter is that the .pdf figure generated in Sweave consists > of > > one extra empty page at the start. This seems to be due to the get.gpar() call in the SplomT() function -- it produces a new page if it is called before any graphics output is drawn. That's not quite correct: The point is that grid.newpage() does some magic to NOT create a new page if it realizes that it is being called with a fresh device with nothing drawn on it yet. Calling get.gpar() is enough to make that magic fail, so the grid.newpage() call inside print.trellis() is actually creating a new page. Your options are: (1) get rid of the get.gpar()$cex call (can it be anything other than 1 on a new device?), or (2) call print(splom(...), newpage=FALSE) -Deepayan > This prevents it from showing up in the final .pdf document. I am not sure > whether this has any thing to do with Sweave. (If the statement is executed > on the command line, the plot in the Quartz window looks allright.) > > Since I have no full version of Adobe Acrobat I cannot eliminate the empty > first page. I tried to fiddle around with the panel functions, but was not > table to mimic my function. > > Thanks for your attention and for looking at my problem. > > Christian Hoffmann > > PS: for *r-devel*: Could this be an Sweave problem? > > Files attached: > SplomT.Rnw : File containing the Functiond and an example, > SplomT.tex : Result from Sweave of .Rnw, > SplomT.pdf : Result from TeXing the .tex, > Fig_A.pdf: Resulting figure from Sweave > SplomT.png : Screenshot of Fig_A.pdf > > sessionInfo() > R version 2.15.1 (2012-06-22) > Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) > > locale: > [1] C > > attached base packages: > [1] tools tcltk stats4splines parallel datasets compiler > [8] graphics grDevices stats grid utils methods base > > other attached packages: > [1] survival_2.36-14 spatial_7.3-3 rpart_3.1-53 nnet_7.3-1 > [5] nlme_3.1-104 mgcv_1.7-18 foreign_0.8-50 codetools_0.2-8 > [9] cluster_1.14.2class_7.3-3 boot_1.3-4 Matrix_1.0-6 > [13] MASS_7.3-18 KernSmooth_2.23-7 cwhmisc_3.0 lattice_0.20-6 >> > > -- > Christian W. Hoffmann, > CH - 8915 Hausen am Albis, Switzerland > Rigiblickstrasse 15 b, Tel.+41-44-7640853 > c-w.hoffm...@sunrise.ch, > christ...@echoffmann.ch, > www.echoffmann.ch > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Colour Schemes
On 5/21/09, Barry Rowlingson wrote: > On Thu, May 21, 2009 at 2:18 PM, wrote: > > > Most of the plots where colour is typically used to signify a variable > > already do map colours to data values. Take a look at help pages for > > levelplot/contourplot/wireframe from the lattice package, and image from > > base graphics. > > > > (The format is typically slightly different to your suggested > > specification, though the principle is the same. The functions take a > > vector of cut points, and a vector of colours.) > > > The problem here is that the user doesn't have exact control of the > mapping from value to colour. For example (using a slightly more > safe-for-use-after-lunch version of the levelplot example grid): > > x <- seq(pi/4, 5 * pi, length.out = 100) > y <- seq(pi/4, 5 * pi, length.out = 100) > r <- as.vector(sqrt(outer(x^2, y^2, "+"))) > grid <- expand.grid(x=x, y=y) > grid$z <- r > grid$z2 = r *0.5 > > > Then I do: > > levelplot(z~x*y, grid, cuts = 5, col.regions=rainbow(5)) > > very nice, but suppose I want to show $r2 on the same colour scale, I > can't just do: > > levelplot(z2~x*y, grid, cuts = 5, col.regions=rainbow(5)) > > because that looks the same as the first one since levelplot uses the > whole colour range. But you could specify an explicit 'at' vector specifying the color breakpoints: effectively, you want at = do.breaks(zlim, 5). lattice does have a function called 'level.colors' that factors out the color assignment computation. -Deepayan > > > The base graphics "image" function has zlim arguments which let you do: > > z=outer(1:10,1:10,"*") > image(z) > image(z/2, zlim=range(z)) > > but again, not obvious, and complex/impossible when using more > sophisticated colour mappings. > > > > There may be some utility in creating functions to generate these colour > > maps outside of the plotting functions, if only so that the code can be > > recycled for new functions. > > > Exactly, it would make a new package. > > > Barry > > > __ > 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] Colour Schemes
On Thu, May 21, 2009 at 10:53 AM, Barry Rowlingson
wrote:
> On Thu, May 21, 2009 at 5:29 PM, Deepayan Sarkar
> wrote:
>
> [oops I didnt reply-to-all]
>
>> But you could specify an explicit 'at' vector specifying the color
>> breakpoints: effectively, you want at = do.breaks(zlim, 5).
>>
>> lattice does have a function called 'level.colors' that factors out
>> the color assignment computation.
>>
> Yes, but these things are all at the wrong conceptual level. What you
> are constructing here is a function that maps value to colour, but
> keeping it as breaks and cut values and colours instead of
> representing it as a function. Wouldn't it be nicer to build a real
> function object and have that to pass around?
If that tickles your fancy, it's not a big stretch to get to
library(lattice)
continuousColours <- function(at, col.regions, ...)
{
function(x) {
level.colors(x, at = at, col.regions = col.regions, ...)
}
}
## caveat: level.colors requires 'at' values to be unique, hence the 999,1001
scheme2 <-
continuousColours(at = list(-1000, 0, 400, 999, 1001, 1),
col.regions = c("blue", "sandYellow",
"grassGreen", "rockBrown", "white"))
## you could do something similar with your list format too, of course.
---
which gives
> scheme2(c(-500, -200, 200, 2000))
[1] "blue" "blue" "sandYellow" "white"
But generally speaking, I wouldn't presume to dictate that any given
approach is universally "nicer" than another; I don't expect others to
have the same tastes as me, and conversely, don't expect to be told
what my tastes should be (if I did, I would probably be using Excel).
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] ggplot2 x axis question
On Mon, Jun 29, 2009 at 9:05 AM, hadley wickham wrote:
> In that case, try:
>
> qplot(reorder(factor(model),delta),delta,data=growthm.bic)
>
> Deepayan: do you think there should also be a numeric method for reorder?
r-devel now has a reorder.default (replacing reorder.factor and
reorder.character), so reorder() should also work for numeric data.
-Deepayan
> Hadley
>
> On Mon, Jun 29, 2009 at 10:39 AM, Christopher
> Desjardins wrote:
>> Hi Hadley,
>> Thanks for the reply and the great graphing package. That code is giving me
>> the following error:
>>
>>> qplot(reorder(model,delta),delta,data=growthm.bic)
>> Error in UseMethod("reorder") : no applicable method for "reorder"
>>
>> Cheers,
>> Chris
[...]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] more special completions
On 8/21/09, Romain Francois wrote: > Hi, > > Would it be possible to add the capability for functions to register how > they would like to complete themselves. > > Currently, there is the .addFunctionInfo, but it allows only functions to > register a static list of potential completions, I was thinking of a way to > register not a fixed list of possible completions, but a __function__ that > would calculate completions dynamically. > > This could be useful for the "new" function in R, if associated with > something that can retrieve the current list of S4 classes (not sure this > exists). > > Another example of where this could be used would be the .jnew function > from rJava, where the first argument is a java class, associated with > something that can complete java class names. That should be useful (library, data, etc. are already hard-coded to do special completion, but there is no reason for them to be special). I'll have to think about how best to implement this. I should have time to work in this in a couple of weeks (I also hope to tackle your earlier request on $ completion then). -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] more special completions
On 8/21/09, Vitalie S. wrote: > On Fri, 21 Aug 2009 11:21:03 +0200, Romain Francois > wrote: > > > > Hi, > > > > Would it be possible to add the capability for functions to register how > they would like to complete themselves. > > > > Currently, there is the .addFunctionInfo, but it allows only functions to > register a static list of potential completions, I was thinking of a way to > register not a fixed list of possible completions, but a __function__ that > would calculate completions dynamically. > > > > This could be useful for the "new" function in R, if associated with > something that can retrieve the current list of S4 classes (not sure this > exists). > > > > Another example of where this could be used would be the .jnew function > from rJava, where the first argument is a java class, associated with > something that can complete java class names. > > > > Not sure, but another example may be a class dependent completion for > generic functions depending on first argument. Like print(df,... ) where df > a data.frame to complete, digits = NULL, quote = FALSE, right = TRUE, > row.names = TRUE instead of only (x,...). That sort of already happens (have you tried?), but instead of print.data.frame, it gives you arguments of all print methods (only for S3 generics though). Finding the right signature needs evaluation of the right (usually first, but not necessarily) argument, which may actually involve another function call. Inheritance makes things more complicated. I'm not sure it's worth the overhead. -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] more special completions
On 8/21/09, Romain Francois wrote: > On 08/21/2009 06:59 PM, Deepayan Sarkar wrote: > > > > > On 8/21/09, Romain Francois > wrote: > > > > > Hi, > > > > > > Would it be possible to add the capability for functions to register > how > > > they would like to complete themselves. > > > > > > Currently, there is the .addFunctionInfo, but it allows only functions > to > > > register a static list of potential completions, I was thinking of a way > to > > > register not a fixed list of possible completions, but a __function__ > that > > > would calculate completions dynamically. > > > > > > This could be useful for the "new" function in R, if associated with > > > something that can retrieve the current list of S4 classes (not sure > this > > > exists). > > > > > > Another example of where this could be used would be the .jnew function > > > from rJava, where the first argument is a java class, associated with > > > something that can complete java class names. > > > > > > > That should be useful (library, data, etc. are already hard-coded to > > do special completion, but there is no reason for them to be special). > > I'll have to think about how best to implement this. > > > > I should have time to work in this in a couple of weeks (I also hope > > to tackle your earlier request on $ completion then). > > > > -Deepayan > > > > Great. > > I guess there are a few challenges, currently library, etc ... only use the > special completion feature for their first argument. > > it might make sense to expand on this, for example the data argument of a > lattice call might be interested in the list of available data frames ... Yes, I'll have to think about it to decide if that's at all feasible (there are some limitations imposed by backends; readline, ESS, and the Windows Rgui all do slightly different things). > Let me know if I can be of help when you tackle this. Will do. -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Lattice: Drawing a single contour line with a negative value fails
On 8/19/09, Thorn Thaler wrote:
> Hi everybody,
>
> I want to add a single contourline to a levelplot. While everything works
> fine if the value at which the line should be drawn is positive, there is an
> error if the value is negative:
>
> library(lattice)
> my.panel <- function(..., at, contour=FALSE, labels=NULL) {
>panel.levelplot(..., at=at, contour=contour, labels=labels)
>panel.contourplot(..., contour=TRUE, labels="Contour", lwd=2,
> at=con)
> }
>
> x <- y <- 1:100
> df <- expand.grid(x=x, y=y)
> df$z <- apply(df, 1, function(x)
>(x[1]^2+x[2]^2)*ifelse(x[1]^2+x[2]^2 < 5000, -1,1))
> col.regions <- heat.colors(50)
>
> # Works
> con <- 1000
> levelplot(df$z~df$x+df$y, col.regions=col.regions, panel=my.panel)
>
> # Does not work
> con <- -1000
> levelplot(df$z~df$x+df$y, col.regions=col.regions, panel=my.panel)
>
> I've tracked down the error to the function "cut.default", which takes an
> argument "breaks", which should be "either a numeric vector of two or more
> cut points or a single number (greater than or equal to 2) giving the number
> of intervals into which 'x' is to be cut."
>
> So it seems to me that a single contourline at a positive value works
> because the value is interpreted as the number of intervals, even though
> there is just this single line in the resulting plot.
>
> What would be the correct way to add just a single contour line to a
> levelplot, or is it indeed a bug?
Definitely a bug. It should be easy to fix (but I haven't had time to
get to it yet).
Using something like
con <- c(-1000, NA)
seems to work though.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Improved Function Information with Key
On Wed, Oct 7, 2009 at 5:56 AM, Lee Kelvin wrote:
> Hello,
>
> Pressing the key when typing a function into an R terminal does not
> produce the expected output. Currently, R will order all of the available
> function inputs into alphabetical order and present them as options, whereas
> it should display the inputs in the order they appear in the function.
>
> For example:
>
>> test = function(b,a,c){
> print(b)
> a*c
> }
>
>> test(
> a= b= c=
>
> where indicates pressing the Tab key.
>
> It's easy to see that if the function were designed to accept 'b' as a
> string, and 'a' and 'c' as numerics that this function would fail if the
> user made the assumption that the output is in the correct order, and
> input 'a' as a string.
>
> This is a simple example, however I have several functions that I use often
> and each has many possible inputs. It would be useful to not have to
> remember the order the inputs are in for each function, or have to use
> args(function) beforehand. It is also on occasion useful not to have to
> explicitly name each input in your function.
>
> Im using Ubuntu Linux 9.04 and a standard install of R 2.9.2 (unfortunately
> not the polished R.app available on Macs - which coincidentally do display
> function inputs in the correct order).
>
> I welcome any thoughts, disagreements or tips any of you may have,
The sorting is a feature of the readline library that is used as the
backend (there is no sorting on the Windows GUI). Apparently readline
6 allows you to inhibit sorting, so that might turn out to be useful.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Improved Function Information with Key
On Thu, Oct 8, 2009 at 5:33 AM, Lee Kelvin wrote:
> Thanks for the responses,
>
> Im not familiar with the development of readline 6, is it possible to test
> this functionality now, or will this be included in a future standard
> release of R?
I don't think it's possible to test it now (but I can't say for sure
as I don't have readline 6 installed and haven't read the
documentation carefully). In theory, some future release should
include a check for readline>=6 and disable sorting, but I'm not sure
when or if that will happen in practice.
> Also, it was suggested that Emacs and the ESS package may be of use. Im not
> overly familiar with emacs, but I will give it a go.
As far as I can tell, Emacs' completion system also sorts, and I don't
see a way to inhibit that. ESS does show you the results of args()
when you type an open paren after a function name, which should be
useful for you.
-Deepayan
>
> Thanks,
> Lee Kelvin
>
>
> 2009/10/8 Deepayan Sarkar
>>
>> On Wed, Oct 7, 2009 at 5:56 AM, Lee Kelvin wrote:
>> > Hello,
>> >
>> > Pressing the key when typing a function into an R terminal does
>> > not
>> > produce the expected output. Currently, R will order all of the
>> > available
>> > function inputs into alphabetical order and present them as options,
>> > whereas
>> > it should display the inputs in the order they appear in the function.
>> >
>> > For example:
>> >
>> >> test = function(b,a,c){
>> > print(b)
>> > a*c
>> > }
>> >
>> >> test(
>> > a= b= c=
>> >
>> > where indicates pressing the Tab key.
>> >
>> > It's easy to see that if the function were designed to accept 'b' as a
>> > string, and 'a' and 'c' as numerics that this function would fail if the
>> > user made the assumption that the output is in the correct order,
>> > and
>> > input 'a' as a string.
>> >
>> > This is a simple example, however I have several functions that I use
>> > often
>> > and each has many possible inputs. It would be useful to not have to
>> > remember the order the inputs are in for each function, or have to use
>> > args(function) beforehand. It is also on occasion useful not to have to
>> > explicitly name each input in your function.
>> >
>> > Im using Ubuntu Linux 9.04 and a standard install of R 2.9.2
>> > (unfortunately
>> > not the polished R.app available on Macs - which coincidentally do
>> > display
>> > function inputs in the correct order).
>> >
>> > I welcome any thoughts, disagreements or tips any of you may have,
>>
>> The sorting is a feature of the readline library that is used as the
>> backend (there is no sorting on the Windows GUI). Apparently readline
>> 6 allows you to inhibit sorting, so that might turn out to be useful.
>>
>> -Deepayan
>
>
>
> --
> Lee Kelvin
>
> lee.s.kel...@gmail.com
> 07765431721
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Windows installer, HTML help, R 2.10.0
On Tue, Nov 10, 2009 at 10:35 AM, Oliver Soong wrote: > I'm not 100% sure this hasn't been covered already (I searched a bit, > but I had a little trouble filtering down to a useful number of useful > results). It has, see http://old.nabble.com/Cannot-activate-chm-help-in-R-2.10-td26067423.html -Deepayan > Anyway, when I install R on Windows, the installer asks to > set the default help type. For some reason, I can set it as HTML in > the installer, but the results open as if help_type = "text" by > default. I presume this is related to the new changes to the help. > Calling help(help, help_type = "html") works as expected, so the HTML > help works and I could manually fix this by setting options(help_type > = "html") in a session or in my .Rprofile. > > I'm not sure if I'm the only one seeing this, but for what it's worth, > I also set SDI and Internet = Standard. I haven't experimented with > different installation settings to see which ones work. > > Oliver > > __ > 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] Indexing bug?
On Wed, May 26, 2010 at 3:27 PM, Duncan Murdoch
wrote:
> Is this expected behaviour?
>
> x <- factor(c("c", "b", "a","c"))
> results <- c(c=4, b=5)
> results[x]
>
> giving
>
>> results[x]
> b c
> NA 5 4 NA
>
> (i.e. it appears to give results[levels(x)]
I would say it gives
results[as.numeric(x)]
and it's not clear if that is less "expected". E.g., what happens if
results has no names? results[as.numeric(x)] would still work, but not
results[as.character(x)].
Factors have a dual nature (character labels vs numeric codes), and
when forced to choose, I think it's reasonable to choose the solution
which works more generally.
-Deepayan
>
>
> whereas results[as.character(x)] does what I expected:
>
> as.character(x)
> results[as.character(x)]
>
>> as.character(x)
> [1] "c" "b" "a" "c"
>> results[as.character(x)]
> c b c
> 4 5 NA 4
>
> Duncan Murdoch
>
> __
> 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] S4 dispatch for .DollarNames (utils)
On Sat, May 29, 2010 at 4:21 AM, Romain Francois
wrote:
> Hello,
>
> I'm trying to make .DollarNames generic and implement a method for it in a
> package. .DollarNames is the function that is now called to get completion
> possibilities.
>
> My R code looks like this:
>
> setGeneric( ".DollarNames" )
>
> setClass("track",
> representation(x="numeric", y="numeric"))
> ## A class extending the previous, adding one more slot
> setClass("trackCurve",
> representation(smooth = "numeric"),
> contains = "track")
>
> setMethod( ".DollarNames", signature( x = "track", pattern = "character" ),
> function(x, pattern){
> grep( pattern, c("foo", "bar"), value = TRUE )
> } )
>
>
> and the NAMESPACE :
>
> import( utils )
> exportMethods( .DollarNames )
> exportClasses( track, trackCurve )
>
>
> When I load the package, I can call .DollarNames explicitely :
>
>> require( foo )
>> x <- new( "trackCurve", x = 1:10, y = 1:10, smooth = 1:10 )
>> .DollarNames( x, "f" )
> [1] "foo"
>
> but completion does not work :
>
>> x$f
> x$
I guess because
> utils:::.DollarNames(x, "f")
character(0)
so the S4 generic is not being seen within the utils namespace. I
don't know what the right fix is...
-Deepayan
> What do I miss ?
>
> I've uploaded foo here : http://addictedtor.free.fr/misc/rcpp/foo_1.0.tar.gz
>
> Romain
>
>
> --
> Romain Francois
> Professional R Enthusiast
> +33(0) 6 28 91 30 30
> http://romainfrancois.blog.free.fr
> |- http://bit.ly/9CQ66r : RMetrics 2010
> |- http://bit.ly/cork4b : highlight 0.1-8
> `- http://bit.ly/bklUXt : RcppArmadillo 0.2.1
>
>
> __
> 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] Argument recycling in substring()
2010/6/4 Martin Maechler :
>> "HP" == Hervé Pagès
>> on Thu, 03 Jun 2010 17:53:33 -0700 writes:
>
> HP> Hi,
> HP> According to its man page substring() "expands (its) arguments
> HP> cyclically to the length of the longest _provided_ none are of
> HP> zero length".
>
> HP> So, as expected, I get an error here:
>
> >> substring("abcd", first=2L, last=integer(0))
> HP> Error in substring("abcd", first = 2L, last = integer(0)) :
> HP> invalid substring argument(s)
>
> HP> But I don't get one here:
>
> >> substring(character(0), first=1:2, last=3L)
> HP> character(0)
>
> HP> which is unexpected.
> according to the docu.
>
> My gut feeling would say that the documentation should be
> updated in this case, rather than the implementation.
>
> RFC! other opinions?
I agree. The current behaviour is reasonable.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cut takes long time
On Wed, Jun 16, 2010 at 3:56 PM, Gabor Grothendieck
wrote:
> The following cut command takes nearly 10 seconds on my machine even
> though the length of input vector is only 6. I am running on Windows
> Vista with C2D BLAS using R 2.11.1. Using the default BLAS and either
> R 2.10.1 or "R version 2.12.0 Under development (unstable) (2010-05-31
> r52164)" also gives me results in the 9-11 second range.
> I would have expected it to take much less time.
>
>
> tt <- structure(c(631206000, 631206060, 631206180, 631206240, 631206300,
> 978224400), class = c("POSIXt", "POSIXct"), tzone = "")
>
> system.time(cut(tt, "2 hours", include = TRUE)) # 9.45 0.01 9.58
The POSIXt aspect is not relevant to this, it's the number of breakpoints.
> system.time(cut(tt, "2 hours", include = TRUE))
user system elapsed
5.884 0.108 6.033
> system.time(cut(rnorm(6), breaks = 5))
user system elapsed
5.200 0.000 5.558
And the time seems linear in the number of breakpoints, which is not
surprising. The "Note" section in ?cut does mention more efficient
alternatives.
Note that
> system.time(cut(tt, "2 hours", include = TRUE, labels = FALSE))
user system elapsed
0.020.000.02
so it's the conversion to factors that seems to take most of the time.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] error in lattice formattedTicksAndLabels.Date (PR#9590)
On 3/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Full_Name: James Szinger
> Version: 2.4.1
> OS: linux and MacOS X
> Submission from: (NULL) (128.165.24.206)
Bugs in packages are supposed to go to package maintainers, not r-bugs.
> I'm trying to plot some data from the past 12 months and the lattice package
> is
> not labeling the time axis correctly. It shows only two labels instead of the
> expected 12. The base graphics get it right.
>
> I think the problem is the commented-out line in formattedTicksAndLabels.Date
> in
> lattice's axis.R:
> ## z <- c(range, x[is.finite(x)])
Why do you think so? This has nothing to do with it.
> The following example demonstrates the problem:
>
> require(lattice) #lattice_0.14-16
>
> x <- rnorm(12)
> t <- seq( as.Date("2006-04-01"),by="month", length=12)
>
> plot(x~t) # Has labels "May", "Jul", "Sep", "Nov", Jan", "Mar"
> xyplot(x~t)# Has labels "Jan", "Mar"
The problem is in the nuances of the algorithm used. You can trigger
the same behavior with base graphics by mimicking what's happening
internally in lattice:
> tt = lattice:::extend.limits(range(t))
> tt
[1] "2006-03-08" "2007-03-24"
> plot(range(x) ~ tt, xaxs = "i")
There is a fundamental difference in how base and lattice handle axis
annotation. In particular, base uses all the data to determine tick
positions, while lattice uses only the range. This is hard to change
given how lattice comes up with a common range combining different
panels. It might still be possible to get around this, but don't
expect a quick solution.
(You can of course specify tick positions explicitly using 'scales')
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R callbacks
Hi,
I'm trying to understand (mostly from the R-exts manual) how to use
the callbacks declared in Rinterface.h. As a first attempt, I'm trying
to redefine ptr_R_WriteConsole in a very trivial manner. Here's my
code:
---
$ cat altr.c
int Rf_initialize_R(int ac, char **av);
#define R_INTERFACE_PTRS 1
#include
extern int R_running_as_main_program;
static void my_R_WriteConsole(char *buf, int len)
{
printf("R<< %s", buf);
}
int main(int ac, char **av)
{
R_running_as_main_program = 1;
ptr_R_WriteConsole = my_R_WriteConsole;
Rf_initialize_R(ac, av);
Rf_mainloop();
return 0;
}
---
I compile and run this in bash with
RPROG=R
INC=`${RPROG} CMD config --cppflags`
LDF=`${RPROG} CMD config --ldflags`
export LD_LIBRARY_PATH=`${RPROG} RHOME`/lib
gcc -o altr ${INC} ${LDF} altr.c
${RPROG} CMD ./altr
However, my customized version seems not to be used. What am I missing?
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R callbacks
On 4/3/07, Simon Urbanek <[EMAIL PROTECTED]> wrote:
> On Apr 2, 2007, at 8:51 PM, Deepayan Sarkar wrote:
>
> > Hi,
> >
> > I'm trying to understand (mostly from the R-exts manual) how to use
> > the callbacks declared in Rinterface.h. As a first attempt, I'm trying
> > to redefine ptr_R_WriteConsole in a very trivial manner. Here's my
> > code:
> >
> > ---
> > $ cat altr.c
> >
> > int Rf_initialize_R(int ac, char **av);
> >
> > #define R_INTERFACE_PTRS 1
> > #include
> >
> > extern int R_running_as_main_program;
> >
> > static void my_R_WriteConsole(char *buf, int len)
> > {
> > printf("R<< %s", buf);
> > }
> >
> > int main(int ac, char **av)
> > {
> > R_running_as_main_program = 1;
> > ptr_R_WriteConsole = my_R_WriteConsole;
> > Rf_initialize_R(ac, av);
> > Rf_mainloop();
> > return 0;
> > }
> > ---
> >
> > I compile and run this in bash with
> >
> >
> > RPROG=R
> >
> > INC=`${RPROG} CMD config --cppflags`
> > LDF=`${RPROG} CMD config --ldflags`
> > export LD_LIBRARY_PATH=`${RPROG} RHOME`/lib
> > gcc -o altr ${INC} ${LDF} altr.c
> >
> > ${RPROG} CMD ./altr
> >
> > However, my customized version seems not to be used. What am I
> > missing?
> >
>
> 1) see Byron's e-mail
> 2) by default R uses stdout/err connections instead of the console
> API, you need to disable that
>
> so the resulting code should look like this:
>
> Rf_initialize_R(ac, av);
> ptr_R_WriteConsole = my_R_WriteConsole;
> R_Outputfile = NULL;
> R_Consolefile = NULL;
> Rf_mainloop();
Thanks, setting things to NULL was the critical piece (I had tried
Byron's suggestion myself). A note mentioning this in R-exts would be
helpful.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Forge?
On 4/6/07, hadley wickham <[EMAIL PROTECTED]> wrote:
> On 4/6/07, Stefan Theussl <[EMAIL PROTECTED]> wrote:
> > hadley wickham wrote:
> > >> > I have recently found RForge.net (http://www.rforge.net/) by Simon
> > >> > Urbanek and found out today that the site is accepting subscriptions.
> > >> > Great! However, browsing a bit on the site I found a link to another
> > >> > forge: R-Forge (http://r-forge.r-project.org/).
> > >> >
> > >> > Is/will the last one be the "offcial" forge for R packages, given that
> > >> > it has domain r-project.org?
> > >>
> > >> Yes, we're currently still testing the functionality and improving the
> > >> documentation, but an article for R News that announces the
> > >> functionality
> > >> is under preparation. There is already a user's manual available on the
> > >> main page which explains how you can register and set up your project
> > >> etc.
> > >> Just as Simon's site this already offers an SVN and nightly builds in a
> > >> CRAN-style repository, and additionally there is the whole GForge system
> > >> with other features such as project forums, mailing lists etc.
> > >
> > > Is it possible to use r-forge just for the nightly builds? (ie. with
> > > svn hosted elsewhere) That would be really handy.
> > >
> > > Hadley
> > We have never thought about it, but this would be technically difficult.
> >
> > But you may migrate your svn (or the part which contains the package) to
> > R-Forge and have the advantage of daily build and checked packages with
> > the possibility to install it directly from R-Forge:
> > |install.packages("/packagename/",repos="http://r-forge.r-project.org";)|
>
> I guess I'm not really comfortable moving my code to an external
> repository completely out of my control. It would be really
> convenient to be able to upload a source package, and have it built,
> with out R CMD check being enforced.
If you are comfortable with mirroring, I recently discovered the
svnsync tool (new in subversion 1.4). It will mirror a subversion
repository in its entirety (including commit history). It requires a
hook script to be present in the target repository (so needs
cooperation from the admin), but otherwise, once you set it up, a one
line cron job will synchronize it.
A quick description is available here:
http://code.google.com/support/bin/answer.py?answer=56682&topic=10386
and the subversion book has more detail.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] corrections to R-exts
Hi,
a couple of minor fixes to R-exts.texi:
In
@subsection Setting R callbacks
which describes Rinterface.h,
The @example block correctly has
extern int (*ptr_R_ReadConsole)(char *, unsigned char *, int, int);
extern int (*ptr_R_ShowFiles)(int, char **, char **, char *,
Rboolean, char *);
Just below that, these are described incorrectly as:
deftypefun int R_ReadConsole (char [EMAIL PROTECTED], char [EMAIL PROTECTED], @
int @var{buflen}, int @var{hist})
(missing 'unsigned')
@deftypefun void R_ShowFiles (int @var{nfile}, char [EMAIL PROTECTED], [...]
(return type 'void' instead of 'int')
Also, the paragraph on R_ReadConsole ends with:
"The return value is 0 on success and >0 on failure."
This is wrong.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] wishlist: additional argument in R_tryEval (Rinternals.h)
Hi,
R_tryEval, exported in Rinternals.h but not part of the API, is
currently defined as:
R_tryEval(SEXP e, SEXP env, int *ErrorOccurred);
I'm trying to embed R in an application (basically yet another GUI),
and this has been very helpful to catch errors. It would be even more
helpful if it also gave access to the visibility flag. I can wrap this
in a call to withVisible, and that works great, but if there is an
error, traceback() contains a bunch of irrelevant levels.
It seems fairly easy to add another argument, similar to
ErrorOccurred, that is set to the visibility flag before returning. Is
this something that could be considered for addition in R-devel? A
possible patch for R/trunk is attached. Mac-GUI/REngine/REngine.m will
also need a patch, but I don't understand the language it's written
in.
-Deepayan
Index: src/include/Rinternals.h
===
--- src/include/Rinternals.h (revision 41080)
+++ src/include/Rinternals.h (working copy)
@@ -616,7 +616,7 @@
void R_ProtectWithIndex(SEXP, PROTECT_INDEX *);
void R_Reprotect(SEXP, PROTECT_INDEX);
-SEXP R_tryEval(SEXP, SEXP, int *);
+SEXP R_tryEval(SEXP, SEXP, int *, int *);
/* return(.) NOT reached : for -Wall */
#define error_return(msg) { Rf_error(msg); return R_NilValue; }
Index: src/library/methods/src/methods_list_dispatch.c
===
--- src/library/methods/src/methods_list_dispatch.c (revision 41080)
+++ src/library/methods/src/methods_list_dispatch.c (working copy)
@@ -299,7 +299,7 @@
val = CDR(val);
SETCAR(val, f_env);
}
-val = R_tryEval(e, Methods_Namespace, &check_err);
+val = R_tryEval(e, Methods_Namespace, &check_err, NULL);
if(check_err)
error(_("S language method selection got an error when called from internal dispatch for function '%s'"),
check_symbol_or_string(fname, TRUE,
@@ -540,7 +540,7 @@
else {
/* get its class */
SEXP arg, class_obj; int check_err;
- PROTECT(arg = R_tryEval(arg_sym, ev, &check_err)); nprotect++;
+ PROTECT(arg = R_tryEval(arg_sym, ev, &check_err, NULL)); nprotect++;
if(check_err)
error(_("error in evaluating the argument '%s' in selecting a method for function '%s'"),
CHAR(PRINTNAME(arg_sym)),CHAR(asChar(fname)));
@@ -551,7 +551,7 @@
else {
/* the arg contains the class as a string */
SEXP arg; int check_err;
- PROTECT(arg = R_tryEval(arg_sym, ev, &check_err)); nprotect++;
+ PROTECT(arg = R_tryEval(arg_sym, ev, &check_err, NULL)); nprotect++;
if(check_err)
error(_("error in evaluating the argument '%s' in selecting a method for function '%s'"),
CHAR(PRINTNAME(arg_sym)),CHAR(asChar(fname)));
@@ -636,7 +636,7 @@
args = CDR(args);
}
if(prim_case) {
- val = R_tryEval(e, ev, &error_flag);
+ val = R_tryEval(e, ev, &error_flag, NULL);
/* reset the methods: R_NilValue for the mlist argument
leaves the previous function, methods list unchanged */
do_set_prim_method(op, "set", R_NilValue, R_NilValue);
@@ -833,7 +833,7 @@
else {
/* get its class */
SEXP arg; int check_err;
- PROTECT(arg = R_tryEval(arg_sym, ev, &check_err));
+ PROTECT(arg = R_tryEval(arg_sym, ev, &check_err, NULL));
if(check_err)
error(_("error in evaluating the argument '%s' in selecting a method for function '%s'"),
CHAR(PRINTNAME(arg_sym)),CHAR(asChar(fname)));
Index: src/main/main.c
===
--- src/main/main.c (revision 41080)
+++ src/main/main.c (working copy)
@@ -1434,7 +1434,7 @@
SETCAR(cur, VECTOR_ELT(f, 1));
}
-val = R_tryEval(e, NULL, &errorOccurred);
+val = R_tryEval(e, NULL, &errorOccurred, NULL);
if(!errorOccurred) {
PROTECT(val);
if(TYPEOF(val) != LGLSXP) {
Index: src/main/context.c
===
--- src/main/context.c (revision 41080)
+++ src/main/context.c (working copy)
@@ -636,7 +636,7 @@
}
SEXP
-R_tryEval(SEXP e, SEXP env, int *ErrorOccurred)
+R_tryEval(SEXP e, SEXP env, int *ErrorOccurred, int *IsVisible)
{
Rboolean ok;
ProtectedEvalData data;
@@ -649,6 +649,9 @@
if (ErrorOccurred) {
*ErrorOccurred = (ok == FALSE);
}
+if (IsVisible) {
+*IsVisible = (int) R_Visible;
+}
if (ok == FALSE)
data.val = NULL;
else
Index: src/gnuwin32/front-ends/rproxy_impl.c
===
--- src/gnuwin32/front-ends/rproxy_impl.c (revision 41080)
+++ src/gnuwin32/front-ends/rproxy_impl.c (working copy)
@@ -305,7 +305,7 @@
switch (lStatus) {
case PARSE_OK:
PROTECT(lSexp);
- lResult = R_tryEval(VECTOR_ELT(lSexp, 0), R_GlobalEnv, &evalError);
+ lResult = R_tryEval(VECTOR_ELT(lSexp, 0), R_GlobalEnv, &evalError, NULL);
UNPROTECT(1);
if(evalError) lRc = SC_PROXY_ERR_EVALUATE_STOP;
else lRc = SEXP2BDX(lResult, pData
Re: [Rd] wishlist: additional argument in R_tryEval (Rinternals.h)
On 4/6/07, Byron Ellis <[EMAIL PROTECTED]> wrote: > It's come up for me when I do FFI stuff. For GUI stuff I usually just > want to suppress, but it's possible that you'd want to detect > visibility if you were to make the GUI more programmable. I usually > end up having to work around the whole business by fiddling with > R_Visible. My GUI is basically a wrapper around R (it's an exercise in teaching myself Qt), so replicating console functionality is a major goal. R is embedded and not the main thread, mostly because I didn't read R-exts carefully enough before starting. But most things have gone fairly smoothly, and I want to see how far I can go. > Speaking of R_tryEval, can someone with the appropriate powers PRETTY > PLEASE just make it an official API? Having it continue to be > unofficial is just getting silly. > > > On 4/6/07, Luke Tierney <[EMAIL PROTECTED]> wrote: > > Even though it isn't officially part of the API it has seen some use > > so I'd prefer not to change the interface; instead add > > > > SEXP R_tryEvalWithVis(SEXP e, SEXP env, int *ErrorOccurred, int *visible); > > > > or something along those lines and define R_tryEval internally in > > terms of that. > > > > It may be worth thinking a bit more though to see if there is > > something else that might be useful at this point. I vaguely recall > > thinking recently about needing something else of this flavor but I > > can't seem to remember what it was exactly -- will try to see if I can > > recall. OK, I'll stick with withVisible for now, and wait for something like R_tryEvalWithVis. -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] small update required in R-lang
The R-lang manual has this example which no longer holds (I couldn't
think of a simple alternative):
As it happens, @R{}'s parser is not perfectly invertible, nor is its
deparser, as the following examples show
@example
> deparse(quote(c(1, 2)))
[1] "c(1, 2)"
> deparse(1:2)
[1] "c(1, 2)"
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rf_PrintValue problem with methods::show
Hi,
I think this is a bug (even though I can't find documentation
explicitly saying that it should work). Basically, Rf_PrintValue(obj)
fails when 'obj' is an S4 object that should be printed using show()
rather than print(). From the error message I'm guessing that the need
to use show is detected correctly but then show is not found.
"cbind2" in the code below is just a representative object, the same
holds for the few other S4 objects I have tried.
The following uses r-devel on i686-pc-linux-gnu, but the results are
same with R 2.4.1 (with suitable changes to the R_ParseVector call).
On powerpc Linux I get a segfault.
$ RPROG=R-devel
$ ${RPROG} --version | head -1
R version 2.6.0 Under development (unstable) (2007-04-06 r41080)
$ export LD_LIBRARY_PATH=`${RPROG} RHOME`/lib
$ cat parseEvalS4.c
#include
#include
#include
int main(int argc, char *argv[])
{
SEXP e, val;
int i, errorOccurred;
ParseStatus status;
char *cmds[] = { "show(5)", "show(cbind2)", "cbind2" };
argv[0] = "R";
Rf_initEmbeddedR(argc, argv);
for (i = 0; i < 3; i++) {
printf("** I **: Executing command: %s\n", cmds[i]);
PROTECT(e = R_ParseVector(mkString(cmds[i]), -1, &status, R_NilValue));
val = eval(VECTOR_ELT(e, 0), R_GlobalEnv);
printf("** I **: Evaluation succeeded, now printing using
Rf_PrintValue:\n");
Rf_PrintValue(val);
UNPROTECT(1);
}
Rf_endEmbeddedR(0);
return 0;
}
$
$ gcc -o parseEvalS4 \
>`${RPROG} CMD config --cppflags` \
>`${RPROG} CMD config --ldflags` parseEvalS4.c
$
$ ${RPROG} CMD ./parseEvalS4 --vanilla --silent
** I **: Executing command: show(5)
[1] 5
** I **: Evaluation succeeded, now printing using Rf_PrintValue:
[1] 5
** I **: Executing command: show(cbind2)
standardGeneric for "cbind2" defined from package "methods"
function (x, y)
standardGeneric("cbind2")
Methods may be defined for arguments: x, y
** I **: Evaluation succeeded, now printing using Rf_PrintValue:
NULL
** I **: Executing command: cbind2
** I **: Evaluation succeeded, now printing using Rf_PrintValue:
Error: could not find function "show"
Error: unprotect(): only 0 protected items
$
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] help with Qt and event loops
Hi, I have been playing with Qt recently, and have the beginnings of a Qt device. Unfortunately, I haven't been able to make it work as an R package yet (I know the device code works because I can use it from a GUI where R is embedded). Trying to package it, I have managed to get it to a stage where typing > library(qtdevice) > QT() will open up a new window, but then control doesn't return to R, so nothing useful can be done. Right now, I have no idea how to proceed. Would someone with enough experience with event loops (preferably in both R and Qt) be willing to look into this? The source code and a brief write-up is available here: http://dsarkar.fhcrc.org/R/R-Qt.html Thanks, -Deepayan __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] help with Qt and event loops
On 4/13/07, Duncan Temple Lang <[EMAIL PROTECTED]> wrote: > Hi Deepayan. > > I can take a look, but it may not be for a few days. No problem. > But if anyone else has the time, can you keep us informed > about any progress so that we don't replicate work in parallel. Sure. -Deepayan __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rinterface.h on Windows
Hi, it looks like Rinterface.h is not available on Windows. Does this mean I can not reset the various ptr_R_* callbacks? Is there an alternative? Is this something fundamentally difficult or something not done because no one needs it? -Deepayan __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rinterface.h on Windows
On 4/13/07, Deepayan Sarkar <[EMAIL PROTECTED]> wrote: > Hi, > > it looks like Rinterface.h is not available on Windows. Does this mean > I can not reset the various ptr_R_* callbacks? Is there an > alternative? Is this something fundamentally difficult or something > not done because no one needs it? For the record, I would really like it if this worked on Windows, because my Qt GUI seems to be working fine if I comment out these callbacks (except that nothing gets printed on the console). -Deepayan __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rinterface.h on Windows
On 4/13/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > On Fri, 13 Apr 2007, Deepayan Sarkar wrote: > > > Hi, > > > > it looks like Rinterface.h is not available on Windows. Does this mean > > I can not reset the various ptr_R_* callbacks? Is there an > > alternative? Is this something fundamentally difficult or something > > not done because no one needs it? > > To my knowledge no one has asked for it, so I assume the latter. > At a glance, it does not look too difficult, as similar things are going > on in src/gnuwin32/system.c. Hmm, so I guess the good long term strategy would be to convert that to using the Rinterface.h API. I'll take a look some day when I'm feeling more adventurous. -Deepayan __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] dendrogram definition
Hi, I'm trying to create a "grob" representing a dendrogram object (for use as a legend with lattice), and I have a question regarding how a "dendrogram" should be interpreted. Are they by definition binary trees or can they in principle have more than two children? -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dendrogram definition
On 4/23/07, Friedrich Leisch <[EMAIL PROTECTED]> wrote: > >>>>> On Fri, 20 Apr 2007 14:46:33 -0700, > >>>>> Deepayan Sarkar (DS) wrote: > > > Hi, > > I'm trying to create a "grob" representing a dendrogram object (for > > use as a legend with lattice), and I have a question regarding how a > > "dendrogram" should be interpreted. Are they by definition binary > > trees or can they in principle have more than two children? > > They can have more than 2 children, and class "dendrogram" supports > this. However, as most trees are currently created using hclust, all > examples have binary trees. Thanks, that's what my guess was since the help page doesn't say anything special about binary trees. My code should work in either case. In case anyone's interested, there's an example of a lattice/grid heatmap at http://dsarkar.fhcrc.org/R/heatmap/lattice-heatmap.pdf (the primary benefit for me is better control over aspect ratio). -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] evaluation in unattached namespace
Hi,
I recently discovered this buglet in lattice: If lattice is _not_
attached, I get
> lattice::dotplot(~1:10)
Error in eval(expr, envir, enclos) : could not find function "bwplot"
This happens because of this:
> lattice:::dotplot.formula
function (x, data = NULL, panel = "panel.dotplot", ...)
{
ocall <- ccall <- match.call()
ccall$data <- data
ccall$panel <- panel
ccall[[1]] <- as.name("bwplot")
ans <- eval.parent(ccall)
ans$call <- ocall
ans
}
That is, ccall is eval()-ed in the global environment where bwplot is
not visible. While this example is somewhat silly, similar things
happen when I try to import lattice from another package.
Are there any simple alternatives? I tried
ccall[[1]] <- as.name("lattice::bwplot")
but that didn't work either.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] evaluation in unattached namespace
On 4/26/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> On 4/26/2007 7:39 PM, Deepayan Sarkar wrote:
> > Hi,
> >
> > I recently discovered this buglet in lattice: If lattice is _not_
> > attached, I get
> >
> >> lattice::dotplot(~1:10)
> > Error in eval(expr, envir, enclos) : could not find function "bwplot"
> >
> > This happens because of this:
> >
> >> lattice:::dotplot.formula
> > function (x, data = NULL, panel = "panel.dotplot", ...)
> > {
> > ocall <- ccall <- match.call()
> > ccall$data <- data
> > ccall$panel <- panel
> > ccall[[1]] <- as.name("bwplot")
> > ans <- eval.parent(ccall)
> > ans$call <- ocall
> > ans
> > }
> >
> >
> > That is, ccall is eval()-ed in the global environment where bwplot is
> > not visible. While this example is somewhat silly, similar things
> > happen when I try to import lattice from another package.
> >
> > Are there any simple alternatives? I tried
> >
> > ccall[[1]] <- as.name("lattice::bwplot")
Seth suggested
ccall[[1]] <- quote(lattice::bwplot)
which makes more sense and seems to work too.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Qt device update
Hi,
a few days back I had asked for help on a Qt device package. Thanks to
hints from Duncan TL and Thomas Friedrichsmeier, I now have something
more or less functional. For those interested, It can be downloaded
from
http://dsarkar.fhcrc.org/R/R-Qt.html
I have a couple of related questions. First, dev.interactive(), used
in example() and many demo()-s to decide if the current device is
interactive, is currently implemented as:
> dev.interactive
function (orNone = FALSE)
{
iDevs <- c("X11", "GTK", "gnome", "quartz", "windows", "JavaGD")
interactive() && (.Device %in% iDevs || (orNone && .Device ==
"null device" && getOption("device") %in% iDevs))
}
This makes it impossible for new devices to be treated as interactive.
Perhaps it would be better to change this to something like
iDevs <- c("X11", "GTK", "gnome", "quartz", "windows", "JavaGD",
getOption("interactive.devices"))
so that packages can set an option to be included in this list.
Second, can someone explain the details of what happens when a symbol
font is requested (with font=5 or with plotmath stuff)? demo(plotmath)
seems to work on a machine with LANG=en_US (I don't know what encoding
this means, probably latin1), but some symbols don't work on my
desktop which has en_US.UTF-8. Presumably, this means I have to
interpret the encoding differently, but what exactly is the rule? Is
it enough to treat it as latin1? Some devices have a lot of code
dealing with encodings, and I want to make sure I understand the
issues before I go off on a wild goose chase.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Qt device update
On 5/3/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> On Thu, 3 May 2007, Deepayan Sarkar wrote:
>
> > Hi,
> >
> > a few days back I had asked for help on a Qt device package. Thanks to
> > hints from Duncan TL and Thomas Friedrichsmeier, I now have something
> > more or less functional. For those interested, It can be downloaded
> > from
> >
> > http://dsarkar.fhcrc.org/R/R-Qt.html
> >
> > I have a couple of related questions. First, dev.interactive(), used
> > in example() and many demo()-s to decide if the current device is
> > interactive, is currently implemented as:
> >
> >> dev.interactive
> > function (orNone = FALSE)
> > {
> >iDevs <- c("X11", "GTK", "gnome", "quartz", "windows", "JavaGD")
> >interactive() && (.Device %in% iDevs || (orNone && .Device ==
> >"null device" && getOption("device") %in% iDevs))
> > }
> >
> > This makes it impossible for new devices to be treated as interactive.
> > Perhaps it would be better to change this to something like
> >
> >iDevs <- c("X11", "GTK", "gnome", "quartz", "windows", "JavaGD",
> > getOption("interactive.devices"))
> >
> > so that packages can set an option to be included in this list.
>
> That would work differently from any existing option, adding to the list.
> But it would make sense for package grDevices to have a function to
> request being added to the list.
>
> (If the device is already running we could use
> grDevices:::dev.displaylist() to ask if this looked like a screen device.)
I will be happy with anything that works. Given Simon's comments, it
looks like this might be non-trivial, so a short term solution could
be to add a ask= argument to demo() (like example() already has) and
remove the explicit overrides in the standard demos.
> > Second, can someone explain the details of what happens when a symbol
> > font is requested (with font=5 or with plotmath stuff)? demo(plotmath)
> > seems to work on a machine with LANG=en_US (I don't know what encoding
> > this means, probably latin1),
>
> If a Linux machine, yes, it is shorthand for en_US.iso88591.
> It could also mean ASCII and according to the standards (XPG?) probably
> should.
>
> > but some symbols don't work on my desktop which has en_US.UTF-8.
> > Presumably, this means I have to interpret the encoding differently, but
> > what exactly is the rule? Is it enough to treat it as latin1? Some
> > devices have a lot of code dealing with encodings, and I want to make
> > sure I understand the issues before I go off on a wild goose chase.
>
> The symbol font is regarded as being in Adobe Symbol encoding, which is an
> 8-bit encoding. So you have to be careful to handle font 5 without
> re-encoding, but that's not hard at device level (the graphics engine has
> handled the re-encoding needed).
Ah, that's the piece I was missing. I was reencoding everything using
QString::fromLocal8bit(). If I skip that when fontface=5, things work
better. I do need it for other fontfaces to get multibyte encodings
working properly.
> If some symbols work and some do not, this is almost certainly a font
> selection issue. If X11 is involved (and AFAIK the Qt implementations on
> Linux run on X11), you do need to ensure that getting a font in the
> desired encoding is given top priority (which can be hard to achieve in
> X11).
That may be a problem in general, but the only problem I see on (both)
my Linux machines after the above fix is that %prop% shows up as mu
(but Windows is fine). I'm not really sure what font is being used,
I'll try to track it down.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] sending signals to embedded R
Hi, one thing I haven't been able to figure out from R-exts is how to interrupt a calculation running inside an embedded R. C code inside R calls R_CheckUserInterrupt() intermittently to check for interrupts, but how does my GUI tell R that the user wants it interrupted? -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sending signals to embedded R
On 5/4/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > On Fri, 4 May 2007, Deepayan Sarkar wrote: > > > one thing I haven't been able to figure out from R-exts is how to > > interrupt a calculation running inside an embedded R. C code inside R > > calls R_CheckUserInterrupt() intermittently to check for interrupts, > > but how does my GUI tell R that the user wants it interrupted? > > Well, the intention is that you send an interrupt, which hardly needs to > be in the manual. I didn't mean to imply that it does. I'm just new to signals and things that should be obvious aren't. Basically kill(2) seems to be the right thing to use, but I wasn't sure what the PID needs to be. Turns out sending SIGINT to my GUI from a shell interrupts R, so raise(SIGINT) should be enough. -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sending signals to embedded R
On 5/5/07, Luke Tierney <[EMAIL PROTECTED]> wrote: > On Sat, 5 May 2007, Prof Brian Ripley wrote: > > > On Sat, 5 May 2007, Luke Tierney wrote: > > > >> On Sat, 5 May 2007, Prof Brian Ripley wrote: > >> > >>> On Fri, 4 May 2007, Luke Tierney wrote: > >>> > >>>> On Fri, 4 May 2007, Deepayan Sarkar wrote: > >>>> > >>>>> On 5/4/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > >>>>>> On Fri, 4 May 2007, Deepayan Sarkar wrote: > >>>>>> > >>>>>>> one thing I haven't been able to figure out from R-exts is how to > >>>>>>> interrupt a calculation running inside an embedded R. C code inside > R > >>>>>>> calls R_CheckUserInterrupt() intermittently to check for interrupts, > >>>>>>> but how does my GUI tell R that the user wants it interrupted? > >>>>>> > >>>>>> Well, the intention is that you send an interrupt, which hardly needs > >>>>>> to > >>>>>> be in the manual. > >>>>> > >>>>> I didn't mean to imply that it does. I'm just new to signals and > >>>>> things that should be obvious aren't. > >>>>> > >>>>> Basically kill(2) seems to be the right thing to use, but I wasn't > >>>>> sure what the PID needs to be. Turns out sending SIGINT to my GUI from > >>>>> a shell interrupts R, so raise(SIGINT) should be enough. > >>>> > >>>> The tricky bit here is figuring out who does the sending. It you have > >>>> a separate thread/process for the GUI and R then that is fine (though > >>>> may raise other issues). If it is a single thread then you need your > >>>> event processing to get an occasional look in to recognise the user > >>>> action that triggers an interrupt. The Windows version handles this by > >>>> having R_CheckUserInterrupt() do a limited amount of event processing > >>>> (you need to be careful in GUI events have R actions associated with > >>>> them). I believe the Mac version is similar though it has been a > >>> > >>> I was assuming that Deepayan's GUI (which seems to need Qt4, BTW, so I > was > >>> unable to compile it) Why is that a problem? As far as I can tell, Qt4 can peacefully coexist with Qt3, and while compiling you just need to use the right qmake (this is currently hardcoded in the configure script unfortunately). Qt4 has been around for a while now, and it's GPL on Windows/Mac as well as X11, so it seemed like the natural choice. > >>> worked via the R-Unix eventloop, in which case it > >>> gets some CPU time from time to time. > >> > >> I was assuming that as well. But my recollection is that on unix the > >> event loop is only run from within the console reader. On Windows > >> (and Mac OS X I believe) some event processing also happens in > >> R_CheckUserInterrupt(); on Windows there is also some more in some > >> blocking library calls, like socket reads as I recall. But unless > >> things have changed since I last looked none of that happens on unix. > >> > >>> > >>> gnomeGUI has an interrupt menu item with action 'onintr', which may well > >>> be what Deepayan is looking for: the only reason that package still > exists > >>> is to provide example code. (Not that it was ever properly integrated > >>> with the R event loop.) > >> > >> It does have some sort of interrupt device (I can't recall if it is a > >> menu item or a butto and I can't seem to build a working gnomeGUI to > >> check). And I believe if you try to use that item (or button?) during > >> a long-running computation you can't because the events won't be > >> looked at until R gets back to a console read, at which point the > >> events will be processed and you jump to the top level (where you > >> already are). > > > > That belief is correct (it has a menu item and a button), but my final > > parenthetical remark was that gnomeGUI was not wedged into the event loop. > > > >>> If the issue is what happens when the user Ctrl-C's in the GUI console, > >>> that depends on what the GUI toolkit does with keyboard input: if it > >>> generates a SIGINT this should just work, but otherwise the keyboard > >>> handler n
Re: [Rd] sending signals to embedded R
On 5/6/07, Jeffrey Horner <[EMAIL PROTECTED]> wrote:
> Luke Tierney wrote:
[...]
> >> Is there a reason R_ProcessEvents cannot be set on Unix but can on
> >> Mac? It doesn't seem user-settable on Windows, but whatever the built
> >> in default is seems to handle the Qt event loop. And for that matter,
> >> why is it possible to set the file.edit callback on Mac but not Linux?
> >> This seems arbitrary, and no explanation is given (that I could find).
> >
> > The R_PRocessEvents callback may be settable on MacOS but I'm not sure
> > it's used -- at least a quick grep didn't reveal its use anywhere
> > outside the gnuwin32 code.
I meant the callback ptr_R_ProcessEvents (in Rinterface.h). The Mac
GUI source has (this is probably not the latest version):
[EMAIL PROTECTED]:~/Mac-GUI-1.17$ grep -i ptr_r_process */*
REngine/Rinit.c:extern void (*ptr_R_ProcessEvents)();
REngine/Rinit.c:ptr_R_ProcessEvents = Re_ProcessEvents;
and R/trunk/src/unix/aqua.c has:
void R_ProcessEvents(void)
{
if(!useaqua){
if (R_interrupts_pending)
onintr();
return;
} else
ptr_R_ProcessEvents();
}
> > It would be good to unify the Mac and *nix mechanisms here since the
> > OS underpinings are now so similar, but it will have to get high
> > enough on someone's priority list to happen.
[...]
> >> The problem I'm having with this solution is that whenever I interrupt
> >> a graphics command, R crashes. This is true for commands being
> >> evaluated by R_tryEval, but not those run from the REPL (for example,
> >> if I make the call inside a debug() environment, interrupting it
> >> causes no problems). As far as I can tell, this is only a problem with
> >> graphics; other commands can be interrupted even when run using
> >> R_tryEval().
> >
> > That sounds like a longjmp being done to a place that doesn't exist --
> > maybe a threading issue in Qt. See what gdb tells you about where the
> > crash is occurring. It might be different for onintr and kill. You
> > might also try just setting the R_interrupts_pending flag from the
> > interrupt event handler rather than calling onintr (which probably
> > longjmp's) or kill (which may be doing something you don't want if
> > other threads with other signal handlers are involved).
I will have to start learning about gdb sometime soon, but in this case, the
problem seems to be due to the interaction of R_tryEval() and
graphics, and has nothing to do with interruptions. Here's a variant
of the trEval test case that triggers a legitimate error caused by
grid.text('foo', gp = gpar(font=1, fontface=1))
[EMAIL PROTECTED]:~$ cat tryEvalGraphics.c ## beware of line wrapping
/*
Compile this as:
RPROG=R-devel
export LD_LIBRARY_PATH=`${RPROG} RHOME`/lib:\${LD_LIBRARY_PATH}
gcc `${RPROG} CMD config --cppflags` \
`${RPROG} CMD config --ldflags` \
-o tryEvalGraphics tryEvalGraphics.c
*/
#include
#include
#include
int
main(int argc, char *argv[])
{
SEXP e, val;
int i, errorOccurred;
ParseStatus status;
char *cmds[] = {
"library(lattice)",
"library(grid)",
"grid.text('foo', gp = gpar(font=1, fontface=1))",
"xyplot(1 ~ 1, panel = function() grid.text('foo', gp =
gpar(font=1, fontface=1)))"
};
argv[0] = "R";
Rf_initEmbeddedR(argc, argv);
for (i = 0; i < 4; i++) {
printf("** I **: Executing command: %s\n", cmds[i]);
fflush(stdout); sleep(1);
PROTECT(e = R_ParseVector(mkString(cmds[i]), -1, &status, R_NilValue));
val = R_tryEval(VECTOR_ELT(e, 0), NULL, &errorOccurred);
if (errorOccurred) { Rprintf("Error executing: %s\n", cmds[i]); }
else Rf_PrintValue(val);
UNPROTECT(1);
printf("** I **: Succeeded\n");
fflush(stdout); sleep(1);
}
Rf_endEmbeddedR(0);
return(0);
}
Running this, I get:
[EMAIL PROTECTED]:~$ R-devel CMD ./tryEvalGraphics
R version 2.6.0 Under development (unstable) (2007-05-04 r41439)
[...]
[Previously saved workspace restored]
** I **: Executing command: library(lattice)
[1] "stats" "graphics" "grDevices" "utils" "datasets" "lattice"
[7] "rcompgen" "methods" "base"
** I **: Succeeded
** I **: Executing command: library(grid)
[1] "grid" "stats" "graphics" "grDevices" "utils" "datasets"
[7] "lattice" "rcompgen" "methods" "base"
** I **: Succeeded
** I **: Executing command: grid.text('foo', gp = gpar(font=1, fontface=1))
Error in validGP(list(...)) : Must specify only one of 'font' and 'fontface'
Error executing: grid.text('foo', gp = gpar(font=1, fontface=1))
** I **: Succeeded
** I **: Executing command: xyplot(1 ~ 1, panel = function()
grid.text('foo', gp = gpar(font=1, fontface=1)))
Error in validGP(list(...)) : Must specify only one of 'font' and 'fontface'
*** caught segfault ***
address 0x22000440, cause 'memory not mapped'
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without sav
Re: [Rd] Qt device update
On 5/5/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
[...]
> odev.interactive() regards devices with the displaylist enabled
> as interactive, and packages can register the names of their
> devices as interactive via deviceIsInteractive().
Thanks. A related issue: 2.5.0's NEWS has:
o options(device = ) now accepts a function object as well as
the name of a function.
(For some reason, I had thought this was true all along, but in any
case) This means that it's now reasonable to do
> options(device = function() x11("", 4, 4))
But then I get (iff there is no device open)
> example(glm)
Error in match(x, table, nomatch = 0) : 'match' requires vector arguments
because dev.interactive() doesn't know about the change yet.
dev.interactive() cannot really do anything useful in this case, but
an error seems too harsh (especially since example(glm) doesn't even
have any graphics).
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sending signals to embedded R
On 5/6/07, Deepayan Sarkar <[EMAIL PROTECTED]> wrote:
> I will have to start learning about gdb sometime soon, but in this case, the
> problem seems to be due to the interaction of R_tryEval() and
> graphics, and has nothing to do with interruptions. Here's a variant
> of the trEval test case that triggers a legitimate error caused by
>
> grid.text('foo', gp = gpar(font=1, fontface=1))
[...]
> Running this, I get:
>
>
> [EMAIL PROTECTED]:~$ R-devel CMD ./tryEvalGraphics
>
> R version 2.6.0 Under development (unstable) (2007-05-04 r41439)
>
> [...]
>
> [Previously saved workspace restored]
>
> ** I **: Executing command: library(lattice)
> [1] "stats" "graphics" "grDevices" "utils" "datasets" "lattice"
> [7] "rcompgen" "methods" "base"
> ** I **: Succeeded
> ** I **: Executing command: library(grid)
> [1] "grid" "stats" "graphics" "grDevices" "utils" "datasets"
> [7] "lattice" "rcompgen" "methods" "base"
> ** I **: Succeeded
> ** I **: Executing command: grid.text('foo', gp = gpar(font=1, fontface=1))
> Error in validGP(list(...)) : Must specify only one of 'font' and 'fontface'
> Error executing: grid.text('foo', gp = gpar(font=1, fontface=1))
> ** I **: Succeeded
> ** I **: Executing command: xyplot(1 ~ 1, panel = function()
> grid.text('foo', gp = gpar(font=1, fontface=1)))
> Error in validGP(list(...)) : Must specify only one of 'font' and 'fontface'
>
> *** caught segfault ***
> address 0x22000440, cause 'memory not mapped'
>
> Possible actions:
> 1: abort (with core dump, if enabled)
> 2: normal R exit
> 3: exit R without saving workspace
> 4: exit R saving workspace
> Selection: 3
> [EMAIL PROTECTED]:~$
And running this again with optimization turned off, I get for the last command:
** I **: Executing command: xyplot(1 ~ 1, panel = function()
grid.text('foo', gp = gpar(font=1, fontface=1)))
Error in validGP(list(...)) : Must specify only one of 'font' and 'fontface'
Error: unprotect(): only 0 protected items
** I **: Succeeded
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sending signals to embedded R [SOLVED]
On 5/7/07, Deepayan Sarkar <[EMAIL PROTECTED]> wrote: > On 5/6/07, Deepayan Sarkar <[EMAIL PROTECTED]> wrote: > > > I will have to start learning about gdb sometime soon, but in this case, > the > > problem seems to be due to the interaction of R_tryEval() and > > graphics, and has nothing to do with interruptions. Here's a variant > > of the trEval test case that triggers a legitimate error caused by [...] Turns out R_tryEval is not to blame; the error (here as well as in my GUI) was occurring inside the unprotected call to PrintValue() after tryEval returned. I should have noticed that sooner. Sorry for the noise. -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
