Skip to content
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

Bug in regexp for parsing expressions #90

Open
ghost opened this issue Apr 9, 2020 · 0 comments
Open

Bug in regexp for parsing expressions #90

ghost opened this issue Apr 9, 2020 · 0 comments
Labels
bug Something isn't working

Comments

@ghost
Copy link

ghost commented Apr 9, 2020

The following expression retrieves a wrong termination for the first parameter reference. It is confused by the parens in the comment.

          bgzip -c $(inputs.vcf.path) > sv.vcf.gz
          tabix sv.vcf.gz

          # This code either subsets our genome (for testing) or passes the
          # whole genome          
          ${
            // Subset the genome
            if(inputs.region) {
              return "samtools faidx " + inputs.reference.path + " " +
              inputs.region;
            } 
            // Pass the whole genome
            else {
              return "cat " + inputs.reference.path;
            }
          } | bcftools consensus sv.vcf.gz -o newgenome.fa 

          ./art_bin_MountRainier/art_illumina \
            -mp \
            -nf 5 \
            -sp \
            -rs $(inputs.seed) \
            -ss $(inputs.sequencer) \
            -i newgenome.fa \
            -l $(inputs.read_len) \
            -m $(inputs.fragment_len) \
            -s $(inputs.fragment_std) \
            -f $(inputs.coverage) \
            -d $(inputs.read_prefix) \
            -o paired_end_reads

Parameter references can be constrained by a newline. It is likely the regexp will be fooled by a similar pattern in ${}. The only foolproof way of handling this is to count open and close parens and know to discard comments. This is likely more work than is worth and we will accept that our expression extraction will have some unsolved corner cases.

@ghost ghost added the bug Something isn't working label Apr 9, 2020
@ghost ghost added this to the 2020.03.31 milestone Apr 9, 2020
@ghost ghost self-assigned this Apr 9, 2020
@ghost ghost modified the milestones: 2020.03.31, 2020.06.30 May 4, 2020
@ghost ghost modified the milestones: 2020.06.30, No scheduled deadline Oct 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

0 participants