diff --git a/SWIG/Doc/Manual/Guile.html b/SWIG/Doc/Manual/Guile.html index 124680be8..7d2d5be60 100644 --- a/SWIG/Doc/Manual/Guile.html +++ b/SWIG/Doc/Manual/Guile.html @@ -168,7 +168,10 @@ following module-system hack:

SWIG can also generate this Scheme stub (from define-module up to export) semi-automagically if you pass it the command-line argument --scmstub foo.scm. Since SWIG doesn't know how +-scmstub. The code will be exported in a file called +module.scm in the directory specified by -outdir +or the current directory if -outdir is not specified. +Since SWIG doesn't know how to load your extension module (with dynamic-link or load-extension), you need to supply this information by including a directive like this in the interface file: @@ -178,7 +181,7 @@ information by including a directive like this in the interface file: (The %scheme directive allows to insert arbitrary Scheme -code into the generated file foo.scm; it is +code into the generated file module.scm; it is placed between the define-module form and the export form.) @@ -434,7 +437,8 @@ The first word of data is the pointer to the object and the second word of data structure describing this type. This is a lot easier than the GH interface above because we can store a pointer to the type info structure right in the type. With the GH interface, there was not enough room in the smob to store two whole words of data so we needed to store part of the "swig_type_info address" -in the smob tag.

+in the smob tag. If a generated GOOPS module has been loaded, smobs will be wrapped by the corresponding +GOOPS class.

14.6.3 Garbage Collection

@@ -537,7 +541,7 @@ struct members, the procedures (struct-member-get pointer) and (struct-member-set pointer value) are not generated. -

14.10 GOOPS

+

14.10 GOOPS Shadow Classes

SWIG can also generate classes and generic functions for use with Guile's Object-Oriented Programming System (GOOPS). GOOPS is a sophisticated object system in the spirit of the Common Lisp Object @@ -546,10 +550,10 @@ System (CLOS).

GOOPS support is only available with the new SCM interface (enabled with the -scm command-line option of SWIG). To enable GOOPS -support, pass the -goops module.scm command argument to +support, pass the -shadow argument to swig. This will export the GOOPS wrapper definitions into the -module.scm file. GOOPS support requires either passive -or module linkage.

+module.scm file in the directory specified by -outdir or the +current directory. GOOPS support requires either passive or module linkage.

The generated file will contain definitions of GOOPS classes mimicking the C++ class hierarchy.

Enabling GOOPS support implies -emit-setters. @@ -640,7 +644,7 @@ the future the following will be valid (make <Foo> #:a 5 #:b 4) This is a valid SWIG file it will work as you think it will for primitive support, but the generated GOOPS file will be broken. Since the someFunc definition is parsed by SWIG before all the -declerations in foo.h, the generated GOOPS file will contain the definition of someFunc() +declarations in foo.h, the generated GOOPS file will contain the definition of someFunc() before the definition of <Foo>. The generated GOOPS file would look like 

;;...
 
@@ -662,7 +666,7 @@ Notice that <Foo> is used before it is defined.  The fix is to just put th
 
As you can see in the example above, there are potential naming conflicts.  The default exported
 accessor for the Foo::a variable is named a.  The name of the wrapper global 
 function is getFooPlus.
-If the -useclassprefix option is passed to swig, the name of all accesors and member 
+If the -useclassprefix option is passed to swig, the name of all accessors and member 
 functions will be prepended with the class name.  So the accessor will be called Foo-a and 
 the member functions will be called Foo-getMultBy.  Also, if the 
 -goopsprefix goops: argument is passed to swig, every identifier will be prefixed by 
@@ -674,13 +678,16 @@ module) or in the scmstub file (if -Linkage passive -scmstub
 guile-module is the swig-module name (given on the command line with the -module argument or with the 
 %module directive) concatenated with the string "-primitive".  For
 example, if %module Test is set in the swig interface file, the name of the guile-module in 
-the scmstub or -Linkage module will be Test-primitive.  
+the scmstub or -Linkage module will be Test-primitive.  Also, the scmstub
+file will be named Test-primitive.scm.
 The string "primitive" can be changed by the -primsuffix swig
 argument.  So the same interface, with the -primsuffix base will produce a module called 
 Test-base. 
-The second generated guile-module contains all the GOOPS class definitions and is located in whatever 
-file is given with the -goops argument.  The name of this guile-module is the name of the 
-swig-module (given on the command line or with the %module directive).

+The second generated guile-module contains all the GOOPS class definitions and is located in
+a file named module.scm in the directory specified with -outdir or the current directory.
+The name of this guile-module is the name of the
+swig-module (given on the command line or with the %module directive).
+In the previous example, the GOOPS definitions will be in a file named Test.scm.

 
 
Because of the naming conflicts, you can't in general use both the -primitive and the GOOPS 
 guile-modules at the same time.  To do this, you need to rename the exported symbols from one or both 
@@ -726,12 +733,12 @@ Produces the following code at the top of the generated GOOPS guile-module
 Module-primitive.scm (with primitive replaced with whatever is given with the -primsuffix
 argument.  The code to load the .so library should be located in the %scheme directive, 
 which will then be added to the scmstub file.
-Swig will automaticly generate the line (use-modules (Package Module-primitive))
+Swig will automatically generate the line (use-modules (Package Module-primitive))
 into the GOOPS guile-module.  So if Module-primitive.scm is on the autoload path for guile, the
 %goops directive can be empty.  Otherwise, the %goops directive should contain 
 whatever code is needed to load the Module-primitive.scm file into guile.
 
%scheme %{ (load-extension "./foo.so" "scm_init_my_modules_foo_module") %}
-// only include the following definition if (my modules foo) can not be loaded automaticly
+// only include the following definition if (my modules foo) can not be loaded automatically
 %goops %{ 
   (primitive-load "/path/to/foo-primitive.scm") 
   (primitive-load "/path/to/Swig/common.scm")
@@ -750,7 +757,7 @@ Produces the following code at the top of the generated GOOPS guile-module
 

 
 
  • Module Linkage: This is very similar to passive linkage with a scmstub file.
-Swig will also automaticly generate the line (use-modules 
+Swig will also automatically generate the line (use-modules 
 (Package Module-primitive)) into the GOOPS guile-module.  Again the %goops
 directive should contain whatever code is needed to get that module loaded into guile.
    • 
 
    %goops %{ (load-extension "./foo.so" "scm_init_my_modules_foo_module") %}
@@ -780,7 +787,7 @@ SWIG installed, you will need to include the common.swg file along with the inst
 derived from classes in mod1, the generated GOOPS file for mod2 will declare
 the correct superclasses.  The only problem is that since mod2 uses symbols from
 mod1, the mod2 GOOPS file must include a (use-modules (mod2)).
-Currently, SWIG does not automaticlly export this line;  it must be included in the %goops
+Currently, SWIG does not automatically export this line;  it must be included in the %goops
 directive of mod2.  Maybe in the future SWIG can detect dependencies and export this line.
 (how do other language modules handle this problem?)