> Paul Johnson
> on Mon, 20 Nov 2017 14:59:26 -0600 writes:
> I mistakenly left a write in "/tmp" in the rockchalk package (version
> 1.8.109) that I uploaded last Friday. Kurt H wrote and asked me to fix
> today.
> While uploading a new one, I became aware of a probl
> Hadley Wickham
> on Mon, 20 Nov 2017 12:50:24 -0600 writes:
> Hi all,
> I think there's an unnecessary line in [.Date which has a considerable
> impact on performance when subsetting large dates:
> x <- Sys.Date() + 1:1e6
> microbenchmark::microbenchmark(x[1])
Dear all,
I want to create a function shrinkVector(x) that takes x and truncates
it to the first element without copy.
With SETLENGTH and SET_TRUELENGTH, I can achieve that. You can find a
reproducible example below.
But the memory that was freed is not available for other objects
afterwards,
DO NOT DO THIS!!! SETLENGTH and SET_TRUELENGTH are NOT part of the API
and are for internal use only.
Tho proper way to do this is to copy the data you want into a smaller
vector and allow the larger one to be garbage collected.
[VECSXPs are like all other vectors in that they are contigously
al
On 21.11.2017 10:15, Martin Maechler wrote:
Paul Johnson
on Mon, 20 Nov 2017 14:59:26 -0600 writes:
> I mistakenly left a write in "/tmp" in the rockchalk package (version
> 1.8.109) that I uploaded last Friday. Kurt H wrote and asked me to fix
> today.
> While uplo
> Yes, at least so it looks in src/main/objects.c
>
> Also, we had a very similar change a while ago :
>
> r65926 | luke | 2014-06-12 15:54:38 +0200 (Thu, 12. Jun 2014) | 2 Zeilen
> Geänderte Pfade:
>M src/library/base/R/
[This is a "re-post" -- for some reason it never appeared on R-devel]
> Etienne Sanchez
> on Tue, 14 Nov 2017 19:33:07 +0100 writes:
> In some cases, str() does not print the "names" attribute of the object:
>
> u <- structure(c(5, 6), names = c("a", "b"), color = "blue")
> str(u)
Is it safe to call Rprintf and REprintf from a background thread? I'm
working on a package that makes calls to fprintf(stderr, ...) on a
background thread when errors happen, but when I run R CMD check, it
says:
Compiled code should not call entry points which might terminate R nor
write to st
On Tue, 21 Nov 2017, Winston Chang wrote:
Is it safe to call Rprintf and REprintf from a background thread? I'm
working on a package that makes calls to fprintf(stderr, ...) on a
background thread when errors happen, but when I run R CMD check, it
says:
Compiled code should not call entry poin
Thanks - I'll find another way to send messages to the main thread for printing.
-Winston
On Tue, Nov 21, 2017 at 12:42 PM, wrote:
> On Tue, 21 Nov 2017, Winston Chang wrote:
>
>> Is it safe to call Rprintf and REprintf from a background thread? I'm
>> working on a package that makes calls to f
On 11/21/2017 04:12 PM, Winston Chang wrote:
Thanks - I'll find another way to send messages to the main thread for printing.
The CRAN synchronicity and Bioconductor BiocParallel packages provide
inter-process locks that you could use to surround writes (instead of
sending message to the main
Hi,
`[<-.data.frame` is cautious about not leaving holes after existing
columns:
> `[<-`(data.frame(id=1:6), 3, value=data.frame(V3=11:16))
Error in `[<-.data.frame`(data.frame(id = 1:6), 3, value =
data.frame(V3 = 11:16)) :
new columns would leave holes after existing columns
but `[[
Hi,
Here is another problem with data frame subsetting:
> df <- data.frame(aa=1:3)
> value <- data.frame(aa=11:12, row.names=c("A", "B"))
> `[<-`(df, 4:5, , value=value)
aa
1 1
2 2
3 3
A 11
B 12
> `[<-`(df, 5:4, , value=value)
aa
1 1
2 2
3 3
B 12
A 11
On 11/21/2017 06:19 PM, Hervé Pagès wrote:
Hi,
Here is another problem with data frame subsetting:
> df <- data.frame(aa=1:3)
> value <- data.frame(aa=11:12, row.names=c("A", "B"))
> `[<-`(df, 4:5, , value=value)
aa
1 1
2 2
3 3
A 11
B 12
> `[<-`(df, 5:4, , v
14 matches
Mail list logo
