TDbasedUFEadv

[tagtag]

Update the following URL to point to the GitHub repository of the package you wish to submit to Bioconductor

• Repository: https://github.com/tagtag/TDbasedUFEadv

Confirm the following by editing each check box to '[x]'

• [x] I understand that by submitting my package to Bioconductor, the package source and all review commentary are visible to the general public.

• [x] I have read the Bioconductor Package Submission instructions. My package is consistent with the Bioconductor Package Guidelines.

• [x] I understand Bioconductor Package Naming Policy and acknowledge Bioconductor may retain use of package name.

• [x] I understand that a minimum requirement for package acceptance is to pass R CMD check and R CMD BiocCheck with no ERROR or WARNINGS. Passing these checks does not result in automatic acceptance. The package will then undergo a formal review and recommendations for acceptance regarding other Bioconductor standards will be addressed.

• [x] My package addresses statistical or bioinformatic issues related to the analysis and comprehension of high throughput genomic data.

• [x] I am committed to the long-term maintenance of my package. This includes monitoring the support site for issues that users may have, subscribing to the bioc-devel mailing list to stay aware of developments in the Bioconductor community, responding promptly to requests for updates from the Core team in response to changes in R or underlying software.

• [x] I am familiar with the Bioconductor code of conduct and agree to abide by it.

I am familiar with the essential aspects of Bioconductor software management, including:

• [x] The 'devel' branch for new packages and features.
• [x] The stable 'release' branch, made available every six months, for bug fixes.
• [x] Bioconductor version control using Git (optionally via GitHub).

For questions/help about the submission process, including questions about the output of the automatic reports generated by the SPB (Single Package Builder), please use the #package-submission channel of our Community Slack. Follow the link on the home page of the Bioconductor website to sign up.

[bioc-issue-bot]

Hi @tagtag

Thanks for submitting your package. We are taking a quick look at it and you will hear back from us soon.

The DESCRIPTION file for this package is:

Package: TDbasedUFEadv
Type: Package
Title: TDbasedUFEadv
Version: 0.99.0
Authors@R: 
    person("Taguchi", "Y-h.", ,
    "tag@granular.com", role = c("aut", "cre"),
    comment = c(ORCID  = "0000-0003-0867-8986"))
Description: 
    This is a comprehensive package to perform
    Tensor decomposition based unsupervised feature extraction.
    It can perform unsupervised feature extraction.
    It uses tensor decompission.
    It is  applicable to gene expression, DNA methylation, and 
    histone modification etc.
    It can perform multiomics analysis.
    It is also applicable to single cell omics data sets.
biocViews: 
    GeneExpression, 
    FeatureExtraction, 
    MethylationArray,
    SingleCell    
License: GPL-3
Encoding: UTF-8
Imports: 
    TDbasedUFE,
    Biobase,
    RTCGA,
    RTCGA.rnaseq,
    RTCGA.clinical,
    utils,
    GenomicRanges,
    rTensor,
    BiocStyle,
    MOFAdata,
    methods,
    graphics,
    stats,
    RITAN,
    STRINGdb,
    enrichR
RoxygenNote: 7.2.3
Suggests: 
    knitr,
    rmarkdown,
    testthat (>= 3.0.0)
VignetteBuilder: knitr
Config/testthat/edition: 3

[vjcitn]

On initial testing I am seeing

--- re-building ‘Enrichment.Rmd’ using rmarkdown
Quitting from lines 41-68 (Enrichment.Rmd) 
Error: processing vignette 'Enrichment.Rmd' failed with diagnostics:
R: geometry does not contain image `/tmp/RtmplX2cjc/Rbuild5cdc763a79ea2/TDbasedUFEadv/vignettes/Enrichment_files/figure-html/unnamed-chunk-2-1.png' @ warning/attribute.c/GetImageBoundingBox/247

[vjcitn]

I don't know why I encountered that with R CMD check, but I will assume it will be remedied if it occurs on the build system. I noted many spelling errors in vignettes; perhaps you can use an automated spelling analyzer to deal with this. The QuickStart has we continue to type 1 and press enter unril we can see the nineth one as -- this approach to exploring data is outmoded. The package passes check so I will pass it to review, but I would suggest you have a look at a) curatedTCGAData as a way of compactly managing many TCGA tumors, and b) shiny as a way of managing user interactions with a large number of results. Developer mentoring may be available to discuss how a shiny app might help your users.

[tagtag]

@vjcitn Thank you very much for your comments. The error did not occur in our system. In the case we cannot correct it, I will ask you. I will check the spelling. I will consider the usage of curatedTCGAData as well as shiny.

[bioc-issue-bot]

A reviewer has been assigned to your package. Learn what to expect during the review process.

IMPORTANT: Please read this documentation for setting up remotes to push to git.bioconductor.org. It is required to push a version bump to git.bioconductor.org to trigger a new build.

Bioconductor utilized your github ssh-keys for git.bioconductor.org access. To manage keys and future access you may want to active your Bioconductor Git Credentials Account

[bioc-issue-bot]

Dear Package contributor,

This is the automated single package builder at bioconductor.org.

Your package has been built on Linux, Mac, and Windows.

On one or more platforms, the build results were: "ERROR, skipped". This may mean there is a problem with the package that you need to fix. Or it may mean that there is a problem with the build system itself.

Please see the build report for more details. This link will be active for 21 days.

Remember: if you submitted your package after July 7th, 2020, when making changes to your repository push to git@git.bioconductor.org:packages/TDbasedUFEadv to trigger a new build. A quick tutorial for setting up remotes and pushing to upstream can be found here.

[tagtag]

@lazappi Although @vjcitn advised me to use curatedTCGAData instead of RTCGA, I found that it is not suitable for us to employ curatedTCGAData. In our vignettes QuickStart, we used all TCGA cancer data set from RTCGA.rnaseq. If we try to do the same by curatedTCGAData, we need to perform all <- curatedTCGAData( "*", "RNASeq2Gene", version = "2.0.1", dry.run = FALSE ) and curatedTCGAData started to download data. Download did not finish even after one hour passed. In contrast to curatedTCGAData, RTCGA.rnaseq includes data within it, thus no need to download. Then I gave up the usage of curatedTCGAData. If you think that I am wrong, I am glad if you can advise me the correct way of using curatedTCUAData.

[tagtag]

@lazappi @vjcitn also advised me to use shiny instead of menu. However, I found that bioconductor can only accept shiny as a whole package, not a part of package. https://contributions.bioconductor.org/shiny.html TDbasedUFEadv cannot be shiny app as a whole, since only a part of package is interactive. Thus, the usage of shiny as a part of TDbasedUFE is impossible. If you think that I am wrong, I am glad if you can advise me the correct way of using shiny in TDbasedUFEadv.

[lazappi]

• I'm not familiar with the TCGA packages, can you explain the difference between {curatedTCGAData} and {RTCGA}?
• What do you mean by "can only accept shiny as a whole package"? I couldn't see a reference to that in the documentation you linked to and if fact I think it requires that a shiny app functions as a normal package with only the interactive part being included in the app.
• Please address the errors from the build system before I can review the package.

[vjcitn]

Let's leave curatedTCGAData to one side for now; @LiNk-NY may wish to comment at some point but it is not urgent. This comment in the linked element of contributors.bioconductor.org [Shiny apps](https://shiny.rstudio.com/) can be submitted to Bioconductor as software packages. seems misleading to me. Packages may include shiny apps but the apps are supposed to be testable functions. I will address this with the maintainers of the guidelines. I think it is overbroad wording.

[tagtag]

@vjcitn @lazappi Thanks for your valuable comments. Yes, I postpone the comments about curatedTCGA at the moment. As for Shiny, I am waiting for the feedback from you or maintainers to know if menu functions I implemented can be replaced with Shiny apps included in individual packages, not as an independent package that includes only Shiny apps. As for errors, I will check it but I was also asked to check spelling. After spell check I will also address build error (actually speaking, we do not have this errors in our side but I will try to fix it).

[tagtag]

@vjcitn @lazappi Thanks for your valuable comments. Yes, I postpone the comments about curatedTCGA at the moment. As for Shiny, I am waiting for the feedback from you or maintainers to know if menu faunctions can be replaced with Shiny apps included in individual packages, not as an independent package that includes only Shiny apps. As for errors, I will check it but I was also asked to check spelling. After spell check I will also adress build error (actually speaking, we do not have this errors in outr side but I will try to fix it).

[LiNk-NY]

all <- curatedTCGAData( "*", "RNASeq2Gene", version = "2.0.1", dry.run = FALSE ) and curatedTCGAData started to download data.

Hi Taguchi, @tagtag

I noticed that the assays argument (RNASeq2Gene) would return both RNASeq2Gene and RNASeq2GeneNorm. Was this the intention? Perhaps, but in either case, a sole RNASeq2Gene input should only return RNASeq2Gene type of assays. I have updated curatedTCGAData to work this way (see version 1.21.2). If you do intend to work with both type of assays, the input should be RNASeq2Gene*.

Note that curatedTCGAData software is lightweight and only downloads the data requested. If you are requesting two assay types from all cancer types, that would require the download of 69 assay files and 66 metadata files (which include colData and metadata) versus 33 assay files and 66 metadata files when requesting only RNASeq2Gene assays.

The download time would also depend on your connection speed relative to the hosting location.

[tagtag]

@LiNk-NY I know that my code download two assays, (thus in total 69 files), and they can be 33 files. However, even if 33 files are download, it took so long time (It is not lightweighted if we need to download as many as 33 files). I know that it depends upon connection speed, too, but I dislike to use something related to connection speed in my package, but something store data in local PC like RTCGA. I am glad if you can consider the situation here. Is it acceptable? > @vjcitn @lazappi

[LiNk-NY]

The typical use case for curatedTCGAData involves a single cancer type and is quite lightweight and integrative.

Is it acceptable?

If I may, I think the use of RTCGA.rnaseq is acceptable. I would suggest making it clear in the vignette that you are using old release TCGA data from 20151101 (based on the package version number and as shown on the website https://rtcga.github.io/RTCGA/).

[tagtag]

@LiNk-NY Thanks. I will mention about it in Vignettes. Since I have used RTCGA only for demonstration purpose in Vignettes, it does not matter that it is an old package.

[bioc-issue-bot]

Received a valid push on git.bioconductor.org; starting a build for commit id: 2092c836a10f48882c5127c68a74f741a249a2ec

[bioc-issue-bot]

Dear Package contributor,

This is the automated single package builder at bioconductor.org.

Your package has been built on Linux, Mac, and Windows.

On one or more platforms, the build results were: "WARNINGS, ERROR, skipped". This may mean there is a problem with the package that you need to fix. Or it may mean that there is a problem with the build system itself.

Please see the build report for more details. This link will be active for 21 days.

Remember: if you submitted your package after July 7th, 2020, when making changes to your repository push to git@git.bioconductor.org:packages/TDbasedUFEadv to trigger a new build. A quick tutorial for setting up remotes and pushing to upstream can be found here.

[bioc-issue-bot]

Received a valid push on git.bioconductor.org; starting a build for commit id: a886ac19242502cc91fb8de1b84a01d3399ac1a1

[bioc-issue-bot]

Dear Package contributor,

This is the automated single package builder at bioconductor.org.

Your package has been built on Linux, Mac, and Windows.

On one or more platforms, the build results were: "WARNINGS, ERROR, skipped". This may mean there is a problem with the package that you need to fix. Or it may mean that there is a problem with the build system itself.

Please see the build report for more details. This link will be active for 21 days.

Remember: if you submitted your package after July 7th, 2020, when making changes to your repository push to git@git.bioconductor.org:packages/TDbasedUFEadv to trigger a new build. A quick tutorial for setting up remotes and pushing to upstream can be found here.

[tagtag]

The build error caused seems to be due to system errors, not because of my package, since it says

Could not find executable pandoc-citeproc

This means that pandoc is missing in the system that tries to build. I will postpone the effort to address other issues until this problem is fixed.

[bioc-issue-bot]

Dear Package contributor,

This is the automated single package builder at bioconductor.org.

Your package has been built on Linux, Mac, and Windows.

On one or more platforms, the build results were: "WARNINGS". This may mean there is a problem with the package that you need to fix. Or it may mean that there is a problem with the build system itself.

Please see the build report for more details. This link will be active for 21 days.

Remember: if you submitted your package after July 7th, 2020, when making changes to your repository push to git@git.bioconductor.org:packages/TDbasedUFEadv to trigger a new build. A quick tutorial for setting up remotes and pushing to upstream can be found here.

[bioc-issue-bot]

Received a valid push on git.bioconductor.org; starting a build for commit id: 8bf7ddb2af86d9dcac63697e0259958adeb5495e

[bioc-issue-bot]

Dear Package contributor,

This is the automated single package builder at bioconductor.org.

Your package has been built on Linux, Mac, and Windows.

On one or more platforms, the build results were: "WARNINGS". This may mean there is a problem with the package that you need to fix. Or it may mean that there is a problem with the build system itself.

Please see the build report for more details. This link will be active for 21 days.

Remember: if you submitted your package after July 7th, 2020, when making changes to your repository push to git@git.bioconductor.org:packages/TDbasedUFEadv to trigger a new build. A quick tutorial for setting up remotes and pushing to upstream can be found here.

[tagtag]

@LiNk-NY Although I have asked about this warning on bioc-devel-ml, since I was advised to continue the discussion here, in this issue, I ask you the solution.

My query:

_I have gotten the following warning. "WARNING: R CMD check exceeded 10 min requirement" [History]Bioconductor Single Package Builder Does it mean that I need to fragment the package into smaller ones?_

Answer from bioc-devel-ml:

Please continue this conversation on the issue being reviewed.

In general, packages are expected to build and check in a reasonable amount of time. If you see this across all platform, there may be opportunities to improve your code and make it more efficient. If it is a single platforms we can evaluate on a case by case basis as one of the builders may be experiencing a heavy load that could affect this result.

My case seems to correspond to the case "it is a single platforms" since Check in UNIX seems to be OK

So, what is the next action that I can take? I am glad if you can advice me about it.

[lazappi]

I think that is a reasonable solution, but maybe you could also mention that {curatedTCGAData} can be used to get the more recent data if the user wants to.

For the Shiny question, I don't think there is any advice that says a package can't include a Shiny app along with other things so I think that should be fine. I haven't looked at exactly what you want to do with it though so we could discuss your concerns a bit more if you want.

[tagtag]

@lazappi Thanks for your valuable comments.

you could also mention that {curatedTCGAData} can be used to get the more recent data if the user wants to.

Yes, I did in updated vignettes.

we could discuss your concerns a bit more if you want.

Actually, it is not my concern. Although I have used menu() function, @vjcitn advised me that it is an old fashioned way and it is better to use Shiny. I used menu() function to let users to select one plot among multiple plots (the number of plots to be shown vary, thus fixed layout, e.g. 3 x 2, is not a good idea). I showed plots one by one, user is forced to select the best one. I offered the three choices, next, previous, select. Then users used next and previous to investigate plot and finally select one of them by select. Do you think that it is better to implement this function with Shiny? If the fixed layout, e.g., 2 x3 can be employed, Shiny is a good idea since it can allow users to select one of them at a glace (although 2x3 layout can be also employed with menu() if we can use mfrow=c(2,3) and accepd number as input for menu(). )

[lazappi]

The build time is most likely due to either the vignette or function example. I would see if you can make these a bit quicker, the simplest thing to try is probably reducing the size of any example datasets used.

I'm not very familiar with using menus but I am happy to take the advice from @vjcitn. Please look into whether you can use Shiny instead.

[tagtag]

@LiNk-NY As for build time, UNIX has no problem and only mac has. In that case, I was informed that "we can evaluate on a case by case basis as one of the builders may be experiencing a heavy load that could affect this result." I am glad if you can tell me who can do this.

As for Shiny, I am not sure if Shiny is fitted to my purpose, since the number of plots that I have to show the user and user must select one among is unlimited. In that case, I think that Shiny is not fitted. Shiny interface is very fitted only to select something among choices that can be shown in a single page. What is your ompinion?

[LiNk-NY]

@tagtag It would be good to know, what is taking most of the nearly 15 minutes on the Mac builder. If it were closer to 10 minutes, it would be okay. Note that the examples take less than 2 minutes:

Examples with CPU (user + system) or elapsed time > 5s
                         user system elapsed
selectFeatureTransRect 55.422  0.569  65.380
prepareCondTCGA        12.198  0.895  15.169

Perhaps it is code in the vignette, unit tests, or code in the package?

In general, it would be advisable to reduce the time the package takes to check by using smaller exemplar datasets as Luke @lazappi mentioned.

[tagtag]

@LiNk-NY Possibly, it is in vignettes. Since it is difficult to reduce time spent by vignette because we need to show the user the validity of the method that requires substantial cpu time, is it acceptable not to execute R code in vignettes on build, but just include the output from R code? I think that it is possible if we can replace executable chunks with not executable ones.

[LiNk-NY]

The vignette should demonstrate the functionality of the package with minimal examples. It is not meant to showcase a cpu intensive validation. For the latter purpose, please create a workflow package and/or move the code to a separate repository (e.g., manuscript preparation repository).

is it acceptable not to execute R code in vignettes on build, but just include the output from R code?

It is not acceptable because code in the vignette should be functional and tested; otherwise, it can go stale.

[tagtag]

@LiNk-NY What is "manuscript preparation repository"? I have never heard about it in Bioconductor.

[LiNk-NY]

@tagtag It seems like the files that you have in the vignette are part of an academic publication. Is that the case? If so, the figures and the code that generates the figures should go in a separate personal repository on GitHub. This is what I mean by "manuscript preparation repository."

[tagtag]

@LiNk-NY No, it doesn't. It is original research I have developed for this vignettes. Thus, if we reduce the size of data, none can be confident of my method. Since UNIX can process R CMD check within limited time, is it possible for you to tell me how to pass it in Mac, too? PS I do not have any Mac box, thus I cannot check it by my self.

[tagtag]

@LiNk-NY I have found that too long time for R CMD check in Mac is universal, not only for mine. https://github.com/elsasserlab/labcode/issues/63 I believe that it is unrealistic to ask developer to consider all platforms some of which have their own problem. How about your opinion?

[lazappi]

I am going to agree with what @LiNk-NY said

• The purpose of a vignette is to demonstrate how to use the package, not to necessarily show how effective a method is (that can be done in a separate paper/repository you can link to). There are plenty of packages that use small, sometimes unrealistic, datasets in their vignettes.
• One of the reasons Bioconductor is trusted is that packages are (mostly) tested on multiple platforms. It is likely you will have users who use MacOS so it's in your interest to try and make the performance similar to what you see on Unix.
• For both of these reasons it is important that code is run on the build system so we don't allow pre-computed results in vignettes (or at least not only that, it may be possible to run the code on an example dataset and then load the full results to use in later steps)
• As this is just a warning I think we can continue with the review (if you have completed the other changes we already discuss) but I think it is worth trying to address it

[tagtag]

@LiNk-NY @lazappi I will take the action that "it may be possible to run the code on an example dataset and then load the full results to use in later steps". Thanks.

[bioc-issue-bot]

Received a valid push on git.bioconductor.org; starting a build for commit id: ad8c63fb4814f15a9252bad5e0b4474e14134813

[bioc-issue-bot]

Dear Package contributor,

This is the automated single package builder at bioconductor.org.

Your package has been built on Linux, Mac, and Windows.

On one or more platforms, the build results were: "WARNINGS". This may mean there is a problem with the package that you need to fix. Or it may mean that there is a problem with the build system itself.

Please see the build report for more details. This link will be active for 21 days.

Remember: if you submitted your package after July 7th, 2020, when making changes to your repository push to git@git.bioconductor.org:packages/TDbasedUFEadv to trigger a new build. A quick tutorial for setting up remotes and pushing to upstream can be found here.

[bioc-issue-bot]

Received a valid push on git.bioconductor.org; starting a build for commit id: 6610459d0ba76294c42b70de076e08164711c693

[bioc-issue-bot]

Dear Package contributor,

This is the automated single package builder at bioconductor.org.

Your package has been built on Linux, Mac, and Windows.

On one or more platforms, the build results were: "WARNINGS". This may mean there is a problem with the package that you need to fix. Or it may mean that there is a problem with the build system itself.

Please see the build report for more details. This link will be active for 21 days.

Remember: if you submitted your package after July 7th, 2020, when making changes to your repository push to git@git.bioconductor.org:packages/TDbasedUFEadv to trigger a new build. A quick tutorial for setting up remotes and pushing to upstream can be found here.

[tagtag]

@lazappi Now cpu time for R CMD check for mac was shorten so as to be within ten minutes. The remaining warning did not come from my side but from RITAN. Warning: replacing previous import 'ensembldb::keys' by 'hash::keys' when loading 'RITAN' Warning: replacing previous import 'ensembldb::filter' by 'stats::filter' when loading 'RITAN' http://bioconductor.org/checkResults/devel/bioc-LATEST/RITAN/nebbiolo1-checksrc.html which I am not responsible for. I am glad if you can advise me how to pass check under this circumstances. I have no way to correct this waring, since it came from RITAN. Or do I need to replace RITAN with something not associated with Warnings?

[bioc-issue-bot]

Received a valid push on git.bioconductor.org; starting a build for commit id: 384e1fce26f51d079571d1593267b1bbaa3a74b5

[bioc-issue-bot]

Dear Package contributor,

This is the automated single package builder at bioconductor.org.

Your package has been built on Linux, Mac, and Windows.

Congratulations! The package built without errors or warnings on all platforms.

Please see the build report for more details. This link will be active for 21 days.

Remember: if you submitted your package after July 7th, 2020, when making changes to your repository push to git@git.bioconductor.org:packages/TDbasedUFEadv to trigger a new build. A quick tutorial for setting up remotes and pushing to upstream can be found here.

[tagtag]

@lazappi I have removed RITAN from TDbasedUFEadv to avoid warnings. If you can tell me how to include RITAN that has warnings, I am happy to recover RITAN. If not, please review the present version, 0.99.6, and let me know your opinion.

[lazappi]

Hi @tagtag

Thanks for submitting TDbasedUFEadv :tada:! Below is my review of your package. Please reply here if anything is unclear or needs any further explanation.

What next?

Please address the comments as best as you can. When you are ready for me to check the package again please reply to let me know with a summary of changes you have made or any other responses. You can use the "Quote reply" option in the ... menu on this comment to reply directly to my points below.

Luke

Review

Key: :rotating_light: Required :warning: Recommended :green_circle: Optional :question: Question

General comments

• [ ] :question: The functions in the package seem to mostly be small helper functions that build on the functionality in {TDbasedUFE}. Have you considered adding them to the existing package rather than creating a new one?

DESCRIPTION file

• [ ] :warning: It may be appropriate to add "Software" to the biocViews field
• [ ] :green_circle: It is recommended to add a BugReports field, this is usually a link to the GitHub issues page or the Bioconductor support site
• [ ] :green_circle: It is recommended to add a URL field, this is usually a link to the GitHub repository

NAMESPACE file

• [ ] :rotating_light: PrepareSummarizedExperimentTensorRect should start with a lower case letter to match the other functions
• [ ] :rotating_light: Please use selective imports using importFrom instead of importing all with import

The NEWS file

• [ ] :warning: Please keep the NEWS file up to date with the latest changes

Package data

• [ ] :rotating_light: The data in inst/extdata/ should be documented in inst/script

Documentation

• [ ] :green_circle: There were quite a lot of typos in different places, the {spelling} package can help with finding these

README

• [ ] :rotating_light: The README looks incomplete, please update to fill in the missing content
• [ ] :warning: It doesn't look as though you are using any RMarkdown functionality, if so it will be simpler to use a plain README.md file instead of README.Rmd

Vignette

• [ ] :rotating_light: Please expand the introduction in the main vignette to describe the package in more detail. This should include the motivation for including the package in Bioconductor and comparisions to any similar packages (if applicable).
• [ ] :warning: It was not clear to me which order to look at the vignettes. I expected to start with TDbasedUFEadv.Rmd but that only convered technical detail, not any information about how to use the package. I suggest renaming/reorganising the vignettes to make this clearer.
• [ ] :warning: It also wasn't clear to me what the difference was between Quickstart.Rmd and Quickstart2.Rmd. I would suggest that this can be combined.
• [ ] :rotating_light: Whatever you decide to do I suggest using a more specific file name than "QuickStart.Rmd", sometimes it causes issues if different packages have vignettes with the same name
• [ ] :rotating_light: The main vignette should have an installation section that includes the Bioconductor installation instructions. These chunk should not be evaluated.
• [ ] :warning: There are lots of images in the vignettes directory, are all of these required or can some be produced by the vignette (I think this is related to the point about interactivity below)?
• [ ] :warning: I don't think you need to show all the menu items, I think it would be enough to mention there is an interactive option and maybe show one or two screenshots
• [ ] :warning: Please don't use fig.keep="none" if it can be avoided, in general the vignette should show the same output as the user would see if they ran the code themselves
• [ ] :green_circle: Usually it is better to use library(package) rather than require(package). I also find it easier to follow the code if the library calls are in a separate chunk at the start.

Man pages

• [ ] :rotating_light: You have included the word "Title" in the function documentation title which is then rendered in the final help page, either use @title TEXT or just TEXT on the first line
• [ ] :green_circle: Some of the variables in the examples are not very descriptive (e.g. dummy) which makes them a bit hard to understand

Unit tests

• [ ] :rotating_light: Please add unit tests for all exported functions. There is some code in the tests file currently by no actual expectation checks

Code

R

• [ ] :rotating_light: Please use named indicies instead of numeric indices where possible
• [ ] :warning: I found the SummarizedExperimentTensorRect class a bit unclear in a few ways
  • [ ] Given the name I expected it to inherit from SummarizedExperiment but that is not the case, I would suggest using a more descriptive name
  • [ ] It doesn't seem to be used by the user, how necessary is it to create a class rather than just using a list?
  • [ ] It is defined in a file called init.R which is not clear, usually this file is called something like AllClasses.R or the name of the class
• [ ] :warning: Please consider using more descriptive argument names, some of them (e.g. "k", "j", "LIST", "L") do not clearly describe what they are used for
• [ ] :warning: Consider adding checks for whether valid inputs are provided to function arguments
• [ ] :warning: I think some of the for loops could maybe be replaced with other iteration methods, e.g. vapply or lapply
• [ ] :warning: Generally functions should not output plots as side effects, generally it is better to have separate analysis and plotting functions
• [ ] :warning: It may be better to separate interactive functions for the non-interactive versions (or change how the options work), I found it a bit surprising that interactive was the default mode. Maybe one function could produce a plot that the user uses to select a parameter which they then pass to another function?
• [ ] :green_circle: This is mostly personal preference but I found your code quite hard to read because of the lack of indenting and whitespace. You may want to look at the tidyverse style guide or the styler package.

Shiny apps

• [ ] :question: I thought the plan was to replace the menus with a Shiny app, is this still the case?

[tagtag]

@LiNk-NY Thank you very much for your detailed comments and efforts.

General comments

• [ ] ❓ The functions in the package seem to mostly be small helper functions that build on the functionality in {TDbasedUFE}. Have you considered adding them to the existing package rather than creating a new one?

I can add them to existing package instead of generating new package. In that case, they are not reviewed and are distributed without reviews. Do you think that it is better to add them to existing package than generating new package?

[tagtag]

@LiNk-NY I am glad, if you can let me know about your opinions in the following.

• [ ] ⚠️ There are lots of images in the vignettes directory, are all of these required or can some be produced by the vignette (I think this is related to the point about interactivity below)?

Yes, it is. Since interactive mode is not allowed to execute in installation, it is impossible for vignettes to generate figures during installation.

• [ ] ⚠️ I don't think you need to show all the menu items, I think it would be enough to mention there is an interactive option and maybe show one or two screenshots

I do not think so. Batch mode will be never used by users, since batch is dummy to pass installation. Batch mode is empty.

• [ ] ⚠️ Please don't use fig.keep="none" if it can be avoided, in general the vignette should show the same output as the user would see if they ran the code themselves

As mentioned in the above, since interactive mode is not allowed, it is impossible for vignettes to generate figures during interactive mode.

• [ ] ⚠️ I think some of the for loops could maybe be replaced with other iteration methods, e.g. vapply or lapply

I have tried to avoid to use "for" as much as possible. Present "for" cannot be removed within my ability unless some one can shoe me how to replace them with "vapply" or "lapply" specifically.

• [ ] ⚠️ Generally functions should not output plots as side effects, generally it is better to have separate analysis and plotting functions

Since it is required to function as interactive mode, it is impossible to supress plot during function

• [ ] ⚠️ It may be better to separate interactive functions for the non-interactive versions (or change how the options work), I found it a bit surprising that interactive was the default mode. Maybe one function could produce a plot that the user uses to select a parameter which they then pass to another function?

As mentioned in the above, batch mode is empty. It does not do anything. Thus it is impossible for batch to be separate one.

Shiny apps

• [ ] ❓ I thought the plan was to replace the menus with a Shiny app, is this still the case?

Is it possible for you to check is Shiny is better than menu in this implementation? In my menu, figures are shown one by one with interaction with users. I do not think that Shiny is suitable for this purpose, although I agree with that menu is an old fashioned interface.

[lazappi]

@LiNk-NY Thank you very much for your detailed comments and efforts.

General comments

• [ ] ❓ The functions in the package seem to mostly be small helper functions that build on the functionality in {TDbasedUFE}. Have you considered adding them to the existing package rather than creating a new one?

I can add them to existing package instead of generating new package. In that case, they are not reviewed and are distributed without reviews. Do you think that it is better to add them to existing package than generating new package?

In the end, this is up to you as the developer who has to maintain the packages but in general it is ok to add functionality to existing packages (unless someone from the core wants to correct me). There are some cases where I think it would be better to make a new package: if it exists a package maintained by somebody else, if there are significant dependencies that you don't want to add to the main package, if for some reason it makes maintenance easier. I'm not sure any of those apply in this case though.

• [ ] ⚠️ There are lots of images in the vignettes directory, are all of these required or can some be produced by the vignette (I think this is related to the point about interactivity below)?

Yes, it is. Since interactive mode is not allowed to execute in installation, it is impossible for vignettes to generate figures during installation.

• [ ] ⚠️ I don't think you need to show all the menu items, I think it would be enough to mention there is an interactive option and maybe show one or two screenshots

I do not think so. Batch mode will be never used by users, since batch is dummy to pass installation. Batch mode is empty.

• [ ] ⚠️ Please don't use fig.keep="none" if it can be avoided, in general the vignette should show the same output as the user would see if they ran the code themselves

As mentioned in the above, since interactive mode is not allowed, it is impossible for vignettes to generate figures during interactive mode.

• [ ] ⚠️ I think some of the for loops could maybe be replaced with other iteration methods, e.g. vapply or lapply

I have tried to avoid to use "for" as much as possible. Present "for" cannot be removed within my ability unless some one can shoe me how to replace them with "vapply" or "lapply" specifically.

• [ ] ⚠️ Generally functions should not output plots as side effects, generally it is better to have separate analysis and plotting functions

Since it is required to function as interactive mode, it is impossible to supress plot during function

• [ ] ⚠️ It may be better to separate interactive functions for the non-interactive versions (or change how the options work), I found it a bit surprising that interactive was the default mode. Maybe one function could produce a plot that the user uses to select a parameter which they then pass to another function?

As mentioned in the above, batch mode is empty. It does not do anything. Thus it is impossible for batch to be separate one.

Shiny apps

• [ ] ❓ I thought the plan was to replace the menus with a Shiny app, is this still the case?

Is it possible for you to check is Shiny is better than menu in this implementation? In my menu, figures are shown one by one with interaction with users. I do not think that Shiny is suitable for this purpose, although I agree with that menu is an old fashioned interface.

I had not realised the batch mode is not functional and only there to pass the tests. This is something I think we want to avoid. It could be very confusing to the user and means the functions are not tested properly. I am beginning to think that Shiny is the best option in this case. That would give a nicer interface to the user than the menus and would make it easier to separate the processing code and the interface so that they can be checked properly.