Re: [Rd] meaning of browser(skipCalls=) [and multiple mouse buttons]
> 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(){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
Re: [Rd] MS Windows: R does not escape quotes in CLI options the same way as Rterm and Rscript
On 12/15/21 10:48 PM, Henrik Bengtsson wrote: On MS Windows 10, the following works: Rscript --vanilla -e "\"abc\"" [1] "abc" and also: Rterm --vanilla --no-echo -e "\"abc.txt\"" [1] "abc.txt" whereas attempting the same with 'R' fails; R --vanilla --no-echo -e "\"abc.txt\"" Error: object 'abc' not found Execution halted I get this with R 4.1.2 and R Under development (unstable) (2021-12-14 r81376 ucrt). Is this a bug? Yes, R.exe does not properly handle quotes (and backslashes preceding a quote, and trailing backslashes). This is the same as PR#18139 for shQuote(). I will put that on my list Best Tomas /Henrik __ 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] Feature request: Change default library path on Windows
Thank you for the update. Really helpful! Between this and the unicode changes, the next version will have a very positive impact on Windows users. Best, Steve On Mon, Dec 13, 2021 at 1:02 PM Tomas Kalibera wrote: > The default was now changed in R-devel to the local application data > (e.g. C:\Users\username\AppData\Local), which should solve the issues > with synchronization/backup/etc services and seems to be more in line > with conventions for the OS. It is a hidden folder, to open in Windows > explorer one can use e.g. shell.exec() from R. > > Best > Tomas > > On 7/27/21 1:12 PM, Tomas Kalibera wrote: > > On 7/26/21 1:44 AM, Steve Haroz wrote: > >> Thanks Ben. I just sent a request for a bugzilla login. > >> Jeroen chimed in earlier in support. > > > > Please note this has been reported, discussed and considered already, > > last time in PR#17842 (though proposing a different replacement for > > the default). > > > > I think changing the default from user documents to something else > > would make sense to consider together with some other breaking change > > for users, not in isolation, if at all. While the change may help > > users with a quota on the documents directory (e.g. shared on a cloud, > > backup, etc), it will make it harder to find the library for others, > > who would not notice the change to the documented behavior, and I > > assume that would still be a much larger group. > > > > Of course it does not help that it is not clear what the correct > > location should be now, and certainly there is little hope it won't > > change again, soon. My understanding is that the choice was originally > > correct when made, following the Microsoft guidelines. > > > > As discussed here as well, users may choose their own library path > > (?.libPaths). > > > > The installation location for R itself can be changed e.g. via /DIR > > option of the installer (see /?). This is useful e.g. when installing > > R only for the current user (/CURRENTUSER) and it impacts also the > > location of the library - it is then inside the given tree. > > > > Best > > Tomas > > > > > > > >> > >> Cheers, > >> Steve > >> > >> __ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] build failure: 'hashtab' is not an exported object from 'namespace:utils'
I just did `svn up' on the R development sources, switched to the build directory (I build R out of tree), ran make, and got this: make[6]: Entering directory '/home/steve/build/r-devel/src/library/tools/src' ../../../../library/tools/libs/tools.so is unchanged make[6]: Leaving directory '/home/steve/build/r-devel/src/library/tools/src' make[5]: Leaving directory '/home/steve/build/r-devel/src/library/tools/src' make[4]: Leaving directory '/home/steve/build/r-devel/src/library/tools' make[4]: Entering directory '/home/steve/build/r-devel/src/library/tools' installing 'sysdata.rda' Error: 'hashtab' is not an exported object from 'namespace:utils' Execution halted make[4]: *** [/home/steve/src/R/r-devel/share/make/basepkg.mk:151: sysdata] Error 1 make[4]: Leaving directory '/home/steve/build/r-devel/src/library/tools' make[3]: *** [Makefile:36: all] Error 2 make[3]: Leaving directory '/home/steve/build/r-devel/src/library/tools' make[2]: *** [Makefile:37: R] Error 1 make[2]: Leaving directory '/home/steve/build/r-devel/src/library' make[1]: *** [Makefile:28: R] Error 1 make[1]: Leaving directory '/home/steve/build/r-devel/src' make: *** [Makefile:61: R] Error 1 I then did `make clean', ran configure and make again, and got the same failure. Is this a known issue and is there a fix? Steve Berman __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] build failure: 'hashtab' is not an exported object from 'namespace:utils'
On Thu, 16 Dec 2021 10:13:11 +0100 Stephen Berman wrote: > Is this a known issue and is there a fix? For me, the fix was to remove the already-installed $SVNROOT/library/utils (which didn't yet contain hashtab) and re-run make, letting the R build process re-install it from scratch. -- Best regards, Ivan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] build failure: 'hashtab' is not an exported object from 'namespace:utils'
On 16/12/2021 09:13, Stephen Berman wrote: I just did `svn up' on the R development sources, switched to the build directory (I build R out of tree), ran make, and got this: Precisely which version of R-devel updating from which version? -- this is an area that has changed frequently in the last several days. I suspect 'make clean' is not enough -- use 'make distclean' for an ab initio build. make[6]: Entering directory '/home/steve/build/r-devel/src/library/tools/src' ../../../../library/tools/libs/tools.so is unchanged make[6]: Leaving directory '/home/steve/build/r-devel/src/library/tools/src' make[5]: Leaving directory '/home/steve/build/r-devel/src/library/tools/src' make[4]: Leaving directory '/home/steve/build/r-devel/src/library/tools' make[4]: Entering directory '/home/steve/build/r-devel/src/library/tools' installing 'sysdata.rda' Error: 'hashtab' is not an exported object from 'namespace:utils' Execution halted make[4]: *** [/home/steve/src/R/r-devel/share/make/basepkg.mk:151: sysdata] Error 1 make[4]: Leaving directory '/home/steve/build/r-devel/src/library/tools' make[3]: *** [Makefile:36: all] Error 2 make[3]: Leaving directory '/home/steve/build/r-devel/src/library/tools' make[2]: *** [Makefile:37: R] Error 1 make[2]: Leaving directory '/home/steve/build/r-devel/src/library' make[1]: *** [Makefile:28: R] Error 1 make[1]: Leaving directory '/home/steve/build/r-devel/src' make: *** [Makefile:61: R] Error 1 I then did `make clean', ran configure and make again, and got the same failure. Is this a known issue and is there a fix? Steve Berman __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] build failure: 'hashtab' is not an exported object from 'namespace:utils'
On Thu, 16 Dec 2021 09:57:40 + Prof Brian Ripley wrote: > On 16/12/2021 09:13, Stephen Berman wrote: >> I just did `svn up' on the R development sources, switched to the build >> directory (I build R out of tree), ran make, and got this: > > Precisely which version of R-devel updating from which version? -- this is an > area that has changed frequently in the last several days. Yes, it's been more than a month since my last build: I updated from r81161 | maechler | 2021-11-08 14:30:50 +0100 (Mon, 08 Nov 2021) | 1 line to r81384 | pd | 2021-12-16 01:20:16 +0100 (Thu, 16 Dec 2021) | 1 line > I suspect 'make clean' is not enough -- use 'make distclean' for an ab initio > build. That certainly gave me a clean slate -- and the build then succeeded. Thanks. On Thu, 16 Dec 2021 12:58:55 +0300 Ivan Krylov wrote: > On Thu, 16 Dec 2021 10:13:11 +0100 > Stephen Berman wrote: > >> Is this a known issue and is there a fix? > > For me, the fix was to remove the already-installed > $SVNROOT/library/utils (which didn't yet contain hashtab) and re-run > make, letting the R build process re-install it from scratch. I guess that would have been $BUILD/library/utils for me? Perhaps that would have shortened the build time, but I had already done `make distclean' and a complete rebuild was quick enough. But thanks for the reply. Steve Berman __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
