[Libreoffice-commits] core.git: include/vcl vcl/README.scheduler

[Andrea Gelmini (via logerrit)]

 include/vcl/TaskStopwatch.hxx |    8 ++++----
 vcl/README.scheduler          |    6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)

New commits:
commit 08097a2eef5e827735af3e5e69b30d23ee213970
Author:     Andrea Gelmini <andrea.gelmini at gelma.net>
AuthorDate: Tue Aug 13 17:05:37 2019 +0200
Commit:     Andrea Gelmini <andrea.gelmini at gelma.net>
CommitDate: Tue Aug 13 18:57:27 2019 +0200

    Fix typos
    
    Change-Id: I5c3d7a041f0d654d04d8cbe71393921ed46c1220
    Reviewed-on: https://gerrit.libreoffice.org/77426
    Reviewed-by: Julien Nabet <serval2412 at yahoo.fr>
    Tested-by: Jenkins

diff --git a/include/vcl/TaskStopwatch.hxx b/include/vcl/TaskStopwatch.hxx
index c98dcc6f5527..fdcc6bdf2ed4 100644
--- a/include/vcl/TaskStopwatch.hxx
+++ b/include/vcl/TaskStopwatch.hxx
@@ -18,7 +18,7 @@
 /**
  * Helper class primary used to track time of long running iterating tasks.
  *
- * Normally it should be sufficiant to instanciate the watch object before
+ * Normally it should be sufficient to instantiate the watch object before
  * starting the iteration and query continueIter() at the end of each.
  *
  * Called Stopwatch, because there is already a Timer class in the Scheduler.
@@ -65,13 +65,13 @@ class VCL_DLLPUBLIC TaskStopwatch
 
 public:
     /**
-     * Per default the watch consideres the last iter time when asking for an
+     * Per default the watch considers the last iter time when asking for an
      * other iteration, so considers Scheduler::acceptableTaskTime as a
      * maximum value.
      *
      * If you already know your iter time vary in a large range, consider
      * setting bConciderLastIterTime to false, so Scheduler::acceptableTaskTime
-     * will be used as a mimimum time slot.
+     * will be used as a minimum time slot.
      **/
     TaskStopwatch(bool bConciderLastIterTime = true)
         : m_nStartTicks(tools::Time::GetSystemTicks())
@@ -87,7 +87,7 @@ public:
     bool exceededRuntime() { return !nextIter(true); }
 
     /**
-     * Returns true, if an other iteration will probably pass in the time slot
+     * Returns true, if another iteration will probably pass in the time slot
      **/
     bool continueIter() { return nextIter(false); }
 
diff --git a/vcl/README.scheduler b/vcl/README.scheduler
index a05a291bc1c3..52c76dac5b85 100644
--- a/vcl/README.scheduler
+++ b/vcl/README.scheduler
@@ -176,7 +176,7 @@ versions are processed but simply don't run the scheduler.
 
 == General: track time of long running tasks ==
 
-There is TaskStopwatch class. It'll track the time and report a timout either
+There is TaskStopwatch class. It'll track the time and report a timeout either
 when the tasks time slice is finished or some system event did occur.
 
 Eventually it will be merged into the main scheduler, so each invoked task can
@@ -189,7 +189,7 @@ There were some questions coming up when implementing it:
 and skip the instant timeout? ===
 
 You never know how long a task will run. Currently the scheduler simply asks
-each task when it'll be ready to run, until two runable tasks are found.
+each task when it'll be ready to run, until two runnable tasks are found.
 Normally this is very quick, as LO has a lot of one-shot instant tasks / Idles
 and just a very few long term pending Timers.
 
@@ -207,7 +207,7 @@ term timer list increases AKA for highly loaded LOOL instances.
 
 But the Linux timer wheel mainly relies on the facts that the OS timers are
 expected to not expire, as they are use to catch "error" timeouts, which rarely
-happen, so this definitly not matches LO's usage.
+happen, so this definitely not matches LO's usage.
 
 === Not really usable to find misbehaving tasks ===