Re: [Bioc-devel] How to fix the error checked in the development version of miRspongeR
Thanks, Hervé for your reply. Now, this error has been fixed ( http://bioconductor.org/checkResults/3.16/bioc-LATEST/miRspongeR/). According to your suggestion, I have just imported the functions used in miRspongeR from SPONGE. In addition, I have removed the line 'library(SPONGE)' in vignettes. If possible, I will fork a part of functions in SPONGE instead of importing it. Regards, Junpeng. Hervé Pagès 于2022年9月24日周六 03:00写道： > On 21/09/2022 07:57, Hervé Pagès wrote: > > > Just a workaround and not a real solution but maybe try to switch the > > order of the clusterProfiler and SPONGE reports? > > > Oops, I meant "imports", not "reports". > > But, again, reducing the huge number of dependencies of both miRspongeR > and SPONGE should be a priority. Something that you might want to > discuss/coordinate with the SPONGE folks. > > Best, > > H. > > -- > Hervé Pagès > > Bioconductor Core Team > hpages.on.git...@gmail.com > > [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] Proposal to limit Internet access during package load
Iñaki, I fully agree, this a very common issue since vast majority of server deployments I have encountered don't allow internet access. In practice this means that such packages are effectively banned. I would argue that not even (1) or (2) are really an issue, because in fact the CRAN policy doesn't impose any absolute limits on size, it only states that the package should be "of minimum necessary size" which means it shouldn't waste space. If there is no way to reduce the size without impacting functionality, it's perfectly fine. That said, there are exceptions such as very large datasets (e.g., as distributed by Bioconductor) which are orders of magnitude larger than what is sustainable. I agree that it would be nice to have a mechanism for specifying such sources. So yes, I like the idea, but I'd like to see more real use cases to justify the effort. The issue with any online downloads, though, is that there is no guarantee of availability - which is real issue for reproducibility. So one could argue that if such external sources are required then they should be on a well-defined, independent, permanent storage such as Zenodo. This could be a matter of policy as opposed to the technical side above which would be adding such support to R CMD INSTALL. Cheers, Simon > On Sep 24, 2022, at 3:22 AM, Iñaki Ucar wrote: > > Hi all, > > I'd like to open this debate here, because IMO this is a big issue. > Many packages do this for various reasons, some more legitimate than > others, but I think that this shouldn't be allowed, because it > basically means that installation fails in a machine without Internet > access (which happens e.g. in Linux distro builders for security > reasons). > > Now, what if connection is suppressed during package load? There are > basically three use cases out there: > > (1) The package requires additional files for the installation (e.g. > the source code of an external library) that cannot be bundled into > the package due to CRAN restrictions (size). > (2) The package requires additional files for using it (e.g., > datasets, a JAR...) that cannot be bundled into the package due to > CRAN restrictions (size). > (3) Other spurious reasons (e.g. the maintainer decided that package > load was a good place to check an online service availability, etc.). > > Again IMO, (3) shouldn't be allowed in any case; (2) should be a > separate function that the user actively calls to download the files, > and those files should be placed into the user dir, and (3) is the > only legitimate use, but then other mechanism should be provided to > avoid connections during package load. > > My proposal to support (3) would be to add a new field in the > DESCRIPTION, "Additional_sources", which would be a comma separated > list of additional resources to download during R CMD INSTALL. Those > sources would be downloaded by R CMD INSTALL if not provided via an > option (to support offline installations), and would be placed in a > predefined place for the package to find and configure them (via an > environment variable or in a predefined subdirectory). > > This proposal has several advantages. Apart from the obvious one > (Internet access during package load can be limited without losing > current functionalities), it gives more visibility to the resources > that packages are using during the installation phase, and thus makes > those installations more reproducible and more secure. > > Best, > -- > Iñaki Úcar > > __ > 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: [Bioc-devel] How to fix the error checked in the development version of miRspongeR
On 21/09/2022 07:57, Hervé Pagès wrote: Just a workaround and not a real solution but maybe try to switch the order of the clusterProfiler and SPONGE reports? Oops, I meant "imports", not "reports". But, again, reducing the huge number of dependencies of both miRspongeR and SPONGE should be a priority. Something that you might want to discuss/coordinate with the SPONGE folks. Best, H. -- Hervé Pagès Bioconductor Core Team hpages.on.git...@gmail.com ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [R-pkg-devel] Warning about ggplot although no ggplot is used anywhere in the package
Hello again, the solution of Duncan seems to work. When resubmitting the package everything worked without any warnings, so this seems to have been some CRAN-side issue of using ggplot 3.3.4 (maybe due to caching as explained by Duncan). Thanks again for the help. Kind regards, Riko Am 23. Sept. 2022, 11:47 +0200 schrieb Duncan Murdoch : I installed your tarball, and I do see element_line being called while loading it, though I don't get the warning. The call I see is from ggplot2::theme_grey, which is called (eventually) from .onLoad in the stan package. I'm using the CRAN version of ggplot2, which is version 3.3.6. Your error message indicates that you (or winbuilder?) are using 3.4.0. It doesn't really make sense that ggplot2 would have this error in its theme_grey function in 3.4.0 (it doesn't in the current Github version), so I would guess that something has resulted in you using functions from a mix of package versions. There was a discussion recently on the R-devel list about the fact that the methods package caches versions of code from other packages, and this causes problems when those other packages change their requirements. See https://stat.ethz.ch/pipermail/r-devel/2022-September/081971.html . So I'd guess ggplot2 3.4.0 was installed on the bad machine long enough for some parts of it to be cached, but now it is back to 3.3.6. I didn't see anywhere in that discussion that you could do something to fix or work around this issue. Probably the problem will go away when all involved machines finally install ggplot2 3.4.0, but before that, I don't see anything you can do to fix it. Duncan Murdoch On 23/09/2022 2:59 a.m., Riko Kelter wrote: Hello again, thanks for the help. Here is a link to download the .tar.gz package: https://uni-siegen.sciebo.de/s/Z9BKwutIPGMieGh I followed the advice to scan the examples, source code and vignettes with the trace function for occurrences of the element_line call. Results: Only when loading either the fbst package (which also loads rstanarm) or loading rstanarm any appearance of element_line is noticed by the tracer (see below). This is regardless of whether a size option is specified or not. As mentioned earlier as a potential solution, rstanarm loads bayesplot and indeed two functions in bayesplot make use of the size option in ggplot2::element_line(). However, I do not use these functions but they are loaded when using library(rstanarm) I guess. I see no way to load rstanarm then. Any suggestions? trace(ggplot2::element_line) library(fbst) Lade nötiges Paket: cubature Lade nötiges Paket: ks Warnung: Paket ‘ks’ wurde unter R Version 4.0.5 erstellt Lade nötiges Paket: viridis Lade nötiges Paket: viridisLite Lade nötiges Paket: rstanarm Lade nötiges Paket: Rcpp Registered S3 methods overwritten by 'htmltools': method from print.html tools:rstudio print.shiny.tag tools:rstudio print.shiny.tag.list tools:rstudio Registered S3 method overwritten by 'htmlwidgets': method from print.htmlwidget tools:rstudio trace: element_line trace: element_line trace: element_line trace: element_line trace: element_line trace: element_line trace: element_line This is rstanarm version 2.21.3 - See https://mc-stan.org/rstanarm/articles/priors for changes to default priors! - Default priors may change, so it's safest to specify priors, even if equivalent to the defaults. - For execution on a local, multicore CPU with excess RAM we recommend calling options(mc.cores = parallel::detectCores()) Kind regards, Riko On Sep. 22 2022, at 5:05 pm, Alexandre Courtiol wrote: Hi Riko, That element_line() is called while loading is not a problem, this is probably just the loading of the NAMESPACE from rstanarm. There is nothing wrong with this function. The problem is only when it is used with the argument `size = ` within it. You need to figure out when that happens. ++ On Thu, 22 Sept 2022 at 15:49, Kelter, Riko mailto:riko.kel...@uni-siegen.de)> wrote: Hello everyone, thanks a lot for the help. I tried the approach to use the trace function to identify where the element_line() command is actually used. In fact, the vignette twodimfbst.Rmd is the problem, but weirdly even if I only load the rstanarm package the trace function tells me that the code is used. Thus, it seems that one cannot even load the rstanarm package without getting this warning (see the appended PDF screenshot). In fact, the element_line() is identified by the trace function only if the rstanarm or fbst package are loaded inside the vignette. I also tried to replace rstanarm with rstan instead but the same happens because both packages rely on ggplot2. I also appended the .tar.gz package file so you can check the vignette code yourself if interested. Has anyone an idea how to avoid this warning on R devel when rstanarm is loaded
Re: [Rd] Proposal to limit Internet access during package load
On Fri, 23 Sept 2022 at 17:22, Iñaki Ucar wrote: > > [snip] > Now, what if connection is suppressed during package load? There are > basically three use cases out there: > > (1) The package requires additional files for the installation (e.g. > the source code of an external library) that cannot be bundled into > the package due to CRAN restrictions (size). > (2) The package requires additional files for using it (e.g., > datasets, a JAR...) that cannot be bundled into the package due to > CRAN restrictions (size). > (3) Other spurious reasons (e.g. the maintainer decided that package > load was a good place to check an online service availability, etc.). > > Again IMO, (3) shouldn't be allowed in any case; (2) should be a > separate function that the user actively calls to download the files, > and those files should be placed into the user dir, and (3) is the > only legitimate use, but then other mechanism should be provided to > avoid connections during package load. > [snip] I meant "(1) is the only legitimate use" above. -- Iñaki Úcar __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Proposal to limit Internet access during package load
Hi all, I'd like to open this debate here, because IMO this is a big issue. Many packages do this for various reasons, some more legitimate than others, but I think that this shouldn't be allowed, because it basically means that installation fails in a machine without Internet access (which happens e.g. in Linux distro builders for security reasons). Now, what if connection is suppressed during package load? There are basically three use cases out there: (1) The package requires additional files for the installation (e.g. the source code of an external library) that cannot be bundled into the package due to CRAN restrictions (size). (2) The package requires additional files for using it (e.g., datasets, a JAR...) that cannot be bundled into the package due to CRAN restrictions (size). (3) Other spurious reasons (e.g. the maintainer decided that package load was a good place to check an online service availability, etc.). Again IMO, (3) shouldn't be allowed in any case; (2) should be a separate function that the user actively calls to download the files, and those files should be placed into the user dir, and (3) is the only legitimate use, but then other mechanism should be provided to avoid connections during package load. My proposal to support (3) would be to add a new field in the DESCRIPTION, "Additional_sources", which would be a comma separated list of additional resources to download during R CMD INSTALL. Those sources would be downloaded by R CMD INSTALL if not provided via an option (to support offline installations), and would be placed in a predefined place for the package to find and configure them (via an environment variable or in a predefined subdirectory). This proposal has several advantages. Apart from the obvious one (Internet access during package load can be limited without losing current functionalities), it gives more visibility to the resources that packages are using during the installation phase, and thus makes those installations more reproducible and more secure. Best, -- Iñaki Úcar __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] Warning about ggplot although no ggplot is used anywhere in the package
Dear Duncan, thanks for the info! This sounds quite reasonable because I used the winbuilder service provided at https://win-builder.r-project.org which I used for running tests on the current version of R-devel this warning occurred. It seems possible that some ggplot version 3.3.4 is cached there and this might be the reason why the warning is generated. On all other systems except this service for Windows binaries no warning was generated. I will resubmit the package to CRAN again and see if the warning is generated. If so, I will reply to the CRAN maintainer and see what happens. In any case, I will reply again here to inform you of the results. Kind regards, Riko Am 23.09.22 um 11:47 schrieb Duncan Murdoch: I installed your tarball, and I do see element_line being called while loading it, though I don't get the warning. The call I see is from ggplot2::theme_grey, which is called (eventually) from .onLoad in the stan package. I'm using the CRAN version of ggplot2, which is version 3.3.6. Your error message indicates that you (or winbuilder?) are using 3.4.0. It doesn't really make sense that ggplot2 would have this error in its theme_grey function in 3.4.0 (it doesn't in the current Github version), so I would guess that something has resulted in you using functions from a mix of package versions. There was a discussion recently on the R-devel list about the fact that the methods package caches versions of code from other packages, and this causes problems when those other packages change their requirements. See https://stat.ethz.ch/pipermail/r-devel/2022-September/081971.html . So I'd guess ggplot2 3.4.0 was installed on the bad machine long enough for some parts of it to be cached, but now it is back to 3.3.6. I didn't see anywhere in that discussion that you could do something to fix or work around this issue. Probably the problem will go away when all involved machines finally install ggplot2 3.4.0, but before that, I don't see anything you can do to fix it. Duncan Murdoch On 23/09/2022 2:59 a.m., Riko Kelter wrote: Hello again, thanks for the help. Here is a link to download the .tar.gz package: https://uni-siegen.sciebo.de/s/Z9BKwutIPGMieGh I followed the advice to scan the examples, source code and vignettes with the trace function for occurrences of the element_line call. Results: Only when loading either the fbst package (which also loads rstanarm) or loading rstanarm any appearance of element_line is noticed by the tracer (see below). This is regardless of whether a size option is specified or not. As mentioned earlier as a potential solution, rstanarm loads bayesplot and indeed two functions in bayesplot make use of the size option in ggplot2::element_line(). However, I do not use these functions but they are loaded when using library(rstanarm) I guess. I see no way to load rstanarm then. Any suggestions? trace(ggplot2::element_line) library(fbst) Lade nötiges Paket: cubature Lade nötiges Paket: ks Warnung: Paket ‘ks’ wurde unter R Version 4.0.5 erstellt Lade nötiges Paket: viridis Lade nötiges Paket: viridisLite Lade nötiges Paket: rstanarm Lade nötiges Paket: Rcpp Registered S3 methods overwritten by 'htmltools': method from print.html tools:rstudio print.shiny.tag tools:rstudio print.shiny.tag.list tools:rstudio Registered S3 method overwritten by 'htmlwidgets': method from print.htmlwidget tools:rstudio trace: element_line trace: element_line trace: element_line trace: element_line trace: element_line trace: element_line trace: element_line This is rstanarm version 2.21.3 - See https://mc-stan.org/rstanarm/articles/priors for changes to default priors! - Default priors may change, so it's safest to specify priors, even if equivalent to the defaults. - For execution on a local, multicore CPU with excess RAM we recommend calling options(mc.cores = parallel::detectCores()) Kind regards, Riko On Sep. 22 2022, at 5:05 pm, Alexandre Courtiol wrote: Hi Riko, That element_line() is called while loading is not a problem, this is probably just the loading of the NAMESPACE from rstanarm. There is nothing wrong with this function. The problem is only when it is used with the argument `size = ` within it. You need to figure out when that happens. ++ On Thu, 22 Sept 2022 at 15:49, Kelter, Riko mailto:riko.kel...@uni-siegen.de)> wrote: Hello everyone, thanks a lot for the help. I tried the approach to use the trace function to identify where the element_line() command is actually used. In fact, the vignette twodimfbst.Rmd is the problem, but weirdly even if I only load the rstanarm package the trace function tells me that the code is used. Thus, it seems that one cannot even load the rstanarm package without getting this warning (see the appended PDF screenshot). In fact, the element_line() is identified by the trace function only if the rstanarm or fbst package are loaded inside the
Re: [Rd] Should package version requirements assume installation from sources?
No, it looks as though this is an unrelated bit of caching being done by
rstan. During startup, it saves some ggplot defaults in an internal
environment ".rstanvis_defaults"; that captured the ggplot2 3.3.6
defaults, which caused problems when being run under ggplot2 3.4.0.
Duncan Murdoch
On 23/09/2022 5:54 a.m., Duncan Murdoch wrote:
This issue may be the culprit in an obscure bug that's been reported on
R-package-devel: see
https://stat.ethz.ch/pipermail/r-package-devel/2022q3/008481.html. It
appears that some ggplot2 version 3.4.0 code is being run even though
3.3.6 is the version on CRAN, and 3.3.6 is *also* being run in the same
check session.
Duncan Murdoch
On 14/09/2022 6:04 a.m., Duncan Murdoch wrote:
On 13/09/2022 5:45 p.m., Mikael Jagan wrote:
[Arguably also appropriate for R-package-devel, but posted to R-devel
as the discussion is aimed primarily at "experts" ... ]
We, the authors of Matrix, have encountered a somewhat subtle issue
induced by caching of S4 classes and methods in package namespaces.
The namespaces of three reverse dependent packages (SeuratObject, conText,
mcmcsae) cache the formal definition of our virtual class Matrix (and some
subclasses). For example:
> ns <- asNamespace("SeuratObject")
> grep("^[.]__C__.*Matrix$", names(ns), value = TRUE)
[1] ".__C__dMatrix" ".__C__compMatrix"".__C__AnyMatrix"
[4] ".__C__generalMatrix" ".__C__CsparseMatrix" ".__C__sparseMatrix"
[7] ".__C__dsparseMatrix" ".__C__Matrix"
The cached definition (which includes a _validity method_) is obtained from
the version of Matrix available when the reverse dependent package was built
from sources. For example, if SeuratObject was built under Matrix 1.4-1,
then we get:
> getValidity(ns$.__C__Matrix)
function (object)
{
if (!isTRUE(r <- .Call(Dim_validate, object, "Matrix")))
r
else .Call(dimNames_validate, object)
}
whereas if SeuratObject was built under Matrix >= 1.5-0, then we get:
> getValidity(ns$.__C__Matrix)
function (object)
.Call(Matrix_validate, object)
There are two "questions" here:
1. The symbol 'Matrix_validate' is not defined until Matrix 1.5-0.
Is it necessary, for this reason alone, for SeuratObject to have
'Imports: Matrix (>= 1.5-0)'? Or can SeuratObject continue using
'Imports: Matrix (>= 1.3-3)', at the risk of errors like
> Error: object 'Matrix_validate' not found
(as already seen here: https://stackoverflow.com/questions/73700130)?
Note that this error would not occur for anyone installing SeuratObject
from sources, unless they decide to _downgrade_ Matrix after doing so.
Hence this primarily concerns Windows and macOS where R users would
typically install a binary built by CRAN (i.e., not on their system).
We are aware that package TMB tests in .onLoad() that the current Matrix
version is equal to or greater than the version available at build time,
thus avoiding a "strict" version requirement, but do not want this
practice
to spread ...
2. For how long should Matrix retain the superceded 'Dim_validate' and
'dimNames_validate', in order to ensure that "stale" cached validity
methods continue to work?
We hope that this discussion will highlight the potential ramifications
of importing classes and methods from other packages, and having one's
classes and methods imported _by_ other packages, especially for version
requirements.
This sounds like a bug or bad design in the S4 system, i.e. caching
things without a way to detect or update when the cache becomes stale.
Is it really necessary to cache things as part of the binary package, or
could they be put in place when needed using lazy loading, getting a
copy from the loaded copy of Matrix?
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Should package version requirements assume installation from sources?
This issue may be the culprit in an obscure bug that's been reported on
R-package-devel: see
https://stat.ethz.ch/pipermail/r-package-devel/2022q3/008481.html. It
appears that some ggplot2 version 3.4.0 code is being run even though
3.3.6 is the version on CRAN, and 3.3.6 is *also* being run in the same
check session.
Duncan Murdoch
On 14/09/2022 6:04 a.m., Duncan Murdoch wrote:
On 13/09/2022 5:45 p.m., Mikael Jagan wrote:
[Arguably also appropriate for R-package-devel, but posted to R-devel
as the discussion is aimed primarily at "experts" ... ]
We, the authors of Matrix, have encountered a somewhat subtle issue
induced by caching of S4 classes and methods in package namespaces.
The namespaces of three reverse dependent packages (SeuratObject, conText,
mcmcsae) cache the formal definition of our virtual class Matrix (and some
subclasses). For example:
> ns <- asNamespace("SeuratObject")
> grep("^[.]__C__.*Matrix$", names(ns), value = TRUE)
[1] ".__C__dMatrix" ".__C__compMatrix"".__C__AnyMatrix"
[4] ".__C__generalMatrix" ".__C__CsparseMatrix" ".__C__sparseMatrix"
[7] ".__C__dsparseMatrix" ".__C__Matrix"
The cached definition (which includes a _validity method_) is obtained from
the version of Matrix available when the reverse dependent package was built
from sources. For example, if SeuratObject was built under Matrix 1.4-1,
then we get:
> getValidity(ns$.__C__Matrix)
function (object)
{
if (!isTRUE(r <- .Call(Dim_validate, object, "Matrix")))
r
else .Call(dimNames_validate, object)
}
whereas if SeuratObject was built under Matrix >= 1.5-0, then we get:
> getValidity(ns$.__C__Matrix)
function (object)
.Call(Matrix_validate, object)
There are two "questions" here:
1. The symbol 'Matrix_validate' is not defined until Matrix 1.5-0.
Is it necessary, for this reason alone, for SeuratObject to have
'Imports: Matrix (>= 1.5-0)'? Or can SeuratObject continue using
'Imports: Matrix (>= 1.3-3)', at the risk of errors like
> Error: object 'Matrix_validate' not found
(as already seen here: https://stackoverflow.com/questions/73700130)?
Note that this error would not occur for anyone installing SeuratObject
from sources, unless they decide to _downgrade_ Matrix after doing so.
Hence this primarily concerns Windows and macOS where R users would
typically install a binary built by CRAN (i.e., not on their system).
We are aware that package TMB tests in .onLoad() that the current Matrix
version is equal to or greater than the version available at build time,
thus avoiding a "strict" version requirement, but do not want this
practice
to spread ...
2. For how long should Matrix retain the superceded 'Dim_validate' and
'dimNames_validate', in order to ensure that "stale" cached validity
methods continue to work?
We hope that this discussion will highlight the potential ramifications
of importing classes and methods from other packages, and having one's
classes and methods imported _by_ other packages, especially for version
requirements.
This sounds like a bug or bad design in the S4 system, i.e. caching
things without a way to detect or update when the cache becomes stale.
Is it really necessary to cache things as part of the binary package, or
could they be put in place when needed using lazy loading, getting a
copy from the loaded copy of Matrix?
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] Warning about ggplot although no ggplot is used anywhere in the package
I installed your tarball, and I do see element_line being called while loading it, though I don't get the warning. The call I see is from ggplot2::theme_grey, which is called (eventually) from .onLoad in the stan package. I'm using the CRAN version of ggplot2, which is version 3.3.6. Your error message indicates that you (or winbuilder?) are using 3.4.0. It doesn't really make sense that ggplot2 would have this error in its theme_grey function in 3.4.0 (it doesn't in the current Github version), so I would guess that something has resulted in you using functions from a mix of package versions. There was a discussion recently on the R-devel list about the fact that the methods package caches versions of code from other packages, and this causes problems when those other packages change their requirements. See https://stat.ethz.ch/pipermail/r-devel/2022-September/081971.html . So I'd guess ggplot2 3.4.0 was installed on the bad machine long enough for some parts of it to be cached, but now it is back to 3.3.6. I didn't see anywhere in that discussion that you could do something to fix or work around this issue. Probably the problem will go away when all involved machines finally install ggplot2 3.4.0, but before that, I don't see anything you can do to fix it. Duncan Murdoch On 23/09/2022 2:59 a.m., Riko Kelter wrote: Hello again, thanks for the help. Here is a link to download the .tar.gz package: https://uni-siegen.sciebo.de/s/Z9BKwutIPGMieGh I followed the advice to scan the examples, source code and vignettes with the trace function for occurrences of the element_line call. Results: Only when loading either the fbst package (which also loads rstanarm) or loading rstanarm any appearance of element_line is noticed by the tracer (see below). This is regardless of whether a size option is specified or not. As mentioned earlier as a potential solution, rstanarm loads bayesplot and indeed two functions in bayesplot make use of the size option in ggplot2::element_line(). However, I do not use these functions but they are loaded when using library(rstanarm) I guess. I see no way to load rstanarm then. Any suggestions? trace(ggplot2::element_line) library(fbst) Lade nötiges Paket: cubature Lade nötiges Paket: ks Warnung: Paket ‘ks’ wurde unter R Version 4.0.5 erstellt Lade nötiges Paket: viridis Lade nötiges Paket: viridisLite Lade nötiges Paket: rstanarm Lade nötiges Paket: Rcpp Registered S3 methods overwritten by 'htmltools': method from print.html tools:rstudio print.shiny.tag tools:rstudio print.shiny.tag.list tools:rstudio Registered S3 method overwritten by 'htmlwidgets': method from print.htmlwidget tools:rstudio trace: element_line trace: element_line trace: element_line trace: element_line trace: element_line trace: element_line trace: element_line This is rstanarm version 2.21.3 - See https://mc-stan.org/rstanarm/articles/priors for changes to default priors! - Default priors may change, so it's safest to specify priors, even if equivalent to the defaults. - For execution on a local, multicore CPU with excess RAM we recommend calling options(mc.cores = parallel::detectCores()) Kind regards, Riko On Sep. 22 2022, at 5:05 pm, Alexandre Courtiol wrote: Hi Riko, That element_line() is called while loading is not a problem, this is probably just the loading of the NAMESPACE from rstanarm. There is nothing wrong with this function. The problem is only when it is used with the argument `size = ` within it. You need to figure out when that happens. ++ On Thu, 22 Sept 2022 at 15:49, Kelter, Riko mailto:riko.kel...@uni-siegen.de)> wrote: Hello everyone, thanks a lot for the help. I tried the approach to use the trace function to identify where the element_line() command is actually used. In fact, the vignette twodimfbst.Rmd is the problem, but weirdly even if I only load the rstanarm package the trace function tells me that the code is used. Thus, it seems that one cannot even load the rstanarm package without getting this warning (see the appended PDF screenshot). In fact, the element_line() is identified by the trace function only if the rstanarm or fbst package are loaded inside the vignette. I also tried to replace rstanarm with rstan instead but the same happens because both packages rely on ggplot2. I also appended the .tar.gz package file so you can check the vignette code yourself if interested. Has anyone an idea how to avoid this warning on R devel when rstanarm is loaded inside a vignette? I currently see no way to solve this except for not using rstanarm which is inconvenient. Kind regards, Riko From: Alexandre Courtiol mailto:alexandre.court...@gmail.com)> Sent: 22 September 2022 14:06 To: Kelter, Riko Cc: r-package-devel@r-project.org (mailto:r-package-devel@r-project.org) Subject: Re: [R-pkg-devel] Warning about ggplot although no ggplot is used anywhere in the package In rstanarm,
Re: [Rd] Date method of as.POSIXct does not respect tz
> Kurt Hornik
> on Fri, 23 Sep 2022 09:57:49 +0200 writes:
> Martin Maechler writes:
> Currently in R-devel,
R> as.POSIXlt.Date
> function (x, ...)
> {
>if (any((y <- unclass(x)) > .Machine$integer.max, na.rm = TRUE))
> as.POSIXlt(.POSIXct(y * 86400), tz = "UTC")
>else .Internal(Date2POSIXlt(x))
> }
R> as.POSIXct.Date
> function (x, ...)
> .POSIXct(unclass(x) * 86400)
> Adding tz to the latter is easy, and the former could do the if() part
> also with a given tz without needing to change the .Internal?
Genau! Even more elegantly than I first thought when I wrote
"post-processing":
The following even adds internal consistency inside as.POSIXlt.Date() :
as.POSIXlt.Date <- function(x, tz = "UTC", ...) {
as.POSIXlt(if(any((y <- unclass(x)) > .Machine$integer.max, na.rm = TRUE))
.POSIXct(y * 86400)
else
.Internal(Date2POSIXlt(x))
, tz = tz)
}
because now, tz is even *formally* treated the same in both
cases (whereas previously it only appeared visually in one case).
So probably, another reason to go there.
Note that I also think we'd keep thetz = "UTZ"
default argument, even when the
other as.POSIX[cl]t() methods have 'tz = ""'
> Roland Fuß
> on Tue, 20 Sep 2022 09:25:52 +0200 writes:
>>> Hello, May I follow up on this? Has it fallen through the
>>> cracks or were there considerations against passing `tz`
>>> to `.POSIXct`?
>>> Regards,
>>> Roland
>> Hmm... I don't remember even though I had replied positively
>> to your question in May 2018.
>> PROS (for allowing 'tz') to be passed to
>> as.POSIXct.Date() and hence ideally also to as.POSIXlt.Date()
>> 1) as.POSIXct() and as.POSIXlt() all show with a 'tz' argument
>> on the help page, and hence for consistency users should
>> really expect that 'tz = ".."' also works in these two cases:
>> Usage:
>> as.POSIXct(x, tz = "", ...)
>> as.POSIXlt(x, tz = "", ...)
>> ## S3 method for class 'character'
>> as.POSIXlt(x, tz = "", format,
>> tryFormats = c("%Y-%m-%d %H:%M:%OS",
>> "%Y/%m/%d %H:%M:%OS",
>> "%Y-%m-%d %H:%M",
>> "%Y/%m/%d %H:%M",
>> "%Y-%m-%d",
>> "%Y/%m/%d"),
>> optional = FALSE, ...)
>> ## Default S3 method:
>> as.POSIXlt(x, tz = "",
>> optional = FALSE, ...)
>> ## S3 method for class 'numeric'
>> as.POSIXlt(x, tz = "", origin, ...)
>> 2) It is easy to be implemented for as.POSIXct() as you found
>> already in 2018.
>> CONS:
>> -
>> 3) The 'Details:' section on the help page,
>> end of 1st paragraph says
>> Dates without times are treated as being at midnight UTC.
>> So the current hardwired behavior is documented.
>> 4a) For as.POSIXlt.Date() to allow passing 'tz' needs changes
>> in the C code, i.e., is considerable more work than for the
as.POSIXct(),
>> (or actually just post-processing in the R code, much less work)
>> 4b) Only changing the behavior for as.POSIXct() but not for as.POSIXlt()
>> is also an inconsistency.
>> My personal inclination would still be to do the change,
>> by giving most weight to '1)' above.
>> What do other experienced R developers think ?
>> Martin
>>> Am 17.05.2018 um 19:55 schrieb Martin Maechler:
> Roland Fuß on Wed, 16 May 2018 17:21:07 +0200
> writes:
> R 3.5.0 Is it intended that the Date method of
as.POSIXct > does not respect the tz parameter? I suggest
changing > as.POSIXct.Date
which is
function (x, ...) .POSIXct(unclass(x) * 86400)
> to this:
function (x, tz = "", ...) .POSIXct(unclass(x) * 86400,
tz = tz)
or rather just forward the '...', i.e., use
function (x, ...) .POSIXct(unclass(x) * 86400, ...)
??
> Currently, the best workaround seems to be using the >
character method if one doesn't want the default timezone
> (which is often an annoying DST timezone).
> This came up on Stack Overflow: >
https://stackoverflow.com/q/50373340/1412059
> --
> Roland
Thank you Roland for your notice (and the help on SO).
Best, Martin
>>> --
>>> Dr. Roland Fuß
>>> Thünen-Institut für Agrarklimaschutz/ Thünen Institute of
>>> Climate-Smart Agriculture
>>> Bundesallee 65 D-38116 Braunschweig, Germany
>>> Tel.: ++49 531 596 2627 Fax: ++49 531 596 2699 Email:
>>> roland.f...@thuenen.de
>>> Arbeitsgruppe "Emissionsberichterstattung"/ Working group
>>> "Emission Inventories" Email:
>>> emissionsinvent...@thuenen.de
>>> Das Johann Heinrich
Re: [Rd] Problem with accessibility in R 4.2.0 and 4.2.1.
Hello all, I can confirm Andrew's assessment of the situation for screen reader users (both JAWS and NVDA) for R GUI version 4.2.1; I don't intend to go back and verify how/when the problem first arose though. The situation is not new, or at least the same experience was evident well before now. When I started using R around 2005/6, the experience we now see today was how I found the GUI then. I investigated the terminal which was a huge success and never looked back. I tracked how the R GUI was going because my students would be using it, and at some stage, the way the GUI cursor behaved changed. If I recall correctly, the physical appearance of the cursor also altered at the same time. I still update versions regularly to stay one step of my students (all sighted) but because no one uses the R GUI, my efforts to trace its behaviour have been dwindling over the last five or so years. I don't need to check the RStudio behaviour because I can't, my colleagues are doing so, and I know it won't change for blind people anytime soon. The terminal has behaved consistently all that time. It has some minor differences between JAWS and NVDA, but the user knows what their screen reader is doing so the differences have relatively minor impact. It remains how I use R and therefore what I recommend for other blind users. N.B. I also strongly recommend R markdown files over R scripts. The experience in the GUI was human dependent, with the choice of screen reader and the skill level of the users with their screen reader both having an impact on the overall user experience. For many years, NVDA users were better off in the GUI than in the terminal, while most JAWS users were happier in the terminal. It has been fairly fluid though so my advice has been to try, using the existing skills and screen reader, but to be prepared to revert to the terminal fairly quickly. Minor variations in the interactions of R GUI and the various screen readers mean the difference between JAWS and NVDA were very similar prior to v4.2.0 to the extent that I would say the experience had converged quite nicely. RStudio has not made any significant progress in making its IDE more accessible, and I fear that it never will. I have tested other front ends and none have yet met accessibility standards. The problem with most of the front ends is that they are using development toolkits (such as QT) that do not speak with screen readers straight out of the box. I mentioned this in my R Journal article back in 2013. I fear that the development toolkit problem is what compromises accessibility of R GUI too. In a discussion I had with Duncan at UseR 2015, it was obvious to me that nothing intentional had been done to the R GUI to improve my initial experience to the situation Andrew has been enjoying. For that reason, I suspect that there is room for something different in the background, as against any explicit action taken by the R developments, which have (unfortunately) taken us backwards. Andrew: I am confident you can move to the terminal without requiring help, but grabbing the latest development version of BrailleR off GitHub will give you some functions that will save a bit of effort. We might arrange a voice call next week for an ongoing discussion. Tomas: I'm not able to help with your suggestion, mainly because I don't understand the nuts and bolts of it. I do believe though that the cursor focus is a critical factor, but that the cursor being used by the screen reader software is different to the cursor being used by the sighted users. When I switch from the active cursor to the screen readers' review mode, the screen readers both take me back to the top left of the window under the menu bar. Has anything changed in the visual appearance of the cursor from v4.1.3 to v4.2.0? I ask because it is the symptom. Peter: Thank you very much for actively bringing me into this thread. I don't know why I hadn't seen Andrew's first message given I get other list traffic. Jonathan -Original Message- From: peter dalgaard Sent: Friday, 23 September 2022 4:24 am To: Andrew Hart Cc: R-devel@r-project.org; Tomas Kalibera ; Jonathan Godfrey Subject: Re: [Rd] Problem with accessibility in R 4.2.0 and 4.2.1. Tomas Kalibera has related that he has some scars from fighting with some unexpected interactions between UTF-8 and the GraphApp library that is used for RGui and I think he said that screen readers were involved. I wouldn't be surprised if this is a leftover issue. (This is obviously a kind of issue that non-blind users don't "see" :-) ). Would it work for you to use the terminal application (the "DOS box", or whatever it is called these days) until the issue gets fixed? In general, I would expect your go-to guy for blindness-related issues to be Jonathon Godfrey (cc'ed). Perhaps he can offer some advice. -pd > On 22 Sep 2022, at 15:48 , Andrew Hart via R-devel > wrote:
Re: [Rd] Date method of as.POSIXct does not respect tz
> Martin Maechler writes:
Currently in R-devel,
R> as.POSIXlt.Date
function (x, ...)
{
if (any((y <- unclass(x)) > .Machine$integer.max, na.rm = TRUE))
as.POSIXlt(.POSIXct(y * 86400), tz = "UTC")
else .Internal(Date2POSIXlt(x))
}
R> as.POSIXct.Date
function (x, ...)
.POSIXct(unclass(x) * 86400)
Adding tz to the latter is easy, and the former could do the if() part
also with a given tz without needing to change the .Internal?
Best
-k
> Roland Fuß
> on Tue, 20 Sep 2022 09:25:52 +0200 writes:
>> Hello, May I follow up on this? Has it fallen through the
>> cracks or were there considerations against passing `tz`
>> to `.POSIXct`?
>> Regards,
>> Roland
> Hmm... I don't remember even though I had replied positively
> to your question in May 2018.
> PROS (for allowing 'tz') to be passed to
> as.POSIXct.Date() and hence ideally also to as.POSIXlt.Date()
> 1) as.POSIXct() and as.POSIXlt() all show with a 'tz' argument
> on the help page, and hence for consistency users should
> really expect that 'tz = ".."' also works in these two cases:
> Usage:
> as.POSIXct(x, tz = "", ...)
> as.POSIXlt(x, tz = "", ...)
> ## S3 method for class 'character'
> as.POSIXlt(x, tz = "", format,
> tryFormats = c("%Y-%m-%d %H:%M:%OS",
>"%Y/%m/%d %H:%M:%OS",
>"%Y-%m-%d %H:%M",
>"%Y/%m/%d %H:%M",
>"%Y-%m-%d",
>"%Y/%m/%d"),
> optional = FALSE, ...)
> ## Default S3 method:
> as.POSIXlt(x, tz = "",
> optional = FALSE, ...)
> ## S3 method for class 'numeric'
> as.POSIXlt(x, tz = "", origin, ...)
> 2) It is easy to be implemented for as.POSIXct() as you found
>already in 2018.
> CONS:
> -
> 3) The 'Details:' section on the help page,
>end of 1st paragraph says
> Dates without times are treated as being at midnight UTC.
>So the current hardwired behavior is documented.
> 4a) For as.POSIXlt.Date() to allow passing 'tz' needs changes
>in the C code, i.e., is considerable more work than for the as.POSIXct(),
>(or actually just post-processing in the R code, much less work)
> 4b) Only changing the behavior for as.POSIXct() but not for as.POSIXlt()
> is also an inconsistency.
> My personal inclination would still be to do the change,
> by giving most weight to '1)' above.
> What do other experienced R developers think ?
> Martin
>> Am 17.05.2018 um 19:55 schrieb Martin Maechler:
Roland Fuß on Wed, 16 May 2018 17:21:07 +0200
writes:
>>> > R 3.5.0 Is it intended that the Date method of
>>> as.POSIXct > does not respect the tz parameter? I suggest
>>> changing > as.POSIXct.Date
>>>
>>> which is
>>>
>>> function (x, ...) .POSIXct(unclass(x) * 86400)
>>>
>>> > to this:
>>>
>>> function (x, tz = "", ...) .POSIXct(unclass(x) * 86400,
>>> tz = tz)
>>>
>>> or rather just forward the '...', i.e., use
>>>
>>> function (x, ...) .POSIXct(unclass(x) * 86400, ...)
>>>
>>> ??
>>>
>>> > Currently, the best workaround seems to be using the >
>>> character method if one doesn't want the default timezone
>>> > (which is often an annoying DST timezone).
>>>
>>> > This came up on Stack Overflow: >
>>> https://stackoverflow.com/q/50373340/1412059
>>>
>>> > --
>>> > Roland
>>>
>>> Thank you Roland for your notice (and the help on SO).
>>>
>>> Best, Martin
>> --
>> Dr. Roland Fuß
>> Thünen-Institut für Agrarklimaschutz/ Thünen Institute of
>> Climate-Smart Agriculture
>> Bundesallee 65 D-38116 Braunschweig, Germany
>> Tel.: ++49 531 596 2627 Fax: ++49 531 596 2699 Email:
>> roland.f...@thuenen.de
>> Arbeitsgruppe "Emissionsberichterstattung"/ Working group
>> "Emission Inventories" Email:
>> emissionsinvent...@thuenen.de
>> Das Johann Heinrich von Thünen-Institut,
>> Bundesforschungsinstitut für Ländliche Räume, Wald und
>> Fischerei – kurz: Thünen-Institut – besteht aus 15
>> Fachinstituten, die in den Bereichen Ökonomie, Ökologie
>> und Technologie forschen und die Politik beraten.
>> The Johann Heinrich von Thünen Institute, Federal Research
>> Institute for Rural Areas, Forestry and Fisheries – Thünen
>> Institute in brief – consists of 15 specialized institutes
>> that carry out research and provide policy advice in the
>> fields of economy, ecology and technology.
> __
> 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] Date method of as.POSIXct does not respect tz
> Roland Fuß
> on Tue, 20 Sep 2022 09:25:52 +0200 writes:
> Hello, May I follow up on this? Has it fallen through the
> cracks or were there considerations against passing `tz`
> to `.POSIXct`?
> Regards,
> Roland
Hmm... I don't remember even though I had replied positively
to your question in May 2018.
PROS (for allowing 'tz') to be passed to
as.POSIXct.Date() and hence ideally also to as.POSIXlt.Date()
1) as.POSIXct() and as.POSIXlt() all show with a 'tz' argument
on the help page, and hence for consistency users should
really expect that 'tz = ".."' also works in these two cases:
Usage:
as.POSIXct(x, tz = "", ...)
as.POSIXlt(x, tz = "", ...)
## S3 method for class 'character'
as.POSIXlt(x, tz = "", format,
tryFormats = c("%Y-%m-%d %H:%M:%OS",
"%Y/%m/%d %H:%M:%OS",
"%Y-%m-%d %H:%M",
"%Y/%m/%d %H:%M",
"%Y-%m-%d",
"%Y/%m/%d"),
optional = FALSE, ...)
## Default S3 method:
as.POSIXlt(x, tz = "",
optional = FALSE, ...)
## S3 method for class 'numeric'
as.POSIXlt(x, tz = "", origin, ...)
2) It is easy to be implemented for as.POSIXct() as you found
already in 2018.
CONS:
-
3) The 'Details:' section on the help page,
end of 1st paragraph says
Dates without times are treated as being at midnight UTC.
So the current hardwired behavior is documented.
4a) For as.POSIXlt.Date() to allow passing 'tz' needs changes
in the C code, i.e., is considerable more work than for the as.POSIXct(),
(or actually just post-processing in the R code, much less work)
4b) Only changing the behavior for as.POSIXct() but not for as.POSIXlt()
is also an inconsistency.
My personal inclination would still be to do the change,
by giving most weight to '1)' above.
What do other experienced R developers think ?
Martin
> Am 17.05.2018 um 19:55 schrieb Martin Maechler:
>>> Roland Fuß on Wed, 16 May 2018 17:21:07 +0200
>>> writes:
>> > R 3.5.0 Is it intended that the Date method of
>> as.POSIXct > does not respect the tz parameter? I suggest
>> changing > as.POSIXct.Date
>>
>> which is
>>
>> function (x, ...) .POSIXct(unclass(x) * 86400)
>>
>> > to this:
>>
>> function (x, tz = "", ...) .POSIXct(unclass(x) * 86400,
>> tz = tz)
>>
>> or rather just forward the '...', i.e., use
>>
>> function (x, ...) .POSIXct(unclass(x) * 86400, ...)
>>
>> ??
>>
>> > Currently, the best workaround seems to be using the >
>> character method if one doesn't want the default timezone
>> > (which is often an annoying DST timezone).
>>
>> > This came up on Stack Overflow: >
>> https://stackoverflow.com/q/50373340/1412059
>>
>> > --
>> > Roland
>>
>> Thank you Roland for your notice (and the help on SO).
>>
>> Best, Martin
> --
> Dr. Roland Fuß
> Thünen-Institut für Agrarklimaschutz/ Thünen Institute of
> Climate-Smart Agriculture
> Bundesallee 65 D-38116 Braunschweig, Germany
> Tel.: ++49 531 596 2627 Fax: ++49 531 596 2699 Email:
> roland.f...@thuenen.de
> Arbeitsgruppe "Emissionsberichterstattung"/ Working group
> "Emission Inventories" Email:
> emissionsinvent...@thuenen.de
> Das Johann Heinrich von Thünen-Institut,
> Bundesforschungsinstitut für Ländliche Räume, Wald und
> Fischerei – kurz: Thünen-Institut – besteht aus 15
> Fachinstituten, die in den Bereichen Ökonomie, Ökologie
> und Technologie forschen und die Politik beraten.
> The Johann Heinrich von Thünen Institute, Federal Research
> Institute for Rural Areas, Forestry and Fisheries – Thünen
> Institute in brief – consists of 15 specialized institutes
> that carry out research and provide policy advice in the
> fields of economy, ecology and technology.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [R-pkg-devel] Warning about ggplot although no ggplot is used anywhere in the package
Hello again,
thanks for the help. Here is a link to download the .tar.gz package:
https://uni-siegen.sciebo.de/s/Z9BKwutIPGMieGh
I followed the advice to scan the examples, source code and vignettes with the
trace function for occurrences of the element_line call.
Results: Only when loading either the fbst package (which also loads rstanarm)
or loading rstanarm any appearance of element_line is noticed by the tracer
(see below). This is regardless of whether a size option is specified or not.
As mentioned earlier as a potential solution, rstanarm loads bayesplot and
indeed two functions in bayesplot make use of the size option in
ggplot2::element_line(). However, I do not use these functions but they are
loaded when using library(rstanarm) I guess. I see no way to load rstanarm
then. Any suggestions?
> trace(ggplot2::element_line)
> library(fbst)
Lade nötiges Paket: cubature
Lade nötiges Paket: ks
Warnung: Paket ‘ks’ wurde unter R Version 4.0.5 erstellt
Lade nötiges Paket: viridis
Lade nötiges Paket: viridisLite
Lade nötiges Paket: rstanarm
Lade nötiges Paket: Rcpp
Registered S3 methods overwritten by 'htmltools':
method from print.html
tools:rstudio
print.shiny.tag
tools:rstudio
print.shiny.tag.list
tools:rstudio
Registered S3 method overwritten by 'htmlwidgets':
method from print.htmlwidget tools:rstudio
trace: element_line
trace: element_line
trace: element_line
trace: element_line
trace: element_line
trace: element_line
trace: element_line
This is rstanarm version 2.21.3
-
See https://mc-stan.org/rstanarm/articles/priors for changes to default priors!
-
Default priors may change, so it's safest to specify priors, even if equivalent
to
the defaults.
- For execution on a local, multicore CPU with excess RAM we recommend
calling
options(mc.cores = parallel::detectCores())
Kind regards,
Riko
On Sep. 22 2022, at 5:05 pm, Alexandre Courtiol
wrote:
> Hi Riko,
> That element_line() is called while loading is not a problem, this is
> probably just the loading of the NAMESPACE from rstanarm.
>
> There is nothing wrong with this function.
> The problem is only when it is used with the argument `size = ` within it.
> You need to figure out when that happens.
> ++
>
>
>
>
> On Thu, 22 Sept 2022 at 15:49, Kelter, Riko (mailto:riko.kel...@uni-siegen.de)> wrote:
> > Hello everyone,
> >
> >
> >
> > thanks a lot for the help.
> >
> >
> > I tried the approach to use the trace function to identify where the
> > element_line() command is actually used. In fact, the vignette
> > twodimfbst.Rmd is the problem, but weirdly even if I only load the rstanarm
> > package the trace function tells me that the code is used.
> >
> >
> > Thus, it seems that one cannot even load the rstanarm package without
> > getting this warning (see the appended PDF screenshot). In fact, the
> > element_line() is identified by the trace function only if the rstanarm or
> > fbst package are loaded inside the vignette. I also tried to replace
> > rstanarm with rstan instead but the same happens because both packages rely
> > on ggplot2.
> >
> >
> > I also appended the .tar.gz package file so you can check the vignette code
> > yourself if interested.
> >
> >
> > Has anyone an idea how to avoid this warning on R devel when rstanarm is
> > loaded inside a vignette? I currently see no way to solve this except for
> > not using rstanarm which is inconvenient.
> >
> >
> > Kind regards,
> > Riko
> >
> >
> >
> >
> >
> >
> >
> > From: Alexandre Courtiol > (mailto:alexandre.court...@gmail.com)>
> > Sent: 22 September 2022 14:06
> > To: Kelter, Riko
> > Cc: r-package-devel@r-project.org (mailto:r-package-devel@r-project.org)
> > Subject: Re: [R-pkg-devel] Warning about ggplot although no ggplot is used
> > anywhere in the package
> >
> >
> > In rstanarm, the function posterior_vs_prior and pp_validate use
> > bayesplot::grid_lines which is defined as:
> >
> > function (color = "gray50", size = 0.2)
> > {
> > theme(panel.grid.major = element_line(color = color, size = size),
> > panel.grid.minor = element_line(color = color, size = size *
> > 0.5))
> > }
> >
> >
> > so bayesplot seems to be the culprit if you use these functions.
> >
> > On Thu, 22 Sept 2022 at 13:51, Alexandre Courtiol
> > mailto:alexandre.court...@gmail.com)> wrote:
> > > You could trace the ggplot function using trace(ggplot2::element_line)
> > > and then load the package and run your examples.
> > > Whenever the function is used in the background, it should tell you.
> > > ++
> > >
> > >
> > >
> > >
> > > On Thu, 22 Sept 2022 at 13:40, Duncan Murdoch > > (mailto:murdoch.dun...@gmail.com)> wrote:
> > > > On 21/09/2022 5:09 p.m., Riko Kelter wrote:
> > > > > Hello everyone,
> > > > >
> > > > > I ran R CMD check --as-cran without any errors. However, when I run a
> > > > > check on the current version of r-devel I obtain the following
> > > > > strange error about some ggplot function:
> > > > > * installing *source* package 'fbst' ...
> >
