Re: [R-pkg-devel] [Rd] static html vignette
I may add two cents on that as we recently made this change in data.table. Using markdown package instead of rmarkdown as a vignette engine reduced burden caused by extra dependencies tremendously. Moreover it made package to not even need c++ compiler, as knitr and markdown both (and their recursive deps) are pure C with no C++. Gains were huge. Deps installation time from 12min to 30sec. CI pipeline compute minutes saving around 100min on a single workflow. But there is even a better news (so be sure to upvote), that knitr may not be required to render Rmd at all in near future. For details see https://github.com/rstudio/markdown/issues/109 On Thu, Jan 4, 2024, 22:27 Adrian Dușa wrote: > On Thu, Jan 4, 2024 at 10:44 PM Uwe Ligges < > lig...@statistik.tu-dortmund.de> > wrote: > > > On 04.01.2024 21:23, Duncan Murdoch wrote:[...] > > > Users aren't forced to install "Suggests" packages. That's a choice > > > they make. The default for `install.packages()` is `dependencies = > NA`, > > > which says to install hard dependencies (Imports, Depends, LinkingTo). > > > Users have to choose a non-default setting to include Suggests. > > > > Also note that the maintainer builds the vignette whe calling > > R CMD build > > CRAN checks whether the vignette can be build. > > If a user installs a package, the already produced vignette (on the > > maintainers machine by R CMD build) is instaled. There is no need for > > the user to install any extra package for being able to look at the > > vignettes. > > > > I see... then I must have tested with dependencies = TRUE thinking this > refers to hard dependencies (one more reason to read the documentation > properly). > > Thank you, > Adrian > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] DESCRIPTION file Imports of base R packages
Hello, I noticed some packages define Imports in DESCRIPTION file listing base R packages like methods, utils, etc. My question is that if it is necessary to list those* dependencies in DESCRIPTION file, or is it enough to have them listed in NAMESPACE file? * by "those" I mean packages listed by: in tools:::.get_standard_package_names()$base [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R_orderVector1 - algo: radix, shell, or another?
Thank you Ivan for all detail. I was looking for particular algo for benchmarking purpose. On Mon, Sep 25, 2023 at 9:26 AM Ivan Krylov wrote: > В Sun, 24 Sep 2023 10:38:41 +0200 > Jan Gorecki пишет: > > > > https://github.com/wch/r-source/blob/ed51d34ec195b89462a8531b9ef30b7b72e47204/src/main/sort.c#L1133 > > > could anyone describe which one R_orderVector1 uses, > > The body of the sorting algorithm is defined in the sort2_with_index > macro. This is shell sort. (I don't actually recognise sorting > algorithms on sight, but the "sincs" array gave it away: > < > https://discourse.julialang.org/t/ironic-observation-about-sort-and-sortperm-speed-for-small-integers-vs-r/8715/3 > >.) > > > and if there is easy API to use different ones from C? > > No easy ones, I think. You could construct a call to order(..., method > = 'radix') from R or bundle a sort implementation of your own. > > These are all undocumented implementation details. They could change in > a new version of R (although quite a lot of it hasn't changed in 11-22 > years). Why are you looking for specific sorting algorithms? Could > there be a better way to solve your problem? > > -- > Best regards, > Ivan > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R_orderVector1 - algo: radix, shell, or another?
Hi Jeff, Yes I did. My question is about R_orderVector1 which is part of public R C api. Should I notice something relevant in the source of R's order? Best Jan On Sun, Sep 24, 2023, 17:27 Jeff Newmiller wrote: > Have you read the output of > > order > > entered at the R console? > > > On September 24, 2023 1:38:41 AM PDT, Jan Gorecki > wrote: > >Dear pkg developers, > > > >Are there any ways to check which sorting algorithm is being used when > >calling `order` function? Documentation at > >https://stat.ethz.ch/R-manual/R-devel/library/base/html/sort.html > >says it is radix for length < 2^31 > > > >On the other hand, I am using R_orderVector1, passing in double float > >smaller than 2^31. Short description of it states > >"Fast version of 1-argument case of R_orderVector". > >Should I expect R_orderVector1 follow the same algo as R's order()? If so > >it should be radix as well. > > > > > https://github.com/wch/r-source/blob/ed51d34ec195b89462a8531b9ef30b7b72e47204/src/main/sort.c#L1133 > > > >If there is no way to check sorting algo, could anyone describe which one > >R_orderVector1 uses, and if there is easy API to use different ones from > C? > > > >Best Regards, > >Jan Gorecki > > > > [[alternative HTML version deleted]] > > > >__ > >R-package-devel@r-project.org mailing list > >https://stat.ethz.ch/mailman/listinfo/r-package-devel > > -- > Sent from my phone. Please excuse my brevity. > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] R_orderVector1 - algo: radix, shell, or another?
Dear pkg developers, Are there any ways to check which sorting algorithm is being used when calling `order` function? Documentation at https://stat.ethz.ch/R-manual/R-devel/library/base/html/sort.html says it is radix for length < 2^31 On the other hand, I am using R_orderVector1, passing in double float smaller than 2^31. Short description of it states "Fast version of 1-argument case of R_orderVector". Should I expect R_orderVector1 follow the same algo as R's order()? If so it should be radix as well. https://github.com/wch/r-source/blob/ed51d34ec195b89462a8531b9ef30b7b72e47204/src/main/sort.c#L1133 If there is no way to check sorting algo, could anyone describe which one R_orderVector1 uses, and if there is easy API to use different ones from C? Best Regards, Jan Gorecki [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] safely allocate SEXP and handle failure
Dear pkg developers
I would like to safely allocate R object from C. By safely I mean
that, I can test if allocation succeeded or failed, and then raise
exception myself.
R_alloc and allocVector both raises exception straightaway, so I am
not able to handle failed allocation myself.
In plain C it is something like that:
int *x = malloc(nx*sizeof(int));
if (!x) {
my_fun_to_set_exception_signal();
free(x);
return;
}
How can I do it for creating SEXP object?
Best Regards,
Jan Gorecki
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] details of CRAN's r-devel-linux-x86_64-debian-clang
Thanks to Kurt Hornik for confirming that following should be sufficient. export _R_S3_METHOD_LOOKUP_BASEENV_AFTER_GLOBALENV_=false export _R_S3_METHOD_LOOKUP_REPORT_SEARCH_PATH_USES_=true I did more tests and found out that for the issue to manifest I had to install xts, rather than just zoo (which registers generic method), because a particular unit test required xts to be present. Now I am able to reproduce the problem. On Sun, Oct 25, 2020 at 12:17 PM Jan Gorecki wrote: > > Thanks Hugh, > I must have dropped it when pasting to email. I checked again and it > doesn't make any difference. So my question is still valid then. > > On Sun, Oct 25, 2020 at 11:14 AM Hugh Parsonage > wrote: > > > > _R_S3_METHOD_LOOKUP_BASEENV_AFTER_GLOBALENV_ > > > > not > > > > R_S3_METHOD_LOOKUP_BASEENV_AFTER_GLOBALENV_ > > > > (i.e. you seem to have dropped the initial underscore)? > > > > On Sun, 25 Oct 2020 at 20:01, Jan Gorecki wrote: > > > > > > Dear community, > > > > > > I am getting an error on CRAN on r-devel-linux-x86_64-debian-clang > > > machine only: > > > > > > S3 method lookup found 'as.x.y' on search path > > > > > > I know how to fix the error. I am interested to know how to reproduce > > > this error locally. I tried combination of > > > R_S3_METHOD_LOOKUP_BASEENV_AFTER_GLOBALENV_ > > > and > > > _R_S3_METHOD_LOOKUP_REPORT_SEARCH_PATH_USES_ > > > but didn't manage to reproduce the error. > > > > > > What is the proper way to set up checks to detect these kinds of issues? > > > > > > Moreover, I kindly request to provide "details" for other CRAN > > > machines in flavors page: > > > https://cran.r-project.org/web/checks/check_flavors.html > > > "Details" are currently provided only for 3 machines there. Having > > > "details" for r-devel-linux-x86_64-debian-clang would probably answer > > > my question without involving readers of this mailing list. > > > > > > Best Regards, > > > Jan Gorecki > > > > > > __ > > > 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] details of CRAN's r-devel-linux-x86_64-debian-clang
Thanks Hugh, I must have dropped it when pasting to email. I checked again and it doesn't make any difference. So my question is still valid then. On Sun, Oct 25, 2020 at 11:14 AM Hugh Parsonage wrote: > > _R_S3_METHOD_LOOKUP_BASEENV_AFTER_GLOBALENV_ > > not > > R_S3_METHOD_LOOKUP_BASEENV_AFTER_GLOBALENV_ > > (i.e. you seem to have dropped the initial underscore)? > > On Sun, 25 Oct 2020 at 20:01, Jan Gorecki wrote: > > > > Dear community, > > > > I am getting an error on CRAN on r-devel-linux-x86_64-debian-clang machine > > only: > > > > S3 method lookup found 'as.x.y' on search path > > > > I know how to fix the error. I am interested to know how to reproduce > > this error locally. I tried combination of > > R_S3_METHOD_LOOKUP_BASEENV_AFTER_GLOBALENV_ > > and > > _R_S3_METHOD_LOOKUP_REPORT_SEARCH_PATH_USES_ > > but didn't manage to reproduce the error. > > > > What is the proper way to set up checks to detect these kinds of issues? > > > > Moreover, I kindly request to provide "details" for other CRAN > > machines in flavors page: > > https://cran.r-project.org/web/checks/check_flavors.html > > "Details" are currently provided only for 3 machines there. Having > > "details" for r-devel-linux-x86_64-debian-clang would probably answer > > my question without involving readers of this mailing list. > > > > Best Regards, > > Jan Gorecki > > > > __ > > 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-pkg-devel] details of CRAN's r-devel-linux-x86_64-debian-clang
Dear community, I am getting an error on CRAN on r-devel-linux-x86_64-debian-clang machine only: S3 method lookup found 'as.x.y' on search path I know how to fix the error. I am interested to know how to reproduce this error locally. I tried combination of R_S3_METHOD_LOOKUP_BASEENV_AFTER_GLOBALENV_ and _R_S3_METHOD_LOOKUP_REPORT_SEARCH_PATH_USES_ but didn't manage to reproduce the error. What is the proper way to set up checks to detect these kinds of issues? Moreover, I kindly request to provide "details" for other CRAN machines in flavors page: https://cran.r-project.org/web/checks/check_flavors.html "Details" are currently provided only for 3 machines there. Having "details" for r-devel-linux-x86_64-debian-clang would probably answer my question without involving readers of this mailing list. Best Regards, Jan Gorecki __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)
Thank you Gabor
On Thu, Jul 2, 2020 at 10:20 AM Gábor Csárdi wrote:
>
> You can set the _R_CHECK_XREFS_MIND_SUSPECT_ANCHORS_=true env var and
> use R-devel.
>
> Alternatively, and you don't need R-devel for this, you can run R CMD
> --html INSTALL on your package, and then look for messages that
> contain "treated as a topic", e.g.
>
> curl_fdshtml
> Rd warning: /Users/gaborcsardi/works/processx/man/curl_fds.Rd:11: file
> link ‘multi_fdset’ in package ‘curl’ does not exist and so has been
> treated as a topic
>
> Gabor
>
>
> On Thu, Jul 2, 2020 at 10:06 AM Jan Gorecki wrote:
> >
> > Hi,
> > What is the recommended way to test for those issues locally?
> > If it is tested during cran submission, then seems reasonable to be enabled
> > just by --as-cran switch. Is it?
> > Thanks
> >
> > On Wed 17 Jun, 2020, 12:32 AM Wayne Oldford, wrote:
> >>
> >> Thank you!
> >>
> >> -Original Message-
> >> From: Gábor Csárdi
> >> Date: Tuesday, June 16, 2020 at 4:32 PM
> >> To: Wayne Oldford
> >> Cc: List r-package-devel
> >> Subject: Re: [R-pkg-devel] check cross-references error: Non-file
> >> package-anchored link(s)
> >>
> >> This is how to look up the filename. The first "sp" is the topic name,
> >> the second is the package name.
> >>
> >> > help("sp", "sp")[[1]]
> >> [1] "C:/Users/csard/R/win-library/4.0/sp/help/00sp"
> >>
> >> So you need to link to the "00sp.Rd" file: \link[sp:00sp]{sp}
> >>
> >> Gabor
> >>
> >> On Tue, Jun 16, 2020 at 9:09 PM Wayne Oldford
> >> wrote:
> >> >
> >> > Hi
> >> >
> >> > I got caught by this new test this week in trying to push an updated
> >> release of the loon package to CRAN.
> >> >
> >> > By following this thread, I corrected my cross-references to
> >> external packages but I got stymied by
> >> > the one I hoped to give to the "sp" package for Spatial data
> >> >
> >> > _
> >> >
> >> > Here is the history:
> >> >
> >> > I tried
> >> >\link[sp:sp]{sp}
> >> > which failed here:
> >> > Debian:
> >> <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_162128/Debian/00check.log>
> >> > Status: 1 WARNING
> >> >
> >> >
> >> > That was meant to correct an earlier attempt (it did for other links
> >> to "scales" for example) where I had tried
> >> > \link[sp]{sp}
> >> > and failed here:
> >> > Debian:
> >> <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200615_213749/Debian/00check.log>
> >> > Status: 1 WARNING
> >> >
> >> >
> >> > So to complete the possibilities as I understand them, I just now
> >> tried
> >> >\link{sp}
> >> > which, as might be expected, failed here:
> >> > Debian:
> >> <https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_213921/Debian/00check.log>
> >> > Status: 1 WARNING
> >> > As expected, error here was different: "Missing link" as opposed
> >> to "Non-file package-anchored link"
> >> >
> >> > _
> >> >
> >> >
> >> > I am not sure whether I have missed a subtlety in WRE or that the
> >> peculiar circumstance
> >> > where the package, the topic, and the file name are all identical
> >> (sp) is some weird boundary case.
> >> >
> >> > Without further advice, I think I am just going to remove the link
> >> to "sp".
> >> > It really is just a courtesy link to the package description for
> >> "sp".
> >> >
> >> > Thanks in advance for your thoughts.
> >> >
> >> > Wayne
> >> >
> >> >
> >> >
> >> >
> >> > -Original Message-
> >> > From: R-package-devel on
> >> behalf of Georgi Boshnakov
> >> > Date
Re: [R-pkg-devel] check cross-references error: Non-file package-anchored link(s)
Hi,
What is the recommended way to test for those issues locally?
If it is tested during cran submission, then seems reasonable to be enabled
just by --as-cran switch. Is it?
Thanks
On Wed 17 Jun, 2020, 12:32 AM Wayne Oldford, wrote:
> Thank you!
>
> -Original Message-
> From: Gábor Csárdi
> Date: Tuesday, June 16, 2020 at 4:32 PM
> To: Wayne Oldford
> Cc: List r-package-devel
> Subject: Re: [R-pkg-devel] check cross-references error: Non-file
> package-anchored link(s)
>
> This is how to look up the filename. The first "sp" is the topic name,
> the second is the package name.
>
> > help("sp", "sp")[[1]]
> [1] "C:/Users/csard/R/win-library/4.0/sp/help/00sp"
>
> So you need to link to the "00sp.Rd" file: \link[sp:00sp]{sp}
>
> Gabor
>
> On Tue, Jun 16, 2020 at 9:09 PM Wayne Oldford
> wrote:
> >
> > Hi
> >
> > I got caught by this new test this week in trying to push an updated
> release of the loon package to CRAN.
> >
> > By following this thread, I corrected my cross-references to
> external packages but I got stymied by
> > the one I hoped to give to the "sp" package for Spatial data
> >
> > _
> >
> > Here is the history:
> >
> > I tried
> >\link[sp:sp]{sp}
> > which failed here:
> > Debian: <
> https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_162128/Debian/00check.log
> >
> > Status: 1 WARNING
> >
> >
> > That was meant to correct an earlier attempt (it did for other links
> to "scales" for example) where I had tried
> > \link[sp]{sp}
> > and failed here:
> > Debian: <
> https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200615_213749/Debian/00check.log
> >
> > Status: 1 WARNING
> >
> >
> > So to complete the possibilities as I understand them, I just now
> tried
> >\link{sp}
> > which, as might be expected, failed here:
> > Debian: <
> https://win-builder.r-project.org/incoming_pretest/loon_1.3.1_20200616_213921/Debian/00check.log
> >
> > Status: 1 WARNING
> > As expected, error here was different: "Missing link" as opposed
> to "Non-file package-anchored link"
> >
> > _
> >
> >
> > I am not sure whether I have missed a subtlety in WRE or that the
> peculiar circumstance
> > where the package, the topic, and the file name are all identical
> (sp) is some weird boundary case.
> >
> > Without further advice, I think I am just going to remove the link
> to "sp".
> > It really is just a courtesy link to the package description for
> "sp".
> >
> > Thanks in advance for your thoughts.
> >
> > Wayne
> >
> >
> >
> >
> > -Original Message-
> > From: R-package-devel on
> behalf of Georgi Boshnakov
> > Date: Tuesday, June 16, 2020 at 9:27 AM
> > To: Gábor Csárdi , Duncan Murdoch <
> murdoch.dun...@gmail.com>
> > Cc: List r-package-devel
> > Subject: Re: [R-pkg-devel] check cross-references error: Non-file
> package-anchored link(s)
> >
> > I think that the current behaviour is documented in WRE:
> >
> > "...There are two other forms of optional argument specified as
> \link[pkg]{foo} and
> > \link[pkg:bar]{foo} to link to the package pkg, to files
> foo.html and bar.html respectively.
> > These are rarely needed, perhaps to refer to not-yet-installed
> packages (but there the HTML
> > help system will resolve the link at run time) or in the
> normally undesirable event that more
> > than one package offers help on a topic7 (in which case the
> present package has precedence so
> > this is only needed to refer to other packages). They are
> currently only used in HTML help
> > (and ignored for hyperlinks in LATEX conversions of help pages),
> and link to the file rather
> > than the topic (since there is no way to know which topics are
> in which files in an uninstalled
> > package) ... Because they have been frequently misused, the
> HTML help system looks for topic foo in package pkg
> > if it does not find file foo.html."
> >
> > Unless I am missing something, it seems that it would be
> relatively painless to reverse the logic of the current behaviour of the
> help system,
> > i.e. to start looking first for the topic and then for a file.
> >
> > Georgi Boshnakov
> >
> > -Original Message-
> > From: R-package-devel
> On Behalf Of Gábor Csárdi
> > Sent: 16 June 2020 13:44
> > To: Duncan Murdoch
> > Cc: List r-package-devel
> > Subject: Re: [R-pkg-devel] check cross-references error:
> Non-file package-anchored link(s)
> >
> > On Mon, Jun 15, 2020 at 5:30 PM Duncan Murdoch <
> murdoch.dun...@gmail.com> wrote:
> > >
> > > On 15/06/2020 12:05 p.m., Martin
Re: [R-pkg-devel] Rbuildignore a file type from a top level directory only
Works great, thanks On Sun, Jun 21, 2020 at 4:21 PM Hugh Parsonage wrote: > > Perhaps > > ^[^/]+\.R$ > > On Sun, 21 Jun 2020 at 22:31, Jan Gorecki wrote: > > > > Hi R developers, > > > > What is the proper way to define an entry in .Rbuildignore file to > > exclude *.R files from a top level directory of R package? > > Using ^.*\.R$ excludes every R script, including those in sub-directories. > > > > Thank you, > > Jan Gorecki > > > > __ > > 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] R_MAKEVARS_USER fail to pass down to sub-makes?
Thank you Jim,
That was the problem indeed. Too bad it is not mentioned in the manual.
On Wed, Jun 17, 2020 at 8:33 PM Jim Hester wrote:
>
> I think the issue is likely that you seem to be using a relative path to the
> R_MAKEVARS_USER file, it needs to be an absolute path as the installation is
> run in a temporary directory not from the directory you call `R CMD INSTALL`
> from.
> I observed similar behavior to what you describe when I had the MAKEVARS_USER
> file as a relative path, but using an absolute path produced the expected
> result.
>
> On Mon, Jun 1, 2020 at 8:04 AM Jan Gorecki wrote:
>>
>> Hi package devel support,
>>
>> I am trying to use R_MAKEVARS_USER to customize build, rather than
>> .R/Makevars. It is properly displayed from config CFLAGS but during
>> package install it doesn't seem to work.
>>
>> In R-admin in "6.3.3 Customizing package compilation" there is:
>>
>> > Note that these mechanisms do not work with packages which fail to pass
>> > settings down to sub-makes, perhaps reading etc/Makeconf in makefiles in
>> > subdirectories.
>>
>> It seems that it applies to me. How should I debug that? to make this
>> env var respected? Note that my pkg has src/Makevars to handle openmp
>> switch nicely
>> Thank you
>>
>> system("R_MAKEVARS_USER=library/gcc/O3/Makevars R CMD config CFLAGS")
>> -O3
>>
>> system("R_MAKEVARS_USER=library/gcc/O3/Makevars R CMD INSTALL
>> --library=library/gcc/O3 mypkg_1.0.0.tar.gz")
>> * installing *source* package 'mypkg' ...
>> ** using staged installation
>> ** libs
>> gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG-fopenmp -fpic -g
>> -O2 -fdebug-prefix-map=/build/r-base-V28x5H/r-base-3.6.3=.
>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
>> -D_FORTIFY_SOURCE=2 -g -c assign.c -o assign.o
>>
>> __
>> 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] Forward function call
"pkg::fun" cannot be a name because it is a function call already
`::`(pkg, fun).
On Tue, Jun 9, 2020 at 8:10 AM Martin Maechler
wrote:
>
> > Göran Broström
> > on Mon, 8 Jun 2020 23:02:30 +0200 writes:
>
> > Thanks for the responses!
> > I found the suggestion
>
> > Call[[1]] <- quote(survival::coxph)
>
> > easiest to implement. And it works.
>
> and it is what we use in R's own R source code in several
> places (and that's where/how I assume it also came to Ben
> Bolker, lme4, etc) :
>
> A simple grep inside current R's source /src/library/ gives
>
> grep -r --color -nHF -e 'quote(stats::'
>
> ./stats/R/acf.R:28:m[[1L]] <- quote(stats::pacf)
> ./stats/R/aggregate.R:154:m[[1L]] <- quote(stats::model.frame)
> ./stats/R/aov.R:36:lmcall[[1L]] <- quote(stats::lm)
> ./stats/R/bartlett.test.R:86:m[[1L]] <- quote(stats::model.frame)
> ./stats/R/cor.test.R:213:m[[1L]] <- quote(stats::model.frame)
> ./stats/R/factanal.R:73:mf[[1L]] <- quote(stats::model.frame)
> ./stats/R/friedman.test.R:92:m[[1L]] <- quote(stats::model.frame)
> ./stats/R/ftable.R:150:m[[1L]] <- quote(stats::model.frame)
> ./stats/R/glm.R:52:mf[[1L]] <- quote(stats::model.frame)
> ./stats/R/glm.R:863:fcall[[1L]] <- quote(stats::glm)
> ./stats/R/lm.R:34:mf[[1L]] <- quote(stats::model.frame)
> ./stats/R/lm.R:546:fcall[[1L]] <- quote(stats::model.frame)
> ./stats/R/loess.R:34:mf[[1L]] <- quote(stats::model.frame)
> ./stats/R/manova.R:22:fcall[[1L]] <- quote(stats::aov)
> ./stats/R/model.tables.R:485:fcall <- c(list(quote(stats::model.frame)),
> args)
> ./stats/R/nls.R:570:mf[[1L]] <- quote(stats::model.frame)
> ./stats/R/ppr.R:30:m[[1L]] <- quote(stats::model.frame)
> ./stats/R/prcomp.R:69:mf[[1L]] <- quote(stats::model.frame)
> ./stats/R/princomp.R:30:mf[[1L]] <- quote(stats::model.frame)
> ./stats/R/quade.test.R:102:m[[1L]] <- quote(stats::model.frame)
> ./stats/R/spectrum.R:220:m[[1L]] <- quote(stats::plot.spec.coherency)
> ./stats/R/spectrum.R:226:m[[1L]] <- quote(stats::plot.spec.phase)
> ./stats/R/t.test.R:141:m[[1L]] <- quote(stats::model.frame)
> ./stats/R/ts.R:744:m[[1L]] <- quote(stats::window)
> ./stats/R/var.test.R:97:m[[1L]] <- quote(stats::model.frame)
> ./stats/R/xtabs.R:40:m[[1L]] <- quote(stats::model.frame)
>
>
> > Best, Göran
>
> > On 2020-06-08 21:42, Ben Bolker wrote:
> >> I think quote(survival::coxph) will work in place of as.name() ?
> >>
> >> On Mon, Jun 8, 2020 at 3:12 PM Göran Broström
> wrote:
> >>>
> >>> Hello,
> >>>
> >>> the function 'coxreg' in my package 'eha' is often just a wrapper for
> >>> 'coxph' in survival, so I have code like
> >>>
> >>> if (cox.ph){
> >>> Call <- match.call()
> >>> Call[[1]] <- as.name("coxph")
> >>> fit <- eval.parent(Call)
> >>> return(fit)
> >>> }
> >>>
> >>> which works since eha depends on survival. Now I am thinking of
> changing
> >>> Depends to Imports, and I would like to change the code to
> >>>
> >>> if (cox.ph){
> >>> Call <- match.call()
> >>> Call[[1]] <- as.name("survival::coxph")
> >>> fit <- eval.parent(Call)
> >>> return(fit)
> >>> }
> >>>
> >>> but this doesn't work, because the function name is turned into
> >>> `survival::coxph` (with the backticks) and the evaluation fails.
> >>>
> >>> How can I solve this?
> >>>
> >>> Thanks, G,
> >>>
> >>> __
> >>> 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
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R_MAKEVARS_USER fail to pass down to sub-makes?
What is the problem exactly? variable name is hardcoded, and variable
value is hardcoded as well.
How it is possible for the second `system` call to deliver different
makevars file than the first one?
This is the problem in question.
Yes, I haven't thought about Windows. I should have mentioned I am on Linux.
On Mon, Jun 1, 2020 at 7:20 PM Jeff Newmiller wrote:
>
> Each call to system is independent, so it definitely is a problem.
>
> Use Sys.setenv to make changes in environment variables that can be used
> within system calls.
>
> Bash is not involved with the system call on Windows... so your syntax for
> setting an environment variable is not portable.
>
> On June 1, 2020 11:10:41 AM PDT, Jan Gorecki wrote:
> >Thank you Jeff for your comments.
> >Yet they does not seem to be related.
> >a) Environment variable is created inside `system` command, so env var
> >stays valid for the command. Which is confirmed in the first call that
> >properly shows CFLAGS.
> >b) Syntax passed checkbashisms so I expect no problems due to that.
> >
> >On Mon, Jun 1, 2020 at 4:03 PM Jeff Newmiller
> > wrote:
> >>
> >> I don't know anything about the function of that environment
> >variable, but
> >>
> >> a) system() invokes a child process so environment variable changes
> >made using it will only affect the child process created by that system
> >call.
> >>
> >> b) The syntax you have used is shell-specific, so does not look
> >portable.
> >>
> >> On June 1, 2020 4:58:19 AM PDT, Jan Gorecki
> >wrote:
> >> >Hi package devel support,
> >> >
> >> >I am trying to use R_MAKEVARS_USER to customize build, rather than
> >> >.R/Makevars. It is properly displayed from config CFLAGS but during
> >> >package install it doesn't seem to work.
> >> >
> >> >In R-admin in "6.3.3 Customizing package compilation" there is:
> >> >
> >> >> Note that these mechanisms do not work with packages which fail to
> >> >pass settings down to sub-makes, perhaps reading etc/Makeconf in
> >> >makefiles in subdirectories.
> >> >
> >> >It seems that it applies to me. How should I debug that? to make
> >this
> >> >env var respected? Note that my pkg has src/Makevars to handle
> >openmp
> >> >switch nicely
> >> >Thank you
> >> >
> >> >system("R_MAKEVARS_USER=library/gcc/O3/Makevars R CMD config
> >CFLAGS")
> >> >-O3
> >> >
> >> >system("R_MAKEVARS_USER=library/gcc/O3/Makevars R CMD INSTALL
> >> >--library=library/gcc/O3 mypkg_1.0.0.tar.gz")
> >> >* installing *source* package 'mypkg' ...
> >> >** using staged installation
> >> >** libs
> >> >gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG-fopenmp -fpic
> >-g
> >> >-O2 -fdebug-prefix-map=/build/r-base-V28x5H/r-base-3.6.3=.
> >> >-fstack-protector-strong -Wformat -Werror=format-security
> >-Wdate-time
> >> >-D_FORTIFY_SOURCE=2 -g -c assign.c -o assign.o
> >> >
> >> >__
> >> >R-package-devel@r-project.org mailing list
> >> >https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >> --
> >> Sent from my phone. Please excuse my brevity.
>
> --
> Sent from my phone. Please excuse my brevity.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R_MAKEVARS_USER fail to pass down to sub-makes?
Thank you Jeff for your comments.
Yet they does not seem to be related.
a) Environment variable is created inside `system` command, so env var
stays valid for the command. Which is confirmed in the first call that
properly shows CFLAGS.
b) Syntax passed checkbashisms so I expect no problems due to that.
On Mon, Jun 1, 2020 at 4:03 PM Jeff Newmiller wrote:
>
> I don't know anything about the function of that environment variable, but
>
> a) system() invokes a child process so environment variable changes made
> using it will only affect the child process created by that system call.
>
> b) The syntax you have used is shell-specific, so does not look portable.
>
> On June 1, 2020 4:58:19 AM PDT, Jan Gorecki wrote:
> >Hi package devel support,
> >
> >I am trying to use R_MAKEVARS_USER to customize build, rather than
> >.R/Makevars. It is properly displayed from config CFLAGS but during
> >package install it doesn't seem to work.
> >
> >In R-admin in "6.3.3 Customizing package compilation" there is:
> >
> >> Note that these mechanisms do not work with packages which fail to
> >pass settings down to sub-makes, perhaps reading etc/Makeconf in
> >makefiles in subdirectories.
> >
> >It seems that it applies to me. How should I debug that? to make this
> >env var respected? Note that my pkg has src/Makevars to handle openmp
> >switch nicely
> >Thank you
> >
> >system("R_MAKEVARS_USER=library/gcc/O3/Makevars R CMD config CFLAGS")
> >-O3
> >
> >system("R_MAKEVARS_USER=library/gcc/O3/Makevars R CMD INSTALL
> >--library=library/gcc/O3 mypkg_1.0.0.tar.gz")
> >* installing *source* package 'mypkg' ...
> >** using staged installation
> >** libs
> >gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG-fopenmp -fpic -g
> >-O2 -fdebug-prefix-map=/build/r-base-V28x5H/r-base-3.6.3=.
> >-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> >-D_FORTIFY_SOURCE=2 -g -c assign.c -o assign.o
> >
> >__
> >R-package-devel@r-project.org mailing list
> >https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> Sent from my phone. Please excuse my brevity.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] R_MAKEVARS_USER fail to pass down to sub-makes?
Hi package devel support,
I am trying to use R_MAKEVARS_USER to customize build, rather than
.R/Makevars. It is properly displayed from config CFLAGS but during
package install it doesn't seem to work.
In R-admin in "6.3.3 Customizing package compilation" there is:
> Note that these mechanisms do not work with packages which fail to pass
> settings down to sub-makes, perhaps reading etc/Makeconf in makefiles in
> subdirectories.
It seems that it applies to me. How should I debug that? to make this
env var respected? Note that my pkg has src/Makevars to handle openmp
switch nicely
Thank you
system("R_MAKEVARS_USER=library/gcc/O3/Makevars R CMD config CFLAGS")
-O3
system("R_MAKEVARS_USER=library/gcc/O3/Makevars R CMD INSTALL
--library=library/gcc/O3 mypkg_1.0.0.tar.gz")
* installing *source* package 'mypkg' ...
** using staged installation
** libs
gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG-fopenmp -fpic -g
-O2 -fdebug-prefix-map=/build/r-base-V28x5H/r-base-3.6.3=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -g -c assign.c -o assign.o
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
