Re: [R-pkg-devel] Problem enhancing a package with a predict method not declared to be an S3 method
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_
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
[Rd] Dialect for shell scripts
Dear all, During a recent package submission, we were highlighted that some lines in our configure script didn't follow the correct syntax. The lines looked like this: x=$(($y/10)) We were indicated at the time that this is because the statement does not use Bourne shell syntax, which is absolutely true, and also that the manual warns about this, which is true again. So far everything is clear. However, what confuses me is that even when the manual says that "you can include an executable (Bourne) shell script configure in your package" [1], the associated footnote says something slightly different: "The script should only assume a POSIX-compliant /bin/sh" [2]. The footnote goes even further, and links to the POSIX specification of the Shell Command Language [3] (as published by The Open Group), which explicitly includes arithmetic expressions like the one above in its syntax [4]. My question then is: what exact dialect should be considered? Given that the statement above does not work in the Bourne shell, I conclude that the Bourne shell is not POSIX-compliant. That in turn would make the manual ambiguous as to the precise dialect that should be used by our configure scripts, and either the shells used by R should be changed to be POSIX-compliants, or the manual edited to be more precise regarding . Many thanks. Rodrigo [1] https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Configure-and-cleanup [2] https://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT25 [3] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html [4] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Collaborative Wiki for fostering Open Innovation in R
Dear R Developers, I am writing in order to open a constructive debate whether if it is worth it that R Project adopts the Apache Software Foundation & Wikipedia Model for Open Documentation by using a Collaborative Wiki & Document Store (As a complement to Bugzilla and Mailing Lists), for fostering collaboration in R Development. The objective would be to promote innovation and collaboration between: • R Contributors. • R Core. • And R Community. For: • R Development. • R Contributed Documentation. • R Internals Wiki. The Wikis Section could be structured in different Sub-Wikis (or Pages) with different levels of permissions: • Some only editable by R Core. • Others only editable by R Core, and R Contributors. • And others editable by any member of R Community. And have different Categories, such as: • R Learning Resources. • R Cheatsheets. • R Development & Key Internals. • R Contributed Documentation. • R Help. • etc. A key point would be that the wikis are installed, hosted and accesible through CRAN Servers, as a way to give some collaborative GUI to CRAN hosted documentation. Three collaborative wikis worth to consider would be: • xwiki SAS (Open Source): http://www.xwiki.org • Atlassian Confluence (Free for Open Source Projects): https://www.atlassian.com/software/confluence • MediaWiki: www.mediawiki.org I personally prefer xwiki for being 100% Open Source, and being editable with a Markdown Syntax; but we use Confluence at work and I am also very happy with it; and MediaWiki is the one Wikipedia uses, but seems difficult to use. Thank you & best, Juan [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Issue related to Rlapack
Hi, I am having an issue regarding R3.4.3. I am launching R instance from RDotNet using following two statements: REngine.SetEnvironmentVariables(rPath, rHome); this._RServer = REngine.GetInstance(); Where rPath = "C:\Program Files\R\R-3.4.3\bin\x64" rHome = "C:\Program Files\R\R-3.4.3" As soon as the second statement (REngine.GetInstance() ) executes I get following error: " *The Program can't start because Rplpack.dll is missing from your computer. Try reinstalling the program to fix this problem.*" I checked, Rplpack.dll is in my rPath location. I did not get this error in the older versions of R. Only R3.4.3 is having this issue. Please help. -- Thanks and regards, Anil [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] workflow page reorganization
Thank you all for the efforts on this! I agree with Mike that there's a lot of yet untapped potential in the workflows, for all levels of BioC users: for beginners, to make their first steps, for more experienced users, to learn new stuff. Mike's points 1-5 are great, I second them. And then some polite pushback on categorization... I think for a volume of one-two dozen workflows, browsing based on short descriptions (Mike's point 3) will often be preferable. And if the volume gets larger, I noted that "search" rather than "manually curated hierarchical menu trees" drives many successful websites (Amazon, Google) and there's probably a lesson in there. Best wishes Wolfgang 15.12.17 16:55, Michael Love scripsit: This already looks much improved, thanks Andrzej and Aaron. I think workflows are where it's at, and this page is probably underappreciated by Bioconductor users and the outside community. My wishlist for the workflows page, which may exceed what is available for the current effort: 1) It should say at the top which version of R/Bioconductor the workflows are being built on. 2) On the main page, for each workflow: * A thumbnail (could live in a pre-specified location in the package) * Author list (autopopulated from DESCRIPTION) * Version * Link to the (most current) F1000Research articles for those which are published (new field in DESCRIPTION?) * Some kind of CI "buttony" thing, to indicate to users that these are live documents * Key Bioc/R packages used in this worfklow (could this also be an additional DESCRIPTION field?) 3) I think it would be good to encourage the more stubby workflow descriptions to add more text, and maybe to decrease the very words ones, so that it's more consistent. Wow, that's pretty obsessive of me, but I think it would make the page look more professional. 4) Text somewhere with a link to the support site and how to ask for help on workflows (e.g. vignette(), ?functionName) 5) An advertisement somewhere for submitting a workflow, link to more detailed doc elsewhere ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- With thanks in advance- Wolfgang --- Wolfgang Huber Principal Investigator, EMBL Senior Scientist European Molecular Biology Laboratory (EMBL) Heidelberg, Germany wolfgang.hu...@embl.de http://www.huber.embl.de ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
