accessing objects from automatically run Rscript

[cawthm]

Suppose I have an Rscript which will be launched automatically via a cron job. The script will, on some set schedule, open a websocket and write some data locally over a period of hours.

Two questions:

1. Is there a way --AFTER the script has begun-- to inspect the objects created by that script via Rstudio?
   Eg, the script starts at 7am, I arrive at my desk at 9am, and I want to see some in-memory object that the script has created: Presumably the objects live somewhere in an R-created environment. Are there things I can do --maybe contemplated in the script up front-- to let myself get to those objects?

2. What's the best way to terminate the script at a set time of day: some self polling feature within the script itself, or should it be killed as a process, again from some Cron-like helper?

Any opinionated guidance would be really appreciated.

Session info

devtools::session_info()
#> ─ Session info ──────────────────────────────────────────────────────────
#>  setting  value                       
#>  version  R version 3.5.2 (2018-12-20)
#>  os       macOS Mojave 10.14.2        
#>  system   x86_64, darwin15.6.0        
#>  ui       X11                         
#>  language (EN)                        
#>  collate  en_US.UTF-8                 
#>  ctype    en_US.UTF-8                 
#>  tz       America/Chicago             
#>  date     2019-02-13                  
#> 
#> ─ Packages ──────────────────────────────────────────────────────────────
#>  package     * version date       lib source                     
#>  assertthat    0.2.0   2017-04-11 [1] CRAN (R 3.5.0)             
#>  backports     1.1.2   2017-12-13 [1] CRAN (R 3.5.0)             
#>  callr         2.0.4   2018-05-15 [1] CRAN (R 3.5.0)             
#>  cli           1.0.1   2018-09-25 [1] CRAN (R 3.5.0)             
#>  crayon        1.3.4   2017-09-16 [1] CRAN (R 3.5.0)             
#>  debugme       1.1.0   2017-10-22 [1] CRAN (R 3.5.0)             
#>  desc          1.2.0   2018-07-09 [1] Github (r-lib/desc@4f60833)
#>  devtools      2.0.1   2018-10-26 [1] CRAN (R 3.5.1)             
#>  digest        0.6.18  2018-10-10 [1] CRAN (R 3.5.0)             
#>  evaluate      0.10.1  2017-06-24 [1] CRAN (R 3.5.0)             
#>  fs            1.2.6   2018-08-23 [1] CRAN (R 3.5.0)             
#>  glue          1.3.0   2018-07-17 [1] CRAN (R 3.5.0)             
#>  htmltools     0.3.6   2017-04-28 [1] CRAN (R 3.5.0)             
#>  knitr         1.20    2018-02-20 [1] CRAN (R 3.5.0)             
#>  magrittr      1.5     2014-11-22 [1] CRAN (R 3.5.0)             
#>  memoise       1.1.0   2017-04-21 [1] CRAN (R 3.5.0)             
#>  pkgbuild      1.0.2   2018-10-16 [1] CRAN (R 3.5.0)             
#>  pkgload       1.0.2   2018-10-29 [1] CRAN (R 3.5.0)             
#>  prettyunits   1.0.2   2015-07-13 [1] CRAN (R 3.5.0)             
#>  processx      3.1.0   2018-05-15 [1] CRAN (R 3.5.0)             
#>  R6            2.3.0   2018-10-04 [1] CRAN (R 3.5.0)             
#>  Rcpp          1.0.0   2018-11-07 [1] CRAN (R 3.5.0)             
#>  remotes       2.0.2   2018-10-30 [1] CRAN (R 3.5.0)             
#>  rlang         0.3.1   2019-01-08 [1] CRAN (R 3.5.2)             
#>  rmarkdown     1.9     2018-03-01 [1] CRAN (R 3.5.0)             
#>  rprojroot     1.3-2   2018-01-03 [1] CRAN (R 3.5.0)             
#>  sessioninfo   1.1.1   2018-11-05 [1] CRAN (R 3.5.1)             
#>  stringi       1.2.4   2018-07-20 [1] CRAN (R 3.5.0)             
#>  stringr       1.3.1   2018-05-10 [1] CRAN (R 3.5.0)             
#>  testthat      2.0.0   2017-12-13 [1] CRAN (R 3.5.0)             
#>  usethis       1.4.0   2018-08-14 [1] CRAN (R 3.5.0)             
#>  withr         2.1.2   2018-03-15 [1] CRAN (R 3.5.0)             
#>  yaml          2.1.19  2018-05-01 [1] CRAN (R 3.5.0)             
#> 
#> [1] /Library/Frameworks/R.framework/Versions/3.5/Resources/library

[jdlong]

Here's a few thoughts:

1. Not really. This is typically why folks use logging and write messages to the log. The log can be as simple as printing to stdout as long as your script is capturing stdout in a file. There are a number of logging frameworks but since you're not using one already, start easy. futile.logger is a good choice but there are others.
2. if your script is doing a loop of some kind just have it check the time and exit the loop if it's not between "run hours"

[cawthm]

Thanks for this reply- I'll mark it solved within a day, but will leave it open just in case someone cares to add any advice.

But if you're feeling generous- I'm a little blocked up on the pattern I need. It's something like:

while (work_day = TRUE) {
  start_my_process()
}

end_my_process()

The problem is that I need start_my_process() to be exactly run once, not over and over in the while condition.

[jdlong]

yeah this kind of depends on what start_my_process() does.. I was expecting that process to have a loop in it. Does it not?

[cawthm]

It does not. It opens a connection-like object to a remote server and a local connection to my db. The while() construction floods and thereby overloads the remote; it only wants one, which ideally remains open for the duration of work_day. Thanks for helping think through it.

[cawthm]

Alright- re question 2) here's some deceptively simple pseudo-code that worked, I guess because as the process (a websocket object driven by an R6 class package) updates state through time, it manages to recheck the second if conditional:

if (work_day == TRUE) {
  start_my_process()
  if (work_day == FALSE) { 
    end_my_process()
  }
}