Re: [Rd] Patches for CVE-2024-27322
svn diff -c 86235 ~/r-devel/R (or 86238 for the port to the release branch) should be easily backported. (CC Luke in case there is more to it) - pd > On 30 Apr 2024, at 11:28 , Iñaki Ucar wrote: > > Dear R-core, > > I just received notification of CVE-2024-27322 [1] in RedHat's Bugzilla. We > updated R to v4.4.0 in Fedora rawhide, F40, EPEL9 and EPEL8, so no problem > there. However, F38 and F39 will stay at v4.3.3, and I was wondering if > there's a specific patch available, or if you could point me to the commits > that fixed the issue, so that we can cherry-pick them for F38 and F39. > Thanks. > > [1] https://nvd.nist.gov/vuln/detail/CVE-2024-27322 > > Best, > -- > Iñaki Úcar > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] read.csv
Hum...
This boils down to
> as.numeric("1.23e")
[1] 1.23
> as.numeric("1.23e-")
[1] 1.23
> as.numeric("1.23e+")
[1] 1.23
which in turn comes from this code in src/main/util.c (function R_strtod)
if (*p == 'e' || *p == 'E') {
int expsign = 1;
switch(*++p) {
case '-': expsign = -1;
case '+': p++;
default: ;
}
for (n = 0; *p >= '0' && *p <= '9'; p++) n = (n < MAX_EXPONENT_PREFIX)
? n * 10 + (*p - '0') : n;
expn += expsign * n;
}
which sets the exponent to zero even if the for loop terminates immediately.
This might qualify as a bug, as it differs from the C function strtod which
accepts
"A sequence of digits, optionally containing a decimal-point character (.),
optionally followed by an exponent part (an e or E character followed by an
optional sign and a sequence of digits)."
[Of course, there would be nothing to stop e.g. "1433E1" from being converted
to numeric.]
-pd
> On 16 Apr 2024, at 12:46 , jing hua zhao wrote:
>
> Dear R-developers,
>
> I came to a somewhat unexpected behaviour of read.csv() which is trivial but
> worthwhile to note -- my data involves a protein named "1433E" but to save
> space I drop the quote so it becomes,
>
> Gene,SNP,prot,log10p
> YWHAE,13:62129097_C_T,1433E,7.35
> YWHAE,4:72617557_T_TA,1433E,7.73
>
> Both read.cv() and readr::read_csv() consider prot(ein) name as (possibly
> confused by scientific notation) numeric 1433 which only alerts me when I
> tried to combine data,
>
> all_data <- data.frame()
> for (protein in proteins[1:7])
> {
> cat(protein,":\n")
> f <- paste0(protein,".csv")
> if(file.exists(f))
> {
> p <- read.csv(f)
> print(p)
> if(nrow(p)>0) all_data <- bind_rows(all_data,p)
> }
> }
>
> proteins[1:7]
> [1] "1433B" "1433E" "1433F" "1433G" "1433S" "1433T" "1433Z"
>
> dplyr::bind_rows() failed to work due to incompatible types nevertheless
> rbind() went ahead without warnings.
>
> Best wishes,
>
>
> Jing Hua
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.4.0 scheduled for April 24
Full schedule is available on developer.r-project.org (pending update from SVN). -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.3.3 is released
The build system rolled up R-4.3.3.tar.gz and .xz (codename "Angel Food Cake")
this morning.
This is a minor update, intended as the wrap-up release for the 4.3.x series.
This also marks the 6th anniversary of R-1.0.0. (2000-02-29)
The list below details the changes in this release.
You can get the source code from
https://cran.r-project.org/src/base/R-4/R-4.3.3.tar.gz
https://cran.r-project.org/src/base/R-4/R-4.3.3.tar.xz
or wait for it to be mirrored at a CRAN site nearer to you.
Binaries for various platforms will appear in due course.
For the R Core Team,
Peter Dalgaard
These are the checksums (md5 and SHA-256) for the freshly created files, in
case you wish
to check that they are uncorrupted:
MD5 (AUTHORS) = 320967884b547734d6279dedbc739dd4
MD5 (COPYING) = eb723b61539feef013de476e68b5c50a
MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343
MD5 (FAQ) = 97a3ddc25aab502a70bfb1a79ab6f862
MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b
MD5 (NEWS) = 0aa4babeb5349c3abc6fb02700e8cf53
MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8
MD5 (NEWS.1) = 4108ab429e768e29b1c3b418c224246e
MD5 (NEWS.2) = b38d94569700664205a76a7de836ba83
MD5 (NEWS.3) = e55ed2c8a547b827b46e08eb7137ba23
MD5 (R-latest.tar.gz) = 4de100b35e3614c19df5e95e483cc3c3
MD5 (R-latest.tar.xz) = 5602f5996107c346dba12a16e866d2e2
MD5 (README) = f468f281c919665e276a1b691decbbe6
MD5 (RESOURCES) = a79b9b338cab09bd665f6b62ac6f455b
MD5 (THANKS) = 45b6d2e88a6ecb5b24fa33a781351cd5
MD5 (VERSION-INFO.dcf) = becc8fce6e97db1703f9ca6d80e36c9d
MD5 (R-4/R-4.3.3.tar.gz) = 4de100b35e3614c19df5e95e483cc3c3
MD5 (R-4/R-4.3.3.tar.xz) = 5602f5996107c346dba12a16e866d2e2
60a0d150e6fc1f424be76ad7b645d236b56e747692a4679f81ce6536c550e949 AUTHORS
e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING
6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB
3a47bca1e2a7db27c0ca12be388c238e2608ff2f768e627650a71a0ffc826038 FAQ
f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL
f28b88bf20aa2a0078214b89353985680c53092d55f83e59b8295e61ad1150e0 NEWS
4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0
5de7657c5e58e481403c0dd1a74a5c090b3ef481ce75a91dfe05d4b03f63163f NEWS.1
cde079b6beab7d700d3d4ecda494e2681ad3b7f8fab13b68be090f949393ec62 NEWS.2
1910a2405300b9bc7c76beeb0753a5249cf799afe175ce28f8d782fab723e012 NEWS.3
80851231393b85bf3877ee9e39b282e750ed864c5ec60cbd68e6e139f0520330
R-latest.tar.gz
9b4c5f4cabab23f38e72fee36d98772c640a97305d06ce6e1a6a73e82b850954
R-latest.tar.xz
2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README
8b7d3856100220f4555d4d57140829f2e81c27eccec5b441f5dce616e9ec9061 RESOURCES
8319c5415de58ee10d4bc058d79c370fd8e6b2ad09e25d7a1e04b74ca5f380a6 THANKS
b8c2534c643ffcd942e8df370a4970c913be5dfc24e687bb12d609e974308aef
VERSION-INFO.dcf
80851231393b85bf3877ee9e39b282e750ed864c5ec60cbd68e6e139f0520330
R-4/R-4.3.3.tar.gz
9b4c5f4cabab23f38e72fee36d98772c640a97305d06ce6e1a6a73e82b850954
R-4/R-4.3.3.tar.xz
This is the relevant part of the NEWS file
CHANGES IN R 4.3.3:
NEW FEATURES:
* iconv() now fixes up variant encoding names such as "utf8"
case-insensitively.
DEPRECATED AND DEFUNCT:
* The legacy encoding = "MacRoman" is deprecated in pdf() and
postscript(): support was incomplete in earlier versions of R.
BUG FIXES:
* Arguments are now properly forwarded to methods on S4 generics
with ... in the middle of their formal arguments. This was broken
for the case when a method introduced an argument but did not
include ... in its own formals. Thanks to Herv'e Pag`es for the
report PR#18538.
* Some invalid file arguments to pictex(), postscript() and xfig()
opened a file called NA rather than throw an error. These
included postscript(NULL) (which some people expected to work
like pdf(NULL)).
* Passing filename = NA to svg(), cairo_pdf(), cairo_ps() or the
Cairo-based bitmap devices opened a file called NA: it now throws
an error.
* quartz(file = NA) opened a file called NA, including when used as
a Quartz-based bitmap device. It now gives an error.
* rank() now works, fixing PR#18617, thanks to Ilia
Kats.
* seq.int() did not adequately check its length.out argument.
* match(, .) is correct again for differing time zones,
ditto for "POSIXlt", fixing PR#18618 reported by Bastian Klein.
* drop.terms(*, dropx = <0-length>) now works, fixing PR#18563 as
proposed by Mikael Jagan.
* drop.terms(*) keeps + offset(.) terms when it should, PR#18565,
and drop.terms() no longer makes up a response, PR#18566, fixing
both bugs thanks to Mikael Jagan.
* getS3method("t", "test") no longer finds the t.test() function,
fixing PR#18627.
* pdf() and postscript() support for the documented Adobe encodings
Re: [Rd] Tcl socket server (tcltk) does not work any more on R 4.3.2
The obvious problem with
while (Tcl_DoOneEvent(TCL_DONT_WAIT) && max_ev) max_ev—;
is that once something does the http server thing, you'll be running
Tcl_DoOneEvent max_ev times, _every_ time you hit TclSpinLoop.
I wonder it we could some sort of hybrid between this and Tcl_ServiceAll()?
Like, calling Tcl_DoOneEvent once before/after Tcl_ServiceAll().
- Peter
> On 21 Feb 2024, at 17:04 , Tomas Kalibera wrote:
>
>
> On 2/21/24 08:01, webmail.gandi.net wrote:
>> Thank you, Ivan for this investigation. I inspected the R changes file
>> (https://cran.r-project.org/doc/manuals/r-devel/NEWS.html) and found nothing
>> about this. I should inspect the sources too!
>>
>> It could possibly break other Tcl/Tk related stuff. The doc about
>> Tcl_ServiceAll and Tcl_DoOneEvent is confusing. On one hand, it says when
>> Tcl is used from an external program, Tcl_ServiceAll should be used in its
>> event loop instead of Tcl_DoOneEvent (and the change in the latest R
>> versions goes in that direction). But in the other hand, it is indicated
>> that Tcl_ServiceAll does not always handle all Tcl events and extra
>> Tcl_DoOneEvent should be called in this case. I think we spotted one case
>> where Tcl_ServiceAll is not doing its job correctly. There may be others.
>>
>> Since the {tcltk} package was working fine with "while
>> (Tcl_DoOneEvent(TCL_DONT_WAIT) && max_ev) max_ev—;", unless there is a clear
>> performance enhancement with "while (i-- && Tcl_ServiceAll())", it would
>> perhaps be wise to revert this back.
>
> Yes, for now I've done that in R-devel. The Tcl documentation is really hard
> to follow, but debugging reveals that Tcl_ServiceAll() doesn't queue new
> events, as also Ivan reports.
>
> Tomas
>
>>
>> Indeed, when I use this on the server side with R 4.3.2:
>>
>> library(tcltk)
>> cmd <- r"(
>> proc accept {chan addr port} { ;# Make a proc to accept connections
>>puts "$addr:$port says [gets $chan]" ;# Receive a string
>>puts $chan goodbye ;# Send a string
>>close $chan ;# Close the socket (automatically
>> flushes)
>> } ;#
>> socket -server accept 12345 ;# Create a server socket)"
>> .Tcl(cmd)
>> .Tcl("vwait myvar")
>>
>> It works again as expected. And vwait is known to call Tcl_DoOneEvent. Of
>> course, in this case, R is blocked and waits for the `myvar` variable on the
>> Tcl side. Anyway, the problem seems to be really in Tcl_ServiceAll not
>> catching all Tcl events.
>>
>> All the best,
>>
>> Philippe
>>
>> ..<°}))><
>> ) ) ) ) )
>> ( ( ( ( (Prof. Philippe Grosjean
>> ) ) ) ) )
>> ( ( ( ( (Numerical Ecology
>> ) ) ) ) ) Mons University, Belgium
>> ( ( ( ( (
>> ..
>>
>>> Le 20 févr. 2024 à 17:13, Ivan Krylov via R-devel a
>>> écrit :
>>>
>>> В Tue, 20 Feb 2024 12:27:35 +0100
>>> "webmail.gandi.net" пишет:
>>>
>>>> When R process #1 is R 4.2.3, it works as expected (whatever version
>>>> of R #2). When R process #1 is R 4.3.2, nothing is sent or received
>>>> through the socket apparently, but no error is issued and process #2
>>>> seems to be able to connect to the socket.
>>> The difference is related to the change in
>>> src/library/tcltk/src/tcltk_unix.c.
>>>
>>> In R-4.2.1, the function static void TclSpinLoop(void *data) says:
>>>
>>>int max_ev = 100;
>>>/* Tcl_ServiceAll is not enough here, for reasons that escape me */
>>>while (Tcl_DoOneEvent(TCL_DONT_WAIT) && max_ev) max_ev--;
>>>
>>> In R-devel, the function instead says:
>>>
>>>int i = R_TCL_SPIN_MAX;
>>>while (i-- && Tcl_ServiceAll())
>>>;
>>>
>>> Manually calling Tcl_DoOneEvent(0) from the debugger at this point
>>> makes the Tcl code respond to the connection. Tcl_ServiceAll() seems to
>>> be still not enough. I'll try reading Tcl documentation to investigate
>>> this further.
>>>
>>> --
>>> Best regards,
>>> Ivan
>>>
>>> __
>>> 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
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Tcl socket server (tcltk) does not work any more on R 4.3.2
I don't think we're going to fix this before 4.3.3. Given that it has gone
unnoticed since June 2022 (yes '22) and that tampering in this area has a
history of popping up complications in other areas, I think we should leave it
alone until 4.4.0.
(I see that Ivan and Tomas has been on the issue since I started writing, but
the above probably still holds true.)
- Peter D.
> On 21 Feb 2024, at 08:01 , webmail.gandi.net wrote:
>
> Thank you, Ivan for this investigation. I inspected the R changes file
> (https://cran.r-project.org/doc/manuals/r-devel/NEWS.html) and found nothing
> about this. I should inspect the sources too!
>
> It could possibly break other Tcl/Tk related stuff. The doc about
> Tcl_ServiceAll and Tcl_DoOneEvent is confusing. On one hand, it says when Tcl
> is used from an external program, Tcl_ServiceAll should be used in its event
> loop instead of Tcl_DoOneEvent (and the change in the latest R versions goes
> in that direction). But in the other hand, it is indicated that
> Tcl_ServiceAll does not always handle all Tcl events and extra Tcl_DoOneEvent
> should be called in this case. I think we spotted one case where
> Tcl_ServiceAll is not doing its job correctly. There may be others.
>
> Since the {tcltk} package was working fine with "while
> (Tcl_DoOneEvent(TCL_DONT_WAIT) && max_ev) max_ev—;", unless there is a clear
> performance enhancement with "while (i-- && Tcl_ServiceAll())", it would
> perhaps be wise to revert this back.
>
> Indeed, when I use this on the server side with R 4.3.2:
>
> library(tcltk)
> cmd <- r"(
> proc accept {chan addr port} { ;# Make a proc to accept connections
> puts "$addr:$port says [gets $chan]" ;# Receive a string
> puts $chan goodbye ;# Send a string
> close $chan ;# Close the socket (automatically
> flushes)
> } ;#
> socket -server accept 12345 ;# Create a server socket)"
> .Tcl(cmd)
> .Tcl("vwait myvar")
>
> It works again as expected. And vwait is known to call Tcl_DoOneEvent. Of
> course, in this case, R is blocked and waits for the `myvar` variable on the
> Tcl side. Anyway, the problem seems to be really in Tcl_ServiceAll not
> catching all Tcl events.
>
> All the best,
>
> Philippe
>
> ..<°}))><
> ) ) ) ) )
> ( ( ( ( (Prof. Philippe Grosjean
> ) ) ) ) )
> ( ( ( ( (Numerical Ecology
> ) ) ) ) ) Mons University, Belgium
> ( ( ( ( (
> ..
>
>> Le 20 févr. 2024 à 17:13, Ivan Krylov via R-devel a
>> écrit :
>>
>> В Tue, 20 Feb 2024 12:27:35 +0100
>> "webmail.gandi.net" пишет:
>>
>>> When R process #1 is R 4.2.3, it works as expected (whatever version
>>> of R #2). When R process #1 is R 4.3.2, nothing is sent or received
>>> through the socket apparently, but no error is issued and process #2
>>> seems to be able to connect to the socket.
>>
>> The difference is related to the change in
>> src/library/tcltk/src/tcltk_unix.c.
>>
>> In R-4.2.1, the function static void TclSpinLoop(void *data) says:
>>
>> int max_ev = 100;
>> /* Tcl_ServiceAll is not enough here, for reasons that escape me */
>> while (Tcl_DoOneEvent(TCL_DONT_WAIT) && max_ev) max_ev--;
>>
>> In R-devel, the function instead says:
>>
>> int i = R_TCL_SPIN_MAX;
>> while (i-- && Tcl_ServiceAll())
>> ;
>>
>> Manually calling Tcl_DoOneEvent(0) from the debugger at this point
>> makes the Tcl code respond to the connection. Tcl_ServiceAll() seems to
>> be still not enough. I'll try reading Tcl documentation to investigate
>> this further.
>>
>> --
>> Best regards,
>> Ivan
>>
>> __
>> 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
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.3.3 scheduled for February 29
Full schedule available on developer.r-project.org in a short while. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ADA Compliance
Yes, Jonathon Godfrey, who wrote the r-devel/2022-December mail (and is himself blind), would be my standard go-to guy in matters relating to visual impairment, screen readers and all that. Peter D. > On 13 Jan 2024, at 00:14 , Ben Bolker wrote: > > I would be very surprised if anyone had written up a VPAT > <https://www.section508.gov/sell/vpat/> for R. > > It won't help you with the bureaucratic requirements, but R is in fact very > accessible to visually impaired users: e.g. see > > https://community.rstudio.com/t/accessibility-of-r-rstudio-compared-to-excel-for-student-that-is-legally-blind/103849/3 > > From https://github.com/ajrgodfrey/BrailleR > > > R is perhaps the most blind-friendly statistical software option because > > all scripts can be written in plain text, using the text editor a user > > prefers, and all output can be saved in a wide range of file formats. The > > advent of R markdown and other reproducible research techniques can offer > > the blind user a degree of efficiency that is not offered in many other > > statistical software options. In addition, the processed Rmd files are > > usually HTML which are the best supported files in terms of screen reader > > development. > > (And there is continued attention to making sure R stays accessible in this > way: https://stat.ethz.ch/pipermail/r-devel/2022-December/082180.html; > https://stat.ethz.ch/pipermail/r-devel/2023-February/082313.html) > > R is also easy to use without a mouse, which should improve accessibility > for users with neuromuscular conditions. > > cheers >Ben Bolker > > > > > On 2024-01-12 2:50 p.m., Hunter, Zayne via R-devel wrote: >> Hello, >> I am working with Ball State University to obtain a license of R. As part of >> our requirements for obtaining new software, we must review the VPAT for ADA >> compliance. Can you provide this information for me? >> Thanks, >> Zayne Hunter >> Technology Advisor & Vendor Relations Manager >> Ball State University >> zayne.hun...@bsu.edu >> (765)285-7853 >> [[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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?
Hmm, it is not actually at odds with help(c), it is just that the autocoercion works different that it used to, so that as.complex(NA) == as.complex(NA_real) == NA_real_+0i) which now differs from NA_complex although both print as NA. I haven't been quite alert when this change was discussed, but it does look a bit unfortunate that usage patterns like c(NA, 0+1i) does not give complex NA for the 1st component, effectively changing the interpretation from "I don't know what this is" to "I don't know what this is but I'm sure it is on the real line". Also, notice that things like > Im(scan(text= "NA 0+1i", what=complex())) Read 2 items [1] NA 1 and > Im(as.complex(c(NA,"0+1i"))) [1] NA 1 but Martin probably thought more deeply about this? -pd > On 5 Nov 2023, at 18:41 , Michael Chirico wrote: > > This is another follow-up to the thread from September "Recent changes to > as.complex(NA_real_)". > > A test in data.table was broken by the changes for NA coercion to complex; > the breakage essentially comes from > > c(NA, 0+1i) > # vs > c(as.complex(NA), 0+1i) > > The former is the output we tested against; the latter is essentially (via > coerceVector() in C) what's generated by our data.table::shift() > > However, these are now (r85472) different: > > Im(c(NA, 0+1i)) > # [1] NA 1 > Im(c(as.complex(NA), 0+1i)) > # [1] 0 1 > > The former matches the behavior of directly using NA_complex_: > > Im(c(NA_complex_, 0+1i)) > # [1] NA 1 > > On R4.3.2, they both match the NA_complex_ behavior: > Im(c(NA, 0+1i)) > # [1] NA 1 > Im(c(as.complex(NA), 0+1i)) > # [1] NA 1 > > Is this intended behavior, does something need to be updated for c() as > well? > > Certainly it's messing with my understanding of how c() behaves, e.g. in ?c > >> All arguments are coerced to a common type which is the type of the > returned value > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.3.2 is released
The build system rolled up R-4.3.2.tar.gz (codename "Eye Holes") this morning.
This is a minor update, with a few bug fixes.
The list below details the changes in this release.
You can get the source code from
https://cran.r-project.org/src/base/R-4/R-4.3.2.tar.gz
or wait for it to be mirrored at a CRAN site nearer to you.
Binaries for various platforms will appear in due course.
For the R Core Team,
Peter Dalgaard
These are the checksums (md5 and SHA-256) for the freshly created files, in
case you wish
to check that they are uncorrupted:
MD5 (AUTHORS) = 320967884b547734d6279dedbc739dd4
MD5 (COPYING) = eb723b61539feef013de476e68b5c50a
MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343
MD5 (FAQ) = 97a3ddc25aab502a70bfb1a79ab6f862
MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b
MD5 (NEWS) = b9ad3b7a9f54856444ec9849a69b18e3
MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8
MD5 (NEWS.1) = 4108ab429e768e29b1c3b418c224246e
MD5 (NEWS.2) = b38d94569700664205a76a7de836ba83
MD5 (NEWS.3) = e55ed2c8a547b827b46e08eb7137ba23
MD5 (R-latest.tar.gz) = 3217f2606bbde5a76fe4deaa4b4d3321
MD5 (README) = f468f281c919665e276a1b691decbbe6
MD5 (RESOURCES) = a79b9b338cab09bd665f6b62ac6f455b
MD5 (THANKS) = 45b6d2e88a6ecb5b24fa33a781351cd5
MD5 (VERSION-INFO.dcf) = 8d6576e0a33475e8b6dcb61f8e49a2b4
MD5 (R-4/R-4.3.2.tar.gz) = 3217f2606bbde5a76fe4deaa4b4d3321
60a0d150e6fc1f424be76ad7b645d236b56e747692a4679f81ce6536c550e949 AUTHORS
e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING
6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB
3a47bca1e2a7db27c0ca12be388c238e2608ff2f768e627650a71a0ffc826038 FAQ
f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL
ec6844344589b717144d51ca3d5d1dbe5bc453d69287c06430f9bb2263abe01f NEWS
4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0
5de7657c5e58e481403c0dd1a74a5c090b3ef481ce75a91dfe05d4b03f63163f NEWS.1
cde079b6beab7d700d3d4ecda494e2681ad3b7f8fab13b68be090f949393ec62 NEWS.2
1910a2405300b9bc7c76beeb0753a5249cf799afe175ce28f8d782fab723e012 NEWS.3
b3f5760ac2eee8026a3f0eefcb25b47723d978038eee8e844762094c860c452a
R-latest.tar.gz
2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README
8b7d3856100220f4555d4d57140829f2e81c27eccec5b441f5dce616e9ec9061 RESOURCES
8319c5415de58ee10d4bc058d79c370fd8e6b2ad09e25d7a1e04b74ca5f380a6 THANKS
f3acaa77b0034a44c9c9b02767a2d383a7c2c2e2a3e7fec929fa20c5102304c5
VERSION-INFO.dcf
b3f5760ac2eee8026a3f0eefcb25b47723d978038eee8e844762094c860c452a
R-4/R-4.3.2.tar.gz
This is the relevant part of the NEWS file
CHANGES IN R 4.3.2:
NEW FEATURES:
* The default initialization of the "repos" option from the
repositories file at startup can be skipped by setting
environment variable R_REPOSITORIES to NULL such that
getOption("repos") is empty if not set elsewhere.
* qr.X() is now an implicit S4 generic in methods.
* iconv(to = "ASCII//TRANSLIT") is emulated using substitution on
platforms which do not support it (notably Alpine Linux). This
should give a human-readable conversion in ASCII on all platforms
(rather than NA_character_).
* trans3d() gains options continuous and verbose addressing the
problem of possible "wrap around" when projecting too long
curves, as reported by Achim Zeileis in PR#18537.
* tools::showNonASCII() has been rewritten to work better on macOS
14 (which has a changed implementation of iconv()).
* tiff(type = "quartz") (the default on macOS) now warns if
compression is specified: it continues to be ignored.
INSTALLATION on a UNIX-ALIKE:
* There is some support for building with Intel's LLVM-based
compilers on x86_64 Linux, such as (C) icx, (C++) ipcx and
(Fortran) ifx from oneAPI 2023.x.y.
* There is support for using LLVM's flang-new as the Fortran
compiler from LLVM 16.0.x (preferably 17.0.0 or later).
UTILITIES:
* R CMD check reports the use of the Fortran 90 random number
generator RANDOM_NUMBER() and the subroutines to initialize it.
'Writing R Extensions' has example code to use R's RNGs from
Fortran.
BUG FIXES:
* substr(x, n, L) <- cc now works (more) correctly for multibyte
UTF-8 strings x when L > nchar(x), thanks to a report and patch
by 'Architect 95'.
* contrib.url(character()) now returns 0-length character() as
documented, which also avoids spurious warnings from
available.packages() et al. in the edge case of an empty vector
of repository URLs.
* readChar(., 4e8) no longer fails, thanks to Kodi Arfer's report
(PR#18557).
* lapply(, as.data.frame) no longer warns falsely for some
base vector components.
* Communication between parent and child processes in the multicore
part of parallel could fail on platforms that do not s
[Rd] R 4.3.2 scheduled for October 31
Full schedule available on developer.r-project.org in a short while. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question about an R idiom: eval()ing a quoted block
In the case of power.t.test, there is a situation where you want to create 4
different functions with the same function body, in order to pass them to
uniroot(). I think that at the time, it just seemed convenient to express that
idea with a quote-eval (macro-like) construction, rather than figure out how to
do it with functions. I suppose that it could have been done neatly enough
along the lines of
g <- function(x1, x2, x3, x4)
{
f <- function(x1, x2, x3, x4) {...body...}
if (is.null(x1)
x1 <- uniroot(function(x1) {target - f(x1, x2, x3, x4)}, )$root
}
This adds an extra layer of function call, but probably makes the byte compiler
happier!
You might also use the ... argument to uniroot() as in
x1 <- uniroot(f, x2=x2, x3=x3, x4=x4, ..other args..)$root
but that gets a bit clunky.
-pd
> On 12 Jul 2023, at 00:01 , Ben Bolker wrote:
>
> In a few places in the R source code, such as the $initialize element of
> `family` objects, and in the body of power.t.test() (possibly other power.*
> functions), sets of instructions that will need to be run later are
> encapsulated by saving them as an expression and later applying eval(),
> rather than as a function. This seems weird to me; the only reason I can
> think of for doing it this way is to avoid having to pass back multiple
> objects and assign them in the calling environment (since R doesn't have a
> particularly nice form of Python's tuple-unpacking idiom).
>
> Am I missing something?
>
> cheers
> Ben
>
>
> https://github.com/r-devel/r-svn/blob/eac72e66a4d2c2aba50867bd80643b978febf5a3/src/library/stats/R/power.R#L38-L52
>
> https://github.com/r-devel/r-svn/blob/master/src/library/stats/R/family.R#L166-L171
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] https://cran.r-project.org/src/base-prerelease/ is not updating
To be more precise, the thing that happened was that Simon had changed the installation directory for texi2any with the 4.3.0 Mac binaries. The release manager (me) needed to update materials for Mon-Wed oral exams, so upgraded to a recent prerelease. This broke the nightly builds because it would no longer build the FAQ and RESOURCES files. Being busy with exams, I didn't notice until Gábor chimed in. Fortunately, there was still a little time before release so that I could fix up the situation. So, thank you very much to Gábor! To everyone: It is very helpful if you keep an eye on such matters, not only for testing whether we fixed your favourite bug, but also because the whole prerelease regime can be a bit brittle. R Core only has a limited set of (aging!) eyes and we may all become distracted by our regular chores. - Peter D. > On 15 Jun 2023, at 18:23 , peter dalgaard wrote: > > Yes that was not intentional. Unexpected interaction between installed R > version and build tools. Should be OK now. > > -pd > >> On 14 Jun 2023, at 14:57 , Gábor Csárdi wrote: >> >> https://cran.r-project.org/src/base-prerelease/ has not updated for >> about a week now, I guess this is not intentional? >> >> Best, >> Gabor >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > -- > Peter Dalgaard, Professor, > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Office: A 4.23 > Email: pd@cbs.dk Priv: pda...@gmail.com > -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Parts of test in datetime3.R not working
Yep, that is a pretty straightforward blunder. It's "stopifnot <- function(...,
exprs =", so partial matching does not happen.
Fixed in R-patched and R-devel (a last-minute addition to 4.3.1 during code
freeze would only happen with truly disastrous bugs).
Peter
> On 15 Jun 2023, at 11:57 , Korpela Mikko
> wrote:
>
> In test file datetime3.R, one call to stopifnot() has an argument named
> "expr" which should probably be "exprs". There are three tests wrapped in
> braces of which only the last one, "omitted 195 entries", is currently
> checked.
>
> Proposed patch:
>
> --- tests/datetime3.R (revision 84544)
> +++ tests/datetime3.R (working copy)
> @@ -45,7 +45,7 @@
> c2 <- capture.output(print(dt, max = 6))
> writeLines(tail(cc, 4))
> writeLines(c2)
> -stopifnot(expr = {
> +stopifnot(exprs = {
> grepl("omitted 151 entries", tail(cc, 1))
> !anyDuplicated(tail(cc, 2))
> grepl("omitted 195 entries", tail(c2, 1))
>
> --
> Best regards,
> Mikko
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] why does [A-Z] include 'T' in an Estonian locale?
Just for amusement: Similar messups occur with Danish and its three extra
letters:
> Sys.setlocale("LC_ALL", "da_DK")
[1] "da_DK/da_DK/da_DK/C/da_DK/en_US.UTF-8"
> sort(c(LETTERS,"Æ","Ø","Å"))
[1] "A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" "M" "N" "O" "P" "Q" "R" "S"
[20] "T" "U" "V" "W" "X" "Y" "Z" "Æ" "Ø" "Å"
> grepl("[A-Å]", "Ø")
[1] FALSE
> grepl("[A-Å]", "Æ")
[1] FALSE
> grepl("[A-Æ]", "Å")
[1] TRUE
> grepl("[A-Æ]", "Ø")
[1] FALSE
> grepl("[A-Ø]", "Å")
[1] TRUE
> grepl("[A-Ø]", "Æ")
[1] TRUE
So for character ranges, the order is Å,Æ,Ø (which is how they'd collate in
Swedish, except that Swedish uses diacriticals rather than Æ and Ø).
> Sys.setlocale("LC_ALL", "sv_SE")
[1] "sv_SE/sv_SE/sv_SE/C/sv_SE/en_US.UTF-8"
> sort(c(LETTERS,"Æ","Ø","Å"))
[1] "A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" "M" "N" "O" "P" "Q" "R" "S"
[20] "T" "U" "V" "W" "X" "Y" "Z" "Å" "Æ" "Ø"
> sort(c(LETTERS,"Ä","Ö","Å"))
[1] "A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" "M" "N" "O" "P" "Q" "R" "S"
[20] "T" "U" "V" "W" "X" "Y" "Z" "Å" "Ä" "Ö"
> On 30 May 2023, at 17:45 , Ben Bolker wrote:
>
> Inspired by this old Stack Overflow question
>
> https://stackoverflow.com/questions/19765610/when-does-locale-affect-rs-regular-expressions
>
> I was wondering why this is TRUE:
>
> Sys.setlocale("LC_ALL", "et_EE")
> grepl("[A-Z]", "T")
>
> TRE's documentation at
> <https://laurikari.net/tre/documentation/regex-syntax/> says that a range "is
> shorthand for the full range of characters between those two [endpoints]
> (inclusive) in the collating sequence".
>
> Yet, T is *not* between A and Z in the Estonian collating sequence:
>
> sort(LETTERS)
> [1] "A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" "M" "N" "O" "P" "Q" "R"
> "S"
> [20] "Z" "T" "U" "V" "W" "X" "Y"
>
> I realize that this may be a question about TRE rather than about R *per se*
> (FWIW the grepl() result is also TRUE with `perl = TRUE`, so the question
> also applies to PCRE), but I'm wondering if anyone has any insights ... (and
> yes, I know that the correct answer is "use [:alpha:] and don't worry about
> it")
>
> (In contrast, the ICU engine underlying stringi/stringr says "[t]he
> characters to include are determined by Unicode code point ordering" - see
>
> https://stackoverflow.com/questions/76365426/does-stringrs-regex-engine-translate-a-z-into-abcdefghijklmnopqrstuvwyz/76366163#76366163
>
> for links)
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.3.1 is released
The build system rolled up R-4.3.1.tar.gz (codename "Beagle Scouts") this morning. This is a minor update, with a few bug fixes. The list below details the changes in this release. You can get the source code from https://cran.r-project.org/src/base/R-4/R-4.3.1.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard These are the checksums (md5 and SHA-256) for the freshly created files, in case you wish to check that they are uncorrupted: MD5 (AUTHORS) = 320967884b547734d6279dedbc739dd4 MD5 (COPYING) = eb723b61539feef013de476e68b5c50a MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343 MD5 (FAQ) = 97a3ddc25aab502a70bfb1a79ab6f862 MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b MD5 (NEWS) = 7ea998dffa2b8d4f5a6aee84c45a383a MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8 MD5 (NEWS.1) = 4108ab429e768e29b1c3b418c224246e MD5 (NEWS.2) = b38d94569700664205a76a7de836ba83 MD5 (NEWS.3) = e55ed2c8a547b827b46e08eb7137ba23 MD5 (R-latest.tar.gz) = b83cee497046d4aef649eb79e6df83e8 MD5 (README) = f468f281c919665e276a1b691decbbe6 MD5 (RESOURCES) = a79b9b338cab09bd665f6b62ac6f455b MD5 (THANKS) = 45b6d2e88a6ecb5b24fa33a781351cd5 MD5 (VERSION-INFO.dcf) = 3d4c6bf5bf44d34766f90ed67d05c34a MD5 (R-4/R-4.3.1.tar.gz) = b83cee497046d4aef649eb79e6df83e8 60a0d150e6fc1f424be76ad7b645d236b56e747692a4679f81ce6536c550e949 AUTHORS e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB 3a47bca1e2a7db27c0ca12be388c238e2608ff2f768e627650a71a0ffc826038 FAQ f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL a8167cfe28e748b67476d4a21a968cfa24d0935da89cd4514c483f45f3f2a83b NEWS 4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0 5de7657c5e58e481403c0dd1a74a5c090b3ef481ce75a91dfe05d4b03f63163f NEWS.1 cde079b6beab7d700d3d4ecda494e2681ad3b7f8fab13b68be090f949393ec62 NEWS.2 1910a2405300b9bc7c76beeb0753a5249cf799afe175ce28f8d782fab723e012 NEWS.3 8dd0bf24f1023c6f618c3b317383d291b4a494f40d73b983ac22ffea99e4ba99 R-latest.tar.gz 2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README 8b7d3856100220f4555d4d57140829f2e81c27eccec5b441f5dce616e9ec9061 RESOURCES 8319c5415de58ee10d4bc058d79c370fd8e6b2ad09e25d7a1e04b74ca5f380a6 THANKS 032260f31c56c011a9724930e356eac4d7ddfcaa63c559f95986063ede3bf91a VERSION-INFO.dcf 8dd0bf24f1023c6f618c3b317383d291b4a494f40d73b983ac22ffea99e4ba99 R-4/R-4.3.1.tar.gz This is the relevant part of the NEWS file CHANGES IN R 4.3.1: C-LEVEL FACILITIES: * The C-level API version of R's integrate(), Rdqags() in Applic.h, now returns the correct number of integrand evaluations neval, fixing PR#18515 reported and diagnosed by Stephen Wade. * The C prototypes for LAPACK calls dspgv and dtptrs in R_exts/Lapack.h had one too many and one too few character length arguments - but this has not caused any known issues. To get the corrected prototypes, include #include // for PR18534fixed #ifdef PR18534fixed # define usePR18534fix 1 #endif #include in your C/C++ code (PR#18534). INSTALLATION: * Many of the checks of esoteric Internet operations and those using unreliable external sites have been moved to a new target that is not run by default and primarily intended for the core developers. To run them use cd tests; make test-Internet-dev BUG FIXES: * .S3methods(), typically called from methods(), again marks methods from package base as visible. Also, the visibility of non-base methods is again determined by the method's presence in search(). * tools::Rdiff() is now more robust against invalid strings, fixing installation tests on Windows without Rtools installed (PR#18530). * Fix (new) bug in hcl.colors(2, *), by Achim Zeileis (PR#18523). * head(., ) and tail(..) now produce more useful "Error in " error messages, fixing PR#18362. * Package code syntax on Windows is checked in UTF-8 when UTF-8 is the native encoding. * na.contiguous(x) now also returns the first run, when it is at the beginning and there is a later one of the same length; reported to R-devel, including a fix, by Georgi Boshnakov. Further, by default, it modifies only an existing attr(*,"tsp") but otherwise no longer sets one. * chol(, pivot = ) now gives a correct error or warning message (depending on pivot), thanks to Mikael Jagan's (PR#18541). -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@
Re: [Rd] https://cran.r-project.org/src/base-prerelease/ is not updating
Yes that was not intentional. Unexpected interaction between installed R version and build tools. Should be OK now. -pd > On 14 Jun 2023, at 14:57 , Gábor Csárdi wrote: > > https://cran.r-project.org/src/base-prerelease/ has not updated for > about a week now, I guess this is not intentional? > > Best, > Gabor > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.3.1 scheduled for June 16
Full schedule available on developer.r-project.org in a short while. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.3.0 scheduled for April 21
Full schedule is available on developer.r-project.org (pending update from SVN). -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.2.3 is released
The build system rolled up R-4.2.3.tar.gz (codename "Shortstop Beagle") this
morning.
The list below details the changes in this release.
You can get the source code from
https://cran.r-project.org/src/base/R-4/R-4.2.3.tar.gz
or wait for it to be mirrored at a CRAN site nearer to you.
Binaries for various platforms will appear in due course.
For the R Core Team,
Peter Dalgaard
These are the checksums (md5 and SHA-256) for the freshly created files, in
case you wish
to check that they are uncorrupted:
MD5 (AUTHORS) = 320967884b547734d6279dedbc739dd4
MD5 (COPYING) = eb723b61539feef013de476e68b5c50a
MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343
MD5 (FAQ) = 3f5d6539d3c4878cbbb74dcbee74447f
MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b
MD5 (NEWS) = 4a300bf9bd24e704614f036452355d23
MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8
MD5 (NEWS.1) = 4108ab429e768e29b1c3b418c224246e
MD5 (NEWS.2) = b38d94569700664205a76a7de836ba83
MD5 (NEWS.3) = e55ed2c8a547b827b46e08eb7137ba23
MD5 (R-latest.tar.gz) = ebfc90b1552581f2b7c9a50f934e6bb0
MD5 (README) = f468f281c919665e276a1b691decbbe6
MD5 (RESOURCES) = a79b9b338cab09bd665f6b62ac6f455b
MD5 (THANKS) = 45b6d2e88a6ecb5b24fa33a781351cd5
MD5 (VERSION-INFO.dcf) = d08f0c8f65c2a021be36324081440dd9
MD5 (R-4/R-4.2.3.tar.gz) = ebfc90b1552581f2b7c9a50f934e6bb0
60a0d150e6fc1f424be76ad7b645d236b56e747692a4679f81ce6536c550e949 AUTHORS
e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING
6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB
8c396b0db6b1b072e66ea78deab8c89f71150744420ad9f74de6505aacee9a80 FAQ
f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL
be3cd8a6d7220726d2cbdf1b929e6b75c09101214b1b006e29ce97dab4450553 NEWS
4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0
5de7657c5e58e481403c0dd1a74a5c090b3ef481ce75a91dfe05d4b03f63163f NEWS.1
cde079b6beab7d700d3d4ecda494e2681ad3b7f8fab13b68be090f949393ec62 NEWS.2
1910a2405300b9bc7c76beeb0753a5249cf799afe175ce28f8d782fab723e012 NEWS.3
55e4a9a6d43be314e2c03d0266a6fa5444afdce50b303bfc3b82b3979516e074
R-latest.tar.gz
2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README
8b7d3856100220f4555d4d57140829f2e81c27eccec5b441f5dce616e9ec9061 RESOURCES
8319c5415de58ee10d4bc058d79c370fd8e6b2ad09e25d7a1e04b74ca5f380a6 THANKS
4701c6802bf3f31e6f8ad66d47909eef0985f8af97b0a28fd391c68a7d3ffc18
VERSION-INFO.dcf
55e4a9a6d43be314e2c03d0266a6fa5444afdce50b303bfc3b82b3979516e074
R-4/R-4.2.3.tar.gz
This is the relevant part of the NEWS file
CHANGES IN R 4.2.3:
C-LEVEL FACILITIES:
* The definition of DL_FUNC in R_ext/Rdynload.h has been changed to
be fully C-compliant. This means that functions loaded _via_ for
example R_GetCCallable need to be cast to an appropriate type if
they have any arguments.
* .Machine has a new element sizeof.time_t to identify old systems
with a 32-bit type and hence a limited range of date-times (and
limited support for dates millions of years from present).
PACKAGE INSTALLATION:
* (Windows) The default C++ standard had accidentally been left at
C++11 when it was changed to C++14 on Unix.
BUG FIXES:
* As "POSIXlt" objects may be "partially filled" and their list
components meant to be recycled, length() now is the length of
the longest component.
* as.POSIXlt.Date() could underflow for dates in the far past (more
than half a million years BCE).
* as.Date.POSIXlt(x) would return "1970-01-01" instead of NA in R
4.2.2, e.g., for
x <- as.POSIXlt(c("2019-01-30","2001-1-1"))
x$mon <- c(0L, NA); as.Date(x)
* R CMD check failed to apply enabled _R_CHECK_SUGGESTS_ONLY_ to
examples and vignettes (regression in R 4.2.0).
* R CMD check did not re-build vignettes in separate processes by
default (regression in R 4.2.0).
* Running examples from HTML documentation now restores previous
knitr settings and options (PR#18420).
* Quartz: fonts are now located using Core Graphics API instead of
deprecated ATS which is no longer supported in the macOS 13 SDK
(PR#18426). This also addresses an issue where the currently
used font in the Quartz device context was not correctly
retained.
* (Windows) Math symbols in text drawing functions are again
rendered correctly (PR#18440). This fixes a regression in R
4.2.1 caused by a fix in PR#18382 which uncovered an issue in
GraphApp due to which the symbol charset was not used with TT
Symbol font face.
* (Windows) Installing a package with a src/Makefile.{win,ucrt}
file includes ~/.R/Makevars.win64 in the search for user
makevars, as documented in "R Installation and Administration"
and done for packages with a src/Makevars.{win,ucrt} f
Re: [Rd] confusing all.equal output
I believe the wording goes back to Martin Maechler many moons ago (AFAICT towards the end of the last millennium.) We might leave it to him to change it? - Peter D. > On 2 Mar 2023, at 19:30 , avi.e.gr...@gmail.com wrote: > > I think if you step back, you can ask what the purpose of an error message > is and who designs it. > > Is the message for the developer or others on their team or something an > end-user knowing nothing about R will see. > > This reminds me a bit of legal mumbo jumbo that turns many reading it off as > it keeps talking about the party of the first part or the plaintiff as > compared to somewhat straighter talk. > > The scenario is that you are comparing two things. Their names are not > things like "target" or "current" so even other programmers not involved in > your code will pause and wonder. > > One view is to use phrases like first and second arguments/lists/whatever. > You might talk about the one on the left (but using LHS is a bit opaque) > versus the one on the right. > > But sometimes it can be too verbose. Sometimes the error message is being > generated not where everything is clear. > > So ideally you could say: > > WARNING Danger Will Robinson. > Comparing two things for equality. > Result finds mismatches. > There were NA found on the (left or right) that were not matched on the > other side. > Number of such found: 2 > > If you had a Systems Engineer write detailed requirements that included > something a bit better than the example and the programmer was able to > supply the data using the words and guidelines, it might fit some needs but > maybe not satisfy other programmers. But there are human factors people > whose job it is to help choose among alternatives and although they may not > choose well, letting a programmer come up with whatever they feel like is > generally worse. > > Yes, in their microcosm centered on a dozen lines of code, "current" and > "target" may have meaning. But are they the intended user of the product? > > -Original Message- > From: R-devel On Behalf Of Antoine Fabri > Sent: Thursday, March 2, 2023 12:23 PM > To: peter dalgaard > Cc: R-devel > Subject: Re: [Rd] confusing all.equal output > > Good points. I don't mind the terminology since target and current are the > names of the arguments. As the function is already designed to stop at the > first failing check we might not need to enumerate or count the mismatches, > instead we could have "`NA` found in `target` but not in `current` at > position " > > [[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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] confusing all.equal output
Yes... Also, of course, the sentence after colon does not the describe the cause of the mismatch, e.g. > all.equal(c(1,NA,NA), c(NA,NA,3)) [1] "'is.NA' value mismatch: 2 in current 2 in target" could be confusing. Perhaps "is.na() mismatch (2 positions)", with the count calculated as sum(is.na(current) != is.na(target)) instead? Or you could give both off-diagonal elements of the confusion matrix: "target-only: 1, current-only: 1" but actually, the whole current/target terminology is somewhat unclear. -pd > On 1 Mar 2023, at 13:53 , Antoine Fabri wrote: > > dear r-devel, > > This has probably been forever like this but is this satisfying ? > > all.equal(c(1,NA,NA), c(1,NA,3)) > #> [1] "'is.NA' value mismatch: 1 in current 2 in target" > > is.NA() doesn't exist (is.na() does), and is.na() is never 1 or 2. > > In this example it's obvious that we're counting missing values, in a > general situation I believe it isn't (we might understand it as the > position of the first NA for instance). > > I would expect something like "'amount of missing values mismatch: 1 in > current 2 in target" > > Thanks, > > Antoine > > [[alternative HTML version deleted]] > > ______ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.2.3 scheduled for March 15
Full schedule available on developer.r-project.org in a short while. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sys.getenv(): Error in substring(x, m + 1L) : invalid multibyte string at '' if an environment variable contains \xFF
> On 31 Jan 2023, at 12:51 , Tomas Kalibera wrote:
>
>
> On 1/31/23 11:50, Martin Maechler wrote:
>> hmm.., that's a pity; I had hoped it was a pragmatic and valid strategy,
>> but of course you are right that type stability is really a
>> valid goal
>>
>> In general, what about behaving close to "old R" and replace all such
>> strings by NA_character_ (and typically raising one warning)?
>> This would keep the result a valid character vector, just with some NA
>> entries.
>>
>> Specifically for Sys.getenv(), I still think Simon has a very
>> valid point of "requiring" (of our design) that
>> Sys.getenv()[["BOOM"]] {double `[[`} should be the same as
>> Sys.getenv("BOOM")
>>
>> Also, as typical R user, I'd definitely want to be able to get all the valid
>> environment variables, even if there are one or more invalid
>> ones. ... and similarly in other cases, it may be a cheap
>> strategy to replace invalid strings ("string" in the sense of
>> length 1 STRSXP, i.e., in R, a "character" of length 1) by
>> NA_character_ and keep all valid parts of the character vector
>> in a valid encoding.
> In case of specifically getenv(), yes, we could return NA for variables
> containing invalid strings, both when obtaining a value for a single variable
> and for multiple, partially matching undocumented and unintentional behavior
> R had before 4.1, and making getenv(var) and getenv()[[var]] consistent even
> with invalid strings. Once we decide on how to deal with invalid strings in
> general, we can change this again accordingly, breaking code for people who
> depend on these things (but so far I only know about this one case). Perhaps
> this would be a logical alternative to the Python approach that would be more
> suitable for R (given we have NAs and given that we happened to have that
> somewhat similar alternative before). Conceptually it is about the same thing
> as omitting the variable in Python: R users would not be able to use such
> variables, but if they don't touch them, they could be inherited to child
> processes, etc.
Hum, I'm out of my waters here, but offhand I would be wary about approaches
that lead to loss of information. Presumably someone will sooner or later
actually want to deal with the content of an environment variable with invalid
bytes inside. I.e. it would be preferable to keep the content and mark the
encoding as something not-multibyte.
In fact this is almost what happens (for me...) if I just add Encoding(x) <-
"bytes" for the return value of .Internal(Sys.getenv(character(), "")):
> Sys.getenv()[["BOOM"]]
[1] "\\xff"
> Encoding(Sys.getenv())
[1] "unknown" "unknown" "bytes" "unknown" "unknown" "unknown" "unknown"
[8] "unknown" "unknown" "unknown" "unknown" "unknown" "unknown" "unknown"
...
but I suppose that breaks if I have environment variables that actually _are_
utf8, because only plain-ASCII becomes "unknown"? And nchar(Sys.getenv()) also
does not work.
(And of course I agree that the QRSH thing is Just Wrong; people using 0xff as
a separator between utf8 strings deserve the same fate as those who used comma
separation between numbers with decimal commas.)
-pd
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recycling in arithmetic operations involving zero-length vectors
Actually, sum(), all(), any(), prod() all return a _carefully considered_ result in the case of an empty vector. The sum over a disjoint union of sets should be the sum of the sums over each set, so if a set is empty, its contribution to the sum must be zero. Similarly, the product over an empty set is 1. Logical aggregate all() should be stable for "&" and any() for "|", hence all(logical(0))==TRUE and any(logical(0))==FALSE. -pd > On 16 Jan 2023, at 16:53 , GILLIBERT, Andre > wrote: > > Duncan Murdoch wrote: > >> To even do that, we would have to first decide which "cases" should produce >> a warning. > >> Let's say `1 + x` should give a warning when x = numeric(0). Then should >> `x^2` also produce a warning? Should `x^0.5`? Should `sqrt(x)`? >> Should `log(x)`? > > > The most probable errors would be in functions taking two arguments (e.g. > `+`) and for which one argument has length >= 2 while the other has length 0. > > In my experience, most code with accidental zero-length propagations (e.g. > typo in data_frame$field) quickly lead to errors, that are easy to debug > (except for beginners), and so, do not need a warning. > > The only cases where zero-length propagation is really dangerous in my > experience is in code using an aggregating function like sum(), all() or > any(), because it silently returns a valid value for a zero-length argument. > Emitting warnings for sum(numeric(0)) would probably have too many false > positives but a (length >= 2) vs (length == 0) warning for common binary > operators could sometimes catch the issue before it reaches the aggregating > function. > > -- > Sincerely > André GILLIBERT > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Looking for R for Windows (rversion: 4.2.2) in base/old/%rversion%/R-%rversion%-win.exe
Dunno what happened there, and Win binaries are generally "not my table". However, 4.2.2 is not old, so possibly should not be on that list at all. It is the current version, so can be obtained via the "here" link at the top of the page (i.e. https://cran.r-project.org/bin/windows/base/) -pd > On 8 Jan 2023, at 06:12 , Andre Mikulec wrote: > > Peter Dalgaard, R-devel team, et al., > > Hi, my name is Andre Mikulec. > > I am an `common` committer to Postgres PL/R . . . > https://github.com/postgres-plr/plr/commits?author=AndreMikulec > > https://github.com/postgres-plr/plr > `PL/R - PostgreSQL support for R as a procedural language (PL)` > > However, now and different from the past, > the `windows/base/old` R 4.2.2 download location URL link now, redirects to > the wrong `R 4.2.1` location. > > Historically, > Previous and Current(still called `old`) Windows versions of R > have been stored here (below) and the current(old) version of R would have > been 4.2.2. and would have pointed to R 4.2.2. > > https://cran.r-project.org/bin/windows/base/old/ > > ``` > In this directory (and its URL redirect (->)): > R 4.2.2 (October, 2022) -> > https://cran.r-project.org/bin/windows/base/old/4.2.1 (NEED 4.2.2) > R 4.2.1 (June, 2022) -> https://cran.r-project.org/bin/windows/base/old/4.2.1/ > ``` > > So, something has changed `R 4.2.2 (October, 2022)` now redirects to > `base/old/4.2.1`. > > Now and in the past, Appveyor builds of PL/R rely a specific version of R in > an exact location: > > https://github.com/postgres-plr/plr/blob/4ac054e61c62f72a9cd3a38f66476d037b3e27a5/appveyor.yml#L25 > ``` > - pg: REL_15_0 >PlatformToolset: v141 >configuration: Release >APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2017 >rversion: 4.2.1 > ``` > > Notice (above and) below the variable `rversion: 4.2.1` > and the hard coded location `base/old/%rversion%/R-%rversion%-win.exe`. > > https://github.com/postgres-plr/plr/blob/4ac054e61c62f72a9cd3a38f66476d037b3e27a5/appveyor.yml#L108 > ``` > - if not exist R-%rversion%-win.exe appveyor downloadfile > https://cran.r-project.org/bin/windows/base/old/%rversion%/R-%rversion%-win.exe > ``` > > E.g. the most recent PL/R build (a month ago) using R 4.2.1 > `PL/R - PostgreSQL support for R as a procedural language (PL)` build: > > https://ci.appveyor.com/project/davecramer/plr-daun5/build/job/7lqs9pkgartjhxwt?fullLog=true#L15 > ``` > Cache 'R-4.2.1-win.exe' - Restored > Running Install scripts > if not exist R-%rversion%-win.exe appveyor downloadfile > https://cran.r-project.org/bin/windows/base/old/%rversion%/R-%rversion%-win.exe > R-%rversion%-win.exe /VERYSILENT > ``` > > Now, where may One find a `specific version of R in an exact location`? > > Please help. > > Thanks, > Andre Mikulec > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] anova and intercept
Yes, that works fine too. It likely depends on what you want to show and to whom. The audience might be ready to see the equivalence between t-tests and anova(lm(...)) but not yet prepared for variance components. - Peter > On 27 Dec 2022, at 18:55 , Greg Snow <538...@gmail.com> wrote: > > Why compute the differences manually when `aov` can do paired > comparisons on this data as is: > > summary(aov(extra ~ factor(group) + Error(ID), data=sleep )) > > gives the same F and P values > > On Tue, Dec 27, 2022 at 3:32 AM Gabor Grothendieck > wrote: >> >> Good idea. >> >> On Mon, Dec 26, 2022 at 12:59 PM peter dalgaard wrote: >>> >>> My usual advice on getting nonstandard F tests out of anova() is to fit the >>> models explicitly and compare. >>> >>> So how about this? >>> >>> fit1 <- lm(diff(extra,10) ~ 1, sleep) >>> fit0 <- update(fit1, ~ -1) >>> anova(fit0, fit1) >>> >>> -pd >>> >>>> On 26 Dec 2022, at 13:49 , Gabor Grothendieck >>>> wrote: >>>> >>>> Suppose we want to perform a paired test using the sleep data frame >>>> with anova in R. Then this works and gives the same p value as >>>> t.test(extra ~ group, sleep, paired = TRUE, var.equal = TRUE) >>>> >>>> ones <- rep(1, 10) >>>> anova(lm(diff(extra, 10) ~ ones + 0, sleep) >>>> >>>> This gives output but does not give an F test at all. >>>> >>>> ones <- rep(1, 10) >>>> anova(lm(diff(extra, 10) ~ 1, sleep) >>>> >>>> Maybe there should be some way to force an F test to be produced for >>>> the intercept in anova for consistency with t.test so that the second >>>> code can be used. >>>> >>>> >>>> -- >>>> Statistics & Software Consulting >>>> GKX Group, GKX Associates Inc. >>>> tel: 1-877-GKX-GROUP >>>> email: ggrothendieck at gmail.com >>>> >>>> __ >>>> R-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >>> -- >>> Peter Dalgaard, Professor, >>> Center for Statistics, Copenhagen Business School >>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark >>> Phone: (+45)38153501 >>> Office: A 4.23 >>> Email: pd@cbs.dk Priv: pda...@gmail.com >>> >> >> >> -- >> Statistics & Software Consulting >> GKX Group, GKX Associates Inc. >> tel: 1-877-GKX-GROUP >> email: ggrothendieck at gmail.com >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Gregory (Greg) L. Snow Ph.D. > 538...@gmail.com -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] anova and intercept
My usual advice on getting nonstandard F tests out of anova() is to fit the models explicitly and compare. So how about this? fit1 <- lm(diff(extra,10) ~ 1, sleep) fit0 <- update(fit1, ~ -1) anova(fit0, fit1) -pd > On 26 Dec 2022, at 13:49 , Gabor Grothendieck wrote: > > Suppose we want to perform a paired test using the sleep data frame > with anova in R. Then this works and gives the same p value as > t.test(extra ~ group, sleep, paired = TRUE, var.equal = TRUE) > > ones <- rep(1, 10) > anova(lm(diff(extra, 10) ~ ones + 0, sleep) > > This gives output but does not give an F test at all. > > ones <- rep(1, 10) > anova(lm(diff(extra, 10) ~ 1, sleep) > > Maybe there should be some way to force an F test to be produced for > the intercept in anova for consistency with t.test so that the second > code can be used. > > > -- > Statistics & Software Consulting > GKX Group, GKX Associates Inc. > tel: 1-877-GKX-GROUP > email: ggrothendieck at gmail.com > > ______ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.Date without "origin"
This is in R-devel, mind you, i.e., unreleased and quite possibly unfinished work. No released version of R does this. E.g., > as.Date(0) Error in as.Date.numeric(0) : 'origin' must be supplied > version _ platform x86_64-apple-darwin21.6.0 arch x86_64 os darwin21.6.0 system x86_64, darwin21.6.0 status Patched major 4 minor 2.2 year 2022 month 11 day02 svn rev83236 language R version.string R version 4.2.2 Patched (2022-11-02 r83236) nickname Innocent and Trusting > On 2 Nov 2022, at 14:38 , Dan Dalthorp via R-devel > wrote: > > I don't see a compelling rationale for changing the default behavior as.Date > to deviate from the wholly reasonable status quo of "as.Date will accept > numeric data (the number of days since an epoch), but only if origin is > supplied." That has been the expectation for a long, long time. > > In any case, the manual should match the behavior. > > -DHD > > > > > --- Original Message --- > On Wednesday, November 2nd, 2022 at 6:20 AM, Spencer Graves > wrote: > > >> >> >> I've felt that "as.Date" should default to origin "1970-01-01", so I >> added a modification to Ecfun: >> >> >> Ecfun::as.Date1970(0) >> >> >> If R-devel chose to change the default on this, I would happily >> deprecate Ecfun::as.Date1970 in favor of base::as.Date ;-) >> >> >> I would therefore support changing the documentation to match the new >> behavior. >> >> >> Spencer Graves >> >> >> On 11/2/22 7:30 AM, Dan Dalthorp via R-devel wrote: >> >>> The new (2022-10-11 r83083 ucrt) as.Date function returns a date rather >>> than an error when called without "origin" specified. >>> >>> # previous versions of R >>> as.Date(0) >>> # Error in as.Date.numeric(0) : 'origin' must be supplied >>> >>> # new: >>> as.Date(0) >>> # [1] "1970-01-01" >>> >>> This is at odds with the help file, which gives: >>> >>> origin >>> >>> aDateobject, or something which can be coerced byas.Date(origin, ...)to >>> such an object. >>> >>> And: >>> as.Datewill accept numeric data (the number of days since an epoch), >>> butonlyiforiginis supplied. >>> >>> The behavior described in the help file and implemented in previous >>> versions seems more reasonable than returning a date with an arbitrary >>> "origin". In any case, in the r-devel there is a mismatch between the >>> function and its description. >>> >>> -Dan >>> [[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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.2.2 is released
The build system rolled up R-4.2.2.tar.gz (codename "Innocent and Trusting") this morning. The list below details the changes in this release. You can get the source code from https://cran.r-project.org/src/base/R-4/R-4.2.2.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard These are the checksums (md5 and SHA-256) for the freshly created files, in case you wish to check that they are uncorrupted: MD5 (AUTHORS) = 320967884b547734d6279dedbc739dd4 MD5 (COPYING) = eb723b61539feef013de476e68b5c50a MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343 MD5 (FAQ) = 1ff069b3d34234bb6df71298380da3a8 MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b MD5 (NEWS) = df3c0a29151cfbc40e6a07a5ad398de1 MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8 MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801 MD5 (NEWS.2) = b38d94569700664205a76a7de836ba83 MD5 (NEWS.3) = e55ed2c8a547b827b46e08eb7137ba23 MD5 (R-latest.tar.gz) = b154500667b5ebb480f1086dd817f017 MD5 (README) = f468f281c919665e276a1b691decbbe6 MD5 (RESOURCES) = a79b9b338cab09bd665f6b62ac6f455b MD5 (THANKS) = 45b6d2e88a6ecb5b24fa33a781351cd5 MD5 (VERSION-INFO.dcf) = 7c5057ff5958b2312a88556487fae295 MD5 (R-4/R-4.2.2.tar.gz) = b154500667b5ebb480f1086dd817f017 60a0d150e6fc1f424be76ad7b645d236b56e747692a4679f81ce6536c550e949 AUTHORS e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB d8cfbd44efe3311bc2d4a71a0850c50aebc18a21affac951898a3b6b45dfe777 FAQ f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL f9700348b098129906da3489ce7299f86ded993aac2a8861349b1935652f8f6d NEWS 4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0 12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1 cde079b6beab7d700d3d4ecda494e2681ad3b7f8fab13b68be090f949393ec62 NEWS.2 1910a2405300b9bc7c76beeb0753a5249cf799afe175ce28f8d782fab723e012 NEWS.3 0ff62b42ec51afa5713caee7c4fde7a0c45940ba39bef8c5c9487fef0c953df5 R-latest.tar.gz 2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README 8b7d3856100220f4555d4d57140829f2e81c27eccec5b441f5dce616e9ec9061 RESOURCES 8319c5415de58ee10d4bc058d79c370fd8e6b2ad09e25d7a1e04b74ca5f380a6 THANKS 4bf8efc154e3f48800a9ddd1dd5bf333d3cf4f7e943876372699dab76e693318 VERSION-INFO.dcf 0ff62b42ec51afa5713caee7c4fde7a0c45940ba39bef8c5c9487fef0c953df5 R-4/R-4.2.2.tar.gz This is the relevant part of the NEWS file CHANGES IN R 4.2.2: NEW FEATURES: * tools::Rdiff(useDiff = TRUE) checks for the presence of an external diff command and switches to useDiff = FALSE if none is found. This allows R CMD Rdiff to always work. * On Windows, environment variable R_LIBCURL_SSL_REVOKE_BEST_EFFORT can be used to switch to only 'best-effort' SSL certificate revocation checks with the default "libcurl" download method. This reduces security, but may be needed for downloads to work with MITM proxies (PR#18379). * (macOS) The run-time check for libraries from XQuartz for X11 and Tcl/Tk no longer uses otool from the Apple Developer Tools (PR#18400). * The LaTeX style for producing the PDF manuals, Rd.sty, now loads the standard amsmath, amsfonts and amssymb packages for greater coverage of math commands in the Rd \eqn and \deqn macros. The \mathscr LaTeX command is also provided (via the mathrsfs package, if available, or the amsfonts bundle otherwise), fulfilling the wish of PR#18398. * (Windows) The default format of readClipboard() and writeClipboard() has been changed to 13 (CF_UNICODETEXT). INSTALLATION on a UNIX-ALIKE: * The PDF manuals (if built) can be compacted by the new target make compact-pdf (at the top level or in directory doc/manual). * There is now configure support for LLVM clang 15 on Linux, which defaults to position-independent (PIE) executables whereas gfortran does not. * Many small changes to ease compilation (and suppress warnings) with LLVM clang 15. BUG FIXES: * Rscript -e would fail if stdin were closed (Reported by Henrik Bengtsson.) * qt(*, log.p=TRUE) in outer tails no longer produces NaN in its final steps, thus fixing PR#18360. * tools::Rd2latex() now escapes hashes and ampersands when writing URLs, fixing LaTeX errors with such URLs in \tabular. * When isGeneric(f, fdef=*) is used with mismatching names, the warning is better understandable; reported (with fix) in PR#18370 by Gabe Becker. * poly(x, n) now works again (and is now documented) when x is a "Date" or "POSIXct" object, or of another class while fulfilling mode(x) == "numeric". This also enables poly(x, *, raw=TRUE) for such
Re: [R-pkg-devel] Invalid UTF-8
> On 18 Oct 2022, at 16:37 , Dirk Eddelbuettel wrote: > > > On 17 October 2022 at 13:20, Göran Broström wrote: > > | G;ran (US keyboard) > > :) > > A fortunes candidate? > Incidentally, he's Gæran on a DK keyboard but Gøran on an NO one. The three Scandinavian languages have the same three extra letters (æøå), but Swedish writes the former two with diaeresis (like German), reverses their order in the alphabet (åöä), and switches ö and ä on the keyboard (compared to Danish, that is). Norwegian writes and sorts like Danish, but has the same key reversion as Swedish. "Brotherly love"... -pd -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] Rscript -e EXPR fails to launch if stdin is closed
Done... -pd > On 11 Oct 2022, at 10:53 , peter dalgaard wrote: > > There's still 2 weeks till code freeze for 4.2.2, and porting the fix would > be trivial. As long as there is no risk that someone will get the bright idea > of changing a critical package to depend on R >= 4.2.2... > > - pd -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rscript -e EXPR fails to launch if stdin is closed
There's still 2 weeks till code freeze for 4.2.2, and porting the fix would be
trivial. As long as there is no risk that someone will get the bright idea of
changing a critical package to depend on R >= 4.2.2...
- pd
> On 10 Oct 2022, at 18:34 , Henrik Bengtsson
> wrote:
>
> Thank you Peter for the quick fix. Will this make it into R-patched
> to become R 4.2.2 soon?
>
> I can confirm that the fix resolved also the original problem report
> involving launching a parallel PSOCK cluster from within a 'processx'
> background process
> (https://stackoverflow.com/questions/73962109/why-are-the-workers-failing-to-connect-when-calling-makepsockcluster-from-an-e/73991833#73991833
> and https://github.com/r-lib/callr/issues/236)
>
>
> /Henrik
>
> On Mon, Oct 10, 2022 at 5:54 AM peter dalgaard wrote:
>>
>> It seems to work simply to do "if (ifd >= 0)..." (the ifp test is fine
>> since ifp is FILE* and initialized to NULL). Will commit (to r-devel for
>> now).
>>
>> -pd
>>
>>> On 10 Oct 2022, at 11:07 , peter dalgaard wrote:
>>>
>>> He!
>>>
>>> Yes, that looks like a blunder.
>>>
>>> mkstemp() returns -1 on failure, not 0, so the test on ifd (and I suppose
>>> also the one on ifp) is wrong. And of course, once you close file
>>> descriptor 0, mkstemp() chooses the 1st available fd, i.e. 0, for its
>>> return value.
>>>
>>> -pd
>>>
>>>> On 9 Oct 2022, at 20:25 , Henrik Bengtsson
>>>> wrote:
>>>>
>>>> Rscript fails to launch if the standard input (stdin) is closed, e.g.
>>>>
>>>> $ Rscript --vanilla -e 42 0<&-
>>>> Fatal error: creating temporary file for '-e' failed
>>>>
>>>> This appear to only happen with `-e EXPR`, e.g. it works when doing:
>>>>
>>>> $ echo "42" > script.R
>>>> $ Rscript --vanilla script.R 0<&-
>>>> [1] 42
>>>>
>>>> and:
>>>>
>>>> $ R --vanilla 0<&-
>>>> R version 4.2.1 (2022-06-23) -- "Funny-Looking Kid"
>>>> Copyright (C) 2022 The R Foundation for Statistical Computing
>>>> Platform: x86_64-pc-linux-gnu (64-bit)
>>>> ...
>>>>>
>>>>
>>>>
>>>> TROUBLESHOOTING:
>>>>
>>>> $ strace Rscript --vanilla -e 42 0<&-
>>>> execve("/home/hb/shared/software/CBI/R-4.2.1-gcc9/bin/Rscript",
>>>> ["Rscript", "--vanilla", "-e", "42"], 0x7fff9f476418 /* 147 vars */) =
>>>> 0
>>>> brk(NULL) = 0x5625ca9e6000
>>>> arch_prctl(0x3001 /* ARCH_??? */, 0x7fff23b4d260) = -1 EINVAL (Invalid
>>>> argument)
>>>> ...
>>>> fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
>>>> write(1, "Fatal error: creating temporary "..., 53Fatal error:
>>>> creating temporary file for '-e' failed
>>>> ) = 53
>>>> exit_group(2) = ?
>>>> +++ exited with 2 +++
>>>>
>>>> which points to src/unix/system.c:
>>>>
>>>> ifd = mkstemp(ifile);
>>>> if (ifd > 0)
>>>> ifp = fdopen(ifd, "w+");
>>>> if(!ifp) R_Suicide(_("creating temporary file for '-e' failed"));
>>>>
>>>>
>>>> One rationale for having closed standard files (including stdin) is to
>>>> avoid leaking file descriptors, cf.
>>>> https://wiki.sei.cmu.edu/confluence/display/c/FIO22-C.+Close+files+before+spawning+processes
>>>> and https://danwalsh.livejournal.com/53603.html. The background for
>>>> reporting on this was that `system()` fails to work in processx
>>>> spawned processes, which closes the standard files by default in
>>>> processx (<= 3.7.0).
>>>>
>>>> Best,
>>>>
>>>> Henrik
>>>>
>>>> __
>>>> R-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>> --
>>> Peter Dalgaard, Professor,
>>> Center for Statistics, Copenhagen Business School
>>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
>>> Phone: (+45)38153501
>>> Office: A 4.23
>>> Email: pd@cbs.dk Priv: pda...@gmail.com
>>>
>>
>> --
>> Peter Dalgaard, Professor,
>> Center for Statistics, Copenhagen Business School
>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
>> Phone: (+45)38153501
>> Office: A 4.23
>> Email: pd@cbs.dk Priv: pda...@gmail.com
>>
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rscript -e EXPR fails to launch if stdin is closed
It seems to work simply to do "if (ifd >= 0)..." (the ifp test is fine since
ifp is FILE* and initialized to NULL). Will commit (to r-devel for now).
-pd
> On 10 Oct 2022, at 11:07 , peter dalgaard wrote:
>
> He!
>
> Yes, that looks like a blunder.
>
> mkstemp() returns -1 on failure, not 0, so the test on ifd (and I suppose
> also the one on ifp) is wrong. And of course, once you close file descriptor
> 0, mkstemp() chooses the 1st available fd, i.e. 0, for its return value.
>
> -pd
>
>> On 9 Oct 2022, at 20:25 , Henrik Bengtsson
>> wrote:
>>
>> Rscript fails to launch if the standard input (stdin) is closed, e.g.
>>
>> $ Rscript --vanilla -e 42 0<&-
>> Fatal error: creating temporary file for '-e' failed
>>
>> This appear to only happen with `-e EXPR`, e.g. it works when doing:
>>
>> $ echo "42" > script.R
>> $ Rscript --vanilla script.R 0<&-
>> [1] 42
>>
>> and:
>>
>> $ R --vanilla 0<&-
>> R version 4.2.1 (2022-06-23) -- "Funny-Looking Kid"
>> Copyright (C) 2022 The R Foundation for Statistical Computing
>> Platform: x86_64-pc-linux-gnu (64-bit)
>> ...
>>>
>>
>>
>> TROUBLESHOOTING:
>>
>> $ strace Rscript --vanilla -e 42 0<&-
>> execve("/home/hb/shared/software/CBI/R-4.2.1-gcc9/bin/Rscript",
>> ["Rscript", "--vanilla", "-e", "42"], 0x7fff9f476418 /* 147 vars */) =
>> 0
>> brk(NULL) = 0x5625ca9e6000
>> arch_prctl(0x3001 /* ARCH_??? */, 0x7fff23b4d260) = -1 EINVAL (Invalid
>> argument)
>> ...
>> fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
>> write(1, "Fatal error: creating temporary "..., 53Fatal error:
>> creating temporary file for '-e' failed
>> ) = 53
>> exit_group(2) = ?
>> +++ exited with 2 +++
>>
>> which points to src/unix/system.c:
>>
>> ifd = mkstemp(ifile);
>> if (ifd > 0)
>> ifp = fdopen(ifd, "w+");
>> if(!ifp) R_Suicide(_("creating temporary file for '-e' failed"));
>>
>>
>> One rationale for having closed standard files (including stdin) is to
>> avoid leaking file descriptors, cf.
>> https://wiki.sei.cmu.edu/confluence/display/c/FIO22-C.+Close+files+before+spawning+processes
>> and https://danwalsh.livejournal.com/53603.html. The background for
>> reporting on this was that `system()` fails to work in processx
>> spawned processes, which closes the standard files by default in
>> processx (<= 3.7.0).
>>
>> Best,
>>
>> Henrik
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk Priv: pda...@gmail.com
>
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rscript -e EXPR fails to launch if stdin is closed
He!
Yes, that looks like a blunder.
mkstemp() returns -1 on failure, not 0, so the test on ifd (and I suppose also
the one on ifp) is wrong. And of course, once you close file descriptor 0,
mkstemp() chooses the 1st available fd, i.e. 0, for its return value.
-pd
> On 9 Oct 2022, at 20:25 , Henrik Bengtsson wrote:
>
> Rscript fails to launch if the standard input (stdin) is closed, e.g.
>
> $ Rscript --vanilla -e 42 0<&-
> Fatal error: creating temporary file for '-e' failed
>
> This appear to only happen with `-e EXPR`, e.g. it works when doing:
>
> $ echo "42" > script.R
> $ Rscript --vanilla script.R 0<&-
> [1] 42
>
> and:
>
> $ R --vanilla 0<&-
> R version 4.2.1 (2022-06-23) -- "Funny-Looking Kid"
> Copyright (C) 2022 The R Foundation for Statistical Computing
> Platform: x86_64-pc-linux-gnu (64-bit)
> ...
>>
>
>
> TROUBLESHOOTING:
>
> $ strace Rscript --vanilla -e 42 0<&-
> execve("/home/hb/shared/software/CBI/R-4.2.1-gcc9/bin/Rscript",
> ["Rscript", "--vanilla", "-e", "42"], 0x7fff9f476418 /* 147 vars */) =
> 0
> brk(NULL) = 0x5625ca9e6000
> arch_prctl(0x3001 /* ARCH_??? */, 0x7fff23b4d260) = -1 EINVAL (Invalid
> argument)
> ...
> fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
> write(1, "Fatal error: creating temporary "..., 53Fatal error:
> creating temporary file for '-e' failed
> ) = 53
> exit_group(2) = ?
> +++ exited with 2 +++
>
> which points to src/unix/system.c:
>
> ifd = mkstemp(ifile);
> if (ifd > 0)
>ifp = fdopen(ifd, "w+");
> if(!ifp) R_Suicide(_("creating temporary file for '-e' failed"));
>
>
> One rationale for having closed standard files (including stdin) is to
> avoid leaking file descriptors, cf.
> https://wiki.sei.cmu.edu/confluence/display/c/FIO22-C.+Close+files+before+spawning+processes
> and https://danwalsh.livejournal.com/53603.html. The background for
> reporting on this was that `system()` fails to work in processx
> spawned processes, which closes the standard files by default in
> processx (<= 3.7.0).
>
> Best,
>
> Henrik
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with accessibility in R 4.2.0 and 4.2.1.
Tomas Kalibera has related that he has some scars from fighting with some unexpected interactions between UTF-8 and the GraphApp library that is used for RGui and I think he said that screen readers were involved. I wouldn't be surprised if this is a leftover issue. (This is obviously a kind of issue that non-blind users don't "see" :-) ). Would it work for you to use the terminal application (the "DOS box", or whatever it is called these days) until the issue gets fixed? In general, I would expect your go-to guy for blindness-related issues to be Jonathon Godfrey (cc'ed). Perhaps he can offer some advice. -pd > On 22 Sep 2022, at 15:48 , Andrew Hart via R-devel > wrote: > > Hi. I'm having an issue with R 4.2.1 on Windows but I'm not sure if this is > the right place to ask about it. If it's not, I'm hoping someone can point me > in the right direction. > > I'm blind and have been using R for about 11 years now. The base build > available on CRAN is quite accessible and works pretty well with > screen-reading software such as JAWS for Windows and NVDA. R-studio is not > accessible which appears to have something to do with the version of QT it > uses, but that's not relevant as I don't use it. > > Recently I installed R 4.2.1 (I tend to upgrade two or three times a year and > this time I was jumping from R 4.1.2 to 4.2.1). > However, I've encountered a serious problem which makes the latest version > more or less unusable for doing any kind of serious work. > The issue is that the screen-reading software is unable to locate the R > cursor and behaves as though the cursor is near the top left of the R > application window. Practically, this means I can't tell what characters I'm > passing over when cursoring left and right, nor can I hear what character is > being deleted when the backspace is pressed. Most importantly, I can't tell > where the insertion point is. This is a major regression in the ability to > work with and edit the command line in the R console. There are ways of > actually viewing the command line but the way I work is frequently calling up > a previous command and making a change so as to not have to type the whole > command again. > > I Went and installed R 4.1.3 and R 4.2.0 in an attempt to find out exactly > when things went awry and the issue first appeared in R 4.2.0. > Looking through the release notes, the only things mentioned that seem likely > to be relevant are the following: > > • R uses a new 64-bit Tcl/Tk bundle. The previous 32-bit/64-bit bundle had a > different layout and can no longer be used. > > and > > • R uses UTF-8 as the native encoding on recent Windows systems (at least > Windows 10 version 1903, Windows Server 2022 or Windows Server 1903). As a > part > of this change, R uses UCRT as the C runtime. UCRT should be installed > manually on systems older than Windows 10 or Windows Server 2016 before > installing > R. > > I can't really see how changing to utf-8 as the native encoding would produce > the behaviour I'm seeing, so I am guessing that the change in TCL/TK might be > the culprit. > > I'm hoping that someone will be able to help shed some light on what's going > on here. > > Thanks a lot, > Andrew. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Parser bug? A comma too much.
As a general matter, empty arguments are allowed and are used meaningfully in some contexts, notably A[i,], which is syntactic sugarcoating of "["(A,i,). I.e., these are different: > "["(Sigma,2,) # 2nd row [1] 0.077 0.168 > "["(Sigma,2) # 2nd element [1] 0.077 It is somewhat rare to have an empty last argument, intermediate ones are more common: > seq(0,1,,5) [1] 0.00 0.25 0.50 0.75 1.00 -pd > On 16 Sep 2022, at 16:33 , Rui Barradas wrote: > > Hello, > > Why doesn't the comma throw an error? > > > plot(1:5,)# works, no complaints > > > Shouldn't this be considered a bug? I would expect the parser to at least > give a warning. > > > sessionInfo() > R version 4.2.1 (2022-06-23 ucrt) > Platform: x86_64-w64-mingw32/x64 (64-bit) > Running under: Windows 10 x64 (build 22000) > > Matrix products: default > > locale: > [1] LC_COLLATE=Portuguese_Portugal.utf8 LC_CTYPE=Portuguese_Portugal.utf8 > [3] LC_MONETARY=Portuguese_Portugal.utf8 LC_NUMERIC=C > [5] LC_TIME=Portuguese_Portugal.utf8 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > loaded via a namespace (and not attached): > [1] compiler_4.2.1 > > > Rui Barradas > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN webserver down
Apparently resurrected now. -pd > On 22 May 2022, at 20:05 , Prof Brian Ripley wrote: > > On 22/05/2022 01:08, Dirk Eddelbuettel wrote: >>> From what I can tell from there, the CRAN webserver appears to be down so no >> cran.r-project.org or www.r-project.org. It appears that other ports respond >> so it may just be in need of restart of the apache service. I am sure someone >> will get to it in due course. Until then we have the mirrors. >> Best, Dirk > > The sysadmins are aware (they have a monitor service), but attempts to > restart Apache remotely failed. So hopefully this will work again in working > hours in Austria tomorrow. > > -- > 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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel tarball at ETH is zero
FWIW, the tarballs in https://cran.r-project.org/src/base-prerelease/ seem ok at this point. (We usually prefer that you use one of the two tarball sources over svn/git because "make dist" issues otherwise can go unnoticed.) -pd > On 3 May 2022, at 13:54 , Dirk Eddelbuettel wrote: > > > Dear Martin as our trusted ETH point person, > > I have some automated builders fall over as the tarball of R-devel is > currently empty: > > > edd@rob:/tmp$ wget https://stat.ethz.ch/R/daily/R-devel.tar.bz2 > --2022-05-03 06:52:20-- https://stat.ethz.ch/R/daily/R-devel.tar.bz2 > Resolving stat.ethz.ch (stat.ethz.ch)... 129.132.119.195 > Connecting to stat.ethz.ch (stat.ethz.ch)|129.132.119.195|:443... connected. > HTTP request sent, awaiting response... 200 OK > Length: 0 [application/x-bzip2] > Saving to: ‘R-devel.tar.bz2’ > > R-devel.tar.bz2 [ <=>] 0 --.-KB/sin 0s > > > 2022-05-03 06:52:21 (0.00 B/s) - ‘R-devel.tar.bz2’ saved [0/0] > > edd@rob:/tmp$ ls -l R-devel.tar.bz2 > -rw-rw-r-- 1 edd edd 0 May 2 19:07 R-devel.tar.bz2 > edd@rob:/tmp$ > > > Can you please take a look / contact the right person, or let us know if we > should switch to svn (or git mirror) checkouts. > > Many thanks, Dirk > > > -- > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > ______ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Snapshot server down?
The tarballs in https://cran.r-project.org/src/base-prerelease/ should be OK. -pd > On 17 Mar 2022, at 23:26 , Mächler Martin wrote: > > Yes, we have had a horrible NAS (Networked File system / storage) failure > which needed both hardware replacements and (micro?) code fixes.. > pretty embarrassing for the NAS producer and its maintenance contract... > > Martin Mächler > ETH Zürich > > Von: R-devel im Auftrag von Rainer Hurling > > Gesendet: Donnerstag, 17. März 2022 14:32:17 > An: r-devel@r-project.org > Betreff: [Rd] Snapshot server down? > > Hi maintainers, > > When I try to download the tarball of the daily snapshot from > https://stat.ethz.ch/R/daily, I get a > > '403 Forbidden' > 'You don't have permission to access this resource'. > > It seems that the permissions were accidentally tightened? > > Greetings, > Rainer Hurling > > __ > 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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wrong number of names?
> On 1 Nov 2021, at 11:36 , Duncan Murdoch wrote:
>
> The StackOverflow post https://stackoverflow.com/a/69767361/2554330 discusses
> a dataframe which has a named numeric column of length 1488 that has 744
> names. I don't think this is ever legal, but am I wrong about that?
>
It is certainly not easy to create such objects at the R level, e.g.:
> x <- 1:10
> names(x) <- 1:10
> length(names(x)) <- 5
> x
12345
123456789 10
> names(x)
[1] "1" "2" "3" "4" "5" NA NA NA NA NA
or even
> x <- 1:10
> attributes(x)$foo <- 1:5
> x
[1] 1 2 3 4 5 6 7 8 9 10
attr(,"foo")
[1] 1 2 3 4 5
> names(attributes(x)) <- "names"
> x
12345
123456789 10
> dput(x)
structure(1:10, .Names = c("1", "2", "3", "4", "5", NA, NA, NA,
NA, NA))
of course, at the C level, everything is possible...
> The `dat.rds` file mentioned in the post is temporarily available online in
> case anyone else wants to examine it.
>
> Assuming that the file contains a badly formed object, I wonder if readRDS()
> should do some sanity checks as it reads.
>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.1.2 is released
The build system rolled up R-4.1.2.tar.gz (codename "Bird Hippie") this morning.
The list below details the changes in this release.
You can get the source code from
https://cran.r-project.org/src/base/R-4/R-4.1.2.tar.gz
or wait for it to be mirrored at a CRAN site nearer to you.
Binaries for various platforms will appear in due course.
For the R Core Team,
Peter Dalgaard
These are the checksums (md5 and SHA-256) for the freshly created files, in
case you wish
to check that they are uncorrupted:
MD5 (AUTHORS) = 320967884b547734d6279dedbc739dd4
MD5 (COPYING) = eb723b61539feef013de476e68b5c50a
MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343
MD5 (FAQ) = ade6a3d38fe5e6a456929cae2b94d568
MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b
MD5 (NEWS) = 924e68decbf327f538a09afb1838506b
MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8
MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801
MD5 (NEWS.2) = a767f7809324c73c49eaff47d14bce81
MD5 (NEWS.3) = e55ed2c8a547b827b46e08eb7137ba23
MD5 (R-latest.tar.gz) = 6e28db9d02c6d3dae51a149b8e261ab1
MD5 (README) = f468f281c919665e276a1b691decbbe6
MD5 (RESOURCES) = a79b9b338cab09bd665f6b62ac6f455b
MD5 (THANKS) = 251d20510bfc3cc93b82c5a99f7efcc6
MD5 (VERSION-INFO.dcf) = a72a49578a254b9163f0f10322a3eecc
MD5 (R-4/R-4.1.2.tar.gz) = 6e28db9d02c6d3dae51a149b8e261ab1
60a0d150e6fc1f424be76ad7b645d236b56e747692a4679f81ce6536c550e949 AUTHORS
e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING
6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB
e84c67931e9b925abb9142d4a6b4ef03b7605948bbf384d7e3d2401823c7f1fe FAQ
f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL
73d5bfb8711bb7833ce8fe7a1359566d48001d13cd32affbd800d759f0b3232a NEWS
4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0
12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1
ba74618bc3f4c0e336dca13d472402a1863d12ba6f7f91a1782bc469ee986f6d NEWS.2
1910a2405300b9bc7c76beeb0753a5249cf799afe175ce28f8d782fab723e012 NEWS.3
2036225e9f7207d4ce097e54972aecdaa8b40d7d9911cd26491fac5a0fab38af
R-latest.tar.gz
2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README
8b7d3856100220f4555d4d57140829f2e81c27eccec5b441f5dce616e9ec9061 RESOURCES
c9c7cb32308b4e560a22c858819ade9de524a602abd4e92d1c328c89f8037d73 THANKS
1e74ef089b526538bbb658dc189bc3d34d931839e9933415fb2f267fd57b0b69
VERSION-INFO.dcf
2036225e9f7207d4ce097e54972aecdaa8b40d7d9911cd26491fac5a0fab38af
R-4/R-4.1.2.tar.gz
This is the relevant part of the NEWS file
CHANGES IN R 4.1.2:
C-LEVEL FACILITIES:
* The workaround in headers R.h and Rmath.h (using namespace std;)
for the Oracle Developer Studio compiler is no longer needed now
C++11 is required so has been removed. A couple more usages of
log() (which should have been std::log()) with an int argument
are reported on Solaris.
* The undocumented limit of 4095 bytes on messages from the
S-compatibility macros PROBLEM and MESSAGE is now documented and
longer messages will be silently truncated rather than
potentially causing segfaults.
* If the R_NO_SEGV_HANDLER environment variable is non-empty, the
signal handler for SEGV/ILL/BUS signals (which offers recovery
user interface) is not set. This allows more reliable debugging
of crashes that involve the console.
DEPRECATED AND DEFUNCT:
* The legacy S-compatibility macros PROBLEM, MESSAGE, ERROR, WARN,
WARNING, RECOVER, ... are deprecated and will be hidden in R
4.2.0. R's native interface of Rf_error and Rf_warning has long
been preferred.
BUG FIXES:
* .mapply(F, dots, .) no longer segfaults when dots is not a list
and uses match.fun(F) as always documented; reported by Andrew
Simmons in PR#18164.
* hist(, ...) and hist(, ...) no longer pass
arguments for rect() (such as col and density) to axis().
(Thanks to Sebastian Meyer's PR#18171.)
* \Sexpr{ch} now preserves Encoding(ch). (Thanks to report and
patch by Jeroen Ooms in PR#18152.)
* Setting the RNG to "Marsaglia-Multicarry" e.g., by RNGkind(), now
warns in more places, thanks to Andr'e Gillibert's report and
patch in PR#18168.
* gray(numeric(), alpha=1/2) no longer segfaults, fixing PR#18183,
reported by Till Krenz.
* Fixed dnbinom(x, size=, .., log=TRUE) regression,
reported by Martin Morgan.
* as.Date.POSIXlt(x) now keeps names(x), thanks to Davis Vaughan's
report and patch in PR#18188.
* model.response() now strips an "AsIs" class typically, thanks to
Duncan Murdoch's report and other discussants in PR#18190.
* try() is considerably faster in case of an error and long call,
as e.g., from some do.call(). Thanks to Alexander Kaever's
suggestion posted to R-devel.
* qqline(y = ) such as y=I(.), now works, see also
PR#181
Re: [Rd] R 4.1.2 scheduled for November 1
Schedule should appear on developer.r-project.org when it gets updated from SVN. > On 3 Oct 2021, at 18:40 , peter dalgaard wrote: > > (Just a quick heads-up for developers.) > > Full schedule to be made available soon. > -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.1.2 scheduled for November 1
(Just a quick heads-up for developers.) Full schedule to be made available soon. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.1.x make check fails, stats-Ex.R, step factor reduced below minFactor
ry
>> '/home/nobackup/co/R/R-4-1-branch/Build-x86_64/tests'
>> make[2]: Entering directory
>> '/home/nobackup/co/R/R-4-1-branch/Build-x86_64/tests'
>> make[3]: Entering directory
>> '/home/nobackup/co/R/R-4-1-branch/Build-x86_64/tests/Examples'
>> Testing examples for package 'base'
>> Testing examples for package 'tools'
>> comparing 'tools-Ex.Rout' to 'tools-Ex.Rout.save' ... OK
>> Testing examples for package 'utils'
>> Testing examples for package 'grDevices'
>> comparing 'grDevices-Ex.Rout' to 'grDevices-Ex.Rout.save' ... OK
>> Testing examples for package 'graphics'
>> comparing 'graphics-Ex.Rout' to 'graphics-Ex.Rout.save' ... OK
>> Testing examples for package 'stats'
>> Error: testing 'stats' failed
>> Execution halted
>> Makefile:37: recipe for target 'test-Examples-Base' failed
>> make[3]: *** [test-Examples-Base] Error 1
>> make[3]: Leaving directory
>> '/home/nobackup/co/R/R-4-1-branch/Build-x86_64/tests/Examples'
>> ../../tests/Makefile.common:198: recipe for target 'test-Examples' failed
>> make[2]: *** [test-Examples] Error 2
>> make[2]: Leaving directory
>> '/home/nobackup/co/R/R-4-1-branch/Build-x86_64/tests'
>> ../../tests/Makefile.common:184: recipe for target 'test-all-basics' failed
>> make[1]: *** [test-all-basics] Error 1
>> make[1]: Leaving directory
>> '/home/nobackup/co/R/R-4-1-branch/Build-x86_64/tests'
>> Makefile:305: recipe for target 'check-all' failed
>> make: *** [check-all] Error 2
>> ## From file: tests/Examples/stats-Ex.Rout.fail
>>> ## Here, requiring close convergence, you need to use more accurate
>>> numerical
>>> ## differentiation; this gives Error: "step factor .. reduced below
>>> 'minFactor' .."
>>> options(digits = 10) # more accuracy for 'trace'
>>> ## IGNORE_RDIFF_BEGIN
>>> try(nlm1 <- update(nlmod, control = list(tol = 1e-7))) # where central
>>> diff. work here:
>> Warning in nls(formula = y ~ Const + A * exp(B * x), algorithm = "default",
>> :
>> No starting values specified for some parameters.
>> Initializing 'Const', 'A', 'B' to '1.'.
>> Consider specifying 'start' or using a selfStart model
>>>(nlm2 <- update(nlmod, control = list(tol = 8e-8, nDcentral=TRUE),
>>> trace=TRUE))
>> Warning in nls(formula = y ~ Const + A * exp(B * x), algorithm = "default",
>> :
>> No starting values specified for some parameters.
>> Initializing 'Const', 'A', 'B' to '1.'.
>> Consider specifying 'start' or using a selfStart model
>> 1017460.306(4.15e+02): par = (1 1 1)
>> 758164.7503(2.34e+02): par = (13.42031396 1.961485 0.05947543745)
>> 269506.3538(3.23e+02): par = (51.75719816 -13.09155957 0.8428607709)
>> 68969.21893(1.03e+02): par = (76.0006985 -1.935226745 1.0190858)
>> 633.3672230(1.29e+00): par = (100.3761515 8.624648402 5.104490259)
>> 151.4400218(9.39e+00): par = (100.6344391 4.913490985 0.2849209569)
>> 53.08739850(7.24e+00): par = (100.6830407 6.899303317 0.4637755074)
>> 1.344478640(5.97e-01): par = (100.0368306 9.897714142 0.5169294939)
>> 0.9908415909 (1.55e-02): par = (100.0300625 9.9144191 0.5023516843)
>> 0.9906046057 (1.84e-05): par = (100.0288724 9.916224018 0.5025207336)
>> 0.9906046054 (9.95e-08): par = (100.028875 9.916228366 0.50252165)
>> 0.9906046054 (9.93e-08): par = (100.028875 9.916228366 0.50252165)
>> Error in nls(formula = y ~ Const + A * exp(B * x), algorithm = "default", :
>> step factor 0.000488281 reduced below 'minFactor' of 0.000976562
>> Calls: update -> update.default -> eval -> eval -> nls
>> Execution halted
>> ## After install, start R with --vanilla and run tests like this:
>> ##
>> https://cran.r-project.org/doc/manuals/r-patched/R-admin.html#Testing-a-Unix_002dalike-Installation
>> Sys.setenv(LC_COLLATE = "C", LC_TIME = "C", LANGUAGE = "en")
>> pdf("tests.pdf")
>> tools::testInstalledPackages(scope="base", errorsAreFatal=FALSE)
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] order of operations
Yes, and were it not for 0 * NA == NA, you might skip evaluation of y if x evaluates to zero. In Andre Gillibert's example: 1 | (alpha<-6) there really is no reason to evaluate the assignment since (1 | any) is always TRUE. Notwithstanding method dispatch, that is. With general function calls, all bets are off. Even f(x <- 1) might decide not to evaluate its argument. - pd > On 27 Aug 2021, at 21:14 , Duncan Murdoch wrote: > > On 27/08/2021 3:06 p.m., Enrico Schumann wrote: >> On Fri, 27 Aug 2021, Gabor Grothendieck writes: >>> Are there any guarantees of whether x will equal 1 or 2 after this is run? >>> >>> (x <- 1) * (x <- 2) >>> ## [1] 2 >>> x >>> ## [1] 2 >> At least the "R Language Definition" [1] says >> "The exponentiation operator ‘^’ and the left >>assignment plus minus operators ‘<- - = <<-’ >>group right to left, all other operators group >>left to right. That is [...] 1 - 1 - 1 is -1" >> which would imply 2. > > I think this is a different issue. There's only one operator in question > (the "*"). The question is whether x*y evaluates x first or y first (and I > believe the answer is that there are no guarantees). I'm fairly sure both are > guaranteed to be evaluated, under the rules for group generics listed in > ?groupGeneric, but I'm not certain the guarantee is honoured in all cases. > > Duncan Murdoch > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem in random number generation for Marsaglia-Multicarry + Kinderman-Ramage
With these matters, one has to be careful to distinguish between method error
and implementation error.
The reason for changing the RNG setup in R v. 1.7.0 was pretty much this kind
of unfortunate interaction between M-M and K-R. There are even more egregious
examples for the distribution of maxima of normal variables. Try e.g.
RNGversion("1.6.0") # Marsaglia-Multicarry, Kinderman-Ramage
s <- replicate(1e6,max(rnorm(10)))
plot(density(s))
(A further bug in K-R was fixed in 1.7.1, but that is tangential to this.)
A glimpse of the source of the problem is seen in the "microcorrelations" in
this:
RNGkind("Mar");m <- matrix(runif(4e7),2)
plot(m[1,],m[2,],xlim=c(0,1e-3),pch=".")
m <- matrix(runif(4e7),2)
points(m[1,],m[2,],pch=".")
These examples are from 2003, so the issue has been known for almost 2 decades.
However, to the best of our knowledge, the M-M RNG is a faithful implementation
of their method, so we have left the RNG in R's arsenal, in case someone needed
it for some specific purpose.
- pd
> On 12 Aug 2021, at 11:51 , GILLIBERT, Andre
> wrote:
>
> Dear R developers,
>
>
> In my opinion, I discovered a severe flaw that occur with the combination of
> the Marsaglia-Multicarry pseudo-random number generator associated to the
> Kinderman-Ramage algorithm to generate normally distributed numbers.
>
>
> The sample program is very simple (tested on R-4.1.1 x86_64 on Windows 10):
>
> set.seed(1, "Marsaglia-Multicarry", normal.kind="Kinderman-Ramage")
> v=rnorm(1e7)
> poisson.test(sum(v < (-4)))$conf.int # returns c(34.5, 62.5)
> poisson.test(sum(v > (4)))$conf.int # returns c(334.2, 410.7)
> pnorm(-4)*1e7 # returns 316.7
>
>
> There should be approximatively 316 values less than -4 and 316 values
> greater than +4, bug there are far too few values less than -4.
>
> Results are similar with other random seeds, and things are even more obvious
> with larger sample sizes.
>
> The Kinderman-Ramage algorithm is fine when combined to Mersenne-Twister, and
> Marsaglia-Multicarry is fine when combined with the normal.kind="Inversion"
> algorithm, but the combination of Marsaglia-Multicarry and Kinderman-Ramage
> seems to have severe flaws.
>
> R should at least warn for that combination !
>
> What do you think? Should I file a bug report?
>
> --
> Sincerely
> Andr� GILLIBERT
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem with pipes, textConnection and read.dcf
It's not a pipe issue:
> textConnection(gsub(gsub(L, pattern = " ", replacement = ""), pattern = " ",
> replacement = ""))
Error in textConnection(gsub(gsub(L, pattern = " ", replacement = ""), :
argument 'object' must deparse to a single character string
> textConnection(gsub(L, pattern = " ", replacement = ""))
A connection with
description "gsub(L, pattern = \" \", replacement = \"\")"
class "textConnection"
mode"r"
text"text"
opened "opened"
can read"yes"
can write "no"
I suppose the culprit is that the deparse(substitute(...)) construct in the
definition of textConnection() can generate multiple lines if the object
expression gets complicated.
> textConnection
function (object, open = "r", local = FALSE, name =
deparse(substitute(object)),
encoding = c("", "bytes", "UTF-8"))
This also suggests that setting name=something might be a cure.
-pd
> On 10 Aug 2021, at 21:33 , Gabor Grothendieck wrote:
>
> This gives an error bit if the first gsub line is commented out then there is
> no
> error even though it is equivalent code.
>
> L <- c("Variable:id", "Length:112630 ")
>
> L |>
>gsub(pattern = " ", replacement = "") |>
>gsub(pattern = " ", replacement = "") |>
>textConnection() |>
>read.dcf()
> ## Error in textConnection(gsub(gsub(L, pattern = " ", replacement = ""), :
> ## argument 'object' must deparse to a single character string
>
> That is this works:
>
> L |>
># gsub(pattern = " ", replacement = "") |>
>gsub(pattern = " ", replacement = "") |>
>textConnection() |>
>read.dcf()
> ## Variable Length
> ## [1,] "id" "112630"
>
> R.version.string
> ## [1] "R version 4.1.0 RC (2021-05-16 r80303)"
> win.version()
> ## [1] "Windows 10 x64 (build 19042)"
>
> --
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.
> tel: 1-877-GKX-GROUP
> email: ggrothendieck at gmail.com
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.1.1 is released
The build system rolled up R-4.1.1.tar.gz (codename "Kick Things") this morning. The list below details the changes in this release. You can get the source code from https://cran.r-project.org/src/base/R-4/R-4.1.1.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard These are the checksums (md5 and SHA-256) for the freshly created files, in case you wish to check that they are uncorrupted: MD5 (AUTHORS) = da5e7c699a83608d0f1e39c458d9fc56 MD5 (COPYING) = eb723b61539feef013de476e68b5c50a MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343 MD5 (FAQ) = 6094024214a482c0d01d2ab2adca4b3f MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b MD5 (NEWS) = fbc4810ff26ebcec514ebaa1c1909ad7 MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8 MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801 MD5 (NEWS.2) = a767f7809324c73c49eaff47d14bce81 MD5 (NEWS.3) = e55ed2c8a547b827b46e08eb7137ba23 MD5 (R-latest.tar.gz) = c278cfeb85b1564540ab214e45fe68d9 MD5 (README) = f468f281c919665e276a1b691decbbe6 MD5 (RESOURCES) = a79b9b338cab09bd665f6b62ac6f455b MD5 (THANKS) = 251d20510bfc3cc93b82c5a99f7efcc6 MD5 (VERSION-INFO.dcf) = 34443dff7fcea700c8ec4740e5804374 MD5 (R-4/R-4.1.1.tar.gz) = c278cfeb85b1564540ab214e45fe68d9 9704a7d96c350a48417ef215888a29f1993ee5dec1b73cb95755e8625b860200 AUTHORS e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB 2894e7a88634a08c05bfafb8a694a26b635e4042160aab46fa6a0f4eb68ea91e FAQ f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL e8bdaf546cf65fdc5bf2a81fa5334572886ff2f1317ec6cdc9e61d6de3532dd4 NEWS 4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0 12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1 ba74618bc3f4c0e336dca13d472402a1863d12ba6f7f91a1782bc469ee986f6d NEWS.2 1910a2405300b9bc7c76beeb0753a5249cf799afe175ce28f8d782fab723e012 NEWS.3 515e03265752257d0b7036f380f82e42b46ed8473f54f25c7b67ed25bbbdd364 R-latest.tar.gz 2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README 8b7d3856100220f4555d4d57140829f2e81c27eccec5b441f5dce616e9ec9061 RESOURCES c9c7cb32308b4e560a22c858819ade9de524a602abd4e92d1c328c89f8037d73 THANKS 02686ea05e64304a755bf776cdeeadafd2c5017a13f9203f1db9278287c81aa6 VERSION-INFO.dcf 515e03265752257d0b7036f380f82e42b46ed8473f54f25c7b67ed25bbbdd364 R-4/R-4.1.1.tar.gz This is the relevant part of the NEWS file CHANGES IN R 4.1.1: NEW FEATURES: * require(pkg, quietly = TRUE) is quieter and in particular does not warn if the package is not found. DEPRECATED AND DEFUNCT: * Use of ftp:// URIs should be regarded as deprecated, with on-going support confined to method = "libcurl" and not routinely tested. (Nowadays no major browser supports them.) * The non-default method = "internal" is deprecated for http:// and ftp:// URIs for both download.file and url. * On Windows, method = "wininet" is deprecated for http://, https:// and ftp:// URIs for both download.file and url. (A warning is only given for ftp://.) For ftp:// URIs the default method is now "libcurl" if available (which it is on CRAN builds). method = "wininet" remains the default for http:// and https:// URIs but if libcurl is available, using method = "libcurl" is preferred. INSTALLATION: * make check now works also without a LaTeX installation. (Thanks to Sebastian Meyer's PR#18103.) BUG FIXES: * make check-devel works again in an R build configured with --without-recommended-packages. * qnbinom(p, size, mu) for large size/mu is correct now in a range of cases (PR#18095); similarly for the (size, prob) parametrization of the negative binomial. Also qpois() and qbinom() are better and or faster for extreme cases. The underlying C code has been modularized and is common to all four cases of discrete distributions. * gap.axis is now part of the axis() arguments which are passed from bxp(), and hence boxplot(). (Thanks to Martin Smith's report and suggestions in PR#18109.) * .First and .Last can again be set from the site profile. * seq.int(from, to, *) and seq.default(..) now work better in large range cases where from-to is infinite where the two boundaries are finite. * all.equal(x,y) now returns TRUE correctly also when several entries of abs(x) and abs(y) are close to .Machine$double.xmax, the largest finite numeric. * model.frame() now clears the object bit when removing the class attribute of a value via na.action (PR#18100). * charClass() now works with multi-character strings on Windows (PR#18104, fixed by Bill Dunlap)
Re: [Rd] I changed my vignette's file name to lowercase, then realized the url was case-sensitive
R-help would surely be wrong, no? (R-package-devel is optimal, I agree) - Peter > On 2 Aug 2021, at 11:59 , Martin Maechler wrote: > > Dear Dominic, > > This is the wrong mailing list for such questions > Do use 'R-help' or 'R-package-devel' instead, please. > > (and also please do use __plain text__ > instead of "formatted" / "rich text" / ... e-mail ) > > Best, > Martin Maechler > > >>>>>> Dominic Comtois >>>>>>on Mon, 2 Aug 2021 02:36:27 -0400 writes: > >> I changed my "Introduction.html" vignette's name to >> "introduction.html", realizing only after the fact that >> CRAN's URLs are case sensitive. > >> Would the solution of adding to my package's source a new >> Introduction.html file pointing to introduction.html using >> a be a viable one? Or is >> there maybe another, better solution? > >> Thanks in advance > >> Dominic Comtois, summarytools author & maintainer > >> [[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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.1.1 scheduled for August 10
Full schedule is available on developer.r-project.org. (This comes somewhat late this year, partly because we needed to squeeze in 4.0.5 before 4.1.0 could be released.) -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] On read.csv and write.csv
?read.csv does actually have
row.names: a vector of row names. This can be a vector giving the
actual row names, or a single number giving the column of the
table which contains the row names, or character string
giving the name of the table column containing the row names.
-pd
> On 5 Jul 2021, at 12:37 , Stephen Ellison wrote:
>
>> From: Simon Urbanek
>> By default there is no column name for a column of row names.
>
>> spreadsheets. Note that such CSV files can be read in R by
>>
>> read.csv(file = "", row.names = 1)
> AHA!! Many thanks.
> I see this clue is in ?write.table, though; I was looking for help on reading
> CSVs in ?read.csv etc.
>
>
> Thanks to all for your time answering this; much appreciated.
>
> S
>
>
> ***
> This email and any attachments are confidential. Any u...{{dropped:21}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] {splines} package gone missing?
No, it really is base R, not Recommended:
Peters-MacBook-Air:BUILD pd$ ls ../R/src/library/Recommended/
KernSmooth.tgz foreign.tgz
KernSmooth_2.23-20.tar.gz foreign_0.8-81.tar.gz
MASS.tgzlattice.tgz
MASS_7.3-54.tar.gz lattice_0.20-44.tar.gz
Makefile.in mgcv.tgz
Makefile.winmgcv_1.8-35.tar.gz
Matrix.tgz nlme.tgz
Matrix_1.3-3.tar.gz nlme_3.1-152.tar.gz
boot.tgznnet.tgz
boot_1.3-28.tar.gz nnet_7.3-16.tar.gz
class.tgz rpart.tgz
class_7.3-19.tar.gz rpart_4.1-15.tar.gz
cluster.tgz spatial.tgz
cluster_2.1.2.tar.gzspatial_7.3-14.tar.gz
codetools.tgz survival.tgz
codetools_0.2-18.tar.gz survival_3.2-11.tar.gz
Peters-MacBook-Air:BUILD pd$ ls ../R/src/library/
Makefile.in compilergridsplines tools
Makefile.windatasetsmethods stats translations
Recommended grDevices parallelstats4 utils
basegraphicsprofile tcltk
> row.names(installed.packages(priority = "base"))
[1] "base" "compiler" "datasets" "graphics" "grDevices" "grid"
[7] "methods" "parallel" "splines" "stats" "stats4""tcltk"
[13] "tools" "utils"
'profile' is not an actual package, though.
- Peter
> On 20 May 2021, at 13:12 , Ben Bolker wrote:
>
> splines is 'recommended' ( not sure about capitalization), not "base'
>
> On Thu, May 20, 2021, 7:02 AM Randall Pruim wrote:
> Thanks. I actually sort of checked for this:
>
>
> row.names(installed.packages(priority = "base"))
> [1] "base" "compiler" "datasets" "graphics" "grDevices" "grid"
> "methods" "parallel" "stats" "stats4""tcltk"
> [12] "tools" "utils"
>
> But, of course, if the package is missing on my system (a newly installed 4.1
> on an RStudio server), then it won’t be listed here.
>
> I’ll have to figure out what went wrong with the install. I’ll probably
> start by having our sysadmin simply reinstall R 4.1 and hope that that takes
> care of the problem.
>
> Looks like profile is missing as well.
>
> —rjp
>
> On May 20, 2021, at 3:14 AM, peter dalgaard
> mailto:pda...@gmail.com>> wrote:
>
> It is part of base R, so comes with the R sources:
>
> Peters-MacBook-Air:R pd$ ls src/library/
> Makefile.in compiler/ grid/ splines/ tools/
> Makefile.win<http://Makefile.win> datasets/ methods/ stats/
> translations/
> Recommended/ grDevices/parallel/ stats4/ utils/
> base/ graphics/ profile/ tcltk/
>
> - pd
>
> On 20 May 2021, at 06:02 , Randall Pruim
> mailto:rpr...@calvin.edu>> wrote:
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cran.r-2Dproject.org_web_packages_splines_index.html=DwIFaQ=4rZ6NPIETe-LE5i2KBR4rw=S6U-baLhvGcJ7iUQX_KZ6K2om1TTOeUI_-mjRpTrm00=GW4Zim0TvggrmjKt0HtW7il0NwJJaworM4-LL3H2FyI=69EYlZJd6di726T20ILKnX7f4GWM-VaUplRjNXfGolQ=
> claims the the {splines} package has been archived. If I follow the link
> there to the archives, the newest version shown is from 1999. It seems like
> something has gone wrong with this package.
>
> I checked on another mirror and {splines} is missing there as well.
>
> —rjp
>
> __
> R-devel@r-project.org<mailto:R-devel@r-project.org> mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Ddevel=DwIFaQ=4rZ6NPIETe-LE5i2KBR4rw=S6U-baLhvGcJ7iUQX_KZ6K2om1TTOeUI_-mjRpTrm00=GW4Zim0TvggrmjKt0HtW7il0NwJJaworM4-LL3H2FyI=Jen0Ht23Vg-znRGxp8YPRc-qCbG0uLYGAyyECxU6kFg=
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk<mailto:pd@cbs.dk> Priv:
> pda...@gmail.com<mailto:pda...@gmail.com>
>
>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.1.0 is released
The build system rolled up R-4.1.0.tar.gz (codename "Camp Pontanezen") this morning. This is a major update, notably containing the new native pipe operator "|>" and shorthand inline functions "\(x) x+1". The list below details the changes in this release. You can get the source code from https://cran.r-project.org/src/base/R-4/R-4.1.0.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard These are the checksums (md5 and SHA-256) for the freshly created files, in case you wish to check that they are uncorrupted: MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4 MD5 (COPYING) = eb723b61539feef013de476e68b5c50a MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343 MD5 (FAQ) = 639fbbba9998cae70ef058be42b80a52 MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b MD5 (NEWS) = b02805558a8315f1a93c7f7d7cd879c1 MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8 MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801 MD5 (NEWS.2) = a767f7809324c73c49eaff47d14bce81 MD5 (NEWS.3) = e55ed2c8a547b827b46e08eb7137ba23 MD5 (R-latest.tar.gz) = bd80f97d0e46a71408f5bc25652a0203 MD5 (README) = f468f281c919665e276a1b691decbbe6 MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435 MD5 (THANKS) = 251d20510bfc3cc93b82c5a99f7efcc6 MD5 (VERSION-INFO.dcf) = 1f3cf39735afb48fea434bca2b7bf483 MD5 (R-4/R-4.1.0.tar.gz) = bd80f97d0e46a71408f5bc25652a0203 2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09 AUTHORS e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB 0dce85f38b9d6351a1b63f057dfbc7f572966245add12946482e57e60d41547c FAQ f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL 20e7185fb5af0f2ac825b27c16afd57ff206726117c6ac5cf7c6f230337af093 NEWS 4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0 12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1 ba74618bc3f4c0e336dca13d472402a1863d12ba6f7f91a1782bc469ee986f6d NEWS.2 1910a2405300b9bc7c76beeb0753a5249cf799afe175ce28f8d782fab723e012 NEWS.3 e8e68959d7282ca147360fc9644ada9bd161bab781bab14d33b8999a95182781 R-latest.tar.gz 2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README 408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9 RESOURCES c9c7cb32308b4e560a22c858819ade9de524a602abd4e92d1c328c89f8037d73 THANKS 2f834a058dcfcdfb7eedf45aa0d897ea1a7c43a9460ffd22f73b60919cb1bf57 VERSION-INFO.dcf e8e68959d7282ca147360fc9644ada9bd161bab781bab14d33b8999a95182781 R-4/R-4.1.0.tar.gz This is the relevant part of the NEWS file CHANGES IN R 4.1.0: FUTURE DIRECTIONS: * It is planned that the 4.1.x series will be the last to support 32-bit Windows, with production of binary packages for that series continuing until early 2023. SIGNIFICANT USER-VISIBLE CHANGES: * Data set esoph in package datasets now provides the correct numbers of controls; previously it had the numbers of cases added to these. (Reported by Alexander Fowler in PR#17964.) NEW FEATURES: * www.omegahat.net is no longer one of the repositories known by default to setRepositories(). (Nowadays it only provides source packages and is often unavailable.) * Function package_dependencies() (in package tools) can now use different dependency types for direct and recursive dependencies. * The checking of the size of tarball in R CMD check --as-cran may be tweaked via the new environment variable _R_CHECK_CRAN_INCOMING_TARBALL_THRESHOLD_, as suggested in PR#1 by Jan Gorecki. * Using c() to combine a factor with other factors now gives a factor, an ordered factor when combining ordered factors with identical levels. * apply() gains a simplify argument to allow disabling of simplification of results. * The format() method for class "ftable" gets a new option justify. (Suggested by Thomas Soeiro.) * New ...names() utility. (Proposed by Neal Fultz in PR#17705.) * type.convert() now warns when its as.is argument is not specified, as the help file always said it _should_. In that case, the default is changed to TRUE in line with its change in read.table() (related to stringsAsFactor) in R 4.0.0. * When printing list arrays, classed objects are now shown _via_ their format() value if this is a short enough character string, or by giving the first elements of their class vector and their length. * capabilities() gets new entry "Rprof" which is TRUE when R has been configured with the equivalent of --enable-R-profiling (as it is by default). (Related to Michael Orlitzky's report PR#17836.) * str(xS4) now also shows extraneous attributes of an S4 object xS4.
Re: [Rd] {splines} package gone missing?
It is part of base R, so comes with the R sources:
Peters-MacBook-Air:R pd$ ls src/library/
Makefile.in compiler/ grid/ splines/ tools/
Makefile.win datasets/ methods/ stats/translations/
Recommended/ grDevices/parallel/ stats4/ utils/
base/ graphics/ profile/ tcltk/
- pd
> On 20 May 2021, at 06:02 , Randall Pruim wrote:
>
>
> https://cran.r-project.org/web/packages/splines/index.html claims the the
> {splines} package has been archived. If I follow the link there to the
> archives, the newest version shown is from 1999. It seems like something has
> gone wrong with this package.
>
> I checked on another mirror and {splines} is missing there as well.
>
> —rjp
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] base R pipe documentation
OK, zapped the \note for 4-1-branch (for now). This close to release, changes have to be very small and safe to be allowed in, so anything more than that will have to wait for a later version. - Peter > On 17 May 2021, at 19:20 , Ben Bolker wrote: > > As of right now, as far as I can tell, the documentation for the new native > |> pipe still says that it's experimental. > > https://github.com/wch/r-source/blob/trunk/src/library/base/man/pipeOp.Rd#L45 > > *Pipe support is experimental and may change prior to release.* > > Also still in the 4-1 branch: > > https://github.com/wch/r-source/blob/R-4-1-branch/src/library/base/man/pipeOp.Rd#L45 > > (The corresponding comment in the NEWS file has been fixed in the last 24 > hours, but hasn't propagated to the online/HTML version on the developer page > yet ...) > > As a "wish list" item, if there are any particularly salient/important > differences between the |> pipe and the %>% magrittr pipe, it would be great > to have those documented (I know that documenting the difference between a > base-R operator and the one that's implemented in a non-Recommended package > is a little weird, but it would be helpful in this case ...) I know I could > go back to the mailing list discussion at > https://hypatia.math.ethz.ch/pipermail/r-devel/2020-December/080173.html and > try to figure it out for myself ... > > cheers > Ben Bolker > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R compilation on old(ish) CentOS
You may want to check out your checkout I see: Peter-Dalgaards-iMac:R pd$ grep newsock src/main/connections.c con = R_newsock(host, port, server, serverfd, open, timeout, options); but your file seems to have lost the ", options" bit somehow. Also, mine is line 3488, not 3477. Maybe you have an old file getting in the way? - Peter > On 29 Apr 2021, at 15:58 , Ben Bolker wrote: > > I probably don't want to go down this rabbit hole very far, but if anyone > has any *quick* ideas ... > > Attempting to build R from scratch with a fresh SVN checkout on a somewhat > out-of-date CentOS system (for which I don't have root access, although I can > bug people if I care enough). > > ../r-devel/configure; make > > ends with > > gcc -std=gnu99 -I../../../r-devel/trunk/src/extra -I. -I../../src/include > -I../../../r-devel/trunk/src/include -I/usr/local/include > -I../../../r-devel/trunk/src/nmath -DHAVE_CONFIG_H -fopenmp -g -O2 -c > ../../../r-devel/trunk/src/main/connections.c -o connections.o > ../../../r-devel/trunk/src/main/connections.c: In function ‘do_sockconn’: > ../../../r-devel/trunk/src/main/connections.c:3477:5: error: too few > arguments to function ‘R_newsock’ > con = R_newsock(host, port, server, serverfd, open, timeout); > ^ > In file included from ../../../r-devel/trunk/src/main/connections.c:80:0: > ../../../r-devel/trunk/src/include/Rconnections.h:83:13: note: declared here > Rconnection R_newsock(const char *host, int port, int server, int serverfd, > const char * const mode, int timeout, int options); > ^ > make[3]: *** [connections.o] Error 1 > > Any suggestions for a quick fix/diagnosis? > > cheers >Ben Bolker > > > > > $ gcc --version > gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39) > > $ lsb_release -a > LSB Version: > :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch > Distributor ID: CentOS > Description: CentOS Linux release 7.8.2003 (Core) > Release: 7.8.2003 > Codename: Core > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.1.0 scheduled for May 18
Full schedule is available on developer.r-project.org. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ 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] R 4.0.5 is released
The build system rolled up R-4.0.5.tar.gz (codename "Shake and Throw") this morning. This is a very minor update, mostly to fix the annoyance with East Asian character sets. The list below details the changes in this release. You can get the source code from https://cran.r-project.org/src/base/R-4/R-4.0.5.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard These are the checksums (md5 and SHA-256) for the freshly created files, in case you wish to check that they are uncorrupted: MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4 MD5 (COPYING) = eb723b61539feef013de476e68b5c50a MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343 MD5 (FAQ) = 639fbbba9998cae70ef058be42b80a52 MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b MD5 (NEWS) = 553381d79675220a90cf9b264997e458 MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8 MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801 MD5 (NEWS.2) = 496062c138e2def06cebccddfb814ac6 MD5 (NEWS.3) = 012e7f4a80cc8ec947bf3f0ff6117ec8 MD5 (R-latest.tar.gz) = eb8fb47cc91ff287005c1633ef8599e6 MD5 (README) = f468f281c919665e276a1b691decbbe6 MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435 MD5 (THANKS) = 251d20510bfc3cc93b82c5a99f7efcc6 MD5 (VERSION-INFO.dcf) = 62b1389bc9fed2bf5857c0c99ef490f2 MD5 (R-4/R-4.0.5.tar.gz) = eb8fb47cc91ff287005c1633ef8599e6 2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09 AUTHORS e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB 0dce85f38b9d6351a1b63f057dfbc7f572966245add12946482e57e60d41547c FAQ f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL bbee124ddbd6682ecbaa5193d5ffc35aa090fcf29b30a9ad6f1498074a720388 NEWS 4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0 12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1 e80de410c77f05ff2012fa70051b89119845f734a7fa5c55857e61e4ed7d5f6e NEWS.2 7201d139947afa52b5e09d26dc01445edf444506264355b2185122bc1ed3dce0 NEWS.3 0a3ee079aa772e131fe5435311ab627fcbccb5a50cabc54292e6f62046f1ffef R-latest.tar.gz 2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README 408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9 RESOURCES c9c7cb32308b4e560a22c858819ade9de524a602abd4e92d1c328c89f8037d73 THANKS 6f7663cb7813af1228978d9ef356fb6e6dad131fab9bbed507b657b48e2df6bd VERSION-INFO.dcf 0a3ee079aa772e131fe5435311ab627fcbccb5a50cabc54292e6f62046f1ffef R-4/R-4.0.5.tar.gz This is the relevant part of the NEWS file CHANGES IN R 4.0.5: BUG FIXES: * The change to the internal table in R 4.0.4 for iswprint has been reverted: it contained some errors in printability of 'East Asian' characters. * For packages using LazyData, R CMD build ignored the --resave-data option and the BuildResaveData field of the DESCRIPTION file (in R versions 4.0.0 to 4.0.4). -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ 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] R 4.0.5 scheduled for March 31
Full schedule is available on https://developer.r-project.org (or https://svn.r-project.org/R-dev-web/trunk/index.html for the impatient). (This is a fast-track release, to resolve an issue with Asian character sets and another issue with R CMD build, before R 4.1.0) -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ 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] trivial typo in src/library/base/man/pmatch.Rd
I suspect this is as meant, but it is "multiply", the adverb, not the verb. So it might be worth rephrasing, but "multiple" would be wrong (it is about cases where you at one position have several partial matches, not several positions where you have a partial match). "Non-uniquely partially matching", perhaps? -pd > On 13 Mar 2021, at 01:50 , Ben Bolker wrote: > > ll. 17-18 of src/library/base/man/pmatch.Rd says "the value to be returned at > non-matching or multiply partially matching positions". > > I think "multiply" should be "multiple" there? > > Can submit an actual patch if that would be more useful. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.0.4 is released
The build system rolled up R-4.0.4.tar.gz (codename "Lost Library Book") this
morning.
The list below details the changes in this release.
You can get the source code from
https://cran.r-project.org/src/base/R-4/R-4.0.4.tar.gz
or wait for it to be mirrored at a CRAN site nearer to you.
Binaries for various platforms will appear in due course.
For the R Core Team,
Peter Dalgaard
These are the checksums (md5 and SHA-256) for the freshly created files, in
case you wish
to check that they are uncorrupted:
MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4
MD5 (COPYING) = eb723b61539feef013de476e68b5c50a
MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343
MD5 (FAQ) = a5596520508b8749aa18baea2cf8ff80
MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b
MD5 (NEWS) = eeb2d15f39e0a38935de2c419b4263f7
MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8
MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801
MD5 (NEWS.2) = 496062c138e2def06cebccddfb814ac6
MD5 (NEWS.3) = 012e7f4a80cc8ec947bf3f0ff6117ec8
MD5 (R-latest.tar.gz) = e205f000947f99eeba0fb6311bd61970
MD5 (README) = f468f281c919665e276a1b691decbbe6
MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435
MD5 (THANKS) = 251d20510bfc3cc93b82c5a99f7efcc6
MD5 (VERSION-INFO.dcf) = 6a5ad95f3b708ce0dc19bab8bbfc3bc0
MD5 (R-4/R-4.0.4.tar.gz) = e205f000947f99eeba0fb6311bd61970
2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09 AUTHORS
e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING
6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB
e9783551b3724b368a42c1300a8e5795ae84add34823c4eb9d8054a0e76f592c FAQ
f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL
2227d48d78c4d70d07c367ecd4c5ba60a04a699ed0391fabac3da6edffdaa5db NEWS
4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0
12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1
e80de410c77f05ff2012fa70051b89119845f734a7fa5c55857e61e4ed7d5f6e NEWS.2
7201d139947afa52b5e09d26dc01445edf444506264355b2185122bc1ed3dce0 NEWS.3
523f27d69744a08c8f0bd5e1e6c3d89a4db29ed983388ba70963a3cd3a4a802e
R-latest.tar.gz
2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README
408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9 RESOURCES
c9c7cb32308b4e560a22c858819ade9de524a602abd4e92d1c328c89f8037d73 THANKS
6c5117e36f4e69f0cd90f3bab6e7fd47ec90b0047e2aaed145300ad4ece20ede
VERSION-INFO.dcf
523f27d69744a08c8f0bd5e1e6c3d89a4db29ed983388ba70963a3cd3a4a802e
R-4/R-4.0.4.tar.gz
This is the relevant part of the NEWS file
CHANGES IN R 4.0.4:
NEW FEATURES:
* File share/texmf/tex/latex/jss.cls has been updated to work with
LaTeX versions since Oct 2020.
* Unicode character width tables (as used by nchar(, type = "w"))
have been updated to Unicode 12.1 by Brodie Gaslam (PR#17781),
including many emoji.
* The internal table for iswprint (used on Windows, macOS and AIX)
has been updated to include many recent Unicode characters.
INSTALLATION on a UNIX-ALIKE:
* If an external BLAS is specified by --with-blas=foo or _via_
environment variable BLAS_LIBS is not found, this is now a
configuration error. The previous behaviour was not clear from
the documentation: it was to continue the search as if
--with-blas=yes was specified.
BUG FIXES:
* all.equal(x,y) now "sees" the two different NAs in factors,
thanks to Bill Dunlap and others in PR#17897.
* (~ NULL)[1] and similar formula subsetting now works, thanks to a
report and patch by Henrik Bengtsson in PR#17935. Additionally,
subsetting leaving an empty formula now works too, thanks to
suggestions by Suharto Anggono.
* .traceback(n) keeps source references again, as before R 4.0.0,
fixing a regression; introduced by the PR#17580, reported
including two patch proposals by Brodie Gaslam.
* unlist(plst, recursive=FALSE) no longer drops content for
pairlists with list components, thanks to the report and patch by
Suharto Anggono in PR#17950.
* iconvlist() now also works on MUSL based (Linux) systems, from a
report and patch suggestion by Wesley Chan in PR#17970.
* round() and signif() no longer tolerate wrong argument names,
notably in 1-argument calls; reported by Shane Mueller on R-devel
(mailing list); later reported as PR#17976.
* .Machine has longdouble.* elements only if
capabilities("long.double") is true, as documented. (Previously
they were included if the platform had long double identical to
double, as ARM does.)
* p.adjust(numeric(), n=0) now works, fixing PR#18002.
* identical(x,y) no longer prints "Unknown Type .." for typeof(x)
== "..." objects.
* Fix (auto-)print()ing of named complex vectors, see PR#17868 and
PR#18019.
* all.equal(, <...>) now works,
[Rd] R 4.0.4 scheduled for February 15
Full schedule is available on https://developer.r-project.org (or https://svn.r-project.org/R-dev-web/trunk/index.html for the impatient). -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ 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] sorting bug in R-devel?
quot;\347" "\351" > ## Ubuntu 18.04 R 4.0.3 > [1] "\ta" "\na" "\"NA\"" "\"b" "\"b\"" "#" "$" > [8] "&" "'NA'""'b" "'b'" "" "" "" > [15] "" "" "@" "a" "a\t" "a\tb""a\tb\tc" > [22] "a\n" "a\nb""a\nb\nc" "a b" "a b c" "a\"" "a\"b" > [29] "a\"b\"c" "a'" "a'b" "a'b'c" "|" > > # order > ## Win 10 R 4.0.2 > [1] 5 9 22 13 15 32 34 26 23 18 20 28 27 29 25 30 33 1 6 3 4 10 7 8 2 > [26] 21 14 11 12 19 16 17 31 24 > ## Win 10 R devel > [1] 5 9 22 13 15 32 34 26 23 18 20 33 1 6 3 4 10 7 8 2 21 14 11 12 19 > [26] 16 17 31 30 28 27 29 25 24 > ## Ubuntu 18.04 R 4.0.3 > [1] 5 9 22 13 15 32 34 26 23 18 20 28 27 29 25 30 33 1 6 3 4 10 7 8 2 > [26] 21 14 11 12 19 16 17 31 24 > > R version 4.0.2 (2020-06-22) > Platform: x86_64-w64-mingw32/x64 (64-bit) > Running under: Windows 10 x64 (build 18363) > > Matrix products: default > > locale: > [1] C > system code page: 1252 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > loaded via a namespace (and not attached): > [1] compiler_4.0.2 fortunes_1.5-4 > > R Under development (unstable) (2021-01-13 r79826) > Platform: x86_64-w64-mingw32/x64 (64-bit) > Running under: Windows 10 x64 (build 18363) > > Matrix products: default > > locale: > [1] C > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > loaded via a namespace (and not attached): > [1] compiler_4.1.0 > > R version 4.0.3 (2020-10-10) > Platform: x86_64-pc-linux-gnu (64-bit) > Running under: Ubuntu 18.04.5 LTS > > Matrix products: default > BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1 > LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1 > > locale: > [1] LC_CTYPE=C LC_NUMERIC=C > [3] LC_TIME=C LC_COLLATE=C > [5] LC_MONETARY=C LC_MESSAGES=nl_BE.UTF-8 > [7] LC_PAPER=nl_BE.UTF-8 LC_NAME=C > [9] LC_ADDRESS=C LC_TELEPHONE=C > [11] LC_MEASUREMENT=nl_BE.UTF-8 LC_IDENTIFICATION=C > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > loaded via a namespace (and not attached): > [1] compiler_4.0.3 fortunes_1.5-4 > > > ir. Thierry Onkelinx > Statisticus / Statistician > > Vlaamse Overheid / Government of Flanders > INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE > AND FOREST > Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance > thierry.onkel...@inbo.be > Havenlaan 88 bus 73, 1000 Brussel > www.inbo.be > > /// > To call in the statistician after the experiment is done may be no > more than asking him to perform a post-mortem examination: he may be > able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher > The plural of anecdote is not data. ~ Roger Brinner > The combination of some data and an aching desire for an answer does > not ensure that a reasonable answer can be extracted from a given body > of data. ~ John Tukey > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New pipe operator
> On 9 Dec 2020, at 16:20 , Duncan Murdoch wrote: > > To me curry(mean, na.rm = TRUE)(x) looks a lot more complicated than mean(x, > na.rm = TRUE), especially since it has the additional risk that users can > define their own function called "curry". Not to mention that it would make people's data handling scripts look like the menu at an Indian restaurant ;-) -pd -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New pipe operator
> On 7 Dec 2020, at 17:35 , Duncan Murdoch wrote: > > On 07/12/2020 11:18 a.m., peter dalgaard wrote: >> Hmm, >> I feel a bit bad coming late to this, but I think I am beginning to side >> with those who want "... |> head" to work. And yes, that has to happen at >> the expense of |> head(). > > Just curious, how would you express head(df, 10)? Currently it is > > df |> head(10) > > Would I have to write it as > > df |> function(d) head(d, 10) It could be df |> ~ head(_, 10) which in a sense is "yes" to your question. > >> As I think it was Gabor points out, the current structure goes down a >> nonstandard evaluation route, which may be difficult to explain and departs >> from usual operator evaluation paradigms by being an odd mix of syntax and >> semantics. R lets you do these sorts of thing, witness ggplot and tidyverse, >> but the transparency of the language tends to suffer. > > I wouldn't call it non-standard evaluation. There is no function > corresponding to |>, so there's no evaluation at all. It is more like the > way "x -> y" is parsed as "y <- x", or "if (x) y" is transformed to `if`(x, > y). That's a point, but maybe also my point. Currently, the parser is inserting the LHS as the 1st argument of the RHS, right? Things might be simpler if it was more like a simple binop. -pd > Duncan Murdoch > >> It would be neater if it was simply so that the class/type of the object on >> the right hand side decided what should happen. So we could have a rule that >> we could have an object, an expression, and possibly an unevaluated call on >> the RHS. Or maybe a formula, I.e., we could hav >> ... |> head >> but not >> ... |> head() >> because head() does not evaluate to anything useful. Instead, we could have >> some of these >> ... |> quote(head()) >> ... |> expression(head()) >> ... |> ~ head() >> ... |> \(_) head(_) >> possibly also using a placeholder mechanism for the three first ones. I kind >> of like the idea that the ~ could be equivalent to \(_). >> (And yes, I am kicking myself a bit for not using ~ in the NSE arguments in >> subset() and transform()) >> -pd >>> On 7 Dec 2020, at 16:20 , Deepayan Sarkar wrote: >>> >>> On Mon, Dec 7, 2020 at 6:53 PM Gabor Grothendieck >>> wrote: >>>> >>>> On Mon, Dec 7, 2020 at 5:41 AM Duncan Murdoch >>>> wrote: >>>>> I agree it's all about call expressions, but they aren't all being >>>>> treated equally: >>>>> >>>>> x |> f(...) >>>>> >>>>> expands to f(x, ...), while >>>>> >>>>> x |> `function`(...) >>>>> >>>>> expands to `function`(...)(x). This is an exception to the rule for >>>>> other calls, but I think it's a justified one. >>>> >>>> This admitted inconsistency is justified by what? No argument has been >>>> presented. The justification seems to be implicitly driven by >>>> implementation >>>> concerns at the expense of usability and language consistency. >>> >>> Sorry if I have missed something, but is your consistency argument >>> basically that if >>> >>> foo <- function(x) x + 1 >>> >>> then >>> >>> x |> foo >>> x |> function(x) x + 1 >>> >>> should both work the same? Suppose it did. Would you then be OK if >>> >>> x |> foo() >>> >>> no longer worked as it does now, and produced foo()(x) instead of foo(x)? >>> >>> If you are not OK with that and want to retain the current behaviour, >>> what would you want to happen with the following? >>> >>> bar <- function(x) function(n) rnorm(n, mean = x) >>> >>> 10 |> bar(runif(1))() # works 'as expected' ~ bar(runif(1))(10) >>> 10 |> bar(runif(1)) # currently bar(10, runif(1)) >>> >>> both of which you probably want. But then >>> >>> baz <- bar(runif(1)) >>> 10 |> baz >>> >>> (not currently allowed) will not be the same as what you would want from >>> >>> 10 |> bar(runif(1)) >>> >>> which leads to a different kind of inconsistency, doesn't it? >>> >>> -Deepayan >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel > -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New pipe operator
Hmm, I feel a bit bad coming late to this, but I think I am beginning to side with those who want "... |> head" to work. And yes, that has to happen at the expense of |> head(). As I think it was Gabor points out, the current structure goes down a nonstandard evaluation route, which may be difficult to explain and departs from usual operator evaluation paradigms by being an odd mix of syntax and semantics. R lets you do these sorts of thing, witness ggplot and tidyverse, but the transparency of the language tends to suffer. It would be neater if it was simply so that the class/type of the object on the right hand side decided what should happen. So we could have a rule that we could have an object, an expression, and possibly an unevaluated call on the RHS. Or maybe a formula, I.e., we could have ... |> head but not ... |> head() because head() does not evaluate to anything useful. Instead, we could have some of these ... |> quote(head()) ... |> expression(head()) ... |> ~ head() ... |> \(_) head(_) possibly also using a placeholder mechanism for the three first ones. I kind of like the idea that the ~ could be equivalent to \(_). (And yes, I am kicking myself a bit for not using ~ in the NSE arguments in subset() and transform()) -pd > On 7 Dec 2020, at 16:20 , Deepayan Sarkar wrote: > > On Mon, Dec 7, 2020 at 6:53 PM Gabor Grothendieck > wrote: >> >> On Mon, Dec 7, 2020 at 5:41 AM Duncan Murdoch >> wrote: >>> I agree it's all about call expressions, but they aren't all being >>> treated equally: >>> >>> x |> f(...) >>> >>> expands to f(x, ...), while >>> >>> x |> `function`(...) >>> >>> expands to `function`(...)(x). This is an exception to the rule for >>> other calls, but I think it's a justified one. >> >> This admitted inconsistency is justified by what? No argument has been >> presented. The justification seems to be implicitly driven by implementation >> concerns at the expense of usability and language consistency. > > Sorry if I have missed something, but is your consistency argument > basically that if > > foo <- function(x) x + 1 > > then > > x |> foo > x |> function(x) x + 1 > > should both work the same? Suppose it did. Would you then be OK if > > x |> foo() > > no longer worked as it does now, and produced foo()(x) instead of foo(x)? > > If you are not OK with that and want to retain the current behaviour, > what would you want to happen with the following? > > bar <- function(x) function(n) rnorm(n, mean = x) > > 10 |> bar(runif(1))() # works 'as expected' ~ bar(runif(1))(10) > 10 |> bar(runif(1)) # currently bar(10, runif(1)) > > both of which you probably want. But then > > baz <- bar(runif(1)) > 10 |> baz > > (not currently allowed) will not be the same as what you would want from > > 10 |> bar(runif(1)) > > which leads to a different kind of inconsistency, doesn't it? > > -Deepayan > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in unsplit() with tibbles
I get the sentiment, but this is really just bad coding (on my own part, I
suspect), so we might as well just fix it...
-pd
> On 21 Nov 2020, at 17:42 , Marc Schwartz via R-devel
> wrote:
>
>
>> On Nov 21, 2020, at 10:55 AM, Mario Annau wrote:
>>
>> Hello,
>>
>> using the `unsplit()` function with tibbles currently leads to the
>> following error:
>>
>>> mtcars_tb <- as_tibble(mtcars, rownames = NULL)
>>> s <- split(mtcars_tb, mtcars_tb$gear)
>>> unsplit(s, mtcars_tb$gear)
>> Error: Must subset rows with a valid subscript vector.
>> ℹ Logical subscripts must match the size of the indexed input.
>> x Input has size 15 but subscript `rep(NA, len)` has size 32.
>> Run `rlang::last_error()` to see where the error occurred.
>>
>> Tibble seems to (rightly) complain, that a logical vector has been used for
>> subsetting which does not have the same length as the data.frame (rows).
>> Since `NA` is a logical value, the subset should be changed to
>> `NA_integer_` in `unsplit()`:
>>
>>> unsplit
>> function (value, f, drop = FALSE)
>> {
>> len <- length(if (is.list(f)) f[[1L]] else f)
>> if (is.data.frame(value[[1L]])) {
>> x <- value[[1L]][rep(*NA_integer_*, len), , drop = FALSE]
>> rownames(x) <- unsplit(lapply(value, rownames), f, drop = drop)
>> }
>> else x <- value[[1L]][rep(NA, len)]
>> split(x, f, drop = drop) <- value
>> x
>> }
>>
>> Cheers,
>> Mario
>
>
> Hi,
>
> Perhaps I am missing something, but if you are using objects, like tibbles,
> that are intended to be part of another environment, in this case the
> tidyverse, why would you not use functions to manipulate these objects that
> were specifically created in the other environment?
>
> I don't use the tidyverse, but it seems to me that to expect base R functions
> to work with objects not created in base R, is problematic, even though,
> perhaps by coincidence, they may work without adverse effects, as appears to
> be the case with split().
>
> In other words, you should not, in reality, have had an a priori expectation
> that split() would work with a tibble either.
>
> Rather than modifying the base R functions, like unsplit(), as you are
> suggesting, to be compatible with these third party objects, the burden
> should either be on you to use relevant tidyverse functions, or on the
> authors of the tidyverse to provide relevant class methods to provide that
> functionality.
>
> Regards,
>
> Marc Schwartz
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in unsplit() with tibbles
Yes. Nevermind tibbles, the [rep(NA, len),] construction only happens to work
because len will always be >= the number of rows in value[[1L]], witness
> (1:10)[rep(NA, 20)]
[1] NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA
> (1:20)[rep(NA, 10)]
[1] NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA
> (1:20)[rep(NA_integer_, 10)]
[1] NA NA NA NA NA NA NA NA NA NA
> (1:10)[rep(NA_integer_, 20)]
[1] NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA
-pd
> On 21 Nov 2020, at 16:55 , Mario Annau wrote:
>
> Hello,
>
> using the `unsplit()` function with tibbles currently leads to the
> following error:
>
>> mtcars_tb <- as_tibble(mtcars, rownames = NULL)
>> s <- split(mtcars_tb, mtcars_tb$gear)
>> unsplit(s, mtcars_tb$gear)
> Error: Must subset rows with a valid subscript vector.
> ℹ Logical subscripts must match the size of the indexed input.
> x Input has size 15 but subscript `rep(NA, len)` has size 32.
> Run `rlang::last_error()` to see where the error occurred.
>
> Tibble seems to (rightly) complain, that a logical vector has been used for
> subsetting which does not have the same length as the data.frame (rows).
> Since `NA` is a logical value, the subset should be changed to
> `NA_integer_` in `unsplit()`:
>
>> unsplit
> function (value, f, drop = FALSE)
> {
>len <- length(if (is.list(f)) f[[1L]] else f)
>if (is.data.frame(value[[1L]])) {
>x <- value[[1L]][rep(*NA_integer_*, len), , drop = FALSE]
>rownames(x) <- unsplit(lapply(value, rownames), f, drop = drop)
>}
>else x <- value[[1L]][rep(NA, len)]
>split(x, f, drop = drop) <- value
>x
> }
>
> Cheers,
> Mario
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sum() (and similar methods) should work for zero row data.frames
Hmm, yes, this is probably wrong. E.g., we are likely to get inconsistencies out of boundary cases like this > a <- na.omit(airquality) > sum(a) [1] 37495.3 > sum(a[FALSE,]) Error in FUN(X[[i]], ...) : only defined on a data frame with all numeric variables Or, closer to an actual use case: > sum(subset(a, Ozone>100)) [1] 3330.5 > sum(subset(a, Ozone>200)) Error in FUN(X[[i]], ...) : only defined on a data frame with all numeric variables However, given that numeric summaries generally treat logicals as 0/1, wouldn't it be easiest just to extend the check inside Summary.data.frame with "&& !is.logical(x)"? > sum(as.matrix(a[FALSE,])) [1] 0 -pd > On 17 Oct 2020, at 21:18 , Martin wrote: > > The "Summary" group generics always throw errors for a data.frame with zero > rows, for example: >> sum(data.frame(x = numeric(0))) > #> Error in FUN(X[[i]], ...) : > #> only defined on a data frame with all numeric variables > Same behaviour for min, max, any, all, ... . I believe this is inconsistent > with what these methods do for other empty objects (vectors, matrices), where > the return value is chosen to ensure transitivity: sum(numeric(0)) == 0. > > The reason for this is that the return type of as.matrix() for empty (no rows > or no columns) data.frame objects is always a matrix of type "logical". The > Summary method for data.frame, in turn, throws an error when the data.frame, > converted to a matrix, is not of numeric type. > > I suggest two ways that make sum, min, max, ... more consistent. IMHO it > would be fitting to implement both of these fixes, because they also make > other things more consistent. > > 1. Make the return type of as.matrix() for zero-row data.frames consistent > with the type that would have been returned, had the data.frame had more than > zero rows. "as.matrix(data.frame(x = numeric(0)))" should then be numeric, if > there is an empty "character" column the return matrix should be a character > etc. This would make subsetting by row and conversion to matrix commute > (except for row names sometimes): >> all.equal(as.matrix(df[rows, , drop = FALSE]), as.matrix(df)[rows, , drop = >> FALSE]) > Furthermore, this change would make as.matrix.data.frame obey the > documentation, which indicates that the coercion hierarchy is used for the > return type. > > 2. Make the Summary.data.frame method accept data.frames that produce > non-numeric matrices. Next to the main focus of this message, I believe it > would e.g. be fitting to have any() and all() work on logical data.frame > objects. The current behaviour is such that >> any(data.frame(x = 1)) > #> [1] TRUE > #> Warning message: > #> In any(1, na.rm = FALSE) : coercing argument of type 'double' to logical > and >> any(data.frame(x = TRUE)) > #> Error in FUN(X[[i]], ...) : > #> only defined on a data frame with all numeric variables > So a numeric data.frame warns about implicit coercion, while a logical > data.frame (which would not need coercion) does not work at all. > > (I feel more strongly about fixing 1. than 2., because I don't know the > discussion that lead to the behaviour described in 2.) > > Best, > Martin > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.0.3 is released
The build system rolled up R-4.0.3.tar.gz (codename "Bunny-Wunnies Freak Out")
this morning.
The list below details the changes in this release.
You can get the source code from
https://cran.r-project.org/src/base/R-4/R-4.0.3.tar.gz
or wait for it to be mirrored at a CRAN site nearer to you.
Binaries for various platforms will appear in due course.
For the R Core Team,
Peter Dalgaard
These are the checksums (md5 and SHA-256) for the freshly created files, in
case you wish
to check that they are uncorrupted:
MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4
MD5 (COPYING) = eb723b61539feef013de476e68b5c50a
MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343
MD5 (FAQ) = 5be656453b81e9393e2a0c42688b04b8
MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b
MD5 (NEWS) = 71728ef32a09c5b9df36b496b52d5c8e
MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8
MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801
MD5 (NEWS.2) = 496062c138e2def06cebccddfb814ac6
MD5 (NEWS.3) = 012e7f4a80cc8ec947bf3f0ff6117ec8
MD5 (R-latest.tar.gz) = 8ecf46afa36c9aff9904aad5ca422c6d
MD5 (README) = f468f281c919665e276a1b691decbbe6
MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435
MD5 (THANKS) = 251d20510bfc3cc93b82c5a99f7efcc6
MD5 (VERSION-INFO.dcf) = bfbcfb2f4ef4416b635087160f965904
MD5 (R-4/R-4.0.3.tar.gz) = 8ecf46afa36c9aff9904aad5ca422c6d
2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09 AUTHORS
e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING
6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB
4390543804392e072378b2d75cd3fb0d57e9885f9dc38ddd5a2ff780487b9d97 FAQ
f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL
895ba3f810fd33d3be63deb6c4588be1f7ba3f5bf80e10ffeafc194221dd5ba9 NEWS
4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0
12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1
e80de410c77f05ff2012fa70051b89119845f734a7fa5c55857e61e4ed7d5f6e NEWS.2
7201d139947afa52b5e09d26dc01445edf444506264355b2185122bc1ed3dce0 NEWS.3
09983a8a78d5fb6bc45d27b1c55f9ba5265f78fa54a55c13ae691f87c5bb9e0d
R-latest.tar.gz
2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README
408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9 RESOURCES
c9c7cb32308b4e560a22c858819ade9de524a602abd4e92d1c328c89f8037d73 THANKS
cd9666c09064b120655598c1ac792266ad20adb57c36aab4d094dedc7e480fa6
VERSION-INFO.dcf
09983a8a78d5fb6bc45d27b1c55f9ba5265f78fa54a55c13ae691f87c5bb9e0d
R-4/R-4.0.3.tar.gz
This is the relevant part of the NEWS file
CHANGES IN R 4.0.3:
NEW FEATURES:
* On platforms using configure option --with-internal-tzcode,
additional values "internal" and (on macOS only) "macOS" are
accepted for the environment variable TZDIR. (See ?TZDIR.)
On macOS, "macOS" is used by default if the system timezone
database is a newer version than that in the R installation.
* When install.packages(type = "source") fails to find a package in
a repository it mentions package versions which are excluded by
their R version requirement and links to hints on why a package
might not be found.
* The default value for options("timeout") can be set from
enviromnent variable R_DEFAULT_INTERNET_TIMEOUT, still defaulting
to 60 (seconds) if that is not set or invalid.
This may be needed when child R processes are doing downloads,
for example during the installation of source packages which
download jars or other forms of data.
LINK-TIME OPTIMIZATION on a UNIX-ALIKE:
* There is now support for parallelized Link-Time Optimization
(LTO) with GCC and for 'thin' LTO with clang _via_ setting the
LTO macro.
* There is support for setting a different LTO flag for the Fortran
compiler, including to empty when mixing clang and gfortran (as
on macOS). See file config.site.
* There is a new LTO_LD macro to set linker options for LTO
compilation, for example to select an alternative linker or to
parallelize thin LTO.
DEPRECATED AND DEFUNCT:
* The LINPACK argument to chol.default(), chol2inv(),
solve.default() and svd() has been defunct since R 3.1.0. Using
it now gives a warning which will become an error in R 4.1.0.
BUG FIXES:
* The code mitigating stack overflow with PCRE regexps on very long
strings is enabled for PCRE2 < 10.30 also when JIT is enabled,
since stack overflows have been seen in that case.
* Fix to correctly show the group labels in dotchart() (which where
lost in the ylab improvement for R 4.0.0).
* addmargins(*, ..) now also works when fn() is a local function,
thanks to bug report and patch PR#17124 from Alex Bertram.
* rank(x) and hence sort(x) now work when x is an object (as per
is.object(x)) of type "raw" _
[Rd] R 4.0.3 scheduled for October 10
[Oops, this apparently got omitted during release scheduling] Full schedule is available on developer.r-project.org. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ 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] Garbage collection of seemingly PROTECTed pairlist
Hm, I'm getting rusty on my C skills, but you repeatedly use a pattern like
> while (row_num <= nr) {
>Rprintf("row_num: %i\n", row_num);
>SEXP row = PROTECT(C_int_mat_nth_row_nrnc(int_mat_int, nr, 2, row_num));
I wonder if there is a subtle difference between assignments and initialized
declarations.
I.e. would it help to write it as
> while (row_num <= nr) {
SEXP row;
Rprintf("row_num: %i\n", row_num);
row = PROTECT(C_int_mat_nth_row_nrnc(int_mat_int, nr, 2, row_num));
?
-pd
> On 12 Sep 2020, at 00:35 , Rory Nolan wrote:
>
> I want to write an R function using R's C interface that takes a 2-column
> matrix of increasing, non-overlapping integer intervals and returns a list
> with those intervals plus some added intervals, such that there are no
> gaps. For example, it should take the matrix rbind(c(5L, 6L), c(7L, 10L),
> c(20L, 30L)) and return list(c(5L, 6L), c(7L, 10L), c(11L, 19L), c(20L,
> 30L)). Because the output is of variable length, I use a pairlist (because
> it is growable) and then I call Rf_PairToVectorList() at the end to make it
> into a regular list.
>
> I'm getting a strange garbage collection error. My PROTECTed pairlist prlst
> gets garbage collected away and causes a memory leak error when I try to
> access it.
>
> Here's my code.
>
> #include
>
>
> SEXP C_int_mat_nth_row_nrnc(int *int_mat_int, int nr, int nc, int n) {
> SEXP out = PROTECT(Rf_allocVector(INTSXP, nc));
> int *out_int = INTEGER(out);
> if (n <= 0 | n > nr) {
>for (int i = 0; i != nc; ++i) {
> out_int[i] = NA_INTEGER;
>}
> } else {
>for (int i = 0; i != nr; ++i) {
> out_int[i] = int_mat_int[n - 1 + i * nr];
>}
> }
> UNPROTECT(1);
> return out;}
>
> SEXP C_make_len2_int_vec(int first, int second) {
> SEXP out = PROTECT(Rf_allocVector(INTSXP, 2));
> int *out_int = INTEGER(out);
> out_int[0] = first;
> out_int[1] = second;
> UNPROTECT(1);
> return out;}
>
> SEXP C_fullocate(SEXP int_mat) {
> int nr = Rf_nrows(int_mat), *int_mat_int = INTEGER(int_mat);
> int last, row_num; // row_num will be 1-indexed
> SEXP prlst0cdr = PROTECT(C_int_mat_nth_row_nrnc(int_mat_int, nr, 2, 1));
> SEXP prlst = PROTECT(Rf_list1(prlst0cdr));
> SEXP prlst_tail = prlst;
> last = INTEGER(prlst0cdr)[1];
> row_num = 2;
> while (row_num <= nr) {
>Rprintf("row_num: %i\n", row_num);
>SEXP row = PROTECT(C_int_mat_nth_row_nrnc(int_mat_int, nr, 2, row_num));
>Rf_PrintValue(prlst); // This is where the error occurs
>int *row_int = INTEGER(row);
>if (row_int[0] == last + 1) {
> Rprintf("here1");
> SEXP next = PROTECT(Rf_list1(row));
> prlst_tail = SETCDR(prlst_tail, next);
> last = row_int[1];
> UNPROTECT(1);
> ++row_num;
>} else {
> Rprintf("here2");
> SEXP next_car = PROTECT(C_make_len2_int_vec(last + 1, row_int[0] - 1));
> SEXP next = PROTECT(Rf_list1(next_car));
> prlst_tail = SETCDR(prlst_tail, next);
> last = row_int[0] - 1;
> UNPROTECT(2);
>}
>UNPROTECT(1);
> }
> SEXP out = PROTECT(Rf_PairToVectorList(prlst));
> UNPROTECT(3);
> return out;}
>
> As you can see, I have some diagnostic print statements in there. The
> offending line is line 40, which I have marked with a comment of // This is
> where the error occurs. I have a minimal reproducible package at
> https://github.com/rorynolan/testpkg and I have run R CMD CHECK with
> valgrind using GitHub actions, the results of which are at
> https://github.com/rorynolan/testpkg/runs/1076595757?check_suite_focus=true.
> That's where I found out which line is causing the error. This function
> works as expected sometimes, and then sometimes this issue appears. This
> lends weight to the suspicion that it's a garbage collection issue.
>
> I really want to know what my mistake is. I'm not that interested in
> alternative implementations; I want to understand the mistake that I'm
> making so that I can avoid making it in future.
>
> I have asked the question on stackoverflow to little avail, but the
> discussion there may prove helpful.
> https://stackoverflow.com/questions/63759604/garbage-collection-of-seemingly-protected-pairlist.
>
>
>
> Thanks,
>
> Rory
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Evaluate values in `Sys.setenv`
It is the shell that does the ~ and $ expansions, and Sys.setenv() doesn't go
via the shell, so you cannot expect it to understand the shell metacharacters.
Instead, you need to do the corresponding computations in R, e.g.
> paste(path.expand("~/mypath"), Sys.getenv("PATH"), sep=":")
[1]
"/Users/pd/mypath:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/gfortran/bin:/usr/local/clang8/bin:/Library/TeX/texbin:/opt/X11/bin"
which you can then pass to Sys.setenv().
-pd
> On 28 Aug 2020, at 11:00 , Jeff King wrote:
>
> Hi all,
>
> I would like to know if there is any way to evaluate the values in
> `Sys.setenv` before setting the environment variables. For example, if we
> want to add a path to the environment variable `PATH`, we can do this in a
> terminal
>
> ```
>> export PATH=~/mypath:$PATH
>> echo $PATH
> /Users/jeff/mypath:...
> ```
>
> However, this style of assignment is not allowed in `Sys.setenv`, it
> treats its argument as a literal string, so
>
> ```
>> Sys.setenv(PATH= " ~/mypath:$PATH")
>> Sys.getenv("PATH")
> [1] " ~/mypath:$PATH "
> ```
> Note that both the symbol `~` and the variable `$PATH` are not expanded.
> While we can manually evaluate the home symbol `~` and PATH using
> `Sys.getenv`, the code seems not quite neat. I would like to suggest adding
> a parameter in ` Sys.setenv` to make the function more convenient(e.g.
> Sys.setenv(..., fixed = TRUE)) if no existing function in base R can do
> them in one line.
>
> Best,
> Jiefei
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.0.2 is released
The build system rolled up R-4.0.2.tar.gz (codename "Taking Off Again") this morning. The list below details the changes in this release. You can get the source code from http://cran.r-project.org/src/base/R-4/R-4.0.2.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard These are the checksums (md5 and SHA-256) for the freshly created files, in case you wish to check that they are uncorrupted: MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4 MD5 (COPYING) = eb723b61539feef013de476e68b5c50a MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343 MD5 (FAQ) = 4afa171cd982aaa60f0ba92e2e7bc5d6 MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b MD5 (NEWS) = 566a6bb3642e28e6bf01cf98db31137c MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8 MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801 MD5 (NEWS.2) = 496062c138e2def06cebccddfb814ac6 MD5 (NEWS.3) = 012e7f4a80cc8ec947bf3f0ff6117ec8 MD5 (R-latest.tar.gz) = 1eac7293d5fe313a56ddabfda02b437e MD5 (README) = f468f281c919665e276a1b691decbbe6 MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435 MD5 (THANKS) = 251d20510bfc3cc93b82c5a99f7efcc6 MD5 (VERSION-INFO.dcf) = 62496d3a0fd8cc2ed644ea518c052371 MD5 (R-4/R-4.0.2.tar.gz) = 1eac7293d5fe313a56ddabfda02b437e 2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09 AUTHORS e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB eddf87b12197c7b3b19cbc9b11c1beab95b14e3dcd715bf37d2f6a8b2a72c2a1 FAQ f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL ec05bba338358410fae6b34fed061605989ab3601aba1b3fcb45a610d5dd2eb9 NEWS 4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0 12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1 e80de410c77f05ff2012fa70051b89119845f734a7fa5c55857e61e4ed7d5f6e NEWS.2 7201d139947afa52b5e09d26dc01445edf444506264355b2185122bc1ed3dce0 NEWS.3 d3bceab364da0876625e4097808b42512395fdf41292f4915ab1fd257c1bbe75 R-latest.tar.gz 2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README 408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9 RESOURCES c9c7cb32308b4e560a22c858819ade9de524a602abd4e92d1c328c89f8037d73 THANKS 10cc5f566a4a5ce49147e7dcfbe9180dba09ccb9efb17298b067309eb799e92e VERSION-INFO.dcf d3bceab364da0876625e4097808b42512395fdf41292f4915ab1fd257c1bbe75 R-4/R-4.0.2.tar.gz This is the relevant part of the NEWS file CHANGES IN R 4.0.2: UTILITIES: * R CMD check skips vignette re-building (with a warning) if the VignetteBuilder package(s) are not available. BUG FIXES: * Paths with non-ASCII characters caused problems for package loading on Windows PR#17833. * Using tcltk widgets no longer crashes R on Windows. * source(*, echo=TRUE) no longer fails in some cases with empty lines; reported by Bill Dunlap in PR#17769. * on.exit() now correctly matches named arguments, thanks to PR#17815 (including patch) by Brodie Gaslam. * regexpr(*, perl=TRUE) no longer returns incorrect positions into text containing characters outside of the Unicode Basic Multilingual Plane on Windows. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tcltk image reading problem (on a mac?): [tcl] encountered an unsupported criticial chunk type "eXIf"
Happy enough for me on Mojave.
On the off chance that you are picking up an old Tcl, do you see this?
> tcl("info","tclversion")
8.6
-pd
> On 11 Jun 2020, at 23:04 , Wayne Oldford wrote:
>
> Hello everyone
>
> I am not sure when this appeared
> (sometime post R 3.5.0 and after I switched to Mac OS Catalina).
>
> I do not think it happens on all platforms (e.g. seems to work on windows).
>
> But it seems that
>
> tkimage.create()
>
> no longer works on a Mac for all png files.
>
>
> (It does work for *some* old png files I have on disk but I have not been
> able to determine what is different about the ones that work)
>
> Any help would be appreciated.
>
> - Wayne
>
>
> R.W. Oldford
> math.uwaterloo.ca/~rwoldfor
>
>
>
>
>> library(tcltk)
>
>> fname <- "Rplot.png"
>> png(filename = fname, width = 500, height = 500)
>> hist(rnorm(20))
>> dev.off()
>
>> tkimage.create("photo", file = fname)
>
> Error in structure(.External(.C_dotTclObjv, objv), class = "tclObj") :
> [tcl] encountered an unsupported criticial chunk type "eXIf".
>
>
> __
>
>> R.version
> _
> platform x86_64-apple-darwin17.0
> arch x86_64
> os darwin17.0
> system x86_64, darwin17.0
> status
> major 4
> minor 0.0
> year 2020
> month 04
> day24
> svn rev78286
> language R
> version.string R version 4.0.0 (2020-04-24)
> nickname Arbor Day
>
> ___
>
> macOS Catalina V 10.15.5
>
> ___
>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-project.org SSL certificate issues
As I said, there is stuff that I don't understand in here (including why browsers apparently do trust alternative chains) -pd > On 10 Jun 2020, at 01:53 , Simon Urbanek wrote: > > You are making a very strong assumption that finding an alternative chain of > trust is safe. I'd argue it's not - it means that an adversary could > manipulate the chain in a way to trust it instead of the declared chain and > thus subverting it. In fact switching to OpenSSL would create a serious > security hole here - in particular since it installs a separate trust store > which it is far more easily attacked and subverted. By your argument we > should disable all SSL checks as that produces error with incorrectly > configured servers so not performing checks is better. It is true that R is > likely not used for sensitive transactions, but I would rather it warned me > about situations where the communication may be compromised instead of just > silently going along. > > Cheers, > Simon > > > >> On Jun 10, 2020, at 11:39 AM, peter dalgaard wrote: >> >> Yes and no... At least as I understand it (Disclaimer: There are things I am >> pretty sure that I don't understand properly, somewhere in the Bermuda >> triangle beween CA bundles, TLS protocols, and Server-side settings), there >> are two sided to this: >> >> One is that various *.r-project.org servers got hit by a fumble where a >> higher-up certificate in the chain of trust expired before the >> *.r-project.org one. This was fixed by changing the certificate chain on >> each server. >> >> The other side is that this situation hit Mac users harder than others, >> because Apple's LibreSSL doesn't have the same feature that openSSL has to >> detect a secondary chain of trust when the primary one expired. This was not >> unique to R - svn also failed from the command line - but it did affect >> download.file() inside R. >> >> The upshot is that there might be 3rd party servers with a similar >> certificate setup which have not been updated like *.r-project.org. This is >> not too unlikely since web browsers do not have trouble accessing them, and >> the whole matter may go undetected. For such servers, download.file() would >> still fail. >> >> I.e., there is a case to be made that we might want to link openSSL rather >> than LibreSSL. On the other hand, I gather that newer versions of LibreSSL >> contain the relevant protocol upgrade, so maybe one can just wait for Apple >> to update it. Or maybe we do want to link R against openSSL, but almost >> certainly not for a hotfix release. >> >> Best >> -pd >> >>> On 10 Jun 2020, at 00:50 , Simon Urbanek >>> wrote: >>> >>> To be clear, this not an issue in the libraries nor R, the certificates on >>> the server were simply wrong. So, no, this has nothing to do with R. >>> >>> Cheers, >>> Simon >>> >>> >>>> On Jun 10, 2020, at 10:45 AM, Henrik Bengtsson >>>> wrote: >>>> >>>> Was this resolved upstream or is this something that R should/could >>>> fix? If the latter, could this also go into the "emergency release" R >>>> 4.0.2 that is scheduled for 2020-06-22? >>>> >>>> My $.02 >>>> >>>> /Henrik >>>> >>>> >>>> On Sun, May 31, 2020 at 8:13 AM Gábor Csárdi >>>> wrote: >>>>> >>>>> Btw. it would be also possible to create a macOS R installer that >>>>> embeds a static or dynamic libcurl with Secure Transport, instead of >>>>> the Apple default LibreSSL. >>>>> >>>>> This might be too late for R 4.0.1, I don't know. >>>>> >>>>> Gabor >>>>> >>>>> On Sun, May 31, 2020 at 4:09 PM Gábor Csárdi >>>>> wrote: >>>>>> >>>>>> On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi >>>>>> wrote: >>>>>> [...] >>>>>>> Btw. why does this affect openssl? That root cert was published in >>>>>>> 2010, surely openssl should know about it? Maybe libcurl / openssl >>>>>>> only uses the chain provided by the server? Without trying to use an >>>>>>> alternate chain? >>>>>> >>>>>> Yes, indeed it seems that old OpenSSL versions cannot handle >>>>>> alternative certificate chains. This has been fixed in OpenSS
Re: [Rd] r-project.org SSL certificate issues
Yes and no... At least as I understand it (Disclaimer: There are things I am
pretty sure that I don't understand properly, somewhere in the Bermuda triangle
beween CA bundles, TLS protocols, and Server-side settings), there are two
sided to this:
One is that various *.r-project.org servers got hit by a fumble where a
higher-up certificate in the chain of trust expired before the *.r-project.org
one. This was fixed by changing the certificate chain on each server.
The other side is that this situation hit Mac users harder than others, because
Apple's LibreSSL doesn't have the same feature that openSSL has to detect a
secondary chain of trust when the primary one expired. This was not unique to R
- svn also failed from the command line - but it did affect download.file()
inside R.
The upshot is that there might be 3rd party servers with a similar certificate
setup which have not been updated like *.r-project.org. This is not too
unlikely since web browsers do not have trouble accessing them, and the whole
matter may go undetected. For such servers, download.file() would still fail.
I.e., there is a case to be made that we might want to link openSSL rather than
LibreSSL. On the other hand, I gather that newer versions of LibreSSL contain
the relevant protocol upgrade, so maybe one can just wait for Apple to update
it. Or maybe we do want to link R against openSSL, but almost certainly not for
a hotfix release.
Best
-pd
> On 10 Jun 2020, at 00:50 , Simon Urbanek wrote:
>
> To be clear, this not an issue in the libraries nor R, the certificates on
> the server were simply wrong. So, no, this has nothing to do with R.
>
> Cheers,
> Simon
>
>
>> On Jun 10, 2020, at 10:45 AM, Henrik Bengtsson
>> wrote:
>>
>> Was this resolved upstream or is this something that R should/could
>> fix? If the latter, could this also go into the "emergency release" R
>> 4.0.2 that is scheduled for 2020-06-22?
>>
>> My $.02
>>
>> /Henrik
>>
>>
>> On Sun, May 31, 2020 at 8:13 AM Gábor Csárdi wrote:
>>>
>>> Btw. it would be also possible to create a macOS R installer that
>>> embeds a static or dynamic libcurl with Secure Transport, instead of
>>> the Apple default LibreSSL.
>>>
>>> This might be too late for R 4.0.1, I don't know.
>>>
>>> Gabor
>>>
>>> On Sun, May 31, 2020 at 4:09 PM Gábor Csárdi wrote:
>>>>
>>>> On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi
>>>> wrote:
>>>> [...]
>>>>> Btw. why does this affect openssl? That root cert was published in
>>>>> 2010, surely openssl should know about it? Maybe libcurl / openssl
>>>>> only uses the chain provided by the server? Without trying to use an
>>>>> alternate chain?
>>>>
>>>> Yes, indeed it seems that old OpenSSL versions cannot handle
>>>> alternative certificate chains. This has been fixed in OpenSSL in
>>>> 2015, so modern Linux systems should be fine. However, macOS uses
>>>> LibreSSL, and LibreSSL never fixed this issue. E.g.
>>>> https://github.com/libressl-portable/portable/issues/595
>>>>
>>>> r-project.org can be updated to send the new root certificate, which
>>>> will solve most of our problems, but we'll probably have issues with
>>>> other web sites that'll update slower or never.
>>>>
>>>> FWIW I built macOS binaries for the curl package, using a static
>>>> libcurl and macOS Secure Transport, so these binaries does not have
>>>> this issue.
>>>>
>>>> They are at https://files.r-hub.io/curl-macos-static and they can be
>>>> installed with
>>>> install.packages("curl", repos =
>>>> "https://files.r-hub.io/curl-macos-static;, type = "binary")
>>>>
>>>> They support R 3.2 and up, including R 4.1, and should work on all
>>>> macOS versions that the given R release supports.
>>>>
>>>> Gabor
>>>
>>> __
>>> 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
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.0.2 scheduled for June 22
Unfortunatly, a memory allocation bug prevented the R Commander package from working on Windows. This is fixed in R-patched, but we cannot have this not working in the official release when IT departments start installing for the Fall semester, so we need to issue a new release. Full schedule is available on developer.r-project.org. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ 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] [External] Re: use of the tcltk package crashes R 4.0.1 for Windows
Well... The first rule of release management is not to have the same version number on different releases. I see three possibilities (1) Tell users to use 4.0.1-patched if they need tcltk on Windows (2) A "vendor patch release": Windows maintainer reissues the binary after applying the critical patch. (3) 4.0.2 As soon as possible (realistically June 22nd-ish) Now, (1) requires no intervention, but it has the problem that we are approaching the time for campus-wide installations (insofar as campuses will actually reopen in Fall). It will be messy to have to tell IT not to use the officially released binary, and most likely they just won't. (2) is possible if we act quickly, although it leaves a "ghost version" of 4.0.1 around (and don't try renaming tricks, it can mess up CRAN scripts - some of us have the scars...). It should work but it is a bit iffy because the actual problem is in fact in the sources and it creates a situation where the binary and the sources are out of sync. (3) is clean, but it takes a while (minimum 12 days) to go through the release run-in. Also, for a new release, I suspect we want to have a closer look at the issue as we seem to be using multiple allocators on Windows in a, hmmm, "eclectic mix". (E.g. connections.c has both Calloc/Free and malloc/free combinations and AFAICT, the latter uses a different allocator.) -pd > On 8 Jun 2020, at 01:20 , Abby Spurdle wrote: > > sorry, release "versions" > > > On Mon, Jun 8, 2020 at 11:17 AM Abby Spurdle wrote: >> >> On Mon, Jun 8, 2020 at 4:09 AM Fox, John wrote: >>> Does it make sense to withdraw the Windows R 4.0.1 binary until the issue >>> is resolved? >> >> Yes, it does. >> All the release reversions should be removed. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] use of the tcltk package crashes R 4.0.1 for Windows
Ah, I see it now:
The remapping of free() to Rm_free() and calloc() to Rm_calloc() happens in
memory.c, but not in tcltk.c; the macro Calloc in R_ext/RS.h maps to a call to
R_chk_alloc which is defined in memory.h; RS.h is included in tcltk.c, so
tcltk.c winds up calling Rm_calloc() via Calloc(), but then the NON-remapped
free(), and the walls come tumbling down.
If the "#if defined(Win32)" block had been inside RS.h, the problem wouldn't
arise.
-pd
> On 8 Jun 2020, at 00:03 , luke-tier...@uiowa.edu wrote:
>
> I've committed the change to use Free instead of free in tcltk.c and
> sys-std.c (r78652 for R-devel, r78653 for R-patched).
>
> We might consider either moving Calloc/Free out of the Windows
> remapping or moving the remapping into header files so everything
> seeing our header files uses our calloc/free. Either would be less
> brittle that the current status.
>
> Best,
>
> luke
>
> On Sun, 7 Jun 2020, peter dalgaard wrote:
>
>>
>>
>>> On 7 Jun 2020, at 18:59 , Jeroen Ooms wrote:
>>>
>>> On Sun, Jun 7, 2020 at 5:53 PM wrote:
>>>>
>>>> On Sun, 7 Jun 2020, peter dalgaard wrote:
>>>>
>>>>> So this wasn't tested for a month?
>>>>>
>>>>> Anyways, Free() is just free() with a check that we're not freeing a null
>>>>> pointer, followed by setting the pointer to NULL. At that point of
>>>>> tcltk.c, we have
>>>>>
>>>>> for (objc = i = 0; i < length(avec); i++){
>>>>> const char *s;
>>>>> char *tmp;
>>>>> if (!isNull(nm) && strlen(s = translateChar(STRING_ELT(nm, i{
>>>>> // tmp = calloc(strlen(s)+2, sizeof(char));
>>>>> tmp = Calloc(strlen(s)+2, char);
>>>>> *tmp = '-';
>>>>> strcpy(tmp+1, s);
>>>>> objv[objc++] = Tcl_NewStringObj(tmp, -1);
>>>>> free(tmp);
>>>>> }
>>>>> if (!isNull(t = VECTOR_ELT(avec, i)))
>>>>> objv[objc++] = (Tcl_Obj *) R_ExternalPtrAddr(t);
>>>>> }
>>>>>
>>>>> and I can't see how tmp can be NULL at the free(), nor can I see it
>>>>> mattering if it is not set to NULL (notice that it goes out of scope with
>>>>> the for loop).
>>>>
>>>> Right. And the calloc->Calloc change doesn't look like an issue either
>>>> -- just checking for a NULL.
>>>>
>>>> If the crash is happening in free() then that most likely means
>>>> corrupted malloc data structures. Unfortunately that could be
>>>> happening anywhere.
>>>
>>> Writing R extensions, section 6.1.2 says: "Do not assume that memory
>>> allocated by Calloc/Realloc comes from the same pool as used by
>>> malloc: in particular do not use free or strdup with it."
>>>
>>> I think the reason is that R uses dlmalloc for Calloc on Windows:
>>> https://github.com/wch/r-source/blob/c634fec5214e73747b44d7c0e6f047fefe44667d/src/main/memory.c#L94-L103
>>
>> But that section #defines calloc and free to Rm_... counterparts in
>> lockstep? (I assume that is where dlmalloc comes in?)
>>
>> Anyways, does it actually work to change free() to Free()? If so, then all
>> this post mortem analysis is rather a moot point.
>>
>> -pd
>>
>>
>
> --
> 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
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Re: use of the tcltk package crashes R 4.0.1 for Windows
> On 7 Jun 2020, at 18:59 , Jeroen Ooms wrote:
>
> On Sun, Jun 7, 2020 at 5:53 PM wrote:
>>
>> On Sun, 7 Jun 2020, peter dalgaard wrote:
>>
>>> So this wasn't tested for a month?
>>>
>>> Anyways, Free() is just free() with a check that we're not freeing a null
>>> pointer, followed by setting the pointer to NULL. At that point of tcltk.c,
>>> we have
>>>
>>> for (objc = i = 0; i < length(avec); i++){
>>> const char *s;
>>> char *tmp;
>>> if (!isNull(nm) && strlen(s = translateChar(STRING_ELT(nm, i{
>>> // tmp = calloc(strlen(s)+2, sizeof(char));
>>> tmp = Calloc(strlen(s)+2, char);
>>> *tmp = '-';
>>> strcpy(tmp+1, s);
>>> objv[objc++] = Tcl_NewStringObj(tmp, -1);
>>> free(tmp);
>>> }
>>> if (!isNull(t = VECTOR_ELT(avec, i)))
>>> objv[objc++] = (Tcl_Obj *) R_ExternalPtrAddr(t);
>>> }
>>>
>>> and I can't see how tmp can be NULL at the free(), nor can I see it
>>> mattering if it is not set to NULL (notice that it goes out of scope with
>>> the for loop).
>>
>> Right. And the calloc->Calloc change doesn't look like an issue either
>> -- just checking for a NULL.
>>
>> If the crash is happening in free() then that most likely means
>> corrupted malloc data structures. Unfortunately that could be
>> happening anywhere.
>
> Writing R extensions, section 6.1.2 says: "Do not assume that memory
> allocated by Calloc/Realloc comes from the same pool as used by
> malloc: in particular do not use free or strdup with it."
>
> I think the reason is that R uses dlmalloc for Calloc on Windows:
> https://github.com/wch/r-source/blob/c634fec5214e73747b44d7c0e6f047fefe44667d/src/main/memory.c#L94-L103
But that section #defines calloc and free to Rm_... counterparts in lockstep?
(I assume that is where dlmalloc comes in?)
Anyways, does it actually work to change free() to Free()? If so, then all this
post mortem analysis is rather a moot point.
-pd
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] use of the tcltk package crashes R 4.0.1 for Windows
> On 7 Jun 2020, at 17:53 , luke-tier...@uiowa.edu wrote:
>
> On Sun, 7 Jun 2020, peter dalgaard wrote:
>
>> So this wasn't tested for a month?
>>
>> Anyways, Free() is just free() with a check that we're not freeing a null
>> pointer, followed by setting the pointer to NULL. At that point of tcltk.c,
>> we have
>>
>> for (objc = i = 0; i < length(avec); i++){
>> const char *s;
>> char *tmp;
>> if (!isNull(nm) && strlen(s = translateChar(STRING_ELT(nm, i{
>> // tmp = calloc(strlen(s)+2, sizeof(char));
>> tmp = Calloc(strlen(s)+2, char);
>> *tmp = '-';
>> strcpy(tmp+1, s);
>> objv[objc++] = Tcl_NewStringObj(tmp, -1);
>> free(tmp);
>> }
>> if (!isNull(t = VECTOR_ELT(avec, i)))
>> objv[objc++] = (Tcl_Obj *) R_ExternalPtrAddr(t);
>> }
>>
>> and I can't see how tmp can be NULL at the free(), nor can I see it
>> mattering if it is not set to NULL (notice that it goes out of scope with
>> the for loop).
>
> Right. And the calloc->Calloc change doesn't look like an issue either
> -- just checking for a NULL.
>
> If the crash is happening in free() then that most likely means
> corrupted malloc data structures. Unfortunately that could be
> happening anywhere.
>
> Best bet to narrow this down is for someone with a good Windows setup
> who can reproduce this to bisect the svn commits and see at what
> commit this started happening. Unfortunately my office Windows machine
> isn't responding and it will probably take some time to get that
> fixed.
Also, it is possible that the issue is really a line or two earlier, so it
would be good to get in with a debugger and see what is actually in *tmp and
objv[objc++] at the point of the crash.
Also, Tcl_NewStringObj(tmp, -1) obviously must allocate, but it would be rather
odd if it didn't use the system allocator (Tcl is designed to be embeddable,
the only strange thing R does in that respect is the marriage of the two event
loops).
-pd
>
> Best,
>
> luke
>
>>
>> -pd
>>
>>
>>> On 7 Jun 2020, at 16:00 , Jeroen Ooms wrote:
>>>
>>> On Sun, Jun 7, 2020 at 3:13 AM Fox, John wrote:
>>>>
>>>> Hi,
>>>>
>>>> The following code, from the examples in ?TkWidgets , immediately crashes
>>>> R 4.0.1 for Windows:
>>>>
>>>> - snip
>>>> library("tcltk")
>>>> tt <- tktoplevel()
>>>> label.widget <- tklabel(tt, text = "Hello, World!")
>>>> button.widget <- tkbutton(tt, text = "Push",
>>>>command = function()cat("OW!\n"))
>>>> tkpack(label.widget, button.widget) # geometry manager
>>>> - snip
>>>
>>>
>>> I can reproduce this. The backtrace shows the crash happens in
>>> dotTclObjv [/src/library/tcltk/src/tcltk.c@243 ]. This looks like a
>>> bug that was introduced by commit 78408/78409 about a month ago. I
>>> think the problem is that this commit changes 'calloc' to 'Calloc'
>>> without changing the corresponding 'free' to 'Free'.
>>>
>>> This has nothing to do with the Windows build or installation. Nothing
>>> has changed in the windows build procedure between 4.0.0 and 4.0.1.
>>>
>>> __
>>> 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
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] use of the tcltk package crashes R 4.0.1 for Windows
So this wasn't tested for a month?
Anyways, Free() is just free() with a check that we're not freeing a null
pointer, followed by setting the pointer to NULL. At that point of tcltk.c, we
have
for (objc = i = 0; i < length(avec); i++){
const char *s;
char *tmp;
if (!isNull(nm) && strlen(s = translateChar(STRING_ELT(nm, i{
// tmp = calloc(strlen(s)+2, sizeof(char));
tmp = Calloc(strlen(s)+2, char);
*tmp = '-';
strcpy(tmp+1, s);
objv[objc++] = Tcl_NewStringObj(tmp, -1);
free(tmp);
}
if (!isNull(t = VECTOR_ELT(avec, i)))
objv[objc++] = (Tcl_Obj *) R_ExternalPtrAddr(t);
}
and I can't see how tmp can be NULL at the free(), nor can I see it mattering
if it is not set to NULL (notice that it goes out of scope with the for loop).
-pd
> On 7 Jun 2020, at 16:00 , Jeroen Ooms wrote:
>
> On Sun, Jun 7, 2020 at 3:13 AM Fox, John wrote:
>>
>> Hi,
>>
>> The following code, from the examples in ?TkWidgets , immediately crashes R
>> 4.0.1 for Windows:
>>
>> - snip
>> library("tcltk")
>> tt <- tktoplevel()
>> label.widget <- tklabel(tt, text = "Hello, World!")
>> button.widget <- tkbutton(tt, text = "Push",
>> command = function()cat("OW!\n"))
>> tkpack(label.widget, button.widget) # geometry manager
>> - snip
>
>
> I can reproduce this. The backtrace shows the crash happens in
> dotTclObjv [/src/library/tcltk/src/tcltk.c@243 ]. This looks like a
> bug that was introduced by commit 78408/78409 about a month ago. I
> think the problem is that this commit changes 'calloc' to 'Calloc'
> without changing the corresponding 'free' to 'Free'.
>
> This has nothing to do with the Windows build or installation. Nothing
> has changed in the windows build procedure between 4.0.0 and 4.0.1.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] use of the tcltk package crashes R 4.0.1 for Windows
John,
The Windows installation instructions document has the following. So, one
obvious question is whether you did select it. (I haven't installed on WIndows
for ages, so I don't know whether this was changed recently or even whether the
selection is on or off by default).
-pd
Using package tcltk
===
The package tcltk supports building graphical interfaces with Tcl/Tk.
"Support Files for Package tcltk" needs to be selected from the
installer for this to work; alternatively you can use an existing
installation of Tcl/Tk 8.6.x by following the instructions in the
rw-FAQ.
> On 7 Jun 2020, at 08:27 , peter dalgaard wrote:
>
> Not happening on Mac, so likely a Windows build issue.
>
> (There's no 4.0.1 CRAN package yet, and no nightly build of 4.0.1 Patched,
> but the only thing changed in the sources since r78644 is the VERSION file.)
>
> -pd
>
>> On 7 Jun 2020, at 03:13 , Fox, John wrote:
>>
>> Hi,
>>
>> The following code, from the examples in ?TkWidgets , immediately crashes R
>> 4.0.1 for Windows:
>>
>> - snip
>> library("tcltk")
>> tt <- tktoplevel()
>> label.widget <- tklabel(tt, text = "Hello, World!")
>> button.widget <- tkbutton(tt, text = "Push",
>> command = function()cat("OW!\n"))
>> tkpack(label.widget, button.widget) # geometry manager
>> - snip
>>
>> Session info (prior to the crash):
>>
>> - snip
>>> sessionInfo()
>> R version 4.0.1 (2020-06-06)
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>> Running under: Windows 10 x64 (build 18363)
>>
>> Matrix products: default
>>
>> locale:
>> [1] LC_COLLATE=English_United States.1252
>> [2] LC_CTYPE=English_United States.1252
>> [3] LC_MONETARY=English_United States.1252
>> [4] LC_NUMERIC=C
>> [5] LC_TIME=English_United States.1252
>>
>> attached base packages:
>> [1] tcltk stats graphics grDevices utils datasets methods
>> [8] base
>>
>> loaded via a namespace (and not attached):
>> [1] compiler_4.0.1 tools_4.0.1
>> - snip
>>
>> I observe this behaviour both in the Rgui and when I run R in a terminal. I
>> think the problem is general to the use of the tcltk package.
>>
>> Best,
>> John
>>
>> -
>> John Fox
>> Professor Emeritus
>> McMaster University
>> Hamilton, Ontario, Canada
>> Web: https://socialsciences.mcmaster.ca/jfox/
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk Priv: pda...@gmail.com
>
>
>
>
>
>
>
>
>
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] use of the tcltk package crashes R 4.0.1 for Windows
Just to be clear, I was talking about Mac binary packages. The one available
and tested was
R-4.0-branch
4.0.1 RC
(2020/05/30, r78644)
from mac.r-project.org. (Simon Urbanek out of office for the weekend, I
suppose.)
-pd
> On 7 Jun 2020, at 08:27 , peter dalgaard wrote:
>
> Not happening on Mac, so likely a Windows build issue.
>
> (There's no 4.0.1 CRAN package yet, and no nightly build of 4.0.1 Patched,
> but the only thing changed in the sources since r78644 is the VERSION file.)
>
> -pd
>
>> On 7 Jun 2020, at 03:13 , Fox, John wrote:
>>
>> Hi,
>>
>> The following code, from the examples in ?TkWidgets , immediately crashes R
>> 4.0.1 for Windows:
>>
>> - snip
>> library("tcltk")
>> tt <- tktoplevel()
>> label.widget <- tklabel(tt, text = "Hello, World!")
>> button.widget <- tkbutton(tt, text = "Push",
>> command = function()cat("OW!\n"))
>> tkpack(label.widget, button.widget) # geometry manager
>> - snip
>>
>> Session info (prior to the crash):
>>
>> - snip
>>> sessionInfo()
>> R version 4.0.1 (2020-06-06)
>> Platform: x86_64-w64-mingw32/x64 (64-bit)
>> Running under: Windows 10 x64 (build 18363)
>>
>> Matrix products: default
>>
>> locale:
>> [1] LC_COLLATE=English_United States.1252
>> [2] LC_CTYPE=English_United States.1252
>> [3] LC_MONETARY=English_United States.1252
>> [4] LC_NUMERIC=C
>> [5] LC_TIME=English_United States.1252
>>
>> attached base packages:
>> [1] tcltk stats graphics grDevices utils datasets methods
>> [8] base
>>
>> loaded via a namespace (and not attached):
>> [1] compiler_4.0.1 tools_4.0.1
>> - snip
>>
>> I observe this behaviour both in the Rgui and when I run R in a terminal. I
>> think the problem is general to the use of the tcltk package.
>>
>> Best,
>> John
>>
>> -
>> John Fox
>> Professor Emeritus
>> McMaster University
>> Hamilton, Ontario, Canada
>> Web: https://socialsciences.mcmaster.ca/jfox/
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk Priv: pda...@gmail.com
>
>
>
>
>
>
>
>
>
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] use of the tcltk package crashes R 4.0.1 for Windows
Not happening on Mac, so likely a Windows build issue.
(There's no 4.0.1 CRAN package yet, and no nightly build of 4.0.1 Patched, but
the only thing changed in the sources since r78644 is the VERSION file.)
-pd
> On 7 Jun 2020, at 03:13 , Fox, John wrote:
>
> Hi,
>
> The following code, from the examples in ?TkWidgets , immediately crashes R
> 4.0.1 for Windows:
>
> - snip
> library("tcltk")
> tt <- tktoplevel()
> label.widget <- tklabel(tt, text = "Hello, World!")
> button.widget <- tkbutton(tt, text = "Push",
>command = function()cat("OW!\n"))
> tkpack(label.widget, button.widget) # geometry manager
> - snip
>
> Session info (prior to the crash):
>
> - snip
>> sessionInfo()
> R version 4.0.1 (2020-06-06)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 10 x64 (build 18363)
>
> Matrix products: default
>
> locale:
> [1] LC_COLLATE=English_United States.1252
> [2] LC_CTYPE=English_United States.1252
> [3] LC_MONETARY=English_United States.1252
> [4] LC_NUMERIC=C
> [5] LC_TIME=English_United States.1252
>
> attached base packages:
> [1] tcltk stats graphics grDevices utils datasets methods
> [8] base
>
> loaded via a namespace (and not attached):
> [1] compiler_4.0.1 tools_4.0.1
> - snip
>
> I observe this behaviour both in the Rgui and when I run R in a terminal. I
> think the problem is general to the use of the tcltk package.
>
> Best,
> John
>
> -
> John Fox
> Professor Emeritus
> McMaster University
> Hamilton, Ontario, Canada
> Web: https://socialsciences.mcmaster.ca/jfox/
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.0.1 is released
The build system rolled up R-4.0.1.tar.gz (codename "See Things Now") this morning. The list below details the changes in this release. You can get the source code from http://cran.r-project.org/src/base/R-4/R-4.0.1.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard These are the checksums (md5 and SHA-256) for the freshly created files, in case you wish to check that they are uncorrupted: MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4 MD5 (COPYING) = eb723b61539feef013de476e68b5c50a MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343 MD5 (FAQ) = 4afa171cd982aaa60f0ba92e2e7bc5d6 MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b MD5 (NEWS) = 425fd186ac71e462e66af7fb33f86ab4 MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8 MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801 MD5 (NEWS.2) = 496062c138e2def06cebccddfb814ac6 MD5 (NEWS.3) = 012e7f4a80cc8ec947bf3f0ff6117ec8 MD5 (R-latest.tar.gz) = 8d199d11865c202cf2bd006e7f32dab7 MD5 (README) = f468f281c919665e276a1b691decbbe6 MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435 MD5 (THANKS) = 251d20510bfc3cc93b82c5a99f7efcc6 MD5 (VERSION-INFO.dcf) = 7d8af8c338a1e146f9471744d092078a MD5 (R-4/R-4.0.1.tar.gz) = 8d199d11865c202cf2bd006e7f32dab7 2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09 AUTHORS e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING 6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB eddf87b12197c7b3b19cbc9b11c1beab95b14e3dcd715bf37d2f6a8b2a72c2a1 FAQ f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL 1dfd76a990f2a1b11ee4ff17284d18c2177179ee7bbaef51b32e1e7a58719596 NEWS 4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0 12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1 e80de410c77f05ff2012fa70051b89119845f734a7fa5c55857e61e4ed7d5f6e NEWS.2 7201d139947afa52b5e09d26dc01445edf444506264355b2185122bc1ed3dce0 NEWS.3 95fe24a4d8d8f8f888460c8f5fe4311cec656e7a1722d233218bc03861bc6f32 R-latest.tar.gz 2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README 408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9 RESOURCES c9c7cb32308b4e560a22c858819ade9de524a602abd4e92d1c328c89f8037d73 THANKS d3cdccb1b1645fce356d08892baa0587aa2aef2e851ad552d47cce856137d9b3 VERSION-INFO.dcf 95fe24a4d8d8f8f888460c8f5fe4311cec656e7a1722d233218bc03861bc6f32 R-4/R-4.0.1.tar.gz This is the relevant part of the NEWS file CHANGES IN R 4.0.1: NEW FEATURES: * paste() and paste0() gain a new optional argument recycle0. When set to true, zero-length arguments are recycled leading to character(0) after the sep-concatenation, i.e., to the empty string "" if collapse is a string and to the zero-length value character(0) when collapse = NULL. A package whose code uses this should depend on R (>= 4.0.1). * The summary() method now maps the counts correctly to the warning messages. BUG FIXES: * aov(frml, ...) now also works where the formula deparses to more than 500 characters, thanks to a report and patch proposal by Jan Hauffa. * Fix a dozen places (code, examples) as Sys.setlocale() returns the new rather than the previous setting. * Fix for adding two complex grid units via sum(). Thanks to Gu Zuguang for the report and Thomas Lin Pedersen for the patch. * Fix parallel::mclapply(..., mc.preschedule=FALSE) to handle raw vector results correctly. PR#17779 * Computing the base value, i.e., 2, "everywhere", now uses FLT_RADIX, as the original machar code looped indefinitely on the ppc64 architecture for the longdouble case. * In R 4.0.0, sort.list(x) when is.object(x) was true, e.g., for x <- I(letters), was accidentally using method = "radix". Consequently, e.g., merge() was much slower than previously; reported in PR#17794. * plot(y ~ x, ylab = quote(y[i])) now works, as e.g., for xlab; related to PR#10525. * parallel::detect.cores(all.tests = TRUE) tries a matching OS name before the other tests (which were intended only for unknown OSes). * Parse data for raw strings is now recorded correctly. Reported by Gabor Csardi. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] [R] a question of etiquette
t;>>> Subject: [R] a question of etiquette >>>> Date: June 1, 2020 at 11:34:00 AM CDT >>>> To: r-h...@r-project.org >>>> >>>> The new version of a package which I maintain will include a new function >>>> which I have ported to R from Matlab. >>>> The documentation of this R function indicates the authors of the original >>>> Matlab code, reference to their paper, URL of the source code. >>>> >>>> Question: is this adequate, or should I include them as co-authors of the >>>> package, or as contributors, or what else? >>>> Is there a general policy about this matter? >>>> >>>> Adelchi Azzalini >>>> http://azzalini.stat.unipd.it/ >>>> >>>> __ >>>> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see >>>> https://stat.ethz.ch/mailman/listinfo/r-help >>>> PLEASE do read the posting guide >>>> http://www.R-project.org/posting-guide.html >>>> and provide commented, minimal, self-contained, reproducible code. >>> [[alternative HTML version deleted]] >>> __ >>> R-package-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel > >__ >R-package-devel@r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-package-devel > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] r-project.org SSL certificate issues
Odd. Safari has no problem and says certificate expires August 16 2020, but I
also see the download.file issue with 4.0.1 beta:
> download.file("https://www.r-project.org;, tempfile())
trying URL 'https://www.r-project.org'
Error in download.file("https://www.r-project.org;, tempfile()) :
cannot open URL 'https://www.r-project.org'
In addition: Warning message:
In download.file("https://www.r-project.org;, tempfile()) :
URL 'https://www.r-project.org/': status was 'Peer certificate cannot be
authenticated with given CA certificates'
(note slightly different error message).
svn is also affected:
Peters-MacBook-Air:R pd$ svn up
Updating '.':
Error validating server certificate for 'https://svn.r-project.org:443':
- The certificate has expired.
Certificate information:
- Hostname: *.r-project.org
- Valid: from Aug 16 00:00:00 2018 GMT until Aug 15 23:59:59 2020 GMT
- Issuer: COMODO RSA Domain Validation Secure Server CA, COMODO CA Limited,
Salford, Greater Manchester, GB
- Fingerprint: 93:B8:AF:9F:0A:67:2F:3A:C9:BA:FF:86:BB:2C:08:47:02:7F:1D:8D
(R)eject, accept (t)emporarily or accept (p)ermanently? t
Usrc/library/grid/R/grob.R
ssltest shows two certificates of which only one is expired?
-pd
> On 30 May 2020, at 22:17 , Gábor Csárdi wrote:
>
> On macOS 10.15.5 and R-devel:
>
>> download.file("https://www.r-project.org;, tempfile())
> trying URL 'https://www.r-project.org'
> Error in download.file("https://www.r-project.org;, tempfile()) :
> cannot open URL 'https://www.r-project.org'
> In addition: Warning message:
> In download.file("https://www.r-project.org;, tempfile()) :
> URL 'https://www.r-project.org': status was 'SSL peer certificate or
> SSH remote key was not OK'
>
> https://www.ssllabs.com/ssltest says:
>
> COMODO RSA Certification Authority
> Fingerprint SHA256:
> 4f32d5dc00f715250abcc486511e37f501a899deb3bf7ea8adbbd3aef1c412da
> Pin SHA256: grX4Ta9HpZx6tSHkmCrvpApTQGo67CYDnvprLg5yRME=
> Valid untilSat, 30 May 2020 10:48:38 UTC (expired 8 hours and 51
> minutes ago) EXPIRED
>
> AFAICT this is the reason:
> https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-2020
>
> FYI,
> Gabor
>
> ______
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.0.1 scheduled for June 6
Full schedule is available on developer.r-project.org. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ 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] Precision of function mean,bug?
Expected, see FAQ 7.31. You just can't trust == on FP operations. Notice also > a2=(z[idx]+x[idx]+y[idx])/3 > a2==a [1] FALSE > a2==b [1] TRUE -pd > On 20 May 2020, at 12:40 , Morgan Morgan wrote: > > Hello R-dev, > > Yesterday, while I was testing the newly implemented function pmean in > package kit, I noticed a mismatch in the output of the below R expressions. > > set.seed(123) > n=1e3L > idx=5 > x=rnorm(n) > y=rnorm(n) > z=rnorm(n) > a=(x[idx]+y[idx]+z[idx])/3 > b=mean(c(x[idx],y[idx],z[idx])) > a==b > # [1] FALSE > > For idx= 1, 2, 3, 4 the last line is equal to TRUE. For 5, 6 and many > others the difference is small but still. > Is that expected or is it a bug? > > Thank you > Best Regards > Morgan Jacob > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dbinom link
In principle a good idea, but I'm not sure the whereabouts of Catherine Loader are known at this point. Last peeps from her on the net seem to be about a decade old. .pd > On 18 May 2020, at 10:31 , Abby Spurdle wrote: > > This has come up before. > > Here's the last time: > https://stat.ethz.ch/pipermail/r-devel/2019-March/077478.html > > I guess my answer to the following the question... > >Perhaps we should ask permission to >nail the thing down somewhere on r-project.org? > > ...would be, to reproduce it somewhere. > And then update the link in the binom help file. > > Given that the article was previously available freely (with no > apparent restrictions on reproducing it), and that the author has > significant published works which are open access, I'd be surprised if > there's any objection to reproducing it. > > > On Mon, May 18, 2020 at 8:01 PM Koenker, Roger W > wrote: >> >> FWIW the link from ?dbinom to the Loader paper on Binomials is broken but >> the paper seems to be >> available here: >> https://octave.1599824.n4.nabble.com/attachment/3829107/0/loader2000Fast.pdf >> >> Roger Koenker >> r.koen...@ucl.ac.uk<mailto:r.koen...@ucl.ac.uk> >> Honorary Professor of Economics >> Department of Economics, UCL >> Emeritus Professor of Economics >> and Statistics, UIUC >> >> >> >>[[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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] edit() doubles backslashes when keep.source=TRUE
To discuss this further, we should probably move over to R-sig-mac and change the subject header. -pd > On 15 May 2020, at 19:26 , peter dalgaard wrote: > > Actually, it's not that hard to set up for a source compile for MacOS..... -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] edit() doubles backslashes when keep.source=TRUE
Actually, it's not that hard to set up for a source compile for MacOS. The hard part is to do it precisely like the CRAN binaries so that you can run binary packages off CRAN, but in other setups you can just build packages from source. A stone in the shoe has been that the documentation on mac.r-project.org was littered with out-of-date information, but it seems that Simon has now cleaned this up considerably. It should now be possible simply to follow instructions on http://mac.r-project.org/tools/. I'm sure Simon will be receptive to information if something doesn't quite work. -pd > On 15 May 2020, at 18:48 , brodie gaslam via R-devel > wrote: > >> >> On Friday, May 15, 2020, 12:13:04 PM EDT, Dirk Eddelbuettel >> wrote: >> On 15 May 2020 at 15:41, Martin Maechler wrote: >> | >> | >> |Why does nobody anymore help R development by working with >> |"R-devel", or at least then the alpha, beta and the "RC" >> |(Release Candidate) versions that we release daily for about one >> |month before the final release? >> | >> |Notably a highly staffed enterprise such as Rstudio (viz the bug >> |report 17800 above), but also others could really help by >> |starting to use the "next version" of R on a routine basis ... >> | >> | >> >> Seconded. Without testing we can never know. R Core does their part. >> >> I provided weekly Debian binaries. One each for the two alphas releases, for >> the beta release, for the release candidate. It is easy to use these, for >> example in a Docker container. >> >> It is also easy to use this on a normal machine as they are standard (Debian) >> packages: install, try some tests, uninstall, revert to previous version by >> installing that. >> >> Dirk > > This is a very reasonably request, and all useRs who benefit from the > tireless work of R-core should consider doing it. I have considered > it, but compiling R from sources on OS X has been my stumbling block. > At least last time I tried I got stuck at the Fortran step. It doesn't > help I have very limited experience compiling software of the complexity > of R. Really, I've only done it within the warm welcoming confines of the > vagrant image Tomas Kalibera set up for `rchk`. > > I also use r-devel on docker, but that isn't very practical for > day-to-day usage, which is what I think we need. > > What would it take to generate pre-release binaries for OS X (and Windows)? I > imagine if such were available the volume of testers would increase > dramatically (at least, I haven't seen them if they exist). > Maybe something the R Consortium would consider funding? > > Best, > > B. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.0.1
A quick heads-up: We intend to have a 4.0.1 release some time early June, possibly 6/6. For the R Core Team Peter D. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Re: R 4.0.0 build error with sysdata.rda on ppc64el architecture
I don't think compiler was involved, it was just the next thing after sysdata.rda, so a suspect at some point. -pd > On 30 Apr 2020, at 16:11 , luke-tier...@uiowa.edu wrote: > > On Thu, 30 Apr 2020, Dirk Eddelbuettel wrote: > >> >> On 30 April 2020 at 09:42, Iñaki Ucar wrote: >> | On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel wrote: >> | > And to keep the list abreast, this appears to be related to the long >> double >> | > issue on powerpc where needed an extra #define to ensure compilation. >> That >> [...] >> | Which reminds me that [1] was required for v3.6.2. Could be related? >> >> Yes, that is what I refered to via "long double issue on powerpc". Without a >> URL but it is the same issue (in the sense of that architecture being "very >> different"); it simply is no longer the same issue of needing the #define to >> compile. But the diffferent nature of powerpc now bite's R own 'compiler' >> package. R Core is on it; I may avoid it in a quicker fix by disabling long >> double support on just this platform (til we have a better fix). > > Maybe I missed something. How is the 'compiler' package involved? > > Best, > > luke > >> >> Dirk >> >> > > -- > 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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.0 build error with sysdata.rda on ppc64el architecture
Hum, at least it is not Apple, so maybe you can attach a debugger to the running process? (gdb -p process_id or something like that --- haven't actually done it for a decade). Then at least we can get a stack trace and a clue about where it is looping. Diddling optimization options can also sometimes provide a clue. -pd > On 29 Apr 2020, at 01:17 , Dirk Eddelbuettel wrote: > > > The R 4.0.0 package migration on Debian is being held back by a failed build > on ppc64el [1]. We can see from the history of builds logs [2] that it used > to build, briefly failed, worked again and then failed leading to R 4.0.0's > release. (And my bad for missing how the alpha1/alpha2/beta/rc builds failed.) > > I have however neither changed anything, nor did I ever have to accomodate > ppc64el (as it has happened with other platforms in the past). > > The automated build gets killed after 150 mins at > > make[7]: Entering directory '/<>/src/library/tools/src' > mkdir -p -- ../../../../library/tools/libs > make[7]: Leaving directory '/<>/src/library/tools/src' > make[6]: Leaving directory '/<>/src/library/tools/src' > make[5]: Leaving directory '/<>/src/library/tools' > make[5]: Entering directory '/<>/src/library/tools' > installing 'sysdata.rda' > E: Build killed with signal TERM after 150 minutes of inactivity > > as can be seen in [3]. The Debian wiki has pointers for getting a shell > account on such platforms [4] (and that is not limited to Debianers but a > 'Minipower' service). I now have one such account on the VM farm at Unicamp > [5] in Brazil. It uses OpenStack (slick, never used it before) and I just > provisioned a reasonably beefy machine, booted from one of the available OSs > (Ubuntu 20.04), installed the build-dependencies and ... am now hanging at > the exact same spot: > > make[7]: Entering directory '/home/ubuntu/git/r-base/src/library/tools/src' > mkdir -p -- ../../../../library/tools/libs > make[7]: Leaving directory '/home/ubuntu/git/r-base/src/library/tools/src' > make[6]: Leaving directory '/home/ubuntu/git/r-base/src/library/tools/src' > make[5]: Leaving directory '/home/ubuntu/git/r-base/src/library/tools' > make[5]: Entering directory '/home/ubuntu/git/r-base/src/library/tools' > installing 'sysdata.rda' > > So at least it reproduces. But how do we go about addressing this? Why would > it be looping infinitely trying to assemble sysdata.rda? > > Any hints or suggestions or debug flags I should set? > > Thanks in advance for any pointers, Dirk > > > [1] https://buildd.debian.org/status/package.php?p=r-base=experimental > [2] https://buildd.debian.org/status/logs.php?pkg=r-base=ppc64el > [3] > https://buildd.debian.org/status/fetch.php?pkg=r-base=ppc64el=4.0.0-1=1587737274=0 > [4] https://wiki.debian.org/ppc64el > [5] https://openpower.ic.unicamp.br/minicloud/ > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.0.0 is released
The build system rolled up R-4.0.0.tar.gz (codename "Arbor Day") this morning.
The list below details the changes in this release.
You can get the source code from
http://cran.r-project.org/src/base/R-4/R-4.0.0.tar.gz
or wait for it to be mirrored at a CRAN site nearer to you.
Binaries for various platforms will appear in due course.
For the R Core Team,
Peter Dalgaard
These are the checksums (md5 and SHA-256) for the freshly created files, in
case you wish
to check that they are uncorrupted:
MD5 (AUTHORS) = b9c44f9f78cab3184ad9898bebc854b4
MD5 (COPYING) = eb723b61539feef013de476e68b5c50a
MD5 (COPYING.LIB) = a6f89e2100d9b6cdffcea4f398e37343
MD5 (FAQ) = 4afa171cd982aaa60f0ba92e2e7bc5d6
MD5 (INSTALL) = 7893f754308ca31f1ccf62055090ad7b
MD5 (NEWS) = 9aafc4b3277fdf482cf8195f707ae758
MD5 (NEWS.0) = bfcd7c147251b5474d96848c6f57e5a8
MD5 (NEWS.1) = eb78c4d053ec9c32b815cf0c2ebea801
MD5 (NEWS.2) = 496062c138e2def06cebccddfb814ac6
MD5 (NEWS.3) = 012e7f4a80cc8ec947bf3f0ff6117ec8
MD5 (R-latest.tar.gz) = 48c487c68112cb3191f3015c6277a50b
MD5 (README) = f468f281c919665e276a1b691decbbe6
MD5 (RESOURCES) = 529223fd3ffef95731d0a87353108435
MD5 (THANKS) = bb45f89c01d509721c47fd41f147da60
MD5 (VERSION-INFO.dcf) = f6e4e96a451cc3131a18d9f63c4c67b8
MD5 (R-4/R-4.0.0.tar.gz) = 48c487c68112cb3191f3015c6277a50b
2cde824a7b18958e5f06b391c801c8288be0f84fa8934b7ddefef23c67e60c09 AUTHORS
e6d6a009505e345fe949e1310334fcb0747f28dae2856759de102ab66b722cb4 COPYING
6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3 COPYING.LIB
eddf87b12197c7b3b19cbc9b11c1beab95b14e3dcd715bf37d2f6a8b2a72c2a1 FAQ
f87461be6cbaecc4dce44ac58e5bd52364b0491ccdadaf846cb9b452e9550f31 INSTALL
b9c6a73f2b03421d157185ee68c88a8e5a26b6f3e1edf977deb26a43c8ed98ed NEWS
4e21b62f515b749f80997063fceab626d7258c7d650e81a662ba8e0640f12f62 NEWS.0
12b30c724117b1b2b11484673906a6dcd48a361f69fc420b36194f9218692d01 NEWS.1
e80de410c77f05ff2012fa70051b89119845f734a7fa5c55857e61e4ed7d5f6e NEWS.2
7201d139947afa52b5e09d26dc01445edf444506264355b2185122bc1ed3dce0 NEWS.3
06beb0291b569978484eb0dcb5d2339665ec745737bdfb4e873e7a5a75492940
R-latest.tar.gz
2fdd3e90f23f32692d4b3a0c0452f2c219a10882033d1774f8cadf25886c3ddc README
408737572ecc6e1135fdb2cf7a9dbb1a6cb27967c757f1771b8c39d1fd2f1ab9 RESOURCES
2a8dca916cd92229ef9e328f3610ca204809c262823b860252b42072dac2473a THANKS
47ad507cd5bbf2ad7a3de95b44b223052d4f53a3928aa3782957694d8c1cf05c
VERSION-INFO.dcf
06beb0291b569978484eb0dcb5d2339665ec745737bdfb4e873e7a5a75492940
R-4/R-4.0.0.tar.gz
This is the relevant part of the NEWS file
CHANGES IN 4.0.0:
SIGNIFICANT USER-VISIBLE CHANGES:
* Packages need to be (re-)installed under this version (4.0.0) of
R.
* matrix objects now also inherit from class "array", so e.g.,
class(diag(1)) is c("matrix", "array"). This invalidates code
incorrectly assuming that class(matrix_obj)) has length one.
S3 methods for class "array" are now dispatched for matrix
objects.
* There is a new syntax for specifying _raw_ character constants
similar to the one used in C++: r"(...)" with ... any character
sequence not containing the sequence )". This makes it easier to
write strings that contain backslashes or both single and double
quotes. For more details see ?Quotes.
* R now uses a stringsAsFactors = FALSE default, and hence by
default no longer converts strings to factors in calls to
data.frame() and read.table().
A large number of packages relied on the previous behaviour and
so have needed/will need updating.
* The plot() S3 generic function is now in package base rather than
package graphics, as it is reasonable to have methods that do not
use the graphics package. The generic is currently re-exported
from the graphics namespace to allow packages importing it from
there to continue working, but this may change in future.
Packages which define S4 generics for plot() should be
re-installed and package code using such generics from other
packages needs to ensure that they are imported rather than rely
on their being looked for on the search path (as in a namespace,
the base namespace has precedence over the search path).
REFERENCE COUNTING:
* Reference counting is now used instead of the NAMED mechanism for
determining when objects can be safely mutated in base C code.
This reduces the need for copying in some cases and should allow
further optimizations in the future. It should help make the
internal code easier to maintain.
This change is expected to have almost no impact on packages
using supported coding practices in their C/C++ code.
MIGRATION TO PCRE2:
* This version of R is built against the PCRE2 library for
Perl-like regular expressions, if available. (On non-Windows
platforms PCRE1 can
Re: [Rd] stringsAsFactors
In both cases, that is as it should be. 1. expand.grid() (sic) has its main application in factorial designs, for which you want a set of factors 2. tables are factorial structures by nature. Converting factors to character would lose level order (true for 1. as well, actually) - pd > On 13 Apr 2020, at 13:01 , Karolis Koncevičius > wrote: > > Hello, > > I also want to report 2 missed cases of stringsAsFactors=TRUE in base: > > 1. grid.expand() still uses hard stringsAsFactors=TRUE in its arguments. > 2. as.data.frame.table() also keeps factors after conversion from table. > >>>>>>> Duncan Murdoch >>>>>>>on Sun, 12 Apr 2020 08:57:14 -0400 writes: >> >> > The NEWS for R 4.0.0 says "R now uses a stringsAsFactors = FALSE >> > default, and hence by default no longer converts strings to factors in >> > calls to data.frame() and read.table()." >> >> > This seems to have been implemented by setting options(stringsAsFactors >> > = FALSE) in the main R profile. However, setting >> >> > options(stringsAsFactors = NULL) >> >> > reverts to the same behavior as the old options(stringsAsFactors = >> > TRUE). Is this intentional? >> >> >> No! Thanks a lot for testing R 4.0.0 alpha/beta, noticing and >> alerting us about it. >> >> This will be changed ASAP. >> >> ... and it will benefit the whole R user community if quite a >> few good R users (as most readers of 'R-devel') would start >> using 'R 4.0.0 beta' routinely now --- thanks a lot in advance! >> >> Martin >> >> ______ >> 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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
