Strange magrittr %>% problem

[sebsilas]

Hey @pmcharrison,

@KilianSander and I discovered some weird behaviour when using the magrittr pipe and calling new_timeline. Consider:

# Load the psychTestR package
library(psychTestR)

# Define a dictionary with a typo
my_dict <- i18n_dict$new(data.frame(key = "key1",
                                    en = "Welcoom to the test!",
                                    de = "Willkoommen zum Test")) # We also like typos

# Composing new_timline in the standard way => expected results
tl_good <- new_timeline(
  list(final_page(i18n("key1"))),
  dict = my_dict
)

# With some base R sugary syntax => expected results
tl_good2 <- list(final_page(i18n("key1"))) |> 
  new_timeline(dict = my_dict)

# With some magrittr sugary syntax => we have a problem
tl_bad <- list(final_page(i18n("key1"))) %>% 
  new_timeline(dict = my_dict)

make_test(tl_good,
          opt = test_options(title = "Test",
                             admin_password = "hi",
                             languages = "de"))

The first two cases (tl_good, tl_good2) work when used as a call to make_test, but not the third (tl_bad). The magrittr pipe seems to break psychTestR's ability to do translations properly.

Indeed:

all.equal(tl_good, tl_good2)

TRUE

all.equal(tl_good, tl_bad)

FALSE

Internally in new_timeline, comparing how tl_good and tl_bad run, things seem to be the same, at least up until just before:

psychTestR::timeline$new(res)

is called. Or maybe it's to do with the finally block?

Or perhaps this is just a magrittr issue? In any case, just making you aware.

@klausfrieler You'll probably find this one fun.

All the best,
Seb

[pmcharrison]

Oof, sounds nasty! I'm sorry about that. new_timeline uses some hairy macros to make i18n work the way it does, and I kind of regret it. I think it makes order of evaluation matter, and that presumably differs between the pipes. I don't quite understand it though and would have to look carefully to figure it out...

[pmcharrison]

Hi @sebsilas, I now checked this and couldn't reproduce any issues, tl_bad works fine for me just like tl_good. Could it be that you are using an old version of magrittr? I remember there was an update a while ago that changed the order of evaluation and I vaguely remember that this resolved this kind of problem.

[sebsilas]

Hi @pmcharrison, we actually already checked that and I do have the latest version here (2.0.3).

Here's my full session info:

R version 4.3.0 (2023-04-21)
Platform: x86_64-apple-darwin20 (64-bit)
Running under: macOS Ventura 13.7.1

Matrix products: default
BLAS:   /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 
LAPACK: /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libRlapack.dylib;  LAPACK version 3.11.0

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: UTC
tzcode source: internal

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

other attached packages:
[1] shiny_1.10.0        psychTestR_2.27.3   musicassessr_2.11.2 psych_2.4.6.26     
[5] itembankr_0.5.1     devtools_2.4.5      usethis_2.2.3      

loaded via a namespace (and not attached):
  [1] rstudioapi_0.16.0    jsonlite_1.8.9       magrittr_2.0.3      
  [4] nloptr_2.1.1         fs_1.6.5             vctrs_0.6.5         
  [7] pyin_0.1.0           memoise_2.0.1        minqa_1.2.7         
 [10] RCurl_1.98-1.14      htmltools_0.5.8.1    signal_1.8-1        
 [13] cellranger_1.1.0     sjmisc_2.8.10        sass_0.4.9          
 [16] parallelly_1.37.1    bslib_0.8.0          htmlwidgets_1.6.4   
 [19] desc_1.4.3           testthat_3.2.1.1     zoo_1.8-12          
 [22] lubridate_1.9.3      cachem_1.1.0         changepoint_2.2.4   
 [25] commonmark_1.9.2     mime_0.12            lifecycle_1.0.4     
 [28] pkgconfig_2.0.3      sjlabelled_1.2.0     Matrix_1.6-5        
 [31] R6_2.5.1             fastmap_1.2.0        future_1.33.2-9008  
 [34] digest_0.6.37        numDeriv_2016.8-1.1  colorspace_2.1-1    
 [37] furrr_0.3.1          rprojroot_2.0.4      pkgload_1.3.4       
 [40] vampr_0.1.0          timechange_0.3.0     httr_1.4.7          
 [43] compiler_4.3.0       proxy_0.4-27         remotes_2.5.0       
 [46] bit64_4.5.2          withr_3.0.2          backports_1.5.0     
 [49] DBI_1.2.3            pkgbuild_1.4.4       R.utils_2.12.3      
 [52] MASS_7.3-60.0.1      sessioninfo_1.2.2    tools_4.3.0         
 [55] musicassessrdb_0.4.2 httpuv_1.6.15        R.oo_1.26.0         
 [58] glue_1.8.0           nlme_3.1-164         promises_1.3.2      
 [61] grid_4.3.0           checkmate_2.3.2      generics_0.1.3      
 [64] gtable_0.3.5         tzdb_0.4.0           R.methodsS3_1.8.2   
 [67] RPostgres_1.4.7      tidyr_1.3.1          hms_1.1.3           
 [70] xml2_1.3.6           markdown_1.12        pillar_1.10.1       
 [73] psyquest_1.5.3       shinyalert_3.1.0     stringr_1.5.1       
 [76] vroom_1.6.5          later_1.4.1          logging_0.10-108    
 [79] splines_4.3.0        dplyr_1.1.4          lattice_0.22-6      
 [82] bit_4.5.0.1          tidyselect_1.2.1     miniUI_0.1.1.1      
 [85] knitr_1.49           hrep_0.16.1          xfun_0.50           
 [88] randtests_1.0.2      brio_1.1.5           DT_0.33             
 [91] stringi_1.8.4        boot_1.3-30          evaluate_1.0.1      
 [94] codetools_0.2-20     dtw_1.23-1           archive_1.1.8       
 [97] tibble_3.2.1         cli_3.6.3            shinythemes_1.2.0   
[100] xtable_1.8-4         jquerylib_0.1.4      munsell_0.5.1       
[103] tuneR_1.4.7          roxygen2_7.3.1       Rcpp_1.0.13-1       
[106] readxl_1.4.3         globals_0.16.3       parallel_4.3.0      
[109] ellipsis_0.3.2       ggplot2_3.5.1        readr_2.1.5         
[112] blob_1.2.4           profvis_0.3.8        urlchecker_1.0.1    
[115] bitops_1.0-7         lme4_1.1-35.4        listenv_0.9.1       
[118] lmerTest_3.1-3       scales_1.3.0         insight_0.20.1      
[121] purrr_1.0.2          crayon_1.5.3         seewave_2.2.3       
[124] rlang_1.1.4          mnormt_2.1.1         shinyjs_2.1.0 

[KilianSander]

Hi, I can reproduce the behaviour with the latest {magrittr} and {psychTestR} versions on a Windows 10 machine.
On the weekend, I can test it on a linux machine.

I also tried a slightly modified dictionary:

my_dict <- i18n_dict$new(data.frame(key = "key1",
                                    de = "Willkoommen zum Test", # switch `de` and `en` columns
                                    en = "Welcoom to the test!",
                                    ja = "ようこそお")) # add another language and typo

tl_bad <- list(final_page(i18n("key1"))) %>% 
  new_timeline(dict = my_dict)
make_test(tl_bad,
          opt = test_options(title = "Test",
                             admin_password = "hi",
                             languages = c("ja", "en", "de")))

This results in key1 being translated as "Willkoomen zum Test" (de) irrespective of the url parameter (e.g., ?language=en).
The three languages are supported (i.e. no Error in check_opt() the following language(s) specified in 'opt$languages' are not supported by 'elts'), but obviously only the first language column of the dictionary is used.
Removing the languages argument (make_test() defaults to languages = "en") also results in the translation "Willkoomen zum Test".

[pmcharrison]

Ah, yes, I get the same problem as @KilianSander now. So, probably not a version error after all...

[sebsilas]

@pmcharrison does my code work as expected for you but not @KilianSander's? Or did you just not e.g., check the URL parameter before when you tried my reprex? (If the former, maybe there's a clue here)

[pmcharrison]

@sebsilas maybe I just didn't know what unexpected behaviour you were referring to? I saw "Willkoommen zum Test" in all cases, which looked like correct behaviour, so I didn't proceed further. What are you referring to with the URL parameter?

[sebsilas]

@pmcharrison - no actually, for me, in my example, tl_bad returns "Welcoom to the test!" (unexpected) but the other two return "Willkoommen zum Test" (expected).

It sounds like for you, in all cases, "Willkoommen zum Test" is returned. In which case, presumably working out the difference between your and my environment/system should be the clue.

[pmcharrison]

Ah, no, I must have been mistaken. I see "Welcoom to the test" like you, and I see that this is incorrect behaviour.