Re: [R-pkg-devel] Suppressing long-running vignette code in CRAN submission

[John Harrold]

I ask myself the question: Who is the vignette for?  It does server two
purposes. One is testing but primarily it's for the users to learn how to
use a package. I think the testing is secondary, and if it slows down
installation or general usability I'd sacrifice the testing. If it's that
important, then the tests can be added explicitly in tests/.

On Tue, Oct 17, 2023 at 3:04 PM Dirk Eddelbuettel  wrote:

>
> On 18 October 2023 at 08:51, Simon Urbanek wrote:
> | John,
> |
> | the short answer is it won't work (it defeats the purpose of vignettes).
>
> Not exactly. Everything is under our (i.e. package author) control, and
> when
> we want to replace 'computed' values with cached values we can.
>
> All this is somewhat of a charade. "Of course" we want vignettes to run
> tests. But then we don't want to fall over random missing .sty files or
> fonts
> (macOS machines have been less forgiving than others), not to mention
> compile
> time.
>
> So for simplicity I often pre-make pdf vignettes that get included in other
> latex code as source. Works great, never fails, CRAN never complained --
> which is somewhat contrary to your statement.
>
> It is effectively the same with tests. We all want maximum test surfaces.
> But
> when tests fail, or when they run too long, or [insert many other reasons
> here] so many packages run tests conditionally.  Such is life.
>
> Dirk
>
>
> | However, this sounds like a purely hypothetical question - CRAN policies
> allow long-running vignettes if they declared.
> |
> | Cheers,
> | Simon
> |
> |
> | > On 18/10/2023, at 3:02 AM, John Fox  wrote:
> | >
> | > Hello Dirk,
> | >
> | > Thank you (and Kevin and John) for addressing my questions.
> | >
> | > No one directly answered my first question, however, which was whether
> the approach that I suggested would work. I guess that the implication is
> that it won't, but it would be nice to confirm that before I try something
> else, specifically using R.rsp.
> | >
> | > Best,
> | > John
> | >
> | > On 2023-10-17 4:02 a.m., Dirk Eddelbuettel wrote:
> | >> Caution: External email.
> | >> On 16 October 2023 at 10:42, Kevin R Coombes wrote:
> | >> | Produce a PDF file yourself, then use the "as.is" feature of the
> R.rsp
> | >> | package.
> | >> For completeness, that approach also works directly with Sweave.
> Described in
> | >> a blog post by Mark van der Loo in 2019, and used in a number of
> packages
> | >> including a few of mine.
> | >> That said, I also used the approach described by John Harrold and
> cached
> | >> results myself.
> | >> Dirk
> | >> --
> | >> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> | >> __
> | >> R-package-devel@r-project.org mailing list
> | >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> | >
> | > __
> | > R-package-devel@r-project.org mailing list
> | > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> | >
> |
> | __
> | R-package-devel@r-project.org mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] package submissions no auto-processed message

[John Harrold]

I got it. Thanks Uwe.

On Sun, Aug 27, 2023 at 4:05 PM Uwe Ligges 
wrote:

> Thanks.This was pending a manual inspection for newbies (packages).
> ALthough, we also have no mail with test results (I guess a CRAN
> server's mail issue when this hot checked), so I just triggered new checks.
>
> Best,
> Uwe Ligges
>
>
>
> On 28.08.2023 00:37, John Harrold wrote:
> > Oh I'm sorry. It's the ruminate package.
> >
> > On Sun, Aug 27, 2023 at 2:22 PM Uwe Ligges
> >  > <mailto:lig...@statistik.tu-dortmund.de>> wrote:
> >
> >
> >
> > On 27.08.2023 22:51, John Harrold wrote:
> >  > Howdy Folks,
> >  >
> >  > I submitted a package on Friday. I got the normal email where you
> > have to
> >  > click on the link to confirm. Then I got an email saying that the
> > package
> >  > was uploaded. Normally after that I get an email saying the
> > package was
> >  > auto-processed. That generally doesn't take very long (typically
> > less than
> >  > an hour). I wanted to know if there was something on the backend
> > that was
> >  > causing a delay, or if there was something wrong and I needed to
> > resubmit
> >  > it.
> >
> > Not that I know. If you told us which package this is about ...
> >
> > Best,
> > Uwe Ligges
> >
> >
> >
> >
> >  >
> >  > Thank you,
> >  > John
> >  > :wq
> >  >
> >  >   [[alternative HTML version deleted]]
> >  >
> >  > __
> >  > R-package-devel@r-project.org
> > <mailto:R-package-devel@r-project.org> mailing list
> >  > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> > <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
> >
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] package submissions no auto-processed message

[John Harrold]

Oh I'm sorry. It's the ruminate package.

On Sun, Aug 27, 2023 at 2:22 PM Uwe Ligges 
wrote:

>
>
> On 27.08.2023 22:51, John Harrold wrote:
> > Howdy Folks,
> >
> > I submitted a package on Friday. I got the normal email where you have to
> > click on the link to confirm. Then I got an email saying that the package
> > was uploaded. Normally after that I get an email saying the package was
> > auto-processed. That generally doesn't take very long (typically less
> than
> > an hour). I wanted to know if there was something on the backend that was
> > causing a delay, or if there was something wrong and I needed to resubmit
> > it.
>
> Not that I know. If you told us which package this is about ...
>
> Best,
> Uwe Ligges
>
>
>
>
> >
> > Thank you,
> > John
> > :wq
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] package submissions no auto-processed message

[John Harrold]

Howdy Folks,

I submitted a package on Friday. I got the normal email where you have to
click on the link to confirm. Then I got an email saying that the package
was uploaded. Normally after that I get an email saying the package was
auto-processed. That generally doesn't take very long (typically less than
an hour). I wanted to know if there was something on the backend that was
causing a delay, or if there was something wrong and I needed to resubmit
it.

Thank you,
John
:wq

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Check package without suggests

[John Harrold]

I want to check my package to make sure I'm properly using suggested
packages. I'm trying to catch mistakes where I forgot to do what you're
suggesting.

On Tue, Jul 18, 2023 at 7:58 AM Serguei Sokol 
wrote:

> Is it possible that you have complicated the task unnecessarily?
> Normally, you can just do
>
> if (requireNamespace("", quietly=TRUE)) {
>   # do the tests involving 
> }
>
> Wasn't that enough?
>
> Best,
> Serguei.
>
>
> Le 18/07/2023 à 16:37, John Harrold a écrit :
> > Howdy Folks,
> >
> > I recent had a package start failing because I wasn't checking properly
> in
> > my tests to make sure my suggested packages were installed before running
> > tests. I think this is something new running on CRAN where packages are
> > tested with only the packages specified as Imports in the DESCRIPTION
> file
> > are installed. It took me a bit of back and forth to get all of these
> > issues worked out.  I was wondering if anyone has a good way to run R CMD
> > check with only the imports installed?  A github action, or a
> > specific platform on rhub?
> >
> > Thank you,
> >
> > John
> > :wq
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Check package without suggests

[John Harrold]

Howdy Folks,

I recent had a package start failing because I wasn't checking properly in
my tests to make sure my suggested packages were installed before running
tests. I think this is something new running on CRAN where packages are
tested with only the packages specified as Imports in the DESCRIPTION file
are installed. It took me a bit of back and forth to get all of these
issues worked out.  I was wondering if anyone has a good way to run R CMD
check with only the imports installed?  A github action, or a
specific platform on rhub?

Thank you,

John
:wq

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Missing ggPMX causing failure for nlmixr2rpt

[John Harrold]

Howdy everyeone,

I think I misunderstood how suggests works. I always thought they would ble
available on CRAN but not necessarily on the end users computer. I've fixed
everything and will resubmit it this weekend.

Thank you both Ivan and Lluís. This was helpful.

John

On Fri, Jun 2, 2023 at 12:18 AM Lluís Revilla 
wrote:

> Dear John,
>
> I think the problem is that the package ggPMX is suggested, but
> nlmixr2rpt isn't prepared for when it isn't available.
> In such cases, a package shouldn't fail the checks.
>
> From the CRAN policies
> https://cran.r-project.org/web/packages/policies.html :
> "A package listed in ‘Suggests’ or ‘Enhances’ should be used
> conditionally in examples or tests if it cannot straightforwardly be
> installed on the major R platforms. (‘Writing R Extensions’ recommends
> that they are always used conditionally.)"
>
> Among other things in the file test-rptnlmixr.R you load several
> suggested packages without checking if they are available.
> You should only run those tests and examples that need those packages
> if they are available.
> Checking via:  if (requireNamespace("ggPMX", verbose = FALSE) could be
> enough
>
> There's also an example that seems to be failing, I didn't understand
> the reason behind it but it might be related.
>
> Best,
>
> Lluís
>
>
> On Fri, 2 Jun 2023 at 02:49, John Harrold 
> wrote:
> >
> > Hello,
> >
> > I recently got a "Dear Maintainer" email from Brian Ripley. It was
> > concerning the nlmixr2rpt package I maintain:
> >
> > https://cran.r-project.org/web/checks/check_results_nlmixr2rpt.html
> >
> > It looks like there is an error on r-release-linux-x86_64 that is causing
> > it. If I'm reading that correctly there is a problem finding ggPMX on
> that
> > flavor. If I look at the check results for ggPMX it seems to be building
> > fine there:
> >
> > https://cran.r-project.org/web/checks/check_results_ggPMX.html
> >
> > Am I reading that correctly that ggPMX not being found is the cause of my
> > issues? If that's the case and it seems to be present now, can I just
> wait
> > and let CRAN machines find it? Or should I just resubmit with those
> pieces
> > removed from the version I submit to CRAN?
> >
> > --
> > Thank you,
> > John
> > :wq
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
John
:wq

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Missing ggPMX causing failure for nlmixr2rpt

[John Harrold]

Hello,

I recently got a "Dear Maintainer" email from Brian Ripley. It was
concerning the nlmixr2rpt package I maintain:

https://cran.r-project.org/web/checks/check_results_nlmixr2rpt.html

It looks like there is an error on r-release-linux-x86_64 that is causing
it. If I'm reading that correctly there is a problem finding ggPMX on that
flavor. If I look at the check results for ggPMX it seems to be building
fine there:

https://cran.r-project.org/web/checks/check_results_ggPMX.html

Am I reading that correctly that ggPMX not being found is the cause of my
issues? If that's the case and it seems to be present now, can I just wait
and let CRAN machines find it? Or should I just resubmit with those pieces
removed from the version I submit to CRAN?

--
Thank you,
John
:wq

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] CRAN package isoband and its reverse dependencies

[John Harrold]

Howdy Folks,

I got a message from CRAN today telling me that I have a strong reverse
dependency on the isoband package. But I'm not alone! It look like more
than 4700 other packages also have a strong dependency on this. Is there
some organized effort to deal with this?

Thanks
John

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Examples taking too long depend on object that takes a while to generate

[John Harrold]

Not to be pedantic but it's not a dataset per-se. It's an R object that the
examples need.

On Thu, Sep 15, 2022 at 2:49 AM Duncan Murdoch 
wrote:

> On 15/09/2022 5:29 a.m., Martin Maechler wrote:
> >>>>>> Duncan Murdoch
> >>>>>>  on Thu, 15 Sep 2022 04:42:04 -0400 writes:
> >
> >  > On 15/09/2022 3:45 a.m., Martin Maechler wrote:
> >  >>>>>>> Duncan Murdoch
> >  >>>>>>> on Wed, 14 Sep 2022 13:02:28 -0400 writes:
> >  >>
> >  >> > On 14/09/2022 12:43 p.m., Ivan Krylov wrote:
> >  >> >> On Wed, 14 Sep 2022 12:31:49 -0400
> >  >> >> Duncan Murdoch  wrote:
> >  >> >>
> >  >> >>> It's also possible to put .R files in the data directory,
> and they
> >  >> >>> are executed to create the data object.  I think that
> happens at the
> >  >> >>> time when you call data() rather than at install time, so it
> might
> >  >> >>> not be helpful.
> >  >> >>
> >  >> >> Some time ago I was hoping to compress a package of mine by
> generating a
> >  >> >> dataset during a data() call instead loading it from an .rda
> file, but
> >  >> >> it turned out that the .R file is executed during R CMD build:
> >  >> >>
> https://github.com/r-devel/r-svn/blob/03df313ad37456c6a62158328d4e373408ce4d59/src/library/tools/R/build.R#L794
> >  >>
> >  >> > Thanks for that info.  That's not good for John, because the
> >  >> > architecture isn't known at build time.
> >  >>
> >  >> > Duncan Murdoch
> >  >>
> >  >> Sorry to muddy the water, but what *is* "build time"?
> >  >> There's the big difference between building
> >  >> 1) a  Source tarballand
> >  >> 2) a  MacOS or Windows binary package
> >  >>
> >  >> Unfortunately, the two situations are very different notably in
> >  >> this case, where '(2)' is really much closer to the
> >  >> "install time" you mention.
> >  >>
> >
> >  > I meant building the tarball, and assumed that was what Ivan was
> talking
> >  > about as well.
> >
> >  > Duncan Murdoch
> >
> > Ok, thank you, for the clarification.
> >
> > Note that  `R CMD build --help`  mentions (among more)
> >
> >--resave-data=re-save data files as compactly as possible:
> >  "no", "best", "gzip" (default)
> >--no-resave-data  same as --resave-data=no
> >
> > so when building the package,
> > Ivan should get what he wanted with
> >
> >  R CMD build --no-resave-data  
> >
> > no ?
>
> It's actually John Harrold who has the problem:  a dataset that he wants
> to use in examples that takes a long time to build, causing his examples
> to exceed the CRAN 5 second limit.
>
> So what I was suggesting is that he should arrange for it to be created
> before running the example; the problem is that the dataset depends on
> the architecture of the machine that's running the example.  To follow
> my suggestion he would need to have the dataset created when the package
> was installed (or the binary was built).
>
> Duncan Murdoch
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
John
:wq

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Examples taking too long depend on object that takes a while to generate

[John Harrold]

Hello Greg,

I'm already using a reduced dataset. I can reduce it a little bit further
but it doesn't really change things much.

John

On Tue, Sep 13, 2022 at 8:35 PM Greg Hunt  wrote:

> John,
> Can you cut the test data size back?  Do you have some processing costs
> that are non-linear with data size?  27 seconds of user CPU is an awful lot
> of processing these days.
>
> Greg
>
> On Wed, 14 Sept 2022 at 13:21, John Harrold 
> wrote:
>
>> Hello,
>>
>> I'm working on submitting a new package. I've created examples for each of
>> the functions. Most of these functions depend on an R object that uses
>> architecture-specific compiled code. To create that object can take
>> between
>> 10-20 seconds. The function that creates it will cache it in the
>> tempdir().
>> So the first example that uses that object will take more than the 5
>> seconds allowed by CRAN. If I wrap that example in donttest, then the next
>> function that uses it will exceed the 5 second limit, and on. I submitted
>> the package with all of these examples wrapped in donttest, but that got
>> me
>> dinged :). So I'm trying to come up with a solution and I'd appreciate any
>> help here.
>>
>> Is there some way to build an object before tests are run?
>>
>> Thank you,
>> John
>>
>> If it would help this is an example where I'm testing it in win-builder:
>>
>> https://win-builder.r-project.org/6641irOr4mI6/
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>

-- 
John
:wq

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Examples taking too long depend on object that takes a while to generate

[John Harrold]

Hello,

I'm working on submitting a new package. I've created examples for each of
the functions. Most of these functions depend on an R object that uses
architecture-specific compiled code. To create that object can take between
10-20 seconds. The function that creates it will cache it in the tempdir().
So the first example that uses that object will take more than the 5
seconds allowed by CRAN. If I wrap that example in donttest, then the next
function that uses it will exceed the 5 second limit, and on. I submitted
the package with all of these examples wrapped in donttest, but that got me
dinged :). So I'm trying to come up with a solution and I'd appreciate any
help here.

Is there some way to build an object before tests are run?

Thank you,
John

If it would help this is an example where I'm testing it in win-builder:

https://win-builder.r-project.org/6641irOr4mI6/

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] if statements in NAMESPACE file

[John Harrold]

I don't have cigwin installed but from the command window, the terminal
that Git installs, RGui, and RStudio they all return "windows" for the
.Platform$OS.type for me.

On Thu, Sep 30, 2021 at 2:38 PM Duncan Murdoch 
wrote:

> On 30/09/2021 5:21 p.m., Jeff Newmiller wrote:
> > What if you are on Windows but running R at the command prompt, or via
> cygwin, or in the console window of RStudio?
> >
> > This seems unstable to me.
>
> Sorry, too much context missing.  What's unstable?
>
> Duncan Murdoch
>
> >
> > On September 30, 2021 11:52:16 AM PDT, Andrew Simmons <
> akwsi...@gmail.com> wrote:
> >> Hello,
> >>
> >>
> >> I'm updating my package 'this.path' which is supposed to retrieve the
> >> absolute path of the executing script when called. It's similar to
> 'here',
> >> except that 'here' constructs paths relative to a project directory,
> >> whereas 'this.path' constructs paths relative to script directories. I
> was
> >> updating the section where I retrieve the executing script's path while
> >> running from a script open in Rgui for Windows, and I needed
> >> utils::getWindowsHandles to do such a thing. But
> utils::getWindowsHandles
> >> is a Windows only function, I
> >> would imagine that 'utils' contains a similar line of code as above:
> >>
> >>
> >> if (.Platform$OS.type == "windows")
> >> getWindowsHandles <- function() ...
> >>
> >>
> >> and then in the NAMESPACE:
> >>
> >>
> >> if (.Platform$OS.type == "windows")
> >> export(getWindowsHandles)
> >>
> >>
> >> so I'd like to change my code to getWindowsHandles and import
> >> getWindowsHandles from utils, but I can only do that on Windows, and so
> the
> >> conditional importing should work for me. At no point does my function
> >> mis-behave because of a attempting to use a function that isn't
> exported on
> >> that platform, because within the function it only uses
> getWindowsHandles
> >> if the OS is Windows.
> >>
> >>
> >> On Thu, Sep 30, 2021 at 11:01 AM Mark Miller <
> mark.roman.mil...@gmail.com>
> >> wrote:
> >>
> >>> Returning to the original question, if it's helpful: I'd like to know
> what
> >>> constraints led to considering an export only available on Windows,
> and see
> >>> if we can suggest some other designs. It'd be good to keep the user's
> >>> mental model abstracted from the platform they're working on. There are
> >>> often unavoidable differences due to platform, but usually they're
> handled
> >>> with warnings and errors rather than selective exports.
> >>>
> >>> On Thu, Sep 30, 2021 at 3:40 AM Berry Boessenkool <
> >>> berryboessenk...@hotmail.com> wrote:
> >>>
> 
>  One of the very best fortunes nominations!
> 
>  [...]
> 
> I suspect something like
> 
>  if (stats::runif(1) > 0.5) export(someFunction)
> 
>  would work too, for a particularly frustrating experience for your
>  users.  It would mean half the installs export the function, and half
>  don't.
> 
>  Duncan Murdoch
> 
> 
>   [[alternative HTML version deleted]]
> 
>  __
>  R-package-devel@r-project.org mailing list
>  https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> >>>
> >>>  [[alternative HTML version deleted]]
> >>>
> >>> __
> >>> R-package-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>>
> >>
> >>  [[alternative HTML version deleted]]
> >>
> >> __
> >> R-package-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
John
:wq

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Spelling and manual CRAN inspection

[John Harrold]

I have a list of words, acronyms and initialisms that commonly get flagged
as misspelled words when I submit updates. I generally just put an
explanation for each one in the "optional comment" section of the
submission form. It's pretty simple and seems to work out well.

On Fri, Jul 16, 2021 at 9:08 AM Kevin R. Coombes 
wrote:

> 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" for my last name (Coombes) --- even though none of the
> other 20 packages that I maintain has ever triggered that particular
> NOTE. A second package also triggered a manual inspection for
> mis-spelled words including "Proteomics". (These flags only arose on the
> debian CRAN machine, not the Windows CRAN machine, and not on my home
> machines. And let's ignore how many spelling corrections I had to make
> while typing this email)
>
> *My question, however, is: why should this NOTE ever trigger a manual
> inspection?* That makes more work for the CRAN maintainers, who I am
> sure have better things to do than evaluate spelling. Anything that
> would actually stop the package from working (mis-spelling a keyword, or
> mis-spelling the name of package that is imported) is going to cause an
> automatic ERROR and a rejection of the submission without making more
> work for the CRAN maintainers. The other mis-spellings may reflect
> poorly on the package author, but since they are NOTEs, it is easy
> enough to get them fixed for the next round without making human
> eyeballs look at them.
>
> Best,
> Kevin
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
John
:wq

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Question about preventing CRAN package archival

[John Harrold]

To add another option. In the past when this has happened to me I've found
other packages that provide similar functionality.

I'm assuming that is.square just checks the number of columns == number of
rows? And the others can probably be implemented pretty easily.

On Wed, Jun 2, 2021 at 10:41 AM Ben Staton  wrote:

> My package uses the MIT license, so would that not meet the compatibility
> requirements?
>
> I will attempt to reach out to the package author - thanks for your help!
>
> On Wed, Jun 2, 2021 at 10:31 AM Ben Bolker  wrote:
>
> > That all sounds exactly right.
> >GPL >= 2 allows you to use the material without asking permission as
> > long as your package is compatibly licensed (e.g. also GPL).
> >Under normal circumstances it would be polite to ask permission, but
> > if the reason for doing this is that the maintainer is unreachable in
> > the first place ...
> >
> >   If you want to try a little harder, it seems quite possible that you
> > can reach the matrixcalc maintainer at the (personal) e-mail address
> > shown in this page:
> >
> >
> https://www.facebook.com/photo/?fbid=10208324530363130=ecnf.1000413042
> >
> >(Possibly an identity confusion, but I rate that as unlikely based on
> > other facebook snooping)
> >
> >I don't think a short, polite e-mail request would be out of bounds,
> > they can always ignore it or tell you to go away.
> >
> >cheers
> > Ben Bolker
> >
> > On 6/2/21 1:15 PM, Ben Staton wrote:
> > > Hello,
> > >
> > > Thank you for your detailed list of solutions.
> > >
> > > I was initially tempted to go with option 1 (move matrixcalc to
> suggests
> > > and check for its existence before using functions that rely on it),
> but
> > as
> > > mentioned, this is not a long term fix.
> > >
> > > I unfortunately can't take on the responsibilities of option 2
> (becoming
> > > the package maintainer) -- there is much that this package does that I
> do
> > > not understand, and do not wish to feign authority!
> > >
> > > I plan to take option 3 (copy the needed functions into my package).
> > There
> > > are only three functions I need from matrixcalc, and all three are
> fairly
> > > simple (is.square.matrix
> > > ,
> > > is.symmetric.matrix
> > > , and
> > > is.positive.definite
> > > ) and
> > there
> > > is only one function in postpack that needs them. I plan to define them
> > > within the postpack function. matrixcalc is licensed under GPL >= 2 and
> > > based on my scan of the license text, this is allowed. Is that correct?
> > >
> > > Regarding option 4 (contacting the matrixcalc maintainer), the original
> > > email from CRAN mentioned that they have attempted to contact the
> package
> > > author with no response.
> > >
> > > Thank you!
> > >
> > > On Wed, Jun 2, 2021 at 9:52 AM J C Nash  wrote:
> > >
> > >> I just downloaded the source matrixcalc package to see what it
> > contained.
> > >> The functions
> > >> I looked at seem fairly straightforward and the OP could likely
> develop
> > >> equivalent features
> > >> in his own code, possibly avoiding a function call. Avoiding the
> > function
> > >> call means NAMESPACE etc. are not involved, so fewer places for
> getting
> > >> into
> > >> trouble, assuming the inline code works properly.
> > >>
> > >> JN
> > >>
> > >>
> > >> On 2021-06-02 12:37 p.m., Duncan Murdoch wrote:
> > >>> On 02/06/2021 12:13 p.m., Ben Staton wrote:
> >  Hello,
> > 
> >  I received an email notice from CRAN indicating that my R package
> >  ('postpack') will be archived soon if I do not take any action and I
> > >> want
> >  to avoid that outcome. The issue is not caused by my package, but
> > >> instead a
> >  package that my package depends on:
> > 
> >  "... package 'matrixcalc' is now scheduled for archival on
> 2021-06-09,
> >  and archiving this will necessitate also archiving its strong
> reverse
> >  dependencies."
> > 
> >  Evidently, xyz has been returning errors on new R builds prompting
> > CRAN
> > >> to
> >  list it as a package to be archived. My package, 'postpack' has
> >  'matrixcalc' listed in the Imports field, which I assume is why I
> > >> received
> >  this email.
> > 
> >  I want to keep 'postpack' active and don't want it to be archived. I
> > >> still
> >  need package 'matrixcalc' for my package, but not for most
> functions.
> > >> Could
> >  I simply move package 'matrixcalc' to the Suggests list and submit
> the
> > >> new
> >  version to CRAN to remove the "Strong Reverse Dependency" issue that
> >  triggered this email to avoid CRAN from archiving my package?
> > >>>
> > >>> That's part of one solution, but not the best solution.
> > >>>
> > >>> If you move it to Suggests, you should make sure that your package
> > 

Re: [R-pkg-devel] Number of cores in examples

[John Harrold]

Hello Max,

The comment I received was:

Please ensure that you do not use more than 2 cores in your examples.

I believe the only output I received was these incoming pretest results:

https://win-builder.r-project.org/incoming_pretest/ubiquity_1.0.0_20190821_023712/

Feel free to browse through them.

Thanks
John

On Sun, Sep 15, 2019 at 10:26 AM Max Turgeon 
wrote:

> Hi John,
>
>
> From the R-hub output you shared with us, we can see that you don't get
> the error on Ubuntu with R-devel, nor on Windows with R-3.6.1. When you
> received the original email from CRAN with the check output, on which
> platform did you get the error about using too many cores? Perhaps that
> info could help narrow it down, or at least you would know on which
> platform to test.
>
>
> Max Turgeon
> Assistant Professor
> Department of Statistics
> Department of Computer Science
> University of Manitoba
> maxturgeon.ca
>
>
> ------
> *From:* R-package-devel  on behalf
> of John Harrold 
> *Sent:* September 15, 2019 11:31:38 AM
> *To:* Uwe Ligges
> *Cc:* r-package-devel@r-project.org
> *Subject:* Re: [R-pkg-devel] Number of cores in examples
>
> Howdy Folks,
>
> I'm testing this on R-hub, and I've set option in the environment. I put
> links to the Windows and Ubuntu outputs below. I've searched for the
> obvious (core, parallel, etc), but I'm not really sure what I need to look
> for to indicate that more than one core is being used. If someone could
> point it out to me I'd be very grateful.
>
> Windows:
>
> https://drive.google.com/file/d/1187cRyrJLFJetaOW3WHL-mLTCTwYxOeG/view?usp=sharing
>
> Ubuntu:
>
> https://drive.google.com/file/d/1XhaKFpaPaRyJLvHuFcbWNyztzYpsLj8r/view?usp=sharing
>
> Thanks
> John
>
>
>
> On Sun, Sep 15, 2019 at 12:42 AM Uwe Ligges <
> lig...@statistik.tu-dortmund.de>
> wrote:
>
> >
> >
> > On 15.09.2019 05:39, John Harrold wrote:
> > > Thanks Uwe,
> > >
> > > Is there a way to find out on my end where this is happening?
> >
> > Yes, simply set the env var
> > _R_CHECK_LIMIT_CORES_=true
> > to reproduce.
> >
> > Best,
> > Uwe
> >
> > >
> > > Thanks
> > > john
> > >
> > > On Fri, Sep 13, 2019 at 10:51 PM Uwe Ligges
> > >  > > <mailto:lig...@statistik.tu-dortmund.de
> >> wrote:
> > >
> > >
> > >
> > > On 14.09.2019 03:33, John Harrold wrote:
> > >  > Hello,
> > >  >
> > >  > I recently submitted a package for consideration in CRAN. One of
> > the
> > >  > comments was:
> > >  >
> > >  > Please ensure that you do not use more than 2 cores in your
> > examples.
> > >  >
> > >  > I do not believe my package does this. Is this a general comment
> > > for a
> > >  > package that requires doParallel or was this triggered because
> > > one of my
> > >  > examples actually used more than 2 cores?
> > >
> > > The latter. In examples, vignettes and tests you must not start
> more
> > > than 2 workers as resources for CRAN checks are limited.
> > >
> > > Best,
> > > Uwe Ligges
> > >
> > >
> > >  >
> > >  > Thanks
> > >  > John
> > >  >
> > >
> > >
> > >
> > > --
> > > John
> > > :wq
> >
>
>
> --
> John
> :wq
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
John
:wq

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Number of cores in examples

[John Harrold]

Howdy Folks,

I'm testing this on R-hub, and I've set option in the environment. I put
links to the Windows and Ubuntu outputs below. I've searched for the
obvious (core, parallel, etc), but I'm not really sure what I need to look
for to indicate that more than one core is being used. If someone could
point it out to me I'd be very grateful.

Windows:
https://drive.google.com/file/d/1187cRyrJLFJetaOW3WHL-mLTCTwYxOeG/view?usp=sharing

Ubuntu:
https://drive.google.com/file/d/1XhaKFpaPaRyJLvHuFcbWNyztzYpsLj8r/view?usp=sharing

Thanks
John



On Sun, Sep 15, 2019 at 12:42 AM Uwe Ligges 
wrote:

>
>
> On 15.09.2019 05:39, John Harrold wrote:
> > Thanks Uwe,
> >
> > Is there a way to find out on my end where this is happening?
>
> Yes, simply set the env var
> _R_CHECK_LIMIT_CORES_=true
> to reproduce.
>
> Best,
> Uwe
>
> >
> > Thanks
> > john
> >
> > On Fri, Sep 13, 2019 at 10:51 PM Uwe Ligges
> >  > <mailto:lig...@statistik.tu-dortmund.de>> wrote:
> >
> >
> >
> > On 14.09.2019 03:33, John Harrold wrote:
> >  > Hello,
> >  >
> >  > I recently submitted a package for consideration in CRAN. One of
> the
> >  > comments was:
> >  >
> >  > Please ensure that you do not use more than 2 cores in your
> examples.
> >  >
> >  > I do not believe my package does this. Is this a general comment
> > for a
> >  > package that requires doParallel or was this triggered because
> > one of my
> >  > examples actually used more than 2 cores?
> >
> > The latter. In examples, vignettes and tests you must not start more
> > than 2 workers as resources for CRAN checks are limited.
> >
> > Best,
> > Uwe Ligges
> >
> >
> >  >
> >  > Thanks
> >  > John
> >  >
> >
> >
> >
> > --
> > John
> > :wq
>


-- 
John
:wq

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Number of cores in examples

[John Harrold]

Thanks Uwe,

Is there a way to find out on my end where this is happening?

Thanks
john

On Fri, Sep 13, 2019 at 10:51 PM Uwe Ligges 
wrote:

>
>
> On 14.09.2019 03:33, John Harrold wrote:
> > Hello,
> >
> > I recently submitted a package for consideration in CRAN. One of the
> > comments was:
> >
> > Please ensure that you do not use more than 2 cores in your examples.
> >
> > I do not believe my package does this. Is this a general comment for a
> > package that requires doParallel or was this triggered because one of my
> > examples actually used more than 2 cores?
>
> The latter. In examples, vignettes and tests you must not start more
> than 2 workers as resources for CRAN checks are limited.
>
> Best,
> Uwe Ligges
>
>
> >
> > Thanks
> > John
> >
>


-- 
John
:wq

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Number of cores in examples

[John Harrold]

Hello,

I recently submitted a package for consideration in CRAN. One of the
comments was:

Please ensure that you do not use more than 2 cores in your examples.

I do not believe my package does this. Is this a general comment for a
package that requires doParallel or was this triggered because one of my
examples actually used more than 2 cores?

Thanks
John
-- 
John
:wq

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] replacing previous import

[John Harrold]

Howdy Folks,

I'm getting the following warning:

Found the following significant warnings:
  Warning: replacing previous import ‘gdata::combine’ by
‘gridExtra::combine’ when loading

In the R scripts I'm using
#'@importFrom gridExtra grid.arrange

To only import the function I want, but I'm not sure how to do that in the
DESCRIPTION file. Is there anything I can do to eliminate this warning or
is this OK?

-- 
Thanks,
John
:wq

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Misspelled words in DESCRIPTION

[John Harrold]

Yeah that's it. Thanks Uwe and Ben.

On Mon, Aug 19, 2019 at 3:21 PM Ben Bolker  wrote:

>
>   I suspect the NOTE said something about "*possibly* misspelled words"
> (emphasis added). This should be OK; just put the explanation below in
> your notes to CRAN about the submission, clarifying that this is indeed
> a false positive.
>
>   cheers
> Ben Bolker
>
> On 2019-08-19 6:13 p.m., John Harrold wrote:
> > Hello,
> >
> > I am attempting to submit my first package to CRAN. I believe I've
> > successfully gotten rid of all the notes, but there is one that I'm
> unable
> > to eliminate. In the DESCRIPTION file in both the Title and Description
> > fields I use the term PKPD. This stands for Pharmacokinetics and
> > Pharmacodynamics. It seems that none of these are recognized as words
> that
> > are spelled correctly. They are kind of important in the context of the
> > package and there are no other better or more accurate descriptors that I
> > can use.
> >
> > Is there a way to get around this?
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
John
:wq

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Misspelled words in DESCRIPTION

[John Harrold]

Hello,

I am attempting to submit my first package to CRAN. I believe I've
successfully gotten rid of all the notes, but there is one that I'm unable
to eliminate. In the DESCRIPTION file in both the Title and Description
fields I use the term PKPD. This stands for Pharmacokinetics and
Pharmacodynamics. It seems that none of these are recognized as words that
are spelled correctly. They are kind of important in the context of the
package and there are no other better or more accurate descriptors that I
can use.

Is there a way to get around this?

-- 
Thanks,
John
:wq

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel