Misc. typos

found via `codespell` and `grep`
This commit is contained in:
luz.paz 2018-05-14 11:00:52 -04:00 committed by luz paz
commit 60dfa31a67
90 changed files with 155 additions and 155 deletions

View file

@ -236,7 +236,7 @@ The following functions can be used to help debug SWIG parse trees.
<blockquote>
Prints the tag-structure of the parse tree to standard output. <tt>node</tt> is the top-level parse tree node. <tt>prefix</tt> is
a string prefix thats added to the start of each line. Normally, you would specify the empty string or NIL for <tt>prefix</tt>.
a string prefix that's added to the start of each line. Normally, you would specify the empty string or NIL for <tt>prefix</tt>.
This function is called by the <tt>-debug-tags</tt> option to SWIG.
<pre>

View file

@ -610,7 +610,7 @@ char *xxx();
<p>
In the case of overloaded functions, mulitple layers are
In the case of overloaded functions, multiple layers are
generated. First, all the overloads for a given name are separated
out into groups based on arity, and are wrapped in
defmethods. Each method calls a distinct wrapper function, but are
@ -1239,7 +1239,7 @@ int zzz(A *inst = 0); /* return inst-&gt;x + inst-&gt;y */
We resolve this issue, by noting synonym relationships between
types while generating the interface. A Primary type is selected
(more on this below) from the candidate list of synonyms. For
all other synonyms, intead of generating a distinct CLOS class
all other synonyms, instead of generating a distinct CLOS class
definition, we generate a form that expands to:
</p>
<div class="targetlang">

View file

@ -1989,7 +1989,7 @@ and more or less equivalent usage from C#
<p>
The C++ code will always print out 20, but the value printed out may not be this in the C# equivalent code.
In order to understand why, consider a garbage collection occuring...
In order to understand why, consider a garbage collection occurring...
</p>
<div class="code">
@ -2141,7 +2141,7 @@ The <tt>CDate &amp;</tt> and <tt>const CDate &amp;</tt> C# code is generated fro
<p>
where '$csclassname' is translated into the proxy class name, <tt>CDate</tt> and '$csinput' is translated into the name of the parameter, eg <tt>dateIn</tt>.
From C#, the intention is then to call into a modifed API with something like:
From C#, the intention is then to call into a modified API with something like:
</p>
<div class="code">

View file

@ -1853,7 +1853,7 @@
</ul>
<li><a href="Scilab.html#Scilab_wrapping_pointers">Pointers</a>
<ul>
<li><a href="Scilab.html#Scilab_wrapping_pointers_pointer_adresses">Utility functions</a>
<li><a href="Scilab.html#Scilab_wrapping_pointers_pointer_addresses">Utility functions</a>
<li><a href="Scilab.html#Scilab_wrapping_pointers_null_pointers">Null pointers:</a>
</ul>
<li><a href="Scilab.html#Scilab_wrapping_structs">Structures</a>

View file

@ -471,7 +471,7 @@ The most Go idiomatic way to manage the memory for some C++ class is to call
<tt><a href="https://golang.org/doc/effective_go.html#defer">defer</a></tt> of
the <tt>DeleteClassName</tt> call. Using <tt>defer</tt> ensures that the memory
of the C++ object is freed as soon as the function containing the <tt>defer</tt>
statement returns. Furthemore <tt>defer</tt> works great for short-lived
statement returns. Furthermore <tt>defer</tt> works great for short-lived
objects and fits nicely C++'s RAII idiom. Example:
</p>
<div class="code">
@ -512,7 +512,7 @@ func main() {
<p>
Using <tt>defer</tt> has limitations though, especially when it comes to
long-lived C++ objects whichs lifetimes are hard to predict. For such C++
long-lived C++ objects whose lifetimes are hard to predict. For such C++
objects a common technique is to store the C++ object into a Go object, and to
use the Go function <tt>runtime.SetFinalizer</tt> to add a finalizer which frees
the C++ object when the Go object is freed. It is strongly recommended to read
@ -788,7 +788,7 @@ DirectorInterface</tt> are a subset of the public and protected virtual methods
of the C++ class. If the <tt>DirectorInterface</tt> contains a method with a
matching signature to a virtual method of the C++ class then the virtual C++
method will be overwritten with the Go method. As Go doesn't support protected
methods all overriden protected virtual C++ methods will be public in Go.
methods all overridden protected virtual C++ methods will be public in Go.
</p>
<p>
@ -941,7 +941,7 @@ methods of the <tt>FooBarAbstract</tt> C++ class by means of embedding. The
public <tt>FooBarGo</tt> interface type includes the <tt>FooBarAbstract</tt>
interface and hence <tt>FooBarGo</tt> can be used as a drop in replacement for
<tt>FooBarAbstract</tt> while the reverse isn't possible and would raise a
compile time error. Furthemore the constructor and destructor functions <tt>
compile time error. Furthermore the constructor and destructor functions <tt>
NewFooBarGo</tt> and <tt>DeleteFooBarGo</tt> take care of all the director
specifics and to the user the class appears as any other SWIG wrapped C++
class.
@ -1054,7 +1054,7 @@ type overwrittenMethodsOnFooBarAbstract struct {
fb FooBarAbstract
// If additional constructor arguments have been given they are typically
// stored here so that the overriden methods can use them.
// stored here so that the overridden methods can use them.
}
func (om *overwrittenMethodsOnFooBarAbstract) Foo() string {
@ -1081,7 +1081,7 @@ func NewFooBarGo() FooBarGo {
// The memory of the FooBarAbstract director object instance can be
// automatically freed once the FooBarGo instance is garbage collected by
// uncommenting the following line. Please make sure to understand the
// runtime.SetFinalizer specific gotchas before doing this. Furthemore
// runtime.SetFinalizer specific gotchas before doing this. Furthermore
// DeleteFooBarGo should be deleted if a finalizer is in use or the fooBarGo
// struct needs additional data to prevent double deletion.
// runtime.SetFinalizer(fbgs, FooBarGo.deleteFooBarAbstract)

View file

@ -4029,7 +4029,7 @@ write handlers for a large number of methods will require
repetitive duplication of the <code>director:except</code> feature code
for each director method.
To mitigate this, a second approach is provided via typemaps in a
fashion analagous to
fashion analogous to
the <a href="Typemaps.html#throws_typemap">"throws" typemap</a>.
The "throws" typemap provides a way to map all the C++
exceptions listed in a method's defined exceptions (either from
@ -8455,7 +8455,7 @@ System.out.println("element value: " + container.getElement().getValue());
<p>
The C++ code will always print out 20, but the value printed out may not be this in the Java equivalent code.
In order to understand why, consider a garbage collection occuring...
In order to understand why, consider a garbage collection occurring...
</p>
<div class="code">
@ -8597,7 +8597,7 @@ The <tt>CDate &amp;</tt> and <tt>const CDate &amp;</tt> Java code is generated f
<p>
where '$javaclassname' is translated into the proxy class name, <tt>CDate</tt> and '$javainput' is translated into the name of the parameter, eg <tt>dateIn</tt>.
From Java, the intention is then to call into a modifed API with something like:
From Java, the intention is then to call into a modified API with something like:
</p>
<div class="code">

View file

@ -101,7 +101,7 @@ that era had a component &gt; 99. For example:</p>
<pre>
$ swig -c++ -javascript -v8 -DV8_VERSION=0x032530 example.i</pre>
</div>
<p>If you're targetting V8 &gt;= 4.3.0, you would just run swig like so:</p>
<p>If you're targeting V8 &gt;= 4.3.0, you would just run swig like so:</p>
<div class="shell">
<pre>
$ swig -c++ -javascript -v8 example.i</pre>

View file

@ -364,7 +364,7 @@ a number of packages to be installed. Full instructions at
<p>
SWIG is known to work on various flavors of OS X. Follow the Unix installation
instructions above. However, as of this writing, there is still great deal of
inconsistency with how shared libaries are handled by various scripting languages
inconsistency with how shared libraries are handled by various scripting languages
on OS X.
</p>

View file

@ -6217,8 +6217,8 @@ they treat it affects how the pure Python module will be able to
locate the C module.
</p>
<p>The details concerning this are covered completly in the documentation
for Python itself. Links to the relavent sections follow:
<p>The details concerning this are covered completely in the documentation
for Python itself. Links to the relevant sections follow:
</p>
<ul>

View file

@ -39,7 +39,7 @@
</ul>
<li><a href="#Scilab_wrapping_pointers">Pointers</a>
<ul>
<li><a href="#Scilab_wrapping_pointers_pointer_adresses">Utility functions</a>
<li><a href="#Scilab_wrapping_pointers_pointer_addresses">Utility functions</a>
<li><a href="#Scilab_wrapping_pointers_null_pointers">Null pointers:</a>
</ul>
<li><a href="#Scilab_wrapping_structs">Structures</a>
@ -92,7 +92,7 @@ This chapter explains how to use SWIG for Scilab. After this introduction, you s
<p>
SWIG for Scilab supports Linux. Other operating sytems haven't been tested.
SWIG for Scilab supports Linux. Other operating systems haven't been tested.
</p>
<p>
@ -337,7 +337,7 @@ There are a few exceptions, such as constants and enumerations, which can be wra
<p>
In Scilab 5.x, identifier names are composed of 24 characters maximum (this limitation disappears from Scilab 6.0 onwards).
<br>By default, variable, member, and function names longer than 24 charaters are truncated, and a warning is produced for each truncation.
<br>By default, variable, member, and function names longer than 24 characters are truncated, and a warning is produced for each truncation.
</p>
<p>This can cause ambiguities, especially when wrapping structs/classes, for which the wrapped function name is composed of the struct/class name and field names.
In these cases, the <a href="SWIG.html#SWIG_rename_ignore">%rename directive</a> can be used to choose a different Scilab name.
@ -765,7 +765,7 @@ typedef enum { RED, BLUE, GREEN } color;
Pointers are supported by SWIG. A pointer can be returned from a wrapped C/C++ function, stored in a Scilab variable, and used in input argument of another C/C++ function.
</p>
<p>
Also, thanks to the SWIG runtime which stores informations about types, pointer types are tracked between exchanges Scilab and the native code. Indeed pointer types are stored alongside the pointer adress.
Also, thanks to the SWIG runtime which stores information about types, pointer types are tracked between exchanges Scilab and the native code. Indeed pointer types are stored alongside the pointer address.
A pointer is mapped to a Scilab structure (<a href="https://help.scilab.org/docs/5.5.2/en_US/tlist.html">tlist</a>), which contains as fields the pointer address and the pointer type (in fact a pointer to the type information structure in the SWIG runtime).
<br>
Why a native pointer is not mapped to a Scilab pointer (type name: "pointer", type ID: 128) ? The big advantage of mapping to a <tt>tlist</tt> is that it exposes a new type for the pointer in Scilab, type which can be acessed in Scilab with the <a href="https://help.scilab.org/docs/5.5.2/en_US/typeof.html">typeof</a> function, and manipulated using the <a href="https://help.scilab.org/docs/5.5.2/en_US/overloading.html">overloading</a> mechanism.
@ -1441,7 +1441,7 @@ void throw_exception() throw(char const *) {
<div class="targetlang"><pre>
--&gt;throw_exception()
!--error 999
SWIG/Scilab: Exception (char const *) occured: Bye world !
SWIG/Scilab: Exception (char const *) occurred: Bye world !
</pre></div>
<p>
@ -1458,7 +1458,7 @@ It can be used with the <tt>lasterror()</tt> function as following:
--&gt; lasterror()
ans =
SWIG/Scilab: Exception (char const *) occured: Bye world !
SWIG/Scilab: Exception (char const *) occurred: Bye world !
</pre></div>
<p>
@ -1488,7 +1488,7 @@ void throw_stl_invalid_arg(int i) throw(std::invalid_argument) {
<div class="targetlang"><pre>
--&gt; throw_int();
!--error 999
SWIG/Scilab: Exception (int) occured: 12
SWIG/Scilab: Exception (int) occurred: 12
--&gt;throw_stl_invalid_arg(-1);
!--error 999