Re: [Rd] Build a R call at C level
Sorry Dirk, I don't remember discussing this topic or alternatives with you at all. Have a nice day. On Tue, 30 Jun 2020, 14:42 Morgan Morgan, wrote: > Thanks Jan and Tomas for the feedback. > Answer from Jan is what I am looking for. > Maybe I am not looking in the right place buy it is not easy to understand > how these LCONS, CONS, SETCDR...etc works. > > Thank you > Best regards > Morgan > > > > On Tue, 30 Jun 2020, 12:36 Tomas Kalibera, > wrote: > >> On 6/30/20 1:06 PM, Jan Gorecki wrote: >> > It is quite known that R documentation on R C api could be improved... >> >> Please see "5.11 Evaluating R expressions from C" from "Writing R >> Extensions" >> >> Best >> Tomas >> >> > Still R-package-devel mailing list should be preferred for this kind >> > of questions. >> > Not sure if that is the best way, but works. >> > >> > call_to_sum <- inline::cfunction( >> >language = "C", >> >sig = c(x = "SEXP"), body = " >> > >> > SEXP e = PROTECT(lang2(install(\"sum\"), x)); >> > SEXP r_true = PROTECT(CONS(ScalarLogical(1), R_NilValue)); >> > SETCDR(CDR(e), r_true); >> > SET_TAG(CDDR(e), install(\"na.rm\")); >> > Rf_PrintValue(e); >> > SEXP ans = PROTECT(eval(e, R_GlobalEnv)); >> > UNPROTECT(3); >> > return ans; >> > >> > ") >> > >> > call_to_sum(c(1L,NA,3L)) >> > >> > On Tue, Jun 30, 2020 at 10:08 AM Morgan Morgan >> > wrote: >> >> Hi All, >> >> >> >> I was reading the R extension manual section 5.11 ( Evaluating R >> expression >> >> from C) and I tried to build a simple call to the sum function. Please >> see >> >> below. >> >> >> >> call_to_sum <- inline::cfunction( >> >>language = "C", >> >>sig = c(x = "SEXP"), body = " >> >> >> >> SEXP e = PROTECT(lang2(install(\"sum\"), x)); >> >> SEXP ans = PROTECT(eval(e, R_GlobalEnv)); >> >> UNPROTECT(2); >> >> return ans; >> >> >> >> ") >> >> >> >> call_to_sum(1:3) >> >> >> >> The above works. My question is how do I add the argument "na.rm=TRUE" >> at C >> >> level to the above call? I have tried various things based on what is >> in >> >> section 5.11 but I did not manage to get it to work. >> >> >> >> Thank you >> >> Best regards >> >> >> >> [[alternative HTML version deleted]] >> >> >> >> __ >> >> R-devel@r-project.org mailing list >> >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > __ >> > 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] `basename` and `dirname` change the encoding to "UTF-8"
Hello, everyone, thank you for your quick and helpful responses and the detailed information. Sorry for not providing a reproducible example for the (potential) bug in `tools::makeLazyLoadDB`. The main point of my mail was the surprising behaviour of `basename` and `dirname`. Fixing those functions would probably solve my problem for me (as a workaround, probably hiding some underlying problem, and likely leading to a failure for someone else fighting with encodings). Concerning my underlying direct problem with `tools::makeLazyLoadDB`, I'm having difficulty to make my example reproducible. I'm trying to use a directory with a non-ASCII-name for a knitr cache. My R-4.0.0 here behaves different from my R-3.6.3, but when I filed a bug report with knitr, Yihui could not reproduce this difference (https://github.com/yihui/knitr/issues/1840). So I'll try R-4.0.2 next, let's see what happens. Cheers Johannes > Gesendet: Dienstag, 30. Juni 2020 um 09:25 Uhr > Von: "Tomas Kalibera" > An: "Johannes Rauh" , "r-devel" > Betreff: Re: [Rd] `basename` and `dirname` change the encoding to "UTF-8" > > On 6/29/20 4:39 PM, Johannes Rauh wrote: > > Dear R Developers, > > > > I noticed that `basename` and `dirname` always return "UTF-8" on Windows > > (tested with R-4.0.0 and R-3.6.3): > > > >> p <- "Föö/Bär" > >> Encoding(p) > > [1] "latin1" > >> Encoding(dirname(p)) > > [1] "UTF-8" > >> Encoding(basename(p)) > > [1] "UTF-8" > > > > Is this on purpose? At least I did not find any relevant comment in the > > documentation of `dirname`/`basename`. > > Background: I'm currently struggeling with a directory name containing a > > latin1-character. (I know that this is a bad idea, but I did not create > > the directory and I cannot rename it.) I now want to pass a > > latin1-directory name to a function, which internally uses > > `tools::makeLazyLoadDB`. At that point, internally, `dirname` is called, > > which changes the encoding, and things break. If I use `debug` to halt the > > processing and "fix" the encoding, things work as expected. > > > > So, if possible, I would prefer that `dirname` and `basename` preserve the > > encoding. > > Please try to always submit a minimal reproducible example with your > reports and test with at least the latest released version of R, ideally > also with R-devel. > > As you have not sent a reproducible example, it is hard to tell for > sure, but most likely as Kevin wrote you have run into a real bug, which > was however already fixed in 4.0.2 and in R-devel (17833). The lazy > loading cache did not work with file names in non-native encoding. > > That real bug has been uncovered by legitimate and correct changes like > the ones you report, where file operations started returning non-ASCII > strings in UTF-8. Historically in R such functions would instead return > native strings with misrepresented characters, and we were reluctant to > change that expecting waking bugs in code silently assuming native > encoding. Still, as people were increasingly running into problems with > non-representable characters, we did that change in several functions > anyway, and yes, it started waking up bugs. > > With some performance overhead and added complexity, we could be > returning preferentially results in native encoding, and in UTF-8 only > when they included non-representable characters. That would increase the > code complexity, increase performance overhead, but wake up existing > bugs with smaller probability. Note - some code that relied previously > on best-fit conversions done by Windows will have been broken anyway. We > would have to bypass win_iconv/iconv for that (adding more complexity). > Bugs in code not handling encodings properly would still be triggered > via non-representable characters. I've recently changed file.path() in > R-devel to be slightly more conservative again, along these lines. > > We can still do it more widely, but it is not high on the priority list. > The way to fix all of these problems is switching to UTF-8 as native > encoding on Windows and every day spent on tuning the existing behavior > postpones that real solution. > > Best > Tomas > > > > > > Best regards > > Johannes > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Bioc-devel] single package builder updates
Hello, We will be performing some updates on the single package builder for new submissions today June 30. There will be a period of downtime while we run the updates. During this time packages on the tracker will not receive automatic builds. We apologize for any inconvenience and appreciate your patience. Cheers, Lori Shepherd Bioconductor Core Team Roswell Park Comprehensive Cancer Center Department of Biostatistics & Bioinformatics Elm & Carlton Streets Buffalo, New York 14263 This email message may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for the delivery of this message to the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or use of this email message is prohibited. If you have received this message in error, please notify the sender immediately by e-mail and delete this email message from your computer. Thank you. [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] Build a R call at C level
On 30 June 2020 at 14:42, Morgan Morgan wrote: | Thanks Jan and Tomas for the feedback. | Answer from Jan is what I am looking for. | Maybe I am not looking in the right place buy it is not easy to understand | how these LCONS, CONS, SETCDR...etc works. a) There are alternatives, and if memory serves I already told you about them. b) This is quite likely the wrong list for your questions. Consider r-package-devel. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build a R call at C level
Thanks Jan and Tomas for the feedback. Answer from Jan is what I am looking for. Maybe I am not looking in the right place buy it is not easy to understand how these LCONS, CONS, SETCDR...etc works. Thank you Best regards Morgan On Tue, 30 Jun 2020, 12:36 Tomas Kalibera, wrote: > On 6/30/20 1:06 PM, Jan Gorecki wrote: > > It is quite known that R documentation on R C api could be improved... > > Please see "5.11 Evaluating R expressions from C" from "Writing R > Extensions" > > Best > Tomas > > > Still R-package-devel mailing list should be preferred for this kind > > of questions. > > Not sure if that is the best way, but works. > > > > call_to_sum <- inline::cfunction( > >language = "C", > >sig = c(x = "SEXP"), body = " > > > > SEXP e = PROTECT(lang2(install(\"sum\"), x)); > > SEXP r_true = PROTECT(CONS(ScalarLogical(1), R_NilValue)); > > SETCDR(CDR(e), r_true); > > SET_TAG(CDDR(e), install(\"na.rm\")); > > Rf_PrintValue(e); > > SEXP ans = PROTECT(eval(e, R_GlobalEnv)); > > UNPROTECT(3); > > return ans; > > > > ") > > > > call_to_sum(c(1L,NA,3L)) > > > > On Tue, Jun 30, 2020 at 10:08 AM Morgan Morgan > > wrote: > >> Hi All, > >> > >> I was reading the R extension manual section 5.11 ( Evaluating R > expression > >> from C) and I tried to build a simple call to the sum function. Please > see > >> below. > >> > >> call_to_sum <- inline::cfunction( > >>language = "C", > >>sig = c(x = "SEXP"), body = " > >> > >> SEXP e = PROTECT(lang2(install(\"sum\"), x)); > >> SEXP ans = PROTECT(eval(e, R_GlobalEnv)); > >> UNPROTECT(2); > >> return ans; > >> > >> ") > >> > >> call_to_sum(1:3) > >> > >> The above works. My question is how do I add the argument "na.rm=TRUE" > at C > >> level to the above call? I have tried various things based on what is in > >> section 5.11 but I did not manage to get it to work. > >> > >> Thank you > >> Best regards > >> > >> [[alternative HTML version deleted]] > >> > >> __ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > > __ > > 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] [External] Re: R-devel internal errors during check produce?
Thanks. Fixed in R-devel in r78754. This was related to a fix for
PR#17809, not the change to unique.default.
Best,
luke
On Tue, 30 Jun 2020, Jan Gorecki wrote:
No packages are being loaded, or even installed.
Did you try running the example on R-devel built with flags I have
provided in this email?
I checked now and it is required to use --enable-strict-barrier to
reproduce the issue.
On Tue, Jun 30, 2020 at 9:02 AM Martin Maechler
wrote:
Kurt Hornik
on Tue, 30 Jun 2020 06:20:57 +0200 writes:
Jan Gorecki writes:
>> Thank you both, You are absolutely correct that example
>> should be minimal, so here it is.
>> l = list(a=new.env(), b=new.env()) unique(l)
>> Just for completeness, env_list during check that raises
>> error
>> env_list <- list(baseenv(),
>> as.environment("package:graphics"),
>> as.environment("package:stats"),
>> as.environment("package:utils"),
>> as.environment("package:methods") )
>> unique(env_list)
> Thanks ... but the above work fine for me. E.g.,
R> l = list(a=new.env(), b=new.env())
R> unique(l)
> [[1]]
> [[2]]
> Best -k
Ditto here; also your (Jan) 2nd example works fine.
So, you must have loaded some (untidy) packages / code which redefine
standard base R behavior ?
Martin
__
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build a R call at C level
On 6/30/20 1:06 PM, Jan Gorecki wrote: It is quite known that R documentation on R C api could be improved... Please see "5.11 Evaluating R expressions from C" from "Writing R Extensions" Best Tomas Still R-package-devel mailing list should be preferred for this kind of questions. Not sure if that is the best way, but works. call_to_sum <- inline::cfunction( language = "C", sig = c(x = "SEXP"), body = " SEXP e = PROTECT(lang2(install(\"sum\"), x)); SEXP r_true = PROTECT(CONS(ScalarLogical(1), R_NilValue)); SETCDR(CDR(e), r_true); SET_TAG(CDDR(e), install(\"na.rm\")); Rf_PrintValue(e); SEXP ans = PROTECT(eval(e, R_GlobalEnv)); UNPROTECT(3); return ans; ") call_to_sum(c(1L,NA,3L)) On Tue, Jun 30, 2020 at 10:08 AM Morgan Morgan wrote: Hi All, I was reading the R extension manual section 5.11 ( Evaluating R expression from C) and I tried to build a simple call to the sum function. Please see below. call_to_sum <- inline::cfunction( language = "C", sig = c(x = "SEXP"), body = " SEXP e = PROTECT(lang2(install(\"sum\"), x)); SEXP ans = PROTECT(eval(e, R_GlobalEnv)); UNPROTECT(2); return ans; ") call_to_sum(1:3) The above works. My question is how do I add the argument "na.rm=TRUE" at C level to the above call? I have tried various things based on what is in section 5.11 but I did not manage to get it to work. Thank you Best regards [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Build a R call at C level
It is quite known that R documentation on R C api could be improved... Still R-package-devel mailing list should be preferred for this kind of questions. Not sure if that is the best way, but works. call_to_sum <- inline::cfunction( language = "C", sig = c(x = "SEXP"), body = " SEXP e = PROTECT(lang2(install(\"sum\"), x)); SEXP r_true = PROTECT(CONS(ScalarLogical(1), R_NilValue)); SETCDR(CDR(e), r_true); SET_TAG(CDDR(e), install(\"na.rm\")); Rf_PrintValue(e); SEXP ans = PROTECT(eval(e, R_GlobalEnv)); UNPROTECT(3); return ans; ") call_to_sum(c(1L,NA,3L)) On Tue, Jun 30, 2020 at 10:08 AM Morgan Morgan wrote: > > Hi All, > > I was reading the R extension manual section 5.11 ( Evaluating R expression > from C) and I tried to build a simple call to the sum function. Please see > below. > > call_to_sum <- inline::cfunction( > language = "C", > sig = c(x = "SEXP"), body = " > > SEXP e = PROTECT(lang2(install(\"sum\"), x)); > SEXP ans = PROTECT(eval(e, R_GlobalEnv)); > UNPROTECT(2); > return ans; > > ") > > call_to_sum(1:3) > > The above works. My question is how do I add the argument "na.rm=TRUE" at C > level to the above call? I have tried various things based on what is in > section 5.11 but I did not manage to get it to work. > > Thank you > Best regards > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel internal errors during check produce?
> Jan Gorecki
> on Tue, 30 Jun 2020 11:29:24 +0100 writes:
> No packages are being loaded, or even installed.
> Did you try running the example on R-devel built with flags I have
> provided in this email?
> I checked now and it is required to use --enable-strict-barrier to
> reproduce the issue.
No, I (and Kurt probably, too) had overlooked the extra flags
setting you'd used
Thank you and Deepayan for checking more there.
I now agree this is something we (R Core) should address one way
or the other.
Martin
> On Tue, Jun 30, 2020 at 9:02 AM Martin Maechler
> wrote:
>>
>> > Kurt Hornik
>> > on Tue, 30 Jun 2020 06:20:57 +0200 writes:
>>
>> > Jan Gorecki writes:
>> >> Thank you both, You are absolutely correct that example
>> >> should be minimal, so here it is.
>>
>> >> l = list(a=new.env(), b=new.env()) unique(l)
>>
>> >> Just for completeness, env_list during check that raises
>> >> error
>>
>> >> env_list <- list(baseenv(),
>> >> as.environment("package:graphics"),
>> >> as.environment("package:stats"),
>> >> as.environment("package:utils"),
>> >> as.environment("package:methods") )
>>
>> >> unique(env_list)
>>
>> > Thanks ... but the above work fine for me. E.g.,
>>
R> l = list(a=new.env(), b=new.env())
R> unique(l)
>> > [[1]]
>>
>> > [[2]]
>>
>> > Best -k
>>
>> Ditto here; also your (Jan) 2nd example works fine.
>>
>> So, you must have loaded some (untidy) packages / code which redefine
>> standard base R behavior ?
>>
>> Martin
>>
>>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-devel internal errors during check produce?
No packages are being loaded, or even installed.
Did you try running the example on R-devel built with flags I have
provided in this email?
I checked now and it is required to use --enable-strict-barrier to
reproduce the issue.
On Tue, Jun 30, 2020 at 9:02 AM Martin Maechler
wrote:
>
> > Kurt Hornik
> > on Tue, 30 Jun 2020 06:20:57 +0200 writes:
>
> > Jan Gorecki writes:
> >> Thank you both, You are absolutely correct that example
> >> should be minimal, so here it is.
>
> >> l = list(a=new.env(), b=new.env()) unique(l)
>
> >> Just for completeness, env_list during check that raises
> >> error
>
> >> env_list <- list(baseenv(),
> >> as.environment("package:graphics"),
> >> as.environment("package:stats"),
> >> as.environment("package:utils"),
> >> as.environment("package:methods") )
>
> >> unique(env_list)
>
> > Thanks ... but the above work fine for me. E.g.,
>
> R> l = list(a=new.env(), b=new.env())
> R> unique(l)
> > [[1]]
>
> > [[2]]
>
> > Best -k
>
> Ditto here; also your (Jan) 2nd example works fine.
>
> So, you must have loaded some (untidy) packages / code which redefine
> standard base R behavior ?
>
> Martin
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] data and load version 3
On 6/30/20 11:48 AM, Göran Broström wrote: On 2020-06-30 01:07, Jeff Newmiller wrote: Your choice. Do you want to support people using older versions of R, or not? Is that all? No point at all with version 3 in packages? Why was it introduced? I have seen an argument for version 2: "... needed ... to support name spaces", but version 3 ... Format 3 supports efficient serialization of ALTREP objects, that is why it was introduced. It also saves the session native encoding and converts string on de-serialization when running in different native encoding. Documented also in R 3.5 NEWS, in R Internals. Tomas Göran On June 29, 2020 1:55:02 PM PDT, "Göran Broström" wrote: I added two data sets (.rda) to my package eha, but when I build the new version I get: WARNING: Added dependency on R >= 3.5.0 because serialized objects in serialize/load version 3 cannot be read in older versions of R. File(s) containing such objects: ‘eha/data/swedeaths.rda’ ‘eha/data/swepop.rda’ In DESCRIPTION I have 'Depends: R (>= 3.0.0)' After googling for a while (found nothing relevant in 'WRE'), I understand that I have two options: (i) Change 'Depends' in DESCRIPTION as suggested, and (ii) using save with 'version = 2' for the new files. And, if I am recommended to choose (i), should I recreate the old data files with 'version = 3'? My guess is go for (i) and version = 3 for all data files, but I feel that I need advise. Thanks, Göran __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] data and load version 3
On 2020-06-30 11:58, Ivan Krylov wrote: On Tue, 30 Jun 2020 11:48:29 +0200 Göran Broström wrote: No point at all with version 3 in packages? Format version 3 [1] introduces support for ALTREP objects [2]. Examples of where ALTREP might be useful include really long integer vectors, like 1:1e10. Thanks, no need for that in the actual data files, so I'll convert them to version 2. Göran __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] R-devel internal errors during check produce?
On Tue, Jun 30, 2020 at 1:32 PM Martin Maechler
wrote:
>
> > Kurt Hornik
> > on Tue, 30 Jun 2020 06:20:57 +0200 writes:
>
> > Jan Gorecki writes:
> >> Thank you both, You are absolutely correct that example
> >> should be minimal, so here it is.
>
> >> l = list(a=new.env(), b=new.env()) unique(l)
>
> >> Just for completeness, env_list during check that raises
> >> error
>
> >> env_list <- list(baseenv(),
> >> as.environment("package:graphics"),
> >> as.environment("package:stats"),
> >> as.environment("package:utils"),
> >> as.environment("package:methods") )
>
> >> unique(env_list)
>
> > Thanks ... but the above work fine for me. E.g.,
>
> R> l = list(a=new.env(), b=new.env())
> R> unique(l)
> > [[1]]
>
> > [[2]]
>
> > Best -k
>
> Ditto here; also your (Jan) 2nd example works fine.
>
> So, you must have loaded some (untidy) packages / code which redefine
> standard base R behavior ?
Looking inside Jan's Dockerfile, it turns out that he is configuring R with
./configure --with-recommended-packages --enable-strict-barrier
--disable-long-double
and with that I can reproduce:
> unique(list(new.env()))
Error in unique.default(list(new.env())) :
LENGTH or similar applied to environment object
--enable-strict-barrier is enough to reproduce the error.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] data and load version 3
On Tue, 30 Jun 2020 11:48:29 +0200 Göran Broström wrote: > No point at all with version 3 in packages? Format version 3 [1] introduces support for ALTREP objects [2]. Examples of where ALTREP might be useful include really long integer vectors, like 1:1e10. -- Best regards, Ivan [1] https://developer.r-project.org/blosxom.cgi/R-3-5-branch/NEWS/2018/04/11#n2018-04-11 [2] https://svn.r-project.org/R/branches/ALTREP/ALTREP.html __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] data and load version 3
On 2020-06-30 01:07, Jeff Newmiller wrote: Your choice. Do you want to support people using older versions of R, or not? Is that all? No point at all with version 3 in packages? Why was it introduced? I have seen an argument for version 2: "... needed ... to support name spaces", but version 3 ... Göran On June 29, 2020 1:55:02 PM PDT, "Göran Broström" wrote: I added two data sets (.rda) to my package eha, but when I build the new version I get: WARNING: Added dependency on R >= 3.5.0 because serialized objects in serialize/load version 3 cannot be read in older versions of R. File(s) containing such objects: ‘eha/data/swedeaths.rda’ ‘eha/data/swepop.rda’ In DESCRIPTION I have 'Depends: R (>= 3.0.0)' After googling for a while (found nothing relevant in 'WRE'), I understand that I have two options: (i) Change 'Depends' in DESCRIPTION as suggested, and (ii) using save with 'version = 2' for the new files. And, if I am recommended to choose (i), should I recreate the old data files with 'version = 3'? My guess is go for (i) and version = 3 for all data files, but I feel that I need advise. Thanks, Göran __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[Rd] Build a R call at C level
Hi All, I was reading the R extension manual section 5.11 ( Evaluating R expression from C) and I tried to build a simple call to the sum function. Please see below. call_to_sum <- inline::cfunction( language = "C", sig = c(x = "SEXP"), body = " SEXP e = PROTECT(lang2(install(\"sum\"), x)); SEXP ans = PROTECT(eval(e, R_GlobalEnv)); UNPROTECT(2); return ans; ") call_to_sum(1:3) The above works. My question is how do I add the argument "na.rm=TRUE" at C level to the above call? I have tried various things based on what is in section 5.11 but I did not manage to get it to work. Thank you Best regards [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] data and load version 3
On Mon, 29 Jun 2020 22:55:02 +0200 Göran Broström wrote: > After googling for a while (found nothing relevant in 'WRE'), I > understand that I have two options: (i) Change 'Depends' in > DESCRIPTION as suggested, and (ii) using save with 'version = 2' for > the new files. One of the steps performed by default during R CMD build is tools::resaveRdaFiles(), which passes NULL as version= argument to save(). Around R (not sure about this) 3.6.0 version=NULL was changed to mean version=3, so if you want to preserve compatibility with R < 3.5.0, you may need to run tools::resaveRdaFiles(..., version = 2) before running R CMD build --no-resave-data. -- Best regards, Ivan __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Rd] R-devel internal errors during check produce?
> Kurt Hornik
> on Tue, 30 Jun 2020 06:20:57 +0200 writes:
> Jan Gorecki writes:
>> Thank you both, You are absolutely correct that example
>> should be minimal, so here it is.
>> l = list(a=new.env(), b=new.env()) unique(l)
>> Just for completeness, env_list during check that raises
>> error
>> env_list <- list(baseenv(),
>> as.environment("package:graphics"),
>> as.environment("package:stats"),
>> as.environment("package:utils"),
>> as.environment("package:methods") )
>> unique(env_list)
> Thanks ... but the above work fine for me. E.g.,
R> l = list(a=new.env(), b=new.env())
R> unique(l)
> [[1]]
> [[2]]
> Best -k
Ditto here; also your (Jan) 2nd example works fine.
So, you must have loaded some (untidy) packages / code which redefine
standard base R behavior ?
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] `basename` and `dirname` change the encoding to "UTF-8"
On 6/29/20 4:39 PM, Johannes Rauh wrote: Dear R Developers, I noticed that `basename` and `dirname` always return "UTF-8" on Windows (tested with R-4.0.0 and R-3.6.3): p <- "Föö/Bär" Encoding(p) [1] "latin1" Encoding(dirname(p)) [1] "UTF-8" Encoding(basename(p)) [1] "UTF-8" Is this on purpose? At least I did not find any relevant comment in the documentation of `dirname`/`basename`. Background: I'm currently struggeling with a directory name containing a latin1-character. (I know that this is a bad idea, but I did not create the directory and I cannot rename it.) I now want to pass a latin1-directory name to a function, which internally uses `tools::makeLazyLoadDB`. At that point, internally, `dirname` is called, which changes the encoding, and things break. If I use `debug` to halt the processing and "fix" the encoding, things work as expected. So, if possible, I would prefer that `dirname` and `basename` preserve the encoding. Please try to always submit a minimal reproducible example with your reports and test with at least the latest released version of R, ideally also with R-devel. As you have not sent a reproducible example, it is hard to tell for sure, but most likely as Kevin wrote you have run into a real bug, which was however already fixed in 4.0.2 and in R-devel (17833). The lazy loading cache did not work with file names in non-native encoding. That real bug has been uncovered by legitimate and correct changes like the ones you report, where file operations started returning non-ASCII strings in UTF-8. Historically in R such functions would instead return native strings with misrepresented characters, and we were reluctant to change that expecting waking bugs in code silently assuming native encoding. Still, as people were increasingly running into problems with non-representable characters, we did that change in several functions anyway, and yes, it started waking up bugs. With some performance overhead and added complexity, we could be returning preferentially results in native encoding, and in UTF-8 only when they included non-representable characters. That would increase the code complexity, increase performance overhead, but wake up existing bugs with smaller probability. Note - some code that relied previously on best-fit conversions done by Windows will have been broken anyway. We would have to bypass win_iconv/iconv for that (adding more complexity). Bugs in code not handling encodings properly would still be triggered via non-representable characters. I've recently changed file.path() in R-devel to be slightly more conservative again, along these lines. We can still do it more widely, but it is not high on the priority list. The way to fix all of these problems is switching to UTF-8 as native encoding on Windows and every day spent on tuning the existing behavior postpones that real solution. Best Tomas Best regards Johannes __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
