#Weka jar with spegasos code#

Such a development methodology is however not mentioned in the paper, and it can be confusing to readers that won't know if BioWorkbench is just something you did (and we can learn from it and play with your demo), something we can repurpose (changing workflows, etc), or something general that can be reused (it can consume any workflow). If I am to create my own BioWorkbench that does a slightly different bioinformatics workflow I would need to make my own Dockerfile with my particular dependencies, create a brand new Swift script using the same patterns, build a new Docker image and test it inside the Docker container (or use vim inside the container to temporarily fix something). the provided Docker container captures 3 specific workflows and the Dockerfile is similarly specialized to add their dependencies.ДЄs such I think you can say you are providing a Methodology rather than a Framework. In the way this is described, BioWorkbench is not a framework for writing any scientific workflow, but a framework for capturing a particular workflow, e.g. While the Docker container containing the Workflow script is great for reproducibility (as I partially verified under Validity), it seems hard for workflow development. * Some grammar and phrasing suggestions Experimental design * Shiny library vs HPFS-Prof vs new 'workbench' code? * How are required tool binaries installed on compute nodes? * Described usage is not 'HPC' -> use 'HTC' I have attached some Detailed Comments line by line.

#Weka jar with spegasos code#

I think the code citations should be moved to References instead of footnotes (they are now first class citable), but I understand if the GitHub hyperlinks should remain as footnotes so that the PeerJ typesetters can add them as inline hyperlinks. The text is well-written and has a good structure.