emove
that dependency (or move it to Suggests, and check for it before using).
If that's not feasible, then you just need to wait for it to become
available. Based on its status page, it shouldn't be long. Try
submitting again tomorrow?
Duncan Murdoch
Thanks
Andrew
On Wed, Apr
or.org/. When
you do, please show the command you used for the install; it's possible
a simple change there will fix things.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
eaders nor .Internal() nor .Call() etc
calls to base packages. Also, ::: should not be used to access
undocumented/internal objects in base packages (nor should other means
of access be employed). Such usages can cause packages to break at any
time, eve
On 31/03/2021 8:28 a.m., Tim Hulsen wrote:
I don’t believe I do anything with lazydata.
Your DESCRIPTION file specifies it is TRUE.
Duncan Murdoch
https://cran.r-project.org/web/checks/check_results_BioVenn.html
<https://cran.r-project.org/web/checks/check_results_BioVenn.html>
bit more
information, e.g. a link to your source.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
On 30/03/2021 12:36 p.m., Duncan Murdoch wrote:
On 30/03/2021 10:39 a.m., Floris Vanderhaeghe wrote:
I just tried \doi{10.5281/zenodo.2611233} and it worked.
Sure, but what about making a hyperlink to
https://doi.org/10.5281/zenodo.2611233 while showing "text" in the
documentat
o, I don't think there's currently any way to do that. Your choices
are probably to link to whatever the DOI links to, e.g.
\href{https://zenodo.org/record/2682323}{text} and live with the fact
that the URL might change tomorrow, or show the D
.
I just tried \doi{10.5281/zenodo.2611233} and it worked.
Duncan Murdoch
Perhaps a 'https://doi.org' address which does not show as such in the
documentation (because of the clickable label) should still be allowed.
With regards
Floris Vanderhaeghe
_
ee where the error occurred.
The problem here is that the "output_handler" argument is new in downlit
0.2.1.9000, and we aren't using that version.
Should R object to the incompatible versions here?
Duncan Murdoch
__
R-package-devel@r
omewhere in your main code to silence the
message. But it's probably better to leave it in Suggests.
As to the "wrong package version" issue: CRAN isn't showing 1.0.5
anywhere. You may have submitted it, but it hasn't been accepted. It's
not in the CRAN
fine with no more changes. Mention the issues you
saw in your submission message, but it looks to me like a transient
issue on Win-builder.
Duncan Murdoch
Any further hint?
Thank you for your time
Best
Gianmarco
Dr Gianmarco Alberti (PhD Udin
is package? Your current
version only mentions "spatstat (>= 1.56-0)". CRAN has spatstat.linnet
2.0-0, but perhaps Win-builder hadn't updated its old release library to
that version when you ran your test.
Duncan Murdoch
I am wondering:
(1) are the 2 notes returned by (a) an
kip that source call and look for the next available path (which may or
may not exist)
* throw an error that this.path is incompatible when sourcing URLs
* return the URL from that source call
No opinion.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
On 16/03/2021 9:04 a.m., Chris Evans wrote:
Hugely appreciated Duncan.
- Original Message -
From: "Duncan Murdoch"
...
You have 5 workflows, and their current content doesn't appear to match
the results on your actions page. Pick one, run it, and I'll see if I
27;ll see if I
can spot the reason for a failure.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
compatible with the old
one, so there would be no excuse for the downstream packages not to
update right away.
Duncan Murdoch
On 11/03/2021 7:39 p.m., Ege Rubak wrote:
Dear Duncan,
Thanks for taking the time to read my message and for the constructive
idea. You are right that it is a bit late
depend on spatstat. at their leisure.
Duncan Murdoch
On 11/03/2021 10:18 a.m., Ege Rubak wrote:
Dear all,
I'm seeking advice on how to submit a new package version with breaking
changes to CRAN. I will try to make this short:
1. spatstat (<= 1.65) had grow to be very large with e
On 06/03/2021 9:12 a.m., Dirk Eddelbuettel wrote:
On 5 March 2021 at 15:41, Duncan Murdoch wrote:
| On 05/03/2021 2:40 p.m., Henrik Bengtsson wrote:
| > Thank you. Glad to hear it's useful.
| >
| > This plain TeX/LaTeX vignette engine is implemented using base R. If
| > some
On 05/03/2021 2:40 p.m., Henrik Bengtsson wrote:
Thank you. Glad to hear it's useful.
This plain TeX/LaTeX vignette engine is implemented using base R. If
someone is willing to drive the efforts, I think it's not too much
work to refactor it and propose it for base R itself, where I think it
be
", "v"))
outside of your function, and that will suppress warnings about them.
You could also put the NULL assignments outside the function and it
would have the same effect. (You don't want to export those variables,
so be careful with your NAMESPACE file.)
Duncan Murdoch
_
aces or punctuation
before or after the patterns will be taken to be part of the pattern.
If your working directory is the top level package directory, this
emulates the test R CMD build uses:
files <- list.files()
files[tools:::inRbuildignore(files, ".")]
It should list all the fil
being included in the .tar.gz file produced by R
CMD build? This could be a bug in devtools::check. If you're using
RStudio, you can use the standard build and check functions by
unchecking the box for "Use devtools package functions if available".
Duncan Murdoch
T
t I
would suspect it will cause trouble with any package compiled against
2.7.11, as the macOS binaries on CRAN likely are.
If reinstalling 2.7.11 doesn't fix it, you may need to remove some 2.8.0
leftovers, as described here:
https://stat.ethz.ch/pipermail/r-sig-mac/2021-February/01395
On 21/02/2021 12:17 p.m., Gábor Csárdi wrote:
On Sun, Feb 21, 2021 at 6:05 PM Duncan Murdoch wrote:
On 21/02/2021 9:47 a.m., Iñaki Ucar wrote:
Hi,
Let's say that pkgA uses pkgB::function1. Then, version 2 of pkgB
removes function1 and exports function2 for the same functionality. So
warning that somethingNonexistent doesn't exist as long as you're not on
the old version of rgl.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
onment variable
_R_CHECK_FORCE_SUGGESTS_ set to "FALSE". If you are worried about a
CRAN submission, explain to them in your submission message why they
can't have all your suggested packages.
Duncan Murdoch
On 18/02/2021 10:36 a.m., Knut Krueger wrote:
The following problem:
there are three packa
?
It looks like some sort of transient problem on the test machine. I'd
ignore it unless you're submitting an update. In that case, I'd comment
on it in your submission comment, saying you haven't fixed one problem
because it was not reproducib
tform$r_arch)')
You can switch to backticks to not depend on bash so this
R_ARCH=`"${R_HOME}/bin/Rscript" -e 'cat(.Platform$r_arch)'`
should work too.
It didn't work for me, but I gave up on that approach pretty quickly so
I might have made some other erro
I'm guessing you use ESS?
No, I use RStudio. When I said "I don't use it much", I meant Roxygen2.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
anything important in my minimal github
repository were I to use pkgDown::build_site() to write directly to that
repository?
Q2b: is there more documentation on enhancing the site build_site() creates
that I can read?
I don't use pkgDown, so can't comment on these questions.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
ual, so I'm not
certain it doesn't violate the intention of some rule or other.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
On 09/02/2021 11:01 a.m., Duncan Murdoch wrote:
I think the WRE manual says that an R_ARCH environment variable will be
set when subarchitectures are involved, but environment variables aren't
accessible in Makevars.
Actually, I probably misread the section about environment variables.
D
On 09/02/2021 11:30 a.m., Sokol Serguei wrote:
Le 09/02/2021 à 17:01, Duncan Murdoch a écrit :
I think the WRE manual says that an R_ARCH environment variable will
be set when subarchitectures are involved, but environment variables
aren't accessible in Makevars.
Is there a standard way t
I think the WRE manual says that an R_ARCH environment variable will be
set when subarchitectures are involved, but environment variables aren't
accessible in Makevars.
Is there a standard way to get a value in Makevars which will match
.Platform$r_arch once R is running?
Duncan Mu
cf68878a1361d00ff2125db2e1ac7dc8f6c8009/src/library/tools/R/QC.R#L2118)
looks at the "DLL name", and ignores the fact that the path to the DLL
is in the rgl libs directory. I'll try to put together a patch for R
that fixes this.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Thanks again to all who wrote on this thread: rgl now lives in git,
with the main website now https://github.com/dmurdoch/rgl. Thanks
especially to Joshua, who did most of the heavy lifting of actually
importing the R-forge material.
Duncan Murdoch
On 02/02/2021 9:13 a.m., Ulrike Grömping wrote:
Am 02.02.2021 um 02:38 schrieb Duncan Murdoch:
On 01/02/2021 5:03 p.m., Ulrike Grömping wrote:
Dear package developeRs,
under the Fedora clang checks, I find the note
"Undeclared packages ‘FrF2’, ‘DoE.wrapper’, ‘sfsmisc’, ‘DoE.MIP
_cache directory, it would be installed (unless
your .Rbuildignore file says to ignore it).
If you extract the tar.gz file into a new directory, does the cache end
up in the same directory as the main vignette file?
Duncan Murdoch
Thanks,
Jose Barrera
Statistician, Associate Lecturer
*I
packages. So presumably
you don't mention those packages in your DESCRIPTION file. Generally
that means they should be listed in Suggests, which doesn't force them
to be installed, but they will be installed during tests. You might
also argue they should be in Enhances, though
On 31/01/2021 3:20 p.m., Joshua Ulrich wrote:
On Sun, Jan 31, 2021 at 2:17 PM Duncan Murdoch wrote:
Thanks to everyone who commented. A few replies inline:
On 31/01/2021 1:21 p.m., Joshua Ulrich wrote:
> I've moved history and issues from R-Forge to GitHub for half a doz
could help
> you do it.
Thanks for the offer (and the more detailed one offline, where you
recommend cloning the repository rather than forking it). Just for
future reference, could you tell me the benefits of cloning over forking?
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
iscussions that were sent to
R-forge.
- I'll need to do a bit of work to change dmurdoch/rgl to a more
standard R package layout, but this should be quite easy: basically
just moving the files in pkg/rgl to the top level. I assume "git mv"
will keep their his
On 31/01/2021 12:35 p.m., Duncan Murdoch wrote:
On 31/01/2021 10:57 a.m., Gábor Csárdi wrote:
Do you actually experience any problems, if you don't treat this case specially?
Yes, what was happening was that remotes::install_deps skipped
installing rgl from CRAN because the local copy
e
`remotes::install_deps()` with `remotes::install_local()` and then
remotes will install the local package as well, not only its
dependencies.
I'll try that.
Duncan
Gabor
On Sun, Jan 31, 2021 at 11:32 AM Duncan Murdoch
wrote:
I am trying out a modified version of the tidyverse actions, a
order?
Duncan Murdoch
On 29/01/2021 2:26 p.m., Hadley Wickham wrote:
On Thu, Jan 28, 2021 at 6:27 PM Henrik Bengtsson
wrote:
Hi,
you're probably already aware of it, but 'rgl' depends on 'magrittr'
which depends on 'rlang', and the latter requires R (>
ing says:
NOTE
'LinkingTo' for ‘js’ is unused as it has no 'include' directory
Is that an ignorable NOTE? If not, is there another strategy for
minifying Javascript files at install time?
Duncan Murdoch
__
R-package-dev
just tried this, and rgl still won't install in 3.2.0. I guess
this is because some of the other dependencies import magrittr, and/or
there are other post 3.2.0 needs. In any case, I'm not too worried
about that ancient of a version.
Duncan Murdoch
On 28/01/2021 7:27 p.m., Henrik Bengts
now installs in the basic r-base container, without adding
additional libs. This is due to some config checks that let it run on a
barebones machine: it can still produce WebGL output for a browser, it
just can't show it on screen.
Duncan Murdoch
On 28/01/2021 11:42 a.m., Dirk Ed
finally, my question: what is the recommended way to handle tests of
new packages on old R versions? Do docker or other images exist that
are already set up and ready to go?
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.
ers.
If you marked them that way because they take too long to run, then it
seems like CRAN shouldn't complain about the run time. I don't know if
they do or not.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat
e similar to the existing \eqn and \deqn macros in base R, it was easy
to switch back to those and I (hopefully temporarily) dropped the
mathjaxr dependency completely. For a package that made more extensive
use of math in the help pages it would be more work.
Duncan Murdoch
NOTE only on some platforms.
Duncan Murdoch
Thanks
Joe
Joe Thorley PhD, RPBio
Computational Biologist
Poisson Consulting Ltd.
4216 Shasheen Road
Nelson, BC
V1L 6X1, Canada
Tel: +1 250 551 2194
Email: j...@poissonconsulting.ca
Web: www.poissonconsulting.ca
[[alternative HT
may fail in CRAN tests; see the
recent "URL checks" thread on R-devel for a discussion of ways in which
this can happen even when the URL works for you.
Duncan Murdoch
Paul
On 2021-01-10 8:04 a.m., Georgi Boshnakov wrote:
> The problem is not in the Warning from the e
lution?
Most users aren't going to run your tests, so they shouldn't be forced
to install software that would let them do so.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
?), and maybe even a
reproducible example if you can extract a minimal amount from the
document and the .bib file. I haven't used Sweave in a few years (I
recommend switching to knitr's implementation of .Rnw processing), but I
didn't have problems like yours in the past.
On 16/12/2020 10:21 a.m., Knut Krueger wrote:
Am 15.12.20 um 14:37 schrieb Duncan Murdoch:
thank you for your answer
You should not have
@importFrom XLConnect createSheet writeWorksheet saveWorkbook
in your ROxygen comments; that results in an unconditional import.
Instead, you should use
markdown") ||
!rmarkdown::pandoc_available("1.14")) {
warning(call. = FALSE, "These vignettes assume rmarkdown and pandoc
version 1.14. These were not found. Older versions will not work.")
knitr::knit_exit()
}
This results in very short vignettes on system
s like
if (requireNamespace("XLConnect")) {
run code
} else {
report that you can't run that code
}
and make sure none of your examples or vignettes fail if XLConnect is
not present.
Duncan Murdoch
__
R-package-devel@r-project.org mailing
On 12/12/2020 6:01 p.m., Ben Bolker wrote:
On 12/12/20 5:50 PM, Duncan Murdoch wrote:
On 12/12/2020 4:08 p.m., Spencer Graves wrote:
Hi, Ben et al.:
On 2020-12-12 13:43, Ben Bolker wrote:
Apologies if I'm telling you something you already know:
By default, fda::CRAN() use
ines?
Most people want the same tests in both places. Those who like writing
lots of time consuming tests are the ones who shouldn't mind a small
step to control them.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
m in a "slowtests" directory, and
tell R CMD check to use that. How could it be easier?
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
o of them. \docType{data} might be flexible
enough. If you do this, you won't use \usage{} or \arguments{}, you'll
put together your own sections using \section{Usage}{ ... } and
\section{Arguments}{ ... } and try to get the formatting right.
Duncan Murdoch
[1]: https://stat.ethz.ch/R-
On 30/11/2020 11:54 a.m., Duncan Murdoch wrote:
On 30/11/2020 11:31 a.m., Dirk Eddelbuettel wrote:
On 30 November 2020 at 11:27, Duncan Murdoch wrote:
| I think that C++11 isn't a requirement of RcppArmadillo, it's an option
It is as of the 10.* series of Armadillo and hence Rcp
On 30/11/2020 11:31 a.m., Dirk Eddelbuettel wrote:
On 30 November 2020 at 11:27, Duncan Murdoch wrote:
| I think that C++11 isn't a requirement of RcppArmadillo, it's an option
It is as of the 10.* series of Armadillo and hence RcppArmadillo 0.10.*
I was going to complain that
f whatever package did that,
even though it isn't a system requirement for RcppArmadillo.
But I could be wrong about this...
Duncan Murdoch
On 30/11/2020 11:06 a.m., Mark Clements wrote:
[Apologies for cross-posting]
A colleague uses a package I maintain (rstpm2) as a dependency i
Why not use the CRAN submission web page, as documented here:
https://cran.r-project.org/web/packages/policies.html#Submission?
Duncan Murdoch
On 26/11/2020 2:57 p.m., Gábor Csárdi wrote:
Why not submit a bug report at the devtools repository?
❯ packageDescription("devtools")$Bug
sage that source-highlight is needed to build the vignette.
This is described in Section 1.6, "Writing portable packages", of
Writing R Extensions.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
g* that requires those packages in the
requireNamespace test.
- Make sure your example code in help pages never calls that function
unless shiny and shinyjqui are present, by a test similar to the above
but a positive one:
if (requireNamespace("shiny") && requireNamespace(&qu
On 13/11/2020 4:32 p.m., Gábor Csárdi wrote:
On Fri, Nov 13, 2020 at 9:02 PM Duncan Murdoch wrote:
[...]
Things may have changed since Henrik and I wrote the code, but his
description matches my understanding as well (and I think he's
contributed more recently than I have).
The way non-S
uess it's
pretty common to forget to include rmarkdown and formatR, since they may
not be explicitly used. Then putting them in the VignetteBuilder field
will trigger an error if they are not also in Suggests.
Duncan Murdoch
My understanding is that R CMD build (and possibly other
co
r Bioconductor - a process that
might take years, if at all.
/Henrik
On Fri, Nov 13, 2020 at 3:23 AM Duncan Murdoch wrote:
On 13/11/2020 3:10 a.m., Jason Luo wrote:
Hi,
I'm submitting a new package (https://github.com/Penncil/pda/) to CRAN. It
relies on some function (zerotrunc and hur
to CRAN without that dependency.
- you could publicize that your package is on Github, and give up on
publishing it on CRAN.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Actually I think it is a bug in the check code. I've just posted about
this on the R-devel list.
Duncan Murdoch
On 12/11/2020 10:13 a.m., Martin Morgan wrote:
This seems more like a problem with the CRAN test machine, with the movMF
package installed with flexmix available but loaded
change your dependency lists if one of them sets a
method that you're using.
Duncan Murdoch
On 11/11/2020 3:31 p.m., Kevin R. Coombes wrote:
Oh, I forgot to mention explicitly that checking (with --as-cran) on the
development version of R on Windows also produces no errors or warnings.
ll.R. But that function runs a new
R instance, and I didn't get to debugging that. I'll try again later
today if nobody else figures it out.
Duncan Murdoch
On 11/11/2020 12:03 p.m., Kevin R. Coombes wrote:
Hi Duncan,
Oops; I didn't realize I had forgotten to push updat
Uwe suggested you suggest flexmix, but I see below you already tried that.
I'd like to take a look, but I can't find your package. The existing
version on CRAN gives the URL as http://oompa.r-forge.r-project.org/,
but I can't see it mentioned there.
Duncan Murdoch
On 11/1
e dimensions).
I am not sure about this one; I'd need to look at the package to check.
Is it on Github?
Duncan Murdoch
Have ever someone faced a similar issue? However, it seems ineffective. Is
there any possibility to be a false negative?
I am sending bellow the links for the check l
= lung)
For example, would you like to generate an error, because you don't
support frailty in this context? Could you clarify that?
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
I don't know the best solution, but one workaround would be to replace
"fl" in your Rd files with "fl".
Duncan Murdoch
On 29/10/2020 10:34 a.m., Anthony Hammond wrote:
Hello,
I'm attempting to upload a package to CRAN and although it passes the R CMD
checks that I
RIPTION file, or
- test for it in the vignette, or
- remove the dependency by being explicit about stringsAsFactors = FALSE.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
On 22/10/2020 12:56 p.m., Marc Schwartz wrote:
On Oct 22, 2020, at 12:12 PM, Duncan Murdoch wrote:
On 22/10/2020 11:55 a.m., Marc Schwartz wrote:
On Oct 22, 2020, at 11:19 AM, Marc Schwartz wrote:
On Oct 22, 2020, at 10:21 AM, Kevin R. Coombes
wrote:
Hi,
I am developing a package and
n license.db, but R could still do computations on them, as described
in ?library in the "Licenses" section.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
wCore apparently does and ignore
the NOTE?
flowCore is a Bioconductor package, not on CRAN. Are you intending to
send yours there, or to CRAN? I suspect Bioconductor is happy with the
Hutch's license.
Duncan Murdoch
__
R-package-devel@r-p
e on to the next one...
Most of the contributors to R are reasonable people, but they have their
own priorities. If you can make it easier for them to achieve their
priorities, they'll appreciate it. If you ask them to change their
priorities, they might not.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
On 13/10/2020 5:33 a.m., Iñaki Ucar wrote:
On Tue, 13 Oct 2020 at 01:47, Ben Bolker wrote:
On 10/12/20 7:37 PM, Duncan Murdoch wrote:
On 12/10/2020 6:51 p.m., Ben Bolker wrote:
On 10/12/20 6:36 PM, Duncan Murdoch wrote:
On 12/10/2020 6:14 p.m., Ben Bolker wrote:
I'd say a mis
On 12/10/2020 6:51 p.m., Ben Bolker wrote:
On 10/12/20 6:36 PM, Duncan Murdoch wrote:
On 12/10/2020 6:14 p.m., Ben Bolker wrote:
I'd say a mismatch in saved output isn't a small problem, it's either a
too-sensitive test or something serious.
Duncan Murdoch
Tha
On 12/10/2020 6:14 p.m., Ben Bolker wrote:
I'd say a mismatch in saved output isn't a small problem, it's either a
too-sensitive test or something serious.
Duncan Murdoch
That's fair enough, but it would be nice if (1) this were a NOTE and
I don't think s
On 12/10/2020 5:17 p.m., Ben Bolker wrote:
On 10/12/20 4:40 PM, Duncan Murdoch wrote:
There's this one in
https://win-builder.r-project.org/incoming_pretest/lme4_1.1-24_20201012_210730/Windows/00check.log:
Comparing 'lmer-1.Rout' to 'lmer-1.Rout.save' ...428
les_and_tests/tests_i386/lmer-1.Rout.save
The difference also doesn't show up in the x64 versions of the files.
Duncan Murdoch
On 12/10/2020 4:03 p.m., Ben Bolker wrote:
Before I risk wasting the CRAN maintainers' time with a query, can
anyone see what I'm missing here? Ev
l but I couldn't
find an answer to my questions.
Hopefully I've added enough info for you.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
g you need
to worry about: that other package has probably been updated to drop
the bibtex dependence, but Debian hasn't got the update yet.
I don't know how you determine which is the "guilty" package. Maybe
there are more hints in the check log?
Duncan Murdoch
On 10/1
w version. In the latter case, mention the failure in
your submission message and say that you're assuming it's a problem on
their end.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
When I tried that on MacOS, it did the gs compression with gs_quality
set to "none", which does nothing. I don't know what quality CRAN uses,
but for me setting the environment variable GS_QUALITY=screen made a big
difference.
Duncan Murdoch
On 08/10/2020 11:10 a.m., John F
Just to clarify: I've never noticed the problem you mention. I just
know how to debug R CMD build.
Duncan
cheers
Ben
On 10/7/20 8:31 PM, Duncan Murdoch wrote:
I don't know the answer to your question, but you can debug the
--compact-vignettes option as follows.
deb
et those criteria. When I trick it into accepting
the compaction, it does put the compacted PDF into the tarball.
Duncan Murdoch
On 07/10/2020 6:03 p.m., John Fox wrote:
Dear Ben,
On 2020-10-07 5:26 p.m., Ben Bolker wrote:
I hope so too. The (annoying) workaround is to compact the vignett
ly, you could choose to distribute your package in some other way
besides CRAN.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
On 26/09/2020 12:54 p.m., Dirk Eddelbuettel wrote:
On 26 September 2020 at 11:50, Duncan Murdoch wrote:
| On 26/09/2020 9:14 a.m., Dirk Eddelbuettel wrote:
| >
| > I had a submission fail and bomb with this error on Windows:
| >
| >Flavor: r-devel-windows-ix86+x86_64
| &g
This makes the test happy, though it also makes the vignette pretty
useless on systems that don't meet the stated requirements. Since
SystemRequirements is free-form, I can see why CRAN doesn't do automatic
interpretation of it, but it would be nice if they did.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
. Rather, you declare dependency
relationsships via DESCRIPTION (and likely NAMESPACE). See "Writing R
Extensions" for all the details.
I think you misread the post: this was an example of code a user would
run, not code from the package.
Dunc
You could probably fix this by adding the envir
argument to exists() in that call, e.g.
test <- sapply(ffun, exists, mode = "function", envir =
parent.env(environment()))
but it would be better to not try to invent a new object system.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
301 - 400 of 911 matches
Mail list logo
