Re: [R-pkg-devel] new maintainer for CRAN package XML
Re: guidance on how to migrate from XML to xml2, these notes from Daniel Nüst may be helpful: https://gist.github.com/nuest/3ed3b0057713eb4f4d75d11bb62f2d66. Best wishes, Heather On Wed, Jan 24, 2024, at 3:38 PM, Emmanuel Blondel wrote: > if XML is deprecated, then what would be the choice for a package > maintainer? Move to xml2 probably at some point I assume > > I use XML in the R packages I've been developing. For some of them, I > started before CRAN started being the maintainer, and before xml2 > inception. The thing is that XML fulfills requirements, it works and > fulfills needs of depending packages that made the choice to use it. For > this, it deserves to be maintained in CRAN, without having to enter into > comparison exercices with other packages that , as of today, may be > better to rely on (with certainly very good reasons). > > Moving to xml2 (or whatever other package), which although I could agree > on the principle, can be costly for packages that use extensively XML. > Doing so would mean that we first get the assurance that all XML > features are covered elsewhere, and can be migrated smoothly. > > In any case, please acknowledge that this kind of migration may take > time and require resources that vary (or even are missing) depending on > the package projects. I doubt having CRAN setting a common deadline for > retirement is a good way to foster an efficient maintenance of R > packages depending on XML. It would be good to receive guidance how to > migrate, while ensuring backward compatibility on our package features. > > Best > > Le 24/01/2024 à 15:59, Jeroen Ooms a écrit : >> On Mon, Jan 22, 2024 at 3:51 PM Uwe Ligges >> wrote: >>> Dear package developers, >>> >>> the CRAN team (and Professor Ripley in particular) has been the defacto >>> maintainer of CRAN package 'XML'. >>> Our hope was that maintainers of packages depending on XML will migrate >>> to other packages for reading XML structures. This has not happened and >>> we still see dozens of strong dependencies on XML. >> How is this hope communicated? Many R users assume that XML package is >> in great shape and the preferable choice because it is maintained by >> the CRAN team and r-core members. >> >> Perhaps one could follow the precedent from the rgdal retirement, and >> set a deadline. >> >> One way to communicate this effectively would be by introducing a >> formal deprecation field in the package description. This could then >> be displayed on the XML CRAN html page, and when loading the package >> interactively. Other packages that import such a deprecated package >> could be given a CMD check warning. >> >> __ >> 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] LaTeX warnings on debian builds only
Hi Adam,
I suspect these two lines in your YAML header are causing trouble
> %\usepackage[utf8]{inputenc}
> %\usepackage[table]{xcolor}
- this is LaTeX code, which you shouldn't need if you're producing an HTML
vignette.
Also, with more recent versions of R markdown you should use knitr::rmarkdown
rather than knitr::knitr as the vignette engine. For an HTML vignette, I'd
expect your vignette field to look like this:
vignette: >
%\VignetteIndexEntry{DEVis}
%\VignetteEngine{knitr::rmarkdown}
%\VignetteEncoding{UTF-8}
so try updating that block and see if that fixes it.
Best wishes,
Heather
On Fri, Jan 18, 2019, at 3:42 PM, Adam Price wrote:
> Hi,
>
> I am currently having an issue getting past a warning that's occurring on
> linux based builds for my vignette. The warning is: "! LaTeX Error: Option
> clash for package xcolor."
>
> The check results are here:
> *https://win-builder.r-project.org/incoming_pretest/DEVis_1.0.1_20181220_164555/Debian/00check.log
> *
>
> Windows and OS X builds work fine, but I don't have access to a debian
> machine that I can reproduce this on. I currently cannot reproduce this
> issue on my side, and travis-ci checks do not seem to produce this warning
> for linux on ubuntu. I can only see it currently when submitting an update
> to my package and failing the CRAN auto-checks.
>
> I have recently changed from PDF vignette to html-based, and am not sure
> why LaTeX packages would even be loading in this case. I have attempted to
> correct for it based on this post (
> https://github.com/haozhu233/kableExtra/issues/274
> ) which claims the issue is a conflict between kableExtra and xcolor.
>
> Some relevant sections of code from the vignette might include:
> "
> vignette: |
> %\VignetteIndexEntry{DEVis}
> %\usepackage[utf8]{inputenc}
> %\usepackage[table]{xcolor}
> %\VignetteEngine{knitr::knitr}
> ---
>
> ```{r loadData, echo = F, eval = TRUE}
> #load("../data/exampleData.Rda")
> knitr::opts_knit$set(root.dir = '../vignettes/')
> knitr::opts_chunk$set(fig.path='figure/graphics-',
> cache.path='cache/graphics-',
> fig.align='center',
> external=TRUE,
> echo=TRUE,
> warning=FALSE,
> fig.pos='H'
> )
> a4width<- 8.3
> a4height<- 11.7
> library(kableExtra)
> library(rmarkdown)
> library(knitr)
> options(knitr.table.format = "html")
> options(kableExtra.latex.load_packages = FALSE)
> "
>
>
> The full package code can be found here: https://github.com/price0416/DEvis
>
> I would appreciate any insight anyone can offer into this issue, as I
> cannot update my package until I get to the bottom of this! Thanks very
> much in advance!
>
> Best,
> -Adam
>
> [[alternative HTML version deleted]]
>
> __
> 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] shadowing a method from the stats package
Hi Oscar,
I don't think this is such a good idea, for a few reasons.
First, `setMethod` defines an S4 method, so both an S3 method (from stats) and
an S4 method (from your package) will be defined. This seems to work, but could
give unexpected results and is confusing for anyone trying to understand what
code is actually called. You could use `R.methodsS3::setMethodS3` to replace
the summary.glm registered by the stats package, but then you're back to square
1.
Second, it's not enough to replace `summary.glm`; you also need to replace
`vcov.glm`, since this calls summary.glm internally and even if you have
defined your own S3/S4 summary method for glms, the one from stats will be used
in that case, since it is in the same namespace.
Third, if you can over-ride `summary.glm`, then another person could,
potentially meaning your unifed family gets used to fit a glm, but then another
summary method is called when summarising the fit.
So I think the safest solution would be to write a wrapper around glm,
`unifed_glm` say, that fits a glm with the unifed family and returns an object
of class c("unifed", "glm", "lm"). Then you can write summary.unifed,
vcov.unifed and any other required methods, passing on to the "glm" methods
when you have set dispersion to 1. This also makes it easier to document the
methods.
Alternatively you could try emailing the R-devel mailing list to propose that
family objects should have an `est.disp` element that is FALSE for binomial,
poisson and any other families that should have dispersion fixed to 1, and is
TRUE otherwise. This would require minimal change to the stats package, while
accommodating your unifed family.
Best wishes,
Heather
On Sat, Jan 12, 2019, at 10:02 PM, qxa...@use.startmail.com wrote:
> Hi Joris,
>
> thank you for your reply.
>
> I re-read the CRAN policy after I saw your reply and you are right,
> I do not need permission for this.
>
> About the search PATH. unifed will always be attached after stats,
> so I think the unifed function would always be found before the one in
> stats (please correct me if you think I am wrong).
>
> Still, I found a different way to solve the problem in order to
> avoid NOTEs when I run 'R CMD check --as-cran', that can be considered
> more robust:
>
> I first changed the name of my wrapper function to something
> different (this is in order to avoid a note in registering S3 methods).
>
> then, in the zzz.R file inside of the .onLoad function I used
> setMethod with where=.GlobalEnv to rewrite the summary method of the glm
> class and in there I call the wrapper function.
>
> This gives the behavior that I wanted and it does not depend on the
> search path.
>
> Cheers,
>
> Oscar.
>
> >
> > Then again, I'm not sure this will always work, as you rely heavily on
> > the search path for your function to be found before the one in stats.
> > I would be interested as well in hearing how this can be solved in a
> > more robust way, but I can't really come up with something myself.
> > Interesting problem!
> >
> > Cheers
> > Joris
> >
> > On Fri, Jan 11, 2019 at 10:14 PM > > wrote:
> >
> > Hello,
> >
> > I created a package for working with a new probability
> > distribution called unifed. The source code can be found at
> > https://gitlab.com/oquijano/unifed .
> >
> > This distribution is suitable for GLMs. I have included a a
> > function called unifed in the package that returns a family that can
> > be used with the glm function.
> >
> > For a unifed glm, it is necessary for the dispersion parameter to
> > be equal to one. The summary method of the glm class does this
> > automatically for the poisson and binomial distributions and I would
> > like the same for the unifed. In order to achieve this, I am
> > including a summary.glm function in the package so it shadows
> > stats::summary.glm when the package is attached. This function is
> > actually just a wrapper around stats::summary.glm. It simply checks
> > if the family is unifed; If this is the case it calls
> > stats::summary.glm with dispersion=1 and otherwise it simply calls
> > stats::summary.glm with the same parameters. Therefore introducing
> > this in the namespace does not break or change the behavior of any
> > existing code that uses summary.glm
> >
> > According to the CRAN policies I need permission from the
> > maintainer of the package for doing this. The maintainer of the
> > package
> > is the R core team. To whom should I write to ask for this permission?
> > Otherwise is there a different way in which I could achieve the right
> > default behavior and respect the CRAN policies?
> >
> >
> > Thank you for your time.
> >
> > __
> > R-package-devel@r-project.org
> >
Re: [R-pkg-devel] Determine subset from glm object
On second thoughts it may be better to preserve the original data and na.action
in the call to glm. So then you might combine the idea of a dummy model frame
with evaluating the subset, e.g.
mfcall <- call("model.frame", reformulate(all.vars(f)), data = data)
mf <- eval(mfcall, parent.frame())
mf$id <- seq_len(nrow(mf))
subset <- mf$id %in% model.frame( ~ id, data = mf, subset = subset)$id
This will give the subset as a logical vector whether it was originally
supplied as logical, numeric or character. Then you might combine this with the
logical vector based on the first glm as follows:
subset[subset] <- linearity
On Mon, Jul 9, 2018, at 10:14 PM, Heather Turner wrote:
> Good point. In that case a solution might be to create a model frame
> based on the named variables, e.g.
>
> # general formula
> f <- ~ log(x) + ns(v, df = 2)
> # model frame based on "bare" variables; deal with user-supplied subset,
> data, na.action, etc
> mfcall <- call("model.frame", reformulate(all.vars(f)), subset = subset,
> data = data, na.action = na.action)
> mf <- eval(mfcall, parent.frame())
>
> Then `mf` can be passed as the data argument to `glm` without any subset
> argument for the first model and with the new subset argument for the
> second model.
>
>
> On Mon, Jul 9, 2018, at 5:06 PM, Ben Bolker wrote:
> >
> > From painful experience: model.frame() does *NOT* necessarily return a
> > data frame that can be successfully used as the data= argument for models.
> >
> > - transformed variables (e.g. log(x)) will be in the model frame
> > rather than the original variables, so when model.frame() is called
> > again within glm(), it won't find the original variables
> > - variables with data-dependent bases (poly(), ns(), etc.) get
> > computed and stuck in the model frame - again, the original variables
> > are inaccessible
> >
> >
> > On 2018-07-09 11:20 AM, Heather Turner wrote:
> > >
> > >
> > > On Sun, Jul 8, 2018, at 8:25 PM, Charles Geyer wrote:
> > >> I spoke too soon. The problem isn't that I don't know how to get the
> > >> subset argument. I am just calling glm (via eval) with (mostly) the
> > >> same arguments as the call to my function, so subset is (if not
> > >> missing) an argument to my function too. So I can just use it.
> > >>
> > >> The problem is that I then want to call glm again fitting a subset of
> > >> the original subset (if there was one). And when I do that glm will
> > >> refer to the original data wherever it is, and I don't have that.
> > >>
> > >> if this isn't clear, here is the code as it stands now
> > >> https://github.com/cjgeyer/glmdr/blob/master/package/glmdr/R/glmdr.R.
> > >>
> > >> The issue is with the lines (very near the end)
> > >>
> > >> subset.lcm <- as.integer(rownames(modmat))
> > >> subset.lcm <- subset.lcm[linearity]
> > >> # call glm again
> > >> call.glm$subset <- subset.lcm
> > >> gout.lcm <- eval(call.glm, parent.frame())
> > >>
> > >> I can see from what Duncan said that I really don't want the
> > >> as.integer around rownames. But it is not clear what would be better.
> > >>
> > >> I just had another thought that I could get the original data with
> > >> another call to glm with subset removed from the call and method =
> > >> "model.frame" added. And I think (maybe, have to try it) that it
> > >> would have NA's removed or whatever na.action says to do.
> > >> But that seems redundant.
> > >>
> > >>
> > > As you are calling stats::glm, you can use `model.frame` to get the data
> > > used to fit the model after applying subset and na.action. So then you
> > > can do:
> > >
> > > call.glm$subset <- linearity
> > > call.glm$data <- model.frame(gout)
> > >
> > > I think this is what you are after?
> > >
> > > Heather
> > >
> > >>
> > >> On Sun, Jul 8, 2018, 1:04 PM Charles Geyer wrote:
> > >>>
> > >>> I think your second option sounds better because this is all happening
> > >>> inside one function I'm writing so users won't be able mess with the
> > >>> glm object. Many thanks.
> > >>>
> > >>> On Sun, Jul 8, 2018, 12:10 PM Duncan Murdoch
> > >>> wrote:
> > >>>>
> > >>>> On 0
Re: [R-pkg-devel] Determine subset from glm object
Good point. In that case a solution might be to create a model frame based on
the named variables, e.g.
# general formula
f <- ~ log(x) + ns(v, df = 2)
# model frame based on "bare" variables; deal with user-supplied subset, data,
na.action, etc
mfcall <- call("model.frame", reformulate(all.vars(f)), subset = subset, data =
data, na.action = na.action)
mf <- eval(mfcall, parent.frame())
Then `mf` can be passed as the data argument to `glm` without any subset
argument for the first model and with the new subset argument for the second
model.
On Mon, Jul 9, 2018, at 5:06 PM, Ben Bolker wrote:
>
> From painful experience: model.frame() does *NOT* necessarily return a
> data frame that can be successfully used as the data= argument for models.
>
> - transformed variables (e.g. log(x)) will be in the model frame
> rather than the original variables, so when model.frame() is called
> again within glm(), it won't find the original variables
> - variables with data-dependent bases (poly(), ns(), etc.) get
> computed and stuck in the model frame - again, the original variables
> are inaccessible
>
>
> On 2018-07-09 11:20 AM, Heather Turner wrote:
> >
> >
> > On Sun, Jul 8, 2018, at 8:25 PM, Charles Geyer wrote:
> >> I spoke too soon. The problem isn't that I don't know how to get the
> >> subset argument. I am just calling glm (via eval) with (mostly) the
> >> same arguments as the call to my function, so subset is (if not
> >> missing) an argument to my function too. So I can just use it.
> >>
> >> The problem is that I then want to call glm again fitting a subset of
> >> the original subset (if there was one). And when I do that glm will
> >> refer to the original data wherever it is, and I don't have that.
> >>
> >> if this isn't clear, here is the code as it stands now
> >> https://github.com/cjgeyer/glmdr/blob/master/package/glmdr/R/glmdr.R.
> >>
> >> The issue is with the lines (very near the end)
> >>
> >> subset.lcm <- as.integer(rownames(modmat))
> >> subset.lcm <- subset.lcm[linearity]
> >> # call glm again
> >> call.glm$subset <- subset.lcm
> >> gout.lcm <- eval(call.glm, parent.frame())
> >>
> >> I can see from what Duncan said that I really don't want the
> >> as.integer around rownames. But it is not clear what would be better.
> >>
> >> I just had another thought that I could get the original data with
> >> another call to glm with subset removed from the call and method =
> >> "model.frame" added. And I think (maybe, have to try it) that it
> >> would have NA's removed or whatever na.action says to do.
> >> But that seems redundant.
> >>
> >>
> > As you are calling stats::glm, you can use `model.frame` to get the data
> > used to fit the model after applying subset and na.action. So then you can
> > do:
> >
> > call.glm$subset <- linearity
> > call.glm$data <- model.frame(gout)
> >
> > I think this is what you are after?
> >
> > Heather
> >
> >>
> >> On Sun, Jul 8, 2018, 1:04 PM Charles Geyer wrote:
> >>>
> >>> I think your second option sounds better because this is all happening
> >>> inside one function I'm writing so users won't be able mess with the glm
> >>> object. Many thanks.
> >>>
> >>> On Sun, Jul 8, 2018, 12:10 PM Duncan Murdoch
> >>> wrote:
> >>>>
> >>>> On 08/07/2018 11:48 AM, Charles Geyer wrote:
> >>>>> I need to find out from an object returned by R function glm with
> >>>>> argument
> >>>>> x = TRUE
> >>>>> what the subsetting was. It appears that if gout is that object, then
> >>>>>
> >>>>> as.integer(rownames(gout$x))
> >>>>>
> >>>>> is a subset vector equivalent to the one actually used.
> >>>>
> >>>> You don't want the "as.integer". If the dataframe had rownames to start
> >>>> with, the x component of the fit will have row labels consisting of
> >>>> those labels, so as.integer may fail. Even if it doesn't, the rownames
> >>>> aren't necessarily sequential integers. You can index the dataframe by
> >>>> the character versions of the default numbers, so simply
> >>>> rownames(gout$x) should always work.
> >>>>
> >>>> More generally, I'm not sure your question is well
Re: [R-pkg-devel] Determine subset from glm object
On Sun, Jul 8, 2018, at 8:25 PM, Charles Geyer wrote: > I spoke too soon. The problem isn't that I don't know how to get the > subset argument. I am just calling glm (via eval) with (mostly) the > same arguments as the call to my function, so subset is (if not > missing) an argument to my function too. So I can just use it. > > The problem is that I then want to call glm again fitting a subset of > the original subset (if there was one). And when I do that glm will > refer to the original data wherever it is, and I don't have that. > > if this isn't clear, here is the code as it stands now > https://github.com/cjgeyer/glmdr/blob/master/package/glmdr/R/glmdr.R. > > The issue is with the lines (very near the end) > > subset.lcm <- as.integer(rownames(modmat)) > subset.lcm <- subset.lcm[linearity] > # call glm again > call.glm$subset <- subset.lcm > gout.lcm <- eval(call.glm, parent.frame()) > > I can see from what Duncan said that I really don't want the > as.integer around rownames. But it is not clear what would be better. > > I just had another thought that I could get the original data with > another call to glm with subset removed from the call and method = > "model.frame" added. And I think (maybe, have to try it) that it > would have NA's removed or whatever na.action says to do. > But that seems redundant. > > As you are calling stats::glm, you can use `model.frame` to get the data used to fit the model after applying subset and na.action. So then you can do: call.glm$subset <- linearity call.glm$data <- model.frame(gout) I think this is what you are after? Heather > > On Sun, Jul 8, 2018, 1:04 PM Charles Geyer wrote: > > > > I think your second option sounds better because this is all happening > > inside one function I'm writing so users won't be able mess with the glm > > object. Many thanks. > > > > On Sun, Jul 8, 2018, 12:10 PM Duncan Murdoch > > wrote: > >> > >> On 08/07/2018 11:48 AM, Charles Geyer wrote: > >> > I need to find out from an object returned by R function glm with > >> > argument > >> > x = TRUE > >> > what the subsetting was. It appears that if gout is that object, then > >> > > >> > as.integer(rownames(gout$x)) > >> > > >> > is a subset vector equivalent to the one actually used. > >> > >> You don't want the "as.integer". If the dataframe had rownames to start > >> with, the x component of the fit will have row labels consisting of > >> those labels, so as.integer may fail. Even if it doesn't, the rownames > >> aren't necessarily sequential integers. You can index the dataframe by > >> the character versions of the default numbers, so simply > >> rownames(gout$x) should always work. > >> > >> More generally, I'm not sure your question is well posed. What do you > >> mean by "the subsetting"? If you have something like > >> > >> df <- data.frame(letters, x = 1:26, y = rbinom(26, 1, 0.5)) > >> > >> df1 <- subset(df, letters > "b" & letters < "y") > >> > >> gout <- glm(y ~ x, data = df1, subset = letters < "q", x = TRUE) > >> > >> the rownames(gout$x) are going to be numbers for rows of df, because df1 > >> will get a subset of those as row labels. > >> > >> > >> > I do also have the call to glm (as a call object) so can determine the > >> > actual subset argument, but this seems to be not so useful because I > >> > don't > >> > know the length of the original variables before subsetting. > >> > >> You should be able to evaluate the subset expression in the environment > >> of the formula, i.e. > >> > >> eval(gout$call$subset, envir = environment(gout$formula)) > >> > >> This may give incorrect results if the variables used in subsetting > >> aren't in the dataframe and have changed since glm() was called. > >> > >> > >> > So now my questions. Is this idea above (using rownames) OK even though > >> > I > >> > cannot find where (if anywhere) it is documented? Is there a better way? > >> > One more guaranteed to be correct in the future? > >> > > >> > >> I would trust evaluating the subset more than grabbing row labels from > >> gout$x, but I don't know for sure it is likely to be more robust. > >> > >> Duncan Murdoch > > __ > 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] compilation flags WARNING
I would suggest not to set the CFLAGS in the package itself - at least not exclusively. R-admin 6.3.3 (the section I linked before) recommends "to enable a reasonable amount of diagnostic messaging (“warnings”) when compiling, such as e.g. -Wall -pedantic for tools from GCC", while R-exts 1.2.1 says"When writing a Makevars file for a package you intend to distribute, take care to ensure that it is not specific to your compiler: flags such as -O2 -Wall -pedantic (and all other -W flags: for the Oracle compilers these are used to pass arguments to compiler phases) are all specific to GCC." Since these are contradictory, you can't satisfy both via PKG_CFLAGS alone. That is why I suggest to use the Makevars.site file to set pedantic flags for local use that are not distributed with the package (if you don't want to set them at a site-wide level R-admin 6.3.3 gives alternatives for setting at user-level). Heather On Thu, Jul 5, 2018, at 9:19 PM, Göran Broström wrote: > Thanks Heather and Iñaki: I understand. > > I have an old Makevars file in the src directory of the package. I > guess I can set the flags there? Now it only contains > > # PKG_CFLAGS = -Wall > # PKG_FFLAGS = -Wall -fbounds-check > PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS) > > Göran > > On 2018-07-05 17:43, Heather Turner wrote: > > > > > > On Thu, Jul 5, 2018, at 3:39 PM, Iñaki Úcar wrote: > >> El jue., 5 jul. 2018 a las 16:11, Göran Broström > >> () escribió: > >>> > >>> I am preparing a CRAN release of eha (a trivial change due to a change > >>> in the survival package), but when checking the build I get: > >>> > >>> goran@M6800:~/R$ R CMD check --as-cran eha_2.5.2.tar.gz > >>> ... > >>> * checking compilation flags used ... WARNING > >>> Compilation used the following non-portable flag(s): > >>> ‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’ > >>> ... > >> > >> AFAIK, these are new checks. I get similar warnings on Fedora for > >> different flags. > >> > >>> I have never seen this before and I haven't (to my knowledge) set any > >>> compilation flags. It is my first build and check on a newly upgraded > >>> ubuntu 18.04 (no issues on 17.10). Should I perhaps ask on r-sig-debian, > >>> or is that observation irrelevant? > >> > >> Again AFAIK (there are package maintainers for several distros here > >> that can correct me if I'm wrong), each distro defines some policies > >> regarding compilation flags that are applied to all packages by > >> default. So these warnings can be safely ignored locally (or you may > >> override them), because those flags won't be defined on CRAN. > >> > > Yes, by default the compilation flags are those set when R was installed. > > You can see the current flags via > > > > R CMD config CFLAGS > > > > which in your case should include ‘-Wdate-time’ etc. > > > > As Iñaki says you can safely ignore the warning, but if you prefer to not > > to have any warnings you can solve this by creating a Makevars.site file > > with CFLAGS excluding the non-portable ones, e.g. > > > > CFLAGS=-Wall -g O0 -fPIC > > > > This should be saved in the /etc directory of R.home(), e.g. /usr/lib/R/etc. > > > > See > > https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation > > for more information. > > > > Heather > > > >> Iñaki > >> > >>> > >>> Göran Broström > >> > >> __ > >> 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] compilation flags WARNING
On Thu, Jul 5, 2018, at 3:39 PM, Iñaki Úcar wrote: > El jue., 5 jul. 2018 a las 16:11, Göran Broström > () escribió: > > > > I am preparing a CRAN release of eha (a trivial change due to a change > > in the survival package), but when checking the build I get: > > > > goran@M6800:~/R$ R CMD check --as-cran eha_2.5.2.tar.gz > > ... > > * checking compilation flags used ... WARNING > > Compilation used the following non-portable flag(s): > >‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’ > > ... > > AFAIK, these are new checks. I get similar warnings on Fedora for > different flags. > > > I have never seen this before and I haven't (to my knowledge) set any > > compilation flags. It is my first build and check on a newly upgraded > > ubuntu 18.04 (no issues on 17.10). Should I perhaps ask on r-sig-debian, > > or is that observation irrelevant? > > Again AFAIK (there are package maintainers for several distros here > that can correct me if I'm wrong), each distro defines some policies > regarding compilation flags that are applied to all packages by > default. So these warnings can be safely ignored locally (or you may > override them), because those flags won't be defined on CRAN. > Yes, by default the compilation flags are those set when R was installed. You can see the current flags via R CMD config CFLAGS which in your case should include ‘-Wdate-time’ etc. As Iñaki says you can safely ignore the warning, but if you prefer to not to have any warnings you can solve this by creating a Makevars.site file with CFLAGS excluding the non-portable ones, e.g. CFLAGS=-Wall -g O0 -fPIC This should be saved in the /etc directory of R.home(), e.g. /usr/lib/R/etc. See https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation for more information. Heather > Iñaki > > > > > Göran Broström > > __ > 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] Handling packages required to build vignettes
Dear All, Since the Fedora checks on R-devel are not currently using packages from Bioconductor, one of my packages is giving new warnings. In my case (and it appears for a number of others) this is due to using BiocStyle::html_document format in the package vignette. Since BiocStyle is only required to build the vignette, I had put it in Suggests, but clearly this is not acceptable. So the question is what to do instead. Possibilities include: 1. Use bookdown::html_document2 instead. This would probably be okay to pass CRAN checks as bookdown is on CRAN, but if bookdown were not available the check would fail. The features lost are relatively minor: document styling, date line, package version line, inline table of contents, wide figures. 2. Use html_document instead. If the rmarkdown package is available, the only additional loss from 1. is figure and table referencing (the raw references are shown instead). Otherwise the knitr vignette engine reverts to R Markdown v1, losing information in the YAML header (title, authors and affiliations, abstract) and breaking citations (no references shown). As the result deteriorates moving from BiocStyle to bookdown to rmarkdown to knitr, it would be great to have a way to use the best output format given the packages available. I don't think it is possible to have conditional code in the YAML header, so I guess the only way to do this is via a custom vignette engine. Ideally this would be incorporated in knitr so that it can cope with a preference list of output formats, rather than everyone having to add custom engines to their packages. Does this sound like a good solution? If so, I'm happy to work on it and with anyone else that would like such a thing. Suggestions of how best to do this, or of better alternatives welcome. Best wishes, Heather [[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] Can roxygen2 export export() and S3method() to namespace?
Hi Jens, If you also have the line #' @export all.bit you will get export(all.bit) in the NAMESPACE file. You still need to keep #' @export to get S3method(all,bit) Best wishes, Heather On Fri, Sep 22, 2017, at 10:23 AM, Jens Oehlschlägel wrote: > Hi, > > is there a way to have roxygen2 write both export(,) > and S3method(,) to the NAMESPACE file? > > I tried > > #' @rdname Summaries > #' @export > all.bit <- function(x, range=NULL, ...) > > and only get > > S3method(all,bit) > > but not > > export(all.bit) > > Thanks for any help > > > Jens Oehlschlägel > > > P.S. > > > roxygen2 version 6.0.1 > > > > version > _ > platform x86_64-pc-linux-gnu > arch x86_64 > os linux-gnu > system x86_64, linux-gnu > status > major 3 > minor 4.1 > year 2017 > month 06 > day 30 > svn rev 72865 > language R > version.string R version 3.4.1 (2017-06-30) > nickname Single Candle > > __ > 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
