Re: [Rd] system(wait = FALSE)
The targets are identical. In fact, I located the exact shortcut
listed as the start menu recent programs entry, and it's the same one
used in the all programs entry (there's some Windows magic going on
here that I don't necessarily understand). Running that through
explorer or the all programs menu gives the weird behavior, and
running it through the recent programs list gives me the expected
behavior.
Oliver
On Thu, Feb 24, 2011 at 3:54 PM, Gabor Grothendieck
wrote:
> On Thu, Feb 24, 2011 at 2:46 PM, Oliver Soong wrote:
>> Sorry, I didn't know about r-wind...@r-project.org. Is that a public
>> mailing list like r-help? It's not listed under
>> http://www.r-project.org/mail.html.
>>
>> I was able to reproduce the issue under two other 32-bit Windows 7
>> machines, so it's not specific to the one computer. It could be
>> something common to my Windows user account configurations, although
>> those accounts are not all configured similarly. The part that's the
>> strangest to me is that things do work when R is started through the
>> start menu recent programs and when called from a command shell, but
>> not through shortcuts or the start menu all programs list. Sys.getenv
>> does not indicate any particular difference. Are there any other
>> things I might check in R?
>
> Right click the particular start menu recent program entry that starts
> it and choose properties; also right click the shortcut and choose
> properties and right click the start menu programs list entry and
> choose properties. See what the differences are in the targets.
>
>
>
>
>
>>
>> The actual command I want to run has quoting concerns (inherent to
>> Windows and cmd) that force me to use system. If you don't like cmd
>> /c dir, this command also serves the purpose and also shows the weird
>> behavior. It presumes that Rscript is on the path:
>> system("Rscript -e \"writeLines(letters,
>> \\\"C:tmptmp.txt\\\")\"", wait = FALSE)
>>
>> I've been told (and can see) that shell just calls system, and since
>> the equivalent command in shell shows the same behavior due to this
>> weirdness I'm finding with system, I decided to focus on what appeared
>> to be the underlying problem (although perhaps not the actual problem
>> if it is just something with me).
>>
>> Oliver
>>
>>
>> On Wed, Feb 23, 2011 at 11:07 PM, Prof Brian Ripley
>> wrote:
>>> On Wed, 23 Feb 2011, Oliver Soong wrote:
>>>
>>>> I'm having a very odd problem with system(wait = FALSE). I'm not
>>>> entirely sure whether it's a bug in R or a problem on our end. It's
>>>> related to a post a month or so ago in R-help which got no responses,
>>>> but I have a little more to add.
>>>
>>> Well, the place you are asked to report issues on the Windows port is
>>> r-wind...@r-project.org. But no one was able to reproduce this, and it
>>> does sound as if the problem is on your specific machine. If so, only you
>>> can debug it and find out if it is really in R.
>>>
>>>> This command works as expected (I use c:\tmp since c:\ isn't normally
>>>> writable under later versions of Windows).
>>>
>>> That's a bold claim (and untrue of my Windows 7 systems), but if c:\ is not
>>> writeable, you cannot create c:\tmp!
>>>
>>>> The file is created at
>>>> c:\tmp\tmp.txt.
>>>> system("cmd /c dir > c:\\tmp\\tmp.txt", wait = TRUE)
>>>> This command does not work as expected. There is no file created at
>>>> c:\tmp\tmp.txt.
>>>> system("cmd /c dir > c:\\tmp\\tmp.txt", wait = FALSE)
>>>
>>> Windows' own programs are peculiar things, and often do not obey Windows'
>>> own rules for everyone else. So I give little weight to such an example.
>>> And in any case, we recommend shell() for such usages.
>>>
>>>> The computer is a 64-bit Windows Server 2008R2 machine. This affects
>>>> R 2.12.1, both the 32-bit and 64-bit RGui executables but not the
>>>> RTerm executables. This does not affect 32-bit Windows XP, 32-bit
>>>> Windows Server 2003, or 64-bit Windows Server 2008. This does not
>>>> affect R 2.12.0, and if I'm reading the svn logs correctly, there were
>>>> some changes made to the system function from 2.12.0 to 2.12.1.
>>>> Things seem to work normally when R is started from the start menu
>>>>
Re: [Rd] system(wait = FALSE)
Sorry, I didn't know about r-wind...@r-project.org. Is that a public
mailing list like r-help? It's not listed under
http://www.r-project.org/mail.html.
I was able to reproduce the issue under two other 32-bit Windows 7
machines, so it's not specific to the one computer. It could be
something common to my Windows user account configurations, although
those accounts are not all configured similarly. The part that's the
strangest to me is that things do work when R is started through the
start menu recent programs and when called from a command shell, but
not through shortcuts or the start menu all programs list. Sys.getenv
does not indicate any particular difference. Are there any other
things I might check in R?
The actual command I want to run has quoting concerns (inherent to
Windows and cmd) that force me to use system. If you don't like cmd
/c dir, this command also serves the purpose and also shows the weird
behavior. It presumes that Rscript is on the path:
system("Rscript -e \"writeLines(letters,
\\\"C:tmptmp.txt\\\")\"", wait = FALSE)
I've been told (and can see) that shell just calls system, and since
the equivalent command in shell shows the same behavior due to this
weirdness I'm finding with system, I decided to focus on what appeared
to be the underlying problem (although perhaps not the actual problem
if it is just something with me).
Oliver
On Wed, Feb 23, 2011 at 11:07 PM, Prof Brian Ripley
wrote:
> On Wed, 23 Feb 2011, Oliver Soong wrote:
>
>> I'm having a very odd problem with system(wait = FALSE). I'm not
>> entirely sure whether it's a bug in R or a problem on our end. It's
>> related to a post a month or so ago in R-help which got no responses,
>> but I have a little more to add.
>
> Well, the place you are asked to report issues on the Windows port is
> r-wind...@r-project.org. But no one was able to reproduce this, and it
> does sound as if the problem is on your specific machine. If so, only you
> can debug it and find out if it is really in R.
>
>> This command works as expected (I use c:\tmp since c:\ isn't normally
>> writable under later versions of Windows).
>
> That's a bold claim (and untrue of my Windows 7 systems), but if c:\ is not
> writeable, you cannot create c:\tmp!
>
>> The file is created at
>> c:\tmp\tmp.txt.
>> system("cmd /c dir > c:\\tmp\\tmp.txt", wait = TRUE)
>> This command does not work as expected. There is no file created at
>> c:\tmp\tmp.txt.
>> system("cmd /c dir > c:\\tmp\\tmp.txt", wait = FALSE)
>
> Windows' own programs are peculiar things, and often do not obey Windows'
> own rules for everyone else. So I give little weight to such an example.
> And in any case, we recommend shell() for such usages.
>
>> The computer is a 64-bit Windows Server 2008R2 machine. This affects
>> R 2.12.1, both the 32-bit and 64-bit RGui executables but not the
>> RTerm executables. This does not affect 32-bit Windows XP, 32-bit
>> Windows Server 2003, or 64-bit Windows Server 2008. This does not
>> affect R 2.12.0, and if I'm reading the svn logs correctly, there were
>> some changes made to the system function from 2.12.0 to 2.12.1.
>> Things seem to work normally when R is started from the start menu
>> recent programs list, but things do not work properly when R is
>> started from a shortcut, from the start menu all programs menu, or
>> through explorer.
>>
>> I'm stumped. Any ideas I can try?
>>
>> Oliver
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Brian D. Ripley, rip...@stats.ox.ac.uk
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UK Fax: +44 1865 272595
>
--
Oliver Soong
Donald Bren School of Environmental Science & Management
University of California, Santa Barbara
Santa Barbara, CA 93106-5131
805-893-7044 (office)
610-291-9706 (cell)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] system(wait = FALSE)
I'm having a very odd problem with system(wait = FALSE). I'm not
entirely sure whether it's a bug in R or a problem on our end. It's
related to a post a month or so ago in R-help which got no responses,
but I have a little more to add.
This command works as expected (I use c:\tmp since c:\ isn't normally
writable under later versions of Windows). The file is created at
c:\tmp\tmp.txt.
system("cmd /c dir > c:\\tmp\\tmp.txt", wait = TRUE)
This command does not work as expected. There is no file created at
c:\tmp\tmp.txt.
system("cmd /c dir > c:\\tmp\\tmp.txt", wait = FALSE)
The computer is a 64-bit Windows Server 2008R2 machine. This affects
R 2.12.1, both the 32-bit and 64-bit RGui executables but not the
RTerm executables. This does not affect 32-bit Windows XP, 32-bit
Windows Server 2003, or 64-bit Windows Server 2008. This does not
affect R 2.12.0, and if I'm reading the svn logs correctly, there were
some changes made to the system function from 2.12.0 to 2.12.1.
Things seem to work normally when R is started from the start menu
recent programs list, but things do not work properly when R is
started from a shortcut, from the start menu all programs menu, or
through explorer.
I'm stumped. Any ideas I can try?
Oliver
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Windows installer, HTML help, R 2.10.0
I'm not 100% sure this hasn't been covered already (I searched a bit, but I had a little trouble filtering down to a useful number of useful results). Anyway, when I install R on Windows, the installer asks to set the default help type. For some reason, I can set it as HTML in the installer, but the results open as if help_type = "text" by default. I presume this is related to the new changes to the help. Calling help(help, help_type = "html") works as expected, so the HTML help works and I could manually fix this by setting options(help_type = "html") in a session or in my .Rprofile. I'm not sure if I'm the only one seeing this, but for what it's worth, I also set SDI and Internet = Standard. I haven't experimented with different installation settings to see which ones work. Oliver __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pairs, par
I dug around in pairs, and I think it has something to do with the
on.exit(par(opar)) bit:
f <- function() {
opar <- par(mfrow = c(2, 2), mar = rep(0.5, 4), oma = rep(4, 4))
on.exit(par(opar))
for(i in 1:4) plot(0:1, 0:1)
par(c("mfg", "omd", "fig", "plt", "usr"))
print(opar)
}
f()
par(xpd = NA)
par(c("omd", "fig", "plt", "usr"))
points(0 - 0.01 * 1:100, 0 - 0.01 * 1:100)
points(0 - 0.01 * 1:100, 1 + 0.01 * 1:100)
points(1 + 0.01 * 1:100, 0 - 0.01 * 1:100)
points(1 + 0.01 * 1:100, 1 + 0.01 * 1:100)
My guess is that there are 2 sets of graphical parameters, the ones
stored in par and the ones used by the plotting functions. Before
par(opar) gets called, the two are synchronized. When par(opar) gets
called, we somehow set new values for par without changing the ones
used by the plotting functions, and the data used by points becomes
out of sync with the par information.
This is reflected in this much simpler example:
x11()
par(c("omd", "fig", "plt", "usr"))
points(0, 0)
Again, par is defined, but this time the data used by the plotting
functions has not been set, and an error occurs.
Thanks for the workaround suggestion. I guess I can always define a
new plotting region to force par and the plotting data to
re-synchronize. It might be nice if those two didn't go out of sync,
as I had assumed par would always be reliable.
Oliver
On 10/29/07, Tony Plate <[EMAIL PROTECTED]> wrote:
> I would look into the code for pairs(). Among other things, it sets and
> restores par(mfrow=...). I suspect this is the relevant issue, not the
> use of pairs(). I would try to figure out what state a graphics device
> is in after resetting par("mfrow"). When I try the following (R 2.6.0
> patched, under Windows), I see a line on the plot, but not in a place
> that corresponds to the axis that were drawn by the 'plot()' command:
>
> > par(mfrow=c(2,2))
> > plot(1:2)
> > par(mfrow=c(1,1))
> > lines(1:2,1:2)
> >
>
> (and if you want to be able to set up a new coordinate system on the
> plotting device to draw on top of the plot left by pairs(), look at
> par("new") & something like plot(0:1, type='n', axes=F, xlab=""))
>
> hope this helps,
>
> Tony Plate
>
> Oliver Soong wrote:
> > Hi,
> >
> > I posted over at R-help, and didn't get a response, but perhaps that
> > was the wrong forum for this question. I'm having some confusion over
> > the coordinate system after using pairs. I'm not interested in the
> > content of the actual pairs plot, although the number of pairs seems
> > to matter a bit. I'm purely interested in knowing where subsequent
> > points will be plotted on the device. However, after using pairs, the
> > par information (omd, fig, plt, and usr) don't reflect what points
> > does. For example:
> >
> > pairs(iris[1:5])
> > par(xpd = NA)
> > points(0 - 0.01 * 1:100, 0 - 0.01 * 1:100)
> > points(0 - 0.01 * 1:100, 1 + 0.01 * 1:100)
> > points(1 + 0.01 * 1:100, 0 - 0.01 * 1:100)
> > points(1 + 0.01 * 1:100, 1 + 0.01 * 1:100)
> > par(c("omd", "fig", "plt", "usr"))
> >
> > The resulting plot shows that the corners of the are approximately
> > 0.05 user coordinate units from the boundaries of the plot region.
> > According to par, though, there is a margin around the plotting region
> > that is clearly not symmetric and does not correspond to around 0.05
> > units.
> >
> > If we use pairs(iris[1:2]) and repeat the rest, the corners are now
> > 0.02 user coordinate units. par provides the same information as
> > before.
> >
> > So:
> > 1. How do I figure out where coordinates I give to points will display
> > on the figure?
> > 2. More generally (for my own understanding), why does the par
> > information not do what I expect? Do I have some fundamental
> > misunderstanding of the arrangement of plotting, figure, display, and
> > margin regions within the device? Is there a bug in pairs and/or par?
> >
> > I'm using R 2.5.1, and this behavior occurs on a fresh R console.
> >
> > Thanks!
> >
> > Oliver
> >
> >
> >
>
>
--
Oliver Soong
Donald Bren School of Environmental Science & Management
University of California, Santa Barbara
Santa Barbara, CA 93106-5131
805-893-7044 (office)
610-291-9706 (cell)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] pairs, par
Hi,
I posted over at R-help, and didn't get a response, but perhaps that
was the wrong forum for this question. I'm having some confusion over
the coordinate system after using pairs. I'm not interested in the
content of the actual pairs plot, although the number of pairs seems
to matter a bit. I'm purely interested in knowing where subsequent
points will be plotted on the device. However, after using pairs, the
par information (omd, fig, plt, and usr) don't reflect what points
does. For example:
pairs(iris[1:5])
par(xpd = NA)
points(0 - 0.01 * 1:100, 0 - 0.01 * 1:100)
points(0 - 0.01 * 1:100, 1 + 0.01 * 1:100)
points(1 + 0.01 * 1:100, 0 - 0.01 * 1:100)
points(1 + 0.01 * 1:100, 1 + 0.01 * 1:100)
par(c("omd", "fig", "plt", "usr"))
The resulting plot shows that the corners of the are approximately
0.05 user coordinate units from the boundaries of the plot region.
According to par, though, there is a margin around the plotting region
that is clearly not symmetric and does not correspond to around 0.05
units.
If we use pairs(iris[1:2]) and repeat the rest, the corners are now
0.02 user coordinate units. par provides the same information as
before.
So:
1. How do I figure out where coordinates I give to points will display
on the figure?
2. More generally (for my own understanding), why does the par
information not do what I expect? Do I have some fundamental
misunderstanding of the arrangement of plotting, figure, display, and
margin regions within the device? Is there a bug in pairs and/or par?
I'm using R 2.5.1, and this behavior occurs on a fresh R console.
Thanks!
Oliver
--
Oliver Soong
Donald Bren School of Environmental Science & Management
University of California, Santa Barbara
Santa Barbara, CA 93106-5131
805-893-7044 (office)
610-291-9706 (cell)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
