0

EDIT: I believe I have found the issue, even though its running as Asynchronous both scripts had a for loop both using i as the counter... I changed script two to use z and now I'm not getting the error anymore

I am using system to source a script as an Asynchronous background process

system("C:/PROGRA~1/R/R-34~1.0/bin/Rscript.exe C:/Users/Federico/Documents/R/win-library/3.4/taskscheduleR/extdata/PriceTesting.R",
       wait=FALSE, show.output.on.console = F)

This script lasts 12 minutes while the original script that sourced this keeps running 24/7

while the sourced script is running the main script fails for 12 minutes. This is all the information I am retrieving from the error logging.

[1] "error at 2018-03-27 11:02:18 StopIteration TRXBTC"
[1] "error at 2018-03-27 11:03:18 StopIteration TRXBTC"
[1] "error at 2018-03-27 11:04:17 StopIteration TRXBTC"
[1] "error at 2018-03-27 11:05:17 StopIteration TRXBTC"
[1] "error at 2018-03-27 11:06:17 StopIteration TRXBTC"
[1] "error at 2018-03-27 11:07:18 StopIteration TRXBTC"
[1] "error at 2018-03-27 11:08:17 StopIteration TRXBTC"
[1] "error at 2018-03-27 11:09:18 StopIteration TRXBTC"
[1] "error at 2018-03-27 11:10:18 StopIteration TRXBTC"
[1] "error at 2018-03-27 11:11:18 StopIteration TRXBTC"
[1] "error at 2018-03-27 11:12:17 StopIteration TRXBTC"
[1] "error at 2018-03-27 11:13:19 StopIteration TRXBTC"
[1] "error at 2018-03-27 11:14:18 StopIteration TRXBTC"

My only thought is that the second script is being called from a parallel process which the main script later tries to kill (before the 12 minutes are over) Could this be the issue? The second script should be pulled totally separately so why is it effecting my first script?

  • Not enough information, I'm afraid. I have no idea what *either* script looks like, though I am inferring the use of the `iterators` package in one of them. – r2evans Mar 27 '18 at 16:29
  • The scripts are very large and go through multiple layers of sourcing to get to this point but I'll try to add more detail without over encumbering... however could it be that the new script using some of the same variables as the one that called it and that causes issues? – Federico Marchese Mar 27 '18 at 16:41
  • At times like these -- especially because your scripts are complex -- I find it incredibly useful to start disabling portions of the script and try to reproduce the problem with as few lines as possible. Sometimes I don't reduce but instead add intense logging so I know *when* something goes wrong. The reduction has two benefits: (1) it provides a MWE (important!) for questions here on SO; and (2) most of the time, while I'm reducing things, I find the error myself and do not need to post the question. It's a vital troubleshooting skill, and it needs to be developed with practice. – r2evans Mar 27 '18 at 16:47
  • So I added some more logging like you suggested and found a new error. Error in do.ply(i) : task 39 failed - "missing value where TRUE/FALSE needed" ... however im still trying to find where this came from – Federico Marchese Mar 27 '18 at 16:50
  • You are peeling the layers of the onion, good ... my guess is that the `StopIteration` error is related to that. Check your `if (...)` blocks, there's likely one that is returning `NA`. See https://stackoverflow.com/a/7355280/3358272. (You can see it in action with `if (NA) 1 else 2`.) – r2evans Mar 27 '18 at 16:53
  • one other question. do you know how I could get more out of geterrmessage() from the parralel processes. It usually just shows "StopIteration" – Federico Marchese Mar 27 '18 at 16:58
  • You can't get any error information from the call*ing* side, but you might try setting `options(error=traceback)` in the call*ed* side, perhaps it will give you more information about the call-tree at the time of the error. Otherwise, I'd deal with the call*ed* file directly (not run via `system("Rscript...")`, line-by-line, with debugging or other step-by-step tricks. (Might help some: https://en.wikibooks.org/wiki/R_Programming/Debugging) – r2evans Mar 27 '18 at 17:22

0 Answers0