[Rd] unicode in R documentation

2021-07-13 Thread Frederick Eaton

Dear R Team,

I am running R from the terminal command line (not RStudio). I've noticed that 
R has been using Unicode quotes in its documentation for some time, maybe since 
before I started using it.

I am wondering if it is possible to compile the documentation to use normal 
quotes instead.

I find it useful to be able to search documentation for strings with quotes, for example when reading "?options" I might search for "'dev" 
to find an option starting with the letters "dev". Without the single-quote at the front, there would be a lot of matches that I'm not interested in, 
but the single-quote at the front helps narrow it down to the parameters that are being indexed in the documentation. However, I can't actually search for 
"'dev" in "?options" because it is written with curly quotes "‘device’" and "'" does not match "‘" on my 
machine.

Similarly, when I read manual pages for commands on Linux, I sometimes search for "-r" instead of "r" because 
"-r" is likely to find documentation for the option "-r", while searching for "r" will match almost 
every line.

I'm wondering what other people do when reading through documentation. Do you search for things at 
all or just read it straight through? Is there a hyperlinked version that just lets you jump to the 
"device" entry in "?options" or do you have to type out a search string? What 
search string do you use? Do you have a way to enter Unicode quotes when doing this, or does your 
pager provide a special regular expression syntax which makes it easier to match them?

Thanks,

Frederick

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] unicode in R documentation

2021-07-13 Thread Frederick Eaton

Thank you both! it works

On Tue, Jul 13, 2021 at 04:00:05PM +, Martin Morgan wrote:

I have options(useFancyQuotes = FALSE) in my ~/.Rprofile.

Martin Morgan



Not sure if this is more of an R-help topic. I use

   options(useFancyQuotes = FALSE)

in my .Rprofile.

Best regards,

Sebastian


I find it useful to be able to search documentation for strings with 
quotes, for example when reading "?options" I might search for 
"'dev" to find an option starting with the letters "dev". Without 
the single-quote at the front, there would be a lot of matches that 
I'm not interested in, but the single-quote at the front helps 
narrow it down to the parameters that are being indexed in the 
documentation. However, I can't actually search for "'dev" in 
"?options" because it is written with curly quotes "‘device’" and 
"'" does not match "‘" on my machine.


Similarly, when I read manual pages for commands on Linux, I 
sometimes search for "-r" instead of "r" because "-r" is likely to 
find documentation for the option "-r", while searching for "r" will 
match almost every line.


I'm wondering what other people do when reading through 
documentation. Do you search for things at all or just read it 
straight through? Is there a hyperlinked version that just lets you 
jump to the "device" entry in "?options" or do you have to type out 
a search string? What search string do you use? Do you have a way to 
enter Unicode quotes when doing this, or does your pager provide a 
special regular expression syntax which makes it easier to match 
them?


Thanks,

Frederick

__
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


[Rd] clarify "by columns"

2021-08-23 Thread Frederick Eaton

Dear R Devel,

I realized that I've been reading something without really thinking
about it. In "?matrix" we have:

   byrow: logical. If 'FALSE' (the default) the matrix is filled by
  columns, otherwise the matrix is filled by rows.

I don't understand on the first reading what "by columns" means. An
experiment ("matrix(1:6,ncol=2,nrow=3)") shows that it means "one
column at a time" rather than "rotating through the columns" as I had
first imagined. However, the purpose of my looking up this
documentation was to remind myself of the order of matrix elements in
R; since I had to do the experiment anyway, I think the documentation
added a useless delay. Perhaps this could be fixed if we define the
meaning of "by columns" in the documentation?

Apparently this is the same as "column-major order", but I am usually
just as unfamiliar with the meaning of this other phrase. I would like
the documentation to define both phrases, for example:

   byrow: logical. If 'FALSE' (the default) the matrix is filled
  by columns, i.e. in "column-major order", meaning that
  matrix elements in the same column are assigned
  consecutive data elements. Otherwise the matrix is
  filled by rows.

Is that too wordy?

Thank you,

Frederick

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] meaning of browser(skipCalls=)

2021-11-22 Thread Frederick Eaton

Dear R Devel,

I have been advised to use "options(error=recover)" to enable
debugging on errors. But sometimes it would seem more convenient to
override "stopifnot", for example:

stopifnot = function(b) { if(!b) { browser(skipCalls=1); } }

However, this doesn't do what I expected. On looking closer I find
that the "skipCalls" argument seems to be ignored except when printing
the "Called from: " message; it does not affect the evaluation context
or the output of 'where':

> var=2; f=function(){var=1; browser(skipCalls=0)}; f()
Called from: f()
Browse[1]> var
[1] 1
Browse[1]> where
where 1: f()

Browse[1]> Q
> var=2; f=function(){var=1; browser(skipCalls=1)}; f()
Called from: top level 
Browse[1]> var

[1] 1
Browse[1]> where
where 1: f()

Browse[1]> Q
> var=2; f=function(){var=1; browser(skipCalls=2)}; f()
Called from: top level 
Browse[1]> var

[1] 1
Browse[1]> where
where 1: f()

Browse[1]> Q

So it appears that the "browser()" API does not actually make it
possible to call this built-in function from within another R function
and thereby emulate the same behavior as calling browser() directly.

If this is the case, it might be good to have it fixed or documented.
I am aware of "browser(expr=)", but this requires editing the
particular call that failed. The documentation for "browser()" led me
to hope that my use case would be supported, if only because it admits
that users might want to build other debugging functions with
browser(): "The 'skipCalls' argument should be used when the
'browser()' call is nested within another debugging function". An
example where this 'skipCalls' parameter is used to build a useful
debugging function would help to clarify its English description in
the manual.

Also, from the browser() command line I could not find a way to step
*out* of the current function. This would have been a way to recover
from skipCalls not working as expected. Am I missing something? For
example is there some command other than "n", where the below
interaction could pause before "hi" and "bye"?

> f=function(){browser(); message("in f"); message("out f")}; f(); message("hi"); 
message("bye")
Called from: f()
Browse[1]> n
debug at #1: message("in f")
Browse[2]> n
in f
debug at #1: message("out f")
Browse[2]> n
out f
hi
bye

If it is not possible for the R debugger to step out of a function, it
would be good to document that too, maybe after the list of browser
prompt commands in "?browser". Being confined within a single function
is not an obvious disability for a debugger to have.

I feel that R is an excellent tool, but sometimes I think that if the
shortcomings of the system were better documented, then this would
save users a lot of time in certain cases.

Thank you,

Frederick

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] meaning of browser(skipCalls=) [and multiple mouse buttons]

2021-12-08 Thread Frederick Eaton

Dear R Core Team,

I'm attaching a proposed patch to hopefully address my confusions regarding the 
documentation of browser(). I'm not sure if all the material I added is 
correct, but I made experiments to confirm that the behavior is at least 
roughly as described.

patch ./src/library/base/man/browser.Rd < browser.patch

Also, here is a patch to support multiple mouse buttons in getGraphicsEvent(). 
This must be edited before it can be applied, I decided to keep the old code in 
an 'if(0)' to help make it clearer that my code is essentially doing the same 
thing.


https://github.com/navarum/tweaks/blob/master/r/patches/0001-Add-support-for-multiple-mouse-buttons.patch
wget -O - 
https://raw.githubusercontent.com/navarum/tweaks/master/r/patches/0001-Add-support-for-multiple-mouse-buttons.patch
 | patch -p1

It would be useful to have support in R for more than three mouse buttons 
because this enables the use of the mouse wheel (buttons 4 and 5), which can 
provide a more convenient interface when adjusting numbers and graphics and so 
on. I also have shift+wheel bound to buttons 6 and 7 via xbindkeys and xte, 
which I use for horizontal scrolling, via a trick from the web somewhere:

$ cat .xbindkeysrc.scm | grep xte
(xbindkey '(shift "b:4") "xte 'mouseclick 6'")
(xbindkey '(shift "b:5") "xte 'mouseclick 7'")

I hope that these contributions can be found acceptable.

Thank you in advance,

Frederick



On Mon, Nov 22, 2021 at 09:13:58AM -0800, Frederick Eaton wrote:

Dear R Devel,

I have been advised to use "options(error=recover)" to enable
debugging on errors. But sometimes it would seem more convenient to
override "stopifnot", for example:

   stopifnot = function(b) { if(!b) { browser(skipCalls=1); } }

However, this doesn't do what I expected. On looking closer I find
that the "skipCalls" argument seems to be ignored except when printing
the "Called from: " message; it does not affect the evaluation context
or the output of 'where':

   > var=2; f=function(){var=1; browser(skipCalls=0)}; f()
   Called from: f()
   Browse[1]> var
   [1] 1
   Browse[1]> where
   where 1: f()

   Browse[1]> Q
   > var=2; f=function(){var=1; browser(skipCalls=1)}; f()
   Called from: top level Browse[1]> var
   [1] 1
   Browse[1]> where
   where 1: f()

   Browse[1]> Q
   > var=2; f=function(){var=1; browser(skipCalls=2)}; f()
   Called from: top level Browse[1]> var
   [1] 1
   Browse[1]> where
   where 1: f()

   Browse[1]> Q

So it appears that the "browser()" API does not actually make it
possible to call this built-in function from within another R function
and thereby emulate the same behavior as calling browser() directly.

If this is the case, it might be good to have it fixed or documented.
I am aware of "browser(expr=)", but this requires editing the
particular call that failed. The documentation for "browser()" led me
to hope that my use case would be supported, if only because it admits
that users might want to build other debugging functions with
browser(): "The 'skipCalls' argument should be used when the
'browser()' call is nested within another debugging function". An
example where this 'skipCalls' parameter is used to build a useful
debugging function would help to clarify its English description in
the manual.

Also, from the browser() command line I could not find a way to step
*out* of the current function. This would have been a way to recover
from skipCalls not working as expected. Am I missing something? For
example is there some command other than "n", where the below
interaction could pause before "hi" and "bye"?

   > f=function(){browser(); message("in f"); message("out f")}; f(); message("hi"); 
message("bye")
   Called from: f()
   Browse[1]> n
   debug at #1: message("in f")
   Browse[2]> n
   in f
   debug at #1: message("out f")
   Browse[2]> n
   out f
   hi
   bye

If it is not possible for the R debugger to step out of a function, it
would be good to document that too, maybe after the list of browser
prompt commands in "?browser". Being confined within a single function
is not an obvious disability for a debugger to have.

I feel that R is an excellent tool, but sometimes I think that if the
shortcomings of the system were better documented, then this would
save users a lot of time in certain cases.

Thank you,

Frederick

--- browser-orig.Rd 2021-12-07 22:35:51.991222137 -0800
+++ browser-new.Rd  2021-12-07 23:53:36.414106296 -0800
@@ -45,8 +45,16 @@
   will be simpler.
 
   The \code{skipCalls} argument should be used when the \code{browser()}
-  call is nested within ano

Re: [Rd] meaning of browser(skipCalls=) [and multiple mouse buttons]

2021-12-15 Thread Frederick Eaton

Just following up to check if anyone has had time to look over these patches.

Frederick

On Wed, Dec 08, 2021 at 12:24:47AM -0800, Frederick Eaton wrote:

Dear R Core Team,

I'm attaching a proposed patch to hopefully address my confusions regarding the 
documentation of browser(). I'm not sure if all the material I added is 
correct, but I made experiments to confirm that the behavior is at least 
roughly as described.

   patch ./src/library/base/man/browser.Rd < browser.patch

Also, here is a patch to support multiple mouse buttons in getGraphicsEvent(). 
This must be edited before it can be applied, I decided to keep the old code in 
an 'if(0)' to help make it clearer that my code is essentially doing the same 
thing.

   
https://github.com/navarum/tweaks/blob/master/r/patches/0001-Add-support-for-multiple-mouse-buttons.patch
   wget -O - 
https://raw.githubusercontent.com/navarum/tweaks/master/r/patches/0001-Add-support-for-multiple-mouse-buttons.patch
 | patch -p1

It would be useful to have support in R for more than three mouse buttons 
because this enables the use of the mouse wheel (buttons 4 and 5), which can 
provide a more convenient interface when adjusting numbers and graphics and so 
on. I also have shift+wheel bound to buttons 6 and 7 via xbindkeys and xte, 
which I use for horizontal scrolling, via a trick from the web somewhere:

   $ cat .xbindkeysrc.scm | grep xte
   (xbindkey '(shift "b:4") "xte 'mouseclick 6'")
   (xbindkey '(shift "b:5") "xte 'mouseclick 7'")

I hope that these contributions can be found acceptable.

Thank you in advance,

Frederick



On Mon, Nov 22, 2021 at 09:13:58AM -0800, Frederick Eaton wrote:

Dear R Devel,

I have been advised to use "options(error=recover)" to enable
debugging on errors. But sometimes it would seem more convenient to
override "stopifnot", for example:

  stopifnot = function(b) { if(!b) { browser(skipCalls=1); } }

However, this doesn't do what I expected. On looking closer I find
that the "skipCalls" argument seems to be ignored except when printing
the "Called from: " message; it does not affect the evaluation context
or the output of 'where':

  > var=2; f=function(){var=1; browser(skipCalls=0)}; f()
  Called from: f()
  Browse[1]> var
  [1] 1
  Browse[1]> where
  where 1: f()

  Browse[1]> Q
  > var=2; f=function(){var=1; browser(skipCalls=1)}; f()
  Called from: top level Browse[1]> var
  [1] 1
  Browse[1]> where
  where 1: f()

  Browse[1]> Q
  > var=2; f=function(){var=1; browser(skipCalls=2)}; f()
  Called from: top level Browse[1]> var
  [1] 1
  Browse[1]> where
  where 1: f()

  Browse[1]> Q

So it appears that the "browser()" API does not actually make it
possible to call this built-in function from within another R function
and thereby emulate the same behavior as calling browser() directly.

If this is the case, it might be good to have it fixed or documented.
I am aware of "browser(expr=)", but this requires editing the
particular call that failed. The documentation for "browser()" led me
to hope that my use case would be supported, if only because it admits
that users might want to build other debugging functions with
browser(): "The 'skipCalls' argument should be used when the
'browser()' call is nested within another debugging function". An
example where this 'skipCalls' parameter is used to build a useful
debugging function would help to clarify its English description in
the manual.

Also, from the browser() command line I could not find a way to step
*out* of the current function. This would have been a way to recover
from skipCalls not working as expected. Am I missing something? For
example is there some command other than "n", where the below
interaction could pause before "hi" and "bye"?

  > f=function(){browser(); message("in f"); message("out f")}; f(); message("hi"); 
message("bye")
  Called from: f()
  Browse[1]> n
  debug at #1: message("in f")
  Browse[2]> n
  in f
  debug at #1: message("out f")
  Browse[2]> n
  out f
  hi
  bye

If it is not possible for the R debugger to step out of a function, it
would be good to document that too, maybe after the list of browser
prompt commands in "?browser". Being confined within a single function
is not an obvious disability for a debugger to have.

I feel that R is an excellent tool, but sometimes I think that if the
shortcomings of the system were better documented, then this would
save users a lot of time in certain cases.

Thank you,

Frederick




--- browser-orig.Rd 2021-12-07 22:35:51.991222137 -0800
+++ browser-new.Rd  2021-12-07 23:53:36.414106296 -0800
@@ -45,8 +45,16 @@
  will

Re: [Rd] meaning of browser(skipCalls=) [and multiple mouse buttons]

2021-12-22 Thread Frederick Eaton

Hi Martin,

The help documentation for browser() doesn't seem to mention anywhere
that it is impossible to step outside of the function that called
browser(). Is that indeed true? Can I use the debugger effectively
without knowing it? Is there some other documentation where this fact
is mentioned?

Why is it not in the documentation? Why not put it there? Why not talk
about it?

So confused,

Frederick

On Thu, Dec 16, 2021 at 10:02:13AM +0100, Martin Maechler wrote:

Frederick Eaton
on Wed, 15 Dec 2021 20:09:46 -0800 writes:


   > Just following up to check if anyone has had time to look over these 
patches.
   > Frederick

I strongly guess that nobody has.

Let me give you my perception of what you have tried to
propose/use,  and why I hadn't thought I should put in time for it:

You had started the thread by proposing "to override stopifnot()",
something which I (even though principal author of the function)
don't find a good idea at all:

stopifnot() is just one important utility function that will
call stop() under some circumstances.
If you want to tweak  error handling / debugging / browser, ..
you need to work on the level of error conditions, their
handlers, etc.

Secondly, you've mixed this up with mouse button
action/interrupt/.. handling  which may be a cool and nice idea,
but then your  `xbindkey`-etc code is, I think, only/entirely
for X11-based R interfaces, and I think this would only be a
Linux console, possibly one from using ESS (Emacs Speaks Statistics),
but most probably (but I'm guessing here) not even relevant when
using Rstudio on Linux, and even less relevant for any of the
other ways R is used interactively on non-Linux platforms. Maybe
it would also apply to *some* uses of R on the Mac, but not even
the default R-Mac GUI..

Sorry that this not as much encouraging as it probably should
be, but I though you'd rather want *some* feedback than none...

Best,
Martin



   > On Wed, Dec 08, 2021 at 12:24:47AM -0800, Frederick Eaton wrote:
   >> Dear R Core Team,
   >>
   >> I'm attaching a proposed patch to hopefully address my confusions 
regarding the documentation of browser(). I'm not sure if all the material I added is 
correct, but I made experiments to confirm that the behavior is at least roughly as 
described.
   >>
   >> patch ./src/library/base/man/browser.Rd < browser.patch
   >>
   >> Also, here is a patch to support multiple mouse buttons in 
getGraphicsEvent(). This must be edited before it can be applied, I decided to keep 
the old code in an 'if(0)' to help make it clearer that my code is essentially doing 
the same thing.
   >>
   >> 
https://github.com/navarum/tweaks/blob/master/r/patches/0001-Add-support-for-multiple-mouse-buttons.patch
   >> wget -O - 
https://raw.githubusercontent.com/navarum/tweaks/master/r/patches/0001-Add-support-for-multiple-mouse-buttons.patch
 | patch -p1
   >>
   >> It would be useful to have support in R for more than three mouse buttons 
because this enables the use of the mouse wheel (buttons 4 and 5), which can provide 
a more convenient interface when adjusting numbers and graphics and so on. I also 
have shift+wheel bound to buttons 6 and 7 via xbindkeys and xte, which I use for 
horizontal scrolling, via a trick from the web somewhere:
   >>
   >> $ cat .xbindkeysrc.scm | grep xte
   >> (xbindkey '(shift "b:4") "xte 'mouseclick 6'")
   >> (xbindkey '(shift "b:5") "xte 'mouseclick 7'")
   >>
   >> I hope that these contributions can be found acceptable.
   >>
   >> Thank you in advance,
   >>
   >> Frederick
   >>
   >>
   >>
   >> On Mon, Nov 22, 2021 at 09:13:58AM -0800, Frederick Eaton wrote:
   >>> Dear R Devel,
   >>>
   >>> I have been advised to use "options(error=recover)" to enable
   >>> debugging on errors. But sometimes it would seem more convenient to
   >>> override "stopifnot", for example:
   >>>
   >>> stopifnot = function(b) { if(!b) { browser(skipCalls=1); } }
   >>>
   >>> However, this doesn't do what I expected. On looking closer I find
   >>> that the "skipCalls" argument seems to be ignored except when printing
   >>> the "Called from: " message; it does not affect the evaluation context
   >>> or the output of 'where':
   >>>
   >>> > var=2; f=function(){var=1; browser(skipCalls=0)}; f()
   >>> Called from: f()
   >>> Browse[1]> var
   >>> [1] 1
   >>> Browse[1]> where
   >>> where 1: f()
   >>>
   >>> Browse[1]> Q
   >>> > var=2; f=function(){v

[Rd] security holes in system2

2022-03-10 Thread Frederick Eaton

Dear R Developers,

The documentation for "system2" only defines "args" as

args: a character vector of arguments to 'command'.

This encourages the reader to think that R's system2 interface is passing its 
arguments unchanged to exec().

But I was surprised to find that under the hood, you're just pasting my 
arguments together and sending them to a subshell to be re-parsed:

command <- paste(c(env, shQuote(command), args), collapse = " ")

What horror! Please fix or document the fact that system2 executes its 
ARGUMENTS and not just the command.

Aside from being relevant to data scientists, it's a big security hole. It 
means that, in some cases, something that looks like plain text in my R code 
will end up being executed as a command on my system, which seems dangerous to 
me.

> my_data=c("<(>&2 echo oops)")
> system2("echo",args=my_data)
/dev/fd/63
oops

Thank you,

Frederick

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel