Re: [R-pkg-devel] Problem enhancing a package with a predict method not declared to be an S3 method

2017-12-17 Thread Chris Brien
Hi Duncan,

Thanks for your comments. I appreciate that you do not speak for CRAN. 

I had thought that, while I am accessing asreml internals, I do not believe 
that it is the intention of the maintainer that they be internal. Indeed, I am 
only calling functions documented in the manual and so it would appear that 
they are intended to be part of the API for the packages. I had hoped that this 
would be an allowed exception.

Nonetheless, I am attempting to contact the maintainer and I will see what that 
brings.

Regards,

  Chris


-Original Message-
From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com] 
Sent: Saturday, 16 December 2017 10:18 PM
To: Chris Brien; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Problem enhancing a package with a predict method 
not declared to be an S3 method

On 15/12/2017 11:52 PM, Chris Brien wrote:
> Dear list members,
> 
> I am in a bind.
> 
> I have a package asremlPlus that "Enhances" the commercial package asreml 
> (and asreml4), for which I am not a maintainer. It is not available in a 
> public repository and because of this, when checking it for CRAN, it always 
> gives the following NOTE, which is acceptable to CRAN:
> 
> Suggests or Enhances not in mainstream repositories:
>asreml, asreml4
> 
> Now asreml has three functions summary.asreml, fitted.asreml and 
> predict.asreml that are (i) not exported and (ii) not declared to be S3 
> methods. In spite of this it is possible to call them using summary, fitted 
> and predict.
> 
> However, if I do this in the code then the suite of unit tests that I have 
> for asremlPlus fails when run with testthat::test_check with the following 
> Error:
> 
>  [31m1. Error: predictPlus.asreml (@testPredictionsPresentation.r#17) 
>  [39m--- could not find function "ie"
> 1: predictPlus.asreml(classify = "Sources:Type", asreml.obj = 
> current.asr, tables = "none", wald.tab = current.asrt$wald.tab, 
> present = c("Type", "Species", "Sources")) at 
> testthat/testPredictionsPresentation.r:17
> 2: predict(asreml.obj, classify = classify, sed = pairwise, trace = 
> trace, ...)
> 3: predict.asreml(asreml.obj, classify = classify, sed = pairwise, 
> trace = trace, ...)
> 
> On the other hand, the test completes successfully if I manually execute it 
> line-by-line, but this is not feasible in practice because there are 21 sets 
> of tests.
> 
> The manifest problem is "ie", which is another unexported function in asreml, 
> apparently called by predict.asreml.
> Has anyone on this list advice to offer on how this problem might be overcome?
> 
> Any help gratefully received,
> 
> Chris Brien, University of South Australia
> 
> PS I know that the problem can be avoided by calling the functions 
> within asremlPlus using asreml:::, but this appears to be unacceptable 
> to CRAN because it produces the NOTE
> 
> Unavailable namespaces imported from by ':::' calls:
>'asreml' 'asreml4'
>See the note in ?`:::` about the use of this operator.
> 
> And the NOTE in ?':::' says
> 
> It is typically a design mistake to use ::: in your code since the 
> corresponding object has probably been kept internal for a good reason. 
> Consider contacting the package maintainer if you feel the need to access the 
> object for anything but mere inspection.

I don't speak for CRAN, but I think it is consistent with their philosophy that 
a package doing what yours does should not be allowed there.

Your package depends on the internals of asreml.  There is nothing to stop that 
package from changing them, causing your package to generate errors or 
incorrect results.  CRAN does what it can to prevent this kind of error, and it 
can't do it with yours.

I'd suggest that you contact the maintainers of asreml, and ask them to export 
the functions you need.  If they are unwilling to do that, then you could ask 
them to distribute your package, or distribute it yourself (e.g. by making it 
available on Github).

One other possibility is that their license would allow you to copy enough of 
their package into yours that you wouldn't need the ::: 
import, but that seems unlikely.

Duncan Murdoch


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


Re: [R-pkg-devel] Lapack: undefined symbol: zgbsv_

2017-12-17 Thread Dirk Eddelbuettel

On 17 December 2017 at 17:50, Dirk Eddelbuettel wrote:
| In short, but relying on (Rcpp)Armadillo, you are submit to it changing its

That should have read: "... by relying on (Rcpp)Armadillo, you are subject to 
..."

My bad.

| solver and it seems to have done so recently.  And as R is primarily
| concerned with double precision, that version you now need was never
| included.

Also, eg on the system where I do reverse-dependency checks, cda was never an
issue as we use the external libraries:

   edd@bud:~/git/rcpp-logs/logs/rcpparmadillo(master)$ grep ^cda 
log-RcppArmadillo-2017*
   log-RcppArmadillo-20170411-1403.txt:cda_2.0.0.tar.gz : success (42 of 344, 
[...]
   log-RcppArmadillo-20170503-1207.txt:cda_2.0.0.tar.gz : success (43 of 347, 
[...]
   log-RcppArmadillo-20170504-0609.txt:cda_2.0.0.tar.gz : success (43 of 347, 
[...]
   log-RcppArmadillo-20170516-1041.txt:cda_2.0.0.tar.gz : success (44 of 349, 
[...]
   log-RcppArmadillo-20170523-1147.txt:cda_2.0.0.tar.gz : success (43 of 349, 
[...]
   log-RcppArmadillo-20170524-1940.txt:cda_2.0.0.tar.gz : success (43 of 349, 
[...]
   log-RcppArmadillo-20170531-0642.txt:cda_2.0.0.tar.gz : success (43 of 350, 
[...]
   log-RcppArmadillo-20170619-0918.txt:cda_2.0.0.tar.gz : success (44 of 357, 
[...]
   log-RcppArmadillo-20170801-1435.txt:cda_2.0.0.tar.gz : success (48 of 375, 
[...]
   log-RcppArmadillo-20170803-1102.txt:cda_2.0.0.tar.gz : success (48 of 376, 
[...]
   log-RcppArmadillo-20170808-1000.txt:cda_2.0.0.tar.gz : success (48 of 377, 
[...]
   log-RcppArmadillo-20170810-0908.txt:cda_2.0.0.tar.gz : success (48 of 377, 
[...]
   log-RcppArmadillo-20170819-1325.txt:cda_2.0.0.tar.gz : success (49 of 381, 
[...]
   log-RcppArmadillo-20171002-1006.txt:cda_2.0.0.tar.gz : success (55 of 400, 
[...]
   log-RcppArmadillo-20171009-0935.txt:cda_2.0.0.tar.gz : success (55 of 405, 
[...]
   log-RcppArmadillo-20171021-0734.txt:cda_2.0.0.tar.gz : success (56 of 411, 
[...]
   log-RcppArmadillo-20171023-1227.txt:cda_2.0.0.tar.gz : success (56 of 412, 
[...]
   log-RcppArmadillo-20171108-2024.txt:cda_2.0.0.tar.gz : success (57 of 426, 
[...]
   log-RcppArmadillo-20171123-0845.txt:cda_2.0.0.tar.gz : success (58 of 434, 
[...]
   log-RcppArmadillo-20171123-1539.txt:cda_2.0.0.tar.gz : success (58 of 434, 
[...]
   log-RcppArmadillo-20171201-1053.txt:cda_2.0.0.tar.gz : success (56 of 430, 
[...]
   log-RcppArmadillo-20171204-0848.txt:cda_2.0.0.tar.gz : success (56 of 431, 
[...]
   log-RcppArmadillo-20171210-0828.txt:cda_2.0.0.tar.gz : success (57 of 435, 
[...]
   edd@bud:~/git/rcpp-logs/logs/rcpparmadillo(master)$ [...]

| In short, you seem to now have a requirement which R Core _may_ solve for you
| in time for R 3.5.0.  Otherwise your users will have to rely on systems with
| a full (external) Lapack/Blas and not the smaller embedded one.

That really seems to be the only way forward, short of embedding the routine
in cda.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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