Run the docs through a spell checker. I usually use an editor that doesn't have one.

10 files changed, 33 insertions, 33 deletions

diff --git a/README b/README
index 22bc899..a162e64 100644
--- a/README
+++ b/README
@@ -41,7 +41,7 @@ virtual worlds you can program a bare cube to act like a car that you
 sit on and drive, the rest is mostly for looks.
 
 There's no such thing as virtual wind in your hair, or smog in your
-nostrils, but if that eventualy gets invented, a generic virtual world
+nostrils, but if that eventually gets invented, a generic virtual world
 system should be able to hook into it easily enough.
 
 Generic.
@@ -57,7 +57,7 @@ philosophy, and you can do almost anything with the usual collection of
 small Unix tools.
 
 So the design of SledjHamr involves lots of little bits of generic code
-that all work together seemlessly.  A major design goal is to be as
+that all work together seamlessly.  A major design goal is to be as
 generic, yet useful, as possible, to support future stuff that hasn't
 been invented yet.  As well as supporting stuff we need to do now.
 
@@ -72,7 +72,7 @@ that computer storage, memory, and CPU power are all very cheap, so why
 bother making things small.  Any long term computer user might have
 noticed that despite our modern computers being many orders of magnitude
 faster and bigger than they where a decade or two ago, everything runs
-slower than it did then.  This proves the falacy of "everything is cheap
+slower than it did then.  This proves the fallacy of "everything is cheap
 and getting cheaper, lets be wasteful" theory.  People are just too
 comfortable with their wasteful habits.  Not to mention that the
 computer industry loves to get every one to throw out their computers
@@ -83,7 +83,7 @@ computers, just to do what it did fine last year.
 Even a small virtual world can use up huge amounts of storage, large
 amounts of memory and CPU power, and large amounts of network bandwidth. 
 This is the problem with simulating worlds, the bits might be small, but
-there's an aweful lot of them.  You can run a busy web site on a $5 per
+there's an awful lot of them.  You can run a busy web site on a $5 per
 month web host, but you need to spend at least $100 per month on a
 hosted server that's powerful enough to run a small OpenSim based
 virtual world.
@@ -102,11 +102,11 @@ Fast.
 Ask any current virtual world user, at least of the types based on SL
 technology, what the number one biggest problem is and they will tell
 you it's lag.  So speed is important to everyone.  Which makes me wonder
-why people use slow bloated things like interpretted scripting languages
+why people use slow bloated things like interpreted scripting languages
 and human readable network protocols / file formats for damn near
 everything?
 
-People use interpretted scripting languages coz it's easy and convenient
+People use interpreted scripting languages coz it's easy and convenient
 for them.  Not so convenient for the user though when it causes more
 lag.  People invent human readable network protocols and file formats
 coz it makes it easy for them to read when they need to debug the
@@ -129,11 +129,11 @@ Once again it's a matter of scale for virtual worlds.  Each part by
 itself might be barely fast enough that people don't notice, but it all
 adds up when you deal with the huge multitude of fiddly little details
 in a virtual world.  Which results in the number one problem being ...
-lag.  Often everything slows down so much it becomens unusable.
+lag.  Often everything slows down so much it becomes unusable.
 
 We can have our cake and eat it to.  So long as the crucial heavily used
 parts of the system that need speed are written efficiently in a
-decently fast language, then we can still use easy interpretted
+decently fast language, then we can still use easy interpreted
 scripting languages for other parts that wont suffer from scaling
 issues.  So long as we stick with efficient binary based network
 protocols and file formats, the tiny percentage of developers that need
@@ -147,7 +147,7 @@ Assembler and C is used for OS kernels, embedded software, and other
 things that need to be efficient.  So C is the major language used for
 SledjHamr.  Bits of assembler might be used if needed.
 
-For the interpretted scripting language of choice used in SledjHamr, I
+For the interpreted scripting language of choice used in SledjHamr, I
 chose Lua.  It's very generic in nature with it's wonderful tables and
 meta tables.  It's tiny, designed to be embedded inside other languages. 
 With the LuaJIT just in time compiler, it's the fastest scripting
@@ -164,7 +164,7 @@ when Apple based their new version of Mac Os X on BSD Unix, the OS wars
 where over.  Everything now is some sort of Unix, except Windows.  Hell,
 iPhones OS is based on Mac OS X, and Android is based on Linux, so even
 the great majority of phones these days are Unix.  Every one is a Unix
-user, wether they know it or not.
+user, whether they know it or not.
 
 Windows makes a nod to being Posix compliant, though it's barely a nod. 
 Cygwin however can be installed on Windows to make it more like the Unix
@@ -253,7 +253,7 @@ Secure.
 -------
 
 One of our developers is a cypherpunk / cryptogeek / whatever term she's
-comfortable being labelled as.  Our team is very privacy focused.  So
+comfortable being labeled as.  Our team is very privacy focused.  So
 security and privacy are important goals as well.  Small modular code is
 better for security, is there is less code to look at to do security
 audits, and less places for things to go wrong, or escape attention. 
@@ -346,7 +346,7 @@ goes against our goals, so expect that to be temporary.  Specifically,
 once we get around to actually implementing the nails protocol stuff,
 some of the Lua network and file formats will get replaced be nails.
 
-The Lua GUI code is losely based on my ancient matrix-RAD stuff that was
+The Lua GUI code is loosely based on my ancient matrix-RAD stuff that was
 written in Java.  The fact that I had most of it working within a week
 is a tribute to how easy Lua is.  The original Java took me years to
 write.  On the other hand, I'm not that happy with the syntax of the
@@ -385,7 +385,7 @@ my vote, so I experimented with it.  There was no EFL integration, so I
 had to write some, which wasn't that hard.  A year later, a new version
 of EFL managed to bit rot my EFL/Irrlicht integration, so I fixed that. 
 But now it flickers like crazy.  After much discussion with other EFL
-develpors, and some preliminary work by the Irrlicht developers, an
+developers, and some preliminary work by the Irrlicht developers, an
 experimental version of Irrlicht is underway that might integrate better
 with EFL.  I've not tried it yet, but it was on my TODO.
 
@@ -401,7 +401,7 @@ released, Irrlicht is much more mature.  So Evas_3D only has basic
 stuff, though it's mostly complete basic stuff.  On the other hand, a
 lot of what's missing in Evas_3D I was thinking about rewriting for
 Irrlicht anyway.  So far one major missing bit is Bullet Physics
-intergration, or any other physics engine.  Irrlicht has Bullet, and
+integration, or any other physics engine.  Irrlicht has Bullet, and
 another part of EFL also has Bullet.  I'm hoping the authors of that
 other EFL part get together with the Evas_3D authors and figure
 something out.
@@ -428,7 +428,7 @@ extantz
             or even just different camera views
             could use the same thing for generating two views for stereo viewing.
     Nails interface to virtual world backend modules.  Each module converts nails commands to / from it's own network protocol.
-        A SledjHamr grid, which definately should be running independantly, 
+        A SledjHamr grid, which definitely should be running independently, 
             so others can log on and stay on when extantz closes down
             which may be a local or remote grid
             might be part of some other grid (a sim)
@@ -464,7 +464,7 @@ GuiLua
 
 Edje Lua
     Lua embedded in edje files, and sandboxed to them.
-    add table marshalling into an edje message
+    add table marshaling into an edje message
     add host proggy supplied Lua functions
         So we can add nails.foo(), GuiLua.foo(), and maybe even LSL.foo().
             All users of GuiLua and nails probably want to be sandboxed, the scripts should be loaded up by extantz, OpenSim, or SledjHamr, not run from the operating system.
diff --git a/docs/ClientHamr/README.GuiLua b/docs/ClientHamr/README.GuiLua
index f60d7b2..72f13f3 100644
--- a/docs/ClientHamr/README.GuiLua
+++ b/docs/ClientHamr/README.GuiLua
@@ -97,7 +97,7 @@ something else), then unmarshal the result before sending it back to
 Lua.
 
 The second alternative, which the host app must REALLY request, is for
-the host app to say "I'm REALLY going out of my way to be threadsafe,
+the host app to say "I'm REALLY going out of my way to be thread safe,
 just call me direct".  No edje wrapper function, BUT the host app still
 has to use edje to register this function.
 
@@ -568,8 +568,8 @@ Windows with widgets relative to each other.
 Manual association of widgets to methods.
 Can include tool tip string, enabled, visible, hover cursor, bounding rectangle?, mouse opaque?, tab groups, font (name, size, style, and alignment).
     More stuff, typically hidden in the OO somewhere.  sigh
-Generally uses fixed image and colour names, which skins overide.
-Skins can also overide the XML files.
+Generally uses fixed image and colour names, which skins override.
+Skins can also override the XML files.
 Translations provide override XML files that need only override the text bits.
 
 
diff --git a/docs/ClientHamr/README.woMan b/docs/ClientHamr/README.woMan
index 1b3bbe0..990f9c5 100644
--- a/docs/ClientHamr/README.woMan
+++ b/docs/ClientHamr/README.woMan
@@ -25,7 +25,7 @@ viewer is not TPVP (Third Party Viewer Policy, an LL thing) compliant,
 and LL are just more anal than the rest of the universe.
 
 NOTE: since I started this, LL in their *cough* infinite wisdom *cough*,
-decided that support of OpenSIm was a Really Bad Thing, so their viewers
+decided that support of OpenSim was a Really Bad Thing, so their viewers
 are no longer capable of dealing with other grids.  LL have even gone as
 far as try to get other viewers to not support other grids.  As far as
 woMan is concerned, this just means that LL viewers, and viewers that
diff --git a/docs/ClientHamr/ScriptEditor.txt b/docs/ClientHamr/ScriptEditor.txt
index 357793a..28cb6a3 100644
--- a/docs/ClientHamr/ScriptEditor.txt
+++ b/docs/ClientHamr/ScriptEditor.txt
@@ -22,5 +22,5 @@ the command finishes.  Naturally that command could be "vi script.lsl",
 
 Toybox and terminology works under cygwin and Mac OS X.
 
-Rob pulls his finger out and starts putting my editting stuff in toybox
+Rob pulls his finger out and starts putting my editing stuff in toybox
 so I can progress with this.
diff --git a/docs/README.Bookie b/docs/README.Bookie
index 1a49f27..bec4b19 100644
--- a/docs/README.Bookie
+++ b/docs/README.Bookie
@@ -28,6 +28,6 @@ versions of the libraries needed in that.  If not found, it could invoke
 an OS specific method of installing a suitable library.  If that fails,
 it can download a SledjHamr specific version into the SledjHamr
 installed directory.  So it tries to do the right thing first, and
-gradually fallsback to doing the wrong thing like LL does.
+gradually falls back to doing the wrong thing like LL does.
 
 That's the theory, in practice, gonna be a pain.
diff --git a/docs/README.LuaSL b/docs/README.LuaSL
index 69bb45c..ed2ffdd 100644
--- a/docs/README.LuaSL
+++ b/docs/README.LuaSL
@@ -1,7 +1,7 @@
 Refer to - http://www.infinitegrid.org/drupal/content/LuaSL_New_scripting_engine
 
 LuaSL is a Lua based LSL scripting engine that will aim for LSL
-compatability first, then adding Lua extensions.  It aims to replace the
+compatibility first, then adding Lua extensions.  It aims to replace the
 woeful XEngine from OpenSim, and at a later stage, be the basis for a
 client side scripting engine.
 
@@ -38,7 +38,7 @@ future.
 
 THIS IS WHERE WE ARE RIGHT NOW.
 
-Should implement embedded Lua somehow.  Probaly the best thing to do is
+Should implement embedded Lua somehow.  Probably the best thing to do is
 to have comments like -
 
 //Lua: local t = {1, 3, 42, x='something', 'something else}
@@ -55,7 +55,7 @@ Incoming commands invoke LSL events via the LuaSL state metatable.  LL
 and OS functions that impact the world will be converted to nails
 commands sent to the command pump.
 
-Initialy, since this is the first thing being written, a nails command
+Initially, since this is the first thing being written, a nails command
 pump client needs to be installed into OpenSim's C# stuff.  Though it
 might be possible to talk directly to ROBUST instead.  Think I'll try
 the ROBUST route, see how far I can get.  That's the general principle
diff --git a/docs/README.REST b/docs/README.REST
index 2981827..0d773f8 100644
--- a/docs/README.REST
+++ b/docs/README.REST
@@ -1,2 +1,2 @@
-REST is probaly good to apply to the web server part.  Alice wants JSON
+REST is probably good to apply to the web server part.  Alice wants JSON
 to, but see nails.
diff --git a/docs/The_Naminator.txt b/docs/The_Naminator.txt
index 3465d44..8a6a25e 100644
--- a/docs/The_Naminator.txt
+++ b/docs/The_Naminator.txt
@@ -6,7 +6,7 @@ and URLs, so the names have to be munged accordingly.  A further issue
 is that different in world objects can have the same name.  Lots of
 copies of the same thing, or two different things that happen to be
 called the same thing.  No one is gonna individually name each tree in a
-forest, or every lampost in the city.  File names and URLs have to be
+forest, or every lamppost in the city.  File names and URLs have to be
 unique.  The Naminator deals with munging names to deal with these
 issues.  It should generate names that are compatible with a variety of
 operating and file systems, as well as being URL compatible.  This is
diff --git a/docs/love.txt b/docs/love.txt
index e21b18b..d95dc30 100644
--- a/docs/love.txt
+++ b/docs/love.txt
@@ -57,7 +57,7 @@ the major amounts of web infrastructure that already exists and already
 solves most of the problems that currently plague virtual worlds based
 on SL tech.
 
-The down side of separated is that changes might be slower propogating
+The down side of separated is that changes might be slower propagating
 to the web server, and there might be two copies of any given set of
 assets in memory at once.
 
@@ -127,7 +127,7 @@ inspired by git using SHA-1 hashes for content addressable assets.
 SHA-1 hashes are 40 character hex codes representing 160 bit numbers
 that are calculated based on the content.  So the same content will give
 the same SHA-1 hash.  Git has proved that you only need the first digits
-of the SHA-1 hash to ensure uniqueness, so it's feasable to use only the
+of the SHA-1 hash to ensure uniqueness, so it's feasible to use only the
 first 128 bits of SHA-1 hashes to squeeze it into a UUID for the
 purposes of uniquely identifying assets.  Precisely what git does.  This
 means it could be backwards compatible with LL's use of UUIDs.
diff --git a/docs/portals.txt b/docs/portals.txt
index c2ba0a1..d54c235 100644
--- a/docs/portals.txt
+++ b/docs/portals.txt
@@ -3,7 +3,7 @@ SledjHamrs killer feature, or one of them.
 A major reason for SledjHamr is to break down the garden walls.  We do
 this by allowing free travel between peoples virtual worlds.  In OpenSim
 this is done by HyperGrid, which is clunky and hard to use.  Second Life
-deliberatly has no such system.  Even worse, it's hard convincing people
+deliberately has no such system.  Even worse, it's hard convincing people
 in SL to visit your grid, coz it's all very hard, again due to
 deliberate policy decisions by LL.  LL knows their content is the key to
 their business, even though almost all of it was created by the users,
@@ -31,7 +31,7 @@ using OpenSim and its HyperGrid system.  Later it would be SledjHamr
 style worlds as well.
 
 A portal would be like Cobalt style portals, you can see the destination
-in real time, and step through it to go there.  They can be permenant,
+in real time, and step through it to go there.  They can be permanent,
 or temporary.  You can carry them in your inventory, they could just be
 normal scripted in world objects.
 
@@ -46,7 +46,7 @@ rez it anywhere.  Or you could rez this portal object in the world you
 are in.  Either way, once the portal is in a world, it connects to your
 home world, showing a view of your front gate, maybe including your
 lovely garden in your front yard.  The portal connects to the "front
-gate" of your homeworld.
+gate" of your home world.
 
 Any one on your home worlds access list can step through this portal to
 get to your home world.  Simple to use, no figuring out HyperGate URLs
@@ -59,7 +59,7 @@ Portals rezzed in world could be temporary, and vanish after who ever
 you invited to come stepped through it.  Or time out several minutes
 later so as not to clutter the universe with left over portals.  Or
 deleted by the owner / managers of the world you left them, or deleted
-yourself from your own world.  Portals could be permenant.  Say you
+yourself from your own world.  Portals could be permanent.  Say you
 found a larger world that you and the owner decide you wish to be a part
 of.  Portals could be left on both worlds linking them.  The "portal"
 could just be reconfiguring each world to locate the other world near