Hi R-devl,
I'm still unable to force opening an *interactive* non-Rstudio
platform-specific plot device on *unix* systems.
dev.new() add a new argument 'noRStudioGD' in R 3.1.1. Thank you. It
works for me when using RStudio on Windows, but on the unix system it
opens a pdf device instead of an interactive device when using an
interactive RStudio session (with R_DEFAULT_DEVICE and
R_INTERACIVE_DEVICE not set).
Do other unix RStudio users see this behavior?
It appears that the relevant line of dev.new (and in zzz.R):
else if (nzchar(dsp) && .Platform$GUI %in% c("X11", "Tk"))
X11
else defdev
but when I step through in debugger, I see that
Browse[2]> .Platform$GUI
[1] "RStudio"
so instead of returning X11, it returnd defdev (pdf)
perhaps changing to
.Platform$GUI %in% c("X11", "Tk", "RStudio")
would work, but seems a little strange logically.
best,
-skye
p.s. I wonder if instead of having a noRStudioGD=TRUE flag, it might be
a more future-proof design to have an avoid.devices='RStudioGD' argument
in case users need to induce similar behavior to avoid other current
or future devices? Probably to late now tho.
issues with dev.new avoiding RStudio plot device on unix?
7 messages · Ott Toomet, Stefan Evert, Skye Bender-deMoll +1 more
Can you describe your problem a bit more? * What kind of unix system do you have? * Can you run other X11 programs? I had a similar issue, and the problem was that the computer was not set up to support X11. As a minimum, you have to install /xauth/, and potentially also other libraries if you want to install packages from source. Best, Ott On Fri, Sep 25, 2015 at 11:53 AM, Skye Bender-deMoll <skyebend at skyeome.net> wrote:
Hi R-devl,
I'm still unable to force opening an *interactive* non-Rstudio
platform-specific plot device on *unix* systems.
dev.new() add a new argument 'noRStudioGD' in R 3.1.1. Thank you. It
works for me when using RStudio on Windows, but on the unix system it opens
a pdf device instead of an interactive device when using an interactive
RStudio session (with R_DEFAULT_DEVICE and R_INTERACIVE_DEVICE not set).
Do other unix RStudio users see this behavior?
It appears that the relevant line of dev.new (and in zzz.R):
else if (nzchar(dsp) && .Platform$GUI %in% c("X11", "Tk"))
X11
else defdev
but when I step through in debugger, I see that
Browse[2]> .Platform$GUI
[1] "RStudio"
so instead of returning X11, it returnd defdev (pdf)
perhaps changing to
.Platform$GUI %in% c("X11", "Tk", "RStudio")
would work, but seems a little strange logically.
best,
-skye
p.s. I wonder if instead of having a noRStudioGD=TRUE flag, it might be a
more future-proof design to have an avoid.devices='RStudioGD' argument in
case users need to induce similar behavior to avoid other current or future
devices? Probably to late now tho.
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Ott Toomet Visiting Researcher School of Information Mary Gates Hall, Suite 310 University of Washington Seattle, WA 98195 [[alternative HTML version deleted]]
Sorry, should have given more background. x11 works fine on all my systems when called by x11(). I'm the maintainer of a package that uses the animation library, which has performance issues when used with the RStudio plot device. But if you call plot.new() when using RStudio, you get an RStudio device, not the standard device for the platform because it overrides the device option. So I've had to have the library do platform detection and platform-specific device calls, which R CMD check doesn't like. I believe that noRStudioGD argument was avoided to give users a way around this, but it doesn't seem to be behaving correctly in the unix interactive case.
On 09/25/2015 08:31 PM, Ott Toomet wrote:
Can you describe your problem a bit more?
* What kind of unix system do you have??
* Can you run other X11 programs?
I had a similar issue, and the problem was that the computer was not set
up to support X11.? As a minimum, you have to install /xauth/, and
potentially also other libraries if you want to install packages from
source.
Best,
Ott
On Fri, Sep 25, 2015 at 11:53 AM, Skye Bender-deMoll
<skyebend at skyeome.net <mailto:skyebend at skyeome.net>> wrote:
Hi R-devl,
I'm still unable to force opening an *interactive* non-Rstudio
platform-specific plot device on *unix* systems.
dev.new() add a new argument 'noRStudioGD' in R 3.1.1.? Thank you.
It works for me when using RStudio on Windows, but on the unix
system it opens a pdf device instead of an interactive device when
using an interactive RStudio session (with R_DEFAULT_DEVICE and
R_INTERACIVE_DEVICE not set).
Do other unix RStudio users see this behavior?
It appears that the relevant line of dev.new (and in zzz.R):
? ? else if (nzchar(dsp) && .Platform$GUI %in% c("X11", "Tk"))
? ? ? ? ? ? ? X11
? ? else defdev
but when I step through in debugger, I see that
Browse[2]> .Platform$GUI
[1] "RStudio"
so instead of returning X11, it returnd defdev (pdf)
perhaps changing to
.Platform$GUI %in% c("X11", "Tk", "RStudio")
would work, but seems a little strange logically.
best,
? -skye
p.s.? I wonder if instead of having a noRStudioGD=TRUE flag, it
might be a more future-proof design to have an
avoid.devices='RStudioGD' argument? in case users need to induce
similar behavior to avoid other current or future devices??
Probably to late now tho.
______________________________________________
R-devel at r-project.org <mailto:R-devel at r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Ott Toomet
Visiting Researcher
School of Information
Mary Gates Hall, Suite 310
University of Washington
Seattle, WA 98195
Same problem here on Mac OS X 10.10.5 with R 3.2.2 and RStudio 0.99.473.
I think dev.new() tries to find a suitable device in an interactive session with this code
dsp <- Sys.getenv("DISPLAY")
if (.Platform$OS.type == "windows")
windows
else if (.Platform$GUI == "AQUA" || ((!nzchar(dsp) || grepl("^/tmp/launch-", dsp)) && .Call(C_makeQuartzDefault)))
quartz
else if (nzchar(dsp) && .Platform$GUI %in% c("X11", "Tk"))
X11
else defdev
which fails for me because RStudio sets .Platform$GUI to "RStudio" (thanks, RStudio!) and my DISPLAY variable looks like this
/private/tmp/com.apple.launchd.2wKas4wzPe/org.macosforge.xquartz:0
so the grepl() on dsp doesn't match.
Best,
Stefan
On 26 Sep 2015, at 06:42, Skye Bender-deMoll <skyebend at skyeome.net> wrote: Sorry, should have given more background. x11 works fine on all my systems when called by x11(). I'm the maintainer of a package that uses the animation library, which has performance issues when used with the RStudio plot device. But if you call plot.new() when using RStudio, you get an RStudio device, not the standard device for the platform because it overrides the device option. So I've had to have the library do platform detection and platform-specific device calls, which R CMD check doesn't like. I believe that noRStudioGD argument was avoided to give users a way around this, but it doesn't seem to be behaving correctly in the unix interactive case.
On 26/09/2015 1:42 AM, Skye Bender-deMoll wrote:
Sorry, should have given more background. x11 works fine on all my systems when called by x11(). I'm the maintainer of a package that uses the animation library, which has performance issues when used with the RStudio plot device. But if you call plot.new() when using RStudio, you get an RStudio device, not the standard device for the platform because it overrides the device option. So I've had to have the library do platform detection and platform-specific device calls, which R CMD check doesn't like. I believe that noRStudioGD argument was avoided to give users a way around this, but it doesn't seem to be behaving correctly in the unix interactive case.
It seems like the best workaround here could come from RStudio. They could provide a way for a user to indicate that they sometimes don't want to use the RStudio graphics device (e.g. an option setting), and your package could set and restore this option around your dev.new() call. The other seems to be for your package to temporarily set R_DEFAULT_DEVICE if the user doesn't already have it set, and use noRStudioGD=TRUE. The disadvantage of this is that you need to do all the platform-based decision making. Duncan
On 09/25/2015 08:31 PM, Ott Toomet wrote:
Can you describe your problem a bit more?
* What kind of unix system do you have??
* Can you run other X11 programs?
I had a similar issue, and the problem was that the computer was not set
up to support X11.? As a minimum, you have to install /xauth/, and
potentially also other libraries if you want to install packages from
source.
Best,
Ott
On Fri, Sep 25, 2015 at 11:53 AM, Skye Bender-deMoll
<skyebend at skyeome.net <mailto:skyebend at skyeome.net>> wrote:
Hi R-devl,
I'm still unable to force opening an *interactive* non-Rstudio
platform-specific plot device on *unix* systems.
dev.new() add a new argument 'noRStudioGD' in R 3.1.1.? Thank you.
It works for me when using RStudio on Windows, but on the unix
system it opens a pdf device instead of an interactive device when
using an interactive RStudio session (with R_DEFAULT_DEVICE and
R_INTERACIVE_DEVICE not set).
Do other unix RStudio users see this behavior?
It appears that the relevant line of dev.new (and in zzz.R):
? ? else if (nzchar(dsp) && .Platform$GUI %in% c("X11", "Tk"))
? ? ? ? ? ? ? X11
? ? else defdev
but when I step through in debugger, I see that
Browse[2]> .Platform$GUI
[1] "RStudio"
so instead of returning X11, it returnd defdev (pdf)
perhaps changing to
.Platform$GUI %in% c("X11", "Tk", "RStudio")
would work, but seems a little strange logically.
best,
? -skye
p.s.? I wonder if instead of having a noRStudioGD=TRUE flag, it
might be a more future-proof design to have an
avoid.devices='RStudioGD' argument? in case users need to induce
similar behavior to avoid other current or future devices??
Probably to late now tho.
______________________________________________
R-devel at r-project.org <mailto:R-devel at r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Ott Toomet
Visiting Researcher
School of Information
Mary Gates Hall, Suite 310
University of Washington
Seattle, WA 98195
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
3 days later
On 09/26/2015 03:22 AM, Duncan Murdoch wrote:
On 26/09/2015 1:42 AM, Skye Bender-deMoll wrote:
Sorry, should have given more background. x11 works fine on all my systems when called by x11(). I'm the maintainer of a package that uses the animation library, which has performance issues when used with the RStudio plot device. But if you call plot.new() when using RStudio, you get an RStudio device, not the standard device for the platform because it overrides the device option. So I've had to have the library do platform detection and platform-specific device calls, which R CMD check doesn't like. I believe that noRStudioGD argument was avoided to give users a way around this, but it doesn't seem to be behaving correctly in the unix interactive case.
It seems like the best workaround here could come from RStudio. They could provide a way for a user to indicate that they sometimes don't want to use the RStudio graphics device (e.g. an option setting), and your package could set and restore this option around your dev.new() call.
That would make sense, I've tried to propose they add it as a feature in the rstudioapi. However, since the noRstudioGD option now exists in R, I'd think it should behave consistently across platforms? Opening pdf on one and interactive on another seems odd.
The other seems to be for your package to temporarily set R_DEFAULT_DEVICE if the user doesn't already have it set, and use noRStudioGD=TRUE. The disadvantage of this is that you need to do all the platform-based decision making.
Great idea, I'll employ this workaround for now. Thanks! best, -skye
On 29/09/2015 2:00 PM, Skye Bender-deMoll wrote:
On 09/26/2015 03:22 AM, Duncan Murdoch wrote:
On 26/09/2015 1:42 AM, Skye Bender-deMoll wrote:
Sorry, should have given more background. x11 works fine on all my systems when called by x11(). I'm the maintainer of a package that uses the animation library, which has performance issues when used with the RStudio plot device. But if you call plot.new() when using RStudio, you get an RStudio device, not the standard device for the platform because it overrides the device option. So I've had to have the library do platform detection and platform-specific device calls, which R CMD check doesn't like. I believe that noRStudioGD argument was avoided to give users a way around this, but it doesn't seem to be behaving correctly in the unix interactive case.
It seems like the best workaround here could come from RStudio. They could provide a way for a user to indicate that they sometimes don't want to use the RStudio graphics device (e.g. an option setting), and your package could set and restore this option around your dev.new() call.
That would make sense, I've tried to propose they add it as a feature in the rstudioapi. However, since the noRstudioGD option now exists in R, I'd think it should behave consistently across platforms? Opening pdf on one and interactive on another seems odd.
The problem is that the device chosen by dev.new() depends on the GUI. You can see the code that does this in grDevices:::.onLoad. So in fact with noRstudioGD=TRUE, the decision is identical to what it is in R: you only get X11 if your GUI is X11 or Tk, you get pdf otherwise. It's pretty common to use R on a machine where X11 won't work, so this makes sense. Now "RStudio" is common enough nowadays as a GUI so perhaps it should be added to the list in both places, but I'm not sure that would work when RStudio is running on a server rather than on the local machine. I think the RStudio people would have to make sure this worked, and if they're doing that, wouldn't it be easier for them to provide the option themselves? Duncan Murdoch
The other seems to be for your package to temporarily set R_DEFAULT_DEVICE if the user doesn't already have it set, and use noRStudioGD=TRUE. The disadvantage of this is that you need to do all the platform-based decision making.
Great idea, I'll employ this workaround for now. Thanks! best, -skye
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel