#:argv(vector-drop(current-command-line-arguments)1); snip the 'setup' from the front
#:once-any
[("-p""--parallel")"Setup in parallel using all cores"(setup-parallel?#true)]
[("-j""--jobs")job-count"Setup in parallel using <job-count> jobs"(setup-parallel?(or(string->numberjob-count)(raise-argument-error'handle-setup"exact positive integer"job-count)))]
[("-p""--parallel")"Render in parallel"(render-parallel?#true)]
#:once-any
[("-p""--parallel")"Render in parallel using all cores"(render-parallel?#true)]
[("-j""--jobs")job-count"Render in parallel using <job-count> jobs"(render-parallel?(or(string->numberjob-count)(raise-argument-error'handle-render"exact positive integer"job-count)))]
#:argsother-args
other-args))
(parameterize([current-poly-target(render-target-wanted)]);; applies to both cases
@ -127,7 +141,7 @@ version print the version" (current-server-port) (make-publish-di
@ -96,16 +96,22 @@ The optional @exec{--target} or @exec{-t} switch specifies the render target for
See also @seclink["raco-pollen-render-poly"].
The optional @exec{--parallel} or @exec{-p} switch creates a set of parallel rendering jobs. On a multi-core machine, this will usually make your rendering job finish faster. The order of rendering is not guaranteed, of course, so if your project depends on a certain order of rendering, don't use this option.
The optional @exec{--parallel} or @exec{-p} switch creates a set of parallel rendering jobs equal to the number of processing cores on the system. On a multi-core machine, this will usually make your rendering job finish faster. The order of rendering is not guaranteed, of course, so if your project depends on a certain order of rendering, don't use this option.
@terminal{
> raco pollen render -p foo.html bar.html zam.css
}
The alternative @exec{--jobs <count>} or @exec{-j <count>} switch does the same thing, but takes one argument that creates @racket[<count>] parallel jobs (which can be more or less than the number of processing cores).
As a rule of thumb, parallel rendering works best if you do @exec{raco setup} first, which updates Pollen's disk caches:
@terminal{
> raco setup
> raco setup -p
> raco pollen render -p
}
@ -115,7 +121,7 @@ As a rule of thumb, parallel rendering works best if you do @exec{raco setup} fi
@bold{Directory mode}: @racket[raco pollen render _directory] renders all preprocessor source files and then all pagetree files found in the specified directory. If none of these files are found, a pagetree will be generated for the directory (which will include all source files) and then rendered. If the @racket[_directory] argument is omitted, the command defaults to the current directory.
In directory mode, this command can be invoked with two other optional arguments (in addition to the @exec{--target} and @exec{--parallel} switches mentioned above):
In directory mode, this command can be invoked with two other optional arguments (in addition to the @exec{--target}, @exec{--parallel}, and @exec{--jobs} switches mentioned above):
The @exec{--subdir} or @exec{-s} switch also renders subdirectories. @racket[current-project-root] remains fixed at the initial directory, just as it would be in the project server after invoking @racket[raco pollen start].
@ -149,6 +155,18 @@ Finds Pollen source files in the current directory, compiles them, and loads the
Can also be invoked as @racket[raco pollen setup _directory], which will set up the files in @racket[_directory].
The optional @exec{--parallel} or @exec{-p} switch creates a set of parallel setup jobs equal to the number of processing cores on the system. On a multi-core machine, this will usually make your setup finish faster.
@terminal{
> raco pollen setup -p
}
The alternative @exec{--jobs <count>} or @exec{-j <count>} switch does the same thing, but takes one argument that creates @racket[<count>] parallel jobs (which can be more or less than the number of processing cores).
