spelling

HenrikBengtsson · HenrikBengtsson · commit 27bae875ff2d · 2025-08-06T12:00:06.000-07:00
diff --git a/DESCRIPTION b/DESCRIPTION
@@ -1,5 +1,5 @@
 Package: parallelly
-Version: 1.45.1-9002
+Version: 1.45.1-9003
 Title: Enhancing the 'parallel' Package
 Imports:
     parallel,
diff --git a/Makefile b/Makefile
@@ -1,7 +1,7 @@
 include .make/Makefile
 
 spelling:
-	$(R_SCRIPT) -e "spelling::spell_check_files(c('NEWS.md', dir('vignettes', pattern='[.]rsp', full.names=TRUE)), ignore=readLines('inst/WORDLIST', warn=FALSE))"
+	$(R_SCRIPT) -e "spelling::spell_check_files(c('NEWS.md', 'incl/OVERVIEW.md', dir('vignettes', pattern='[.](md|rsp)$$', full.names=TRUE)), ignore=readLines('inst/WORDLIST', warn=FALSE))"
 
 vignettes/parallelly-01-intro.md: incl/OVERVIEW.md vignettes/incl/clean.css
 	sed -E -i '/^(<!-- DO NOT EDIT THIS FILE|!\[|#+[[:space:]])/,$$d' $@
diff --git a/incl/OVERVIEW.md b/incl/OVERVIEW.md
@@ -57,7 +57,7 @@ Did you know that `parallel::detectCores()` might return NA on some systems, or
 Just like other software tools that "hijacks" all cores by default, R scripts, and packages that defaults to `detectCores()` number of parallel workers cause lots of suffering for fellow end-users and system administrators.  For instance, a shared server with 48 cores will come to a halt already after a few users run parallel processing using `detectCores()` number of parallel workers.  This problem gets worse on machines with many cores because they can host even more concurrent users.  If these R users would have used `availableCores()` instead, then the system administrator can limit the number of cores each user get to, say, two (2), by setting the environment variable `R_PARALLELLY_AVAILABLECORES_FALLBACK=2`.
 In contrast, it is _not_ possible to override what `parallel::detectCores()` returns, cf. [PR#17641 - WISH: Make parallel::detectCores() agile to new env var R_DEFAULT_CORES ](https://bugs.r-project.org/show_bug.cgi?id=17641).
 
-Similarly, `availableCores()` is also agile to CPU limitations set by Unix control groups (cgroups), which is often used by Linux containers (e.g. Docker, Apptainer / Singularity, and Podman) and Kubernetes (K8s) environments.  For example, `docker run --cpuset-cpus=0-2,8 ...` sets the CPU affinity so that the processes can only run on CPUs 0, 1, 2, and 8 on the host system.  In this case `availableCores()` detects this and returns four (4).  Another example is `docker run --cpu=3.4 ...`, which throttles the CPU quota to on average 3.4 CPUs on the host system.  In this case `availableCores()` detects this and returns three (3), because it rounds to the nearest integer.  In contrast, `parallel::detectCores()` completely ignores such cgroups settings and returns the number of CPUs on the host system, which results in CPU overuse and degredated performance.  Continous Integration (CI) services (e.g. GitHub Actions, Travis CI, and Appveyor CI) and cloud services (e.g. RStudio Cloud) use these types of cgroups settings under the hood, which means `availableCores()` respects their CPU allocations.
+Similarly, `availableCores()` is also agile to CPU limitations set by Unix control groups (cgroups), which is often used by Linux containers (e.g. Docker, Apptainer / Singularity, and Podman) and Kubernetes (K8s) environments.  For example, `docker run --cpuset-cpus=0-2,8 ...` sets the CPU affinity so that the processes can only run on CPUs 0, 1, 2, and 8 on the host system.  In this case `availableCores()` detects this and returns four (4).  Another example is `docker run --cpu=3.4 ...`, which throttles the CPU quota to on average 3.4 CPUs on the host system.  In this case `availableCores()` detects this and returns three (3), because it rounds to the nearest integer.  In contrast, `parallel::detectCores()` completely ignores such cgroups settings and returns the number of CPUs on the host system, which results in CPU overuse and degraded performance.  Continuous Integration (CI) services (e.g. GitHub Actions, Travis CI, and AppVeyor CI) and cloud services (e.g. RStudio Cloud) use these types of cgroups settings under the hood, which means `availableCores()` respects their CPU allocations.
 
 If running on an HPC cluster with a job scheduler, a script that uses `availableCores()` will run the number of parallel workers that the job scheduler has assigned to the job.  For example, if we submit a Slurm job as `sbatch --cpus-per-task=16 ...`, then `availableCores()` returns 16, because it respects the `SLURM_*` environment variables set by the scheduler.  On Son of Grid Engine (SGE), the scheduler sets `NSLOTS` when submitting using `qsub -pe smp 8 ...` and `availableCores()` returns eight (8).  See `help("availableCores", package = "parallelly")` for currently supported job schedulers, which includes 'Fujitsu Technical Computing Suite', 'Load Sharing Facility' (LSF), Simple Linux Utility for Resource Management (Slurm), Sun Grid Engine/Oracle Grid Engine/Son of Grid Engine (SGE), Univa Grid Engine (UGE), and TORQUE/PBS.
 
diff --git a/inst/WORDLIST b/inst/WORDLIST
@@ -1,12 +1,16 @@
-AppVeyor
+AMI
 Apptainer
+AppVeyor
 AsIs
 BiocParallel
+Bubblewrap
 CGroups
 CMD
+DDNS
 DJOB
 DNS
 FQDN
+GCE
 GetConnection
 HOSTFILE
 HenrikBengtsson
@@ -15,6 +19,7 @@ LSB
 LSF
 LibreSSL
 MSYS
+MiB
 MinGW
 NCPUS
 NSLOTS
@@ -30,10 +35,12 @@ PJM
 PPK
 PPN
 PSOCK
+Podman
 Pre
 PuTTY
 PuTTY's
 RStudio
+RStudio's
 Renviron
 RichSOCKcluster
 RichSOCKnode
@@ -90,6 +97,7 @@ freezed
 getOption
 getOptionOrEnvVar
 github
+globbing
 grepl
 hardcoded
 hostname
@@ -101,6 +109,7 @@ isForkedChild
 isForkedNode
 isLocalhostNode
 isNodeAlive
+jumphost
 libPaths
 libs
 linux
@@ -134,6 +143,7 @@ rshcmd
 rshlogfile
 rstudio
 sQuote
+sandboxed
 scontrol
 setTimeLimit
 sig
@@ -150,7 +160,9 @@ tasklist
 tcltk
 tmp
 todo
+udocker
 useFancyQuotes
 useXDR
 workRSOCK
 yYF
+VM
diff --git a/vignettes/parallelly-01-intro.md b/vignettes/parallelly-01-intro.md
@@ -68,7 +68,7 @@ Did you know that `parallel::detectCores()` might return NA on some systems, or
 Just like other software tools that "hijacks" all cores by default, R scripts, and packages that defaults to `detectCores()` number of parallel workers cause lots of suffering for fellow end-users and system administrators.  For instance, a shared server with 48 cores will come to a halt already after a few users run parallel processing using `detectCores()` number of parallel workers.  This problem gets worse on machines with many cores because they can host even more concurrent users.  If these R users would have used `availableCores()` instead, then the system administrator can limit the number of cores each user get to, say, two (2), by setting the environment variable `R_PARALLELLY_AVAILABLECORES_FALLBACK=2`.
 In contrast, it is _not_ possible to override what `parallel::detectCores()` returns, cf. [PR#17641 - WISH: Make parallel::detectCores() agile to new env var R_DEFAULT_CORES ](https://bugs.r-project.org/show_bug.cgi?id=17641).
 
-Similarly, `availableCores()` is also agile to CPU limitations set by Unix control groups (cgroups), which is often used by Linux containers (e.g. Docker, Apptainer / Singularity, and Podman) and Kubernetes (K8s) environments.  For example, `docker run --cpuset-cpus=0-2,8 ...` sets the CPU affinity so that the processes can only run on CPUs 0, 1, 2, and 8 on the host system.  In this case `availableCores()` detects this and returns four (4).  Another example is `docker run --cpu=3.4 ...`, which throttles the CPU quota to on average 3.4 CPUs on the host system.  In this case `availableCores()` detects this and returns three (3), because it rounds to the nearest integer.  In contrast, `parallel::detectCores()` completely ignores such cgroups settings and returns the number of CPUs on the host system, which results in CPU overuse and degredated performance.  Continous Integration (CI) services (e.g. GitHub Actions, Travis CI, and Appveyor CI) and cloud services (e.g. RStudio Cloud) use these types of cgroups settings under the hood, which means `availableCores()` respects their CPU allocations.
+Similarly, `availableCores()` is also agile to CPU limitations set by Unix control groups (cgroups), which is often used by Linux containers (e.g. Docker, Apptainer / Singularity, and Podman) and Kubernetes (K8s) environments.  For example, `docker run --cpuset-cpus=0-2,8 ...` sets the CPU affinity so that the processes can only run on CPUs 0, 1, 2, and 8 on the host system.  In this case `availableCores()` detects this and returns four (4).  Another example is `docker run --cpu=3.4 ...`, which throttles the CPU quota to on average 3.4 CPUs on the host system.  In this case `availableCores()` detects this and returns three (3), because it rounds to the nearest integer.  In contrast, `parallel::detectCores()` completely ignores such cgroups settings and returns the number of CPUs on the host system, which results in CPU overuse and degraded performance.  Continuous Integration (CI) services (e.g. GitHub Actions, Travis CI, and AppVeyor CI) and cloud services (e.g. RStudio Cloud) use these types of cgroups settings under the hood, which means `availableCores()` respects their CPU allocations.
 
 If running on an HPC cluster with a job scheduler, a script that uses `availableCores()` will run the number of parallel workers that the job scheduler has assigned to the job.  For example, if we submit a Slurm job as `sbatch --cpus-per-task=16 ...`, then `availableCores()` returns 16, because it respects the `SLURM_*` environment variables set by the scheduler.  On Son of Grid Engine (SGE), the scheduler sets `NSLOTS` when submitting using `qsub -pe smp 8 ...` and `availableCores()` returns eight (8).  See `help("availableCores", package = "parallelly")` for currently supported job schedulers, which includes 'Fujitsu Technical Computing Suite', 'Load Sharing Facility' (LSF), Simple Linux Utility for Resource Management (Slurm), Sun Grid Engine/Oracle Grid Engine/Son of Grid Engine (SGE), Univa Grid Engine (UGE), and TORQUE/PBS.
 
diff --git a/vignettes/parallelly-10-local-workers.md b/vignettes/parallelly-10-local-workers.md
@@ -20,7 +20,7 @@ where R is supported, e.g. Linux, macOS, and MS Windows.
 ## Example: Launching two parallel workers
 
 The below illustrates how to launch a cluster of two parallel workers
-on the current machine, run some basic calculations in paralllel, and
+on the current machine, run some basic calculations in parallel, and
 then shut down the cluster.
 
 ```r
@@ -59,7 +59,7 @@ cl <- makeClusterPSOCK(c("localhost", "localhost"))
 
 The `availableCores()` function will return the number of workers that
 the system allows. It respects many common settings that controls the
-number of CPU cores that the current R process is alloted, e.g. R
+number of CPU cores that the current R process is allotted, e.g. R
 options, environment variables, and CGroups settings. For details, see
 `help("availableCores")`. For example,
 
diff --git a/vignettes/parallelly-12-remote-workers.md b/vignettes/parallelly-12-remote-workers.md
@@ -10,8 +10,8 @@
 
 # Introduction
 
-Sometimes it is not sufficient to parallize on a single computer - it
-cannot provide all of the compute power we are looking for. When we
+Sometimes it is not sufficient to parallelize on a single computer -
+it cannot provide all of the compute power we are looking for. When we
 hit this limit, a natural next level is to look at other computers
 near us, e.g. desktops in an office or other computers we have access
 to remotely. In this vignette, we will cover how to run parallel R
@@ -205,7 +205,7 @@ parallel R workers on these machines with little efforts.
 
 Some machines do not use the default port 22 to answer on SSH
 connection requests. If the machine uses another port, say, port 2201,
-then we canspecify that via option `-p port`, when we connect to it,
+then we can specify that via option `-p port`, when we connect to it,
 e.g.
 
 ```sh
@@ -483,8 +483,8 @@ referred to as a "jumphost".  For example, assume machine
 {alice@secret1}$ 
 ```
 
-To achive the same in a single SSH call, we can specify the "jumphost"
-`-J hostname` option for SSH, as in:
+To achieve the same in a single SSH call, we can specify the
+"jumphost" `-J hostname` option for SSH, as in:
 
 ```sh
 {ally@local}$ ssh -J alice@login.remote.org alice@secret1.remote.org
diff --git a/vignettes/parallelly-17-hpc-workers.md b/vignettes/parallelly-17-hpc-workers.md
@@ -98,7 +98,7 @@ version 4.5.1 (2025-06-13), platform x86_64-pc-linux-gnu)
 
 
 
-## Example: Launch parallel workers via the'Fujitsu Technical Computing Suite job scheduler
+## Example: Launch parallel workers via the Fujitsu Technical Computing Suite job scheduler
 
 The 'Fujitsu Technical Computing Suite' is a high-performance compute
 (HPC) job scheduler where one can request compute resources on
