Closed krlmlr closed 7 months ago
Maybe it's non related, but I see in the trace that collector is called twice, which I tried to avoid, so this should be locked into as well :
traceback()
16: eval(call_to_original, new_caller_env)
15: eval(call_to_original, new_caller_env) at collector.R#116
14: collector::collect_and_run()
13: FUN(X[[i]], ...)
12: lapply(.x, .f, ...) at import-standalone-purrr.R#38
11: map(indices, dplyr_row_slice, data = data) at group-split.R#103
10: dplyr_chop(out, indices) at group-split.R#99
9: group_split_impl(.tbl, .keep = .keep) at group-split.R#85
8: group_split.grouped_df(.) at group-split.R#46
7: (function (.tbl, ..., .keep = TRUE)
{
lifecycle::signal_stage("experimental", "group_split()")
UseMethod("group_split")
})(.)
6: eval(call_to_original, new_caller_env)
5: eval(call_to_original, new_caller_env) at collector.R#116
4: collector::collect_and_run()
3: dplyr::group_split(.)
2: df %>% dplyr::group_by(edge) %>% dplyr::filter(edge %in% comparable.edges) %>%
dplyr::group_split()
1: cogmapr::RelationshipTest(my.project, units = c("Belgium", "Québec"))
No, that's fine, we have in the package :
df %>% dplyr::group_by(edge) %>% dplyr::filter(edge %in% comparable.edges) %>% dplyr::group_split()
These calls are all dplyr calls on the same stack but called from the other package's ns so we do want to record them all
We can reproduce outside of the package, group_split always fails:
iris |>
group_by(Species) |>
group_split()
#> Error in eval(call_to_original, new_caller_env) :
#> '...' used in an incorrect context
That's something with lapply(...)
,
lapply(list(cars), mutate, a = 1)
#> Error in eval(call_to_original, new_caller_env) :
#> '...' used in an incorrect context
Well, just the dots in fact :
fun <- function(...) {
mutate(cars, ...)
}
fun(a = 1)
#> Error in eval(call_to_original, new_caller_env) :
#> '...' used in an incorrect context
The code tried to make a lazy binding out of ...
, R didn't like that, If we don't try to set is as a lazy binding it removes the failure (still have to check if the value retrieval works ok).
What it means however is that we would always serialize ...
even if it's not used. I think it's ok because the dots take trivial space, they just point to bindings we keep the values from only if they're used.
Created on 2024-04-18 with reprex v2.1.0
Other packages work without error. I'll keep trying.