2 Notes from CRAN pre-test on v1.1.3

[LittleBeannie]

Note 1:

* checking dependencies in R code ... NOTE
Missing object imported by a ':::' call: 'simtrial:::as_gt.simtrial_gs_wlr'

Note 2:

Examples with CPU (user + system) or elapsed time > 10s
               user system elapsed
gs_design_wlr 10.46   0.11   10.58

I will work on a new gsDesign2 v1.1.3 and start with the 2nd note first.
@jdblischak, do you happen to know the reason of the 1st note?

[jdblischak]

do you happen to know the reason of the 1st note?

Yes. We added it to the CRAN comments in #480. Do you manually build and upload the tarball, or do you use a devtools convenience function? If you are doing it manually, you need to copy-paste the contents of cran-comments.md into the submission comments box.

gsDesign2/cran-comments.md

Lines 1 to 8 in 67e7423

	# gsDesign2 1.1.3
	We are aware of the following NOTE, and we also maintain {simtrial}:
	```
	* checking dependencies in R code ... NOTE
	Missing object imported by a ':::' call: ‘simtrial:::as_gt.simtrial_gs_wlr’
	```

Recall that according to @yihui (Merck/simtrial#287 (review)), CRAN allows the use of ::: to access internal functions of another package only when they have the same maintainer.

[yihui]

Before the new version of simtrial is on CRAN, we can conditionally call the internal function via something like this:

.as_gt <- asNamespace('simtrial')$as_gt.simtrial_gs_wlr
if (is.function(.as_gt)) .as_gt(...) else stop('simtrial version too low')

After the new release of simtrial, we can switch to getFromNamespace().

[jdblischak]

I don't think this is necessary. The class "simtrial_gs_wlr" does not exist in simtrial 0.4.1 (the current version on CRAN). The class was added at the same time as the methods as_gt() and summary() (Merck/simtrial@89a6657). Thus there is no chance of this code path being executed if someone is running simtrial <= 0.4.1, ie since no objects have the class, there will never be S3 dispatch to this non-existent method.

[jdblischak]

Submitted getFromNamespace() workaround in #492