Merge remote-tracking branch 'origin/master' into gsoc2012-scilab

Doc/Manual/Contents.html

@@ -1528,9 +1528,9 @@
 <li><a href="Ruby.html#Ruby_Placement_of_typemaps">Placement of typemaps</a>
 <li><a href="Ruby.html#Ruby_nn39">Ruby typemaps</a>
 <ul>
-<li><a href="Ruby.html#Ruby_in_typemap">&nbsp;"in" typemap</a>
+<li><a href="Ruby.html#Ruby_in_typemap">"in" typemap</a>
 <li><a href="Ruby.html#Ruby_typecheck_typemap">"typecheck" typemap</a>
-<li><a href="Ruby.html#Ruby_out_typemap">&nbsp;"out" typemap</a>
+<li><a href="Ruby.html#Ruby_out_typemap">"out" typemap</a>
 <li><a href="Ruby.html#Ruby_arginit_typemap">"arginit" typemap</a>
 <li><a href="Ruby.html#Ruby_default_typemap">"default" typemap</a>
 <li><a href="Ruby.html#Ruby_check_typemap">"check" typemap</a>

Doc/Manual/Python.html

@@ -795,7 +795,9 @@ If you need to build it on your own, the following notes are provided:
 You will need to create a DLL that can be loaded into the interpreter. 
 This section briefly describes the use of SWIG with Microsoft Visual
 C++.   As a starting point, many of SWIG's examples include project
-files.  You might want to take a quick look at these in addition to
+files (.dsp files) for Visual C++ 6. These can be opened by more 
+recent versions of Visual Studio.
+You might want to take a quick look at these examples in addition to
 reading this section.
 </p>
 
@@ -868,6 +870,24 @@ set of Win32 debug or thread libraries.  You will have to fiddle around with
 the build options of project to try and track this down.
 </p>
 
+<p>
+A 'Debug' build of the wrappers requires a debug build of the Python interpreter.
+This normally requires building the Python interpreter from source, which is not a
+job for the feint-hearted. Alternatively you can use the 'Release' build of the
+Python interpreter with a 'Debug' build of your wrappers by defining the <tt>SWIG_PYTHON_INTERPRETER_NO_DEBUG</tt>
+symbol under the preprocessor options. Or you can ensure this macro is defined at the beginning
+of the wrapper code using the following in your interface file, where <tt>_MSC_VER</tt> ensures it is
+only used by the Visual Studio compiler:
+</p>
+
+<div class="code"><pre>
+%begin %{
+#ifdef _MSC_VER
+#define SWIG_PYTHON_INTERPRETER_NO_DEBUG
+#endif
+%}
+</pre></div>
+
 <p>
 Some users have reported success in building extension modules using Cygwin
 and other compilers.  However, the problem of building usable DLLs with these
@@ -3294,6 +3314,53 @@ what can be done without having to rely on any of the more advanced
 customization features.
 </p>
 
+<p>
+There is also <tt>%pythonbegin</tt> which is another directive very similar to <tt>%pythoncode</tt>,
+but generates the given Python code at the beginning of the <tt>.py</tt> file.
+This directive works in the same way as <tt>%pythoncode</tt>, except the code is copied
+just after the SWIG banner (comment) at the top of the file, before any real code.
+This provides an opportunity to add your own description in a comment near the top of the file as well
+as Python imports that have to appear at the top of the file, such as "<tt>from __future__ import</tt>"
+statements.
+</p>
+
+<p>
+The following shows example usage for Python 2.6 to use <tt>print</tt> as it can in Python 3, that is, as a function instead of a statement:
+</p>
+
+<div class="code">
+<pre>
+%pythonbegin %{
+# This module provides wrappers to the Whizz Bang library
+%}
+
+%pythonbegin %{
+from __future__ import print_function
+print("Loading", "Whizz", "Bang", sep=' ... ')
+%}
+</pre>
+</div>
+
+<p>
+which can be seen when viewing the first few lines of the generated <tt>.py</tt> file:
+</p>
+
+<div class="code">
+<pre>
+# This file was automatically generated by SWIG (http://www.swig.org).
+# Version 2.0.11
+#
+# Do not make changes to this file unless you know what you are doing--modify
+# the SWIG interface file instead.
+
+# This module provides wrappers to the Whizz Bang library
+
+from __future__ import print_function
+print("Loading", "Whizz", "Bang", sep=' ... ')
+
+</pre>
+</div>
+
 <p>Sometimes you may want to replace or modify the wrapper function
 that SWIG creates in the proxy <tt>.py</tt> file.  The Python module
 in SWIG provides some features that enable you to do this.  First, to

Doc/Manual/SWIGPlus.html

@@ -4433,7 +4433,7 @@ around some other class.  For example:
 template<class T> class SmartPtr {
     T *pointee;
 public:
-    ...
+    SmartPtr(T *p) : pointee(p) { ... }
     T *operator->() {
         return pointee;
     }
@@ -4453,7 +4453,7 @@ typedef SmartPtr<Foo_Impl> Foo;
 
 // Create smart pointer Foo
 Foo make_Foo() {
-    return SmartPtr(new Foo_Impl());
+    return SmartPtr<Foo_Impl>(new Foo_Impl());
 }
 
 // Do something with smart pointer Foo
@@ -4461,6 +4461,9 @@ void do_something(Foo f) {
     printf("x = %d\n", f->x);
     f->bar();
 }
+
+// Call the wrapped smart pointer proxy class in the target language 'Foo'
+%template(Foo) SmartPtr<Foo_Impl>;
 </pre>
 </div>
 

Doc/Manual/Windows.html

@@ -147,7 +147,7 @@ PERL5_LIB: D:\nsPerl5.004_04\lib\CORE\perl.lib<br>
 
 
 <p>
-<b><tt>PYTHON_INCLUDE</tt></b> : Set this to the directory that contains python.h<br>
+<b><tt>PYTHON_INCLUDE</tt></b> : Set this to the directory that contains Python.h<br>
 <b><tt>PYTHON_LIB</tt></b> : Set this to the python library including path for linking<p>
 Example using Python 2.1.1:<br>
 <tt>