Misc. typos
found via `codespell` and `grep`
This commit is contained in:
parent
3eb41c9beb
commit
60dfa31a67
90 changed files with 155 additions and 155 deletions
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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->x + inst->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">
|
||||
|
|
|
|||
|
|
@ -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 &</tt> and <tt>const CDate &</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">
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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 &</tt> and <tt>const CDate &</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">
|
||||
|
|
|
|||
|
|
@ -101,7 +101,7 @@ that era had a component > 99. For example:</p>
|
|||
<pre>
|
||||
$ swig -c++ -javascript -v8 -DV8_VERSION=0x032530 example.i</pre>
|
||||
</div>
|
||||
<p>If you're targetting V8 >= 4.3.0, you would just run swig like so:</p>
|
||||
<p>If you're targeting V8 >= 4.3.0, you would just run swig like so:</p>
|
||||
<div class="shell">
|
||||
<pre>
|
||||
$ swig -c++ -javascript -v8 example.i</pre>
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
-->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:
|
|||
--> 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>
|
||||
--> throw_int();
|
||||
!--error 999
|
||||
SWIG/Scilab: Exception (int) occured: 12
|
||||
SWIG/Scilab: Exception (int) occurred: 12
|
||||
|
||||
-->throw_stl_invalid_arg(-1);
|
||||
!--error 999
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue