Fix some typos through 'codespell' (#138)

* Fix some typos

* Checked codespell manually

* Checked codespell manually

* Fixed allways

CREDITS.md

@@ -36,7 +36,7 @@
 - [Pavel Tzekov](mailto:[email protected]): Win32 support
 - Charles Vidal: Tcl/Tk interface
 - [Tapio K. Vocaldo](mailto:[email protected]): Macintosh port
-- Tormod Volden: Fixes for X11 driver to improve compatability with Xorg, XScreenSaver, Beryl and Compiz
+- Tormod Volden: Fixes for X11 driver to improve compatibility with Xorg, XScreenSaver, Beryl and Compiz
 - [Philippe Wautelet](mailto:[email protected]): Bug fixes for version 3.1.1, French translation, gcc 4.0 fixes
 - Sergio Zanchetta: Italian translation
 - Alexey Loginov: Russian translation

NEWS

@@ -127,7 +127,7 @@ markup into image files that get included in the HTML output.
 The documentation still needs a lot of work before it is ready, and we 
 have to make some modifications to Sphinx itself in order to integrate 
 the documentation it produces with XaoS's help system.  However, it is 
-far enough along that we would welcome volunteers who are familar with 
+far enough along that we would welcome volunteers who are familiar with 
 reStructuredText to submit improvements to the documentation.
 
 The new documentation is located in the help/rest directory, and it can
@@ -250,7 +250,7 @@ audience now.
 Mateusz has been working on the underlying SFFE (SegFault Formula
 Evaluator) library for several months. XaoS-3.3 can be compiled using
 both NASM (Netwide Assembler) or GSL (GNU Scientific Library) for the
-underlying complex arithmetics used by SFFE. For more information about
+underlying complex arithmetic used by SFFE. For more information about
 the available user functions please read the enclosed documentation 
 (see online help, "Other things to read", last entry), or visit
 Mateusz's info page on http://www.segfaultlabs.com/sfXaoS.

catalogs/de.cat

@@ -31,7 +31,7 @@ gefunden werden kann.  "
 
 def1 "Eine der möglichen Definitionen ist:"
 #Definition from the intro.xaf is displayed here.
-#If it is a problem in your langage catalog, let me
+#If it is a problem in your language catalog, let me
 #know and I will create a special key
 def2 "Was heisst das?"
 def3 "Um dies zu erklären, müssen wir zuerst

catalogs/en.cat

@@ -42,7 +42,7 @@ if some self-similarity can be found"
 
 def1 "One of the possible definitions is..."
 #Definition from the intro.xaf is displayed here.
-#If it is a problem in your langage catalog, let me
+#If it is a problem in your language catalog, let me
 #know and I will create a special key
 def2 "What does this mean?"
 def3 "To explain it we first need

catalogs/fr.cat

@@ -42,7 +42,7 @@ d'auto-similarité."
 
 def1 "Une des définitions est la suivante..."
 #Definition from the intro.xaf is displayed here.
-#If it is a problem in your langage catalog, let me
+#If it is a problem in your language catalog, let me
 #know and I will create a special key
 def2 "Qu'est-ce que ça veut bien dire?"
 def3 "Pour expliquer ça, il faut d'abord

catalogs/it.cat

@@ -43,7 +43,7 @@ autosomiglianza."
 
 def1 "Una delle possibili definizioni è..."
 #Definition from the intro.xaf is displayed here.
-#If it is a problem in your langage catalog, let me
+#If it is a problem in your language catalog, let me
 #know and I will create a special key
 def2 "Cosa significa tutto ciò?"
 def3 "Per spiegarlo dobbiamo prima capire cosa

catalogs/pt.cat

@@ -56,7 +56,7 @@ se possui alguma auto-semelhança"
 
 def1 "Uma possível definição é..."
 #Definition from the intro.xaf is displayed here.
-#If it is a problem in your langage catalog, let me
+#If it is a problem in your language catalog, let me
 #know and I will create a special key
 def2 "O que isso significa?"
 def3 "Para explicar, primeiramente precisamos 

catalogs/ro.cat

@@ -43,7 +43,7 @@ prezintă o anumită auto-similaritate"
 
 def1 "Una din posibilele definitii este..."
 #Definition from the intro.xaf is displayed here.
-#If it is a problem in your langage catalog, let me
+#If it is a problem in your language catalog, let me
 #know and I will create a special key
 def2 "Ce inseamna aceasta?"
 def3 "Pentru a explica trebuie mai intai

catalogs/ru.cat

@@ -43,7 +43,7 @@ fmath3 "Мы обычно называем что-то фракталом,
 
 def1 "Одно из возможных определений..."
 #Definition from the intro.xaf is displayed here.
-#If it is a problem in your langage catalog, let me
+#If it is a problem in your language catalog, let me
 #know and I will create a special key
 def2 "Что это значит?"
 def3 "Чтобы объяснить это, мы сначала

src/engine/3dd.h

@@ -131,7 +131,7 @@ static void do_3d(void *dataptr, struct taskinfo */*task*/, int r1, int r2)
             else
                 inpdata[x].max = maxinp - 32;
 
-            /* caluclate top of mountain.  */
+            /* calculate top of mountain.  */
             d = inp / 16;
             d = y - (d > height ? height : d);
 

src/engine/btrace.cpp

@@ -12,7 +12,7 @@
  * This is an implementation of famous boundary trace algorithm.
  * See fractint documentation if you don't know what this means :)
  *
- * Here is two different implentation of this algorithm - one is faster
+ * Here is two different implementation of this algorithm - one is faster
  * and second is threadable.
  *
  * An faster one is quite usual implementation - get first uncalculated pixel,
@@ -36,7 +36,7 @@
  > its left" designated as if they were in a "logical" ring. Each processor
  > pushes new pixels on the processor to its left's substack, and pops from
  > its own. This way, busy parts of the image wind up spread among all
- > processors. By adding substacks, this can be expanded to accomodate more
+ > processors. By adding substacks, this can be expanded to accommodate more
  > processors. Some amount is optimal, after which a point of diminishing
  > returns is reached when most processors only do a few pixels and spend
  > most of their time waiting for new stuff from the processor to its right.
@@ -46,13 +46,13 @@
  > image anyways.) Also, the end is only reached when NO processors have
  > anything in their stacks.
  This method looks very interesting but has few serious problems.
- Most significant probably is that it always caluclates pixels up
+ Most significant probably is that it always calculates pixels up
  to distance 3 from boundary. Simple modification should lower it
- to distance 2. But "right hand rule" based algorithm should actualy
+ to distance 2. But "right hand rule" based algorithm should actually
  calculate points just to distance 1. So I want to implement such alrogithm,
- since number of caluclated points is still significant.
+ since number of calculated points is still significant.
 
- So I think I have to extend stack for two informations:
+ So I think I have to extend stack for two information:
  1) direction
  2) color of boundary I am tracking(not color I am at)
  and main algorithm should look like:
@@ -61,16 +61,16 @@
  yes:add point at the right to stack and exit
  is there boundary color?
  no:we are meeting boundary with different color - so we need
- to track this boundary too. add point at right to stack with oposite
+ to track this boundary too. add point at right to stack with opposite
  direction and boundary color set to current color
  3) look forward: similar scheme as to look right
  4) look left: again similar
  5) exit
 
- This hould trace boundaries to distance 1 (I hope) and do not miss anything.
+ This should trace boundaries to distance 1 (I hope) and do not miss anything.
  Problem is that this algorithm never ends, since boundaries will be rescaned
- again and again. So I need to add an caluclated array wich should looks like:
- for every point has mask for all directions that were scaned+calculated mask
+ again and again. So I need to add an calculated array which should looks like:
+ for every point has mask for all directions that were scanned+calculated mask
  (set to 1 if pixel is already calculated)+inprocess mask(set to 1 if some
  other processor is currently calculating it)
 
@@ -81,16 +81,16 @@
  some point)
 
  I was also thinking about perCPU queues. I think that one queue is OK,
- it is simplier and should not take much more time(except it will be locked
- more often but time spend in locked queue in comparsion to time spent
+ it is simpler and should not take much more time(except it will be locked
+ more often but time spend in locked queue in comparison to time spent
  in rest should be so small so this should not be drastical for less than 10
  procesors)
 
  At the other hand - perCPU queues should have one advantage - each
  cpu should own part of image and points from its part will be added to
  this cpu. This should avoid procesor cache conflict and speed up process.
  At the other hand, when cpu's queue is empty, cpu will have to browse
- others queues too and steal some points from other CPU, wich should introduce
+ others queues too and steal some points from other CPU, which should introduce
  some slowdown and I am not sure if this way will bring any improvement.
 
  Other think that should vote for perCPU queue is fact, that in one CPU
@@ -100,10 +100,10 @@
  cross broders, so they should be added to queue at the initialization, so
  this should be OK.
 
- I am beginer to threds, SMP etc. So I looking for ideas, and suggestions
+ I am beginer to threads, SMP etc. So I looking for ideas, and suggestions
  to improve this alg. (or design different one).
  Also someone with SMP box, who should test me code is welcomed.
- BTW whats is the average/maximal number of CPU in todays SMP boxes?
+ BTW what's is the average/maximal number of CPU in today's SMP boxes?
 
  Please reply directly to my email:[email protected]
 
@@ -119,13 +119,13 @@
  *    This will make queue bigger and reduce probability of situation, where
  *    queue is empty and other processors has to wait for one, that is
  *    calculating and should add something there (maybe :)
- * 2) Stack (queue :) is used just when neccesary - in situations where queue
+ * 2) Stack (queue :) is used just when necessary - in situations where queue
  *    is quite full (there is more items than 10) procesor just continues in
  *    tracing path it started. This reduces number of slow stack operations,
  *    locks/unlocks, cache conflicts and other bad thinks.
  * 3) Just each fourth pixel should be added into queue
  * 4) Foodfill algorithm should be avoided since colors at the boundaries
- *    are always correct, we should simply go trought each scanline and when
+ *    are always correct, we should simply go through each scanline and when
  *    pixel is uncalcualted, copy value from its left neighbor
  *
  * Current implementation has about 6% lower results than "fast" algorithm
@@ -162,7 +162,7 @@ static int exitnow;
 #define PAGESHIFT 14
 #define PAGESIZE (1 << PAGESHIFT)
 #define MAXPAGES                                                               \
-    200 /*Well limit is about 6MB of stack..Hope it will never owerflow */
+    200 /*Well limit is about 6MB of stack..Hope it will never overflow */
 #define MAXSIZE (MAXPAGES * PAGESIZE - 1)
 struct stack {
     int color;

src/engine/btraced.h

@@ -364,7 +364,7 @@ static void queue(void *data, struct taskinfo *task, int r1, int r2)
             nwaiting++;      /*We are not latest task. */
             xth_sleep(0, 0); /*Wait until other task will push some data */
             nwaiting--;
-            if (exitnow) { /*Evrything is done now? */
+            if (exitnow) { /*Everything is done now? */
                 xth_unlock(0);
                 return;
             }

src/engine/docalc.h

@@ -2,7 +2,7 @@
 /* Hello reader!
 
  * Are you sure you want read this? Its very cryptic and strange code. YOU
- * HAVE BEEN WARNED! Its purpose is to genereate as fast as possible
+ * HAVE BEEN WARNED! Its purpose is to generate as fast as possible
  * calculation loops for various formulas/algorithms. It uses lots of
  * coprocesor magic. It is included from formulas.c
  */
@@ -246,7 +246,7 @@ static unsigned int CALC(number_t zre, number_t zim, number_t pre, number_t pim)
 }
 #endif
 
-/*F. : Periodicity checking rountines.          (16-02-97)
+/*F. : Periodicity checking routines.          (16-02-97)
    All comments preceded by F. are mine (Fabrice Premel [email protected]).
    Tried to make code as efficient as possible.
    Next to do is convert lim in a variable that would be updated sometimes
@@ -261,15 +261,15 @@ static unsigned int CALC(number_t zre, number_t zim, number_t pre, number_t pim)
 
    UNCOMPRESSed form is just an extension, with careful that if we only check
    whentosave all 8 iterations, number of iterations must be well set at the
-   begining.This is done by adding a (iter&7) in the while statement preceeding
+   beginning.This is done by adding a (iter&7) in the while statement preceding
    then uncompressed calculation. */
 
 /*F. : This is from then lim factor that depends all periodicity check spped :
    the bigger it is, the faster we can detect periodicity, but the bigger it is,
    the more we can introduce errors. I suggest a value of
    (maxx-minx)/(double)getmaxx for a classic Mandelbrot Set, and maybe a lesser
-   value for an extra power Mandelbrot. But this should be calculated outter
-   from here (ie each frame, for example), to avoid new calculs */
+   value for an extra power Mandelbrot. But this should be calculated outer
+   from here (ie each frame, for example), to avoid new calculus */
 #ifdef PERI
 #define PCHECK                                                                 \
     (abs_less_than(r1 - zre, cfractalc.periodicity_limit) &&                   \
@@ -333,7 +333,7 @@ static unsigned int PERI(number_t zre, number_t zim, number_t pre, number_t pim)
             iter -= 8;
             r1 = zre;
             s1 = zim;
-            whensavenew = 3; /*You should adapt theese values */
+            whensavenew = 3; /*You should adapt these values */
             /*F. : We should always define whensavenew as 2^N-1, so we could use
              * a AND instead of % */
 
@@ -432,7 +432,7 @@ static unsigned int PERI(number_t zre, number_t zim, number_t pre, number_t pim)
                iter--;
                } */
         } else {
-            whensavenew = 7; /*You should adapt theese values */
+            whensavenew = 7; /*You should adapt these values */
             /*F. : We should always define whensavenew as 2^N-1, so we could use
              * a AND instead of % */
 

src/engine/filter.cpp

@@ -103,7 +103,7 @@ int reqimage(struct filter *f, struct requirements *req, int supportedmask,
  * requirements. So it should share image, create image that shares image data
  * or create new image)
  *
- * fills f->image, f->childimage and returns 1 if sucess and 0 if fail(usually
+ * fills f->image, f->childimage and returns 1 if success and 0 if fail(usually
  * out of memory or it is unable to fit child's requirements)
  * and prepares data for child call.
  */
@@ -134,7 +134,7 @@ int inherimage(struct filter *f, struct initdata *data, int flags, int width,
     if (!(palette->type & f->req.supportedmask)) {
 #ifdef DEBUG
         printf(
-            "Initalization of filter %s failed due to unsupported type by child %s-%i,%i\n",
+            "Initialization of filter %s failed due to unsupported type by child %s-%i,%i\n",
             f->name, f->previous->name, f->req.supportedmask, palette->type);
 #endif
         f->image = data->image;
@@ -155,12 +155,12 @@ int inherimage(struct filter *f, struct initdata *data, int flags, int width,
         newimage = 1, sharedimage = 0;
 
     if (f->childimage != NULL && (f->flags & ALLOCEDIMAGE)) {
-        /*is an old child image still useable for us purposes? if not burn it
+        /*is an old child image still usable for us purposes? if not burn it
          * it! */
         /*We should share image? Why alloc new?? */
         if (!newimage && (f->flags & ALLOCEDIMAGE))
             destroyinheredimage(f), ddatalost = 1;
-        /*We should share data? but child image dont do that! */
+        /*We should share data? but child image don't do that! */
         if (subimage && !(f->flags & SHAREDDATA))
             destroyinheredimage(f), ddatalost = 1;
         /*We can't share data but child image does that? */

src/engine/formulas.cpp

@@ -21,11 +21,11 @@
  */
 /* Hello reader!
  * code you are looking at is dangerous for both you and your hardware! PLEASE
- * CLOSE THIS FILE UNLESS YOU REALY KNOW WHAT YOU ARE DOING.
+ * CLOSE THIS FILE UNLESS YOU REALLY KNOW WHAT YOU ARE DOING.
  *
  * Main purpose of this file is to generate optimal caluclation loops for
  * various formulas/algorithms. It heavily includes docalc.c - set of
- * caluclation loops, that then uses macros instad of formulas. This lets me
+ * caluclation loops, that then uses macros instead of formulas. This lets me
  * to change calculation loops easily. At the other hand it looks very ugly.
  * You have been warned :)
  */

src/engine/fractal.cpp

@@ -170,7 +170,7 @@ void set_fractalc(fractal_context *context, struct image *img)
 {
     update_view(context);
     precalculate_rotation(context);
-    cfractalc = *context; /*its better to copy often accesed data into fixed
+    cfractalc = *context; /*its better to copy often accessed data into fixed
                              memory locations */
     cpalette = *img->palette;
     cimage = *img;

src/engine/star.cpp

@@ -13,7 +13,7 @@ struct starfielddata {
 static unsigned int state;
 static inline void mysrandom(unsigned int x) { state = x; }
 
-#define MYLONG_MAX 0xffffff /*this is enought for me. */
+#define MYLONG_MAX 0xffffff /*this is enough for me. */
 static inline unsigned int myrandom(void)
 {
     state = ((state * 1103515245) + 12345) & MYLONG_MAX;