%>% order of execution got reversed in Version 2
Someone894 opened this issue · comments
Hello,
I'm using the %>% operator quite extensively (sometimes 10 to 20 statements in a row) and I encountered a strange behavior that brakes all my existing code. From Version 1.5 to 2.0.1 the order in which the statements are executed got reversed. Here is a example using Docker:
docker run -it --rm r-base:4.0.4 bash
Within the container:
apt-get update
apt-get install -y libcurl4-openssl-dev libssl-dev libxml2-dev
R
Within R
> install.packages("devtools")
#### TO LONG TO SHOW ####
> devtools::install_version("magrittr", version = "1.5", repos = "http://cran.us.r-project.org")
Downloading package from url: http://cran.us.r-project.org/src/contrib/Archive/magrittr/magrittr_1.5.tar.gz
#### BORING ####
* DONE (magrittr)
Save workspace image? [y/n/c]: n
root@de715ce8bb15:/# R
R version 4.0.4 (2021-02-15) -- "Lost Library Book"
Copyright (C) 2021 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (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.
> test_order <- function(){
funca <- function(a){
print("A")
print(a)
}
funcb <- function(a){
print("B")
print(a)
}
funcc <- function(a){
print("C")
print(a)
}
"W" %>%
funca %>%
funcb %>%
funcc
}
test_order()
[1] "A"
[1] "W"
[1] "B"
[1] "W"
[1] "C"
[1] "W"
> devtools::install_version("magrittr", version = "2.0.1", repos = "http://cran.us.r-project.org")
Downloading package from url: http://cran.us.r-project.org/src/contrib/magrittr_2.0.1.tar.gz
#### BORING ####
* DONE (magrittr)
>
Save workspace image? [y/n/c]: n
reload the session to get the new magrittr version going
root@de715ce8bb15:/# R
R version 4.0.4 (2021-02-15) -- "Lost Library Book"
Copyright (C) 2021 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (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(magrittr)
test_order <- function(){
funca <- function(a){
print("A")
print(a)
}
funcb <- function(a){
print("B")
print(a)
}
funcc <- function(a){
print("C")
print(a)
}
"W" %>%
funca %>%
funcb %>%
funcc
}
test_order()
[1] "C"
[1] "B"
[1] "A"
[1] "W"
[1] "W"
[1] "W"
As you can see the execution order changed from A,B,C to C,B,A.
Since my code depends on the order in which the statements come this is important to me.
Can you reproduce this behavior and is there a way to obtain the old behavior?
See the 2.0.0 release notes for the motivation (https://www.tidyverse.org/blog/2020/11/magrittr-2-0-is-here/#laziness) and workaround (https://www.tidyverse.org/blog/2020/11/magrittr-2-0-is-here/#sequential-evaluation).
Thank you for your quick reply, I’ve read those blog entries before posting the issue, I just thought they weren’t related to my topic. But it turned out I do have a tricky side effect in my code, I wasn’t aware of.
To speed up the calculation I use a multi-thread approach, where each thread gets a socket to write in a log file and I use 64 threads. As you can see here R only supports 125 sockets (= 128 - 3 (stdin, stdout, stderr)). The lazy evaluation caused the system to open up 64 sockets without performing a calculation and then opening up another 64 sockets, thus exceeding the limit and crashing.