-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New plotting functions and various improvements. #110
Conversation
More chances to come, will notify you when PR is ready for review. Thanks, |
use_augmented_maf = TRUE){ | ||
use_augmented_maf = TRUE, | ||
add_qc_metric = FALSE, | ||
seq_type = "genome"){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You added seq_type but didn't modify the place where functions are called that would require this parameter to make it useful, e.g. the call to assign_cn_to_ssm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This parameter was added to satisfy the call of collate_qc_results
. But I should also update the call of assign_cn_to_ssm
to use the same seq_type
. Thanks!
R/viz.R
Outdated
as.data.frame() | ||
#get gambl metadata (if not supplied) | ||
if(missing(metadata)){ | ||
this_meta = get_gambl_metadata() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will default to genome. You must past the seq_type along (seq_type_filter=seq_type). EVERY line that calls get_gambl_metadata MUST have this explicit and passed from the calling function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, thanks for your comment. All metadata functions used in these plotting functions will be updated to call seq_type_filter
.
arrange(sample_id) %>% | ||
as.data.frame() | ||
#filter metadata on selected cohort (if filter_cohort is called) | ||
if(missing(these_samples)){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will not work as expected if someone supplies BOTH filter_cohort AND filter_pathology, will it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it will not. The way I designed this function was so that the user can define one or the other. But I can see how it could be useful to further subset your data based on both conditions. I will address this.
}else if(!missing(filter_pathology)){ | ||
these_samples = dplyr::filter(this_meta, pathology == filter_pathology) %>% | ||
dplyr::select(sample_id) %>% | ||
as.data.frame() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This really should not be if/else it should just be individual if for any filter. I also notice you switched between if(!missing) and if(!not.null) and only one of those is likely to work
these_samples = dplyr::filter(this_meta, pathology == filter_pathology) %>% | ||
dplyr::select(sample_id) %>% | ||
as.data.frame() | ||
if(missing(these_samples)){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same issue as above. Is the idea here that someone will only ever be expected to filter using one or the other but never combine them? If so, then you will need to check that they never provide more than one filter and throw an error if they do
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, see my response to your previous comment. It's the same for all these functions. I think it's best to have the function filter on both if both parameters are used.
R/viz.R
Outdated
|
||
#get gambl metadata (if not supplied) | ||
if(missing(metadata)){ | ||
this_meta = get_gambl_metadata() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same issue I raised previously. NEVER call this function in another function without passing it seq_type_filter from the calling function
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted, the full collection of these fancy QC plots needs to be updated in this regard.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some major issues here that have me worried you don't fully understand some of the nuances of how get_gambl_metadata works within functions.
Thanks for your comments Ryan. I completely understand the importance of the issues you raised and also that it is important to call get_gambl_metadata with the correct parameters. I am continuously making updates to these functions over the last couple of days and as the comment on this PR states, It is not 100% for review yet. All good comments though, I will address these issues in an upcoming commit. Please do not worry. |
…s, (3)hot-fixes, parameter updates, updating if statements etc.
… and other small fixes
Pull Request Checklists
Important: When opening a pull request, keep only the applicable checklist and delete all other sections.
Checklist for all PRs
Required
I tested the new code for my use case (please provide a reproducible example of how you tested the new functionality)
I ensured all dplyr functions that commonly conflict with other packages are fully qualified.
This can be checked and addressed by running
check_functions.pl
and responding to the prompts. Test your code after you do this.devtools::document()
) and addedNAMESPACE
and all other modified files in the root directory and underman
.Optional but preferred with PRs
Checklist for New Functions
Required
I documented my function using ROxygen style.)
All parameters for the function are described in the documentation and the function has a decriptive title.
Example:
import
statment.Example:
Checklist for changes to existing code
I added/removed arguments to a function and updated documentation for all changed/new arguments
I tested the new code for compatability with existing functionality in the Master branch (please provide a reprex of how you tested the original functionality)