[Mesa-dev] [PATCH] docs: gratuitous spelling pass

Brian Paul brianp at vmware.com
Mon Jan 6 08:59:21 PST 2014


On 01/03/2014 04:44 PM, Nathan Kidd wrote:
> From: Nathan Kidd <nkidd at opentext.com>
>
> Fixed what I noticed; no warranty for exhaustiveness.
>
> Signed-off-by: Nathan Kidd <nkidd at opentext.com>
> ---
>   docs/conform.html    |    2 +-
>   docs/devinfo.html    |    2 +-
>   docs/dispatch.html   |   10 +++++-----
>   docs/egl.html        |    8 ++++----
>   docs/envvars.html    |    6 +++---
>   docs/faq.html        |    8 ++++----
>   docs/opengles.html   |    4 ++--
>   docs/openvg.html     |    2 +-
>   docs/repository.html |    2 +-
>   docs/shading.html    |    2 +-
>   docs/sourcetree.html |    2 +-
>   docs/thanks.html     |    2 +-
>   docs/xlibdriver.html |    2 +-
>   13 files changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/docs/conform.html b/docs/conform.html
> index c5f8ece..5593137 100644
> --- a/docs/conform.html
> +++ b/docs/conform.html
> @@ -19,7 +19,7 @@
>   <p>
>   The SGI OpenGL conformance tests verify correct operation of OpenGL
>   implementations.  I, Brian Paul, have been given a copy of the tests
> -for testing Mesa.  The tests are not publically available.
> +for testing Mesa.  The tests are not publicly available.
>   </p>
>   <p>
>   This file has the latest results of testing Mesa with the OpenGL 1.2
> diff --git a/docs/devinfo.html b/docs/devinfo.html
> index a9d8b4f..d4a6dfb 100644
> --- a/docs/devinfo.html
> +++ b/docs/devinfo.html
> @@ -206,7 +206,7 @@ exclusively for the older branch.
>   This "CC" syntax for patch nomination will cause patches to automatically be
>   copied to the mesa-stable@ mailing list when you use "git send-email" to send
>   patches to the mesa-dev@ mailing list. Also, if you realize that a commit
> -should be nominate for the stable branch after it has already been commited,
> +should be nominated for the stable branch after it has already been committed,
>   you can send a note directly to the mesa-stable at lists.freedesktop.org where
>   the Mesa stable-branch maintainers will receive it. Be sure to mention the
>   commit ID of the commit of interest (as it appears in the mesa master branch).
> diff --git a/docs/dispatch.html b/docs/dispatch.html
> index 4b529bc..aacd01e 100644
> --- a/docs/dispatch.html
> +++ b/docs/dispatch.html
> @@ -25,7 +25,7 @@ href="#overview">overview of Mesa's implementation</a>.</p>
>   <h2>1. Complexity of GL Dispatch</h2>
>
>   <p>Every GL application has at least one object called a GL <em>context</em>.
> -This object, which is an implicit parameter to ever GL function, stores all
> +This object, which is an implicit parameter to every GL function, stores all
>   of the GL related state for the application.  Every texture, every buffer
>   object, every enable, and much, much more is stored in the context.  Since
>   an application can have more than one context, the context to be used is
> @@ -51,7 +51,7 @@ example, <tt>glFogCoordf</tt> may operate differently depending on whether
>   or not fog is enabled.</p>
>
>   <p>In multi-threaded environments, it is possible for each thread to have a
> -differnt GL context current.  This means that poor old <tt>glVertex3fv</tt>
> +different GL context current.  This means that poor old <tt>glVertex3fv</tt>
>   has to know which GL context is current in the thread where it is being
>   called.</p>
>
> @@ -207,13 +207,13 @@ few preprocessor defines.</p>
>   <li>If <tt>GLX_USE_TLS</tt> is defined, method #4 is used.</li>
>   <li>If <tt>HAVE_PTHREAD</tt> is defined, method #3 is used.</li>
>   <li>If <tt>WIN32_THREADS</tt> is defined, method #2 is used.</li>
> -<li>If none of the preceeding are defined, method #1 is used.</li>
> +<li>If none of the preceding are defined, method #1 is used.</li>
>   </ul>
>
>   <p>Two different techniques are used to handle the various different cases.
>   On x86 and SPARC, a macro called <tt>GL_STUB</tt> is used.  In the preamble
>   of the assembly source file different implementations of the macro are
> -selected based on the defined preprocessor variables.  The assmebly code
> +selected based on the defined preprocessor variables.  The assembly code
>   then consists of a series of invocations of the macros such as:
>
>   <blockquote>
> @@ -242,7 +242,7 @@ first technique, is to insert <tt>#ifdef</tt> within the assembly
>   implementation of each function.  This makes the assembly file considerably
>   larger (e.g., 29,332 lines for <tt>glapi_x86-64.S</tt> versus 1,155 lines for
>   <tt>glapi_x86.S</tt>) and causes simple changes to the function
> -implementation to generate many lines of diffs.  Since the assmebly files
> +implementation to generate many lines of diffs.  Since the assembly files
>   are typically generated by scripts (see <a href="#autogen">below</a>), this
>   isn't a significant problem.</p>
>
> diff --git a/docs/egl.html b/docs/egl.html
> index 240cec5..dc23241 100644
> --- a/docs/egl.html
> +++ b/docs/egl.html
> @@ -88,7 +88,7 @@ drivers will be installed to <code>${libdir}/egl</code>.</p>
>   <dd>
>
>   <p>List the platforms (window systems) to support.  Its argument is a comma
> -seprated string such as <code>--with-egl-platforms=x11,drm</code>.  It decides
> +separated string such as <code>--with-egl-platforms=x11,drm</code>.  It decides
>   the platforms a driver may support.  The first listed platform is also used by
>   the main library to decide the native platform: the platform the EGL native
>   types such as <code>EGLNativeDisplayType</code> or
> @@ -223,7 +223,7 @@ the X server directly using (XCB-)DRI2 protocol.</p>
>   <dd>
>
>   <p>This driver is based on Gallium3D.  It supports all rendering APIs and
> -hardwares supported by Gallium3D.  It is the only driver that supports OpenVG.
> +hardware supported by Gallium3D.  It is the only driver that supports OpenVG.
>   The supported platforms are X11, DRM, FBDEV, and GDI.</p>
>
>   <p>This driver comes with its own hardware drivers
> @@ -273,8 +273,8 @@ longer than the display that creates them.</p>
>
>   <p>In EGL, when a display is terminated through <code>eglTerminate</code>, all
>   display resources should be destroyed.  Similarly, when a thread is released
> -throught <code>eglReleaseThread</code>, all current display resources should be
> -released.  Another way to destory or release resources is through functions
> +through <code>eglReleaseThread</code>, all current display resources should be
> +released.  Another way to destroy or release resources is through functions
>   such as <code>eglDestroySurface</code> or <code>eglMakeCurrent</code>.</p>
>
>   <p>When a resource that is current to some thread is destroyed, the resource
> diff --git a/docs/envvars.html b/docs/envvars.html
> index 3cc3c80..31d14a4 100644
> --- a/docs/envvars.html
> +++ b/docs/envvars.html
> @@ -47,7 +47,7 @@ sometimes be useful for debugging end-user issues.
>   <li>MESA_NO_SSE - if set, disables Intel SSE optimizations
>   <li>MESA_DEBUG - if set, error messages are printed to stderr.  For example,
>      if the application generates a GL_INVALID_ENUM error, a corresponding error
> -   message indicating where the error occured, and possibly why, will be
> +   message indicating where the error occurred, and possibly why, will be
>      printed to stderr.<br>
>      If the value of MESA_DEBUG is 'FP' floating point arithmetic errors will
>      generate exceptions.
> @@ -201,14 +201,14 @@ See src/mesa/state_tracker/st_debug.c for other options.
>       to stderr
>   <li>SOFTPIPE_NO_RAST - if set, rasterization is no-op'd.  For profiling purposes.
>   <li>SOFTPIPE_USE_LLVM - if set, the softpipe driver will try to use LLVM JIT for
> -    vertex shading procesing.
> +    vertex shading processing.
>   </ul>
>
>
>   <h3>LLVMpipe driver environment variables</h3>
>   <ul>
>   <li>LP_NO_RAST - if set LLVMpipe will no-op rasterization
> -<li>LP_DEBUG - a comma-separated list of debug options is acceptec.  See the
> +<li>LP_DEBUG - a comma-separated list of debug options is accepted.  See the
>       source code for details.
>   <li>LP_PERF - a comma-separated list of options to selectively no-op various
>       parts of the driver.  See the source code for details.
> diff --git a/docs/faq.html b/docs/faq.html
> index 97c59d3..d4037e8 100644
> --- a/docs/faq.html
> +++ b/docs/faq.html
> @@ -137,7 +137,7 @@ Just follow the Mesa <a href="install.html">compilation instructions</a>.
>   <h2>1.6 Are there other open-source implementations of OpenGL?</h2>
>   <p>
>   Yes, SGI's <a href="http://oss.sgi.com/projects/ogl-sample/index.html">
> -OpenGL Sample Implemenation (SI)</a> is available.
> +OpenGL Sample Implementation (SI)</a> is available.
>   The SI was written during the time that OpenGL was originally designed.
>   Unfortunately, development of the SI has stagnated.
>   Mesa is much more up to date with modern features and extensions.
> @@ -353,7 +353,7 @@ That's where Mesa development is discussed.
>   </p>
>   <p>
>   The <a href="http://www.opengl.org/documentation">
> -OpenGL Specification</a> is the bible for OpenGL implemention work.
> +OpenGL Specification</a> is the bible for OpenGL implementation work.
>   You should read it.
>   </p>
>   <p>Most of the Mesa development work involves implementing new OpenGL
> @@ -375,7 +375,7 @@ For a Gallium3D hardware driver, the r300g, r600g and the i915g are good example
>   </p>
>   <p>The DRI website has more information about writing hardware drivers.
>   The process isn't well document because the Mesa driver interface changes
> -over time, and we seldome have spare time for writing documentation.
> +over time, and we seldom have spare time for writing documentation.
>   That being said, many people have managed to figure out the process.
>   </p>
>   <p>
> @@ -390,7 +390,7 @@ The <a href="http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compres
>   indicates that there are intellectual property (IP) and/or patent issues
>   to be dealt with.
>   </p>
> -<p>We've been unsucessful in getting a response from S3 (or whoever owns
> +<p>We've been unsuccessful in getting a response from S3 (or whoever owns
>   the IP nowadays) to indicate whether or not an open source project can
>   implement the extension (specifically the compression/decompression
>   algorithms).
> diff --git a/docs/opengles.html b/docs/opengles.html
> index f08acb5..24ad69f 100644
> --- a/docs/opengles.html
> +++ b/docs/opengles.html
> @@ -16,7 +16,7 @@
>
>   <h1>OpenGL ES</h1>
>
> -<p>Mesa implements OpenGL ES 1.1 and OpenGL ES 2.0.  More informations about
> +<p>Mesa implements OpenGL ES 1.1 and OpenGL ES 2.0.  More information about
>   OpenGL ES can be found at <a href="http://www.khronos.org/opengles/">
>   http://www.khronos.org/opengles/</a>.</p>
>
> @@ -48,7 +48,7 @@ EGL drivers for your hardware.</p>
>
>   <h3>Dispatch Table</h3>
>
> -<p>OpenGL ES has an additional indirection when dispatching fucntions</p>
> +<p>OpenGL ES has an additional indirection when dispatching functions</p>
>
>   <pre>
>     Mesa:       glFoo() --> _mesa_Foo()
> diff --git a/docs/openvg.html b/docs/openvg.html
> index 5bc866a..28ebb82 100644
> --- a/docs/openvg.html
> +++ b/docs/openvg.html
> @@ -20,7 +20,7 @@
>   The current version of the OpenVG state tracker implements OpenVG 1.1.
>   </p>
>   <p>
> -More informations about OpenVG can be found at
> +More information about OpenVG can be found at
>   <a href="http://www.khronos.org/openvg/">
>   http://www.khronos.org/openvg/</a> .
>   </p>
> diff --git a/docs/repository.html b/docs/repository.html
> index 510f438..bb0ae00 100644
> --- a/docs/repository.html
> +++ b/docs/repository.html
> @@ -156,7 +156,7 @@ each time you do a pull.
>   </p>
>   <li>Small changes to master
>   <p>
> -If you are an experienced git user working on substancial modifications,
> +If you are an experienced git user working on substantial modifications,
>   you are probably
>   working on a separate branch and would rebase your branch prior to
>   merging with master.
> diff --git a/docs/shading.html b/docs/shading.html
> index 4015cdf..77a0ee4 100644
> --- a/docs/shading.html
> +++ b/docs/shading.html
> @@ -234,7 +234,7 @@ This option is only relevant if EmitHighLevelInstructions is set.
>
>   <dt>EmitComments</dt>
>   <dd>
> -If set, instructions will be annoted with comments to help with debugging.
> +If set, instructions will be annotated with comments to help with debugging.
>   Extra NOP instructions will also be inserted.
>   </dd>
>   </dl>
> diff --git a/docs/sourcetree.html b/docs/sourcetree.html
> index a6868d3..4c93f63 100644
> --- a/docs/sourcetree.html
> +++ b/docs/sourcetree.html
> @@ -123,7 +123,7 @@ each directory.
>             Currently there's run-time code generation for x86/SSE, PowerPC
>             and Cell SPU.
>         <li><b>tgsi</b> - TG Shader Infrastructure.  Code for encoding,
> -          manipulating and interpretting GPU programs.
> +          manipulating and interpreting GPU programs.
>         <li><b>translate</b> - module for translating vertex data from one format
>             to another.
>         <li><b>util</b> - assorted utilities for arithmetic, hashing, surface
> diff --git a/docs/thanks.html b/docs/thanks.html
> index 4ec92d3..29a41e4 100644
> --- a/docs/thanks.html
> +++ b/docs/thanks.html
> @@ -14,7 +14,7 @@
>   <iframe src="contents.html"></iframe>
>   <div class="content">
>
> -<h1>Acknowledgments</h1>
> +<h1>Acknowledgements</h1>
>
>
>   The following individuals and groups are to be acknowledged for their
> diff --git a/docs/xlibdriver.html b/docs/xlibdriver.html
> index ce1ff3b..d3d8ab4 100644
> --- a/docs/xlibdriver.html
> +++ b/docs/xlibdriver.html
> @@ -107,7 +107,7 @@ for your application.
>   <p>
>   When using Mesa directly or with GLX, it's up to the application
>   writer to create a window with an appropriate colormap.  The GLUT
> -toolkit tris to minimize colormap <em>flashing</em> by sharing
> +toolkit tries to minimize colormap <em>flashing</em> by sharing
>   colormaps when possible.  Specifically, if the visual and depth of the
>   window matches that of the root window, the root window's colormap
>   will be shared by the Mesa window.  Otherwise, a new, private colormap
>

Reviewed-by: Brian Paul <brianp at vmware.com>

Thanks.  I'll push this soon.

-Brian



More information about the mesa-dev mailing list