Am 16.05.24 um 11:34 schrieb Duncan Murdoch:
On 2024-05-16 4:15 a.m., Sebastian Meyer wrote:
Am 15.05.24 um 00:09 schrieb Lluís Revilla:
Hi Junhui,
There is a separate log for checking if your package works without
suggested packages: in the StepReg results
The noSuggests title leads
being installed.
Best,
Sebastian Meyer
However, it is best to not use the Bioconductor style for a package in
CRAN.
You could use the *_vignette or *_document format directly (from rmarkdown
if I recall correctly).
You will remove a dependency and avoid this problem entirely.
Best,
There is a note on your help page that says
These data are **not** immediately available in the `eglhmm` package.
which seems to be in line with the check warning.
Best wishes,
Sebastian Meyer
Am 16. Januar 2024 23:13:22 MEZ schrieb Rolf Turner :
>
>In a package that I am updating,
I think a workaround that currently works for your use case is to use
\code{fooval.\var{m}} as the label (i.e., wrapped inside \code).
Best regards,
Sebastian Meyer
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Am 14.03.22 um 11:32 schrieb Duncan Murdoch:
On 13/03/2022 8:11 p.m., Ben Bolker wrote:
After switching some vignette elements of the form
https://doi.org/10.1214/09-AOAS306
to
\doi{10.1214/09-AOAS306}
in the glmmTMB package,
GitHub Actions under Ubuntu 20.04 is throwing an error
Am 08.03.22 um 17:23 schrieb Dirk Eddelbuettel:
On 8 March 2022 at 18:46, Ivan Krylov wrote:
| On Sun, 6 Mar 2022 11:00:43 -0600
| Dirk Eddelbuettel wrote:
|
| > ==1485886== LEAK SUMMARY:
| > ==1485886==definitely lost: 32 bytes in 1 blocks
|
| > ==1485886== ERROR SUMMARY: 0 errors from 0
ate (see
https://CRAN.R-project.org/web/packages/submission_checklist.html), or
explain that the listed words were wrongly flagged (if that is the case,
by replying to the auto-check e-mail).
Best regards,
Sebastian Meyer
Thank you in advance,
Lucas.
'normal'), 1)
bold <- sample(which(!fonts$italic & fonts$weight > 'normal'), 1)
italic <- sample(which(fonts$italic & fonts$weight <= 'normal'), 1)
## Error in sample.int(length(x), size, replace, prob) :
## invalid first argument
(as there are no italic fonts).
HTH,
hould also
say something like "(for comparison)" to clarify that these results are
not the reason for the failure of the automatic pretest.
Best regards,
Sebastian Meyer
[1]
https://win-builder.r-project.org/incoming_pretest/box_1.0.3_20210912_125241/Debian/00check.log
[2]
e to the user's home filespace without
consent.
You should probably also avoid this NOTE when submitting to CRAN:
> Version contains large components (1.0.0.9000)
Best regards,
Sebastian Meyer
Am 16.08.21 um 17:37 schrieb Pooja Gangras via R-package-devel:
Hi all,
PFA the p
ce().
Best regards,
Sebastian Meyer
Kind regards,
David Norris
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.or
ls section in help("aspell-utils").
Best regards,
Sebastian Meyer
Am 16.07.21 um 18:08 schrieb Kevin R. Coombes:
Hi,
I have been updating a couple of R packages this morning. One of them
triggered a manual inspection for "possibly mis-spelled words in
DESCRIPTION&q
version currently on CRAN (which indeed gives the NOTE from
checking compiled code).
Best regards,
Sebastian Meyer
Am 15.07.21 um 11:39 schrieb Ronan GRIOT:
Dear R developpers,
I submitted my package on the CRAN and had this NOTE :
Found no calls to: ‘R_registerRoutines
he CRAN team. I can see your submission in the "inspect"
folder of the incoming queue (https://CRAN.R-project.org/incoming/).
Best regards,
Sebastian Meyer
>
> Thank you,
> Alberto
>
> [[alternative HTML version deleted]]
>
> ___
Am 21.04.21 um 08:35 schrieb Mark van der Loo:
> Hi Ott,
>
> There is no documented way to detect whether you are running on CRAN. So
> there is nothing to rely on, on that side.
>
> You can only make your own machine detectable by the test code. For example
> by setting an environment variable
Am 14.04.21 um 13:11 schrieb Rafael CM:
> Dear all,
> I am having the following warning when loading my rpackage:
>
> * checking LazyData ... WARNING
> LazyData DB of 62.1 MB without LazyDataCompression set
>
>
> I can't get to fix this problem. I have tried the tools option to optimize
>
egards,
Sebastian Meyer
PS: This is a duplicate of a recent discussion on this list, see
https://stat.ethz.ch/pipermail/r-package-devel/2021q1/006643.html
Am 11.03.21 um 21:57 schrieb Jonathan Callahan:
> I am building a package using R 4.0.4 on OS X 10.15.7.
>
> In a terminal I t
rectly?
Otherwise I guess you may have overlooked another issue somewhere in the
check log. If you included a link to the pre-test results (or a copy of
the check logs) you will likely receive more sophisticated replies.
Best regards,
Sebastian Meyer
Am 04.03.21 um 14:56 schrieb Thierry D
Am 04.03.21 um 10:24 schrieb Rolf Turner:
>
> On Thu, 4 Mar 2021 08:44:31 +0100
> Sebastian Meyer wrote:
>
>> Am 04.03.21 um 01:41 schrieb Rolf Turner:
>>>
>>> ... by using R CMD build --resave-data
>>>
>>> But I *did* use that flag wit
You'll get the NOTE when R CMD check finds that running
tools::resaveRdaFiles() on the data directory would reduce a file's size
by more than 10% with a different type of compression (if the original
size is >10KB).
Hope this helps.
Best regards,
Sebastian Meyer
>
> When I load stoma
Am 24.02.21 um 12:22 schrieb Uwe Ligges:
>
>
> On 24.02.2021 10:30, Knut Krueger wrote:
>> Am 24.02.21 um 10:05 schrieb Sebastian Meyer:
>>
>> Yes I realized that it is a problem in various packages
>> The question was, whether there is a mistake or a limit
Numbering.html#2.6.1
Finally, again citing the list info: "Please note that while
R-package-devel contributors will do their best to provide you accurate
and authoritative information, the final arbiters of CRAN submission is
the CRAN team." ;)
Best regards,
Sebastian Meyer
Am
kets.
Example: Einstein et al. (1935) .
Best regards,
Sebastian Meyer
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
versions of R, following an R-devel thread from last year:
https://stat.ethz.ch/pipermail/r-devel/2020-May/079500.html
Best regards,
Sebastian Meyer
Am 06.02.21 um 19:08 schrieb J. Aravind via R-package-devel:
> Dear R developers,
> I am facing an issue while submitting update to my p
ed (including removing outdated
> material).
Best regards,
Sebastian Meyer
>
> On Wed, Dec 16, 2020 at 8:29 AM Colin Gillespie wrote:
>>
>> Hi,
>>
>> I'm planning on using the tools::R_user_dir function in a package. But
>> for obvious reasons,
hard to recognize if you don't know).
You could apply the above function to all of "man" using, e.g.,
lapply(list.files("man", full.names=TRUE), tools::showNonASCIIfile)
at the root of your package and look for "<80><90>" in the result.
Hope this help
No need to reinvent the wheel. Göran, you already use the "specials"
feature of terms.formula to find strata():
> specials: which functions in the formula should be marked as special in
> the 'terms' object? A character vector or 'NULL'.
I think you can do the same for frailty(), for
Back to the original topic: graphics.off() is probably not what you
want. It shuts down *all* open graphics devices, not just the current
one. Example code or your plotting functions should not do that.
Calling graphics.off() in example code will also disturb standard R CMD
check. Before running
which will magically make the corresponding coerce methods available as
well.
HTH!
Sebastian Meyer
Am 21.07.20 um 00:41 schrieb Tim Keitt:
> Thanks for pointing to the bug.
>
> Now I am finding I cannot use the 'as' definitions from 'raster' without
> loading the
Yes, indeed, it is confusing. You don't need to file a new bug report, though.
There is one already:
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17179
Please feel free to comment there. This thread could serve as another
confirmation. :-)
Best regards,
Sebastian
Am 20. Juli 2020
Has the discussion about potential updates to Rd2HTML come to an end?
Should I be prepared to fix non-file package-anchored links in
(non-roxygen) packages I maintain, i.e., look up the help file structure
of the referenced packages?
I don't yet believe that R has really given up on supporting
NAMESPACE.
Best regards,
Sebastian Meyer
Am 02.06.20 um 10:01 schrieb Edgar Josymar Torrejón-Magallanes:
> Dear members
>
> I just finished some minor updates to an R package (sizeMat) I've had on
> CRAN (haven't had to update in a month). My package passes Check on my
> local mac
ow")
but the package neither defines an S4 class "bujar" nor methods for the
S4 generic "show". You should remove these two lines from your NAMESPACE.
Best regards,
Sebastian Meyer
Am 01.06.20 um 18:34 schrieb Wang, Zhu:
> Dear All,
>
> I received w
/lme4/news.html
Best regards,
Sebastian Meyer
Am 08.04.20 um 13:43 schrieb Helmut Schütz:
> Dear all,
>
> I was notified about errors:
> https://cran.r-project.org/web/checks/check_results_replicateBE.html
>
> Since I don't have access to those operating systems, I'm a
The reason that your package does not pass the incoming checks is
> * checking CRAN incoming feasibility ... NOTE
> Maintainer: ‘Cristian Quiroz-Moreno ’
>
> Uses the superseded package: ‘snow’
You would need to explain to CRAN why you need to use "snow" rather than
base R's "parallel" package.
Hi Tiago,
Then it seems likely that an update of a direct or indirect dependency
of your package causes this failure on CRAN's check system.
ggplot2 currently fails with a similar error message on CRAN
> Error: Unknown colour name: NA
Sebastian Meyer :
>I was able to reproduce the vignette error in an R-devel session with
>this environment variable set. It came from a strange polygon() call
>with x and y arguments being matrices with list elements.
>
>I cannot test at the moment. Maybe you condition on
>class(som
onsole.
>In addition, setting _R_CLASS_MATRIX_ARRAY_ to "" in onLoad did not
>solve the problem while checking as cran.
>
>I do not understand how the values I got from the debug print when
>checking
>as cran could result in the error.
>
>Any ideas?
>
>On Thu, Nov 28, 2019
This is most likely related to the recently changed class of matrices.
R> class(matrix(1))
returned "matrix" but will return c("matrix", "array") in future
versions of R. See the corresponding item in the R-devel NEWS
https://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html
To reproduce the
Dear Philipp,
What kind of problems does the incoming check report?
If they are related to your package's vignette, a simple solution would
be to transform this toy example into a package test using
tools::buildVignette in the test script, which can be run conditionally
on specific system
The failure stated in the R CMD check failure report is:
> --- failure: length > 1 in coercion to logical ---
This comes from --as-cran performing useful extra checks via setting the
environment variable _R_CHECK_LENGTH_1_LOGIC2_, which means:
> check if either argument of the binary operators
I think your package can be useful. However, I'm with CRAN here in that
I would not want my standard graphics output to be changed just because
some package ("prettyB") gets loaded, which could happen
*unintentionally* as a dependency (or a dependency of a dependency, ...)
of another package.
warning on a mac laptop, or any other system.
>
> Travers
>
> On Mon, Apr 8, 2019 at 2:27 PM Sebastian Meyer wrote:
>>
>> No false positive. This file is indeed marked as an executable file, see
>> also at https://github.com/cran/qs/blob/0.14.1/src/LZ4/LICENSE, which
No false positive. This file is indeed marked as an executable file, see
also at https://github.com/cran/qs/blob/0.14.1/src/LZ4/LICENSE, which says
> Executable File | 25 lines (20 sloc) | 1.28 KB
On a Unix-based system you could do
> chmod -x src/LZ4/LICENSE
to remove the executable bit from
plyr’
>
> How I can solve this issue?
>
> Thanks in advance
>
> Le jeudi 4 avril 2019 à 08:22:26 UTC+2, Sebastian Meyer
> a écrit :
>
>
> Note that output concerning masked objects are just messages which do
> not cause your vignette to fail. So it is not stricl
Note that output concerning masked objects are just messages which do
not cause your vignette to fail. So it is not stricly necessary to start
working on these conflicts now.
However, looking closely at the win-builder check results
The DESCRIPTION's Author field is auto-generated from Authors@R during R
CMD build. You are right, the format has slightly changed since R 3.3.3
(e.g., support for ORCID ID).
The CRAN repository policy says:
> Uploads must be source tarballs created by R CMD build and following
> the
These issues originate in a change in how R looks for S3 methods, at
least on some of the CRAN machines. To reproduce locally, you currently
need to set the environnment variable
_R_S3_METHOD_LOOKUP_BASEENV_AFTER_GLOBALENV_=TRUE
See the source code at
Hi Kevin,
I think using
> canCoerce(wv, "double") || getRversion() < "3.6.0"
could solve the issue of an inconsistent test result and is descriptive.
Best regards,
Sebastian
Am 06.12.18 um 16:59 schrieb Kevin Coombes:
> Hi,
>
> A package I recently submitted to CRAN includes an S4
49 matches
Mail list logo
