Re: [R-pkg-devel] vignette with "Run Examples"

[Deepayan Sarkar]

On Tue, 12 Dec 2023 at 12:54, Sigbert Klinke 
wrote:

> Hi,
>
> is it possible to get a button or link to run an example in a vignette
> like we see for the examples in the R help?
>

Just to understand your expectations: The 'run examples' option only works
within the "dynamic" R help system, because it has access to a running
version of R. Vignettes can also be viewed through the dynamic system, but
they perhaps more useful as standalone documentation (say on the CRAN page
of a package). Would it be really useful to be able to run the code only in
the limited setup of dynamic help?

The other issue is that examples are expected to be short and simple,
whereas vignettes can often be more complicated. They will also typically
include the "output" from running the code, so what would be the point of
running it again?

If you want to really try the vignette code, then the package documentation
page typically includes the R code extracted from a vignette, which you can
download and run. And of course with IDEs like ESS or RStudio, you can
simply open the vignette source and run the code interactively.

Best,
-Deepayan


>
> Thanks Sigbert
>
> --
> https://hu.berlin/sk
> https://www.stat.de/faqs
> https://hu.berlin/mmstat
> https://hu.berlin/mmstat-ar
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] data.frame weirdness

[Deepayan Sarkar]

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] data.frame weirdness

[Deepayan Sarkar]

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: [R-pkg-devel] Recent dev version of R CMD check fails when a package function named X also has a parameter named X

[Deepayan Sarkar]

On Mon, 30 Oct 2023 at 12:48, Markus Jochim
 wrote:
>
> Hi R people,
>
> I am the maintainer of the emuR package and I am having a problem with
> recent versions of R CMD check.
>
> CRAN‘s r-devel test suites [1] have started to emit a NOTE about the
> HTML version of the manual:
>
> > Version: 2.4.1
> > Check: HTML version of manual
> > Result: NOTE
> > Found the following HTML validation problems:
> > query.html:50:9 (query.Rd:22): Warning:  anchor "query"
> > already defined
> > Flavors: r-devel-linux-x86_64-debian-clang,
> > r-devel-linux-x86_64-debian-gcc, r-devel-linux-x86_64-fedora-clang,
> > r-devel-linux-x86_64-fedora-gcc, r-devel-windows-x86_64
> >
> This is caused by one of my package’s functions that is named query and
> also has a parameter named query.
>
> I think I have tracked this down to SVN revision r85407 of R. With
> earlier versions:
>
> R CMD Rdconv -t html query.Rd
>
> would output (line 50, as referenced by the NOTE):
>
> query
>
> But newer versions output:
>
> query

Yes, sorry, my bad.

r85440 (just committed) should have a temporary fix by omitting the id
from the  title. Please let me know if problems still persist.

Best,
-Deepayan

> Notice the difference in id. The id "query" appears both here and
> further up in the file, specifically in the h2 heading. This triggers
> the HTML validation problem. I suppose this is a bug in the experimental
> table of contents feature? As such, should I rather post this to R-devel?
>
> Unfortunately, this also prevents me from uploading a new version of my
> package, since it does not get past CRAN’s automatic pretest. Can I
> resubmit my new version and simply state in the comments that I cannot
> fix the NOTE from r-devel at this point? Or should I rather wait until
> this is changed upstream? (the described NOTE is the only complaint from
> the pretest). Changing the function or parameter name is not an option,
> they have been used in this package ever since it was released a couple
> of years ago.
>
> This NOTE can also be reproduced with a minimal R package that has
> nothing but a hello function with a parameter named hello.
>
> Thanks for reading this. I appreciate any help.
>
> Markus
>
>
> Institute for Phonetics and Speech Processing
>
> Ludwig-Maximilians-Universität München
>
> https://www.phonetik.uni-muenchen.de
>
>
> [1] https://cran.rstudio.com//web/checks/check_results_emuR.html
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] Autocompletion for the new S3 generic @ method?

[Deepayan Sarkar]

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] Autocompletion for the new S3 generic @ method?

[Deepayan Sarkar]

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: [Bioc-devel] S4 Methods Documentation Convention Triggers Warnings

[Deepayan Sarkar]

R-devel and R-4-3-branch both now have the option of suppressing these
warnings by setting

_R_CHECK_RD_ALLOW_EMPTY_ITEM_IN_DESCRIBE_=true

But please note this is only intended to be a stop-gap measure, and
will likely be removed at some point.

Best,
-Deepayan

On Mon, Jan 30, 2023 at 12:02 PM Hervé Pagès  wrote:
>
> On 28/01/2023 19:42, Deepayan Sarkar wrote:
> ...
> > I'm open to suppressing the warning for \describe items (the warning
> > is more important for \arguments). Let me know.
>
> Hi Deepayan, suppressing the warning for \describe would kind of make
> sense. Thanks for the offer.
>
> Best,
>
> H.
>
> --
> Hervé Pagès
>
> Bioconductor Core Team
> hpages.on.git...@gmail.com
>

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] tab-complete for non-syntactic names could attempt backtick-wrapping

[Deepayan Sarkar]

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: [Bioc-devel] S4 Methods Documentation Convention Triggers Warnings

[Deepayan Sarkar]

On Fri, Jan 27, 2023 at 9:26 PM Hervé Pagès  wrote:
>
> On 27/01/2023 02:00, Dario Strbenac via Bioc-devel wrote:
>
> > Good day,
> >
> > So, is the ultimate solution to manually change everything to the format of
> >
> > \item{\code{show(x)}:}{
> >...
> > } ?
>
> I think I will do this in my own packages. Still need to make those
> changes though, just didn't have time to work on a script to automate this.
>
> >
> > The warnings persist, so it does not seem as though R will revert to 
> > allowing the currently-popular syntax past its check.
>
> I don't see that anybody complained about this on R-devel, so they don't
> really have a reason to revert.

I'm open to suppressing the warning for \describe items (the warning
is more important for \arguments). Let me know.

Best,
-Deepayan

> H.
>
> >
> > --
> > Dario Strbenac
> > University of Sydney
> > Camperdown NSW 2050
> > Australia
> > ___
> > Bioc-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> --
> Hervé Pagès
>
> Bioconductor Core Team
> hpages.on.git...@gmail.com
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] Recycling in arithmetic operations involving zero-length vectors

[Deepayan Sarkar]

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] Not documenting a function and not getting a check error?

[Deepayan Sarkar]

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: [Bioc-devel] S4 Methods Documentation Convention Triggers Warnings

[Deepayan Sarkar]

On Sun, Nov 27, 2022 at 12:30 PM Dario Strbenac via Bioc-devel <
bioc-devel@r-project.org> wrote:

> Good day,
>
> For a long time, it has been a convention to document S4 methods in the
> format:
>
> \section{Displaying}{
>   In the code snippets below, \code{x} is a GRanges object.
>   \describe{
> \item{}{
>   \code{show(x)}:
>   Displays the first five and last five elements.
> }
>   }
> }
>
> In R Under Development, this is now a warning:
>
> * checking Rd files ... WARNING
> checkRd: (5) GRanges-class.Rd:115-165: \item in \describe must have
> non-empty label.
>

> This affects my own package as well as the core Bioconductor packages
> which I used as inspiration for designing my pacakge documentation seven
> years ago. What should the new convention be? Or could R developers be
> convinced to get rid of this check before this prototype is released?
>

The warning is primarily meant for \items inside \arguments, as in HTML
output these now have an id that can be used to link to specific arguments.
The code is shared with \describe, which is why the warning is showing up
here.

So I guess it might be possible to fine-tune the warning to accept this
kind of usage inside \describe. But I think this is a horrible
"convention", and unless this is really widespread that wouldn't be my
first choice.

An alternative to Henrik's suggestion is to just use \itemize instead of
\describe and drop  the first {} after \item.

Best,
-Deepayan



>
> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] running examples with enhanced help engine also requires mime package

[Deepayan Sarkar]

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] Bundling MathJax

[Deepayan Sarkar]

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: [R-pkg-devel] Is there a better way ...?

[Deepayan Sarkar]

On Thu, Oct 21, 2021 at 12:15 PM Rolf Turner  wrote:
>
>
> On Thu, 21 Oct 2021 02:03:41 -0400
> Duncan Murdoch  wrote:
>
> > On 21/10/2021 12:40 a.m., Andrew Simmons wrote:
> > > I think the simplest answer is to store the variable in the
> > > functions frame. I'm assuming here that the only plot.foo needs
> > > access to .fooInfo, if not this can be changed.
> > >
> > >
> > > plot.foo <- function (...)
> > > {
> > >  .fooInfo
> > > }
> > > environment(plot.foo) <- new.env()
> > > evalq({
> > >  .fooInfo <- NULL
> > > }, environment(plot.foo))
> > >
> > >
> > > Make your function, and do whatever you need with .fooInfo within
> > > said function. Whenever you previously updated .fooInfo in the
> > > global environment, update .fooInfo in plot.foo environment instead.
> > > Also, because .fooInfo is not stored in the package's frame, it
> > > won't be locked when the namespace is sealed. If you created it at
> > > the toplevel, that would create some issues. But this works fine.
> >
> > I agree with the final result, but I'd write the code differently:
> >
> > plot.foo <- local({
> >
> >.fooInfo <- NULL
> >
> >function (...) { ... }
> > })
> >
> > creates an environment, puts .fooInfo into it with value NULL, then
> > creates a function with that environment attached and returns it.
> >
> > I think Andrew's approach will work, but changing a function's
> > environment always worries me.  Using local(), the function assigned
> > to plot.foo never has a different environment than the one it ends up
> > with (and I don't need to remember how evalq() works).
>
> Thanks everyone for these suggestions.  They seem a great deal
> less shaganappi/kludgy than my previous approaches.
>
> I've never really felt totally comfortable with the environment
> concept, despite have used it quite a bit (basically in a
> hammer-and-hope style.)
>
> Can anyone comment on the difference between Deepayan's suggestion
> (create a new environment in the package) and Duncan's suggestion
> (create an environment that is local to plot.foo())?  Are there pros
> and cons between the two?

My suggestion is having a package-specific environment, and Duncan's
is to have a function-specific environment. If you only need this for
this one function, then that should be good enough. If you eventually
want to access the persistent information from multiple functions,
having a package-specific environment would be more useful.

I'm not sure what you are trying to do, but I can't see how you can do
something sensible with a function-specific environment if someone
does

plot.foo(something)
plot.default(1:10)
plot.foo(something else, add = TRUE)

So maybe you would eventually want to set a hook (?setHook) for
plot.new to ensure that no other plot has been created in between,
which could write into this package-specific environment.

> And Deepayan:  what is the rationale for not exporting the new
> environment that you suggest creating?  Presumably this guards against
> something.  What?  I'd just like to extend my (currently minimal)
> comprehension of the issues.

Nothing other than the usual reason for not exporting things
unnecessarily, which is to not pollute the user workspace.

> I must admit that Andrew's suggestion kind of overwhelms and bewilders
> me.  I really have no idea what evalq() does.  I guess I could RTFM,
> but the thought of doing that scares me! :-)

Andrew's suggestion looks more complicated than it is. Think of
.fooInfo as a "global" variable, just in your package namespace rather
than .GlobalEnv, so you could do (in your package code)

.fooInfo <- NULL

plot.foo <- function(...)
{
   if (is.null(.fooInfo)) ... # use .fooInfo
   .fooInfo <<- something # set .fooInfo
}

Andrew suggested a separate (and unnamed) environment to store both
.fooInfo and plot.foo, so the setting part becomes a bit more
complicated (but accessing becomes safer in the sense that no other
function can access .fooInfo).

My suggestion is essentially similar, except that you can use <-
instead of <<- because it's an environment.

.fooEnv <- new.env()

plot.foo <- function(...)
{
   if (is.null(.fooEnv$info)) ... # use .fooEnv$info
   .fooEnv$info <- something # set .fooEnv$info
}

Best,
-Deepayan

> Thanks again everybody.
>
> cheers,
>
> Rolf
>
> --
> Honorary Research Fellow
> Department of Statistics
> University of Auckland
> Phone: +64-9-373-7599 ext. 88276
>

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Is there a better way ...?

[Deepayan Sarkar]

On Thu, Oct 21, 2021 at 9:59 AM Rolf Turner  wrote:
>
>
> I have a plot method (say plot.foo()) that I want to be able to call so
> that if argument "add" is set equal to TRUE, then further structure will
> be added to the same plot.  This is to be used *only* in the context in
> which the plot being added to was created using plot.foo().
>
> [Please don't ask me why I don't do everything in a single call to
> plot.foo().  There *are* reasons.]
>
> In order to make sure that the "further structure" has the appropriate
> form, the call to plot.foo(...,add=TRUE,...) needs to access information
> about what was done in the previous call to plot.foo().
>
> Initially I tried to effect this by creating, in a call of the form
> plot.foo(...,add=FALSE,...), an object, say ".fooInfo", in the global
> environment, and then having the call plot.foo(...,add=TRUE,...)
> access the necessary information from ".fooInfo".

Why not have a private (unexported) environment in your own package
for the same purpose? (That's the strategy used by lattice.) E.g., in
your zzz.R

.FooEnv <- new.env()

and then have your plot.foo write into / read from that. Long term, it
may be better to write accessor functions (which can still be
unexported if only used by your package code) if you want an
implementation-agnostic interface.

Best,
-Deepayan

> It all worked OK, but when I built my package for Windoze, using
> win-builder, I got a note of the form:
>
> > NOTE
> > Found the following assignment to the global environment:
> > File 'pckgename/R/plot.foo.R':
> >   assign(".fooInfo", fooInfo, pos = 1)
>
> I thought uh-oh; CRAN will kick up a stink if/when I submit my package.
>
> I think I've figured out a work-around using tempfile().  There
> are difficulties in that tempfile() creates unique names by tacking
> on an alpha-numeric string such as "38348397e595c" to the file name
> that I specify, so the call to plot.foo(...,add=TRUE,...) cannot know
> the *exact* file name.  I think I can get around that by grepping on
> "fooInfo" in list.files(tempdir()).  I also need to make sure that
> I unlink() any old instances of files in tempdir() with the string
> "fooInfo" in their names before creating a new instance.  Elsewise
> ambiguities will ensue.
>
> As I say --- I think this can all be made to work.  But 
> Am I missing some "obvious" strategy?  I.e. is there a
> better/simpler/less convoluted way of handling this problem?
>
> Grateful for any pearls of wisdom.
>
> cheers,
>
> Rolf Turner
>
> --
> Honorary Research Fellow
> Department of Statistics
> University of Auckland
> Phone: +64-9-373-7599 ext. 88276
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] Possible bug in help file name generation

[Deepayan Sarkar]

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: [R-pkg-devel] Redirect error in .Rd file

[Deepayan Sarkar]

On Wed, May 26, 2021 at 2:23 AM Lenth, Russell V
 wrote:
>
> Hello package developers,
>
> I just upgraded to R version 4.1.0, and now get a new error when I re-build 
> my package. Among the messages about converting help files, I now get:
>
> ...
> update.emmGrid  html
> REDIRECT:topic   levels<-.emmGrid -> update.emmGrid.html [ FAIL ]
> ...
>
> But I don't see anything wrong. In my source code, I have ROxygen tags like 
> this:

You can ignore this; the message just tells you that an attempt to
create a file named "levels<-.emmGrid.html" has failed (because < is
not allowed in file names in Windows).

This will not impact anything _unless_ another package has a
documentation link of the form \link[pkg:levels<-.emmGrid], in which
case the link will fail (but only for static HTML help, which is
rarely used any more).

Best,
-Deepayan

> #' @rdname update.emmGrid
> #' @export
> #' @param x an \code{emmGrid} object
> ...
> #'
> "levels<-.emmGrid" = function(x, value) {
> update.emmGrid(x, levels = value)
> }
>
> And the file update.emmGrid.Rd starts like this:
>
> % Generated by roxygen2: do not edit by hand
> % Please edit documentation in R/emmGrid-methods.R
> \name{update.emmGrid}
> \alias{update.emmGrid}
> \alias{levels<-.emmGrid}
> \title{Update an \code{emmGrid} object}
> \usage{
> \method{update}{emmGrid}(object, ..., silent = FALSE)
>
> \method{levels}{emmGrid}(x) <- value
> }
> ...
>
> This all looks right to me. The help page documents both functions and shows 
> parameters, details, and examples for both functions. If I ask for help for 
> either function, it brings up this page. The only thing I see wrong is the 
> message from building it. Any suggestions?
>
>
> Russell V. Lenth  -  Professor Emeritus
> Department of Statistics and Actuarial Science
> The University of Iowa  -  Iowa City, IA 52242  USA
> Voice (319)335-0712 (Dept. office)  -  FAX (319)335-3017
>
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Bioc-devel] Rd warnings in Windows bioc-devel check

[Deepayan Sarkar]

This has been fixed in R, and should go away once the binaries have caught
up. See

https://bugs.r-project.org/bugzilla/show_bug.cgi?id=18090

Best,
Deepayan

On Sat, May 1, 2021, 4:44 PM Benjamin Jean-Marie Tremblay <
benjamin.tremb...@uwaterloo.ca> wrote:

> Dear Bioc-devel,
>
> For a little while now I've been getting a couple of odd Rd warnings in
> the Windows check of the devel branch of my package:
>
> Found the following significant warnings:
>   Rd warning: Previous alias or file overwritten by alias:
> convert_motifs,PWM-method
>   Rd warning: cannot open file
> 'D:/biocbuild/bbs-3.13-bioc/meat/universalmotif.buildbin-libdir/00LOCK-universalmotif/00new/universalmotif/help/[<-,universalmotif-method.html':
> Invalid argument
> See 'D:/biocbuild/bbs-3.13-bioc/meat/universalmotif.Rcheck/00install.out'
> for details.
>
> These warnings do not appear in the release branch Windows check, so I am
> a bit confused as to what may be happening. My guess is that the first
> warning is happening due to the presence of another alias
> (convert_motifs,pwm-method) which might pose a problem if the Rd aliases or
> filenames were case insensitive. The second warning I suspect is relating
> to some of the characters in '<-' not playing nice with Rd aliases or
> filenames, but again I find it strange that this has suddenly become a
> problem. I have noticed that I'm not alone in getting these warnings
> though, for example I can see that IRanges, BiocGenerics, etc are getting
> them too.
>
> Any insight would be helpful. The deadline for passing R CMD check is in a
> couple of weeks, and I am a loss as to what to do. The fact that core
> Bioconductor packages are getting similar warnings suggests to me that
> these might be considered 'acceptable warnings' as mentioned in the release
> schedule, but I wanted to ask ahead of time to be sure.
>
> Thanks,
>
> Benjamin
>
>
> https://bioconductor.org/checkResults/devel/bioc-LATEST/universalmotif/riesling1-checksrc.html
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] reshape documentation

[Deepayan Sarkar]

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] reshape documentation

[Deepayan Sarkar]

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] New pipe operator

[Deepayan Sarkar]

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] New pipe operator

[Deepayan Sarkar]

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

[Deepayan Sarkar]

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] R-devel internal errors during check produce?

[Deepayan Sarkar]

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] Surpising behavior when using an active binding as loop index in R 4.0.0

[Deepayan Sarkar]

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] Possible documentation problem/bug?

[Deepayan Sarkar]

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] inappropriate warning in latticeExtra

[Deepayan Sarkar]

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] inappropriate warning in latticeExtra

[Deepayan Sarkar]

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] [R] Bug : Autocorrelation in sample drawn from stats::rnorm (hmh)

[Deepayan Sarkar]

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] apply with zero-row matrix

[Deepayan Sarkar]

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] inappropriate warning in latticeExtra

[Deepayan Sarkar]

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] R-3.3.3/R-3.4.0 change in sys.call(sys.parent())

[Deepayan Sarkar]

On Thu, May 11, 2017 at 8:03 PM, William Dunlap <wdun...@tibco.com> 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 <deepayan.sar...@gmail.com>
> wrote:
>>
>> On Wed, May 10, 2017 at 2:36 AM, William Dunlap via R-devel
>> <r-devel@r-project.org> 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())

[Deepayan Sarkar]

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] unlicense

[Deepayan Sarkar]

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 CMD BATCH vs R CMD batch

[Deepayan Sarkar]

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] [patch] Add support for editor function in edit.default

[Deepayan Sarkar]

On Sun, Aug 24, 2014 at 9:14 AM, Scott Kostyshak skost...@princeton.edu wrote:
 On Tue, May 20, 2014 at 5:55 AM, Scott Kostyshak skost...@princeton.edu 
 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] legitimate use of :::

[Deepayan Sarkar]

On Wed, May 14, 2014 at 12:29 AM, Duncan Murdoch
murdoch.dun...@gmail.com 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: [Bioc-devel] tab completion for library()

[Deepayan Sarkar]

On Wed, Nov 13, 2013 at 10:55 PM, Martin Morgan mtmor...@fhcrc.org wrote:
 On 11/13/2013 09:17 AM, Tim Triche, Jr. wrote:

 This seems like what I'm looking for, but it doesn't do what I'd expect:

 R rc.options(ipck=TRUE)
 R rc.options()$ipck
 [1] TRUE
 R require(Biostr\t
 # nothing happens

 Should I be using one of the intermediate/undocumented functions to grab a
 list of possible completions?


 should be rc.settings(ipck=TRUE)

Yes, sorry, my bad :-)

-Deepayan

 Tab completion can be pretty useful to customize for class developers, for
 instance library(GenomicRanges); .DollarNames.GenomicRanges is what enables
 tab completion on the metadata column names

 gr = GRanges(chr1, IRanges(1, 10), foo=1, bar=2)
 gr$ftab

 Martin


 Thanks,

 --t


 R sessionInfo()
 R Under development (unstable) (2013-11-11 r64202)
 Platform: x86_64-unknown-linux-gnu (64-bit)

 locale:
   [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
   [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
   [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
   [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
   [9] LC_ADDRESS=C   LC_TELEPHONE=C
 [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

 attached base packages:
 [1] parallel  stats graphics  grDevices datasets  utils methods
 [8] base

 other attached packages:
   [1] Matrix_1.1-0
   [2] frma_1.15.1
   [3] BSgenome.Hsapiens.UCSC.hg19_1.3.19
   [4] BSgenome_1.31.6
   [5] Biostrings_2.31.1
   [6] Homo.sapiens_1.1.1
   [7] TxDb.Hsapiens.UCSC.hg19.knownGene_2.10.1
   [8] org.Hs.eg.db_2.10.1
   [9] GO.db_2.10.1
 [10] RSQLite_0.11.4
 [11] DBI_0.2-7
 [12] OrganismDbi_1.5.0
 [13] GenomicFeatures_1.15.2
 [14] AnnotationDbi_1.25.3
 [15] Biobase_2.23.2
 [16] chromophobe_0.79
 [17] fastcluster_1.1.11
 [18] pheatmap_0.7.7
 [19] ggplot2_0.9.3.1
 [20] reshape2_1.2.2
 [21] GenomicRanges_1.15.9
 [22] XVector_0.3.1
 [23] IRanges_1.21.8
 [24] BiocGenerics_0.9.0
 [25] BiocInstaller_1.13.2
 [26] gtools_3.1.1
 [27] devtools_1.3

 loaded via a namespace (and not attached):
   [1] affxparser_1.35.0affy_1.41.1  affyio_1.31.0

   [4] biomaRt_2.19.1   bit_1.1-10   bitops_1.0-6

   [7] codetools_0.2-8  colorspace_1.2-4 dichromat_2.0-0

 [10] digest_0.6.3 evaluate_0.5.1   ff_2.2-12

 [13] foreach_1.4.1GenomicAlignments_0.99.2 graph_1.41.1

 [16] grid_3.1.0   gtable_0.1.2 httr_0.2

 [19] iterators_1.0.6  labeling_0.2 lattice_0.20-24

 [22] MASS_7.3-29  matrixStats_0.8.12   memoise_0.1

 [25] munsell_0.4.2oligo_1.27.0 oligoClasses_1.25.1

 [28] plyr_1.8 preprocessCore_1.25.0proto_0.3-10

 [31] R.methodsS3_1.5.2RBGL_1.39.1  RColorBrewer_1.0-5

 [34] RCurl_1.95-4.1   Rsamtools_1.15.7 rtracklayer_1.23.3

 [37] scales_0.2.3 splines_3.1.0stats4_3.1.0

 [40] stringr_0.6.2tools_3.1.0  whisker_0.3-2

 [43] XML_3.98-1.1 zlibbioc_1.9.0


 *He that would live in peace and at ease, *
 *Must not speak all he knows, nor judge all he sees.*

 Benjamin Franklin, Poor Richard's
 Almanackhttp://archive.org/details/poorrichardsalma00franrich


 On Wed, Nov 13, 2013 at 8:43 AM, Deepayan Sarkar
 deepayan.sar...@gmail.comwrote:

 On Wed, Nov 13, 2013 at 10:06 PM, Tim Triche, Jr. tim.tri...@gmail.com
 wrote:

 How hard would this be to set up (e.g. using a mechanism like
 AnnotationHub's)?

 I'm really lazy and wondering if the time spent writing a little package
 might be recovered when I want to load a BSgenome or SNPlocs (or...)
 package this way.

 Plus if the mechanism could involve caching, maybe that could work for
 biocLite too.

 Just a thought.  How much trouble am I looking at and what should I
 watch
 out for?


 Set

 rc.options(ipck = TRUE)

 and try again. Is this what you are looking for?

 -Deepayan

 thanks,

 --t


 *He that would live in peace and at ease, *
 *Must not speak all he knows, nor judge all he sees.*

 Benjamin Franklin, Poor Richard's
 Almanackhttp://archive.org/details/poorrichardsalma00franrich

  [[alternative HTML version deleted]]

 ___
 Bioc-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/bioc-devel



 [[alternative HTML version deleted]]

 ___
 Bioc-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/bioc-devel



 --
 Computational Biology / Fred Hutchinson Cancer Research Center
 1100 Fairview Ave. N.
 PO Box 19024 Seattle, WA 98109

 Location: Arnold Building M1 B861
 Phone: (206) 667-2793

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] tab completion for library()

[Deepayan Sarkar]

On Wed, Nov 13, 2013 at 10:06 PM, Tim Triche, Jr. tim.tri...@gmail.com wrote:
 How hard would this be to set up (e.g. using a mechanism like
 AnnotationHub's)?

 I'm really lazy and wondering if the time spent writing a little package
 might be recovered when I want to load a BSgenome or SNPlocs (or...)
 package this way.

 Plus if the mechanism could involve caching, maybe that could work for
 biocLite too.

 Just a thought.  How much trouble am I looking at and what should I watch
 out for?

Set

rc.options(ipck = TRUE)

and try again. Is this what you are looking for?

-Deepayan

 thanks,

 --t


 *He that would live in peace and at ease, *
 *Must not speak all he knows, nor judge all he sees.*

 Benjamin Franklin, Poor Richard's
 Almanackhttp://archive.org/details/poorrichardsalma00franrich

 [[alternative HTML version deleted]]

 ___
 Bioc-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/bioc-devel

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] Type annotations for R function parameters.

[Deepayan Sarkar]

On Fri, Aug 30, 2013 at 2:49 PM, Оботуров Артем obotu...@gmail.com 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] Extending suggestion for stopifnot

[Deepayan Sarkar]

On Wed, Aug 21, 2013 at 3:30 AM, ivo welch ivo.we...@gmail.com 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] Extending suggestion for stopifnot

[Deepayan Sarkar]

On Wed, Aug 21, 2013 at 12:11 AM, ivo welch ivo.we...@anderson.ucla.edu 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] 'modifyList' drops (not adds) NULL components

[Deepayan Sarkar]

On Thu, Jun 27, 2013 at 10:59 PM, Raubertas, Richard
richard_rauber...@merck.com 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] Question lattice SplomT

[Deepayan Sarkar]

On Mon, Sep 24, 2012 at 9:22 PM, Christian Hoffmann
c-w.hoffm...@sunrise.ch 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] warning in lattice key function

[Deepayan Sarkar]

On Thu, Aug 16, 2012 at 8:35 AM, Richard M. Heiberger r...@temple.edu 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=browsegroup_id=638atid=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] [ESS] completion in [] (R internal completion fails)

[Deepayan Sarkar]

On Wed, Mar 14, 2012 at 3:27 PM, Vitalie Spinu spinu...@gmail.com 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]]$ATAB

-Deepayan


 Best,
 Vitalie.

 Andreas Leha andreas.l...@med.uni-goettingen.de
 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$aaTAB

   On the other hand, strangly enough, this works as expected:
   ttt$aaa[ ttt$aaTAB

   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] Command completion of the R binary / Ubuntu

[Deepayan Sarkar]

On Wed, Jan 11, 2012 at 4:16 PM, Claudia Beleites
claudia.belei...@ipht-jena.de 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-here I hit tab
 --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] Cases of TAB-completion that hang Rterm

[Deepayan Sarkar]

On Tue, Jun 7, 2011 at 1:49 PM, Henrik Bengtsson h...@biostat.ucsf.edu 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] Source for bash_completion.d/R?

[Deepayan Sarkar]

On Tue, May 3, 2011 at 4:40 AM, Dirk Eddelbuettel e...@debian.org 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] strange interaction between rasterImage and Grid graphics

[Deepayan Sarkar]

On Fri, Oct 1, 2010 at 12:17 AM, baptiste auguie
baptiste.aug...@googlemail.com 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

[Deepayan Sarkar]

On Sat, Oct 2, 2010 at 4:35 PM, Paul Murrell p.murr...@auckland.ac.nz 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] Strange R object

[Deepayan Sarkar]

On Fri, Jul 9, 2010 at 5:25 AM, Peter Dalgaard pda...@gmail.com wrote:
 Gabor Grothendieck wrote:
 On Fri, Jul 9, 2010 at 5:09 AM, Peter Dalgaard pda...@gmail.com 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] Tips for debugging: R CMD check examples

[Deepayan Sarkar]

On Wed, Jun 30, 2010 at 3:26 AM, Hadley Wickham had...@rice.edu 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] cut takes long time

[Deepayan Sarkar]

On Wed, Jun 16, 2010 at 3:56 PM, Gabor Grothendieck
ggrothendi...@gmail.com 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] Argument recycling in substring()

[Deepayan Sarkar]

2010/6/4 Martin Maechler maech...@stat.math.ethz.ch:
 HP == Hervé Pagès hpa...@fhcrc.org
     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] S4 dispatch for .DollarNames (utils)

[Deepayan Sarkar]

On Sat, May 29, 2010 at 4:21 AM, Romain Francois
rom...@r-enthusiasts.com 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$fTAB
 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] Indexing bug?

[Deepayan Sarkar]

On Wed, May 26, 2010 at 3:27 PM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
 Is this expected behaviour?

 x - factor(c(c, b, a,c))
 results - c(c=4, b=5)
 results[x]

 giving

 results[x]
 NA    b    c NA
  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 NA    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] Windows installer, HTML help, R 2.10.0

[Deepayan Sarkar]

On Tue, Nov 10, 2009 at 10:35 AM, Oliver Soong osoon...@gmail.com 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] Improved Function Information with TAB Key

[Deepayan Sarkar]

On Wed, Oct 7, 2009 at 5:56 AM, Lee Kelvin lee.s.kel...@gmail.com wrote:
 Hello,

 Pressing the TAB 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(   TABTAB
 a=  b=  c=

 where TAB 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 TAB 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 TAB Key

[Deepayan Sarkar]

On Thu, Oct 8, 2009 at 5:33 AM, Lee Kelvin lee.s.kel...@gmail.com 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 deepayan.sar...@gmail.com

 On Wed, Oct 7, 2009 at 5:56 AM, Lee Kelvin lee.s.kel...@gmail.com wrote:
  Hello,
 
  Pressing the TAB 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(   TABTAB
  a=  b=  c=
 
  where TAB 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 TAB 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] Lattice: Drawing a single contour line with a negative value fails

[Deepayan Sarkar]

On 8/19/09, Thorn Thaler thot...@sbox.tugraz.at 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] more special completions

[Deepayan Sarkar]

On 8/21/09, Romain Francois romain.franc...@dbmail.com 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

[Deepayan Sarkar]

On 8/21/09, Vitalie S. vitosm...@rambler.ru wrote:
 On Fri, 21 Aug 2009 11:21:03 +0200, Romain Francois
 romain.franc...@dbmail.com 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

[Deepayan Sarkar]

On 8/21/09, Romain Francois romain.franc...@dbmail.com wrote:
 On 08/21/2009 06:59 PM, Deepayan Sarkar wrote:

 
  On 8/21/09, Romain Francoisromain.franc...@dbmail.com
 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] [R] ggplot2 x axis question

[Deepayan Sarkar]

On Mon, Jun 29, 2009 at 9:05 AM, hadley wickhamh.wick...@gmail.com 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
 Desjardinscddesjard...@gmail.com 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] Colour Schemes

[Deepayan Sarkar]

On Thu, May 21, 2009 at 10:53 AM, Barry Rowlingson
b.rowling...@lancaster.ac.uk wrote:
 On Thu, May 21, 2009 at 5:29 PM, Deepayan Sarkar
 deepayan.sar...@gmail.com 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] Google Summer of Code 2009

[Deepayan Sarkar]

On 2/19/09, Dirk Eddelbuettel e...@debian.org wrote:

[...]

 On 19 February 2009 at 09:33, Simon Urbanek wrote:
 | If primitive 3d scatterplot interactivity is all you want, go with
 | rggobi. It's GTK and has all this already and much more. However,
 | ggobi also shows why GTK is not a good choice for general interactive
 | graphics toolkit - it [GTK] is slow and lacks reasonable graphics
 | support. OpenGL is IMHO a better way to go since IG don't really
 | leverage any of the widgets (you get them for free via R widgets
 | packages anyway) and OpenGL gives you excellent speed, alpha-support
 | and anti-aliasing etc.

 I don't want to turn this into an all-out 'vi versus emacs' slugfest but:

 -- GTk it not the only choice, and I have been very happy with Qt (and Qwt
for a simple yet nice plot widget) on both Linux and Windows; I don't
 have
access to a Mac so I didn't test there.

 -- Qt supports OpenGL natively. The demos are very impressive (for OpenGL as
well as the other widgets).

 -- Deepayan has been working on Qt-based code to enhance R, as that appears
to be 'unannounced' I won't post the SVN repo but allow me to state that
the code already ran all (or almost all) examples from the lattice book.

Just to expand on that: yes, I have been working on a Qt-based
infrastructure, and Michael Lawrence is also involved now, and has
been working on refining and optimizing it for more general uses. The
details are still in flux, but we hope to have something to show at
DSC.

Which is not to say that other alternatives wouldn't be good, of course.

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Buggy trellis.focus() with xyplot ?

[Deepayan Sarkar]

On Wed, Nov 19, 2008 at 8:55 AM, Daniel Kornhauser
[EMAIL PROTECTED] wrote:
 Hi:

 (Tried to find a bug report about this issue, but was unable to find it, let
 me know if this is a known issue)
 I have been working on an interface to highlight xyplot panels on mouse
 overs in JavaGD but I have stumbled with what seems to be a bug in
 trellis.focus.
 I am using R 2.8 with lattice 0.17-15


 *** To replicate the bug:
 1.- display an xyplot. For example, from the xyplot help page:
 library(lattice)
 require(stats)
 EE - equal.count(ethanol$E, number=9, overlap=1/4)
 ## Constructing panel functions on the fly; prepanel
 xyplot(NOx ~ C | EE, data = ethanol,
   prepanel = function(x, y) prepanel.loess(x, y, span = 1),
   xlab = Compression Ratio, ylab = NOx (micrograms/J),
   panel = function(x, y) {
   panel.grid(h=-1, v= 2)
   panel.xyplot(x, y)
   panel.loess(x,y, span=1)
   },
   aspect = xy)
 2.- resize to window be rectangular and have large margins in the left hand
 and right hand side.
 3.- run trellis.focus() and try to select the first or last panel, you
 should observe that it does not select the right one.

 sidenotes:
 There are other problems with the focus in JavaGD but I just wanted to
 include a simple self contained example in this mail.
 If you make the window smaller, trellis.focus() works fine, you have to make
 it bigger than the initial size.


 *** To Fix the bug:
 I tried to fix this bug in interraction.R but I was unsuccesful.

 The problem should stem from the a bad calculation of the pads in the
 follwoing lines :
leftPad -
 convertX(sum(glayout$page.layout$widths[1:(colRange[1]-1)]), npc,
 valueOnly = TRUE)
rightPad -
 convertX(sum(glayout$page.layout$widths[(colRange[2]+1):layCols]), npc,
 valueOnly = TRUE)
topPad -
 convertY(sum(glayout$page.layout$heights[1:(rowRange[1]-1)]), npc,
 valueOnly = TRUE)
botPad -
 convertY(sum(glayout$page.layout$heights[(rowRange[2]+1):layRows]), npc,
 valueOnly = TRUE)

 I was succesful in tweaking the follwing lines adding arbitrary constants to
 make it work for a particular instance of a xyplot with a particular size of
 a window
   clickXScaled - (as.numeric(clickLoc$x) - leftPad + Danielconstant1)
 / (1 - leftPad - rightPad  + Danielconstant1)

clickYScaled - (as.numeric(clickLoc$y) - botPad + Danielconstant2)
 / (1 - botPad - topPad + Danielconstant3)
 This is of course a useless fix, since you want the fix to work for any plot
 with any window size, but I might be valuable information.


 *** Questions:
 - Is this a real bug ?
 - Any suggestions for fixing it ?
 - If it can't be fixed, is there a way around this bug ?
 (For example, setting the margins to be zero and set a fixed size for the
 xplot)

It appears that the conversions used in the current implementation
(contributed by Felix Andrews) don't work when aspect != fill
(probably leading back to the use of 'respect = TRUE' in grid.layout).
The right way to do this is to first go down to the subregion
containing just the panels, and then locate the click location within
it. But this requires a suitable viewport to be predefined.

I have changed print.trellis to create such a dummy viewport
(accessible by trellis.focus(figure)), and modified trellis.focus()
to use it. I will test it a bit more before uploading a new version
(and also give Felix a chance to see if this breaks anything in
playwith etc.). To see if the fix works, you can try the svn copy at

https://svn.r-project.org/R-packages/trunk/lattice

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Buggy trellis.focus() with xyplot ?

[Deepayan Sarkar]

On 11/19/08, Daniel Kornhauser [EMAIL PROTECTED] wrote:
 Thanks a lot for taking this on guys !

  Some more background in case you are interested:

 I have almost a working version of focus for selecting a panel with mouse
 over in a stanalone Java application using an REngine I only have two
 issues:

 - trellis.unfocus() is terribly slow in a plot of 10 x 10 panels, it takes
 1.5 seconds to unfocus, do you know any way to speed it up ?

Call as trellis.unfocus(highlight=FALSE). Unhighlighting essentially
redraws the whole thing (this would be true whenever any component is
removed, though adding is fine).

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Fw: alpha transparency crashes R

[Deepayan Sarkar]

I'm forwarding a bug report from Jeff Gove that didn't make it to the list.
-Deepayan

--- Original Message 
Subject:alpha transparency crashes R
Date:   Fri, 07 Nov 2008 14:32:27 -0500
From:   jeff gove [EMAIL PROTECTED]
To: [EMAIL PROTECTED]


I ran into a problem with R crashing when a certain number of
transparent objects (e.g., symbols) are sent to a PDF output device.
This has happened on R 2.71, 2.7.2 (Fedora 8 and Ububtu 8.04
platforms) and now 2.8.0 (I've only tried Fedora 8). The current
pertinent R system stats are...

R.version
   _
platform   x86_64-redhat-linux-gnu
arch   x86_64
os linux-gnu
system x86_64, linux-gnu
status
major  2
minor  8.0
year   2008
month  10
day20
svn rev46754
language   R
version.string R version 2.8.0 (2008-10-20)

The following small example program when run with n large enough
(e.g., n=1000) and transparency will crash R...

alphaBomb.r = function(n=100, wantAlpha=T) {
   df = data.frame(a=rnorm(n),b=runif(n))
   if(wantAlpha)
 alpha=runif(n)
   else
 alpha = 1
   j = xyplot(b~a, df, alpha=alpha, pch=19)
   print(j)
   trellis.device('pdf',file='alphaBomb.pdf',version='1.4')
   print(j)
   dev.off()
}

Please note that the crash seems to occur in the dev.off() component,
and that the file actually seems to get written out correctly.  The
trace of the bomb is found below, excluding the memory map. Please
also note that it may be somehow related to grid, as the following
code (supplied by Deepayan Sarkar) using base graphics does not crash
R, even with n=10...

pdf()
n = 1000
plot(rnorm(n), rnorm(n), col = rgb(0, 0, 0, alpha = runif(n)), pch = 16)
dev.off()

The error trace from the above alphaBomb.r() code is...

R alphaBomb.r(100)   #this is fine
X11cairo
   2

R alphaBomb.r(1000,F) #also fine

R alphaBomb.r(1000)
*** glibc detected *** /usr/lib64/R/bin/exec/R: double free or
corruption (!prev): 0x032c1d90 ***
=== Backtrace: =
/lib64/libc.so.6[0x3ee8c72832]
/lib64/libc.so.6(cfree+0x8c)[0x3ee8c75f2c]
/usr/lib64/R/library/grDevices/libs/grDevices.so[0x2aaab000b0fc]
/usr/lib64/R/lib/libR.so[0x3d1f48ddd3]
/usr/lib64/R/lib/libR.so[0x3d1f48e2dc]
/usr/lib64/R/lib/libR.so[0x3d1f4ec81c]
/usr/lib64/R/lib/libR.so(Rf_eval+0x42e)[0x3d1f4be8ae]
/usr/lib64/R/lib/libR.so[0x3d1f4bf572]
/usr/lib64/R/lib/libR.so(Rf_eval+0x42e)[0x3d1f4be8ae]
/usr/lib64/R/lib/libR.so(Rf_applyClosure+0x291)[0x3d1f4c0bf1]
/usr/lib64/R/lib/libR.so(Rf_eval+0x303)[0x3d1f4be783]
/usr/lib64/R/lib/libR.so[0x3d1f4bf572]
/usr/lib64/R/lib/libR.so(Rf_eval+0x42e)[0x3d1f4be8ae]
/usr/lib64/R/lib/libR.so(Rf_applyClosure+0x291)[0x3d1f4c0bf1]
/usr/lib64/R/lib/libR.so(Rf_eval+0x303)[0x3d1f4be783]
/usr/lib64/R/lib/libR.so(Rf_ReplIteration+0x188)[0x3d1f4dc878]
/usr/lib64/R/lib/libR.so[0x3d1f4dcb90]
/usr/lib64/R/lib/libR.so(run_Rmainloop+0x50)[0x3d1f4dcec0]
/usr/lib64/R/bin/exec/R(main+0x1b)[0x40082b]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x3ee8c1e074]
/usr/lib64/R/bin/exec/R[0x400729]
=== Memory map: 
etc...

Please note that R only crashes with PDF output; tiff, png and eps
(even though it doesn't accept transparency) all exit cleanly.

My version of glibc is 2.7.

Thanks, I hope that the problem is already resolved!

Jeff

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Emacs tags for R code

[Deepayan Sarkar]

Hi,

I have put up details of a new tool for tagging R code at

http://dsarkar.fhcrc.org/rtags/rtags.html

that Emacs/ESS users may be interested in. It should be possible to
extend this for other editors as well.

Comments and feedback welcome.

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Getting the panel location of a xyplot matrix using a mouse click in a GDCanvas

[Deepayan Sarkar]

On Thu, Oct 23, 2008 at 12:26 PM, Daniel Kornhauser
[EMAIL PROTECTED] wrote:
 Hi:

 I would like to find out the panel of a xyplot matrix where a mouse clicked.

 I know this functionality is already bundled in trellis.focus but I can't
 use it because I am coding a stand alone application in Java using with
 GDCanvas as a graphics device.

 I tried calling trellis.focus from Java with:
   re.eval(t = trellis.focus()));
 However it did not work for an embedded GDCanvas. The above call to the
 trellis.focus() returns null no matter where I click.

 (Side note: the functionality must be implemented in the GDCanvas because
 trellis.focus does work correctly in JGR)

 I wish to handle all the user GUI events in Java to evaluate different
 commands in an Rengine.
 With a GDCanvas, it's straightforward to get the x y position of a mouse
 click with the standard e.getX() and e.getY()
 So my handler would look like:
public void mouseClicked(MouseEvent e) {
System.out.println(Clicked + e.getX() +   + e.getY());
System.out.println(re.eval(t = trellis.focus()));
System.out.println(re.eval(t));
   // I would update the panel here ...
}

 I am only using Java because:
 - I am proficient in Java GUI programmer
 - It is multiplatform

 Another way of posing the question is:
 Given the coordinates from grid.location how can I find out the plane of an
 xyplot matrix where the user clicked.

 I have tried to figure out how to do it from code using trellis.clickFocus,
 but I have have only been playing with R for a week, so I am quite lost
 reading R code.

The approach in trellis.clickFocus should get you close. One important
point is that

clickLoc - grid.locator(npc)

returns the location in NPC, whereas your e.getX() and e.getY() would
be in device coordinates. help(grconvertX) should tell you how to make
the conversion.

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R CMD INSTALL problem

[Deepayan Sarkar]

On Tue, Oct 21, 2008 at 3:23 PM, John Fox [EMAIL PROTECTED] wrote:
 Dear list members,

 I've run into a problem with R CMD INSTALL under Windows Vista and R 2.8.0:

 - snip ---

 C:\Users\John Fox\workspacec:\R\R-2.8.0\bin\R CMD INSTALL car
 installing to ''

Not sure if this is relevant for you, but I was seeing similar
behavior on Linux, and the reason turned out to be that the INSTALL
script invokes

R_DEFAULT_PACKAGES=NULL R --no-restore --slave

which ran code in my .Rprofile, but without the usual packages
attached. In my case, this was causing an error (because of not
carefully written code in the profile) leading to an empty string for
$lib (which seems to be happening for you too).

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] rawToChar(raw(0))

[Deepayan Sarkar]

On 5/21/08, Henrik Bengtsson [EMAIL PROTECTED] wrote:
 Hi,

  right now we have (on R v2.7.0 patched (2008-04-23 r45466)) that:

   rawToChar(raw(0))
  [1] 
   rawToChar(raw(0), multiple=TRUE)
  character(0)

  Is this intended or should both return character(0)?  Personally, I
  would prefer that an empty input vector returns an empty output
  vector.

I don't see why; rawToChar(, multiple=FALSE) is meant to be a map from
an n-vector to a scalar. Why should there be an exception when n==0?
Would you expect

mean(numeric(0))

to return numeric(0)?

 Same should then apply to charToRaw(), but right now we get:

   x - character(0)
   charToRaw(x)
  Error in charToRaw(x) : argument must be a character vector of length 1

The error message says it all: charToRaw() maps a scalar to an
n-vector. For vectors of length  1, it uses the first element with a
warning.

No comments on the rest.

-Deepayan

  [...]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R-Forge SVN repositories: R CMD build/check error on Windows machines

[Deepayan Sarkar]

On 4/28/08, Prof Brian Ripley [EMAIL PROTECTED] wrote:
 The difference is in INSTALL, not build/check.

  You are right that the Unix INSTALL was changed in r25808 (Aug 2003), but
 AFAICS this was not documented at the time in [O]NEWS, nor anywhere else.

  Can you point me to the documentation you used to implement this?

FWIW, the NEWS for 2.5.0 [1] has

o   R CMD build now takes the package name from the DESCRIPTION
file and not from the directory.  (PR#9266)

and that does seem to work on Windows.

[1] https://stat.ethz.ch/pipermail/r-announce/2007/000828.html

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] RFC: What should ?foo do?

[Deepayan Sarkar]

For what it's worth, I use ?foo mostly to look up usage of functions
that I know I want to use, and find it perfect for that (one benefit
over help() is that completion works for ?). The only thing I miss is
the ability to do the equivalent of help(foo, package = bar);
?bar::foo gives the help page for ::. Perhaps that would be
something to consider for addition.

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] autocompletion problem

[Deepayan Sarkar]

On 4/9/08, Herve Pages [EMAIL PROTECTED] wrote:

[...]

  BTW are there any plans to deal with backquoted symbols/names?
  There are currently 2 problems with this:

   1. Completion will work and expand symbols or names that contain special
  characters but without backquoting them:

xxx - as.list(11:13)
names(xxx) - letters[1:3]
names(xxx)[2] - 2b

 xxx$TABTAB# TAB stands for a hit on the Tab key
xxx$2b  xxx$a   xxx$c
 xxx$2b# I hit 2, then TAB gives me the b

 Now if I hit Enter, of course I get:

Error: unexpected numeric constant in xxx$2

   2. Completion of names after $ will not work if I've already backquoted
  the partial name:

 xxx$`2TABTABTAB...  # nothing happens

1 will be hard to ``fix'' because of limitations in the various
backends (some of which are unable to insert text before the cursor).
Also, more checks will presumably slow things down, and it's not clear
that the benefits would be worth it.

2 might be doable; I'll look into it.

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] autocompletion problem

[Deepayan Sarkar]

On 4/9/08, Herve Pages [EMAIL PROTECTED] wrote:
 Hi,

  Let's create the xxx object just to avoid confusion even if it's not 
 necessary
  for reproducing the problem below:

xxx - 8:3

  If I start typing this:

max(xxx[

  and now try to autocomplete with TAB, then I get the following error (and 
 a warning):

 max(xxx[Error in grep(sprintf(^%s, makeRegexpSafe(text)), allArgs, 
 value = TRUE) :
  invalid regular expression '^xxx['
In addition: Warning message:
In grep(sprintf(^%s, makeRegexpSafe(text)), allArgs, value = TRUE) :
  regcomp error:  'Invalid regular expression'

Thanks for the report, makeRegexpSafe was not escaping [. Does the
following workaround fix the problem (without introducing additional
ones)?

assignInNamespace(makeRegexpSafe, ns = utils, value = function(s)
{
s - gsub(., \\., s, fixed = TRUE)
s - gsub(?, \\?, s, fixed = TRUE)
s - gsub([, \\[, s, fixed = TRUE)
s - gsub(], \\], s, fixed = TRUE) # necessary?
s
})

(with 2.6.x, replace utils with rcompgen)

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R on AIX?

[Deepayan Sarkar]

On 2/14/08, Susan R. Atlas [EMAIL PROTECTED] wrote:
 Hi,
Last year our systems group tried to install R on an IBM
  p5-570 machine (16 nodes, 256 GB shared RAM), running AIX 5.3.   They
  ran into all sorts of difficulties and finally gave up.
I am interested in trying again (and working with an IBM support
  group if necessary), but before embarking on this odyssey I was
  wondering if anyone on this list has ever successfully run
  R on a similar architecture/AIX OS?   If so, is there any
  kind of cribsheet or other underground documentation that we could
  consult to get around any AIX peculiarities?

Have you read the R Installation and Administration manual? [1] It
has a couple of paragraphs on AIX and suggests that installing R
should be possible at least on AIX 5.x 'powerpc'.

-Deepayan

[1] http://cran.us.r-project.org/doc/manuals/R-admin.html

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Surprising behaviour of levelplot in lattice package

[Deepayan Sarkar]

On 2/13/08, Deepayan Sarkar [EMAIL PROTECTED] wrote:
 On 2/13/08, Wolfgang Huber [EMAIL PROTECTED] wrote:
  Hi Deepayan,
 
  levelplot from the lattice package produces a peculiar output when
  called on a matrix whose column or row names contained duplicated
  elements. In particular, the plot contains white stripes, and the
  arrangement of data regions and axes labels seems messed up. I did not
  see this documented (my apologies if this is an oversight) and guess
  that it is unintended:

 Yes, the current design does not anticipate the possibility of
 duplicated row and column names. A fix may or may not be simple; I
 will look into it.

Actually, the fix should be easy. A workaround is

levelplot(m, ylim = colnames(m), xlim = rownames(m))

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Surprising behaviour of levelplot in lattice package

[Deepayan Sarkar]

On 2/13/08, Wolfgang Huber [EMAIL PROTECTED] wrote:
 Hi Deepayan,

 levelplot from the lattice package produces a peculiar output when
 called on a matrix whose column or row names contained duplicated
 elements. In particular, the plot contains white stripes, and the
 arrangement of data regions and axes labels seems messed up. I did not
 see this documented (my apologies if this is an oversight) and guess
 that it is unintended:

Yes, the current design does not anticipate the possibility of
duplicated row and column names. A fix may or may not be simple; I
will look into it.

-Deepayan




 library(lattice)
 m = matrix(runif(12L), ncol=3L)
 colnames(m) = c(A, A, B)
 rownames(m) = c(x, y, y, z)
 print(levelplot(m))



 Best wishes
  Wolfgang

 --
 Wolfgang Huber  EBI/EMBL  Cambridge UK  http://www.ebi.ac.uk/huber



  sessionInfo()
 R version 2.7.0 Under development (unstable) (2008-02-13 r44450)
 x86_64-unknown-linux-gnu

 locale:
 LC_CTYPE=it_IT.UTF-8;LC_NUMERIC=C;LC_TIME=it_IT.UTF-8;LC_COLLATE=it_IT.UTF-8;LC_MONETARY=it_IT.UTF-8;LC_MESSAGES=it_IT.UTF-8;LC_PAPER=it_IT.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=it_IT.UTF-8;LC_IDENTIFICATION=C

 attached base packages:
 [1] stats graphics  grDevices utils datasets  methods   base

 other attached packages:
 [1] lattice_0.17-4 fortunes_1.3-4

 loaded via a namespace (and not attached):
 [1] grid_2.7.0
 

 __
 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] interactive graphics devices

[Deepayan Sarkar]

On 12/18/07, Byron Ellis [EMAIL PROTECTED] wrote:
 I probably missed this discussion, but why not just ASK the device if
 it is interactive?

That's done if the device is open. deviceIsInteractive() takes away
the guessing even when it's not (the use-case is when you type
example(something) without a device open, and R has to decide whether
to set par(ask = TRUE) just by looking at getOption(device)).

 I can easily imagine a case where a device might be
 interactive or not depending on how it was started. In fact, I don't
 have to imagine a case since the Quartz device in R-devel can have
 exactly this behavior. Something like a Cairo device might also have
 this behavior, though I don't know if the current Cairo devices
 support it.

If there's ambiguity, you can choose not to use deviceIsInteractive.
You'll still be OK once the device is open (I don't think there's much
more that can be done).

-Deepayan


 On Dec 18, 2007 4:34 PM, Paul Murrell [EMAIL PROTECTED] wrote:
  Hi
 
  For all developers of add-on graphics devices:  please note the
  existence of deviceIsInteractive() for adding your device to the list of
  devices for which dev.interactive() returns TRUE.  (Available since R
  2.6.0;  thanks to Brian Ripley I think)
 
  Paul
  --
  Dr Paul Murrell
  Department of Statistics
  The University of Auckland
  Private Bag 92019
  Auckland
  New Zealand
  64 9 3737599 x85392
  [EMAIL PROTECTED]
  http://www.stat.auckland.ac.nz/~paul/
 
  __
  R-devel@r-project.org mailing list
  https://stat.ethz.ch/mailman/listinfo/r-devel
 



 --
 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] available.packages() not accurate?

[Deepayan Sarkar]

On 12/18/07, hadley wickham [EMAIL PROTECTED] wrote:
  pkgs - 
  as.data.frame(available.packages(contrib.url(http://cran.r-project.org;)))
  pkgs[sn, c(Package, Version)]

 But looking at http://cran.r-project.org/src/contrib/ only sn_0.4-2 is
 available.  Any ideas?

I see 0.4-4. Could be a caching problem on your browser.

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] available.packages() not accurate?

[Deepayan Sarkar]

On 12/18/07, hadley wickham [EMAIL PROTECTED] wrote:
 On 12/18/07, Deepayan Sarkar [EMAIL PROTECTED] wrote:
  On 12/18/07, hadley wickham [EMAIL PROTECTED] wrote:
pkgs - 
as.data.frame(available.packages(contrib.url(http://cran.r-project.org;)))
pkgs[sn, c(Package, Version)]
  
   But looking at http://cran.r-project.org/src/contrib/ only sn_0.4-2 is
   available.  Any ideas?
 
  I see 0.4-4. Could be a caching problem on your browser.

 Oh sorry - I explained it the wrong way around - available.packages
 lists 0.4-2 as the latest version, but 0.4-4 is available from
 src/contrib.  The following packages also have a version mismatch
 between available.packages and CRAN:

 GOSim (1.0.2), GammaTest (2.1), InfNet (0.1), RcppTemplate (5.2),
 SNPassoc (1.4-8), StoppingRules (1.1), actuar (0.9-3), ape (2.0-1),
 bcp (1.7.2), dtw (0.3-1), edci (1.0-1), gstat (0.9-40), kappalab
 (0.4-0), mlegp (1.1), polycor (0.7-3), pwt (6.1-1), rcompletion
 (0.1-2), relaimpo (1.2-2), roblm (0.6), seewave (1.4.3), sfsmisc
 (0.95-13)

I see

 pkgs - 
 as.data.frame(available.packages(contrib.url(http://cran.r-project.org;)))
 pkgs[c(sn, GOSim, GammaTest), c(Package, Version)]
  Package Version
sn sn   0.4-4
GOSim   GOSim   1.1.2
NA   NANA

which match CRAN (which doesn't have GammaTest). So not sure what's going on.

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Defaults for postscript()

[Deepayan Sarkar]

On 12/6/07, Prof Brian Ripley [EMAIL PROTECTED] wrote:
 The defaults for postscript()

 paper = default
 onefile = TRUE
 horizontal = TRUE

 (it seems) date from the days when people used to used this to send plots
 directly to a postscript printer via print.it=TRUE.  I haven't done that
 for years, and it seems that our current generation of students don't even
 know the concept.  It seems 'horizontal = TRUE' is particularly difficult
 to grasp.

 Given that I suspect almost all uses of postscript() are to produce plots
 to be viewed on-screen or incorporated into another document, a more
 appropriate set of defaults would be

 width = 7, height = 7
 paper = special
 onefile = FALSE
 horizontal = FALSE

 which would have the advantage of using the same default aspect ratio for
 plots as all (?) other R graphics devices.

 Does anyone see a reason not to change the defaults?

I'm not so sure about the 'onefile' change. Scripts with multiple
plots run in batch mode will end up with multiple files; I prefer the
current behaviour. I also have test scripts in packages that go


postscript(something.ps)
many examples
dev.off()


Unless I change all these to have onefile=TRUE, I'll end up only with
the last plot available after the tests are run.

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Friday question: negative zero

[deepayan . sarkar]

On 8/31/07, Duncan Murdoch [EMAIL PROTECTED] wrote:
 The IEEE floating point standard allows for negative zero, but it's hard
 to know that you have one in R.  One reliable test is to take the
 reciprocal.  For example,
 
   y - 0
   1/y
 [1] Inf
   y - -y
   1/y
 [1] -Inf
 
 The other day I came across one in complex numbers, and it took me a
 while to figure out that negative zero was what was happening:
 
x - complex(real = -1)
x
 [1] -1+0i
1/x
 [1] -1+0i
x^(1/3)
 [1] 0.5+0.8660254i
(1/x)^(1/3)
 [1] 0.5-0.8660254i
 
 (The imaginary part of 1/x is negative zero.)
 
 As a Friday question:  are there other ways to create and detect
 negative zero in R?
 
 And another somewhat more serious question:  is the behaviour of
 negative zero consistent across platforms?  (The calculations above were
 done in Windows in R-devel.)

No, I get

 1/ Im(1/complex(real = -1))
[1] Inf
 sessionInfo()
R version 2.6.0 Under development (unstable) (2007-08-16 r42532) 
x86_64-unknown-linux-gnu 

This is on an AMD 64, and I get -Inf on everything else I've tried so far, 
which are all Intel. 

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] aesthetics of do.call

[deepayan . sarkar]

On 8/20/07, Vincent Carey 525-2265 [EMAIL PROTECTED] wrote:


 library(MASS)
 G1 = glm(sp~CW, data=crabs, fam=binomial)
 G2 = do.call(glm, list(sp~CW, family=binomial, data=crabs))

 G1$call is very nice to look at
 G2$call is very voluminous

 if we revise do.call to

 function (what, args, quote = FALSE, envir = parent.frame())
 {
 if (!is.list(args))
 stop(second argument must be a list)
 if (quote) {
 enquote - function(x) as.call(list(as.name(quote),
 x))
 args - lapply(args, enquote)
 }
 ans = .Internal(do.call(what, args, envir))
 ans$call = match.call()
 ans
 }

 G1 and G2 look a lot more alike

But then you get things like

 do.call(c, list(1, 2, 3))
[[1]]
[1] 1

[[2]]
[1] 2

[[3]]
[1] 3

$call
do.call2(what = c, args = list(1, 2, 3))

Warning message:
In ans$call = match.call() : Coercing LHS to a list

which is probably not what you want to happen.

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] substitute and expression

[Deepayan Sarkar]

Hi,

I'm trying to understand whether the use of substitute() is
appropriate/documented for plotmath annotation. The following two
calls give the same results:

 plot(1:10, main = expression(alpha == 1))
 do.call(plot, list(1:10, main = expression(alpha == 1)))

But not these two:

 plot(1:10, main = substitute(alpha == a, list(a = 2)))
 do.call(plot, list(1:10, main = substitute(alpha == a, list(a = 2
Error in as.graphicsAnnot(main) : object alpha not found

(as a consequence, xyplot(..., main = substitute(alpha)) doesn't
currently work.)

On the other hand, this works:

 foo - function(x) plot(1, main = x)
 foo(substitute(alpha))

I'm not sure how to interpret ?plotmath; it says

 If the 'text' argument to one of the text-drawing functions
 ('text', 'mtext', 'axis', 'legend') in R is an expression, the
 argument is interpreted as a mathematical expression...

and uses substitute() in its examples, but

 is.expression(substitute(alpha == a, list(a = 1)))
[1] FALSE

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute and expression

[Deepayan Sarkar]

On 7/16/07, Peter Dalgaard [EMAIL PROTECTED] wrote:
 Deepayan Sarkar wrote:
  Hi,
 
  I'm trying to understand whether the use of substitute() is
  appropriate/documented for plotmath annotation. The following two
  calls give the same results:
 
 
  plot(1:10, main = expression(alpha == 1))
  do.call(plot, list(1:10, main = expression(alpha == 1)))
 
 
  But not these two:
 
 
  plot(1:10, main = substitute(alpha == a, list(a = 2)))
  do.call(plot, list(1:10, main = substitute(alpha == a, list(a = 2
 
  Error in as.graphicsAnnot(main) : object alpha not found
 
  (as a consequence, xyplot(..., main = substitute(alpha)) doesn't
  currently work.)
 
  On the other hand, this works:
 
 
  foo - function(x) plot(1, main = x)
  foo(substitute(alpha))
 
 
  I'm not sure how to interpret ?plotmath; it says
 
   If the 'text' argument to one of the text-drawing functions
   ('text', 'mtext', 'axis', 'legend') in R is an expression, the
   argument is interpreted as a mathematical expression...
 
  and uses substitute() in its examples, but
 
 
  is.expression(substitute(alpha == a, list(a = 1)))
 
  [1] FALSE
 
 I think you need to take plotmath out of the equation and study the
 difference between objects of mode call and those of mode
 expression. Consider this:

   f - function(...)match.call()
   do.call(f, list(1:10, main = substitute(alpha == a, list(a = 2
 function(...)match.call()
 (1:10, main = alpha == 2)
   do.call(list, list(1:10, main = substitute(alpha == a, list(a = 2
 Error in do.call(list, list(1:10, main = substitute(alpha == a, list(a =
 2 :
 object alpha not found

 The issue is that function ends up with an argument  alpha == 2 which it
 proceeds to evaluate (lazily), where a direct call sees
 substitute(.). It is a general problem with the do.call mechanism
 that it effectively pre-evaluates the argument list, which can confuse
 functions that rely on accessing the original argument expression. Try,
 e.g., do.call(plot, list(airquality$Wind, airquality$Ozone)) and watch
 the axis labels.

Right. Lazy evaluation was the piece I was missing.

 Does it work if you use something like

  main = substitute(quote(alpha == a), list(a = 2))?

Not for xyplot, though I haven't figured out why. Turns out this also
doesn't work:

 plot(y ~ x, data = list(x = 1:10, y = 1:10), main = substitute(alpha))
Error in as.graphicsAnnot(main) : object alpha not found

I'll take this to mean that the fact that substitute() works sometimes
(for plotmath) is an undocumented side effect of the implementation
that should not be relied upon.

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] parse(text=...) and the srcfile attribute

[Deepayan Sarkar]

On 7/12/07, Gabor Grothendieck [EMAIL PROTECTED] wrote:
 You can do this:

  [EMAIL PROTECTED]
 [1] \na - 1; b - 2**2\na + b\n

  # or this
  as.character(foo)
 [1] a - 1   b - 2^2 a + b

Neither of which is what I want. I want

 sapply(attr(foo, srcref), as.character)
[1] a - 1b - 2**2 a + b

but was hoping for a better way than this.

-Deepayan


 On 7/12/07, Deepayan Sarkar [EMAIL PROTECTED] wrote:
  Hi,
 
  I'm trying to understand whether the new source file references can
  help me with something I want to do. Let's say I have
 
  foo - parse(text = 
  a - 1; b - 2**2
  a + b
  )
 
  I now wish to recover the sources for the parsed expressions. I can
  get them one at a time:
 
   foo[[2]]
  b - 2^2
   as.character(attr(foo, srcref)[[2]])
  [1] b - 2**2
 
  Is there a better way? Perhaps like the print method
 
   as.character(foo, useSource = TRUE)
 
  could give all the sources at once?
 
  -Deepayan
 
  __
  R-devel@r-project.org mailing list
  https://stat.ethz.ch/mailman/listinfo/r-devel
 


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] parse(text=...) and the srcfile attribute

[Deepayan Sarkar]

Hi,

I'm trying to understand whether the new source file references can
help me with something I want to do. Let's say I have

foo - parse(text = 
a - 1; b - 2**2
a + b
)

I now wish to recover the sources for the parsed expressions. I can
get them one at a time:

 foo[[2]]
b - 2^2
 as.character(attr(foo, srcref)[[2]])
[1] b - 2**2

Is there a better way? Perhaps like the print method

 as.character(foo, useSource = TRUE)

could give all the sources at once?

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] HTML vignette browser

[Deepayan Sarkar]

On 6/5/07, Friedrich Leisch [EMAIL PROTECTED] wrote:
  On Mon, 04 Jun 2007 11:52:51 -0700,
  Robert Gentleman (RG) wrote:

Deepayan Sarkar wrote:
On 6/4/07, Seth Falcon [EMAIL PROTECTED] wrote:
Friedrich Leisch [EMAIL PROTECTED] writes:
Looks good to me, and certainly something worth being added to R.
   
2 quick (related) comments:
   
1) I am not sure if we want to include links to the Latex-Sources by
default, those might confuse unsuspecting novices a lot. Perhaps
make those optional using an argument to browseVignettes(), which
is FALSE by default?
I agree that the Rnw could confuse folks.  But I'm not sure it needs
to be hidden or turned off by default...  If the .R file was also
included then it would be less confusing I suspect as the curious
could deduce what Rnw is about by triangulation.
   
2) Instead links to .Rnw files we may want to include links to the R
code - should we R CMD INSTALL a tangled version of each vignette
such that we can link to it? Of course it is redundant information
given the .Rnw, but we also have the help pages in several formats
ready.
Including, by default, links to the tangled .R code seems like a
really nice idea.  I think a lot of users who find vignettes don't
realize that all of the code used to generate the entire document is
available to them -- I just had a question from someone who wanted to
know how to make a plot that appeared in a vignette, for example.
   
I agree that having a Stangled .R file would be a great idea (among
other things, it would have the complete code, which many PDFs will
not).
   
I don't have a strong opinion either way about linking to the .Rnw
file. It should definitely be there if the PDF file is absent (e.g.
for grid, and other packages installed with --no-vignettes, which I
always do for local installation). Maybe we can keep them, but change
the name to something more scary than source, e.g. LaTeX/Noweb
source.

   I would very much prefer to keep the source, with some name, scary or
not...

 I have no strong opinion eitehr way, just source may have a lot of
 people belive that is R code - whatever scary name is chosen sounds
 good to me.

 I'll have a shot at installing the tangled code later this week (there
 is a holiday coming up on Thursday).

Great. Assuming that this will involve .../Meta/vignette.rds getting a
new column similar to PDF, the code changes in browseVignette()
should be minimal. I'll work on a .Rd file.

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] HTML vignette browser

[Deepayan Sarkar]

On 6/4/07, Seth Falcon [EMAIL PROTECTED] wrote:
 Friedrich Leisch [EMAIL PROTECTED] writes:
  Looks good to me, and certainly something worth being added to R.
 
  2 quick (related) comments:
 
  1) I am not sure if we want to include links to the Latex-Sources by
 default, those might confuse unsuspecting novices a lot. Perhaps
 make those optional using an argument to browseVignettes(), which
 is FALSE by default?

 I agree that the Rnw could confuse folks.  But I'm not sure it needs
 to be hidden or turned off by default...  If the .R file was also
 included then it would be less confusing I suspect as the curious
 could deduce what Rnw is about by triangulation.

  2) Instead links to .Rnw files we may want to include links to the R
 code - should we R CMD INSTALL a tangled version of each vignette
 such that we can link to it? Of course it is redundant information
 given the .Rnw, but we also have the help pages in several formats
 ready.

 Including, by default, links to the tangled .R code seems like a
 really nice idea.  I think a lot of users who find vignettes don't
 realize that all of the code used to generate the entire document is
 available to them -- I just had a question from someone who wanted to
 know how to make a plot that appeared in a vignette, for example.

I agree that having a Stangled .R file would be a great idea (among
other things, it would have the complete code, which many PDFs will
not).

I don't have a strong opinion either way about linking to the .Rnw
file. It should definitely be there if the PDF file is absent (e.g.
for grid, and other packages installed with --no-vignettes, which I
always do for local installation). Maybe we can keep them, but change
the name to something more scary than source, e.g. LaTeX/Noweb
source.

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] HTML vignette browser

[Deepayan Sarkar]

On 6/4/07, Prof Brian Ripley [EMAIL PROTECTED] wrote:
 Folks,

 I think this is a nice idea (and not very different to somethign I have
 bene playing with), but with lots of CHARSXP changes pending I'd
 like to come back to it next week or so.

 Sorry, Deepayan, you've happened to hit a very busy stage in R
 development.

No problem.

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] HTML vignette browser

[Deepayan Sarkar]

Hi,

this is tangentially related to the recent discussion on vignettes.
vignette() currently produces a listing of available vignettes, but
these are not clickable. Since R has a browseURL() function, it seems
natural to have a version that produces HTML with clickable links.
Here's an attempt at that:

source(http://dsarkar.fhcrc.org/R/vignette-browser.R;)
browseVignettes()
browseVignettes(package = grid)

etc. Perhaps some variant of this could be added to R.

Comments welcome.

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Calling R_PolledEvents from R_CheckUserInterrupt

[Deepayan Sarkar]

On 5/5/07, Luke Tierney [EMAIL PROTECTED] wrote:

[...]

 However, R_PolledEvents is only called from a limited set of places
 now (including the socket reading code to keep things responsive
 during blocking reads).  But it is not called from the interupt
 checking code, which means if a user does something equivalent to

 while (TRUE) {}

 there is not point where events get looked at to see a user interrupt
 action. The current definition of R_CheckUserInterrupt is

 void R_CheckUserInterrupt(void)
 {
  R_CheckStack();
  /* This is the point where GUI systems need to do enough event
 processing to determine whether there is a user interrupt event
 pending.  Need to be careful not to do too much event
 processing though: if event handlers written in R are allowed
 to run at this point then we end up with concurrent R
 evaluations and that can cause problems until we have proper
 concurrency support. LT */
 #if  ( defined(HAVE_AQUA) || defined(Win32) )
  R_ProcessEvents();
 #else
  if (R_interrupts_pending)
  onintr();
 #endif /* Win32 */
 }

 So only on Windows or Mac do we do event processing.  We could add a
 R_PolledEvents() call in the #else bit to support this, though the
 cautions in the comment do need to be kept in mind.

I have been using the following patch to src/main/errors.c for a while
without any obvious ill effects. Could we add this to r-devel (with
necessary changes for Windows, if any)?

-Deepayan

Index: errors.c
===
--- errors.c(revision 41764)
+++ errors.c(working copy)
@@ -39,6 +39,8 @@
 #include R_ext/GraphicsEngine.h /* for GEonExit */
 #include Rmath.h /* for imax2 */

+#include R_ext/eventloop.h
+
 #ifndef min
 #define min(a, b) (ab?a:b)
 #endif
@@ -117,6 +119,8 @@
 #if  ( defined(HAVE_AQUA) || defined(Win32) )
 R_ProcessEvents();
 #else
+R_PolledEvents();
 if (R_interrupts_pending)
onintr();
 #endif /* Win32 */

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] feature request for page() and options()

[Deepayan Sarkar]

Hi,

I have been playing around with a Qt based pager. One of the things I
would like to be able to do is syntax highlighting for R code. This is
mostly relevant with the page function, e.g.

page(ls)

The problem in this case is that the pager has no way of knowing
whether the file it is showing contains R code (e.g. page(,
method=print) need not produce valid R code); the name of the file
is always produced by tempfile(Rpage.), so it looks like
/tmp/RtmpQfmyH8/Rpage.4a43d33f.

A simple solution is to use an appropriate file extension. Here's a
trivial patch that implements this:

Index: src/library/utils/R/page.R
===
--- src/library/utils/R/page.R  (revision 41765)
+++ src/library/utils/R/page.R  (working copy)
@@ -19,10 +19,12 @@
 } else {
 subx - deparse(substitute(x))
 }
-file - tempfile(Rpage.)
-if(match.arg(method) == dput)
+if(match.arg(method) == dput) {
+file - sprintf(%s.R, tempfile(Rpage.))
 local.dput(x, file, ...)
+}
 else {
+file - sprintf(%s.txt, tempfile(Rpage.))
 sink(file)
 local.print(x, ...)
 sink()

Unless there is a downside (or a better solution), I would like to see
this feature added.


My second feature request is a bit more involved. options(pager) can
be a function, which is how I have implemented my pager. I would like
options(browser) and options(editor) to behave similarly, i.e. to
have them be settable to functions as well. This seems to allow more
flexibility, be consistent with S philosophy, and there shouldn't be
any incompatibility as the defaults do not change.

This needs changes in a few different places, but if the idea seems
acceptable, I am happy to supply a patch (I have a working
implementation).

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] regexp bug in very recent r-devel

[Deepayan Sarkar]

completion is semi-broken in today's r-devel, and the reason seems to
be some regular expression changes:

 sessionInfo()
R version 2.6.0 Under development (unstable) (2007-05-22 r41673)
i686-pc-linux-gnu

locale:
[...]

attached base packages:
[1] stats graphics  grDevices utils datasets  methods
[7] base
 regexpr(o, foo, fixed = TRUE)
[1] 2
attr(,match.length)
[1] 1
 gregexpr(o, foo, fixed = FALSE)
[[1]]
[1] 2 3
attr(,match.length)
[1] 1 1

 gregexpr(o, foo, fixed = TRUE)

 *** caught segfault ***
address 0xc022fdab, cause 'memory not mapped'

Traceback:
 1: gregexpr(o, foo, fixed = TRUE)

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace

On a different machine, this freezes R for a long time, consuming CPU
cycles and a lot of memory, before returning an error:

 gregexpr(o, foobar, fixed = TRUE)
Error in gregexpr(o, foobar, fixed = TRUE) :
negative length vectors are not allowed
 sessionInfo()
R version 2.6.0 Under development (unstable) (2007-05-22 r41675)
x86_64-unknown-linux-gnu

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] dev.interactive() changes

[Deepayan Sarkar]

On 5/5/07, Prof Brian Ripley [EMAIL PROTECTED] wrote:

[...]

 You meam as in

  o  dev.interactive() regards devices with the displaylist enabled
 as interactive, and packages can register the names of their
 devices as interactive via deviceIsInteractive().

 ?

Quick follow up: the displaylist based detection is working well, but
deviceIsInteractive() gives me an error:

 deviceIsInteractive(QT)
Error in deviceIsInteractive(QT) : cannot change value of locked
binding for '.known_interactive.devices'
 sessionInfo()
R version 2.6.0 Under development (unstable) (2007-05-21 r41658)
i686-pc-linux-gnu

This happens interactively as well as in package loading code.

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel