As of R Under development (unstable) (2018-01-19 r74138):
> as.character(list(NA))
[1] "NA"
> is.na(as.character(list(NA)))
[1] FALSE
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
(An example is wchar_t which has typically 16b on
> Windows as guaranteed by the standard and 32b on Unix)
>
> Best,
> Mark
>
>
> Patrick Perry <mailto:ppe...@stern.nyu.edu>
> December 11, 2017 at 10:32 AM
> A recent change to r-devel causes
A recent change to r-devel causes an R CMD check warning when a C file
includes a "#pragma GCC diagnostic ignored" pragma:
https://github.com/wch/r-source/commit/b76c8fd355a0f5b23d42aaf44a879cac0fc31fa4
. This causes the CRAN checks for the "corpus" package to emit a
warning:
https://www.r-pro
Converting a data.frame with a nested data.frame to a matrix fails:
x <- structure(list(a = data.frame(letters)),
class = "data.frame",
row.names = .set_row_names(26))
as.matrix(x)
#> Error in ncol(xj) : object 'xj' not found
The offending code is here, in the defi
ps://github.com/gagolews/stringi/issues/287 and the links to the
related issues).
Patrick
> Patrick Perry <mailto:ppe...@stern.nyu.edu>
> September 14, 2017 at 7:47 AM
> This particular issue has a simple fix. Currently, the
> "R_check_locale" function includes the fo
(All output from R 3.5 r73238, see
> sessionInfo at the end)
>
> > Sys.getlocale("LC_CTYPE")
> [1] "German_Germany.1252"
> > x <- c("€", "ž", "š", "ü")
> > sapply(x, charToRaw)
> \u0080 \u009e \u009a ü
&g
My understanding (which could be wrong) is that when you source a file,
it first gets translated to your native locale and then parsed. When you
parse a character vector, it does not get translated.
In your locale, every "я" character (U+044F) gets replaced by the byte
"\xFF":
> iconv("\u044
Regarding the Windows character encoding issues Daniel Possenriede
posted about earlier this month, where non-Latin-1 strings were getting
marked as such
(https://stat.ethz.ch/pipermail/r-devel/2017-August/074731.html ):
The issue is that on Windows, when the character locale is Windows-1252,
t, then (1) seems like the
correct option. If Rprintf is sending to a file connection with encoding
set to UTF-8 (for example, after a call to sink(file(...,
encoding="UTF-8"))), then (2) is correct. Is there any way to know the
encoding that Rprintf is expecting?
Thanks,
Patrick
-
probably end up prefixing all of my functions with "corpus_" to
avoid future namespace clashers.
Patrick
Dirk Eddelbuettel wrote:
>
> On 11 May 2017 at 12:16, Patrick Perry wrote:
> | I've done a bit more investigation into this issue. Here is my current
> | understand
can see the source for the libreadline xrealloc at
https://github.com/JuliaLang/readline/blob/master/xmalloc.c#L67
Patrick Perry wrote:
>
> I have a package on CRAN now (corpus-0.3.1) that is currently failing
> tests on Linux, but passing on all other architectures:
>
> https://cran
I have a package on CRAN now (corpus-0.3.1) that is currently failing
tests on Linux, but passing on all other architectures:
https://cran.r-project.org/web/checks/check_results_corpus.html
I believe that the issue arrises from a namespace class between
"xrealloc", which my package provides for
Is the following expected behavior?
> mkext <- inline::cfunction(language="C", body='return
R_MakeExternalPtr(NULL, install("tag"), R_NilValue);')
> x <- mkext()
> y <- x
> attr(y, "foo") <- "bar"
> attributes(x)
$foo
[1] "bar"
I would expect that modifying y's attributes should not affect x.
The CRAN submission process seems in need of a massive overhaul. Why has this
process not been automated yet?
—
Patrick Perry
Assistant Professor
NYU Stern School of Business
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman
> I suspect that what we really need is
>
> fitI <- lm(x ~ xreg - 1, na.action = na.omit)
> fit <- if(length(dx) > ncol(dxreg))
> lm(dx ~ dxreg - 1, na.action = na.omit)
> else list(rank = 0L)
> if(fit$rank == 0L) {
> ## Degenerate model. Proceed anyway so as not to break old code
> fit <- fit
Thanks for your help, Martin and Peter.
I tried taking the value of “n.used” from the C functions (ARIMA_CSS and
ARIMA_Like) instead of computing n.used on the R side. Here is a patch, in
case you’re interested:
https://github.com/patperry/r-source/commit/8fed79a6d2d558ef34738624a2a4f9e795bcf8
26644f743cc645e0
) was designed to change the initialization for the optimization routine.
The proposed fix leaves the deliberate part of the patch unchanged (it
preserves the value of "init0").
--
Patrick Perry
Assistant Professor
Stern School of Business
New York University
On
there’s anything I can do to help get this fix
incorporated.
--
Patrick Perry
Assistant Professor
Stern School of Business
New York University
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
18 matches
Mail list logo
