Re: [Rd] R Console Bug?
Hi Simon,
Thank you for the feedback.
It is really strange that you have a different output.
I have attached a picture of my R console.
I am just trying to port some pure C code that prints progress bars to R
but it does not seem to be printing properly.
It seems I am doing something wrong with REprintf and R_FlushConsole.
Best regards,
Morgan
On Sat, Apr 17, 2021 at 12:36 AM Simon Urbanek
wrote:
> Sorry, unable to reproduce on macOS, in R console:
>
> > dyn.load("test.so")
> > .Call("printtest",1e4L)
>
>Processing data chunk 1 of 3
> [==] 100%
>
>Processing data chunk 2 of 3
> [==] 100%
>
>Processing data chunk 3 of 3
> [==] 100%
> NULL
>
> But honestly I'm not sure sure I understand the report. R_FlushConsole is
> a no-op for terminal console and your code just prints on stderr anyway
> (which is not buffered). All this does is just a lot of \r output (which is
> highly inefficient anywhere but in Terminal by definition). Can you clarify
> what the code tries to trigger?
>
> Cheers,
> Simon
>
>
> > On Apr 16, 2021, at 23:11, Morgan Morgan
> wrote:
> >
> > Hi,
> >
> > I am getting a really weird behaviour with the R console.
> > Here is the code to reproduce it.
> >
> > 1/ C code: ---
> >
> > SEXP printtest(SEXP x) {
> > const int PBWIDTH = 30, loop = INTEGER(x)[0];
> > int val, lpad;
> > double perc;
> > char PBSTR[PBWIDTH], PBOUT[PBWIDTH];
> > memset(PBSTR,'=', sizeof(PBSTR));
> > memset(PBOUT,'-', sizeof(PBOUT));
> > for (int k = 0; k < 3; ++k) {
> >REprintf("\n Processing data chunk %d of 3\n",k+1);
> >for (int i = 0; i < loop; ++i) {
> > perc = (double) i/(loop-1);
> > val = (int) (perc * 100);
> > lpad = (int) (perc * PBWIDTH);
> > REprintf("\r [%.*s%.*s] %3d%%", lpad, PBSTR, PBWIDTH - lpad, PBOUT,
> > val);
> > R_FlushConsole();
> >}
> >REprintf("\n");
> > }
> > return R_NilValue;
> > }
> >
> > 2/ Build so/dll: ---
> >
> > R CMD SHLIB
> >
> > 3/ Run code : ---
> >
> > dyn.load("test.so")
> > .Call("printtest",1e4L)
> > dyn.unload("test.so")
> >
> > 4/ Issue: ---
> > If you run the above code in RStudio, it works well both on Mac and
> Windows.
> > If you run it in Windows cmd, it is slow.
> > If you run it in Windows RGui, it is slow but also all texts are flushed.
> > If you run it in Mac terminal, it runs perfectly.
> > If you run it in Mac R Console, it prints something like :
> >> .Call("printtest",1e4L)
> > [==] 100%NULL]
> 0%
> >
> > I am using R 4.0.4 (Mac) / 4.0.5 (Windows)
> >
> > Is that a bug or am I doing something wrong?
> >
> > Thank you
> > Best regards,
> > Morgan
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > 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] R Console Bug?
Ah, so you're not using R console, you're using the R.app Mac-GUI. That one is
not a terminal, so it has entirely different rules, because it is combining all
four streams (stdout, stderr and WriteConsole for both output and message).
Also for historical reasons macOS (the original) used to use \r as newline
(unix has \n and Windows has \r\n) - for that reason your combination of \n\r
doesn't work since it is ambiguous in the Mac context and treated as CR. If you
want a proper newline, you can change your example to something like
REprintf("\n Processing data chunk %d of 3\n ",k+1);
Which makes sure the \n is interpreted as \r\n first and only then you follow
with \r. I suppose we could sunset the special handling of \r since it is
likely quite rare to see Mac line endings these days... you could file an issue
against Mac-GUI.
Cheers,
Simon
> On Apr 17, 2021, at 19:26, Morgan Morgan wrote:
>
> Hi Simon,
> Thank you for the feedback.
> It is really strange that you have a different output.
> I have attached a picture of my R console.
> I am just trying to port some pure C code that prints progress bars to R but
> it does not seem to be printing properly.
> It seems I am doing something wrong with REprintf and R_FlushConsole.
> Best regards,
> Morgan
>
> On Sat, Apr 17, 2021 at 12:36 AM Simon Urbanek
> wrote:
> Sorry, unable to reproduce on macOS, in R console:
>
> > dyn.load("test.so")
> > .Call("printtest",1e4L)
>
>Processing data chunk 1 of 3
> [==] 100%
>
>Processing data chunk 2 of 3
> [==] 100%
>
>Processing data chunk 3 of 3
> [==] 100%
> NULL
>
> But honestly I'm not sure sure I understand the report. R_FlushConsole is a
> no-op for terminal console and your code just prints on stderr anyway (which
> is not buffered). All this does is just a lot of \r output (which is highly
> inefficient anywhere but in Terminal by definition). Can you clarify what the
> code tries to trigger?
>
> Cheers,
> Simon
>
>
> > On Apr 16, 2021, at 23:11, Morgan Morgan wrote:
> >
> > Hi,
> >
> > I am getting a really weird behaviour with the R console.
> > Here is the code to reproduce it.
> >
> > 1/ C code: ---
> >
> > SEXP printtest(SEXP x) {
> > const int PBWIDTH = 30, loop = INTEGER(x)[0];
> > int val, lpad;
> > double perc;
> > char PBSTR[PBWIDTH], PBOUT[PBWIDTH];
> > memset(PBSTR,'=', sizeof(PBSTR));
> > memset(PBOUT,'-', sizeof(PBOUT));
> > for (int k = 0; k < 3; ++k) {
> >REprintf("\n Processing data chunk %d of 3\n",k+1);
> >for (int i = 0; i < loop; ++i) {
> > perc = (double) i/(loop-1);
> > val = (int) (perc * 100);
> > lpad = (int) (perc * PBWIDTH);
> > REprintf("\r [%.*s%.*s] %3d%%", lpad, PBSTR, PBWIDTH - lpad, PBOUT,
> > val);
> > R_FlushConsole();
> >}
> >REprintf("\n");
> > }
> > return R_NilValue;
> > }
> >
> > 2/ Build so/dll: ---
> >
> > R CMD SHLIB
> >
> > 3/ Run code : ---
> >
> > dyn.load("test.so")
> > .Call("printtest",1e4L)
> > dyn.unload("test.so")
> >
> > 4/ Issue: ---
> > If you run the above code in RStudio, it works well both on Mac and Windows.
> > If you run it in Windows cmd, it is slow.
> > If you run it in Windows RGui, it is slow but also all texts are flushed.
> > If you run it in Mac terminal, it runs perfectly.
> > If you run it in Mac R Console, it prints something like :
> >> .Call("printtest",1e4L)
> > [==] 100%NULL] 0%
> >
> > I am using R 4.0.4 (Mac) / 4.0.5 (Windows)
> >
> > Is that a bug or am I doing something wrong?
> >
> > Thank you
> > Best regards,
> > Morgan
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > 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] R Console Bug?
Just for completeness, This can be easily illustrated simply in R, no C code
needed:
cat("foo\n\rbar\n")
In unix terminal:
> cat("foo\n\rbar\n")
foo
bar
In Mac-GUI:
> cat("foo\n\rbar\n")
bar
Cheers,
Simon
> On Apr 17, 2021, at 20:29, Simon Urbanek wrote:
>
> Ah, so you're not using R console, you're using the R.app Mac-GUI. That one
> is not a terminal, so it has entirely different rules, because it is
> combining all four streams (stdout, stderr and WriteConsole for both output
> and message). Also for historical reasons macOS (the original) used to use \r
> as newline (unix has \n and Windows has \r\n) - for that reason your
> combination of \n\r doesn't work since it is ambiguous in the Mac context and
> treated as CR. If you want a proper newline, you can change your example to
> something like
>
> REprintf("\n Processing data chunk %d of 3\n ",k+1);
>
> Which makes sure the \n is interpreted as \r\n first and only then you follow
> with \r. I suppose we could sunset the special handling of \r since it is
> likely quite rare to see Mac line endings these days... you could file an
> issue against Mac-GUI.
>
> Cheers,
> Simon
>
>
>
>> On Apr 17, 2021, at 19:26, Morgan Morgan wrote:
>>
>> Hi Simon,
>> Thank you for the feedback.
>> It is really strange that you have a different output.
>> I have attached a picture of my R console.
>> I am just trying to port some pure C code that prints progress bars to R but
>> it does not seem to be printing properly.
>> It seems I am doing something wrong with REprintf and R_FlushConsole.
>> Best regards,
>> Morgan
>>
>> On Sat, Apr 17, 2021 at 12:36 AM Simon Urbanek
>> wrote:
>> Sorry, unable to reproduce on macOS, in R console:
>>
>>> dyn.load("test.so")
>>> .Call("printtest",1e4L)
>>
>> Processing data chunk 1 of 3
>> [==] 100%
>>
>> Processing data chunk 2 of 3
>> [==] 100%
>>
>> Processing data chunk 3 of 3
>> [==] 100%
>> NULL
>>
>> But honestly I'm not sure sure I understand the report. R_FlushConsole is a
>> no-op for terminal console and your code just prints on stderr anyway (which
>> is not buffered). All this does is just a lot of \r output (which is highly
>> inefficient anywhere but in Terminal by definition). Can you clarify what
>> the code tries to trigger?
>>
>> Cheers,
>> Simon
>>
>>
>>> On Apr 16, 2021, at 23:11, Morgan Morgan wrote:
>>>
>>> Hi,
>>>
>>> I am getting a really weird behaviour with the R console.
>>> Here is the code to reproduce it.
>>>
>>> 1/ C code: ---
>>>
>>> SEXP printtest(SEXP x) {
>>> const int PBWIDTH = 30, loop = INTEGER(x)[0];
>>> int val, lpad;
>>> double perc;
>>> char PBSTR[PBWIDTH], PBOUT[PBWIDTH];
>>> memset(PBSTR,'=', sizeof(PBSTR));
>>> memset(PBOUT,'-', sizeof(PBOUT));
>>> for (int k = 0; k < 3; ++k) {
>>> REprintf("\n Processing data chunk %d of 3\n",k+1);
>>> for (int i = 0; i < loop; ++i) {
>>> perc = (double) i/(loop-1);
>>> val = (int) (perc * 100);
>>> lpad = (int) (perc * PBWIDTH);
>>> REprintf("\r [%.*s%.*s] %3d%%", lpad, PBSTR, PBWIDTH - lpad, PBOUT,
>>> val);
>>> R_FlushConsole();
>>> }
>>> REprintf("\n");
>>> }
>>> return R_NilValue;
>>> }
>>>
>>> 2/ Build so/dll: ---
>>>
>>> R CMD SHLIB
>>>
>>> 3/ Run code : ---
>>>
>>> dyn.load("test.so")
>>> .Call("printtest",1e4L)
>>> dyn.unload("test.so")
>>>
>>> 4/ Issue: ---
>>> If you run the above code in RStudio, it works well both on Mac and Windows.
>>> If you run it in Windows cmd, it is slow.
>>> If you run it in Windows RGui, it is slow but also all texts are flushed.
>>> If you run it in Mac terminal, it runs perfectly.
>>> If you run it in Mac R Console, it prints something like :
.Call("printtest",1e4L)
>>> [==] 100%NULL] 0%
>>>
>>> I am using R 4.0.4 (Mac) / 4.0.5 (Windows)
>>>
>>> Is that a bug or am I doing something wrong?
>>>
>>> Thank you
>>> Best regards,
>>> Morgan
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> 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] R 4.0.1-4.0.5 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7-7.9
On Fri, 16 Apr 2021 18:39:04 +
Ryan Novosielski wrote:
> I guess there’s probably some mode of m4 I could run against that and
> see if there’s any indication?
Here's a shell script that should be doing the same thing that
R's .../configure does, but a bit more verbose:
---8<---
#!/bin/sh
cat > conftest1.c <
uintptr_t dummy_ii(void)
{
int ii;
/* This is intended to return a local address. We could just return
(uintptr_t) &ii, but doing it indirectly through ii_addr avoids
a compiler warning (-Wno-return-local-addr would do as well).
*/
volatile uintptr_t ii_addr = (uintptr_t) ⅈ
return ii_addr;
}
EOF
cat > conftest.c <
#include
extern uintptr_t dummy_ii(void);
typedef uintptr_t (*dptr_type)(void);
volatile dptr_type dummy_ii_ptr;
int main(int ac, char **av)
{
int i;
dummy_ii_ptr = dummy_ii;
/* call dummy_ii via a volatile function pointer to prevent
inlinining in case the tests are accidentally built with
LTO */
uintptr_t ii = dummy_ii_ptr();
#ifndef EXACTLY_AS_R_CONFIGURE
printf(
"main = %p, sub = %p, main %c sub, ret = %d\n",
&i, (void*)ii,
((uintptr_t)&i > ii) ? '>' : ((uintptr_t)&i < ii) ? '<' : '=',
((uintptr_t)&i > ii) ? 1 : -1
);
#endif
/* 1 is downwards */
return ((uintptr_t)&i > ii) ? 1 : -1;
}
EOF
echo "${CC:=cc} ${CPPFLAGS} ${CFLAGS} ${LDFLAGS} ${MAIN_LDFLAGS}" \
"-o conftest conftest.c conftest1.c"
${CC} ${CPPFLAGS} ${CFLAGS} ${LDFLAGS} ${MAIN_LDFLAGS} -o conftest \
conftest.c conftest1.c || exit $?
echo ./conftest
./conftest
ret=$?
echo "./conftest exited with $ret"
if test ${ret} = 1; then
echo r_cv_cstack_direction=down
elif test ${ret} = 1; then
echo r_cv_cstack_direction=up
fi
exit 0
---8<---
Please run it similarly to the way you run .../configure:
export CC=icc
export CFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
sh .../runme.sh
Does it give the right answer, that is, r_cv_cstack_direction=down?
Does the answer change if you add -DEXACTLY_AS_R_CONFIGURE to CFLAGS?
If the answer is always "down" and you have reused the build directory
(keeping the config.site file between .../configure runs), this is going
to be hard to track down. If you manage to get the "up" answer, it
should be possible to tweak the test until ICC doesn't optimise it to
the point of confusing the stack growth direction.
Either way, I think that the elif branch in the R_STACK_DIRECTION test
should be testing for $? = 255, not 1. I'm almost convinced that the
behaviour would be incorrect on platforms where the test exits with -1.
--
Best regards,
Ivan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.1-4.0.5 built with Intel Composer 19.0-19.1.1, errors in "make check" on CentOS 7.7-7.9
On Sat, 17 Apr 2021 00:13:42 +
Ryan Novosielski wrote:
> reg-tests-1d.Rout.fail:
> https://rutgersconnect-my.sharepoint.com/:u:/g/personal/novosirj_oarc_rutgers_edu/EYK2JHWQ1-9Dvu6gK9lrkRIBkEyA4QqkeH7C4gmbAYyBBQ?e=lfGJL7
> reg-packages.Rout.fail:
> https://rutgersconnect-my.sharepoint.com/:u:/g/personal/novosirj_oarc_rutgers_edu/EazCjI6fRnNKhQASFPeySBUBENVpCqCljFg3-sokBZJnAw?e=8lwywe
Sorry, these links seem to be asking me to log in. Could you try a
"paste bin" service like https://paste.debian.net/?
> These maybe seem like they’re OK, and if I don’t have pdf2latex,
> they’re expected?
I've never tried to build R without TeX Live installed. Is there
anything about LaTeX-less installation in 'R Installation and
Administration'?
> For the regression tests, these seem like some of them are actual
> problems, but maybe someone here knows if some are expected?
Anything that crashes (well, raises an R error, not crashes the R
process) inside tools::assertError(...) is meant to do that. In fact,
you get an error if it doesn't crash:
tools::assertError(stop('I will crash'))
tools::assertError(stop('I will crash'), verbose = TRUE)
# Asserted error: I will crash
tools::assertError(2+2)
# Error: Failed to get error in evaluating 2 + 2
--
Best regards,
Ivan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] reshape documentation
Dear Deepayan,
I do not have further suggestions, but I just wanted to thank you for taking
the time to improve the documentation so much! (and for adding support for
specifying "varying" as a vector)
Both "Typical usage" and the details are useful additions. Adding a vignette
also seems an excellent idea.
These changes will probably helps numerous users.
Best,
Thomas
On Wed, Mar 17, 2021 at 7:55 PM Michael Dewey
wrote:
>
> Comments in line
>
> On 13/03/2021 09:50, SOEIRO Thomas wrote:
> > Dear list,
> >
> > I have some questions/suggestions about reshape.
> >
> > 1) I think a good amount of the popularity of base::reshape alternative is
> > due to the complexity of reshape documentation. It is quite hard (at least
> > it is for me) to figure out what argument is needed for respectively "long
> > to wide" and "wide to long", because reshapeWide and reshapeLong are
> > documented together.
> > - Do you agree with this?
> > - Would you consider a proposal to modify the documentation?
> > - If yes, what approach do you suggest? e.g. split in two pages?
>
> The current documentation is much clearer than it was when I first
> started using R but we should always strive for more.
>
> I would suggest leaving the documentation in one place but it might be
> helpful to add which direction is relevant for each parameter by placing
> (to wide) or (to long) as appropriate. I think having completely
> separate lists is not needed
I have just checked in some updates to the documentation (in R-devel)
which hopefully makes usage clearer. Any further suggestions are
welcome. We are planning to add a short vignette as well, hopefully in
time for R 4.1.0.
> > 2) I do not think the documentation indicates that we can use varying
> > argument to rename variables in reshapeWide.
> > - Is this worth documenting?
> > - Is the construct list(c()) really needed?
>
> Yes, because you may have more than one set of variables which need to
> correspond to a single variable in long format. So in your example if
> you also had 11 variables for the temperature as well as the
> concentration each would need specifying as a separate vector in the list.
That's a valid point, but on the other hand, direction="long" already
supports specifying 'varying' as a vector, and it does simplify the
single variable case. So we decided to be consistent and allow it for
direction="wide" too, hopefully with loud enough warnings in the
documentation about using the feature carelessly.
Best,
-Deepayan
> Michael
>
> >
> > reshape(Indometh,
> > v.names = "conc",
> > idvar = "Subject",
> > timevar = "time",
> > direction = "wide",
> > varying = list(c("conc_0.25hr",
> > "conc_0.5hr",
> > "conc.0.75hr",
> > "conc_1hr",
> > "conc_1.25hr",
> > "conc_2hr",
> > "conc_3hr",
> > "conc_4hr",
> > "conc_5hr",
> > "conc_6hr",
> > "conc_8hr")))
> >
> > Thanks,
> >
> > Thomas
> > __
> > R-devel using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
> Michael
> http://www.dewey.myzen.co.uk/home.html
>
> __
> R-devel using 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] R 4.0.1-4.0.5 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7-7.9
Thank you Ryan and Ivan for reporting and debugging this. Godbolt.org
shows that icc 19.0.1 with -O2 -ipo (inter-procedural optimizations) is
too smart and optimizes this stack growth detection code so that it
returns incorrect result on x86_64. Detecting stack growth from C is
tricky - in principle, it cannot be done correctly in a portable way. As
the compilers are getting more sophisticated, it is increasingly more
difficult. We'll have to improve the test, perhaps re-using some or
completely remove it and assume stack grows down. I doubt anyone today
would run a real, non-emulated, system running R where stack would grow up.
(and yes, the elif conditional should use 255)
Tomas
On 4/17/21 11:40 AM, Ivan Krylov wrote:
On Fri, 16 Apr 2021 18:39:04 +
Ryan Novosielski wrote:
I guess there’s probably some mode of m4 I could run against that and
see if there’s any indication?
Here's a shell script that should be doing the same thing that
R's .../configure does, but a bit more verbose:
---8<---
#!/bin/sh
cat > conftest1.c <
uintptr_t dummy_ii(void)
{
int ii;
/* This is intended to return a local address. We could just return
(uintptr_t) &ii, but doing it indirectly through ii_addr avoids
a compiler warning (-Wno-return-local-addr would do as well).
*/
volatile uintptr_t ii_addr = (uintptr_t) ⅈ
return ii_addr;
}
EOF
cat > conftest.c <
#include
extern uintptr_t dummy_ii(void);
typedef uintptr_t (*dptr_type)(void);
volatile dptr_type dummy_ii_ptr;
int main(int ac, char **av)
{
int i;
dummy_ii_ptr = dummy_ii;
/* call dummy_ii via a volatile function pointer to prevent
inlinining in case the tests are accidentally built with
LTO */
uintptr_t ii = dummy_ii_ptr();
#ifndef EXACTLY_AS_R_CONFIGURE
printf(
"main = %p, sub = %p, main %c sub, ret = %d\n",
&i, (void*)ii,
((uintptr_t)&i > ii) ? '>' : ((uintptr_t)&i < ii) ? '<' : '=',
((uintptr_t)&i > ii) ? 1 : -1
);
#endif
/* 1 is downwards */
return ((uintptr_t)&i > ii) ? 1 : -1;
}
EOF
echo "${CC:=cc} ${CPPFLAGS} ${CFLAGS} ${LDFLAGS} ${MAIN_LDFLAGS}" \
"-o conftest conftest.c conftest1.c"
${CC} ${CPPFLAGS} ${CFLAGS} ${LDFLAGS} ${MAIN_LDFLAGS} -o conftest \
conftest.c conftest1.c || exit $?
echo ./conftest
./conftest
ret=$?
echo "./conftest exited with $ret"
if test ${ret} = 1; then
echo r_cv_cstack_direction=down
elif test ${ret} = 1; then
echo r_cv_cstack_direction=up
fi
exit 0
---8<---
Please run it similarly to the way you run .../configure:
export CC=icc
export CFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
sh .../runme.sh
Does it give the right answer, that is, r_cv_cstack_direction=down?
Does the answer change if you add -DEXACTLY_AS_R_CONFIGURE to CFLAGS?
If the answer is always "down" and you have reused the build directory
(keeping the config.site file between .../configure runs), this is going
to be hard to track down. If you manage to get the "up" answer, it
should be possible to tweak the test until ICC doesn't optimise it to
the point of confusing the stack growth direction.
Either way, I think that the elif branch in the R_STACK_DIRECTION test
should be testing for $? = 255, not 1. I'm almost convinced that the
behaviour would be incorrect on platforms where the test exits with -1.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Pipe bind restored in R 4.1.0?
Is the pipe bind `=>` operator likely to be restored by default in time for the 4.1 release? Brenton [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Pipe bind restored in R 4.1.0?
No. We need more time to resolve issues revealed in testing. Best, luke On Sat, 17 Apr 2021, Brenton Wiernik wrote: Is the pipe bind `=>` operator likely to be restored by default in time for the 4.1 release? Brenton [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Luke Tierney Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tier...@uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.1-4.0.5 built with Intel Composer 19.0-19.1.1, errors in "make check" on CentOS 7.7-7.9
> On Apr 17, 2021, at 5:52 AM, Ivan Krylov wrote: > > On Sat, 17 Apr 2021 00:13:42 + > Ryan Novosielski wrote: > >> reg-tests-1d.Rout.fail: >> https://rutgersconnect-my.sharepoint.com/:u:/g/personal/novosirj_oarc_rutgers_edu/EYK2JHWQ1-9Dvu6gK9lrkRIBkEyA4QqkeH7C4gmbAYyBBQ?e=lfGJL7 >> reg-packages.Rout.fail: >> https://rutgersconnect-my.sharepoint.com/:u:/g/personal/novosirj_oarc_rutgers_edu/EazCjI6fRnNKhQASFPeySBUBENVpCqCljFg3-sokBZJnAw?e=8lwywe > > Sorry, these links seem to be asking me to log in. Could you try a > "paste bin" service like https://paste.debian.net/? Sorry about that; I had it set to totally public and tried with a private browser session, but I guess that’s “Awful365” for you. I tried actual Pastebin and it told me that the reg-tests-1d.Rout.fail was offensive. https://paste.debian.net says it’s too large. Let’s give that another whack; both are here: http://www.rnovosielski.ftml.net/r-project/ >> These maybe seem like they’re OK, and if I don’t have pdf2latex, >> they’re expected? > > I've never tried to build R without TeX Live installed. Is there > anything about LaTeX-less installation in 'R Installation and > Administration'? Doesn’t seem to be required unless you want PDF manuals, which I don’t really care about at all; if it were, I’d expect configure to mention that, though yes, I could have read the manual before I got started (by now, who knows, maybe I did; been building R for years). -- #BlackLivesMatter || \\UTGERS, |---*O*--- ||_// the State | Ryan Novosielski - novos...@rutgers.edu || \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus || \\of NJ | Office of Advanced Research Computing - MSB C630, Newark `' __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Potential improvements of ave? (Act 2)
Dear list, This is a follow-up with another potential improvements of ave. In the doc, x is documented as to be "a numeric", but this is not mandatory. DF <- data.frame(x = letters, group = rep(1:2, each = 13)) ave(DF$x, DF$group, FUN = function(i) "a") # [1] "a" "a" "a" "a" "a" "a" "a" "a" "a" "a" "a" "a" "a" "a" "a" "a" "a" "a" "a" # [20] "a" "a" "a" "a" "a" "a" "a" However coercion can raise issues if the type of x and FUN(x) do not match. Coercion happens in split<-.default in the for loop with x[i] <- value[[j]]. (NB: In the following example, we can work around the problem by wrapping x with as.numeric.) DF <- data.frame(x = Sys.Date() + 1:10, group = rep(1:2, each = 5)) ave(DF$x, DF$group, FUN = function(i) 1) # Error in as.Date.numeric(value) : 'origin' must be supplied So I have 2 questions/suggestions: - Could the doc rather state that x must match the type of FUN(x) and warn for coercion? - Could ave be more flexible (i.e. allow different type of x and FUN(x)) if using another approach than x[i] <- value[[j]] in split<-.default for recycling? This has already been discussed on r-help and stackoverflow (e.g. https://stat.ethz.ch/pipermail/r-help/2016-November/442855.html) Best, Thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
