similar to: ALTREP: Bug reports

Hello Luke and Gabriel, Thank you very much for your quick responses. The explanation of STDVEC is very helpful and I appreciate it! For the wrapper, I have a few new questions. 1. Like Luke said a mutable object is not possible. However, I noticed that there is one extra argument *deep* in the function duplicate. I've googled all the available documentation for ALTREP but I did not find

Jiefei, Inline. On Thu, May 16, 2019 at 2:30 PM ??? <szwjf08 at gmail.com> wrote: > Hello Luke and Gabriel, > > Thank you very much for your quick responses. The explanation of STDVEC is > very helpful and I appreciate it! For the wrapper, I have a few new > questions. > > > 1. Like Luke said a mutable object is not possible. However, I noticed > that there is

Hi Jiefei, Thanks for tryingout the ALTREP stuff and letting us know how it is going. That said I don't think either of these are bugs, per se, but rather a misunderstanding of the API. Details inline. On Thu, May 16, 2019 at 11:57 AM ??? <szwjf08 at gmail.com> wrote: > Hello, > > I have encountered two bugs when using ALTREP APIs. > > 1. STDVEC_DATAPTR > > From

Hello, I'm trying to estimate a cox model with a frailty variable and time-dependent covariate (below there is the statement I use and the error message). It's seems to be impossible, because every time I add the time-dependent covariate the model doesn't converge. Instead, if I estimate the same model without the time-dependent covariate it's converge. I'd like knowing if

Hi, I am searching for a way to solve the following problem: I want to use an external function, defined in a dyn.load()ed shared object, in another dyn.load()ed shared object. Currently I have to take the sources (Fortran) from one libraries src/ directory and copy them into the src/ dir of the other library, resulting in two copies of this function. This is bad for maintanance and maybe also

Hello, I?m experimenting with ALTREP and was wondering if there is a preferred way to create an ALTREP wrapper vector without using .Internal(wrap_meta(?)), which R CMD check doesn?t like since it uses an .Internal() function. I was trying to create a factor that used an ALTREP integer, but attempting to set the class and levels attributes always ended up duplicating and materializing the

Hi all, The coercion function defined for the ALTREP object will not be called by R when an assignment operation implicitly introduces coercion for a large ALTREP object. For example, If I create a vector of length 10, the ALTREP coercion function seems to work fine. ``` > x <- 1:10 > y <- wrap_altrep(x) > .Internal(inspect(y)) @0x000000001f9271c0 13 INTSXP g0c0 [REF(2)] I am

and 'host google.com 8.8.8.8' also gives the expected output? Like this: > root at pf:~# host google.com 8.8.8.8 > Using domain server: > Name: 8.8.8.8 > Address: 8.8.8.8#53 > Aliases: > > google.com has address 74.125.136.100 > google.com has address 74.125.136.113 > google.com has address 74.125.136.101 > google.com has address 74.125.136.138 >

I have a toy alt-rep string package that generates randomly seeded strings. example: library(altstringisode) x <- altrandomStrings(1e8) head(x) [1] "2PN0bdwPY7CA8M06zVKEkhHgZVgtV1" "5PN2qmWqBlQ9wQj99nsQzldVI5ZuGX" ... etc object.size(1e8) Object.size will call the set_altstring_Elt_method for every single element, materializing (slowly) every element of the vector. This

>>>>> Martin Maechler >>>>> on Tue, 8 Sep 2020 10:40:24 +0200 writes: >>>>> Hugh Parsonage >>>>> on Tue, 8 Sep 2020 18:08:11 +1000 writes: >> I can only reproduce on Windows, but reliably (both 4.0.0 and 4.0.2): >> $> R --vanilla >> x <- c(0L, -2e9:2e9) >> # > Segmentation

On Mon, 21 Jan 2019, Martin Maechler wrote: >>>>>> Travers Ching >>>>>> on Tue, 15 Jan 2019 12:50:45 -0800 writes: > > > I have a toy alt-rep string package that generates > > randomly seeded strings. example: library(altstringisode) > > x <- altrandomStrings(1e8) head(x) [1] > >

I can only reproduce on Windows, but reliably (both 4.0.0 and 4.0.2): $> R --vanilla x <- c(0L, -2e9:2e9) # > Segmentation fault Tried to reproduce on Linux but the above worked as expected. Not an issue merely with the length of the vector; for example, x <- rep_len(1:10, 1e10) works, though the altrep vector must be long to reproduce: x <- c(0L, -1e9:1e9) #ok Segmentation

Thanking John for his suggestion I build this function which get the mode of both categorial and discrete data. Mode<-function(x){t<-table(x) if (is.numeric(x)) as.numeric(names(t)[t == max(t)]) else (names(t)[t == max(t)]) } Any other improvement and suggestion will welcome. Best Vito > s [1] 1 1 6 1 1 7 6 5 6 2 1 4 5 6 6 7 3 5 4 1 7 3 7 3 3 7 7 2 1 4 4 2 7 7 6 6 1 2 [39] 5 1 7 7

Hi Jiefei and Kylie, Great to see people engaging with the ALTREP framework and identifying places we may need more tooling. Comments inline. On Thu, Jul 18, 2019 at 12:22 PM King Jiefei <szwjf08 at gmail.com> wrote: > > If that is the case and you are 100% sure the reference number should be 1 > for your variable *y*, my solution is to call *SET_NAMED *in C++ to reset > the

Hi Gabriel, here is a simple package for reproducing the problem. https://github.com/Jiefei-Wang/testPkg Best, Jiefei On Thu, Oct 8, 2020 at 5:04 AM Gabriel Becker <gabembecker at gmail.com> wrote: > Jiefei, > > Where does the code for your altrep class live? > > Thanks, > ~G > > On Wed, Oct 7, 2020 at 4:25 AM Jiefei Wang <szwjf08 at gmail.com> wrote: >

On Tue, 8 Sep 2020, Hugh Parsonage wrote: > Thanks Martin. On further testing, it seems that the segmentation > fault can only occur when the amount of obtainable memory is > sufficiently high. On my machine (admittedly with other processes > running): > > $ R --vanilla --max-mem-size=30G -e "x <- c(0L, -2e9:2e9)" > Segmentation fault > > $ R --vanilla

On 1/22/19 6:17 PM, Kevin Ushey wrote: > I think that object.size() is most commonly used to answer the question, > "what R objects are consuming the most memory currently in my R session?" > and for that reason I think returning the size of the internal > representations of objects (for e.g. ALTREP objects; unevaluated promises) > is the right default behavior. I

I ran into strange behavior when removing names. Two ways of removing names: i <- rep(1:4, length.out=20000) k <- c(a=1, b=2, c=3, d=4) x1 <- unname(k[i]) x2 <- k[i] x2 <- unname(x2) Are they identical? identical(x1,x2) # TRUE but no identical(serialize(x1,NULL),serialize(x2,NULL)) # FALSE But problem is with serialization type 3, cause:

>>>>> luke-tierney >>>>> on Tue, 8 Sep 2020 09:42:43 -0500 (CDT) writes: > On Tue, 8 Sep 2020, Martin Maechler wrote: >>>>>>> Martin Maechler >>>>>>> on Tue, 8 Sep 2020 10:40:24 +0200 writes: >> >>>>>>> Hugh Parsonage >>>>>>> on Tue, 8 Sep 2020

While implementing R's new 'altrep' functionality in the TERR engine, I discovered a bug in R's 'deferred_string' altrep object: it is not using the correct value of the 'OutDec' option when it expands a deferred_string. See the following example: R 3.5.1: (same results in R 3.6.0 devel engine built 10/5) > options(scipen=0, OutDec=".") >