CRAN Package Check Results for Maintainer ‘John R. Stevens <john.r.stevens at usu.edu>’

Last updated on 2024-11-21 19:53:10 CET.

Package WARN NOTE OK
phyext2 13
SigTree 1 10 2

Package phyext2

Current CRAN status: OK: 13

Package SigTree

Current CRAN status: WARN: 1, NOTE: 10, OK: 2

Version: 1.10.6
Check: Rd files
Result: NOTE checkRd: (-1) export.figtree.Rd:64: Lost braces; missing escapes or markup? 64 | The tip labels of \code{tree} (accessed via \code{tree$tip.label}) must have the same names (and the same length) as the tip labels in \code{unsorted.pvalues}, but may be in a different order. The p-values in column 2 of \code{unsorted.pvalues} obviously must be in the [0, 1] range. \code{p.cutoffs} takes values in the (0, 1) range. The default value for \code{p.cutoffs} is \code{c(0.01, 0.05, 0.1, 0.9, 0.95, 0.99)} if side is \code{1} and \code{c(0.01, 0.05, 0.1)} if side is \code{2}. Thus, the ranges (when side is \code{1}) are: [0, .01], (.01, .05], ..., (.99, 1]. These ranges correspond to the colors specified in \code{pal}. P-values in the [0, .01] range correspond to the left-most color if \code{pal} is a palette (view this via \code{display.brewer.pal(x, pal)} - where \code{x} is the number of colors to be used) or the first value in the vector if \code{pal} is a vector of colors. If \code{pal} is a vector of colors, then the length of \code{pal} should be one greater than the length of \code{p.cutoffs}. In other words, its length must be the same as the number of p-value ranges. In addition, each color in this vector of colors needs to be in hexadecimal format, for example, \code{"#B2182B"}. Formats of colors other than hexadecimal will likely give unwanted results in the edges of the tree produced in \emph{FigTree}, such as all-black edges or the edges being colored in a meaningless way. This is because the color conversion assumes hexadecimal colors. The default value of \code{pal} is \code{"RdBu"} (a divergent palette of reds and blues, with reds corresponding to small p-values) if \code{side} is \code{1} and the reverse of \code{"Reds"} (a sequential palette) if \code{side} is {2}. The sequential palettes in \code{RColorBrewer} go from light to dark, so \code{"Reds"} is reversed so that the dark red corresponds to small p-values. It probably makes more sense to use a divergent palette when using 1-sided p-values and a sequential palette (reversed) when using 2-sided p-values. To create a vector of reversed colors from a palette with \code{x} number of colors and \code{"PaletteName"} as the name of the palette, use \code{rev(brewer.pal(x, "PaletteName"))}. \code{ignore.edge.length} may be useful to get a more uniformly-shaped tree. \code{export.figtree} assumes that each internal node has exactly two descendants. It also assumes that each internal node has a lower number than each of its ancestors (excluding tips). | ^ checkRd: (-1) plotSigTree.Rd:91: Lost braces; missing escapes or markup? 91 | The tip labels of \code{tree} (accessed via \code{tree$tip.label}) must have the same names (and the same length) as the tip labels in \code{unsorted.pvalues}, but may be in a different order. The p-values in column 2 of \code{unsorted.pvalues} obviously must be in the [0, 1] range. \code{p.cutoffs} takes values in the (0, 1) range. The default value for \code{p.cutoffs} is \code{c(0.01, 0.05, 0.1, 0.9, 0.95, 0.99)} if \code{side} is \code{1} and \code{c(0.01, 0.05, 0.1)} if side is \code{2}. Thus, the ranges (when side is \code{1}) are: [0, .01], (.01, .05], ..., (.99, 1]. These ranges correspond to the colors specified in \code{pal}. P-values in the [0, .01] range correspond to the left-most color if \code{pal} is a palette (view this via \code{display.brewer.pal(x, pal)} - where \code{x} is the number of colors to be used) or the first value in the vector if \code{pal} is a vector of colors. If \code{pal} is a vector of colors, then the length of \code{pal} should be one greater than the length of \code{p.cutoffs}. In other words, its length must be the same as the number of p-value ranges. An example of a color in hexadecimal format is \code{"#B2182B"}. The default value of \code{pal} is \code{"RdBu"} (a divergent palette of reds and blues, with reds corresponding to small p-values) if \code{side} is \code{1} and the reverse of \code{"Reds"} (a sequential palette) if \code{side} is {2}. The sequential palettes in \code{RColorBrewer} go from light to dark, so \code{"Reds"} is reversed so that the dark red corresponds to small p-values. It probably makes more sense to use a divergent palette when using 1-sided p-values and a sequential palette (reversed) when using 2-sided p-values. To create a vector of reversed colors from a palette with \code{x} number of colors and \code{"PaletteName"} as the name of the palette, use \code{rev(brewer.pal(x, "PaletteName"))}. \code{use.edge.length} may be useful to get a more uniformly-shaped tree. \code{plotSigTree} assumes that each internal node has exactly two descendants. It also assumes that each internal node has a lower number than each of its ancestors (excluding tips). | ^ Flavors: r-devel-linux-x86_64-debian-clang, r-devel-linux-x86_64-debian-gcc, r-devel-linux-x86_64-fedora-clang, r-devel-linux-x86_64-fedora-gcc, r-devel-windows-x86_64, r-patched-linux-x86_64, r-release-linux-x86_64, r-release-macos-arm64, r-release-macos-x86_64, r-release-windows-x86_64

Version: 1.10.6
Check: for non-standard things in the check directory
Result: NOTE Found the following files/directories: ‘ExportFigtree1.tre’ Flavors: r-devel-linux-x86_64-debian-clang, r-devel-linux-x86_64-debian-gcc, r-devel-linux-x86_64-fedora-clang, r-devel-linux-x86_64-fedora-gcc, r-patched-linux-x86_64, r-release-linux-x86_64

Version: 1.10.6
Check: examples
Result: WARN Found the following significant warnings: Warning: 'adonis' is deprecated. Warning: 'adonis' is deprecated. Warning: 'adonis' is deprecated. Warning: 'adonis' is deprecated. Deprecated functions may be defunct as soon as of the next release of R. See ?Deprecated. Flavor: r-oldrel-windows-x86_64

These binaries (installable software) and packages are in development.
They may not be fully stable and should be used with caution. We make no claims about them.