release schedule

[topepo]

When do you think that you'll do another release? I have a recipes version going to CRAN before the end of the year and I wasn't sure if I could include the NNMF or autoencoder features from dimRed in that version.

[gdkrmr]

yes, I wanted to make another release very soon, I was waiting for the R journal manuscript to be published, to include it as a vignette, but then I did not really find time to actually do it.

[gdkrmr]

I just tried to submit version 0.2.0 to CRAN, but it gets stuck with recipes in the reverse dependencies check:

https://win-builder.r-project.org/incoming_pretest/dimRed_0.2.0_20181012_094004/reverseDependencies/summary.txt

Recipes does not install, what should I tell the CRAN maintainers?

[topepo]

I assume that this means that, with the new version of dimRed, the CRAN version of recipes will not install. I'll look into it today (which will mostly be spent trying to to get pcaL1 installed from source).

[topepo]

I think that we need more information from the CRAN folks. win-builder only shows:

Results:
Check status summary:
                  ERROR OK
  Source packages     0  1
  Reverse depends     1  0

Check results summary:
dimRed ... OK
rdepends_recipes ... ERROR
* checking whether package ‘recipes’ can be installed ... [3s/3s] ERROR

Check results changes:
Package: recipes
Check: whether package can be installed
New result: ERROR

I don't see a file or directory that has the details.

There are no baseline issues with recipes.

I also tried using revdepcheck and had no errors:

> library(revdepcheck)
> revdep_check()
── INIT ─────────────────────────────────────────────────── Computing revdeps ──
── INSTALL ─────────────────────────────────────────────────────── 2 versions ──
Installing CRAN version of dimRed
Installing DEV version of dimRed
Installing 4 packages: CVST, doParallel, iterators, kernlab
── CHECK ───────────────────────────────────────────────────────── 1 packages ──
✔ recipes 0.1.3                          ── E: 0     | W: 2     | N: 0          
OK: 1                                                                         
BROKEN: 0
Total time: 3 min
── REPORT ──────────────────────────────────────────────────────────────────────
Writing summary to 'revdep/README.md'
Writing problems to 'revdep/problems.md'

> sessioninfo::session_info()
─ Session info ───────────────────────────────────────────────────────────────────────────────────────────────────────
 setting  value                       
 version  R version 3.5.0 (2018-04-23)
 os       macOS High Sierra 10.13.6   
 system   x86_64, darwin15.6.0        
 ui       X11                         
 language (EN)                        
 collate  en_US.UTF-8                 
 ctype    en_US.UTF-8                 
 tz       America/New_York            
 date     2018-10-12                  

─ Packages ───────────────────────────────────────────────────────────────────────────────────────────────────────────
 ! package     * version     date       lib source                               
   assertthat    0.2.0       2017-04-11 [1] CRAN (R 3.5.0)                       
   backports     1.1.2       2017-12-13 [1] CRAN (R 3.5.0)                       
   base64enc     0.1-3       2015-07-28 [1] CRAN (R 3.5.0)                       
   bit           1.1-14      2018-05-29 [1] CRAN (R 3.5.0)                       
   bit64         0.9-7       2017-05-08 [1] CRAN (R 3.5.0)                       
   blob          1.1.1       2018-03-25 [1] CRAN (R 3.5.0)                       
 V callr         3.0.0.9000  2018-10-12 [1] Github (r-lib/callr@d0ea2b6)         
 V cli           1.0.1       2018-10-12 [1] Github (r-lib/cli@56538e3)           
   clisymbols    1.2.0       2017-05-21 [1] CRAN (R 3.5.0)                       
   crancache     0.0.0.9000  2018-06-25 [1] Github (r-lib/crancache@e2185c7)     
   cranlike      1.0.1.9001  2018-06-25 [1] Github (r-hub/cranlike@3c72c14)      
   crayon        1.3.4       2017-09-16 [1] CRAN (R 3.5.0)                       
   curl          3.2         2018-03-28 [1] CRAN (R 3.5.0)                       
   DBI           1.0.0       2018-05-02 [1] CRAN (R 3.5.0)                       
   debugme       1.1.0       2017-10-22 [1] CRAN (R 3.5.0)                       
   desc          1.2.0       2018-10-12 [1] Github (r-lib/desc@7c12d36)          
 V digest        0.6.17      2018-10-10 [1] CRAN (R 3.5.0)                       
   glue          1.3.0       2018-10-09 [1] Github (tidyverse/glue@4e74901)      
   gmailr        0.7.1       2016-04-12 [1] CRAN (R 3.5.0)                       
   highr         0.7         2018-06-09 [1] CRAN (R 3.5.0)                       
   hms           0.4.2       2018-03-10 [1] CRAN (R 3.5.0)                       
   httr          1.3.1       2017-08-20 [1] CRAN (R 3.5.0)                       
   jsonlite      1.5         2017-06-01 [1] CRAN (R 3.5.0)                       
   knitr         1.20        2018-02-20 [1] CRAN (R 3.5.0)                       
   magrittr      1.5         2014-11-22 [1] CRAN (R 3.5.0)                       
   memoise       1.1.0       2017-04-21 [1] CRAN (R 3.5.0)                       
   parsedate     1.1.3       2017-03-02 [1] CRAN (R 3.5.0)                       
   pkgbuild      1.0.1.9000  2018-10-12 [1] Github (r-lib/pkgbuild@446d70c)      
   pkgconfig     2.0.2       2018-08-16 [1] CRAN (R 3.5.0)                       
   prettyunits   1.0.2       2015-07-13 [1] CRAN (R 3.5.0)                       
   processx      3.2.0.9000  2018-10-07 [1] Github (r-lib/processx@8374340)      
   progress      1.2.0.9000  2018-10-12 [1] Github (gaborcsardi/progress@54a14f5)
   ps            1.1.0       2018-08-10 [1] CRAN (R 3.5.0)                       
   R6            2.3.0       2018-10-04 [1] CRAN (R 3.5.0)                       
   rappdirs      0.3.1       2016-03-28 [1] CRAN (R 3.5.0)                       
   rcmdcheck     1.3.0.9000  2018-10-12 [1] Github (r-lib/rcmdcheck@6a3afa2)     
   Rcpp          0.12.19.2   2018-10-08 [1] Github (RcppCore/Rcpp@b7dc5f1)       
   remotes       2.0.0.9000  2018-10-12 [1] Github (r-lib/remotes@15e515b)       
   revdepcheck * 1.0.0.9000  2018-10-12 [1] Github (r-lib/revdepcheck@1a43564)   
   rlang         0.2.99.0000 2018-10-12 [1] Github (r-lib/rlang@30d6671)         
   rprojroot     1.3-2       2018-01-03 [1] CRAN (R 3.5.0)                       
   RSQLite       2.1.1       2018-05-06 [1] CRAN (R 3.5.0)                       
   sessioninfo   1.1.0       2018-09-25 [1] CRAN (R 3.5.0)                       
   whoami        1.2.0       2018-09-11 [1] CRAN (R 3.5.0)                       
   withr         2.1.2       2018-03-15 [1] CRAN (R 3.5.0)                       
   xopen         1.0.0       2018-09-17 [1] CRAN (R 3.5.0)                       
   yaml          2.2.0       2018-07-25 [1] CRAN (R 3.5.0)                       

[1] /Library/Frameworks/R.framework/Versions/3.5/Resources/library

 V ── Loaded and on-disk version mismatch.

[gdkrmr]

It seems that there are timeout issues with my package I have to solve first. CRAN only lets the package build for 10 minutes before aborting. The new vignette I added added an extra 250s to build time :-)

[topepo]

I don't know if you want to got this route, but I like to have real examples that take longer to run. tidyposterior has an overall flag for running the file. See this (CRAN) versus [this]() (pkgdown site).

[gdkrmr]

Do you know if the vignette published on CRAN is the one I send, or the one that is rebuilt during testing? Then I could simply cheat CRAN into building a dummy.

[topepo]

They publish what we give them but run the code for testing (I had to look it up):

Note that since you build vignettes locally, CRAN only receives the html/pdf and the source code. However, CRAN does not re-build the vignette. It only checks that the code is runnable (by running it). This means that any packages used by the vignette must be declared in the DESCRIPTION. But this also means that you can use Rmarkdown (which uses pandoc) even though CRAN doesn’t have pandoc installed.

[gdkrmr]

This is really frustrating: I cut down a lot of test time and did a bad hack to avoid rebuilding of the vignette, but winbuilder time went from 600s up to 750s, even though the timings for tests went down, maybe I have to resubmit at midnight (or wait until the next full moon) when there is less congestion on the server.

[topepo]

What branch are you working from?

[gdkrmr]

the version I sent to CRAN is on develop---minus the version number increase.

[topepo]

I get the same problem with

test_dimRedData.R:32: failure: misc functions
nrow(Iris) not equal to 150.
target is NULL, current is numeric

Not sure what to do there.

I suggest using skip_on_cran() for the high level function, AutoEncoder, and NNMF tests to solve the time problem.

[gdkrmr]

win-builder takes 350s, this has to be enough, it used to take 1000s.

[gdkrmr]

Sorry for the delay, but this was really frustrating and I had some other stuff to do besides jumping through CRAN-hoops. dimRed just passed the pretests on CRAN, but the reverse dependency check for recipes fails again:

https://win-builder.r-project.org/incoming_pretest/dimRed_0.2.0_20181106_212055/

I cannot find any useful information in the logs.

EDIT: I just installed recipes master without any problems, some of the tests fail:

OK:       1149
Failed:   5
Warnings: 9
Skipped:  0

[topepo]

I would email cran-submissions@r-project.org (or post to R-devel) and ask for advice. Was this an issue from a CRAN submission (or just from pre-testing)?

edit: changed email

[gdkrmr]

CRAN submission and it's the reverse dependency check that fails. I just wrote to the CRAN maintainers, let's see if they have any suggestions.

[topepo]

Can you try adding this version requirement to the description file: Matrix (>= 1.2-15) and try win-builder again?

[gdkrmr]

you mean resubmit? Win-builder worked just fine.

[topepo]

I was thinking to test with. I'm starting to think that this issue is stringi; it has never really built on the same specific architecture that dimRed fails on.

[gdkrmr]

Finally on CRAN! Sorry for the delay. I will reopen in case CRAN catches fire due to dimRed.

[DavisVaughan]

Did CRAN catch fire? I see 0.2.1 from today on there, and a Biobase dependency? But I don't see that anywhere in the github code. Is that new? Additionally, when I try and install:

> install.packages("dimRed")
Warning in install.packages :
  dependency ‘Biobase’ is not available

Travis can't seem to find it either 😢 https://travis-ci.org/tidymodels/recipes/jobs/452987202#L3350

[DavisVaughan]

Did ripley repackage your package and reupload? I downloaded the tar.gz of 0.2.1 and this is the DESCRIPTION file. Note the "Packaged" line near the bottom. The 0.2.0 release says your name.

(Maybe because NMF suggests them?)

Package: dimRed
Title: A Framework for Dimensionality Reduction
Version: 0.2.1
Authors@R: c(
    person("Guido", "Kraemer",
           email = "gkraemer@bgc-jena.mpg.de",
           role = c("aut", "cre"))
    )
Description: A collection of dimensionality reduction
    techniques from R packages and a common
    interface for calling the methods.
Depends: R (>= 3.0.0), DRR
Imports: NMF, magrittr, methods, bigmemory, Biobase
Suggests: cccd, MASS, Matrix, RANN, RSpectra, Rtsne, coRanking,
        diffusionMap, energy, fastICA, ggplot2, graphics, igraph,
        keras, kernlab, knitr, lle, loe, optimx, pcaL1, pcaPP,
        reticulate, rgl, scales, scatterplot3d, stats, tensorflow,
        testthat, tidyr, tinytex, umap, vegan
VignetteBuilder: knitr
License: GPL-3 | file LICENSE
URL: https://github.com/gdkrmr/dimRed
LazyData: true
Encoding: UTF-8
Collate: 'dimRedMethod-class.R' 'misc.R' 'dimRedData-class.R'
        'dimRedResult-class.R' 'autoencoder.R' 'dataSets.R' 'diffmap.R'
        'dimRed.R' 'drr.R' 'embed.R' 'fastica.R' 'get_info.R'
        'graph_embed.R' 'hlle.R' 'isomap.R' 'kpca.R' 'l1pca.R' 'leim.R'
        'lle.R' 'loe.R' 'mds.R' 'mixColorSpaces.R' 'nmds.R' 'nnmf.R'
        'pca.R' 'plot.R' 'quality.R' 'rotate.R' 'soe.R' 'tsne.R'
        'umap.R'
RoxygenNote: 6.1.0
NeedsCompilation: yes
Packaged: 2018-11-09 11:51:39 UTC; ripley
Author: Guido Kraemer [aut, cre]
Maintainer: Guido Kraemer <gkraemer@bgc-jena.mpg.de>
Repository: CRAN
Date/Publication: 2018-11-09 16:03:21 UTC

[topepo]

Having an import of Biobase is a big potential problem for recipes. We've have to give additional code for people to get that package before installing recipes since install.packages won't install it.

Was that discussed anywhere?

[gdkrmr]

Yes, CRAN caught fire. Yes, Brian Ripley did a hack to fix this and bumped the version number to 0.2.1 Yes, I am really not happy about importing bigmemory and Biobase. I would really like to fix this. The main problem is that I have not found a way to reproduce this on my machine or travis so I am flying blind.

My current working hypothesis is that dimRed does not call setGeneric("nrow"), which never was a problem until (through NMF) it depended somehow on BiocGenerics which does that call to setGeneric("nrow").

I don't understand how I can make this reproducible on my ubuntu machine.

Here is the relevant part of Brian Ripleys mail:

See https://cran.r-project.org/web/checks/check_results_dimRed.html The crux is

** testing if installed package can be loaded Warning: namespace ‘Biobase’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘bigmemory’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘Biobase’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘bigmemory’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘Biobase’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘Biobase’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘Biobase’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘Biobase’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘bigmemory’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘bigmemory’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Warning: namespace ‘bigmemory’ is not available and has been replaced by .GlobalEnv when processing object ‘’ Error: package or namespace load failed for ‘dimRed’: Function found when exporting methods from the namespace ‘dimRed’ which is not S4 generic: ‘nrow’ Error: loading failed Execution halted ERROR: loading failed

The failures come from checking with _R_CHECK_INSTALLDEPENDS=true, part of --as-cran. It appears that you intended to use the nrow() generic from bigmemory, but did not import it. And something else in the package depends on the Biobase namespace. (These are put on the search path by NMF, but you cannot rely on that.)

[gdkrmr]

I tried Brian Ripley's suggestion and v0.2.0 keeps passing on my machine and on travis.

What about:

• Move NMF to Suggests
• remove require("NMF")
• check if the user already called library("NMF")/require("NMF")
• if the user did not, prompt him to do so before using non-negative matrix factorization.

[DavisVaughan]

There's a pretty standard way to do that I think. It uses requireNamespace(). Here's an example https://github.com/DavisVaughan/nodegraph/blob/master/R/plot.R

(I don't yet put the package in Suggests but you should for NMF)

[gdkrmr]

I am usually doing exactly this, see here, but there was a problem with NMF so it had to be moved to Depends, see here.

@topepo on current develop I have moved NMF back to suggests and everything seems to work fine on my computer, on travis, and winbuilder (except oldrelease which gives an unrelated error), can you please check.

[topepo]

I have a recipes branch that has your develop branch in its remotes and has no trace of bigmemory or Biobase in the travis file. You current devel version doesn't have a direct Biobase dependency (although NMF has it as suggests).

Despite that, travis failed prior to running R CMD check with:

$ Rscript -e 'deps <- devtools::dev_package_deps(dependencies = NA);devtools::install_deps(dependencies = TRUE);if (!all(deps$package %in% installed.packages())) { message("missing: ", paste(setdiff(deps$package, installed.packages()), collapse=", ")); q(status = 1, save = "no")}'
abind        (NA -> 1.4-5       ) [CRAN]
BH           (NA -> 1.66.0-1    ) [CRAN]
bigmemory    (NA -> 4.5.33      ) [CRAN]
bigmemory... (NA -> 0.1.3       ) [CRAN]
bindr        (NA -> 0.1.1       ) [CRAN]
bindrcpp     (NA -> 0.2.2       ) [CRAN]
broom        (NA -> 0.5.0       ) [CRAN]
covr         (NA -> 3.2.1       ) [CRAN]
CVST         (NA -> 0.2-2       ) [CRAN]
ddalpha      (NA -> 1.3.4       ) [CRAN]
DEoptimR     (NA -> 1.0-8       ) [CRAN]
dplyr        (NA -> 0.7.8       ) [CRAN]
DRR          (NA -> 0.0.3       ) [CRAN]
evaluate     (NA -> 0.12        ) [CRAN]
generics     (NA -> 0.0.1       ) [CRAN]
geometry     (NA -> 0.3-6       ) [CRAN]
gower        (NA -> 0.1.2       ) [CRAN]
highr        (NA -> 0.7         ) [CRAN]
htmltools    (NA -> 0.3.6       ) [CRAN]
igraph       (NA -> 1.2.2       ) [CRAN]
kernlab      (NA -> 0.9-27      ) [CRAN]
knitr        (NA -> 1.20        ) [CRAN]
lubridate    (NA -> 1.7.4       ) [CRAN]
magic        (NA -> 1.5-9       ) [CRAN]
markdown     (NA -> 0.8         ) [CRAN]
pkgconfig    (NA -> 2.0.2       ) [CRAN]
plogr        (NA -> 0.2.0       ) [CRAN]
pls          (NA -> 2.7-0       ) [CRAN]
praise       (NA -> 1.0.0       ) [CRAN]
purrr        (NA -> 0.2.5       ) [CRAN]
recipes      (NA -> 0.1.3       ) [CRAN]
rex          (NA -> 1.1.2       ) [CRAN]
rmarkdown    (NA -> 1.10        ) [CRAN]
robustbase   (NA -> 0.93-3      ) [CRAN]
sfsmisc      (NA -> 1.1-2       ) [CRAN]
testthat     (NA -> 2.0.1       ) [CRAN]
tidyr        (NA -> 0.8.2       ) [CRAN]
tidyselect   (NA -> 0.2.5       ) [CRAN]
timeDate     (NA -> 3043.102    ) [CRAN]
tinytex      (NA -> 0.9         ) [CRAN]
xfun         (NA -> 0.4         ) [CRAN]
yaml         (NA -> 2.2.0       ) [CRAN]
rsample      (NA -> 7dda4194a...) [GitHub]
dimRed       (NA -> 7c27038e7...) [GitHub]
Skipping 1 packages not available: Biobase
Installing 43 packages: abind, BH, bigmemory, bigmemory.sri, bindr, bindrcpp, Biobase, broom, covr, CVST, ddalpha, DEoptimR, dplyr, DRR, evaluate, generics, geometry, gower, highr, htmltools, igraph, kernlab, knitr, lubridate, magic, markdown, pkgconfig, plogr, pls, praise, purrr, recipes, rex, rmarkdown, robustbase, sfsmisc, testthat, tidyr, tidyselect, timeDate, tinytex, xfun, yaml
Installing packages into `/usr/local/lib/R/site-library`
(as `lib` is unspecified)
Error: (converted from warning) package `Biobase` is not available (for R version 3.5.1)
Execution halted

I can add it as a package that travis should install (and that will most likely work) but I'm not sure what that means for CRAN. One of the main issues here is the difference between official CRAN checks and what we have available to us.

Although its results are not very stable, can you try running it on r-hub (via devtools::check_rhub)?

on current develop I have moved NMF back to suggests and everything seems to work fine on my computer, on travis, and winbuilder (except oldrelease which gives an unrelated error), can you please check.

Your develop branch works for me (with neither Biobase or bigmemory installed).

I'd send an email to the CRAN folks and tell them the evidence that you have for this new version working and see if you can resubmit. For me, adding Biobase as an imports (instead of suggests) is the major issue. You would think that NMF having Biobase and bigmemory in its suggests would be fine but travis failed to install those too.

Sorry that this has been such a hassle. As a potential fallback, a different NMF package could be used (I think that we first looked at NNLM but my recollection is that it wasn't that great) or we could use reticulate to invoke the python method in sklearn. I think that you do that for a different method in dimRed IIRC.

[edit]

An expert within our group looked at this and commented that

I am basically 100% confident that both that the issue is dimRed not importing generics it is using and also that it is possible to do so conditionally without a hard dependency

[gdkrmr]

I will try to submit what is currently in the develop branch as 0.2.2 with an explanatory note. Current develop fails on win-builder oldrelease, I think due to some stringiissue, but there are more failures which I am not sure are caused by stringi.

I have already some python dependencies, namely tensorflow, keras, and umap-learn. There are already some possible traps with the virtual environments that are created by tensorflow::install_tensorflow/keras and umap-learn. I would like to avoid adding more python dependencies if possible, on the other hand these traps are already set.

Do you have any idea what changed with NMF? I did not work before and there were no new NMF releases. Also on my computer it works now with R-3.4.4 which is the same version I tried it with last time.

[topepo]

Do you have any idea what changed with NMF? I did not work before and there were no new NMF releases. Also on my computer it works now with R-3.4.4 which is the same version I tried it with last time.

No idea.

We can go with another implementation. A friend just sent me a pretty lightweight NMF implementation that just uses base R if you want to try that.

[gdkrmr]

How big is the difference in features and performance? The inverse is a trivial matrix multiplication, but for the forward calculation you have to solve a linear equation system without producing negative numbers.

[topepo]

It's pretty bare bones in terms of features. For the weights, they are set to zero if negative. Given how prevalent zeros are in the loading matrices, I think that it is pretty common.

nmf = function(x, k, maxit=10, tol=1e-2, u=x[, 1:k], v=x[1:k, ]) {
  j = 1
  eps = Inf
  pinv = function (x, eps=1e-12) {  # helper function
    i = x > eps
    x[i] = 1 / x[i]
    x[! i] = 0
    x
  }
  while(j <= maxit && eps > tol)
  {
    s = svd(v)
    u = tcrossprod(x, v) %*% s$u %*% (pinv(s$d)^2 * t(s$u))
    u[u < 0] = 0
    s = svd(u)
    v = s$v %*% (pinv(s$d)^2 * t(s$v)) %*% crossprod(u, x)
    v[v < 0] = 0
    j = j + 1
    eps = norm(x - u %*% v, "F")
  }
  list(u=u, v=v, eps=eps, iterations=j-1, tol=tol)
}

I would change the convergence criterion and a few other things (but would leave the core intact).

There's always NNLM too. That only has Rcpp dependencies.

[gdkrmr]

Is NNLM maintained? I don't have a lot of time for the rest of the year, I will try to simply submit dimRed with NMF in Suggests if this still fails badly we will have to think of something. I have never dug into implementations for nnmf, so I cannot really give an opinion about your code, maybe I will do it if I find some free time. I really would like to have a forward function.

[topepo]

Is NNLM maintained?

Not sure. The user hasn't been on GH much from what I can see (public repos, that is).

if this still fails badly we will have to think of something.

If that happens, can you send in a version without NMF? I've gotten emails in the last day about caret install issues (since it depends on recipes).

[gdkrmr]

What you mean without NMF? No non-negative matrix factorization or a non-NMF version of non-negative matrix factorization?

[topepo]

Sorry, I meant a version without the NMF package, even if that means no code for non-negative matrix factorization (if we have no good alternative).

[gdkrmr]

v0.2.2 is on its way to CRAN, let's see if it will work this time.

[topepo]

I had a few of our people with 1000x more expertise than mine take a look and that think that it should be fine.

[gdkrmr]

The interesting question to me is what changed, since we tried it the first time.

[gdkrmr]

The OSX builds are still failing. 1) I forgot to check for the pcaL1 package in the examples and 2) The tests fail without a useful error message.

[topepo]

Can you point me to the failures? Anything that we can do to help?

[gdkrmr]

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

The OSX examples fail, because I do not check for the presence of pcaL1, there is no useful information about the failing tests as far as I can see, maybe they fix themselves after fixing the example.

The main problem is that CRAN won't build OSX binaries, is it possible to install dimRed anyway on a mac without going through too much trouble?

[topepo]

The OSX examples fail, because I do not check for the presence of pcaL1, there is no useful information about the failing tests as far as I can see, maybe they fix themselves after fixing the example.

That's easy to fix with one of testthat's skip functions.

The main problem is that CRAN won't build OSX binaries, is it possible to install dimRed anyway on a mac without going through too much trouble?

I had a ton of trouble getting pcaL1 installed due to its external dependency. I couldn't find it on homebrew then someone pointed me to

brew tap coin-or-tools/coinor
brew install clp

It might help to make of note of this in the readme file or on that man page.

Where do things stand now? Any comments back from CRAN on this version?

[gdkrmr]

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

0.2.2 is on CRAN and working great, except for OSX, because I had to make some stuff conditional on the presence of the pcaL1 package, this should be fixed in current develop. Therefore dimRed for OSX on CRAN is still version 0.1.0, if that is a problem.

I have never had a Mac so you are probably better suited to describe this, could you please add this to the documentation of the PCA_L1 class or give me a paragraph that I can add.

We should also write the CRAN maintainers and ask them to install coinor on the OSX machines.

[topepo]

have never had a Mac so you are probably better suited to describe this, could you please add this to the documentation of the PCA_L1 class or give me a paragraph that I can add.

I'll put in a PR.

0.2.2 is on CRAN and working great

Ok. I thought that we were still waiting on that for approval. I've got a deluge for packages headed for CRAN then.

Thanks!

[gdkrmr]

So there is no hurry for fixing the osx fails?