Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add customizable responses's time for prompts #291

Open
capitantyler opened this issue Jan 8, 2024 · 5 comments
Open

add customizable responses's time for prompts #291

capitantyler opened this issue Jan 8, 2024 · 5 comments

Comments

@capitantyler
Copy link

It would be possible add customizable response's time for possible Rstudio form's prompts?
I am looking at the code and this time was set in 10 secs, which is too short to fill them.

I have been having problems running jobs from RStudio if it has Rstudio prompts inside.

@kevinushey
Copy link
Contributor

Can you please give an example? AFAIK RStudio shouldn't be timing out in any of the prompts exposed to rstudioapi.

@capitantyler
Copy link
Author

The mentioned code is in the remote.R line 65

# check for response
  if (file.exists(responseFile))
    break

  # check for lack of response
  diff <- difftime(Sys.time(), now, units = "secs")
  if (diff > 10)
    stop("RStudio did not respond to rstudioapi IPC request")

  # wait a bit
  Sys.sleep(0.1)

}

@kevinushey
Copy link
Contributor

Ahh, thanks -- so this is specifically for the case where rstudioapi is being invoked remotely; that is, from within an R child process. We can take a look at that.

@capitantyler
Copy link
Author

Well, I called it from a R Job, Besides, I filled the prompt manually.

jonovik added a commit to jonovik/rstudioapi that referenced this issue Jul 4, 2024
…tudio#291.

Revised function signatures:
showDialog(title, message, url = "", timeout = 10)
callFun(fname, ...)
callRemote(call, frame, timeout = 10)

Original function signatures:
showDialog(title, message, url = "")
callFun(fname, ...)
callRemote(call, frame)

To avoid adding arguments to callFun(), I make an object of list(...) and check whether it has a `timeout` element, then callRemote() with two or three arguments as needed.
jonovik added a commit to jonovik/rstudioapi that referenced this issue Jul 4, 2024
…tudio#291.

I've added a `timeout` argument to showDialog() and callRemote() as described below, and added logical to callFun() to propagate a named `timeout` argument to callRemote() if running as a job.

Revised function signatures:
showDialog(title, message, url = "", timeout = 10)
callFun(fname, ...)
callRemote(call, frame, timeout = 10)

Original function signatures:
showDialog(title, message, url = "")
callFun(fname, ...)
callRemote(call, frame)

To avoid adding arguments to callFun(), I make an object of list(...) and check whether it has a `timeout` element, then callRemote() with two or three arguments as needed.
jonovik added a commit to jonovik/rstudioapi that referenced this issue Jul 4, 2024
…tudio#291.

I've added a `timeout` argument to showDialog() and callRemote() as described below, and added logic to callFun() to propagate a named `timeout` argument to callRemote() if running as a job.

Revised function signatures:
showDialog(title, message, url = "", timeout = 10)
callFun(fname, ...)
callRemote(call, frame, timeout = 10)

Original function signatures:
showDialog(title, message, url = "")
callFun(fname, ...)
callRemote(call, frame)

To avoid adding arguments to callFun(), I make an object of list(...) and check whether it has a `timeout` element, then callRemote() with two or three arguments as needed.
@jonovik
Copy link

jonovik commented Jul 4, 2024

I created a pull request to solve this, but am a bit surprised it was not autolinked here:

#301

Sorry about the force pushes to my fork; I didn't realize they were being linked here before I finalized my pull request. Please focus on the latest one (f2cc66e), and I'll make no more force pushes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants