Closed whedon closed 6 years ago
Hello human, I'm @whedon. I'm here to help you with some common editorial tasks. @jedbrown it looks like you're currently assigned as the editor for this paper :tada:
For a list of things I can do to help you, just type:
@whedon commands
Attempting PDF compilation. Reticulating splines etc...
👋 @jedbrown - the submitting author suggested you as the handling editor.
:wave: @genomematt @ctb @afrubin Would any of you be available to review this submission?
@jedbrown I'm happy to review it.
Dear @afrubin and @jedbrown Thank you for considering my manuscript. However, after a first look at the automatically generated pdf article proof, it seems that the file paper.bib was incorrectly formatted. I have therefore edited both files paper.md and paper.bib accordingly. They are now available from the GitLab repository of REQ. Finally, please note that the Markdown code O(n5) is incorrectly interpreted into the pdf article proof, and I really don't know how to correctly edit this mathematical notation. Yours sincerely, -- Alexis Criscuolo -- https://tinyurl.com/0-GIPhy-0
@whedon commands
Here are some things you can ask me to do:
# List Whedon's capabilities
@whedon commands
# List of editor GitHub usernames
@whedon list editors
# List of reviewers together with programming language preferences and domain expertise
@whedon list reviewers
🚧 🚧 🚧 Experimental Whedon features 🚧 🚧 🚧
# Compile the paper
@whedon generate pdf
@whedon generate pdf
Attempting PDF compilation. Reticulating splines etc...
@whedon generate pdf
Attempting PDF compilation. Reticulating splines etc...
@alex2cris You would use LaTeX-style math mode $O(n^5)$
.
I am concerned in looking at the repository that this might be a "utility package" in the sense of https://joss.readthedocs.io/en/latest/submitting.html#submission-requirements. It is about 100 lines of code in very dense format (225 LoC in standard formatting) and most of that is input and basic string processing -- the actual meat of the algorithm is very short. (The problem solved here is far from my research area.)
I also note that the Makefile is hard-wired to gcj
(unmaintained and no longer part of the GNU Compiler Collection) so users have to manually run the commands to create a JAR, and that there are no automated tests.
@jedbrown
REQ was purposely developed to provide the scientific community with a practical bioinformatics tool for estimating direct branch supports of distance-based phylogenetic trees. Further details may be found in paper.md
. To this respect, I assume that this program meets some of the JOSS submission requirements, e.g. a contribution that makes addressing research challenges significantly better (e.g., faster, easier, simpler).
The program REQ proceeds as follow. After reading input files (e.g. lines 85-100) and preprocessing data (e.g. lines 102-113), computing the rates of elementary quartets (REQ) is performed by the remaining lines of code (e.g. from line 115). Of note, the input phylogenetic tree is in NEWICK format (i.e. tree representation based on nested parentheses). Therefore, these remaining lines make full use of such a String representation (see e.g. code comments at lines 135-138) with the help of the four static methods cop, ccp, aop and apc (e.g. lines 164-186), instead of building a tree data structure (which would involve more lines of code and would require more RAM). This artful implementation thus allows REQ value at every branch of a phylogenetic tree to be computed with a few dozens lines of code.
The file README.md
describes two clear ways of compiling the Java source code of REQ. The standard way is to execute four command lines to create an executable JAR file. The alternative is to use Makefile
to build a binary with the GNU compiler gcj. Although gcj is unmaintained, I provided this alternative because some people may prefer using binaries in the place of executable JAR files. Moreover, gcj compilation is provided via a Makefile
in order to point out that this way will lead to a binary. Should it be a better option, I could merge these two compiling processes into a unique Makefile.
As you noticed, in the current version, no automated tests are provided. My view was that those were not so crucial in the sense that the piece of code is quite short. Moreover, the program REQ was used a large number of times by different collaborators with no apparent error. However, based on your feedback, I completed the directory example with the expected output file tree.req.t
associated to the two example files matrix.d
and tree.t
, as well as the output of the verbose mode (see the Example section inside README.md
).
Finally, following your comments, I replaced the Markdown code by the appropriate LaTeX-style math mode into the file paper.md
.
@whedon generate pdf
Attempting PDF compilation. Reticulating splines etc...
Hi @alex2cris, thanks for your submission. Unfortunately the editorial board has decided that this submission falls under the "minor utility" designation and is thus not appropriate for JOSS.
Minor, 'utility' packages, including 'thin' API clients are not acceptable
https://joss.readthedocs.io/en/latest/submitting.html#submission-requirements
Submitting author: @alex2cris (alexis criscuolo) Repository: https://gitlab.pasteur.fr/GIPhy/REQ Version: v1.2.180713ac Editor: @jedbrown Reviewer: Pending
Author instructions
Thanks for submitting your paper to JOSS @alex2cris. The JOSS editor (shown at the top of this issue) will work with you on this issue to find a reviewer for your submission before creating the main review issue.
@alex2cris if you have any suggestions for potential reviewers then please mention them here in this thread. In addition, this list of people have already agreed to review for JOSS and may be suitable for this submission.
Editor instructions
The JOSS submission bot @whedon is here to help you find and assign reviewers and start the main review. To find out what @whedon can do for you type: