Fix typos in documentation, tests and benchmarks

benchmarks/suites/dtable.jl

@@ -75,7 +75,7 @@ function dtable_suite(ctx; method, accels)
             fetch_wait(dt)
         end setup=begin
             genchunk = $genchunk
-            @info "$(time_ns()) Writing mutiple CSVs"
+            @info "$(time_ns()) Writing multiple CSVs"
             path = mktempdir()
             nchunks = $nchunks
             wait.([Threads.@spawn CSV.write(joinpath(path, "datapart_$i.csv"), genchunk(MersenneTwister(1111+i), nchunks)) for i in 1:nchunks])

benchmarks/visualize.jl

@@ -119,7 +119,7 @@ push!(legend_names, "cpu+dagger")
 legend = fig[1, 2] = Legend(fig, line_plots, legend_names)
 save("weak_scaling.png", fig)
 
-# 3. Comparision against Base
+# 3. Comparison against Base
 
 fig = Figure(resolution = (1200, 800))
 perf = fig[1, 1] = Axis(fig, title = "Dagger vs Base")

docs/src/datadeps.md

@@ -128,7 +128,7 @@ Dagger.spawn_datadeps() do
 end
 ```
 
-The other way allows you to seperate what argument is passed to the function,
+The other way allows you to separate what argument is passed to the function,
 from how that argument is accessed within the function. This is done with the
 `Deps` wrapper, which is used like so:
 

docs/src/dynamic.md

@@ -27,7 +27,7 @@ various uses:
 When working with thunks acquired from `get_dag_ids` or `add_thunk!`,
 you will have `ThunkID` objects which refer to a thunk by ID. Scheduler
 control functions which work with thunks accept or return `ThunkID`s. For
-example, one can create a new thunkt and get its result with `Base.fetch`:
+example, one can create a new thunk and get its result with `Base.fetch`:
 
 ```julia
 function mythunk(x)

docs/src/task-spawning.md

@@ -37,7 +37,7 @@ key-value pairs, which can be any of:
 - `meta::Bool` -- Pass the input [`Chunk`](@ref) objects themselves to `f` and
   not the value contained in them.
 
-There are also some extra optionss that can be passed, although they're considered advanced options to be used only by developers or library authors:
+There are also some extra options that can be passed, although they're considered advanced options to be used only by developers or library authors:
 - `get_result::Bool` -- return the actual result to the scheduler instead of [`Chunk`](@ref) objects. Used when `f` explicitly constructs a [`Chunk`](@ref) or when return value is small (e.g. in case of reduce)
 - `persist::Bool` -- the result of this Thunk should not be released after it becomes unused in the DAG
 - `cache::Bool` -- cache the result of this Thunk such that if the thunk is evaluated again, one can just reuse the cached value. If it’s been removed from cache, recompute the value.

docs/src/use-cases/parallel-nested-loops.md

@@ -74,7 +74,7 @@ In this code we have job interdependence. Firstly, we are calculating the
 standard deviation `σ` and than we are using that value in the function `f`.
 Since `Dagger.@spawn` yields an `DTask` rather than actual values, we need
 to use the `fetch` function to obtain those values. In this example, the value
-fetching is perfomed once all computations are completed (note that `@sync`
+fetching is performed once all computations are completed (note that `@sync`
 preceding the loop forces the loop to wait for all jobs to complete). Also,
 note that contrary to the previous example, we do not need to implement locking
 as we are just pushing the `DTask` results of `Dagger.@spawn` serially

test/processors.jl

@@ -19,7 +19,7 @@ end
         @test op isa OSProc
         @test op.pid == 1
     end
-    @testset "Function/argument compatability" begin
+    @testset "Function/argument compatibility" begin
         unknown_func = () -> nothing
         tp = ThreadProc(1, 1)
         op = get_parent(tp)