Re: [Rd] Daily News about R-devel/NEWS is not updating
Thank you! Jen On Fri, May 15, 2020 at 9:02 AM Duncan Murdoch wrote: > On 15/05/2020 10:39 a.m., Jennifer Lyon wrote: > > Hi: > > > > The "Daily News about R-devel/NEWS" webpage at > > http://developer.r-project.org/blosxom.cgi/R-devel/NEWS seems to not be > > updating. As of today, the latest entry is Tue, 14 Apr 2020. > > > > Thanks. > > > > Thanks for noticing that. It's now fixed. (The issue was that R-devel > on the news machine didn't have rJava installed; the highlighting of > differences is done by some old Java code.) > > Duncan Murdoch > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Daily News about R-devel/NEWS is not updating
Hi: The "Daily News about R-devel/NEWS" webpage at http://developer.r-project.org/blosxom.cgi/R-devel/NEWS seems to not be updating. As of today, the latest entry is Tue, 14 Apr 2020. Thanks. Jen [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readBin should check that its endian argument is a legal value
Thank you! Jen On Wed, Dec 18, 2019 at 4:12 AM Tomas Kalibera wrote: > Thank you for reporting this problem, R-devel now has a check in readBin > and writeBin. > > I've identified two CRAN packages with an incorrect value for "endian" > and reported to maintainers, unfortunately in their case the intention > was to specify "little". > > Best > Tomas > > On 11/18/19 11:22 PM, Jennifer Lyon wrote: > > I think it would be helpful if readBin checked that its endian argument > is > > a legal value. > > > > Why? I was reviewing some of our code and noticed that the author had > > readBin(..., endian="network") and never having heard of "network", I > > looked at the man page for readBin, and it hadn't heard of "network" > > either. Not good. > > > > I then looked at the R code for readBin, which has this line: > > swap <- endian != .Platform$endian > > > > and swap is passed into the .Internal(readBin). Further use of Google > > revealed that "network" is a known endian in the universe, and our code > was > > working by essentially a lucky chance that the data was "big" and our > > current machines are "little". Really not good. I don't know enough about > > endian stuff to know if it makes sense that "network" should be one of > the > > choices for endian for readBin (which from the documentation currently > are: > > "big", "little" or "swap"), but in my opinion R should have failed with > the > > choice of "network" in our code in the current version of R. I did > > eventually find an aside in the R Data Import/Export document that > > "network" is "big" so I will patch our code to be legal. Of course some > > code may depend on this undocumented behavior, but I would guess that in > > the vast majority of cases an illegal value really is a mistake. > > > > Jen > > > >> sessionInfo() > > R version 3.6.1 (2019-07-05) > > Platform: x86_64-pc-linux-gnu (64-bit) > > Running under: Ubuntu 18.04.3 LTS > > > > Matrix products: default > > BLAS: /home/mbr/r-project/R-3.6.1/lib/libRblas.so > > LAPACK: /home/mbr/r-project/R-3.6.1/lib/libRlapack.so > > > > locale: > > [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C > > [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 > > [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 > > [7] LC_PAPER=en_US.UTF-8 LC_NAME=C > > [9] LC_ADDRESS=C LC_TELEPHONE=C > > [11] LC_MEASUREMENT=en_US.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_3.6.1 > > > > [[alternative HTML version deleted]] > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] readBin should check that its endian argument is a legal value
I think it would be helpful if readBin checked that its endian argument is a legal value. Why? I was reviewing some of our code and noticed that the author had readBin(..., endian="network") and never having heard of "network", I looked at the man page for readBin, and it hadn't heard of "network" either. Not good. I then looked at the R code for readBin, which has this line: swap <- endian != .Platform$endian and swap is passed into the .Internal(readBin). Further use of Google revealed that "network" is a known endian in the universe, and our code was working by essentially a lucky chance that the data was "big" and our current machines are "little". Really not good. I don't know enough about endian stuff to know if it makes sense that "network" should be one of the choices for endian for readBin (which from the documentation currently are: "big", "little" or "swap"), but in my opinion R should have failed with the choice of "network" in our code in the current version of R. I did eventually find an aside in the R Data Import/Export document that "network" is "big" so I will patch our code to be legal. Of course some code may depend on this undocumented behavior, but I would guess that in the vast majority of cases an illegal value really is a mistake. Jen > sessionInfo() R version 3.6.1 (2019-07-05) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 18.04.3 LTS Matrix products: default BLAS: /home/mbr/r-project/R-3.6.1/lib/libRblas.so LAPACK: /home/mbr/r-project/R-3.6.1/lib/libRlapack.so locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.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_3.6.1 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug 17432 in readLines with R >= 3.5.0 still a problem
Michael:
I don't see any comments on Bug 17432 (
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17432) later than June
1, 2018. Would you please supply a link pointing to the followup to this
discussion on bugzilla?
Thanks.
Jen.
> On Thu Sep 13 14:14:46 CEST 2018 Michael Lawrence wrote:
>
> Thanks, I responded to this on bugzilla.
> On Wed, Sep 12, 2018 at 9:04 AM Chris Culnane
> wrote:
> >
> > Bug 17432 (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17432)
is still a problem when using pipes for IPC.
> >
> > The bug is evident when calling R from another process and trying to
communicate via StdIn. R will buffer the input and not read lines until the
buffer is exceeded or StdIn is closed by the sending process. This prevents
interactive communication between a calling process and a child R process.
> >
> > From a quick look at the source code, it looks like the bug is caused
by only disabling buffering when isatty() returns true for a file
descriptor (connections.c). This fixes the original bug when the script is
run in a terminal, but doesn't help for pipes, which will return false for
isatty().
> >
> > An example R script and python script are provided to demonstrate the
problem:
> >
> > R script (example.r):
> >
> > f <- file("stdin")
> > open(f)
> > while(length(line <- readLines(f,n=1)) > 0) {
> > write(line, stderr())
> > }
> >
> > Python3 script:
> >
> > import sys, os, subprocess
> > process = subprocess.Popen(['Rscript', 'example.r'],
stdin=subprocess.PIPE, stdout=subprocess.PIPE)
> > for line in sys.stdin:
> > process.stdin.write((line + '\n').encode('utf-8'))
> > process.stdin.flush()
> >
> >
> > Expected Behaviour:
> > Run python script, each line entered is echoed back immediately by the
R script - which is what happens on 3.4.4
> >
> > Observed Behaviiour on >=3.5.0 (include devel):
> > The R script does not process lines as they are sent, it only receives
them when StdIn is closed.
> >
> >
> > Best Regards
> >
> > Chris
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readLines function with R >= 3.5.0
Hi Michael:
I can confirm Martin's comment. I tested my software with r-devel (r74914)
and it works, while with r-patched (r74914) it does not work (it hangs, as
it did in R 3.5.0). I apologize for it taking so long for me to test this,
but is there any chance this fix could make into R 3.5.1?
Thanks.
Jen.
On Wed, Jun 13, 2018 at 6:24 AM, Michael Lawrence wrote:
> Are you sure it's not available in patched? It's definitely in the
> source since 6/1.
>
> Michael
>
>
> On Wed, Jun 13, 2018 at 2:19 AM, Martin Maechler
> wrote:
> >>>>>> Michael Lawrence
> >>>>>> on Tue, 12 Jun 2018 19:27:49 -0700 writes:
> >
> > > Hi Jen, This was already resolved for R 3.5.1 by just
> > > disabling buffering on terminal file connections like stdin.
> >
> > and before R 3.5.1 exists, *and*
> > as the change is also not yet available in R patched (!)
> > this means using a version of
> > "R-devel", e.g. for Windows available from
> >https://cloud.r-project.org/bin/windows/base/rdevel.html
> >
> > Martin
> >
> > > Sounds like you might want to be running a web service or
> > > something instead though.
> >
> > > Michael
> >
> > > On Tue, Jun 12, 2018 at 4:46 PM, Jennifer Lyon
> > > wrote:
> > >> Hi:
> > >>
> > >> I have also just stumbled into this bug. Unfortunately, I
> > >> can not change the data my program receives from
> > >> stdin. My code runs in a larger system and stdin is sent
> > >> to a Docker container running my R code. The protocol is
> > >> I read a line, readLines("stdin", n=1), do some actions,
> > >> send output on stdout, and wait for the next set of data.
> > >> I don't have control over this protocol, so I can't use
> > >> the ^D workaround.
> > >>
> > >> I am open for other workaround suggestions. The single
> > >> line is actually JSON and can be quite large. If there
> > >> isn't something else cleaner, I am going to try
> > >> readChar() in a while loop looking for \n but I'm
> > >> guessing that would likely be too slow. I am open to
> > >> other workaround solutions. For the moment I have
> > >> reverted back to R 3.4.4.
> > >>
> > >> Thanks for any suggestions.
> > >>
> > >> Jen.
> > >>
> > >>
> > >>>> >>>>> Martin Maechler >>>>> on Mon, 28 May 2018
> > >>>> 10:28:01 +0200 writes:
> > >>>>
> > >>>> >>>>> Ralf Stubner >>>>> on Fri, 25 May 2018 19:18:58
> > >>>> +0200 writes:
> > >>>>
> > >>>> >> Dear all, I would like to draw you attention to this
> > >>>> >> question on SO:
> > >>>> >>
> > >> https://stackoverflow.com/questions/50372043/readlines-
> function-with-new-version-of-r
> > >>>>
> > >>>>
> > >>>> >> Based on the OP's code I used the script
> > >>>>
> > >>>> >> ###
> > >>>> >> create_matrix <- function() { >> cat("Write the
> > >>>> numbers of vertices: ") >> user_input <-
> > >>>> readLines("stdin", n=1) >> user_input <-
> > >>>> as.numeric(user_input) >> print(user_input) >> } >>
> > >>>> create_matrix()
> > >>>> >> ###
> > >>>>
> > >>>> >> and called it with "R -f " from the
> > >>>> command line.
> > >>>>
> > >>>> >> With 'R version 3.4.4 (2018-03-15) -- "Someone to
> > >>>> Lean On"' the
> > >> script
> > >>>> >> prints the inputed number as expected. With both 'R
> > >>>> version 3.5.0 >> (2018-04-23) -- "Joy in Playing"' and
> > >>>> 'R Under development
> > >> (unstable)
> > >>>> >> (2018-05-19 r74746) -- "Unsuffered Consequences&quo
Re: [Rd] readLines function with R >= 3.5.0
Hi:
I have also just stumbled into this bug. Unfortunately, I can not
change the data my program receives from stdin. My code runs in a
larger system and stdin is sent to a Docker container running my R
code. The protocol is I read a line, readLines("stdin", n=1), do some
actions, send output on stdout, and wait for the next set of data. I
don't have control over this protocol, so I can't use the ^D
workaround.
I am open for other workaround suggestions. The single line is
actually JSON and can be quite large. If there isn't something else
cleaner, I am going to try readChar() in a while loop looking for \n
but I'm guessing that would likely be too slow. I am open to other
workaround solutions. For the moment I have reverted back to R 3.4.4.
Thanks for any suggestions.
Jen.
>> > Martin Maechler
>> > on Mon, 28 May 2018 10:28:01 +0200 writes:
>>
>> > Ralf Stubner
>> > on Fri, 25 May 2018 19:18:58 +0200 writes:
>>
>> >> Dear all, I would like to draw you attention to this
>> >> question on SO:
>> >>
https://stackoverflow.com/questions/50372043/readlines-function-with-new-version-of-r
>>
>>
>> >> Based on the OP's code I used the script
>>
>> >> ###
>> >> create_matrix <- function() {
>> >> cat("Write the numbers of vertices: ")
>> >> user_input <- readLines("stdin", n=1)
>> >> user_input <- as.numeric(user_input)
>> >> print(user_input)
>> >> }
>> >> create_matrix()
>> >> ###
>>
>> >> and called it with "R -f " from the command line.
>>
>> >> With 'R version 3.4.4 (2018-03-15) -- "Someone to Lean On"' the
script
>> >> prints the inputed number as expected. With both 'R version 3.5.0
>> >> (2018-04-23) -- "Joy in Playing"' and 'R Under development
(unstable)
>> >> (2018-05-19 r74746) -- "Unsuffered Consequences"' the script does
not
>> >> continue after inputing a number.
>>
>> > I can confirm.
>> > It "works" if you additionally (the [Enter], i.e., EOL) you also
>> > "send" an EOF -- in Unix alikes via -D
>>
>> > The same happens if you use 'Rscript '
>>
>> > I'm not the expert here, but am close to sure that we (R core)
>> > did not intend this change, when fixing other somewhat subtle
>> > bugs in Rscript / 'R -f'
>>
>> > Martin Maechler
>>
>> The same behavior in regular R , no need for a script etc.
>>
>> > str(readLines("stdin", n=1))
>>
>> then in addition to the input you need to "give" an EOF (Ctrl D) in R
>= 3.5.0
>>
>> Interestingly, everything works fine if you use stdin() instead
>> of "stdin" :
>>
>> > rr <- readLines(stdin(), n=1)
>> foo
>> > rr
>> [1] "foo"
>> >
>> --
>>
>> So, for now use stdin() which is much clearer than the string
>> "stdin" anyway
>>
>> Martin Maechler
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readLines() segfaults on large file & question on how to work around
Jeroen: Thank you for pointing me to ndjson, which I had not heard of and is exactly my case. My experience: jsonlite::stream_in - segfaults ndjson::stream_in - my fault, I am running Ubuntu 14.04 and it is too old so it won't compile the package corpus::read_ndjson - works!!! Of course it does a different simplification than jsonlite::fromJSON, so I have to change some code, but it works beautifully at least in simple tests. The memory-map option may be of use in the future. Another correspondent said that strings in R can only be 2^31-1 long, which is why any "solution" that tries to load the whole file into R first as a string, will fail. Thanks for suggesting a path forward for me! Jen On Sun, Sep 3, 2017 at 2:15 AM, Jeroen Ooms <jeroeno...@gmail.com> wrote: > On Sat, Sep 2, 2017 at 8:58 PM, Jennifer Lyon <jennifer.s.l...@gmail.com> > wrote: > > I have a 2.1GB JSON file. Typically I use readLines() and > > jsonlite:fromJSON() to extract data from a JSON file. > > If your data consists of one json object per line, this is called > 'ndjson'. There are several packages specialized to read ndjon files: > > - corpus::read_ndjson > - ndjson::stream_in > - jsonlite::stream_in > > In particular the 'corpus' package handles large files really well > because it has an option to memory-map the file instead of reading all > of its data into memory. > > If the data is too large to read, you can preprocess it using > https://stedolan.github.io/jq/ to extract the fields that you need. > > You really don't need hadoop/spark/etc for this. > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readLines() segfaults on large file & question on how to work around
Thank you for your suggestion. Unfortunately, while R doesn't segfault
calling readr::read_file() on the test file I described, I get the error
message:
Error in read_file_(ds, locale) : negative length vectors are not allowed
Jen
On Sat, Sep 2, 2017 at 1:38 PM, Ista Zahn <istaz...@gmail.com> wrote:
> As s work-around I suggest readr::read_file.
>
> --Ista
>
>
> On Sep 2, 2017 2:58 PM, "Jennifer Lyon" <jennifer.s.l...@gmail.com> wrote:
>
>> Hi:
>>
>> I have a 2.1GB JSON file. Typically I use readLines() and
>> jsonlite:fromJSON() to extract data from a JSON file.
>>
>> When I try and read in this file using readLines() R segfaults.
>>
>> I believe the two salient issues with this file are
>> 1). Its size
>> 2). It is a single line (no line breaks)
>>
>> I can reproduce this issue as follows
>> #Generate a big file with no line breaks
>> # In R
>> > writeLines(paste0(c(letters, 0:9), collapse=""), "alpha.txt", sep="")
>>
>> # in unix shell
>> cp alpha.txt file.txt
>> for i in {1..26}; do cat file.txt file.txt > file2.txt && mv -f file2.txt
>> file.txt; done
>>
>> This generates a 2.3GB file with no line breaks
>>
>> in R:
>> > moo <- readLines("file.txt")
>>
>> *** caught segfault ***
>> address 0x7cff, cause 'memory not mapped'
>>
>> Traceback:
>> 1: readLines("file.txt")
>>
>> Possible actions:
>> 1: abort (with core dump, if enabled)
>> 2: normal R exit
>> 3: exit R without saving workspace
>> 4: exit R saving workspace
>> Selection: 3
>>
>> I conclude:
>> I am potentially running up against a limit in R, which should give a
>> reasonable error, but currently just segfaults.
>>
>> My question:
>> Most of the content of the JSON is an approximately 100K x 6K JSON
>> equivalent of a dataframe, and I know R can handle much bigger than this
>> size. I am expecting these JSON files to get even larger. My R code lives
>> in a bigger system, and the JSON comes in via stdin, so I have absolutely
>> no control over the data format. I can imagine trying to incrementally
>> parse the JSON so I don't bump up against the limit, but I am eager for
>> suggestions of simpler solutions.
>>
>> Also, I apologize for the timing of this bug report, as I know folks are
>> working to get out the next release of R, but like so many things I have
>> no
>> control over when bugs leap up.
>>
>> Thanks.
>>
>> Jen
>>
>> > sessionInfo()
>> R version 3.4.1 (2017-06-30)
>> Platform: x86_64-pc-linux-gnu (64-bit)
>> Running under: Ubuntu 14.04.5 LTS
>>
>> Matrix products: default
>> BLAS: R-3.4.1/lib/libRblas.so
>> LAPACK:R-3.4.1/lib/libRlapack.so
>>
>> locale:
>> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
>> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>> [7] LC_PAPER=en_US.UTF-8 LC_NAME=C
>> [9] LC_ADDRESS=C LC_TELEPHONE=C
>> [11] LC_MEASUREMENT=en_US.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_3.4.1
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] readLines() segfaults on large file & question on how to work around
Hi:
I have a 2.1GB JSON file. Typically I use readLines() and
jsonlite:fromJSON() to extract data from a JSON file.
When I try and read in this file using readLines() R segfaults.
I believe the two salient issues with this file are
1). Its size
2). It is a single line (no line breaks)
I can reproduce this issue as follows
#Generate a big file with no line breaks
# In R
> writeLines(paste0(c(letters, 0:9), collapse=""), "alpha.txt", sep="")
# in unix shell
cp alpha.txt file.txt
for i in {1..26}; do cat file.txt file.txt > file2.txt && mv -f file2.txt
file.txt; done
This generates a 2.3GB file with no line breaks
in R:
> moo <- readLines("file.txt")
*** caught segfault ***
address 0x7cff, cause 'memory not mapped'
Traceback:
1: readLines("file.txt")
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 3
I conclude:
I am potentially running up against a limit in R, which should give a
reasonable error, but currently just segfaults.
My question:
Most of the content of the JSON is an approximately 100K x 6K JSON
equivalent of a dataframe, and I know R can handle much bigger than this
size. I am expecting these JSON files to get even larger. My R code lives
in a bigger system, and the JSON comes in via stdin, so I have absolutely
no control over the data format. I can imagine trying to incrementally
parse the JSON so I don't bump up against the limit, but I am eager for
suggestions of simpler solutions.
Also, I apologize for the timing of this bug report, as I know folks are
working to get out the next release of R, but like so many things I have no
control over when bugs leap up.
Thanks.
Jen
> sessionInfo()
R version 3.4.1 (2017-06-30)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS
Matrix products: default
BLAS: R-3.4.1/lib/libRblas.so
LAPACK:R-3.4.1/lib/libRlapack.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.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_3.4.1
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] print.POSIXct doesn't seem to use tz argument, as per its example
On the documentation page for DateTimeClasses, in the Examples section,
there are the following two lines:
format(.leap.seconds) # the leap seconds in your time zone
print(.leap.seconds, tz = "PST8PDT") # and in Seattle's
The second line (using print) seems to ignore the tz argument, and prints
the dates in my time zone, while:
format(.leap.seconds, tz = "PST8PDT")
does print the dates in PST. The code in
https://github.com/wch/r-source/blob/trunk/src/library/base/R/datetime.R
around line 234 looks like the ... argument is passed to print, not to
format.
print.POSIXct <-
print.POSIXlt <- function(x, ...)
{
max.print <- getOption("max.print", L)
if(max.print < length(x)) {
print(format(x[seq_len(max.print)], usetz = TRUE), ...)
cat(' [ reached getOption("max.print") -- omitted',
length(x) - max.print, 'entries ]\n')
} else print(if(length(x)) format(x, usetz = TRUE)
else paste(class(x)[1L], "of length 0"), ...)
invisible(x)
}
The documentation for print() on this page seems to be silent on tz as an
argument, but I do believe the example using print() does not work as
advertised.
Thanks.
Jen
sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] typo in help page for log1p
There is a small typo in the Source section of the help page for log1p: Source: 'log1p' and 'expm1' may be taken from the operating system, but if not available there are based on the Fortran subroutine 'dlnrel' there - they Jen sessionInfo() R version 3.0.2 (2013-09-25) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_3.0.2 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
