Re: [Rd] Bracketed paste issues on Linux
I would have used source("clipboard") on systems which support it (Tomas
has confirmed it works on Linux). See ?file.
The macOS equivalent source(pipe("pbpaste")) also works.
On 14/06/2021 11:06, Cesko Voeten wrote:
Making it 1024 times larger gives:
installing 'sysdata.rda'
Error: segfault from C stack overflow
Making it only 4 times larger provides a usable R. In my test case of
copying&pasting mgcv::gam, I observe the same visual corruption at the
prompt as before, but when pressing return it has actually been received
correctly. My real-world problem involved a file 33KiB in size, which -
as expected, since 16KiB < 33KiB - still has the same problem as before.
I know nothing about readline, but I presume that there is no way for
this buffer size to be dynamically resized at run time. In that case,
maybe R should simply force-disable readline's bracketed paste? By the
way, according to readline's changelog, this does indeed seem to be a
feature that changed (viz. was enabled in more places) from readline-8.0
to readline-8.1.
Finally, please disregard my earlier comment about vim and nano working
just fine. They do, but they don't actually use readline (according to
ldd), so don't provide a valid comparison.
Thanks for your efforts!
Cesko
On 14-06-2021 at 08:33, Tomas Kalibera wrote:
Thanks, Cesko, for more debugging. As you are already compiling the
code, could you please try increasing CONSOLE_BUFFER_SIZE in
./include/Defn.h from 4096 to some very large value (e.g. 1024 times),
rebuild R and check if the problems (not all bytes received correctly,
visual corruption) go away for texts of the size you looked at before?
Thanks,
Tomas
On 6/13/21 10:59 AM, Voeten, C.C. wrote:
Thanks for looking into this! I've just compiled today's R-devel
snapshot, and it shows the same issue. extSoftVersion() from that build:
zlib
"1.2.11"
bzlib
"1.0.8, 13-Jul-2019"
xz
"5.2.5"
PCRE
"10.37 2021-05-26"
ICU
"69.1"
TRE
"TRE 0.8.0 R_fixes (BSD)"
iconv
"glibc 2.33"
readline
"8.1"
BLAS
"/home/cesko/r-devel/usr/lib64/R/lib/libRblas.so"
Thanks for your observation that it works on your system - that
implicates my readline-8.1 as being the culprit. Unfortunately, I
don't dare attempt to downgrade it on my system to test, and
regardless we still don't know why other readline-using programs can
paste in the same text with no issues.
I've made some further progress on debugging: I noticed that text
<4096 bytes in size arrives fine (although sometimes with visual
corruption), but text >4096 bytes doesn't. Pasting in the result of
perl -e 'print ("if(T)cat(\"a\")\n"x292)' works as expected, changing
the 292 to 293 causes R to print a bunch of a's followed by the
source code of the cat function.
To still answer your question: with mgcv::gam, pasting in the first
94 lines (as printed by R with options(width=80)) produces a visual
corruption of the prompt (it reads "G$family <-
familyar.summaryintercept = drop.intercept)) control$scalePenalty,")
but if I press return and type the closing "}" the code has actually
arrived just fine. The text up to and including that line is 4023
bytes in size; when trying to add in more, it fails again.
Cesko
--
*Van:* Tomas Kalibera
*Verzonden:* zondag 13 juni 2021 10:00:27
*Aan:* Voeten,
Re: [Rd] Bracketed paste issues on Linux
One can also disable bracketed paste for R in .inputrc:
$if R
set enable-bracketed-paste off
$endif
Tomas
On 6/15/21 11:09 AM, Prof Brian Ripley wrote:
I would have used source("clipboard") on systems which support it
(Tomas has confirmed it works on Linux). See ?file.
The macOS equivalent source(pipe("pbpaste")) also works.
On 14/06/2021 11:06, Cesko Voeten wrote:
Making it 1024 times larger gives:
installing 'sysdata.rda'
Error: segfault from C stack overflow
Making it only 4 times larger provides a usable R. In my test case of
copying&pasting mgcv::gam, I observe the same visual corruption at
the prompt as before, but when pressing return it has actually been
received correctly. My real-world problem involved a file 33KiB in
size, which - as expected, since 16KiB < 33KiB - still has the same
problem as before.
I know nothing about readline, but I presume that there is no way for
this buffer size to be dynamically resized at run time. In that case,
maybe R should simply force-disable readline's bracketed paste? By
the way, according to readline's changelog, this does indeed seem to
be a feature that changed (viz. was enabled in more places) from
readline-8.0 to readline-8.1.
Finally, please disregard my earlier comment about vim and nano
working just fine. They do, but they don't actually use readline
(according to ldd), so don't provide a valid comparison.
Thanks for your efforts!
Cesko
On 14-06-2021 at 08:33, Tomas Kalibera wrote:
Thanks, Cesko, for more debugging. As you are already compiling the
code, could you please try increasing CONSOLE_BUFFER_SIZE in
./include/Defn.h from 4096 to some very large value (e.g. 1024
times), rebuild R and check if the problems (not all bytes received
correctly, visual corruption) go away for texts of the size you
looked at before?
Thanks,
Tomas
On 6/13/21 10:59 AM, Voeten, C.C. wrote:
Thanks for looking into this! I've just compiled today's R-devel
snapshot, and it shows the same issue. extSoftVersion() from that
build:
zlib
"1.2.11"
bzlib
"1.0.8, 13-Jul-2019"
xz
"5.2.5"
PCRE
"10.37 2021-05-26"
ICU
"69.1"
TRE
"TRE 0.8.0 R_fixes (BSD)"
iconv
"glibc 2.33"
readline
"8.1"
BLAS
"/home/cesko/r-devel/usr/lib64/R/lib/libRblas.so"
Thanks for your observation that it works on your system - that
implicates my readline-8.1 as being the culprit. Unfortunately, I
don't dare attempt to downgrade it on my system to test, and
regardless we still don't know why other readline-using programs
can paste in the same text with no issues.
I've made some further progress on debugging: I noticed that text
<4096 bytes in size arrives fine (although sometimes with visual
corruption), but text >4096 bytes doesn't. Pasting in the result of
perl -e 'print ("if(T)cat(\"a\")\n"x292)' works as expected,
changing the 292 to 293 causes R to print a bunch of a's followed
by the source code of the cat function.
To still answer your question: with mgcv::gam, pasting in the first
94 lines (as printed by R with options(width=80)) produces a visual
corruption of the prompt (it reads "G$family <-
familyar.summaryintercept = drop.intercept))
control$scalePenalty,") but if I press return and type the closing
"}" the code has actually arrived just fine. The text up to and
including that line is 4023 bytes in size; when trying to add in
more, it fails again.
Cesko
---
Re: [Rd] Bracketed paste issues on Linux
Thanks to both for these suggested workarounds! I had indeed modified my
.inputrc to disable bracketed paste; thanks for also making me aware of the
existence of source("clipboard").
Of course, it would be nice if there still was a way for bracketed paste to
work even with large amounts of text, but I understand that this may be
technically infeasible (and/or, quite simply, unimportant!).
Cesko
> -Original Message-
> From: Tomas Kalibera
> Sent: Tuesday, June 15, 2021 11:11 AM
> To: Prof Brian Ripley ; Voeten, C.C.
> ; r-devel@r-project.org
> Subject: Re: [Rd] Bracketed paste issues on Linux
>
> One can also disable bracketed paste for R in .inputrc:
>
> $if R
> set enable-bracketed-paste off
> $endif
>
> Tomas
>
> On 6/15/21 11:09 AM, Prof Brian Ripley wrote:
> > I would have used source("clipboard") on systems which support it
> > (Tomas has confirmed it works on Linux). See ?file.
> >
> > The macOS equivalent source(pipe("pbpaste")) also works.
> >
> > On 14/06/2021 11:06, Cesko Voeten wrote:
> >> Making it 1024 times larger gives:
> >>
> >> installing 'sysdata.rda'
> >> Error: segfault from C stack overflow
> >>
> >> Making it only 4 times larger provides a usable R. In my test case of
> >> copying&pasting mgcv::gam, I observe the same visual corruption at
> >> the prompt as before, but when pressing return it has actually been
> >> received correctly. My real-world problem involved a file 33KiB in
> >> size, which - as expected, since 16KiB < 33KiB - still has the same
> >> problem as before.
> >>
> >> I know nothing about readline, but I presume that there is no way for
> >> this buffer size to be dynamically resized at run time. In that case,
> >> maybe R should simply force-disable readline's bracketed paste? By
> >> the way, according to readline's changelog, this does indeed seem to
> >> be a feature that changed (viz. was enabled in more places) from
> >> readline-8.0 to readline-8.1.
> >>
> >> Finally, please disregard my earlier comment about vim and nano
> >> working just fine. They do, but they don't actually use readline
> >> (according to ldd), so don't provide a valid comparison.
> >>
> >> Thanks for your efforts!
> >> Cesko
> >>
> >> On 14-06-2021 at 08:33, Tomas Kalibera wrote:
> >>> Thanks, Cesko, for more debugging. As you are already compiling the
> >>> code, could you please try increasing CONSOLE_BUFFER_SIZE in
> >>> ./include/Defn.h from 4096 to some very large value (e.g. 1024
> >>> times), rebuild R and check if the problems (not all bytes received
> >>> correctly, visual corruption) go away for texts of the size you
> >>> looked at before?
> >>>
> >>>
> >>> Thanks,
> >>> Tomas
> >>>
> >>>
> >>>
> >>> On 6/13/21 10:59 AM, Voeten, C.C. wrote:
>
> Thanks for looking into this! I've just compiled today's R-devel
> snapshot, and it shows the same issue. extSoftVersion() from that
> build:
>
> zlib
> "1.2.11"
> bzlib
> "1.0.8, 13-Jul-2019"
> xz
> "5.2.5"
> PCRE
> "10.37 2021-05-26"
> ICU
> "69.1"
> TRE
> "TRE 0.8.0 R_fixes (BSD)"
> iconv
> "glibc 2.33"
> readline
> "8.1"
> BLAS
> "/home/cesko/r-devel/usr/lib64/R/lib/libRblas.so"
>
> Thanks for your observation that it works on your system - that
> implicates my readline-8.1 as being the culprit. Unfortunately, I
> don't dare attempt to downgrade it on my system to test, and
> regardless we still don't know why other readline-using programs
> can paste in the same text with no issues.
>
>
> I've made some further progress on debugging: I noticed that text
> <4096 bytes in size arrives fine (although sometimes with visual
> corruption), but text >4096 bytes doesn't. Pasting in the result of
> perl -e 'print ("if(T)cat(\"a\")\n"x292)' works as expected,
> changing the 292 to 293 causes R to print a bunch of a's followed
> by the source code of the cat function.
>
>
> To still answer your question: with mgcv::gam, pasting in the first
> 94 lines (as printed by R with options(width=80)) produces a visual
> corruption of the prompt (it reads "G$family <-
> familyar.summaryintercept = drop.intercept))
> control$scalePena
[Rd] R for Windows leaves detritus in the temp directory
ISSUE:
The TMPDIR validation done in src/gnuwin32/system.c:
/* in case getpid() is not unique -- has been seen under Windows */
snprintf(ifile, 1024, "%s/Rscript%x%x", tm, getpid(),
(unsigned int) GetTickCount());
ifp = fopen(ifile, "w+b");
if(!ifp) R_Suicide(_("creation of tmpfile failed -- set TMPDIR suitably?"));
}
does _not_ clean up after itself, i.e. there's a missing
unlink(ifile);
In contrast, ditto in src/unix/system.c does this.
BACKGROUND:
When running R CMD check --as-cran on my 'future' package, I get:
* checking for detritus in the temp directory ... NOTE
Found the following files/directories:
'Rscript171866c62e'
when checked on R Under development (unstable) (2021-06-13 r80496),
including on win-builder. I can reproduce this with a package
'tests/detritus.R':
cl <- parallel::makeCluster(1)
dummy <- parallel::clusterEvalQ(cl, {
cl <- parallel::makeCluster(1)
on.exit(parallel::stopCluster(cl))
parallel::clusterEvalQ(cl, Sys.getpid())
})
print(dummy)
parallel::stopCluster(cl)
I believe it requires a nested PSOCK cluster to reproduce the 'R CMD
check' NOTE, e.g. it does _not_ happen with:
cl <- parallel::makeCluster(1)
dummy <- parallel::clusterEvalQ(cl, {
Sys.getpid()
})
print(dummy)
parallel::stopCluster(cl)
/Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
