search for: magrittr

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 package...

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 ho...

Dear colleagues, preparing a release of my package ?polmineR? I encountered the following issue with a new warning issued when running R CMD check with the --as-cran option on Debian with R-devel. To reexport the magrittr pipe operator %>%, my package adopted I snippet you?d see in the dplyr package, for instance: #' @importFrom magrittr %>% #' @export magrittr::`%>%` The dplyr package has many statements of this kind and I guess the pattern is common. Roxygn2 will prepare a file documenting the r...

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: x86_64-apple-darwin15.6.0 (64-bit) Running under: macOS High Sierra 10.13.3 This error did not occur under R version...

...John Mount <jmount at win-vector.com> a ?crit : > 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/ ), and for > some reason we chickened out and didn't spend time on it in the dot pipe > paper ( https://journal.r-project.org/archive/2018/RJ-2018-042/index.html > ). > > For documentation Bizarro pipe has the advantage that one can work out how > it works from...

...) [CRAN] 5: cli (3.3.0 -> 3.6.1 ) [CRAN] 6: openssl (1.4.5 -> 2.0.6 ) [CRAN] 7: curl (4.3.2 -> 5.0.0 ) [CRAN] 8: Rcpp (1.0.7 -> 1.0.10) [CRAN] 9: ps (1.6.0 -> 1.7.4 ) [CRAN] 10: processx (3.5.2 -> 3.8.0 ) [CRAN] 11: purrr (0.3.4 -> 1.0.1 ) [CRAN] 12: magrittr (2.0.1 -> 2.0.3 ) [CRAN] 13: fastmap (1.1.0 -> 1.1.1 ) [CRAN] 14: cachem (1.0.6 -> 1.0.7 ) [CRAN] 15: fs (1.5.2 -> 1.6.1 ) [CRAN] Enter one or more numbers, or an empty line to skip updates: * installing *source* package 'nser' ... ** package 'nser' successfull...

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 ( https://journal.r-project.org/archive/2018/RJ-2018-042/index.html <https://journal.r-project.org/archive/2018/RJ-2...

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 '.' placehol...

...transformPipe( a %>% b %>% c ) could convert the original expression into one like yours below. This could be done by a smart IDE like RStudio without the user typing anything. A really strong argument for doing this in a package instead of Bison/C code in the parser is the help page ?magrittr::"%>%". There are so many special cases there that it's certainly hard and possibly impossible for the parser to do the transformation: I think some parts of the transformation depend on run-time values, not syntax. Of course, a simpler operator like Antoine's would be ea...

...om> a ?crit : > >> 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/ ), and for >> some reason we chickened out and didn't spend time on it in the dot pipe >> paper ( https://journal.r-project.org/archive/2018/RJ-2018-042/index.html >> ). >> >> For documentation Bizarro pipe has the advantage that one can work out h...

On Sat, 5 Oct 2019 at 17:15, Hugh Marera <hugh.marera at gmail.com> wrote: > > 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?" Two packages with many features, dozens of functions and under heavy development to fix bugs, add new

...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 > 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...

...t ot base R I guess 1 and 6 could be held against my proposal, because : (1) everything can be done without pipes (6) They are somewhat surprising (though with explicit dots not that much, and not more surprising than say `bquote()`) In my opinion the + offset the -. I wouldn't advise taking magrittr's pipe (providing the license allows so) for instance, because it makes a lot of design choices and has a complex behavior, what I propose is 2 lines of code very unlikely to evolve or require maintenance. Antoine PS: I just receive the digest once a day so If you don't "reply all&qu...

...st() on an output from dplyr::group_by() 2) Using tibble::tibble() with <name> = <value> arguments 3) Using dplyr::select() on a tibble to select two columns Any obvious clues as to what's happening here? The only non-base packages loaded are current tidyverse, forcats, magrittr, readxl and stringr. Thanks, John John Szumiloski, Ph.D. Principal Scientist, Statistician Pharmaceutical Development / Drug Product Science & Technology NBR105-1-1411 Bristol-Myers Squibb P.O. Box 191 1 Squibb Drive New Brunswick, NJ 08903-0191 (732) 227-7167 _____________________________...

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 a regular function with a very limited impact on the stack. And if implemented as a SPECIALSXP, it would be completely invisible. We've been planning to rewrite %>% to fix the perf...

...yverse: ggplot2 Loading tidyverse: tibble Loading tidyverse: tidyr Loading tidyverse: readr Loading tidyverse: purrr Loading tidyverse: dplyr Conflicts with tidy packages -------------------------------------------------------------- filter(): dplyr, stats lag(): dplyr, stats Desktop> library(magrittr) Attaching package: ?magrittr? The following object is masked from ?package:purrr?: set_names The following object is masked from ?package:tidyr?: extract Desktop> Test <- read_csv("Test.csv") Parsed with column specification: cols( Tests1 = col_character(), Tests...

...RDER BY AB DESC") > Hack12Batting$AB [1] 664 661 639 632 632 632 626 623 620 618 617 613 606 605 602 > Hack12Batting$3B Error: unexpected numeric constant in "Hack12Batting$3" How to handle? You can rename columns on-the-fly by piping. See reference [1] and use either library(magrittr) or library(dplyr) or a combination thereof: library(magrittr) dbGetQuery(con2,"SELECT * FROM batting WHERE yearID = 2018 AND AB >600 ORDER BY AB DESC") %>% set_colnames(make.names(colnames(.))) #OR one of the following: library(dplyr) dbGetQuery(con2,"SELECT * FROM batting...

...::group_by() > >2) Using tibble::tibble() with <name> = <value> arguments > >3) Using dplyr::select() on a tibble to select two columns > >Any obvious clues as to what's happening here? The only non-base >packages loaded are current tidyverse, forcats, magrittr, readxl and >stringr. > >Thanks, >John >John Szumiloski, Ph.D. >Principal Scientist, Statistician >Pharmaceutical Development / Drug Product Science & Technology >NBR105-1-1411 > >Bristol-Myers Squibb >P.O. Box 191 >1 Squibb Drive >New Brunswick, NJ >08...

...t;>> 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 a regular function with a >> very limited impact on the stack. And if implemented as a SPECIALSXP, >> it would be completely invisible. We've been planni...

...ack12Batting$AB > [1] 664 661 639 632 632 632 626 623 620 618 617 613 606 605 602 > > Hack12Batting$3B > Error: unexpected numeric constant in "Hack12Batting$3" > > How to handle? You can rename columns on-the-fly by piping. See > reference [1] and use either library(magrittr) or library(dplyr) or a > combination thereof: > > library(magrittr) > dbGetQuery(con2,"SELECT * FROM batting WHERE yearID = 2018 AND AB >600 > ORDER BY AB DESC") %>% set_colnames(make.names(colnames(.))) > > #OR one of the following: > > library(dplyr) &g...