Examples failing on r-devel on linux `unused argument (std.nox = std.nox)`
Opened this issue · 13 comments
Both tidySEM and lavaanExtra are currently experiencing the error below on CRAN, but only on r-devel on linux. Because I have a Windows machine, it's a bit harder to troublehsoot.
> summary(res)
Error in lav_object_summary(object = object, header = header, fit.measures = fit.measures, :
unused argument (std.nox = std.nox)
Calls: summary -> summary -> .locallav_object_summary() is a function from lavaan, but their own CRAN checks don't fail. This seems to be due to an update in lavaan from 2 days ago. Let me know if you find the solution.
However, further testing on Windows reveals that this bug seems due to loading tidySEM:
library(lavaan)
packageVersion("lavaan")
#> [1] '0.6.18'
HS.model <- ' visual =~ x1 + x2 + x3
textual =~ x4 + x5 + x6
speed =~ x7 + x8 + x9 '
fit <- sem(HS.model, data = HolzingerSwineford1939)
out <- summary(fit, fit.measures = TRUE)
library(tidySEM)
packageVersion("tidySEM")
#> [1] '0.2.7'
out <- summary(fit, fit.measures = TRUE)
#> Error in lav_object_summary(object = object, header = header, fit.measures = fit.measures, : unused argument (std.nox = std.nox)Created on 2024-06-09 with reprex v2.1.0
Could this be related to the changes in namespacing in #93? 🤔 Definitely similar to #88
I see no errors when I follow your links.. false positive?
This is probably related to an issue with the latest update of lavaan that says "the ‘std.nox’ argument is no longer used in parameterEstimates()/summary() (but can be set in standardized= instead)"
So, ight be that some code in tidySEM is still looking for std.nox
@maugavilla do you see errors?
I see no errors when I follow your links.. false positive?
You are right! It's gone now. Sorry for the false alarm. Strange.
However, locally I still get the error. I tried redownloading (again) fresh versions of both lavaan and tidySEM, and the reprex still holds. Can you try it?
It seems there is at least one other user who could fix this error by unloading tidySEM before running lavaan::sem().
Downgrading the lavaan version to the preceding version fixes the issue:
library(lavaan)
packageVersion("lavaan")
#> [1] '0.6.17'
HS.model <- ' visual =~ x1 + x2 + x3
textual =~ x4 + x5 + x6
speed =~ x7 + x8 + x9 '
fit <- sem(HS.model, data = HolzingerSwineford1939)
out <- summary(fit, rsquare= TRUE, fit.measures = TRUE)
library(tidySEM)
packageVersion("tidySEM")
#> [1] '0.2.7'
out <- summary(fit, fit.measures = TRUE)Created on 2024-06-10 with reprex v2.1.0
So it seems like a newly emerged incompatiblity between lavaan and tidySEM.
I cant reproduce the error either. With the either version of lavaan
Now, looking into which function is giving the error (av_object_summary), that is an internal function from lavaan. So, I think the error with some issues of the update of lavaan. And this is only happending in linux, right? I think you should comment this on the lavaan forum/github
After updating lavaan, I also get the error on my windows system. We're not modifying summary() from lavaan, so I think the problem is internal to lavaan.
Is there something different in our sessioninfo() ? because the latest version works well in my windows
`> sessionInfo()
R version 4.4.0 (2024-04-24 ucrt)
Platform: x86_64-w64-mingw32/x64
Running under: Windows 11 x64 (build 22631)
Matrix products: default
locale:
[1] LC_COLLATE=English_Netherlands.utf8 LC_CTYPE=English_Netherlands.utf8 LC_MONETARY=English_Netherlands.utf8
[4] LC_NUMERIC=C LC_TIME=English_Netherlands.utf8
time zone: Europe/Amsterdam
tzcode source: internal
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] lavaan_0.6-18 tidySEM_0.2.7 OpenMx_2.21.11
loaded via a namespace (and not attached):
[1] gtable_0.3.5 ggplot2_3.5.1 QuickJSR_1.2.2 psych_2.4.3 inline_0.3.19
[6] CompQuadForm_1.4.3 lattice_0.22-6 quadprog_1.5-8 vctrs_0.6.5 tools_4.4.0
[11] generics_0.1.3 stats4_4.4.0 parallel_4.4.0 sandwich_3.1-0 tibble_3.2.1
[16] fansi_1.0.6 MplusAutomation_1.1.1 pkgconfig_2.0.3 proto_1.0.0 Matrix_1.7-0
[21] data.table_1.15.4 checkmate_2.3.1 RcppParallel_5.1.7 tmvnsim_1.0-2 lifecycle_1.0.4
[26] compiler_4.4.0 munsell_0.5.1 mnormt_2.1.1 codetools_0.2-20 carData_3.0-5
[31] bayesplot_1.11.1 car_3.1-2 pillar_1.9.0 MASS_7.3-60.2 dbscan_1.1-12
[36] gsubfn_0.7 StanHeaders_2.32.9 abind_1.4-5 boot_1.3-30 nlme_3.1-164
[41] parallelly_1.37.1 rstan_2.32.6 tidyselect_1.2.1 digest_0.6.35 mvtnorm_1.2-5
[46] future_1.33.2 listenv_0.9.1 nonnest2_0.5-7 dplyr_1.1.4 pander_0.6.5
[51] grid_4.4.0 colorspace_2.1-0 cli_3.6.2 magrittr_2.0.3 loo_2.7.0
[56] fastDummies_1.7.3 pkgbuild_1.4.4 utf8_1.2.4 future.apply_1.11.2 pbivnorm_0.6.0
[61] scales_1.3.0 backports_1.5.0 httr_1.4.7 globals_0.16.3 matrixStats_1.3.0
[66] igraph_2.0.3 gridExtra_2.3 progressr_0.14.0 RANN_2.6.1 zoo_1.8-12
[71] coda_0.19-4.1 rstantools_2.4.0 rlang_1.1.3 Rcpp_1.0.12 xtable_1.8-4
[76] glue_1.7.0 blavaan_0.5-5 rstudioapi_0.16.0 R6_2.5.1 plyr_1.8.9
[81] bain_0.2.10 texreg_1.39.3 `
@rempsyc Confirmed that the problem originates in lavaan, not tidySEM. Please do not advise people to unload tidySEM, instead refer them to the solution here: yrosseel/lavaan#359 (comment)
See here for some additional background.
The latest blavaan just went to CRAN, and it can take a couple days for all the binaries to be available. So my guess is that the older blavaan was still active on the Linux check that failed, which is why running it later did not reproduce the same error.
For your local test, try (re)installing the latest version of blavaan, which should avoid magically loading lavaan's old summary() method. Note that @maugavilla's sessionInfo() shows he has the latest blavaan, and he does not get the error. So hopefully that works for you, @rempsyc.
Hi, sorry for the delay. I confirm that updating blavaan locally fixed the issue for me. The reason I was confused was that my GitHub action workflows were also failing with this error despite installing the latest CRAN versions of all packages, but this could be explained by what Terrence mentioned about the binaries taking a couple days to be available. Consistent with that, I just ran the workflows again now and they pass. Thank you for providing the solution! I updated the answer on stackoverflow accordingly (sorry about that, Caspar). Thanks all. So I think this issue can be closed now?
You're good, thanks for doing that ;)