search for: dataptr

...\ --with-blas \ --with-lapack \ --with-readline \ --with-tcl-config=/usr/lib/tcl8.6/tclConfig.sh \ --with-tk-config=/usr/lib/tk8.6/tkConfig.sh make ---<--------------------cut here---------------end--------------------->--- the build shows several warnings about function dataptr: ---<--------------------cut here---------------start------------------->--- radixsort.c:1643:10: warning: implicit declaration of function ?DATAPTR? [-Wimplicit-function-declaration] xd = DATAPTR(x); ^ radixsort.c:1643:8: warning: assignment makes pointer from integer without...

...int i, ns, nt; nt = LENGTH(t); ns = LENGTH(s); switch (TYPEOF(s)) { ... case INTSXP: for (i = 0; i < ns; i++) INTEGER(s)[i] = INTEGER(t)[i % nt]; break; ... could that be replaced with : case INTSXP: for (i=0; i<ns/nt; i++) memcpy((char *)DATAPTR(s)+i*nt*sizeof(int), (char *)DATAPTR(t), nt*sizeof(int)); break; and similar for the other types in copyVector. This won't help regular vector copies, since those seem to be done by the DUPLICATE_ATOMIC_VECTOR macro, see next suggestion below, but it should help copyMatrix which calls...

...roposing is not about changing the internal representation, but rather about how we design and use the ALTREP API. I might do not state the workarounds clearly as English is not my first language. Please let me explain them again in detail. 1. Update the existing R functions. When the ALTREP API Dataptr_or_null returns NULL, use get_element instead(or as best as we can). I have seen this pattern for some R functions, but somehow there are still some functions left that do not follow this rule. For example, print function will blindly call Dataptr (It even did not call Dataptr_or_null first) and fo...

Hello from Bioconductor, I'm developing a package to share R objects across clusters using boost library. The concept is similar to mmap package: https://cran.r-project.org/web/packages/mmap/index.html . However, I have a problem when I was trying to write Dataptr_method for the alternative string. Based on my understanding, the return value of the Dataptr_method function should be a vector of CHARSXP pointers. This design might be problematic in two ways: 1. The behavior of Dataptr_method function is inconsistent for string and the other ALTREP types. For...

...... and I turn those off. | --with-readline \ | --with-tcl-config=/usr/lib/tcl8.6/tclConfig.sh \ | --with-tk-config=/usr/lib/tk8.6/tkConfig.sh | make | ---<--------------------cut here---------------end--------------------->--- | | the build shows several warnings about function dataptr: | | ---<--------------------cut here---------------start------------------->--- | radixsort.c:1643:10: warning: implicit declaration of function ?DATAPTR? [-Wimplicit-function-declaration] | xd = DATAPTR(x); | ^ | radixsort.c:1643:8: warning: assignment makes pointer from int...

...\ --with-blas \ --with-lapack \ --with-readline \ --with-tcl-config=/usr/lib/tcl8.6/tclConfig.sh \ --with-tk-config=/usr/lib/tk8.6/tkConfig.sh make ---<--------------------cut here---------------end--------------------->--- the build shows several warnings about function dataptr: ---<--------------------cut here---------------start------------------->--- radixsort.c:1643:10: warning: implicit declaration of function ?DATAPTR? [-Wimplicit-function-declaration] xd = DATAPTR(x); ^ radixsort.c:1643:8: warning: assignment makes pointer from integer without...

Sorry to ask about a bit drifted topic, but will there be an alternative API to DATAPTR? > DATAPTR is not in the API and can't be at least in this form I believe it's vital for ALTREP to return the pointer to the expanded version of a SEXP just like the implementation in base R does [1]. At least, VECSXP has no other measure to expose the pointer if I understand correctly...

...39;t have a super-simple example to show > you at the moment. The closest is this example by Mikael Jagan: > https://github.com/lme4/lme4/issues/794#issuecomment-2155093049 > > which shows that if x is a pointer to a zero-length vector (in plain C++ > for R, no Rcpp is involved), DATAPTR(x) and REAL(x) evaluate to different > values. > > Mikael further points out that "Rcpp seems to cast a (void *) returned by > DATAPTR to (double *) when constructing a Vector<REALSXP> from a SEXP, rather > than using the (double *) returned by REAL." So perhaps R...

...ing the internal representation, but rather > about how we design and use the ALTREP API. > > I might do not state the workarounds clearly as English is not my first > language. Please let me explain them again in detail. > > 1. Update the existing R functions. When the ALTREP API Dataptr_or_null > returns NULL, use get_element instead(or as best as we can). I have seen > this pattern for some R functions, but somehow there are still some > functions left that do not follow this rule. For example, print function > will blindly call Dataptr (It even did not call Dataptr_o...

...following IR example: define void @simple([4 x double] *%ptr, i64 %idx) { %stack = alloca [4 x double] %ptri8 = bitcast [4 x double] *%ptr to i8* %stacki8 = bitcast [4 x double] *%stack to i8* call void @llvm.memcpy.p0i8.p0i8.i32(i8 *%stacki8, i8 *%ptri8, i32 32, i32 0, i1 0) %dataptr = getelementptr inbounds [4 x double], [4 x double] *%ptr, i32 0, i64 %idx store double 0.0, double *%dataptr call void @llvm.memcpy.p0i8.p0i8.i32(i8 *%ptri8, i8 *%stacki8, i32 32, i32 0, i1 0) ret void } I would like to see this optimized to just a single store (into %ptr). Right now...

Experimenting with altrep objects and v3 serialization, I discovered a possible bug. Calling DATAPTR on a compact_intseq object returns a pointer to the expanded integer sequence in memory. If you modify this data, the object values appear to be changed. However, if the compact_intseq object is then serialized (with version=3), only the original integer sequence info is written. For example, su...

...what you're describing may be true, this is simply how R handles character vector (what you're calling string) values internally. It doesn't actually have anything to do with ALTREP. Standard character vector SEXPs have an array of CHARSXP pointers in their payload (what is returned by DATAPTR) as well. As far as I know, this is important for string caching and is actually intended to save memory when the same string value appears many times in an R session (and takes up more bytes than a pointer), though I haven't dug around R's low-level string handling a ton. Either way thou...

...at this point; I don't have a super-simple example to show you at the moment. The closest is this example by Mikael Jagan: https://github.com/lme4/lme4/issues/794#issuecomment-2155093049 which shows that if x is a pointer to a zero-length vector (in plain C++ for R, no Rcpp is involved), DATAPTR(x) and REAL(x) evaluate to different values. Mikael further points out that "Rcpp seems to cast a (void *) returned by DATAPTR to (double *) when constructing a Vector<REALSXP> from a SEXP, rather than using the (double *) returned by REAL." So perhaps R-core doesn't wan...

Hi, I am curious about whether there exist thread-safe functions in `Rinternals.h`. I know that R is single-threaded designed, but for the simple and straightforward functions like `DATAPTR` and `INTEGER_GET_REGION`, are these functions safe to call in a multi-thread environment? Best, Jiefei [[alternative HTML version deleted]]

Jiefei, Beyond the general response that Luke gave, to be a bit more specific to what you said, DATAPTR and INTEGER_GET_REGION involve ALTREP method execution (for ALTREP objects, obviously) so even they are not as simple and straightforward as they were a couple years ago. They should not (any longer) be thought of as being guaranteed to be essentially bare metal data retrieval from memory. Best, ~...

...Thanks Luke. ~G On Wed, Jul 24, 2019 at 8:25 AM Tierney, Luke <luke-tierney at uiowa.edu> wrote: > If one of you wanted to try to create a patch to support ALTREP > generic vectors here are some notes: > > The main challenge I am aware of (there might be others): Allowing > DATAPTR to return a writable pointer would be too dangerous because > the GC write barrier needs to see all mutations. So it would be best > if Dataptr and Dataptr_or_null methods were not allowed to be > defined. The default methods in altrep.c should do the right think. > > A reasonable na...

...R-build/src/library/tools' installing 'sysdata.rda' ASAN:SIGSEGV ================================================================= ==3543==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000043b2f2 bp 0x7ffeb5fdc670 sp 0x7ffeb5fdc660 T0) #0 0x43b2f1 in ALTVEC_DATAPTR ../../../R-svn/src/main/altrep.c:305 #1 0x6b1068 in DATAPTR ../../../R-svn/src/include/Rinlinedfuns.h:105 #2 0x6b1068 in GetNewPage ../../../R-svn/src/main/memory.c:908 #3 0x6b5284 in Rf_allocVector3 ../../../R-svn/src/main/memory.c:2514 #4 0x654a49 in Rf_allocVector ../../../R-svn/...

...atEx.nAvgBytesPerSec = 8000; int quality =8; speex_bits_init(&bits); enc_state = speex_encoder_init(&speex_nb_mode); speex_encoder_ctl(enc_state, SPEEX_SET_QUALITY, &quality); In my recording callback function LRESULT RecordSound::OnSoundData(WPARAM wParam, LPARAM lParam) { .... dataPtr = (char *)lpHdr ->lpData; dataSize = (int)lpHdr ->dwBytesRecorded; for(int k=0;k<FRAME_SIZE;k++) input[k] = dataPtr[k]; //input is float[FRAME_SIZE] speex_bits_reset(&bits); speex_encode(enc_state, input, &bits); encByte = speex_bits_write(&amp...

...e GC. Right now I'm allocating via allocVector and copying all the data in it. However, this requires twice the amount of space (and time), and we're running out of memory when doing concurrent analysis. What I'd would like to do is: - "patch" the SEXP returned to R so that DATAPTR() points directly to the required address. - create a normal LISTSXP in the package, which holds a reference to all these objects, so that GC never takes place. - turn these objects read-only, or, at least, ensure that they are never free()d or remalloc()ed. overwriting the contents is not...

quite some speed improvement indeed. attached the updated patch to apply to svn/trunk. j -------------- next part -------------- A non-text attachment was scrubbed... Name: theora-mmx.patch.gz Type: application/x-gzip Size: 8648 bytes Desc: not available Url : http://lists.xiph.org/pipermail/theora-dev/attachments/20040824/5a5f2731/theora-mmx.patch-0001.bin