[Rd] The regular expressions in compareVersion()
Hi,
I guess the backslash should not be used as the separator for
strsplit() in compareVersion(), because the period in [.] is no longer
a metacharacter (no need to "escape" it using a backslash):
https://github.com/wch/r-source/blob/trunk/src/library/utils/R/packages.R#L866-L867
> compareVersion
function (a, b)
{
a <- as.integer(strsplit(a, "[\\.-]")[[1L]])
b <- as.integer(strsplit(b, "[\\.-]")[[1L]])
A similar regular expression problem also exists in the Sweave syntax
(for \Sexpr{}), and I have reported it once. It was fixed but the fix
was immediately reverted for some reason:
https://github.com/wch/r-source/commit/52b0a46e15136a7f9e4777e9960fdda6d84880c0
Regards,
Yihui
--
Yihui Xie
Web: http://yihui.name
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] palette() can hang and fail due to X11
For many years, when my R process starts up I've been automatically
setting my preferred default plot colors, basically like so:
my.colors <-
c("black" ,"red" ,"gold" ,"sky blue" ,"green" ,"blue" ,"orange"
,"grey" ,"hot pink" ,"brown" ,"sea green" ,"cyan" ,"purple" ,"tomato1")
require("grDevices")
palette(my.colors)
That seemed to work reliably in all 2.x versions of R, regardless of
whether my R was interactive or not, or if my Linux, ssh, and screen
environment had X-Windows properly set up or not. It Just Worked.
However, now in R 3.1.0 Patched (2014-04-15 r65398, on Linux),
depending on whether I have a good X-Windows connection or not it can
fail like so:
Error in .External2(C_X11, d$display, d$width, d$height, d$pointsize, :
unable to start device X11
Simply wrapping the palette() call in try() of course helps keep that
error from breaking the rest of my R start up. However, occasionally
the call to palette() will hang for perhaps a minute, unexpectedly
locking up my R process until it finishes whatever it was doing.
But, all I want to do here is set my default colors to the length 14
vector above, which seems like something that SHOULD be simple... Is
there some way for me to reliably do that WITHOUT invoking all this
extra X11 device machinery?
The relevant C code appears to be "palette" in
"src/library/grDevices/src/colors.c" and "do_dotcallgr" for
.Call.graphics in "src/main/dotcode.c", but I don't understand what
part is triggering the additional complex behavior, nor how I should
avoid it.
Any advice on how I should handle this robustly? (Thanks!)
--
Andrew Piskorski
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The regular expressions in compareVersion()
On 24/04/2014, 1:11 PM, Yihui Xie wrote:
Hi,
I guess the backslash should not be used as the separator for
strsplit() in compareVersion(), because the period in [.] is no longer
a metacharacter (no need to "escape" it using a backslash):
https://github.com/wch/r-source/blob/trunk/src/library/utils/R/packages.R#L866-L867
compareVersion
function (a, b)
{
a <- as.integer(strsplit(a, "[\\.-]")[[1L]])
b <- as.integer(strsplit(b, "[\\.-]")[[1L]])
Could you post an example where this causes trouble, or are you just
suggesting this as a way to make the source a little cleaner?
A similar regular expression problem also exists in the Sweave syntax
(for \Sexpr{}), and I have reported it once. It was fixed but the fix
was immediately reverted for some reason:
https://github.com/wch/r-source/commit/52b0a46e15136a7f9e4777e9960fdda6d84880c0
A link to your report would be more useful, if it included an example
where the bad regexp causes trouble.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The regular expressions in compareVersion()
On Thu, Apr 24, 2014 at 1:42 PM, Duncan Murdoch
wrote:
> On 24/04/2014, 1:11 PM, Yihui Xie wrote:
>>
>> Hi,
>>
>> I guess the backslash should not be used as the separator for
>> strsplit() in compareVersion(), because the period in [.] is no longer
>> a metacharacter (no need to "escape" it using a backslash):
>>
>> https://github.com/wch/r-source/blob/trunk/src/library/utils/R/packages.R#L866-L867
>>
>>> compareVersion
>>
>> function (a, b)
>> {
>>
>> a <- as.integer(strsplit(a, "[\\.-]")[[1L]])
>> b <- as.integer(strsplit(b, "[\\.-]")[[1L]])
>>
>>
>
>
> Could you post an example where this causes trouble, or are you just
> suggesting this as a way to make the source a little cleaner?
Maybe it's already clear, but [\\.] is the set for the two symbols '\'
and '.', not '.' alone. For example, I would expect an error below:
> compareVersion("3.14-59.26", "3.14-59\\26")
[1] 0
/Henrik
>
>
>>
>> A similar regular expression problem also exists in the Sweave syntax
>> (for \Sexpr{}), and I have reported it once. It was fixed but the fix
>> was immediately reverted for some reason:
>>
>> https://github.com/wch/r-source/commit/52b0a46e15136a7f9e4777e9960fdda6d84880c0
>
>
> A link to your report would be more useful, if it included an example where
> the bad regexp causes trouble.
>
> Duncan Murdoch
>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The regular expressions in compareVersion()
On 24/04/2014, 5:26 PM, Henrik Bengtsson wrote:
On Thu, Apr 24, 2014 at 1:42 PM, Duncan Murdoch
wrote:
On 24/04/2014, 1:11 PM, Yihui Xie wrote:
Hi,
I guess the backslash should not be used as the separator for
strsplit() in compareVersion(), because the period in [.] is no longer
a metacharacter (no need to "escape" it using a backslash):
https://github.com/wch/r-source/blob/trunk/src/library/utils/R/packages.R#L866-L867
compareVersion
function (a, b)
{
a <- as.integer(strsplit(a, "[\\.-]")[[1L]])
b <- as.integer(strsplit(b, "[\\.-]")[[1L]])
Could you post an example where this causes trouble, or are you just
suggesting this as a way to make the source a little cleaner?
Maybe it's already clear, but [\\.] is the set for the two symbols '\'
and '.', not '.' alone. For example, I would expect an error below:
compareVersion("3.14-59.26", "3.14-59\\26")
[1] 0
How does that cause problems?
Duncan Murdoch
/Henrik
A similar regular expression problem also exists in the Sweave syntax
(for \Sexpr{}), and I have reported it once. It was fixed but the fix
was immediately reverted for some reason:
https://github.com/wch/r-source/commit/52b0a46e15136a7f9e4777e9960fdda6d84880c0
A link to your report would be more useful, if it included an example where
the bad regexp causes trouble.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] palette() can hang and fail due to X11
The fundamental problem here seems to be a change (probably a bug) in the behavior of palette(). In R 3.1.0, calling palette() opens a new X window (on Linux)! That seems like a bug, as I can't think of any good reason for it to open a window, and it never did in any of the 2.x versions of R I've ever used. I am using: R 3.1.0 (Patched), 2014-04-15, svn.rev 65398, x86_64-unknown-linux-gnu Ubuntu 12.04.3 LTS Is there something else I should check to help track down the bug? -- Andrew Piskorski __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] palette() can hang and fail due to X11
Andrew,
palette is a property recorded in the graphics device* and therefore R will
create a new device (see dev.new()) if only the null device is open. Which
device is really up to your settings, so you could adjust your preferred device
depending on what you want it to be.
The bottom line is that you probably don't want to set the palette if you don't
have a device that could be used. The delay you see is probably due to your
local settings that seem to choose X11 as the default device which may or may
not work depending on the different way you start R and/or the availability of
the server you DISPLAY is pointing to.
* - this has changed in R 3.0.0, quote:
Palette changes get recorded on the display list, so
replaying plots (including when resizing screen devices and using
dev.copy()) will work better when the palette is changed
during a plot.
Cheers,
Simon
On Apr 24, 2014, at 4:13 PM, Andrew Piskorski wrote:
> For many years, when my R process starts up I've been automatically
> setting my preferred default plot colors, basically like so:
>
> my.colors <-
> c("black" ,"red" ,"gold" ,"sky blue" ,"green" ,"blue" ,"orange"
> ,"grey" ,"hot pink" ,"brown" ,"sea green" ,"cyan" ,"purple" ,"tomato1")
> require("grDevices")
> palette(my.colors)
>
> That seemed to work reliably in all 2.x versions of R, regardless of
> whether my R was interactive or not, or if my Linux, ssh, and screen
> environment had X-Windows properly set up or not. It Just Worked.
>
> However, now in R 3.1.0 Patched (2014-04-15 r65398, on Linux),
> depending on whether I have a good X-Windows connection or not it can
> fail like so:
>
> Error in .External2(C_X11, d$display, d$width, d$height, d$pointsize, :
>unable to start device X11
>
> Simply wrapping the palette() call in try() of course helps keep that
> error from breaking the rest of my R start up. However, occasionally
> the call to palette() will hang for perhaps a minute, unexpectedly
> locking up my R process until it finishes whatever it was doing.
>
> But, all I want to do here is set my default colors to the length 14
> vector above, which seems like something that SHOULD be simple... Is
> there some way for me to reliably do that WITHOUT invoking all this
> extra X11 device machinery?
>
> The relevant C code appears to be "palette" in
> "src/library/grDevices/src/colors.c" and "do_dotcallgr" for
> .Call.graphics in "src/main/dotcode.c", but I don't understand what
> part is triggering the additional complex behavior, nor how I should
> avoid it.
>
> Any advice on how I should handle this robustly? (Thanks!)
>
> --
> Andrew Piskorski
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The regular expressions in compareVersion()
You are right that this is unlikely to cause problems, because users
are unlikely to put backslashes in version numbers. Henrik has pointed
out the problem. It is not about "making the source code a little
cleaner", but "making it correct". Either someone in R core corrects
the wrong regular expressions in a few seconds (unless you think \ can
be a legal character in a version number), or I just give up the
report. It seems the latter is easier. It is not worth additional
Q&A's back and forth.
Regarding the regular expression problem for \Sexpr{} in Sweave,
please see here for a record:
http://r.789695.n4.nabble.com/Sweave-printing-an-underscore-in-the-output-from-an-R-command-td4675177.html
As I said, it is a similar problem: someone tried to escape a
character that did not need to be escaped in [].
Regards,
Yihui
--
Yihui Xie
Web: http://yihui.name
On Thu, Apr 24, 2014 at 6:20 PM, Duncan Murdoch
wrote:
> On 24/04/2014, 5:26 PM, Henrik Bengtsson wrote:
>>
>> On Thu, Apr 24, 2014 at 1:42 PM, Duncan Murdoch
>> wrote:
>>>
>>> On 24/04/2014, 1:11 PM, Yihui Xie wrote:
Hi,
I guess the backslash should not be used as the separator for
strsplit() in compareVersion(), because the period in [.] is no longer
a metacharacter (no need to "escape" it using a backslash):
https://github.com/wch/r-source/blob/trunk/src/library/utils/R/packages.R#L866-L867
> compareVersion
function (a, b)
{
a <- as.integer(strsplit(a, "[\\.-]")[[1L]])
b <- as.integer(strsplit(b, "[\\.-]")[[1L]])
>>>
>>>
>>>
>>> Could you post an example where this causes trouble, or are you just
>>> suggesting this as a way to make the source a little cleaner?
>>
>>
>> Maybe it's already clear, but [\\.] is the set for the two symbols '\'
>> and '.', not '.' alone. For example, I would expect an error below:
>>
>>> compareVersion("3.14-59.26", "3.14-59\\26")
>>
>> [1] 0
>>
>
> How does that cause problems?
>
> Duncan Murdoch
>
>
>> /Henrik
>>
>>>
>>>
A similar regular expression problem also exists in the Sweave syntax
(for \Sexpr{}), and I have reported it once. It was fixed but the fix
was immediately reverted for some reason:
https://github.com/wch/r-source/commit/52b0a46e15136a7f9e4777e9960fdda6d84880c0
>>>
>>>
>>>
>>> A link to your report would be more useful, if it included an example
>>> where
>>> the bad regexp causes trouble.
>>>
>>> Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The regular expressions in compareVersion()
FWIW the link has a long thread that is 90% irrelevant - AFAICS the relevant
part is
From: Yihui Xie-2
Sep 02, 2013; 4:11pm
Re: Sweave: printing an underscore in the output from an R command
[...]
Now you are good at the regular expression level, but Sweave comes and
bites you, and that is due to this bug in the regular expression in
Sweave Noweb syntax:
> SweaveSyntaxNoweb$docexpr
[1] "Sexpr\\{([^\\}]*)\\}"
It should have been "Sexpr\\{([^}]*)\\}", i.e. } does not need to
be escaped inside [], and \\ will be interpreted literally inside [].
In your case, Sweave sees \ in \Sexpr{}, and the regular expression
stops matching there, and is unable to see } after \, so it believes
there is no inline R expressions in your document.
On Apr 24, 2014, at 10:15 PM, Yihui Xie wrote:
> You are right that this is unlikely to cause problems, because users
> are unlikely to put backslashes in version numbers. Henrik has pointed
> out the problem. It is not about "making the source code a little
> cleaner", but "making it correct". Either someone in R core corrects
> the wrong regular expressions in a few seconds (unless you think \ can
> be a legal character in a version number), or I just give up the
> report. It seems the latter is easier. It is not worth additional
> Q&A's back and forth.
>
> Regarding the regular expression problem for \Sexpr{} in Sweave,
> please see here for a record:
> http://r.789695.n4.nabble.com/Sweave-printing-an-underscore-in-the-output-from-an-R-command-td4675177.html
> As I said, it is a similar problem: someone tried to escape a
> character that did not need to be escaped in [].
>
> Regards,
> Yihui
> --
> Yihui Xie
> Web: http://yihui.name
>
>
> On Thu, Apr 24, 2014 at 6:20 PM, Duncan Murdoch
> wrote:
>> On 24/04/2014, 5:26 PM, Henrik Bengtsson wrote:
>>>
>>> On Thu, Apr 24, 2014 at 1:42 PM, Duncan Murdoch
>>> wrote:
On 24/04/2014, 1:11 PM, Yihui Xie wrote:
>
>
> Hi,
>
> I guess the backslash should not be used as the separator for
> strsplit() in compareVersion(), because the period in [.] is no longer
> a metacharacter (no need to "escape" it using a backslash):
>
>
> https://github.com/wch/r-source/blob/trunk/src/library/utils/R/packages.R#L866-L867
>
>> compareVersion
>
>
> function (a, b)
> {
>
> a <- as.integer(strsplit(a, "[\\.-]")[[1L]])
> b <- as.integer(strsplit(b, "[\\.-]")[[1L]])
>
>
Could you post an example where this causes trouble, or are you just
suggesting this as a way to make the source a little cleaner?
>>>
>>>
>>> Maybe it's already clear, but [\\.] is the set for the two symbols '\'
>>> and '.', not '.' alone. For example, I would expect an error below:
>>>
compareVersion("3.14-59.26", "3.14-59\\26")
>>>
>>> [1] 0
>>>
>>
>> How does that cause problems?
>>
>> Duncan Murdoch
>>
>>
>>> /Henrik
>>>
>
> A similar regular expression problem also exists in the Sweave syntax
> (for \Sexpr{}), and I have reported it once. It was fixed but the fix
> was immediately reverted for some reason:
>
>
> https://github.com/wch/r-source/commit/52b0a46e15136a7f9e4777e9960fdda6d84880c0
A link to your report would be more useful, if it included an example
where
the bad regexp causes trouble.
Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
