From 7666177682592afe8bbccc722e803aec69dd152b Mon Sep 17 00:00:00 2001 From: David Walter Seikel Date: Wed, 28 May 2014 16:15:21 +1000 Subject: Run the docs through a spell checker. I usually use an editor that doesn't have one. --- README | 32 ++++++++++++++++---------------- docs/ClientHamr/README.GuiLua | 6 +++--- docs/ClientHamr/README.woMan | 2 +- docs/ClientHamr/ScriptEditor.txt | 2 +- docs/README.Bookie | 2 +- docs/README.LuaSL | 6 +++--- docs/README.REST | 2 +- docs/The_Naminator.txt | 2 +- docs/love.txt | 4 ++-- docs/portals.txt | 8 ++++---- 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 -- cgit v1.1