similar to: roxygen2 / documentation of reexports

On 16/11/2015 4:00 AM, Richard Cotton wrote: > On 22 October 2015 at 22:55, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: >> I'm planning on adding some new WebGL functionality to the rgl package, but >> it will pull in a very large number of dependencies. Since many people won't >> need it, I'd like to make the new parts optional. > >> Can

Hi John, Thanks, but the Bizzaro pipe comes with many flaws though : * It's not a single operator * It has a different precedence * It cannot be used in a subcall * The variable assigned to must be on the right * It doesn't trigger indentation when going to the line * It creates/overwrite a `.` variable in the worksace. And it doesn't deal gracefully with some lazy evaluation edge

Dear R-devel, The most popular piping operator sits in the package `magrittr` and is used by a huge amount of users, and imported /reexported by more and more packages too. Many workflows don't even make much sense without pipes nowadays, so the examples in the doc will use pipes, as do the README, vignettes etc. I believe base R could have a piping operator so packages can use a pipe in

One piece of feedback that I received at useR was that the assertive package is getting too big, and should be broken down into smaller pieces. I want to split the functionality into assertive.base, assertive.types, and a few others, then have the assertive package as a virtual package (suggestions for better terminology welcomed) that just imports and reexports the contents of the underlying

Hi, I am trying to create my first R package. I will later today put the files on Github. However I gets this error and I can't find any reason for it: R> roxygen2::roxygenise() First time using roxygen2. Upgrading automatically... Error in x$tag : $ operator is invalid for atomic vectors R> Any ideas? Regards Martin M. S. Pedersen [[alternative HTML version deleted]]

It says that nser requires the most recent version of magrittr that you do not have installed. You must update magrittr before attempting to install nser: update.packages(oldPkgs = "magrittr") or at the prompt you were presented before, choose to update magrittr before installing nser. On Sun, Apr 9, 2023, 17:55 akshay kulkarni <akshay_e4 at hotmail.com> wrote: > Dear

library("lintr") Error: package or namespace load failed for 'lintr' in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck = vI[[j]]): there is no package called 'magrittr' library("magrittr") Error in library("magrittr") : there is no package called 'magrittr' session.Info(): R version 3.4.4 (2018-03-15) Platform:

Hi, I have a machine that must to reexport glusterfs to nfs. CONFIGURATION 2 glusterfs servers | ?| ? | 1 gluterfs client 1 nfs server ?| ?| ?| 1 nfs client #*********************************************** # GLUSTERFS SERVER ?#*********************************************** # Export with glusterfs $ glusterfs -f /etc/glusterfs/glusterfs-server.vol $ cat

Dear members, I can't install "nser" package. It is not in cran but install_version and install_github both are not working: > install_version("nser",version = "1.4.0") Downloading package from url: https://cran.rstudio.com//src/contrib/Archive/nser/nser_1.4.0.tar.gz These packages have more recent versions available. It is

IMHO, if base R were to include a pipe operator, I think it should be much simpler than the magrittr pipe. It should satisfy the property that: x |> f(...) is equivalent to f(x, ...) Except, perhaps, in terms of when the promise for 'x' gets forced. We shouldn't need to mess with bindings in environments to make that work. My understanding is that the '.'

Actually, base R already has a pipe fairly close to the one you describe: ->.; iris ->.; head(.) ->.; dim(.) # [1] 6 5 I've called it the Bizarro pipe ( http://www.win-vector.com/blog/2016/12/magrittrs-doppelganger/ <http://www.win-vector.com/blog/2016/12/magrittrs-doppelganger/> ), and for some reason we chickened out and didn't spend time on it in the dot pipe paper (

On 05/10/2019 7:50 p.m., Gabriel Becker wrote: > Hi all, > > I think there's some nuance here that makes makes me agree partially with > each "side". > > The pipe is inarguably extremely popular. Many probably think of it as a > core feature of R, along with the tidyverse that (as was pointed out) > largely surrounds it and drives its popularity. Whether its

How is your argument different to, say, "Should dplyr or data.table be part of base R as they are the most popular data science packages and they are used by a large number of users?" Kind regards On Sat, Oct 5, 2019 at 4:34 PM Ant F <antoine.fabri at gmail.com> wrote: > Dear R-devel, > > The most popular piping operator sits in the package `magrittr` and is used >

Hello, R is a functional language, pipes are not. There are even higher order functions such as [1] and [2]. Besides, packages are part of R, R couldn't live without them. I find pipes a good idea but I also find it better not to have them as part of base R. If you want to use them, load a package, if you don't, don't. This simple. As for your example, compose, there is a

Thanks for the feedback Jeff. Before I pursue a bug report, let me give a full example: ###### begin console output R version 3.4.1 (2017-06-30) -- "Single Candle" Copyright (C) 2017 The R Foundation for Statistical Computing Platform: i386-w64-mingw32/i386 (32-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions.

Hi Philip, You've probably realized by now that R doesn't like column names that start with a number. If you try to access an R-dataframe column named 2B or 3B with the familiar "$" notation, you'll get an error: > library(DBI) > library(RSQLite) > con2 <- dbConnect(SQLite(), "~/R_Dir/lahmansbaseballdb.sqlite") > Hack12Batting <-

*sigh* The answer is that the large exported filesystem is a very large XFS... and at least through CentOS 6, upstream has *never* fixed an NFS bug that I find, googling, being complained about in '09: it gags on inodes > 32bit (not sure if that's signed, or unsigned, but....). The answer was to either create, or find an unneeded directory with a < 32bit inode, rename the

> > On 7 Oct 2019, at 13:47, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > > On 07/10/2019 4:22 a.m., Lionel Henry wrote: >> Hi Gabe, >>> There is another way the pipe could go into base R that could not be >>> done in package space and has the potential to mitigate some pretty >>> serious downsides to the pipes relating to debugging

This is really a feature of SQL, not R. SQL requires that you double quote column names that start with numbers, include spaces, etc., or that are SQL key words. E.g., > d <- data.frame(Order=c("sit","stay","heel"), Where=c("here","there","there"), From=c("me","me","you")) >

Hi Gabe, > There is another way the pipe could go into base R that could not be > done in package space and has the potential to mitigate some pretty > serious downsides to the pipes relating to debugging I assume you're thinking about the large stack trace of the magrittr pipe? You don't need a parser transformation to solve this problem though, the pipe could be implemented as