2

The code consists in two files:

caller.R:

a <- 1
source("s1.R", encoding = "UTF-8")
b <- fa()

s1.R:

fa <- function() {
  a*2
}

This code runs smoothly when caller.R is sourced (Crtl+Shift+S) in RStudio IDE, providing the correct expected result b=2.

However, when caller.R is sourced through "Source as Local Job...", it throws an error (Portuguese), meaning that execution was interrupted because it was not able to find object 'a':

Error in fa() : objeto 'a' n�o encontrado
Calls: sourceWithProgress -> eval -> eval -> fa
Execu��o interrompida

I have tried all possible "Source as Local Job..." options combinations ("Run job with copy of global environments, etc.) without success.

What do I have to do to be able to run caller.R as a local job?

Fabio Correa
  • 1,257
  • 1
  • 11
  • 17
  • 1
    Based on the Unicode rubbish you’re running Windows. Be aware that `source(…, encoding = 'utf-8')` [is broken on Windows](https://stackoverflow.com/a/5588488/1968)! Use `eval(parse(…, encoding = 'utf-8'))` instead. – Konrad Rudolph Oct 19 '21 at 12:02
  • 1
    And, as mentioned below the answer, it would be better to rewrite your `s1.R` in such a way that it no longer relies on external state. Have a look at [‘box’ modules](https://klmr.me/box/articles/box.html) for a slightly different and (IMHO, though I’m biased) vastly superior approach. – Konrad Rudolph Oct 19 '21 at 12:04
  • 1
    In RStudio, *"a “local job” is an R script that runs in a separate, dedicated R session"* ([ref](https://blog.rstudio.com/2019/03/14/rstudio-1-2-jobs/)). Variables in one R session are not available in another R session; this is not unique to R, it is how process-management (and security and encapsulation and ...) works. This is a new process, not a new thread (which might support what you want, albeit R and threads is still not great). I second Konrad's comment: write your function so that it doesn't effect scope-breach. – r2evans Oct 19 '21 at 12:14
  • As such, I think this is two things: (1) not understanding that "source as a local job" runs the script in a completely new, untarnished, unprepped R session, so the script file needs to initialize *everything* needed (data, packages, functions, etc); and this is highlighted by (2) an anti-pattern of a `function` that breaks reproducibility and does not adhere to *functional programming* fundamentals. Fix #2 and the symptom goes away; understand #1 and internalize #2 and your programming becomes much more robust/resilient :-) – r2evans Oct 19 '21 at 12:17
  • 2
    @r2evans I think you’re misunderstanding the error description: both scripts are executed in the *same* R process. Yes, there’s a new process when launching a script as a local job; but that process runs `caller.R` which, in turn, sources `s1.R`. All in the same process. – Konrad Rudolph Oct 19 '21 at 12:39
  • @KonradRudolph, yup, I missed that detail, thank you. – r2evans Oct 19 '21 at 12:43
  • @KonradRudolph thanks for the utf-8 issue warning, and the box package suggestion. – Fabio Correa Oct 19 '21 at 12:43

1 Answers1

3

If you want to have it available in the same environment, you can try to use the local = TRUE

source("s1.R", encoding = "UTF-8", local = TRUE)
Merijn van Tilborg
  • 5,452
  • 1
  • 7
  • 22