[Rd] stopifnot() does not stop at first non-TRUE argument

Hi, It's surprising that stopifnot() keeps evaluating its arguments after it reaches the first one that is not TRUE: > stopifnot(3 == 5, as.integer(2^32), a <- 12) Error: 3 == 5 is not TRUE In addition: Warning message: In stopifnot(3 == 5, as.integer(2^32), a <- 12) : NAs introduced

Re: [Rd] R 3.4 and mclapply assertion failure - is this a bug?

That's great news that OpenMP is now enabled in MacOS CRAN binaries! Thanks Simon. data.table is supposed to automatically switch down to single-threaded mode when explicitly parallelized via the fork mechanism. It does that via functions registered in init.c as follows : pthread_atfork(&wh

[Rd] potential bug in simulate.lm when gaussian(link != "identity")

Dear all, I think that there is a bug in the function simulate.lm() when called upon a glm fitted with gaussian family with a link other than identity. The variance of the simulated response is clearly off and an inspection to the code of simulate.lm reveals that it is because the variance is divi

Re: [Rd] R 3.4 and mclapply assertion failure - is this a bug?

Yan, this looks like an interaction of OpenMP in data.table and forking - you may want to report that to Matt as he can shed more light on that. He has been complaining that we didn't enable OpenMP before 3.4 so he probably knows about the issue and how to fix it. Cheers, Simon > On May 2, 2

[Rd] R 3.4 and mclapply assertion failure - is this a bug?

Dear all,  I am not sure if this is a bug, so I prefer to post it here before filing. After upgrading to 3.4 I encounter the following message with mclapply: Assertion failure at kmp_runtime.cpp(6480): __kmp_thread_pool == __null.OMP: Error #13: Assertion failure at kmp_runtime.cpp(6480).OMP: Hint

Re: [Rd] Byte compilation with window<- in R3.4.0

Thanks for the report, fixed in R-devel and R-patched. Best Tomas On 04/30/2017 10:48 PM, Christoph Sax wrote: Hi, I am running into a problem when I use the window<- replacement function in R 3.4.0. It will lead to an error when it is called inside a loop, probably the result of the byte comp

Re: [Rd] Any progress on write.csv fileEncoding for UTF-16 and UTF-32 ?

On 01/05/2017 8:49 PM, Jack Kelley wrote: Thanks for looking into this. A few notes regarding all the UTF encodings on Windows 10 ... This all stems from the ancient bad decision by Microsoft to translate LF characters to CR LF when writing text files. R passes 0A or 0A 00 or 0A 00 00 00 to