On Mon, Mar 3, 2014 at 2:50 PM, Simon Urbanek
wrote:
> Jens,
>
> On Mar 3, 2014, at 3:35 PM, Jens Oehlschlägel <
> jens.oehlschlae...@truecluster.com> wrote:
>
> >
> > Well, I did read, for example "Writing R Extensions" (Version 3.1.0
> Under development (2014-02-28)) chapter "5.9.10 Named object
Jens,
On Mar 3, 2014, at 3:35 PM, Jens Oehlschlägel
wrote:
> Thanks for answering Simon,
>
> > None, there is no concept of "shared" memory at R level. You seem to be
> > mixing C level API specifics and the R language. In the former duplicate()
> > creates a new copy.
>
> I take this as ev
Thanks for answering Simon,
> None, there is no concept of "shared" memory at R level. You seem to
be mixing C level API specifics and the R language. In the former
duplicate() creates a new copy.
I take this as evidence that calling duplicate() is the only way to make
sure I have a non-shar
On Mar 2, 2014, at 12:37 PM, Jens Oehlschlägel
wrote:
> Dear core group,
>
> Which operation in R guarantees to get a true copy of an atomic vector, not
> just a second symbol pointing to the same shared memory?
>
None, there is no concept of "shared" memory at R level. You seem to be mixin
Dear core group,
Which operation in R guarantees to get a true copy of an atomic vector,
not just a second symbol pointing to the same shared memory?
y <- x[]
#?
y <- x
y[1] <- y[1]
#?
Is there any function that returns its argument as a non-shared atomic
but only copies if the argument was
