-
Notifications
You must be signed in to change notification settings - Fork 80
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
Best way to document additional XCMS object processing steps in the ProcessHistory slot? #735
Comments
Update: I no longer like the list option I've described above because then printing the object throws an error when there's no |
Hi! well, indeed it would make sense to open this up. Originally, this was only used internally to document/log the xcms processing steps. so, the There is also an extension to the For both classes, there is a constructor function ( Up to now it was only me using these classes - but I'm OK to opening up and export all of it. Is there something you would need/like (e.g. also a new data processing type)? |
Yep! I think I've got a pretty clear sense of how to interact with the objects, I just can't embed it into a package of my own because the functions aren't exported. I guess the question is also a more general one - the idea behind the ProcessHistory is to make the XCMS objects more reproducible by documenting the steps involved. I don't have a parameter that's being supplied, however. The goal is to make peak quality detection interactive so all that would be documented are the features removed for being low-quality. Does this mesh with the philosophy behind the ProcessHistory? I agree that it's rare to see it used for debugging or reproducibility purposes because the XCMS object is so rarely stored somewhere instead of just the raw code / data files. I like the idea behind it and want to support it, but if it's going to be a pain and nobody else uses it then probably best to spend time elsewhere. The code I'd like to include is below: ph <- xcms:::ProcessHistory(date. = date(),
type. = "Low-quality feature removal via squallms",
fileIndex = 1:length(fileNames(xcms_filled)))
xph <- xcms:::XProcessHistory(param = NULL, date. = date(),
type. = "Unknown",
fileIndex = 1:length(fileNames(xcms_filled)),
msLevel = 1)
xcms:::addProcessHistory(xcms_filled, ph) %>%
processHistory() As you note, the data processing type isn't currently supported so an error's thrown upon attempting to define the
I'm not sure how much of a hassle this is to add. Looks like there might need to be specific |
Hi again,
I'm writing a package that extends the default XCMS functionality with the option to return an XCMSnExp (and soon, hopefully, an XcmsExperiment object!) where low-quality features have been removed. I'd like to document this processing step in the history, but can't figure out a good way to implement it from my side alone because it looks like the
addProcessHistory
function isn't exported, along with the necessaryProcessHistory()
andXProcessHistory()
class constructors. It also looks like the processing type is restricted to a small set of possible "types", none of which my addition fits into nicely. Was this an intentional design decision or are you open to expanding this class?Right now I'm adding my processing step as a list with components meant to mimic the layout of the existing XProcessHistory objects but it would be great to do this "officially".
The text was updated successfully, but these errors were encountered: