From the user's (or package author's) point, all strings should always
be valid in their declared encoding. If they are not, the result of
string operations is undefined - it may be an error or warning, but also
silently produced correct or incorrect result. There are R functions
that check if
Hi all,
I used `gzfile` and `gzcon` to read a compressed file but I found that
`gzcon` gave me a different result than `gzfile`. It seems like the `gzcon`
does not handle the data correctly. I have posted an example below. In the
example, a portion of a compressed file is downloaded from Google Cl
> Jan Gorecki writes:
> So the unique.default is from the R tools package during checks.
> I don't see those issues on CRAN checks.
I cannot reproduce this locally (and have no clues about docker).
Perhaps you can try to debug this on your end? And see what env_list is
when the error occurs?
> Vincent Goulet via R-devel writes:
Thanks: fixed now in the trunk with c78751.
Best
-k
> In trying to change the driver used by Sweave on the command line using
>R CMD Sweave --driver=foo
> I consistently get the "directory 'foo' does not exist' error. (For any value
> of 'foo', eve
Dear R Developers,
I noticed that `basename` and `dirname` always return "UTF-8" on Windows
(tested with R-4.0.0 and R-3.6.3):
> p <- "Föö/Bär"
> Encoding(p)
[1] "latin1"
> Encoding(dirname(p))
[1] "UTF-8"
> Encoding(basename(p))
[1] "UTF-8"
Is this on purpose? At least I did not find any rele
> Kurt Hornik
> on Mon, 29 Jun 2020 16:13:03 +0200 writes:
> Jan Gorecki writes:
>> So the unique.default is from the R tools package during
>> checks. I don't see those issues on CRAN checks.
> I cannot reproduce this locally (and have no clues about
> docker).
On 29/06/2020 10:39 a.m., Johannes Rauh wrote:
Dear R Developers,
I noticed that `basename` and `dirname` always return "UTF-8" on Windows
(tested with R-4.0.0 and R-3.6.3):
p <- "Föö/Bär"
Encoding(p)
[1] "latin1"
Encoding(dirname(p))
[1] "UTF-8"
Encoding(basename(p))
[1] "UTF-8"
Is thi
Hi all,
it seems that from R 4.0.1 EXTPTR_PTR can be either a macro or a
function, depending on whether USE_RINTERNALS is requested.
Jeroen helped me find that this was in 78592:
https://github.com/wch/r-source/commit/c634fec5214e73747b44d7c0e6f047fefe44667d
This is a problem, because binary pac
Did you test with R 4.0.2 or R-devel? A bug related to this issue was
recently fixed:
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17833
Best,
Kevin
On Mon, Jun 29, 2020 at 11:51 AM Duncan Murdoch
wrote:
>
> On 29/06/2020 10:39 a.m., Johannes Rauh wrote:
> > Dear R Developers,
> >
> > I
Thank you both,
You are absolutely correct that example should be minimal, so here it is.
l = list(a=new.env(), b=new.env())
unique(l)
Just for completeness, env_list during check that raises error
env_list <- list(baseenv(),
as.environment("package:graphics"),
as.environment("package:stats"
EXTPTR_PTR is not in the API so it is not guaranteed to even exist in
the future. The API function for accessing the pointer address is
R_ExternalPtrAddr. See Section 5.13 in WRE.
Sometimes internals need to be changed, In this case a change was made
to deal with a segfault; the commit notice tel
> Jan Gorecki writes:
> Thank you both,
> You are absolutely correct that example should be minimal, so here it is.
> l = list(a=new.env(), b=new.env())
> unique(l)
> Just for completeness, env_list during check that raises error
> env_list <- list(baseenv(),
> as.environment("package:gra
12 matches
Mail list logo
