[Rd] Questions regarding ALTREP_SET_ELT APIs
Hi all, I'm wondering if there is any way to define a `SET_ELT` function for an ALTREP class? I see there are ` ALTINTEGER_SET_ELT` etc. functions exported in Rinternal.h, but there is no corresponding ALTREP APIs to define them. The only way to set the value of an ALTREP is through a pointer, which will require that the ALTREP data is in memory. Is it on purpose? Will there be any plan to develop these ALTREP set element APIs? Best, Jiefei [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Questions regarding ALTREP_SET_ELT APIs
Hi Luke, Thanks for your quick response. I appreciate your help. Best, Jiefei On Tue, Jul 30, 2019 at 12:41 PM Tierney, Luke wrote: > On Tue, 30 Jul 2019, Wang Jiefei wrote: > > > Hi all, > > > > I'm wondering if there is any way to define a `SET_ELT` function for an > > ALTREP class? I see there are ` ALTINTEGER_SET_ELT` etc. functions > exported > > in Rinternal.h, but there is no corresponding ALTREP APIs to define them. > > The only way to set the value of an ALTREP is through a pointer, which > will > > require that the ALTREP data is in memory. Is it on purpose? > > For now, yes. We do support a Set_elt method for ALTSTRING classes but > not yet for others. I seem to recall that there are some issues with > going there for others, but we'll probably take a closer look later > this year. > > One thing to keep in mind is that the R pass-by-value semantics > require that C code duplicate an object for which MAYBE_REFERENCED is > true, and the assumption in existing code is that duplicate returns an > object that can safely be mutated. That places a lot of limitations on > what can be done. You can see some notes on the issues in the > README.md and the vignette in > https://github.com/ALTREP-examples/Rpkg-mutable. > > Best, > > luke > > > Will there be > > any plan to develop these ALTREP set element APIs? > > > > Best, > > Jiefei > > > > [[alternative HTML version deleted]] > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Luke Tierney > Ralph E. Wareham Professor of Mathematical Sciences > University of Iowa Phone: 319-335-3386 > Department of Statistics andFax: 319-335-3017 > Actuarial Science > 241 Schaeffer Hall email: luke-tier...@uiowa.edu > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] ALTREP package interaction with testthat
Hi
I found a weird problem in testthat while working with an ALTREP package.
The package name is AltWrapper. My ALTREP serialize function is called even
when I'm trying to serialize a non-ALTREP object. Here is an example
```
context("altrep")
length_func<-function(x){
return(length(x))
}
setAltClass(className = "test", classType = "real")
setAltMethod(className = "test", getLength = length_func)
testData = runif(10)
myAltrep = makeAltrep("test", testData)
test_that("Auto serialize", {
browser()
A = 10
A_serialized=serialize(A,NULL)
B = new.env()
B_serialized=serialize(B,NULL)
})
```
There is nothing but two variables A and B in the test function. I use
browser() to stop and debug the code. Here is the weird thing, my package
function is called when I’m trying to serialize *A* and *B*:
```
Browse[1]> A = 10
Browse[1]> A_serialized=serialize(A,NULL)
Browse[1]> B = new.env()
Browse[1]> B_serialized=serialize(B,NULL)
serializing data
Auto serializing data
[1] "Internal serialize altWrapper function"
```
The output indicates that my package function is called. The function is
designed for an ALTREP object. Since *B* is not an ALTREP, I don’t
understand why the ALTREP related function has been called. Also, variable
A works find. It seems like R dispatches the serialize function according
to the variable type, but I am not sure if there is any way to see the
dispatching rules. Here are the things I have tried:
1. if I comment out the code that defines an ALTREP in my example, the bug
will disappear, so it might relate to the implementation of ALTREP.
2. If I run the test script in the global environment, R wouldn’t call the
internal function, it only happens when I call `devtools::test()`.
I am stuck here. I do not know if it is a bug of my package or testthat or
the ALTREP implementation of R or possibly the interaction between them. I
will appreciate if anyone can shed light on it. Here is the link to my
package test file:
https://github.com/Jiefei-Wang/AltWrapper/blob/master/tests/testthat/test_test.R
Best,
Jiefei
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] What is the best way to loop over an ALTREP vector?
Hi devel team, I'm working on C/C++ level ALTREP compatibility for a package. The package previously used pointers to access the data of a SEXP, so it would not work for some ALTREP objects which do not have a pointer. I plan to rewrite the code and use functions like get_elt, get_region, and get_subset to access the values of a vector, so I have a few questions for ALTREP: 1. Since an ALTREP do not have to define all of the above functions(element, region, subset), is there any way to check which function has been defined for an ALTREP class? I did a search on RInternal.h and altrep.c but did not find a solution for it. If not, will it be added in the future? 2. Given the diversity of ALTREP classes, what is the best way to loop over an ALTREP object? I hope there can be an all-in-one function which can get the values from a vector as long as at least one of the above functions has been defined, so package developers would not be bothered by tons of `if-else` statement if they want their package to work with ALTREP. Since it seems like there is no such function exist, what could be the best way to do the loop under the current R version? Best, Jiefei [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [ALTREP] What is the meaning of the return value of Is_sorted and No_NA function?
Hi,
I've found the answers to my questions:
1. For sort function, here are some macros defined in Rinternal.h:
/* ALTREP sorting support */
enum {SORTED_DECR_NA_1ST = -2,
SORTED_DECR = -1,
UNKNOWN_SORTEDNESS = INT_MIN, /*INT_MIN is NA_INTEGER! */
SORTED_INCR = 1,
SORTED_INCR_NA_1ST = 2,
KNOWN_UNSORTED = 0};
The macro names are pretty self-explanatory. The current implementation
only supports the ascending sort.
2. For anyNA, it goes to(Real SEXP)
===coerce.c===
if(REAL_NO_NA(x))
return FALSE;
ITERATE_BY_REGION(x, xD, i, nbatch, double, REAL, {
for (int k = 0; k < nbatch; k++)
if (ISNAN(xD[k]))
return TRUE;
});
===altrep.c===
int REAL_NO_NA(SEXP x)
{
return ALTREP(x) ? ALTREAL_DISPATCH(No_NA, x) : 0;
}
If the argument x is not an ALTREP, the function will return 0, and a
default method will be used, so there is no way to return true without loop
over the argument x right now. I hope this could be changed in the future.
Best,
Jiefei
On Tue, Sep 3, 2019 at 2:49 PM Wang Jiefei wrote:
> Hi,
>
>
>
> I would like to figure out the meaning of the return value of these two
> functions. Here are the default definitions I find from R source code:
>
>
>
> static int altreal_Is_sorted_default(SEXP x) { return UNKNOWN_SORTEDNESS;
> }
>
> static int altreal_No_NA_default(SEXP x) { return 0; }
>
> I guess the macro *UNKNOWN_SORTEDNESS *in *Is_sorted* and 0 in *No_NA *simply
> means
> unknown sorted/NA status of the vector, so R will loop over the vector and
> find the answer. However, what should we return in these functions to
> indicate whether the vector has been sorted/ contains NA? My initial guess
> is 0/1 but since *NA_NA *uses 0 as its default value so it will be
> ambiguous. Are there any macros to define yes/no return values for these
> functions? I would appreciate any thought here.
>
>
>
> Best,
>
> Jiefei
>
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [ALTREP] What is the meaning of the return value of Is_sorted and No_NA function?
Hi,
I would like to figure out the meaning of the return value of these two
functions. Here are the default definitions I find from R source code:
static int altreal_Is_sorted_default(SEXP x) { return UNKNOWN_SORTEDNESS; }
static int altreal_No_NA_default(SEXP x) { return 0; }
I guess the macro *UNKNOWN_SORTEDNESS *in *Is_sorted* and 0 in *No_NA
*simply means
unknown sorted/NA status of the vector, so R will loop over the vector and
find the answer. However, what should we return in these functions to
indicate whether the vector has been sorted/ contains NA? My initial guess
is 0/1 but since *NA_NA *uses 0 as its default value so it will be
ambiguous. Are there any macros to define yes/no return values for these
functions? I would appreciate any thought here.
Best,
Jiefei
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [ALTREP] What is the meaning of the return value of Is_sorted and No_NA function?
Hi Gabriel,
Thanks for your answer and future update plan. Somehow this email has been
delayed for a week, so there might be a wired reply from me saying that I
have found the answer from the R source code, it was sent from me last
week. Hopefully, this reply will not cost another week to post:)
As a side note, I like the idea that defining a macro for sortedness, and I
can see why we can only have a binary answer for NO_NA (since the return
value is actually bool). For making the code more readable, and for
possibly working with the future R release, is it possible to define a
macro for NO_NA function in RInternal.h? So if there is any change in NO_NA
function, there is no need to modify the code. Also, the code can be more
readable by doing that.
Best,
Jiefei
On Wed, Sep 11, 2019 at 1:58 PM Gabriel Becker
wrote:
> Hi Jiefei,
>
> The meanings of the return values for sortedness can be found in
> RInternals.h, and are as follows:
>
> /* ALTREP sorting support */
> enum {SORTED_DECR_NA_1ST = -2,
> SORTED_DECR = -1,
> UNKNOWN_SORTEDNESS = INT_MIN, /*INT_MIN is NA_INTEGER! */
> SORTED_INCR = 1,
> SORTED_INCR_NA_1ST = 2,
> KNOWN_UNSORTED = 0};
>
> The default value there is NA_INTEGER (ie INT_MIN), indicating that there
> is no sortedness information.
>
> Currently, *_NO_NA effectively return a boolean, (even though the actual
> return value is int). This can be seen in the method we provide for compact
> sequences in altclasses.c:
>
>
> static int compact_intseq_No_NA(SEXP x)
> {
> #ifdef COMPACT_INTSEQ_MUTABLE
> /* If the vector has been expanded it may have been modified. */
> if (COMPACT_SEQ_EXPANDED(x) != R_NilValue)
> return FALSE;
> #endif
> return TRUE;
> }
>
> (FALSE is a macro for 0, TRUE is a macro for 1).
>
> Think of the meaning of the return value to No_NA methods as the object's
> answer to the following question
>
> "Are you sure there are zero NAs in your data?"
>
> When it is sure of that, it says "yes" (returning 1, ie TRUE). When it
> either is sure there are NAs *OR* doesn't have any information about
> whether there are NAs, it says "no" (returning 0, ie FALSE).
>
> Also please note, it is possible there may be another API point in the
> future which asks the object *how many NAs it has.∫ˆ* If that
> materializes, No_NA would just consume the answer to thatto get the
> binarized version, but again there is nothing like that in there now.
>
> Hope that helps.
>
> Best,
> ~G
>
> On Wed, Sep 11, 2019 at 12:04 AM Wang Jiefei wrote:
>
>> Hi,
>>
>>
>>
>> I would like to figure out the meaning of the return value of these two
>> functions. Here are the default definitions I find from R source code:
>>
>>
>>
>> static int altreal_Is_sorted_default(SEXP x) { return UNKNOWN_SORTEDNESS;
>> }
>>
>> static int altreal_No_NA_default(SEXP x) { return 0; }
>>
>> I guess the macro *UNKNOWN_SORTEDNESS *in *Is_sorted* and 0 in *No_NA
>> *simply means
>> unknown sorted/NA status of the vector, so R will loop over the vector and
>> find the answer. However, what should we return in these functions to
>> indicate whether the vector has been sorted/ contains NA? My initial guess
>> is 0/1 but since *NA_NA *uses 0 as its default value so it will be
>> ambiguous. Are there any macros to define yes/no return values for these
>> functions? I would appreciate any thought here.
>>
>>
>>
>> Best,
>>
>> Jiefei
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] What is the best way to loop over an ALTREP vector?
Hi Gabriel,
I have tried the macro and found a small issue, it seems like the macro is
written in C and does an implicit type conversion(const void * to const int
*), see below. While it is allowed in C, C++ seems not happy with it. Is it
possible to add an explicit type casting so that it can be compatible with
both language?
#define ITERATE_BY_REGION_PARTIAL(sx, px, idx, nb, etype, vtype, \
strt, nfull, expr) do { \
*const etype *px = (const** etype *)DATAPTR_OR_NULL(sx); *
\
if (px != NULL) { \
R_xlen_t __ibr_n__ = strt + nfull;\
R_xlen_t nb = __ibr_n__; \
for (R_xlen_t idx = strt; idx < __ibr_n__; idx += nb) { \
expr\
} \
} \
else ITERATE_BY_REGION_PARTIAL0(sx, px, idx, nb, etype, vtype,
\
strt, nfull, expr);\
} while (0)
Also, I notice that the element type(etype) and vector type(vtype) has to
be specified in the macro. Since the SEXP is the first argument in the
macro, it seems redundant to define etype and vtype for they have to match
the type of the SEXP. I'm wondering if this is intentional? Will there be a
type-free macro in R in the future? Here is a simple type-free macro I'm
using.
#define type_free_iter(sx, ptr, ind, nbatch,expr)\
switch(TYPEOF(sx)){\
case INTSXP:\
ITERATE_BY_REGION(sx, ptr, ind, nbatch, int, INTEGER, expr);\
break; \
case REALSXP:\
ITERATE_BY_REGION(sx, ptr, ind, nbatch, double, REAL, expr);\
break; \
case LGLSXP:\
ITERATE_BY_REGION(sx, ptr, ind, nbatch, int, LOGICAL, expr);\
break; \
default:\
Rf_error("Unknow data type\n"); \
break; \
}
// [[Rcpp::export]]
double sillysum(SEXP x) {
double s = 0.0;
type_free_iter(x, ptr, ind, nbatch,
{
for (int i = 0; i < nbatch; i++) { s = s + ptr[i]; }
});
return s;
}
Best,
Jiefei
On Wed, Aug 28, 2019 at 2:32 PM Wang Jiefei wrote:
> Thank you, Gabriel. The loop macro is very helpful. It is also exciting to
> see that there are lots of changes in ALTREP in R devel version. I really
> appreciate your help!
>
> Best,
> Jiefei
>
> On Wed, Aug 28, 2019 at 7:37 AM Gabriel Becker
> wrote:
>
>> Jiefei,
>>
>> I've been meaning to write up something about this so hopefully this will
>> be an impetus for me to actually do that, but until then, responses inline.
>>
>>
>> On Tue, Aug 27, 2019, 7:22 PM Wang Jiefei wrote:
>>
>>> Hi devel team,
>>>
>>> I'm working on C/C++ level ALTREP compatibility for a package. The
>>> package
>>> previously used pointers to access the data of a SEXP, so it would not
>>> work
>>> for some ALTREP objects which do not have a pointer. I plan to rewrite
>>> the
>>> code and use functions like get_elt, get_region, and get_subset to access
>>> the values of a vector, so I have a few questions for ALTREP:
>>>
>>> 1. Since an ALTREP do not have to define all of the above
>>> functions(element, region, subset), is there any way to check which
>>> function has been defined for an ALTREP class? I did a search on
>>> RInternal.h and altrep.c but did not find a solution for it. If not, will
>>> it be added in the future?
>>>
>>
>> Element and region are guaranteed to always be defined and work (for
>> altrep and non-altrep INTSXP, REALSXP, LGLSXPs, etc, we currently don't
>> have region for STRSXP or VECSXP, I believe). If the altrep class does not
>> provide them then default methods will be used, which may be inefficient in
>> some cases but will work. Subset is currently a forward looking stub, but
>> once implimented, that will also be guaranteed to work for all valid ALTREP
>> classes.
>>
>>
>>>
>>> 2. Given the diversity of ALTREP classes, what is the best way to loop
>>> over
>>> an ALTREP object? I hope there can be an all-in-one function which can
>>> get
>>> the values from a vector as long as at least one of the above functions
>>> has
>>> been defined, so package developers would not be bothered by tons of
>>> `if-else` statement if they want their package to work with ALTREP. Since
>>> it seems like there is no such function exist, what could be the best way
>>> to do the loop under the curre
Re: [Rd] What is the best way to loop over an ALTREP vector?
Sorry for post a lot of things, for the first part of code, I copied my C++
iter macro by mistake(and you can see an explicit type casting). Here is
the macro definition from R_exts/Itermacros.h
#define ITERATE_BY_REGION_PARTIAL(sx, px, idx, nb, etype, vtype, \
strt, nfull, expr) do { \
* const** etype *px = DATAPTR_OR_NULL(sx); * \
if (px != NULL) { \
R_xlen_t __ibr_n__ = strt + nfull;\
R_xlen_t nb = __ibr_n__; \
for (R_xlen_t idx = strt; idx < __ibr_n__; idx += nb) { \
expr\
} \
} \
else ITERATE_BY_REGION_PARTIAL0(sx, px, idx, nb, etype, vtype,
\
strt, nfull, expr);\
} while (0)
Best,
Jiefei
On Mon, Sep 23, 2019 at 3:12 PM Wang Jiefei wrote:
> Hi Gabriel,
>
> I have tried the macro and found a small issue, it seems like the macro is
> written in C and does an implicit type conversion(const void * to const int
> *), see below. While it is allowed in C, C++ seems not happy with it. Is it
> possible to add an explicit type casting so that it can be compatible with
> both language?
>
>
> #define ITERATE_BY_REGION_PARTIAL(sx, px, idx, nb, etype, vtype, \
>
> strt, nfull, expr) do { \
>
>*const etype *px = (const** etype *)DATAPTR_OR_NULL(sx); *
> \
>
>if (px != NULL) { \
>
>R_xlen_t __ibr_n__ = strt + nfull;\
>
>R_xlen_t nb = __ibr_n__; \
>
>for (R_xlen_t idx = strt; idx < __ibr_n__; idx += nb) { \
>
> expr\
>
> } \
>
>} \
>
>else ITERATE_BY_REGION_PARTIAL0(sx, px, idx, nb, etype,
> vtype, \
>
>strt, nfull, expr);\
>
> } while (0)
>
>
> Also, I notice that the element type(etype) and vector type(vtype) has
> to be specified in the macro. Since the SEXP is the first argument in the
> macro, it seems redundant to define etype and vtype for they have to match
> the type of the SEXP. I'm wondering if this is intentional? Will there be a
> type-free macro in R in the future? Here is a simple type-free macro I'm
> using.
>
> #define type_free_iter(sx, ptr, ind, nbatch,expr)\
>
> switch(TYPEOF(sx)){\
>
> case INTSXP:\
>
>ITERATE_BY_REGION(sx, ptr, ind, nbatch, int, INTEGER, expr);\
>
>break; \
>
> case REALSXP:\
>
>ITERATE_BY_REGION(sx, ptr, ind, nbatch, double, REAL, expr);\
>
>break; \
>
> case LGLSXP:\
>
>ITERATE_BY_REGION(sx, ptr, ind, nbatch, int, LOGICAL, expr);\
>
>break; \
>
> default:\
>
>Rf_error("Unknow data type\n"); \
>
>break; \
>
> }
>
>
>
> // [[Rcpp::export]]
>
> double sillysum(SEXP x) {
>
>double s = 0.0;
>
>type_free_iter(x, ptr, ind, nbatch,
>
> {
>
> for (int i = 0; i < nbatch; i++) { s = s + ptr[i]; }
>
> });
>
> return s;
>
> }
>
>
>
>
> Best,
>
> Jiefei
>
> On Wed, Aug 28, 2019 at 2:32 PM Wang Jiefei wrote:
>
>> Thank you, Gabriel. The loop macro is very helpful. It is also exciting
>> to see that there are lots of changes in ALTREP in R devel version. I
>> really appreciate your help!
>>
>> Best,
>> Jiefei
>>
>> On Wed, Aug 28, 2019 at 7:37 AM Gabriel Becker
>> wrote:
>>
>>> Jiefei,
>>>
>>> I've been meaning to write up something about this so hopefully this
>>> will be an impetus for me to actually do that, but until then, responses
>>> inline.
>>>
>>>
>>> On Tue, Aug 27, 2019, 7:22 PM Wang Jiefei wrote:
>>>
>>>> Hi devel team,
>>>>
>>>> I'm working on C/C++ level ALTREP compatibility for a package. The
>>>> package
>>>> previously used pointers to access the data of a SEXP, so it would not
>>>> work
>>>> for some ALTREP objects which do not have a pointer. I plan to rewrite
>>>> the
>>>&
Re: [Rd] New matrix function
Hi Morgan, I think there is a discussion on how developers include a function in base R in another thread: https://stat.ethz.ch/pipermail/r-devel/2019-October/078551.html Best, Jiefei On Fri, Oct 11, 2019 at 8:19 AM Morgan Morgan wrote: > On Fri, 11 Oct 2019 10:45 Duncan Murdoch, > wrote: > > > On 11/10/2019 6:44 a.m., Morgan Morgan wrote: > > > Hi All, > > > > > > I was looking for a function to find a small matrix inside a larger > > matrix > > > in R similar to the one described in the following link: > > > > > > > > > https://www.mathworks.com/matlabcentral/answers/194708-index-a-small-matrix-in-a-larger-matrix > > > > > > I couldn't find anything. > > > > > > The above function can be seen as a "generalisation" of the "which" > > > function as well as the function described in the following post: > > > > > > > > > https://coolbutuseless.github.io/2018/04/03/finding-a-length-n-needle-in-a-haystack/ > > > > > > Would be possible to add such a function to base R? > > > > > > I am happy to work with someone from the R core team (if you wish) and > > > suggest an implementation in C. > > > > That seems like it would sometimes be a useful function, and maybe > > someone will point out a package that already contains it. But if not, > > why would it belong in base R? > > > > If someone already implemented it, that would great indeed. I think it is a > very general and basic function, hence base R could be a good place for it? > > But this is probably not a good reason; maybe someone from the R core team > can shed some light on how they decide whether or not to include a function > in base R? > > > > Duncan Murdoch > > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4SXP type vs S4 object bit?
Hi Travers, Just an additional remarks to Michael's answer, if your S4 class inherits from R's basic types, say integer, the resulting object will be an INTSXP. If your S4 class does not inherit from any class, it will be an S4SXP. You can think about this question from the object-oriented framework: If one class inherits the integer class, what should R do to make all the integer related functions compatible with the new class at C level? Best, Jiefei On Tue, Oct 22, 2019 at 4:28 AM Travers Ching wrote: > I'm trying to understand the R internals a bit better and reading over the > documentation. > > I see that there is a bit related to whether an object is S4 > (S4_OBJECT_MASK), and also the object type S4SXP (25). The documentation > makes clear that these two things aren't the same. > > But in practice, will the S4-bit and object type ever disagree for S4 > objects? I know that one can set the bit manually in C; are there any > practical applications for doing so? > > Thank you > Travers > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Unexpected behavior when using macro to loop over vector
Hi all,
I found an unexpected behavior when I was trying to use the macro defined
in "R_ext/Itermacros.h" to loop over an atomic vector. Here is a minimum
example:
C++ code
```
#include "R_ext/Itermacros.h"
#define GET_REGION_BUFSIZE 2
//Redefine the macro since C++ is not happy with the implicit type
conversion
#define ITERATE_BY_REGION_PARTIAL(sx, px, idx, nb, etype, vtype, \
strt, nfull, expr) do { \
const etype *px = (etype*)DATAPTR_OR_NULL(sx); \
if (px != NULL) { \
R_xlen_t __ibr_n__ = strt + nfull; \
R_xlen_t nb = __ibr_n__; \
for (R_xlen_t idx = strt; idx < __ibr_n__; idx += nb) { \
expr \
} \
} \
else ITERATE_BY_REGION_PARTIAL0(sx, px, idx, nb, etype, vtype, \
strt, nfull, expr); \
} while (0)
// [[Rcpp::export]]
void C_testPrint(SEXP x) {
ITERATE_BY_REGION_PARTIAL(x, ptr, idx, nbatch, double, REAL, 1, 4, {
for (R_xlen_t i = 0; i < nbatch; i++)
Rprintf("idx: %lld, i: %lld, ptr:%f\n", idx, i, ptr[i]);
});
}
```
The function C_testPrint loops over its argument x and prints out one value
of x at each loop. The loop starts from the second element and ends in the
fifth element of x. I also redefine the buffer size to see the effect of
it. Here is my R code:
R code
```
> C_testPrint(as.numeric(1:10))
idx: 1, i: 0, ptr:2.00
idx: 1, i: 1, ptr:3.00
idx: 3, i: 0, ptr:4.00
idx: 3, i: 1, ptr:5.00
> C_testPrint(c(1,2,3,4,5,6,7,8,9,10))
idx: 1, i: 0, ptr:1.00
idx: 1, i: 1, ptr:2.00
idx: 1, i: 2, ptr:3.00
idx: 1, i: 3, ptr:4.00
idx: 1, i: 4, ptr:5.00
```
There are two problems in the outputs:
1. The numbers of lines are different
2. The starting indices are not the same.
>From my understanding, the first output seems correct to me. The second is
not unexpected. I believe the differences are due to the accessibility of
the data pointer. Did I misunderstand and misuse the macro? Or is it a bug
in R? Here is my session info. My R is a bit outdated but the macro seems
unchanged in R 4.0. Thanks
```
> sessionInfo()
R Under development (unstable) (2019-08-22 r77060)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)
```
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected behavior when using macro to loop over vector
Thank you, Tomas. I appreciate your help. BTW, could you also add an
explicit type conversion in " ITERATE_BY_REGION_PARTIAL" macro while you
are fixing the bug? C++ compiler does not happy with the implicit
conversion from void* to T* somehow and I have to redefine it before using
the macro.
Best,
Jiefei
On Fri, Oct 25, 2019 at 11:13 AM Tomas Kalibera
wrote:
> On 10/25/19 11:01 AM, Tomas Kalibera wrote:
> > On 10/23/19 6:45 AM, Wang Jiefei wrote:
> >> Hi all,
> >>
> >> I found an unexpected behavior when I was trying to use the macro
> >> defined
> >> in "R_ext/Itermacros.h" to loop over an atomic vector. Here is a
> >> minimum
> >> example:
> >>
> >> C++ code
> >> ```
> >> #include "R_ext/Itermacros.h"
> >> #define GET_REGION_BUFSIZE 2
> >> //Redefine the macro since C++ is not happy with the implicit type
> >> conversion
> >> #define ITERATE_BY_REGION_PARTIAL(sx, px, idx, nb, etype, vtype, \
> >> strt, nfull, expr) do { \
> >> const etype *px = (etype*)DATAPTR_OR_NULL(sx); \
> >> if (px != NULL) { \
> >> R_xlen_t __ibr_n__ = strt + nfull; \
> >> R_xlen_t nb = __ibr_n__; \
> >> for (R_xlen_t idx = strt; idx < __ibr_n__; idx += nb) { \
> >> expr \
> >> } \
> >> } \
> >> else ITERATE_BY_REGION_PARTIAL0(sx, px, idx, nb, etype, vtype, \
> >> strt, nfull, expr); \
> >> } while (0)
> >> // [[Rcpp::export]]
> >> void C_testPrint(SEXP x) {
> >> ITERATE_BY_REGION_PARTIAL(x, ptr, idx, nbatch, double, REAL, 1, 4, {
> >> for (R_xlen_t i = 0; i < nbatch; i++)
> >> Rprintf("idx: %lld, i: %lld, ptr:%f\n", idx, i, ptr[i]);
> >
> > You need to index "ptr" by "idx + i", not by "i". Have a look at how
> > the macros are used in R, e.g. printvector.c.
>
> Actually, the macro should do this for you, we will investigate/fix.
> Thanks for the report!
>
> Best
> Tomas
>
> >
> > Best,
> > Tomas
> >
> >> });
> >> }
> >> ```
> >>
> >> The function C_testPrint loops over its argument x and prints out one
> >> value
> >> of x at each loop. The loop starts from the second element and ends
> >> in the
> >> fifth element of x. I also redefine the buffer size to see the effect of
> >> it. Here is my R code:
> >>
> >> R code
> >> ```
> >>> C_testPrint(as.numeric(1:10))
> >> idx: 1, i: 0, ptr:2.00
> >> idx: 1, i: 1, ptr:3.00
> >> idx: 3, i: 0, ptr:4.00
> >> idx: 3, i: 1, ptr:5.00
> >>> C_testPrint(c(1,2,3,4,5,6,7,8,9,10))
> >> idx: 1, i: 0, ptr:1.00
> >> idx: 1, i: 1, ptr:2.00
> >> idx: 1, i: 2, ptr:3.00
> >> idx: 1, i: 3, ptr:4.00
> >> idx: 1, i: 4, ptr:5.00
> >> ```
> >>
> >> There are two problems in the outputs:
> >> 1. The numbers of lines are different
> >> 2. The starting indices are not the same.
> >>
> >> From my understanding, the first output seems correct to me. The
> >> second is
> >> not unexpected. I believe the differences are due to the
> >> accessibility of
> >> the data pointer. Did I misunderstand and misuse the macro? Or is it
> >> a bug
> >> in R? Here is my session info. My R is a bit outdated but the macro
> >> seems
> >> unchanged in R 4.0. Thanks
> >>
> >> ```
> >>> sessionInfo()
> >> R Under development (unstable) (2019-08-22 r77060)
> >> Platform: x86_64-w64-mingw32/x64 (64-bit)
> >> Running under: Windows >= 8 x64 (build 9200)
> >> ```
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Questions on the R C API
Hi Morgan,
My solutions might not be the best one(I believe it's not), but it should
work for your question.
1. Have you considered Rf_duplicate function? If you want to change the
value of `a` and reset it later, you have to have a duplication somewhere
for resetting it. Instead of changing the value of `a` directly, why not
changing the value of a duplicated `a`? So you do not have to reset it.
2. I think a pairlist behaves like a linked list(I might be wrong here and
please correct me if so). Therefore, there is no simple way to locate an
element in a pairlist. As for as I know, R defines a set of
convenient functions for you to access a limited number of elements. See
below
```
#define CAR(e) ((e)->u.listsxp.carval)
#define CDR(e) ((e)->u.listsxp.cdrval)
#define CAAR(e) CAR(CAR(e))
#define CDAR(e) CDR(CAR(e))
#define CADR(e) CAR(CDR(e))
#define CDDR(e) CDR(CDR(e))
#define CDDDR(e) CDR(CDR(CDR(e)))
#define CADDR(e) CAR(CDR(CDR(e)))
#define CADDDR(e) CAR(CDR(CDR(CDR(e
#define CAD4R(e) CAR(CDR(CDR(CDR(CDR(e)
```
You can use them to get first a few arguments from a pairlist. Another
solution would be converting the pairlist into a list so that you can use
the methods defined for a list to access any element. I do not know which C
function can achieve that but `as.list` at R level should be able to do
this job, you can evaluate an R function at C level and get the list
result( By calling `Rf_eval`). I think this operation is relatively low
cost because the list should only contain a set of pointers pointing to
each element. There is no object duplication(Again I might be wrong here).
3. You can get unevaluated expression at the R level before you call the C
function and pass it to your C function( by calling `substitute` function).
However, from my vague memory, the expression would be eventually evaluated
at the C level even you pass the expression to it. Therefore, I think you
can create a list of unevaluated arguments before you enter the C function,
so your C function can expect a list rather than a pairlist as its
argument. This can solve both your second and third questions.
Best,
Jiefei
On Mon, Nov 4, 2019 at 2:41 PM Morgan Morgan
wrote:
> Hi All,
>
> I have some questions regarding the R C API.
>
> Let's assume I have a function which is defined as follows:
>
> R file:
>
> myfunc <- function(a, b, ...) .External(Cfun, a, b, ...)
>
> C file:
>
> SEXP Cfun(SEXP args) {
> args = CDR(args);
> SEXP a = CAR(args); args = CDR(args);
> SEXP b = CAR(args); args = CDR(args);
> /* continue to do something with remaining arguments in "..." using the
> same logic as above*/
>
> return R_NilValue;
> }
>
> 1/ Let's suppose that in my c function I change the value of a inside the
> function but I want to reset it to what it was when I did SEXP a =
> CAR(args); . How can I do that?
>
> 2/Is there a method to set "args" at a specific position so I can access a
> specific value of my choice? If yes, do you have an simple example?
>
> 3/ Let's suppose now, I call the function in R. Is there a way to avoid the
> function to evaluate its arguments before going to the C call? Do I have to
> do it at the R level or can it be done at the C level?
>
> Thank you very much in advance.
> Best regards
> Morgan
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] What should dnorm(0, 0, -Inf) return?
Good question, I cannot speak for R's developers but I would like to
provide some information on the problem. Here are the first few lines of
the dnorm function located at src\nmath\dnorm.c:
```
double dnorm4(double x, double mu, double sigma, int give_log)
{
#ifdef IEEE_754
if (ISNAN(x) || ISNAN(mu) || ISNAN(sigma))
return x + mu + sigma;
#endif
if(!R_FINITE(sigma)) return R_D__0;
if(!R_FINITE(x) && mu == x) return ML_NAN;/* x-mu is NaN */
if (sigma <= 0) {
if (sigma < 0) ML_ERR_return_NAN;
/* sigma == 0 */
return (x == mu) ? ML_POSINF : R_D__0;
}
}
```
You can clearly see where the problem is. I think either the document or
the code needs a modification.
Best,
Jiefei
On Sat, Dec 7, 2019 at 5:05 PM Weigand, Stephen D. via R-devel <
r-devel@r-project.org> wrote:
> Hi,
> Apropos of a recent Inf question, I've previously wondered if dnorm "does
> the right thing" with
>
> dnorm(0, 0, -Inf)
>
> which gives zero. Should that be zero or NaN (or NA)?
>
> The help says "'sd < 0' is an error and returns 'NaN'" and since -Inf < 0
> is TRUE, then... is this a bug?
>
> Thank you,
> Stephen
> Rochester, MN USA
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD INSTALL cannot recognize full path on Windows
Hi all,
Here is a bug(or feature?) that exists at least from R 2020-02-24
r77852 to 2020-03-09 r77919 on Window. Consider this example makefile in a
package
```
*test1=$(shell echo 'runif(3)'|R --vanilla --slave)test2=$(shell echo
'runif(3)'|"C:/Program Files/R/R-devel/bin/R" --vanilla
--slave)test3=$(shell echo 'runif(3)'|"C:/PROGRA~1/R/R-devel/bin/R"
--vanilla --slave)$(info test1 is $(test1))$(info test2 is $(test2))$(info
test3 is $(test3))*
```
I have no problem running the file using GUN make or installing the package
on R 3.6, both give the same result.
```
*C:\Rtools\mingw_64\bin\mingw32-make.exe *
*test1 is [1] 0.3427626 0.8027041 0.5611914test2 is [1] 0.9904205 0.3922129
0.5970083test3 is [1] 0.3469528 0.1993838 0.8434841mingw32-make: *** No
targets. Stop.*
*```*
However, on the devel version of R, it cannot recognize both the full and
short path of R and gives an error
```
*test1 is [1] 0.42686376 0.84126831 0.09538047The filename, directory
name, or volume label syntax is incorrect.test2 isThe filename, directory
name, or volume label syntax is incorrect.test3 is*
```
I found this issue because my package needs to call R functions in the
makefile. The code is similar to:
```
* myvar = $(shell echo 'runif(3)'|"${R_HOME}/bin/R" --vanilla --slave)*
```
Since *R_HOME *is set to *C:/PROGRA~1/R/R-devel/*, this will result in the
same error as I mentioned above. I do not know whether this is intentional.
If so, what is the correct way to call R function in a makefile?
Best,
Jiefei
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD INSTALL cannot recognize full path on Windows
Oops, I think both of us forget to cite the r-devel channel.
Best,
Jiefei
On Tue, Mar 10, 2020 at 5:13 AM Wang Jiefei wrote:
> Thanks for your quick response, Tomas.
>
> Yes, this is a path issue, I think the problem is related to R, not the
> Rtools make. I built an example package for reproducing the problem:
> https://github.com/Jiefei-Wang/example
>
> Here is the version of my R and Rtools:
> The release R version:
> R version 3.6.2 (2019-12-12)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 10 x64 (build 18362)
>
> The devel R version:
> R Under development (unstable) (2020-03-09 r77919)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 10 x64 (build 18362)
>
> Rtools version 3.5.0.4
>
> Things become interesting after I did more tests. I originally thought
> this might be only related to the devel R, but it seems like the released
> version is also affected. Here is a summary of my test results using the
> example package:
>
> 1. command-line Rtools make: Success
> 2. command-line R CMD INSTALL: Failed on both R3.6.2 and R4.0
> 3. Rstudio install button: Success on R3.6.2 but failed on R4.0
> 4. Rstudio running devtool::install: Success on both
>
> Now the problem becomes more intricate. I have no idea which one goes
> wrong. Here are the details of my test results, I hope it can be helpful:
>
> *Command line:*
> 1. "C:\Rtools\mingw_64\bin\mingw32-make.exe" -f example-master/src/Makevars
> test1 is [1] 0.2039269 0.1454402 0.1578401
> test2 is [1] 0.1919521 0.9257183 0.2130247
> test3 is [1] 0.06255174 0.27555363 0.72737111
> mingw32-make: *** No targets. Stop.
>
> 2. "C:\Program Files\R\R-3.6.2\bin\R" CMD INSTALL testPackage_1.0.tar.gz
> *** arch - x64
> test1 is [1] 0.1584299 0.9338829 0.9528810
> The filename, directory name, or volume label syntax is incorrect.
> test2 is
> The filename, directory name, or volume label syntax is incorrect.
> test3 is
>
> 3. "C:\Program Files\R\R-devel\bin\R" CMD INSTALL testPackage_1.0.tar.gz
> *** arch - x64
> test1 is [1] 0.2668522 0.9246174 0.0184601
> The filename, directory name, or volume label syntax is incorrect.
> test2 is
> The filename, directory name, or volume label syntax is incorrect.
> test3 is
>
> *R studio:*
> 1. R3.6: Clicking the install button
> ==> Rcmd.exe INSTALL --no-multiarch --with-keep.source example-master
> * installing to library 'C:/Users/wangj/Documents/R/win-library/3.6'
> * installing *source* package 'testPackage' ...
> ** using staged installation
> ** libs
> test1 is [1] 0.1583112 0.6631700 0.2265564
> test2 is [1] 0.6999799 0.5205237 0.8264029
> test3 is [1] 0.3591798 0.1767392 0.2869383
>
> 2. R4.0: Clicking the install button
> Rcmd.exe INSTALL --no-multiarch --with-keep.source example-master
> * installing to library 'C:/Program Files/R/R-devel/library'
> * installing *source* package 'testPackage' ...
> ** using staged installation
> ** libs
> test1 is [1] 0.2091070 0.5411138 0.1051517
> The filename, directory name, or volume label syntax is incorrect.
> test2 is
> The filename, directory name, or volume label syntax is incorrect.
> test3 is
>
> 3. R3.6: devtools::load_all(".")
> devtools::load_all(".")
> Loading testPackage
> Re-compiling testPackage
> - installing *source* package 'testPackage' ... (364ms)
>** using staged installation
>** libs
>test1 is [1] 0.93251741 0.03975758 0.57824150
>test2 is [1] 0.8681301 0.4801464 0.9112827
>test3 is [1] 0.430470791 0.008393394 0.341484128
>test1 is [1] 0.68865768 0.05354531 0.91665539
>test2 is [1] 0.19473846 0.60293655 0.09421961
>test3 is [1] 0.90653581 0.12456034 0.09526018
>
> 4. R4.0: devtools::load_all(".")
> Loading testPackage
> Re-compiling testPackage
> ─ installing *source* package 'testPackage' ... (357ms)
>** using staged installation
>** libs
>test1 is [1] 0.00545376 0.30696231 0.68752312
>test2 is [1] 0.1059506 0.7506894 0.8607918
>test3 is [1] 0.5321226 0.6985332 0.7343680
>test1 is [1] 0.7722255 0.3881171 0.5611294
>test2 is [1] 0.5443175 0.8418503 0.3479382
>test3 is [1] 0.7400557 0.3322797 0.6818899
>
>
> Cheers,
> Jiefei
>
> On Tue, Mar 10, 2020 at 4:11 AM Tomas Kalibera
> wrote:
>
>> Hi Jiefei,
>>
>> thanks for your report, but I don't understand from you current
>> description what the problem is. Are you saying that "make" shipped with
>> some recent Rtools is not accepting some forms of PATHs? But, which
>> Rtools then, which vers
Re: [Rd] R CMD INSTALL cannot recognize full path on Windows
Thanks, Tomas. I took your suggestion and change the make file to test1:=$(shell $(R_HOME)/bin/R --slave -e 'runif(3)') all: testPackage.dll echo "test1 is $(test1)" echo "R_HOME is $(R_HOME)" However, R CMD INSTALL still gives me the same error: > R CMD INSTALL testPackage_1.0.tar.gz* installing to library 'C:/Program Files/R/R-devel/library' * installing *source* package 'testPackage' ... ** using staged installation ** libs *** arch - i386 The filename, directory name, or volume label syntax is incorrect. c:/Rtools/mingw_32/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-devel/include" -DNDEBUG -I'C:/Program Files/R/R-devel/library/Rcpp/include' -I"C:/projects/BUILD/R-source-win32/extsoft/include" -O2 -Wall -mfpmath=sse -msse2 -c RcppExports.cpp -o RcppExports.o c:/Rtools/mingw_32/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-devel/include" -DNDEBUG -I'C:/Program Files/R/R-devel/library/Rcpp/include' -I"C:/projects/BUILD/R-source-win32/extsoft/include" -O2 -Wall -mfpmath=sse -msse2 -c example.cpp -o example.o c:/Rtools/mingw_32/bin/g++ -std=gnu++11 -shared -s -static-libgcc -o testPackage.dll tmp.def RcppExports.o example.o -LC:/projects/BUILD/R-source-win32/extsoft/lib/i386 -LC:/projects/BUILD/R-source-win32/extsoft/lib -LC:/PROGRA~1/R/R-devel/bin/i386 -lR echo "test1 is " test1 is echo "R_HOME is C:/PROGRA~1/R/R-devel" installing to C:/Program Files/R/R-devel/library/00LOCK-testPackage/00new/testPackage/libs/i386 I have no idea how to make the example even more minimal for there is literally nothing in the package now. Like you said if R just sets R_HOME and runs "make", I do not understand why it cannot find R in this case for R_HOME seems correct to me. I think there are some other things behind R CMD INSTALL but my poor knowledge does not allow me to see them...Any help will be appreciated. Best, Jiefei On Wed, Mar 11, 2020 at 8:57 AM Tomas Kalibera wrote: > > Thanks, Jiefei, unfortunately your example does not work on my system, and > also it is far from minimal. The error message you are getting is from > Windows and could be caused for example by accidental quoting of the path > using single quotes. > > Issues with RStudio or devtools would have to be discussed in their > mailing lists/with their authors, but my guess is that the problem is in > your local configuration, and after all you need it to work with the base R > CMD INSTALL anyway. There is not much wrong R could do here, it just sets > R_HOME and runs "make". > > For example this works for me, but some closer alternations of your code > work as well: > > test1 := $(shell $(R_HOME)/bin/R --slave -e 'runif(3)') > all: > echo "test1 is $(test1)" > echo "R_HOME is $(R_HOME)" > > I would recommend that you try to narrow down your example so that it is > really minimal. Use R_HOME, not hard-coded paths, as that is what you would > use in reality anyway. Print R_HOME and check it is valid. If the problem > persists, find out why it works when invoked from the command line but not > from R CMD INSTALL. > > Best > Tomas > > On 3/10/20 10:15 AM, Wang Jiefei wrote: > > Oops, I think both of us forget to cite the r-devel channel. > > Best, > Jiefei > > On Tue, Mar 10, 2020 at 5:13 AM Wang Jiefei wrote: > >> Thanks for your quick response, Tomas. >> >> Yes, this is a path issue, I think the problem is related to R, not the >> Rtools make. I built an example package for reproducing the problem: >> https://github.com/Jiefei-Wang/example >> >> Here is the version of my R and Rtools: >> The release R version: >> R version 3.6.2 (2019-12-12) >> Platform: x86_64-w64-mingw32/x64 (64-bit) >> Running under: Windows 10 x64 (build 18362) >> >> The devel R version: >> R Under development (unstable) (2020-03-09 r77919) >> Platform: x86_64-w64-mingw32/x64 (64-bit) >> Running under: Windows 10 x64 (build 18362) >> >> Rtools version 3.5.0.4 >> >> Things become interesting after I did more tests. I originally thought >> this might be only related to the devel R, but it seems like the released >> version is also affected. Here is a summary of my test results using the >> example package: >> >> 1. command-line Rtools make: Success >> 2. command-line R CMD INSTALL: Failed on both R3.6.2 and R4.0 >> 3. Rstudio install button: Success on R3.6.2 but failed on R4.0 >> 4. Rstudio running devtool::install: Success on both >> >> Now the problem becomes more intricate. I have no idea which one goes >> wrong. Here are the details of my test results, I hope
Re: [Rd] R CMD INSTALL cannot recognize full path on Windows
Thanks a lot for your suggestions. I see what you mean. I have removed all unnecessary files and dependences on https://github.com/Jiefei-Wang/example, but still no luck. I've tried to install the package as a user, not admin, but I got the same error. Also, I apologize for spamming the mail list. I will keep my reply as neat as possible. Martin has suggested checking the encoding of the file and locale in the session info, so here is this missing information: The makefile is encoded in UTF-8, and the locale is: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 That is where I am stuck, any help would be appreciated. Best, Jiefei On Wed, Mar 11, 2020 at 9:56 AM Tomas Kalibera wrote: > On 3/11/20 2:26 PM, Wang Jiefei wrote: > > Thanks, Tomas. I took your suggestion and change the make file to > > test1:=$(shell $(R_HOME)/bin/R --slave -e 'runif(3)') > > all: testPackage.dll > echo "test1 is $(test1)" > echo "R_HOME is $(R_HOME)" > > However, R CMD INSTALL still gives me the same error: > > > R CMD INSTALL testPackage_1.0.tar.gz* installing to library 'C:/Program > Files/R/R-devel/library' > * installing *source* package 'testPackage' ... > ** using staged installation > ** libs > > *** arch - i386 > The filename, directory name, or volume label syntax is incorrect. > c:/Rtools/mingw_32/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-devel/include" > -DNDEBUG -I'C:/Program Files/R/R-devel/library/Rcpp/include' > -I"C:/projects/BUILD/R-source-win32/extsoft/include" -O2 -Wall > -mfpmath=sse -msse2 -c RcppExports.cpp -o RcppExports.o > c:/Rtools/mingw_32/bin/g++ -std=gnu++11 -I"C:/PROGRA~1/R/R-devel/include" > -DNDEBUG -I'C:/Program Files/R/R-devel/library/Rcpp/include' > -I"C:/projects/BUILD/R-source-win32/extsoft/include" -O2 -Wall > -mfpmath=sse -msse2 -c example.cpp -o example.o > c:/Rtools/mingw_32/bin/g++ -std=gnu++11 -shared -s -static-libgcc -o > testPackage.dll tmp.def RcppExports.o example.o > -LC:/projects/BUILD/R-source-win32/extsoft/lib/i386 > -LC:/projects/BUILD/R-source-win32/extsoft/lib > -LC:/PROGRA~1/R/R-devel/bin/i386 -lR > echo "test1 is " > test1 is > echo "R_HOME is C:/PROGRA~1/R/R-devel" > installing to C:/Program > Files/R/R-devel/library/00LOCK-testPackage/00new/testPackage/libs/i386 > > > I have no idea how to make the example even more minimal for there is > literally nothing in the package now. Like you said if R just sets R_HOME > and runs "make", I do not understand why it cannot find R in this case for > R_HOME seems correct to me. I think there are some other things behind R > CMD INSTALL but my poor knowledge does not allow me to see them...Any help > will be appreciated. > > Please lets not spam the whole list with this any more - this is also why > I didn't add R-devel to cc originally. The makefile may be minimal, but the > example package is not - you have Rcpp dependency there, two C source > files, some R Studio specific thing (an .Rproj file at least). Maybe it is > not related, but if you want other to help you, it would be nice to spend > some of your time reducing it anyway. > > That test1 is empty means that executing R has failed. You need to find > out why. > > I see that you are installing into C:/Program Files/R/R-devel/library. > Normally that directory should not be writeable. Are you running this as > Administrator? In principle this could be related, but better to find out > directly why executing R is failing. > > Best > Tomas > > > > > Best, > Jiefei > > > On Wed, Mar 11, 2020 at 8:57 AM Tomas Kalibera > wrote: > >> >> Thanks, Jiefei, unfortunately your example does not work on my system, >> and also it is far from minimal. The error message you are getting is from >> Windows and could be caused for example by accidental quoting of the path >> using single quotes. >> >> Issues with RStudio or devtools would have to be discussed in their >> mailing lists/with their authors, but my guess is that the problem is in >> your local configuration, and after all you need it to work with the base R >> CMD INSTALL anyway. There is not much wrong R could do here, it just sets >> R_HOME and runs "make". >> >> For example this works for me, but some closer alternations of your code >> work as well: >> >> test1 := $(shell $(R_HOME)/bin/R --slave -e 'runif(3)') >> all: >> echo "test1 is $(test1)" >
Re: [Rd] R CMD INSTALL cannot recognize full path on Windows
Thanks for your test result Simon, I really appreciate it. I borrowed a new laptop and found the issue is only reproducible on my machine, so there is something not in R or the package that causes this problem. I will stop chattering and try to figure out where the problem is. Thanks again for your time and help! Cheers, Jiefei On Wed, Mar 11, 2020 at 6:22 PM Simon Urbanek wrote: > Jiefei, > > you did not commit all files into the example package - your example has > things like RcppExports.cpp as well as additional flags which are not in > your GH project. I suspect the issue is with the extra flags you're adding > - those don't come from R. Please make sure you can replicate the issue > with the GH package you created. > > Cheers, > Simon > > > * installing *source* package 'testPackage' ... > ** using staged installation > ** libs > > *** arch - i386 > echo "test1 is [1] 0.1522111 0.2533619 0.6591809" > test1 is [1] 0.1522111 0.2533619 0.6591809 > echo "R_HOME is C:/R/R-3.6.2" > R_HOME is C:/R/R-3.6.2 > echo "Fake library" > testPackage.dll > installing to > C:/R/R-3.6.2/library/00LOCK-testPackage/00new/testPackage/libs/i38 > 6 > > *** arch - x64 > echo "test1 is [1] 0.9271811 0.8040735 0.4739104" > test1 is [1] 0.9271811 0.8040735 0.4739104 > echo "R_HOME is C:/R/R-3.6.2" > R_HOME is C:/R/R-3.6.2 > echo "Fake library" > testPackage.dll > installing to > C:/R/R-3.6.2/library/00LOCK-testPackage/00new/testPackage/libs/x64 > > ** help > No man pages found in package 'testPackage' > *** installing help indices > ** building package indices > ** testing if installed package can be loaded from temporary location > *** arch - i386 > *** arch - x64 > ** testing if installed package can be loaded from final location > *** arch - i386 > *** arch - x64 > ** testing if installed package keeps a record of temporary installation > path > * DONE (testPackage) > Making 'packages.html' ... done > > > On 12/03/2020, at 4:33 AM, Wang Jiefei wrote: > > > > Thanks a lot for your suggestions. I see what you mean. I have removed > all > > unnecessary files and dependences on > https://github.com/Jiefei-Wang/example, > > but still no luck. I've tried to install the package as a user, not > admin, > > but I got the same error. Also, I apologize for spamming the mail list. I > > will keep my reply as neat as possible. > > > > Martin has suggested checking the encoding of the file and locale in the > > session info, so here is this missing information: The makefile is > encoded > > in UTF-8, and the locale is: > > > > [1] LC_COLLATE=English_United States.1252 > > [2] LC_CTYPE=English_United States.1252 > > [3] LC_MONETARY=English_United States.1252 > > [4] LC_NUMERIC=C > > [5] LC_TIME=English_United States.1252 > > > > That is where I am stuck, any help would be appreciated. > > > > Best, > > Jiefei > > > > > > > > On Wed, Mar 11, 2020 at 9:56 AM Tomas Kalibera > > > wrote: > > > >> On 3/11/20 2:26 PM, Wang Jiefei wrote: > >> > >> Thanks, Tomas. I took your suggestion and change the make file to > >> > >> test1:=$(shell $(R_HOME)/bin/R --slave -e 'runif(3)') > >> > >> all: testPackage.dll > >>echo "test1 is $(test1)" > >>echo "R_HOME is $(R_HOME)" > >> > >> However, R CMD INSTALL still gives me the same error: > >> > >>> R CMD INSTALL testPackage_1.0.tar.gz* installing to library 'C:/Program > >> Files/R/R-devel/library' > >> * installing *source* package 'testPackage' ... > >> ** using staged installation > >> ** libs > >> > >> *** arch - i386 > >> The filename, directory name, or volume label syntax is incorrect. > >> c:/Rtools/mingw_32/bin/g++ -std=gnu++11 > -I"C:/PROGRA~1/R/R-devel/include" > >> -DNDEBUG -I'C:/Program Files/R/R-devel/library/Rcpp/include' > >> -I"C:/projects/BUILD/R-source-win32/extsoft/include" -O2 -Wall > >> -mfpmath=sse -msse2 -c RcppExports.cpp -o RcppExports.o > >> c:/Rtools/mingw_32/bin/g++ -std=gnu++11 > -I"C:/PROGRA~1/R/R-devel/include" > >> -DNDEBUG -I'C:/Program Files/R/R-devel/library/Rcpp/include' > >> -I"C:/projects/BUILD/R-source-win32/extsoft/include" -O2 -Wall > >> -mfpmath=sse -msse2 -c example.cpp -o example.o > >> c:/Rtools/mingw_32/bin/g++ -std=gnu++11 -s
[Rd] Inconsistant result for normalizePath on Windows
Hi all,
I saw a quite surprising result in the devel R when using the function
*normalizePath*. If the input is a path to a folder, the function returns
an absolute path with/without a slash at the end depending on the existence
of the folder. I know both results are valid on Windows but this behavior
is different than R3.6, I do not know if the change in the devel version is
made on purpose. Here is a minimal example, suppose that the folder
`C:/windows1/` does not exist.
> normalizePath("C:/windows/", mustWork = FALSE)
[1] "C:\\Windows"
> normalizePath("C:/windows1/", mustWork = FALSE)
[1] "C:\\windows1\\"
In R 3.6, the return value always ends with a slash if the input ends with
a slash. From the NEWS file, It seems like there are some changes to
*normalizePath* but none of them should be relevant, it might be an
unintentional result introduced by the update.
Best,
Jiefei
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] The finalizer of the externalPtr does not work when closing R?
Hi all, I found that the finalizer of the externalPtr is not called when R is quitting. However, manually calling GC() works fine. This behavior is observed on devel R 2020-04-02 r78142 on Win and R 3.6.3 on Ubuntu. I make a reproducible package here: https://github.com/Jiefei-Wang/example Here is the detail of how to reproduce the problem, I create a temporary file in the package root path and make an external pointer. The finalizer of the external pointer will delete the temporary file when it is called. In the first round, I manually remove the external pointer from the global environment and call GC() to verify if the finalizer is programmed properly. The temporary file is deleted successfully. Then I create the file and the pointer again and close the R session without saving the global environment. Since the external pointer is removed when closing R, so the finalizer should be called in this procedure. However, the temp file still exists after closing the R session. Here is the test code(which can be found in inst/example/example.R) ## Create a temporary file tmpFile <- paste0(system.file(package = "testPackage"), "/tmp") tmpFile file.create(tmpFile) file.exists(tmpFile) ## Create an external pointer whose finalizer will delete ## the file when the variable is not in used x <- testPackage:::makeExtPtr(file.remove,tmpFile) ## GC is working fine rm(list="x") gc() file.exists(tmpFile) ## Create the temporary file again file.create(tmpFile) file.exists(tmpFile) x <- testPackage:::makeExtPtr(file.remove,tmpFile) ## Quit R session without explicitly cleaning the working space quit(save = "no") ##=Open a new R session=== ## The temporary file still exist tmpFile <- paste0(system.file(package = "testPackage"), "/tmp") file.exists(tmpFile) Not sure if this behavior is designed on purpose, but it sounds wired to me and can cause memory leaking if not properly handled. Best, Jiefei [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] The finalizer of the externalPtr does not work when closing R?
Thanks for all your guys responses! It is amazing to get so many answers in a few minutes! My package needs to handle the shared memory so the finalizer does cause memory leaking. The Ex version should be my solution for that. Thanks for all your help. Best Jiefei On Fri, Apr 3, 2020, 9:14 PM wrote: > Use R_RegisterFinalizerEx in your C code. See > > > https://cran.r-project.org/doc/manuals/r-release/R-exts.html#External-pointers-and-weak-references > > This still gives you only "best effort"; for anything stronger you > would need a different approach. > > In general, finalizers should only be used as a backstop, not as a > primary resource management tool (in R or any other garbage-collected > language). > > Memory leaks are not an issue -- unless you are doing very unusual > things your OS will reclaim memory resources used by your process when > it exits, cleanly or otherwise. > > Best, > > luke > > On Fri, 3 Apr 2020, Wang Jiefei wrote: > > > Hi all, > > > > I found that the finalizer of the externalPtr is not called when R is > > quitting. However, manually calling GC() works fine. This behavior is > > observed on devel R 2020-04-02 r78142 on Win and R 3.6.3 on Ubuntu. I > make > > a reproducible package here: https://github.com/Jiefei-Wang/example > > > > Here is the detail of how to reproduce the problem, I create a temporary > > file in the package root path and make an external pointer. The finalizer > > of the external pointer will delete the temporary file when it is > called. > > In the first round, I manually remove the external pointer from the > global > > environment and call GC() to verify if the finalizer is programmed > > properly. The temporary file is deleted successfully. Then I create the > > file and the pointer again and close the R session without saving the > > global environment. Since the external pointer is removed when closing R, > > so the finalizer should be called in this procedure. However, the temp > file > > still exists after closing the R session. > > > > Here is the test code(which can be found in inst/example/example.R) > > > > ## Create a temporary file > > tmpFile <- paste0(system.file(package = "testPackage"), "/tmp") > > tmpFile > > file.create(tmpFile) > > file.exists(tmpFile) > > ## Create an external pointer whose finalizer will delete > > ## the file when the variable is not in used > > x <- testPackage:::makeExtPtr(file.remove,tmpFile) > > ## GC is working fine > > rm(list="x") > > gc() > > file.exists(tmpFile) > > > > ## Create the temporary file again > > file.create(tmpFile) > > file.exists(tmpFile) > > x <- testPackage:::makeExtPtr(file.remove,tmpFile) > > ## Quit R session without explicitly cleaning the working space > > quit(save = "no") > > > > > > ##=Open a new R session=== > > ## The temporary file still exist > > tmpFile <- paste0(system.file(package = "testPackage"), "/tmp") > > file.exists(tmpFile) > > > > Not sure if this behavior is designed on purpose, but it sounds wired to > me > > and can cause memory leaking if not properly handled. > > > > Best, > > Jiefei > > > > [[alternative HTML version deleted]] > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Luke Tierney > Ralph E. Wareham Professor of Mathematical Sciences > University of Iowa Phone: 319-335-3386 > Department of Statistics andFax: 319-335-3017 > Actuarial Science > 241 Schaeffer Hall email: luke-tier...@uiowa.edu > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
