fix: fixed an error when := assignment is used inside the code in qenv

[kpagacz]

Here is an example illustrating the problem:

# MRE
# devtools::load_all("../../teal.code")
# devtools::load_all("../../teal.data")
library(teal)
library(teal.modules.general)
library(ggplot2)
library(data.table)

iris <- data.table::data.table(iris) %>%
  .[, NewSpecies := factor(Species)]
code <- "
iris <- data.table::data.table(iris) %>%
  .[, NewSpecies := factor(Species)]
"
data <- teal.data::teal_data(iris = iris, code = code)
app <- teal::init(
  data = data,
  modules = teal::modules(
    teal.modules.general::tm_g_scatterplot(
      label = "Scatterplot",
      x = teal.transform::data_extract_spec(
        dataname = "iris",
        select = teal.transform::select_spec(
          choices = teal.transform::variable_choices("iris"),
          selected = "Sepal.Length"
        )
      ),
      y = teal.transform::data_extract_spec(
        dataname = "iris",
        select = teal.transform::select_spec(
          choices = teal.transform::variable_choices("iris"),
          selected = "Sepal.Width"
        )
      )
    )
  )
)
if (interactive()) {
  shiny::shinyApp(ui = app$ui, server = app$server)
}

This errors out with an informative:

Warning in sym_cond > ass_cond :
longer object length is not a multiple of shorter object length
Warning: Error in if: the condition has length > 1
5: runApp
4: print.shiny.appobj
2: base::source
1: nvimcom:::source.and.clean

And precludes launching the application.

After some investigation, I narrowed the issue to the fact that the custom := is unfortunately parsed by whatever teal.code uses to parse as LEFT_ASSIGNMENT token, which causes problems in these lines:

teal.code/R/utils-get_code_dependency.R

Lines 272 to 281 in 584dfc9

	ass_cond <- grep("ASSIGN", x$token)
	if (!length(ass_cond)) {
	return(c("<-", unique(x[sym_cond, "text"])))
	}
	sym_cond <- sym_cond[sym_cond > ass_cond] # NOTE 1
	# If there was an assignment operation detect direction of it.
	if (unique(x$text[ass_cond]) == "->") { # NOTE 2
	sym_cond <- rev(sym_cond)
	}

What happens is that ass_cond (great naming convention, guys) is length > 1, which means that the if at the end errors. As a simple, dirty fix, I propose a Filter on such a custom := assignment operator, which cannot be used for any real assignments:

l := 1

This does not parse in R > 3 (and probably even more ancient), so it should be OK with the rest of the function's logic, which, I gathered, tries to establish parent-child relationships between symbols using the assignment operators.

Let me know if you want me to change something, scrap it or do something else entirely.

[github-actions]

✅ All contributors have signed the CLA
_{Posted by the CLA Assistant Lite bot.}

[kpagacz]

I have read the CLA Document and I hereby sign the CLA

[m7pr]

I think I'd like to write a test for this case and see what are the results. Will handle on Monday, thanks!

[kpagacz]

Hi, @m7pr how is this one going?

I am asking because we have quite a few of the scripts that could use solving the := issue because refactoring several thousands of lines of preprocessing code is no fun, and the workarounds leave much to be desired.

[m7pr]

@kpagacz on it

[m7pr]

Hey, narrowing it down to a simpler case:

code <- "
iris <- data.table::data.table(iris) %>%
  .[, NewSpecies := factor(Species)]
"
data <- teal.data::teal_data(iris = iris, code = code)

eval_code(teal_data(), code)

[m7pr]

Hey @kpagacz thanks for reporting.
I created a separate PR that fixes this issue #234
I added changes to the code in different place and also added a test.

I need team's opinion on how we test this edge case as it needs data.table package, and that's a big big package to be added in Suggests of the package. Will keep you posted. Probably we can sort this out today

[m7pr]

Ok, we changed the test to use := from rlang. 6d38745
We will merge soon today

[kpagacz]

I am closing this then.