diff --git a/design-patterns/branch-and-merge/index.md b/design-patterns/branch-and-merge/index.md index 268a37d..e908d02 100644 --- a/design-patterns/branch-and-merge/index.md +++ b/design-patterns/branch-and-merge/index.md @@ -34,7 +34,7 @@ workflow run { # Run `stepD`, connecting the `in1` input to `stepB`'s `out` output # and the `in2` input to `stepC`'s `out` output. - call stepC { input: in1 = stepB.out, in2 = stepC.out } + call stepD { input: in1 = stepB.out, in2 = stepC.out } } ``` @@ -143,7 +143,7 @@ workflow run { # (b) The merge happens here. call merge_vcfs { input: snp_vcf = filter_snps.filtered_vcf, - indel_vcf = filter_snps.filtered_vcf, + indel_vcf = filter_indels.filtered_vcf, } output { diff --git a/design-patterns/conditional-statement/index.md b/design-patterns/conditional-statement/index.md index 1417022..af57545 100644 --- a/design-patterns/conditional-statement/index.md +++ b/design-patterns/conditional-statement/index.md @@ -4,7 +4,7 @@ It is often desirable to only execute some section of a computation graph only i particular condition holds. This could be as simple as a user input to the workflow indicating the "mode A" should be run instead of "mode B", whether to scatter and gather tasks rather than running a single multi-threaded task, or enabling an entire analysis -based on if some analytical check passes a QC threshold. In these cases, you'll want to +based on whether some analytical check passes a QC threshold. In these cases, you'll want to reach for **conditional statements** (also known as `if`/`else` statements). ![A diagram showing three tasks: `stepA`, `stepB`, and `stepC`. `stepA` is always diff --git a/getting-started/quickstart.md b/getting-started/quickstart.md index 9328dcf..6717b8a 100644 --- a/getting-started/quickstart.md +++ b/getting-started/quickstart.md @@ -116,7 +116,7 @@ the output of the above workflow would be the following. "Hello, world!", "Hallo, world!", "Hej, world!", - // "Ahoy, world!" is included is `is_pirate` is set to `true` above. + // "Ahoy, world!" is included if `is_pirate` is set to `true` above. ] } ``` diff --git a/language-guide/tasks.md b/language-guide/tasks.md index fcafc7d..658a0bd 100644 --- a/language-guide/tasks.md +++ b/language-guide/tasks.md @@ -5,14 +5,14 @@ outline: deep # Tasks **Tasks** ([spec link][spec-tasks]) are the atomic unit of computation within WDL. -Fundamentally, the represent a bash script that is intended to be run to accomplish some +Fundamentally, they represent a bash script that is intended to be run to accomplish some goal. You'll reach for tasks when defining each of the constituent analyses within a broader [workflow](./workflows.md). -Tasks have a required ```command``` section and several optional sections for things +Tasks have a required `command` section and several optional sections for things like defining inputs, defining outputs, documenting your task, and specifying runtime requirements. We'll cover each of these in detail here while leaving an exhaustive -explanation to [the specification][spec-tasks]. +explanation to [the specification][spec-tasks]. Below is a representative example of what a simple task might look like. @@ -179,7 +179,7 @@ them when the need arises. [spec-tasks]: https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#task-definition [spec-task-inputs]: https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#task-inputs -[spec-task-inputs]: https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#task-outputs +[spec-task-outputs]: https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#task-outputs [spec-requirements]: https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#-requirements-section [spec-requirements-attributes]: https://github.com/openwdl/wdl/blob/wdl-1.2/SPEC.md#requirements-attributes diff --git a/overview.md b/overview.md index 7e8d84b..0fb4eae 100644 --- a/overview.md +++ b/overview.md @@ -64,7 +64,7 @@ ensure you have the best possible experience: * Follow the quickstart guide to learn the most important concepts in WDL ([link](./getting-started/quickstart.md)). -* Install an developer extension within LSP integration, such as +* Install a developer extension within LSP integration, such as [Sprocket][sprocket-ext], and pay attention to the validation errors and lints. * Select an execution engine for the environment(s) you're planning to run your workflows within and stick with it