Minor updates

Signed-off-by: Ben Sherman <[email protected]>

docs/dsl1.md

@@ -26,7 +26,6 @@ nextflow.enable.dsl=1
 params.str = 'Hello world!'
 
 process splitLetters {
-
     output:
     file 'chunk_*' into letters
 
@@ -36,7 +35,6 @@ process splitLetters {
 }
 
 process convertToUpper {
-
     input:
     file x from letters.flatten()
 
@@ -55,35 +53,8 @@ To migrate this code to DSL2, you need to move all of your channel logic through
 
 Refer to the {ref}`workflow-page` page to learn how to define a workflow. The DSL2 version of the above script is duplicated here for your convenience:
 
-```groovy
-params.str = 'Hello world!'
-
-process splitLetters {
-
-    output:
-    path 'chunk_*'
-
-    """
-    printf '${params.str}' | split -b 6 - chunk_
-    """
-}
-
-process convertToUpper {
-
-    input:
-    path x
-
-    output:
-    stdout
-
-    """
-    cat $x | tr '[a-z]' '[A-Z]'
-    """
-}
-
-workflow {
-    splitLetters | flatten | convertToUpper | view { it.trim() }
-}
+```{literalinclude} snippets/your-first-script.nf
+:language: groovy
 ```
 
 ## Channel forking
@@ -95,7 +66,7 @@ In DSL2, channels are automatically forked when connecting two or more consumers
 For example, this would not work in DSL1 but is not a problem in DSL2:
 
 ```groovy
-channel
+Channel
     .from('Hello','Hola','Ciao')
     .set{ cheers }
 
@@ -116,6 +87,10 @@ In DSL1, the entire Nextflow pipeline must be defined in a single file (e.g. `ma
 
 DSL2 introduces the concept of "module scripts" (or "modules" for short), which are Nextflow scripts that can be "included" by other scripts. While modules are not essential to migrating to DSL2, nor are they mandatory in DSL2 by any means, modules can help you organize a large pipeline into multiple smaller files, and take advantage of modules created by others. Check out the {ref}`module-page` to get started.
 
+:::{note}
+With DSL2, the Groovy shell used by Nextflow also imposes a 64KB size limit on pipeline scripts, so if your DSL1 script is very large, you may need to split your script into modules anyway to avoid this limit.
+:::
+
 ## Deprecations
 
 ### Processes

docs/getstarted.md

@@ -96,32 +96,8 @@ nextflow self-update
 
 Copy the following example into your favorite text editor and save it to a file named `tutorial.nf`:
 
-```groovy
-params.str = 'Hello world!'
-
-process splitLetters {
-  output:
-    path 'chunk_*'
-
-  """
-  printf '${params.str}' | split -b 6 - chunk_
-  """
-}
-
-process convertToUpper {
-  input:
-    path x
-  output:
-    stdout
-
-  """
-  cat $x | tr '[a-z]' '[A-Z]'
-  """
-}
-
-workflow {
-  splitLetters | flatten | convertToUpper | view { it.trim() }
-}
+```{literalinclude} snippets/your-first-script.nf
+:language: groovy
 ```
 
 :::{note}

docs/module.md

@@ -30,7 +30,7 @@ Nextflow implicitly looks for the script file `./some/module.nf`, resolving the
 Module includes are subject to the following rules:
 
 - Relative paths must begin with the `./` prefix.
-- Include statements are not allowed from within a worklfow. They must occur at the script level.
+- Include statements are not allowed from within a workflow. They must occur at the script level.
 
 (module-directory)=
 

docs/snippets/your-first-script.nf

@@ -0,0 +1,26 @@
+params.str = 'Hello world!'
+
+process splitLetters {
+    output:
+    path 'chunk_*'
+
+    """
+    printf '${params.str}' | split -b 6 - chunk_
+    """
+}
+
+process convertToUpper {
+    input:
+    path x
+
+    output:
+    stdout
+
+    """
+    cat $x | tr '[a-z]' '[A-Z]'
+    """
+}
+
+workflow {
+    splitLetters | flatten | convertToUpper | view { it.trim() }
+}

docs/workflow.md

@@ -41,7 +41,7 @@ The `main:` label can be omitted if there are no `take:` or `emit:` blocks.
 Workflows were introduced in DSL2. If you are still using DSL1, see the {ref}`dsl1-page` page to learn how to migrate your Nextflow pipelines to DSL2.
 :::
 
-## Invoking processes
+## Process invocation
 
 A process can be invoked like a function in a workflow definition, passing the expected input channels like function arguments. For example:
 
@@ -77,12 +77,12 @@ workflow {
 ```
 
 :::{warning}
-A process can be only be invoked once in a single workflow, unless using {ref}`module-aliases`.
+A process can be only be invoked once in a single workflow, however you can get around this restriction by using {ref}`module-aliases`.
 :::
 
 ### Process composition
 
-Processes with matching input/output declarations can be composed so that the output of the first process is passed as input to the second process. Taking in consideration the previous example, it's possible to write the following:
+Processes with matching input/output declarations can be composed so that the output of the first process is passed as input to the second process. The previous example can be rewritten as follows:
 
 ```groovy
 workflow {
@@ -134,6 +134,14 @@ workflow {
 }
 ```
 
+When referencing a named output directly from the process invocation, you can use a more concise syntax:
+
+```groovy
+workflow {
+    ch_samples = foo().samples_bam
+}
+```
+
 ### Process named stdout
 
 The `emit` option can also be used to name a `stdout` output: