text:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<title>SWIG and Allegro Common Lisp</title>
<link rel="stylesheet" type="text/css" href="style.css">

18 SWIG and Allegro Common Lisp

Basics

Running SWIG

Command Line Options

Inserting user code into generated files

Wrapping Overview

Function Wrapping

Foreign Wrappers

FFI Wrappers

Non-overloaded Defuns

Overloaded Defuns

What about constant and variable access?

Object Wrapping

Wrapping Details

Namespaces

Constants

Variables

Enumerations

Arrays

Classes and Structs and Unions (oh my!)

CLOS wrapping of

CLOS Inheritance

Member fields and functions

Why not directly access C++ classes using foreign types?

Templates

Generating wrapper code for templates

Implicit Template instantiation

Typedef, Templates, and Synonym Types

Choosing a primary type

Function overloading/Parameter defaulting

Operator wrapping and Operator overloading

Varargs

C++ Exceptions

Pass by value, pass by reference

Typemaps

Code Generation in the C++ Wrapper

IN Typemap

OUT Typemap

CTYPE Typemap

Code generation in Lisp wrappers

LIN Typemap

LOUT Typemap

FFITYPE Typemap

LISPTYPE Typemap

LISPCLASS Typemap

Modifying SWIG behavior using typemaps

Identifier Converter functions

Creating symbols in the lisp environment

Existing identifier-converter functions

identifier-convert-null

identifier-convert-lispify

Default identifier to symbol conversions

Defining your own identifier-converter

Instructing SWIG to use a particular identifier-converter

This chapter describes SWIG's support of Allegro Common Lisp. Allegro
CL is a full-featured implementation of the Common Lisp language
standard that includes many vendor-specific enhancements and add-on
modules for increased usability.

One such module included in Allegro CL is the Foreign Functions
Interface (FFI). This module, tailored primarily toward interfacing
with C/C++ and, historically, Fortran, provides a means by which
compiled foreign code can be loaded into a running lisp
environment and executed. The interface supports the calling of
foreign functions and methods, allows for executing lisp routines
from foreign code (callbacks), and the passing of data between foreign
and lisp code.

The goal of this module is to make it possible to quickly generate the
necessary foreign function definitions so one can make use of C/C++
foreign libraries directly from lisp without the tedium of having to
code them by hand. When necessary, it will also generate further C/C++
code that will need to be linked with the intended library for proper
interfacing from lisp. It has been designed with an eye toward
flexibility. Some foreign function calls may release the heap, while
other should not. Some foreign functions should automatically convert
lisp strings into native strings, while others should not. These
adjustments and many more are possible with the current module.

It is significant to note that, while this is a vendor-specific
module, we would like to acknowledge the current and ongoing
work by developers in the open source lisp community that are
working on similar interfaces to implementation-independent
foreign function interfaces (UFFI or CFFI, for example). Such
work can only benefit the lisp community, and we would not
be unhappy to see some enterprising folk use this work to add
to it.

18.1 Basics

18.1.1 Running SWIG

If you're reading this, you must have some library you need to
generate an interface for. In order for SWIG to do this work, however,
it needs a bit of information about how it should go about creating
your interface, and what you are interfacing to.

SWIG expects a description of what in the foreign interface you wish
to connect to. It must consisting of C/C++ declarations and special
SWIG directives. SWIG can be furnished with a header file, but an
interface can also be generated without library headers by supplying a
simple text file--called the interface file, which is typically named
with a <tt>.i</tt> extension--containing any foreign declarations of
identifiers you wish to use. The most common approach is to use a an
interface file with directives to parse the needed headers. A straight
parse of library headers will result in usable code, but SWIG
directives provides much freedom in how a user might tailor the
generated code to their needs or style of coding.

Note that SWIG does not require any function definitions; the
declarations of those functions is all that is necessary. Be careful
when tuning the interface as it is quite possible to generate code
that will not load or compile.

An example interface file is shown below. It makes use of two SWIG
directives, one of which requests that the declarations in a header
file be used to generate part of the interface, and also includes an
additional declaration to be added.

example.i

%module example

%include "header.h"

int fact(int n);

The contents of header.h are very simple:

header.h

int fact(char *statement);   // pass it a fact, and it will rate it.

The contents of example.cl will look like this:

example.cl

(defpackage :example
  (:use :common-lisp :swig :ff :excl))

  ... helper routines for defining the interface ...

(swig-in-package ())

(swig-defun ("fact")
  ((PARM0_statement cl:string (* :char) ))
  (:returning (:int )
   :strings-convert t)
  (let ((SWIG_arg0 PARM0_statement))
  (swig-ff-call SWIG_arg0)))

(swig-defun ("fact")
  ((PARM0_n cl:integer :int ))
  (:returning (:int )
   :strings-convert t)
  (let ((SWIG_arg0 PARM0_n))
  (swig-ff-call SWIG_arg0)))

(swig-dispatcher ("fact" :type :function :arities (1)))

The generated file contains calls to internal swig helper
functions. In this case there are two calls to swig-defun.
These calls will expand into code that will make the appropriate
definitions using the Allegro FFI. Note also, that this code is
erroneous. Function overloading is not supported in C, and this
code will not compile even though SWIG did not complain.

In order to generate a C interface to Allegro CL using this code run
swig using the <tt>-allegrocl</tt> option, as below:

% swig -allegrocl example.i

When building an interface to C++ code, include the <tt>-c++</tt> option:

% swig -allegrocl -c++ example.i

As a result of running one of the above commands, a file named <tt>example.cl</tt>
will be generated containing the lisp side of the interface. As well, a file
<tt>example_wrap.cxx</tt> is also generated, containing C/C++ wrapper code to
facilitate access to C++ methods, enumeration values, and constant values.
Wrapper functions are necessary in C++ due to the lack of a standard for mangling
the names of symbols across all C++ compilers. These wrapper functions are
exported from the shared library as appropriate, using the C name mangling
convention. The lisp code that is generated will interface to your foreign
library through these wrappers.

It is possible to disable the creation of the .cxx file when generating a C
interface by using the -nocwrap command-line argument. For interfaces that
don't contain complex enum or constant expressions, contain nested struct/union
declarations, or doesn't need to use many of the SWIG customization featuers,
this will result in a more streamlined, direct interface to the
intended module.

The generated wrapper file is below. It contains very simple
wrappers by default, that simply pass the arguments to the
actual function.

example_wrap.i

   ... lots of SWIG internals ...

EXPORT int ACL___fact__SWIG_0 (char *larg1) {
    int lresult = (int)0 ;
    char *arg1 = (char *) 0 ;
    int result;

    arg1 = larg1;
    try {
        result = (int)fact(arg1);

        lresult = result;
        return lresult;
    } catch (...) {
        return (int)0;
    }
}

EXPORT int ACL___fact__SWIG_1 (int larg1) {
    int lresult = (int)0 ;
    int arg1 ;
    int result;

    arg1 = larg1;
    try {
        result = (int)fact(arg1);

        lresult = result;
        return lresult;
    } catch (...) {
        return (int)0;
    }
}

And again, the generated lisp code. Note that it differs from
what is generated when parsing C code:

   ...

(swig-in-package ())

(swig-defmethod ("fact" "ACL___fact__SWIG_0" :type :function :arity 1)
  ((PARM0_statement cl:string (* :char) ))
  (:returning (:int )
   :strings-convert t)
  (let ((SWIG_arg0 PARM0_statement))
  (swig-ff-call SWIG_arg0)))

(swig-defmethod ("fact" "ACL___fact__SWIG_1" :type :function :arity 1)
  ((PARM0_n cl:integer :int ))
  (:returning (:int )
   :strings-convert t)
  (let ((SWIG_arg0 PARM0_n))
  (swig-ff-call SWIG_arg0)))

(swig-dispatcher ("fact" :type :function :arities (1)))

In this case, the interface generates two swig-defmethod forms and
a swig-dispatcher form. This provides a single functional interface for
all overloaded routines. A more detailed description of this features
is to be found in the section titled Function overloading/Parameter defaulting.

In order to load a C++ interface, you will need to build a shared library
from example_wrap.cxx. Be sure to link in the actual library you created
the interface for, as well as any other dependent shared libraries. For
example, if you intend to be able to call back into lisp, you will also
need to link in the Allegro shared library. The library you create from
the C++ wrapper will be what you then load into Allegro CL.

18.1.2 Command Line Options

There are three Allegro CL specific command-line option:

swig -allegrocl [ options ] filename

   -identifier-converter [name] - Binds the variable swig:*swig-identifier-convert*
                                  in the generated .cl file to <tt>name</tt>.
				  This function is used to generate symbols
				  for the lisp side of the interface.

   -cwrap - [default] Generate a .cxx file containing C wrapper function when
            wrapping C code. The interface generated is similar to what is
	    done for C++ code.
   -nocwrap - Explicitly turn off generation of .cxx wrappers for C code. Reasonable
              for modules with simple interfaces. Can not handle all legal enum
	      and constant constructs, or take advantage of SWIG customization features.

   -isolate - With this command-line argument, all lisp helper functions are defined
              in a unique package named <tt>swig.<module-name></tt> rather than
	      <tt>swig</tt>. This prevents conflicts when the module is
	      intended to be used with other swig generated interfaces that may,
	      for instance, make use of different identifier converters.

See Section 17.5 Identifier converter
functions for more details.

18.1.3 Inserting user code into generated files

It is often necessary to include user-defined code into the
automatically generated interface files. For example, when building
a C++ interface, example_wrap.cxx will likely not compile unless
you add a <tt>#include "header.h"</tt> directive. This can be done
using the SWIG <tt>%insert(section) %{ ...code... %}</tt> directive:

%module example

%{
#include "header.h"
%}

%include "header.h"

int fact(int n);

Additional sections have been added for inserting into the
generated lisp interface file

<tt>lisphead</tt> - inserts before type declarations

<tt>lisp</tt> - inserts after type declarations according to
    where it appears in the .i file

Note that the block <tt>%{ ... %}</tt> is effectively a shortcut for
<tt>%insert("header") %{ ... %}</tt>.

18.2 Wrapping Overview

New users to SWIG are encouraged to read
SWIG Basics, and
SWIG and C++, for those
interested in generating an interface to C++.

18.2.1 Function Wrapping

  Writing lisp code that directly invokes functions at the foreign
  function interface level can be cumbersome. Data must often be
  translated between lisp and foreign types, data extracted from
  objects, foreign objects allocated and freed upon completion of
  the foreign call. Dealing with pointers can be unwieldy when it
  comes to keeping them distinct from other valid integer values.

  We make an attempt to ease some of these burdens by making the
  interface to foreign code much more lisp-like, rather than C
  like. How this is done is described in later chapters. The
  layers themselves, appear as follows:

        ______________
       |              |  (foreign side)
       | Foreign Code |  What we're generating an interface to.
       |______________|
               |
	       |
        _______v______
       |              |  (foreign side)
       | Wrapper code |  extern "C" wrappers calling C++
       |______________|  functions and methods.
               |
    .  . . - - + - - . .  .
        _______v______
       |              |  (lisp side)
       |  FFI Layer   |  Low level lisp interface. ff:def-foreign-call,
       |______________|  ff:def-foreign-variable
               |
	       +----------------------------
        _______v______              _______v______
       |              |            |              | (lisp side)
       |    Defuns    |            |  Defmethods  | wrapper for overloaded
       |______________|            |______________| functions or those with
        (lisp side)                        |        defaulted arguments
	Wrapper for non-overloaded         |
	functions and methods       _______v______
	                           |              | (lisp side)
				   |    Defuns    | dispatch function
				   |______________| to overloads based
				                    on arity

18.2.2 Foreign Wrappers

    These wrappers are as generated by SWIG default. The types of
    function parameters can be transformed in place using the CTYPE
    typemap. This is use for converting pass-by-value parameters to
    pass-by-reference where necessary. All wrapper parameters are then
    bound to local variables for possible transformation of values
    (see LIN typemap). Return values can be transformed via the OUT
    typemap.

18.2.3 FFI Wrappers

    These are the generated ff:def-foreign-call forms. No typemaps are
    applicable to this layer, but the <tt>%ffargs</tt> directive is
    available for use in .i files, to specify which keyword arguments
    should be specified for a given function.

ffargs.i:

%module ffargs

%ffargs(strings_convert="nil",call_direct="t") foo;
%ffargs(strings_convert="nil",release_heap=":never",optimize_for_space="t") bar;

int foo(float f1, float f2);
int foo(float f1, char c2);

void bar(void *lisp_fn);

char *xxx();

Generates:

ffargs.cl:

(swig-in-package ())

(swig-defmethod ("foo" "ACL___foo__SWIG_0" :type :function :arity 2)
  ((PARM0_f1 cl:single-float :float )
   (PARM1_f2 cl:single-float :float ))
  (:returning (:int )
   :call-direct t
   :strings-convert nil)
  (let ((SWIG_arg0 PARM0_f1))
  (let ((SWIG_arg1 PARM1_f2))
  (swig-ff-call SWIG_arg0 SWIG_arg1))))

(swig-defmethod ("foo" "ACL___foo__SWIG_1" :type :function :arity 2)
  ((PARM0_f1 cl:single-float :float )
   (PARM1_c2 cl:character :char character))
  (:returning (:int )
   :call-direct t
   :strings-convert nil)
  (let ((SWIG_arg0 PARM0_f1))
  (let ((SWIG_arg1 PARM1_c2))
  (swig-ff-call SWIG_arg0 SWIG_arg1))))

(swig-dispatcher ("foo" :type :function :arities (2)))
(swig-defun ("bar" "ACL___bar__SWIG_0" :type :function)
  ((PARM0_lisp_fn  (* :void) ))
  (:returning (:void )
   :release-heap :never
   :optimize-for-space t
   :strings-convert nil)
  (let ((SWIG_arg0 PARM0_lisp_fn))
  (swig-ff-call SWIG_arg0)))

(swig-defun ("xxx" "ACL___xxx__SWIG_0" :type :function)
  (:void)
  (:returning ((* :char) )
   :strings-convert t)
  (swig-ff-call))

%ffargs(strings_convert="t");

    Is the only default value specified in <tt>allegrocl.swg</tt> to force
    the muffling of warnings about automatic string conversion when defining
    ff:def-foreign-call's.

18.2.4 Non-overloaded Defuns

    These are simple defuns. There is no typechecking of arguments.
    Parameters are bound to local variables for possible
    transformation of values, such as pulling values out of instance
    slots or allocating temporary stack allocated structures, via the
    <tt>lin</tt> typemap. These arguments are then passed to the
    foreign-call (where typechecking may occur). The return value from
    this function can be manipulated via the <tt>lout</tt> typemap.

18.2.5 Overloaded Defuns

    In the case of overloaded functions, mulitple 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
    themselves distinguished by the types of their arguments
    (see <tt>lispclass</tt> typemap). These are further wrapped in a
    dispatching function (defun) which will invoke the appropriate
    generic-function based on arity. This provides a single functional
    interface to all overloads. The return value from this function
    can be manipulated via the <tt>lout</tt> typemap.

18.2.6 What about constant and variable access?

    Along with the described functional layering, when creating a .cxx wrapper,
    this module will generate getter and--if not immutable--setter,
    functions for variables and constants. If the -nocwrap option is used,
    <tt>defconstant</tt> and <tt>ff:def-foreign-variable</tt> forms will be
    generated for accessing constants and global variables. These, along with
    the <tt>defuns</tt> listed above are the intended API for calling
    into the foreign module.

18.2.7 Object Wrapping

  All non-primitive types (Classes, structs, unions, and typedefs
  involving same) have a corresponding foreign-type defined on the
  lisp side via ff:def-foreign-type.

  All non-primitive types are further represented by a CLOS class,
  created via defclass. An attempt is made to create the same class
  hierarchy, with all classes inheriting directly or indirectly from
  ff:foreign-pointer. Further, wherever it is apparent, all pointers
  returned from foreign code are wrapped in a CLOS instance of the
  appropriate class. For ff:def-foreign-calls that have been defined
  to expect a :foreign-address type as argument, these CLOS instances
  can legally be passed and the pointer to the C++ object
  automatically extracted. This is a natural feature of Allegro's
  foreign function interface.

18.3 Wrapping Details

    In this section is described how particular C/C++ constructs are
    translated into lisp.

18.3.1 Namespaces

    C++ namespaces are translated into Lisp packages by SWIG. The
    Global namespace is mapped to a package named by the <tt>%module</tt>
    directive or the <tt>-module</tt> command-line argument. Further
    namespaces are generated by the <tt>swig-defpackage</tt> utility
    function and given names based on Allegro CLs nested namespace
    convention. For example:

foo.i:

%module foo

%{
#include "foo.h"
%}

%include "foo.h"

namespace car {
   ...
   namespace tires {
      int do_something(int n);
   }
}

Generates the following code.

foo.cl

(defpackage :foo
  (:use :common-lisp :swig :ff :excl))

...

(swig-defpackage ("car"))
(swig-defpackage ("car" "tires"))

...

(swig-in-package ("car" "tires"))
(swig-defun ("do_something" "ACL_car_tires__do_something__SWIG_0" :type :function)
  ((PARM0_n  :int ))
  (:returning (:int )
   :strings-convert t)
  (let ((SWIG_arg0 PARM0_n))
  (swig-ff-call SWIG_arg0)))

      The above interface file would cause packages foo, foo.car, and
      foo.car.tires to be created. One would find the function wrapper
      for do_something defined in the foo.car.tires package(*).

(*) Except for the package named by the module, all
      namespace names are passed to the identifier-converter-function
      as strings with a <tt>:type</tt> of <tt>:namespace</tt>. It is the
      job of this function to generate the desired symbol, accounting for
      case preferences, additional naming cues, etc.

      Note that packages created by <tt>swig-defpackage</tt> do not
      use the COMMON-LISP or EXCL package. This reduces possible
      conflicts when defining foreign types via the SWIG interface
      in all but the toplevel modules package. This may
      lead to confusion if, for example, the current package is
      <tt>foo.car.tires</tt> and you attempt to use a common-lisp
      function such as <tt>(car '(1 2 3)</tt>.

18.3.2 Constants

      Constants, as declared by the preprocessor #define macro or SWIG
      <tt>%constant</tt> directive, are included in SWIG's parse tree
      when it can be determined that they are, or could be reduced to,
      a literal value. Such values are translated into defconstant
      forms in the generated lisp wrapper when the -nocwrap command-line
      options is used. Else, wrapper functions are generated as in the
      case of variable access (see section below).

      Here are examples of simple preprocessor constants when using -nocwrap.

#define A 1                    => (swig-defconstant "A" 1)
#define B 'c'                  => (swig-defconstant "B" #\c)
#define C B                    => (swig-defconstant "C" #\c)
#define D 1.0e2                => (swig-defconstant "D" 1.0d2)
#define E 2222                 => (swig-defconstant "E" 2222)
#define F (unsigned int)2222   => no code generated
#define G 1.02e2f              => (swig-defconstant "G" 1.02f2)
#define H foo                  => no code generated

      Note that where SWIG is unable to determine if a constant is
      a literal, no node is added to the SWIG parse tree, and so
      no values can be generated.

      For preprocessor constants containing expressions which can be
      reduced to literal values, nodes are created, but with no simplification
      of the constant value. A very very simple infix to prefix converter
      has been implemented that tries to do the right thing for simple cases, but
      does not for more complex expressions. If the literal parser determines
      that something is wrong, a warning will be generated and the literal
      expression will be included in the generated code, but commented out.

#define I A + E                => (swig-defconstant "I" (+ 1 2222))
#define J 1|2                  => (swig-defconstant "J" (logior 1 2))
#define Y 1 + 2 * 3 + 4        => (swig-defconstant "Y" (* (+ 1 2) (+ 3 4)))
#define Y1 (1 + 2) * (3 + 4)   => (swig-defconstant "Y1" (* (+ 1 2) (+ 3 4)))
#define Y2 1 * 2 + 3 * 4       => (swig-defconstant "Y2" (* 1 (+ 2 3) 4))  ;; WRONG
#define Y3 (1 * 2) + (3 * 4)   => (swig-defconstant "Y3" (* 1 (+ 2 3) 4))  ;; WRONG
#define Z 1 + 2 - 3 + 4 * 5    => (swig-defconstant "Z" (* (+ 1 (- 2 3) 4) 5)) ;; WRONG

	Users are cautioned to get to know their constants before use, or
	not use the <tt>-nocwrap</tt> command-line option.

18.3.3 Variables

      For C wrapping, a def-foreign-variable call is generated for access
      to global variables.

      When wrapping C++ code, both global and member variables, getter
      wrappers are generated for accessing their value, and if not immutable,
      setter wrappers as well. In the example below, note the lack of a
      setter wrapper for global_var, defined as const.

vars.h

namespace nnn {
  int const global_var = 2;
  float glob_float = 2.0;
}

    Generated code:

vars.cl

(swig-in-package ("nnn"))
(swig-defun ("global_var" "ACL_nnn__global_var_get__SWIG_0" :type :getter)
  (:void)
  (:returning (:int )
   :strings-convert t)
  (swig-ff-call))

(swig-defun ("glob_float" "ACL_nnn__glob_float_set__SWIG_0" :type :setter)
  ((PARM0_glob_float  :float ))
  (:returning (:void )
   :strings-convert t)
  (let ((SWIG_arg0 PARM0_glob_float))
  (swig-ff-call SWIG_arg0)))

(swig-defun ("glob_float" "ACL_nnn__glob_float_get__SWIG_0" :type :getter)
  (:void)
  (:returning (:float )
   :strings-convert t)
  (swig-ff-call))

      Note also, that where applicable, setter wrappers are implemented
      as setf methods on the getter function, providing a lispy interface
      to the foreign code.

user> (load "globalvar.dll")
; Foreign loading globalvar.dll.
t
user> (load "globalvar.cl")
; Loading c:\mikel\src\swig\test\globalvar.cl
t
user>
globalvar> (globalvar.nnn::global_var)
2
globalvar> (globalvar.nnn::glob_float)
2.0
globalvar> (setf (globalvar.nnn::glob_float) 3.0)
3.0
globalvar> (globalvar.nnn::glob_float)
3.0

18.3.4 Enumerations

      In C, an enumeration value is an integer value, while in C++ an
      enumeration value is implicitly convertible to an integer value,
      but can also be distinguished by its enum type. For each enum
      declaration a def-foreign-type is generated, assigning the enum
      a default type of :int. Users may adjust the foreign type of
      enums via SWIG <tt>typemaps</tt>.

      Enum values are a bit trickier as they can be initialized using
      any valid C/C++ expression. In C with the -nocwrap command-line option,
      we handle the typical cases (simple integer initialization) and
      generate a defconstant form for each enum value. This has the advantage
      of it not being necessary to probe into foreign space to retrieve enum
      values. When generating a .cxx wrapper file, a more general solution is
      employed. A wrapper variable is created in the module_wrap.cxx file, and
      a ff:def-foreign-variable call is generated to retrieve its value into lisp.

For example, the following header file

enum.h:

enum COL { RED, GREEN, BLUE };
enum FOO { FOO1 = 10, FOO2, FOO3 };

      In -nocwrap mode, generates

enum.cl:

(swig-def-foreign-type "COL" :int)
(swig-defconstant "RED" 0)
(swig-defconstant "GREEN" (+ #.(swig-insert-id "RED" () :type :constant) 1))
(swig-defconstant "BLUE" (+ #.(swig-insert-id "GREEN" () :type :constant) 1))

(swig-def-foreign-type "FOO" :int)
(swig-defconstant "FOO1" 10)
(swig-defconstant "FOO2" (+ #.(swig-insert-id "FOO1" () :type :constant) 1))
(swig-defconstant "FOO3" (+ #.(swig-insert-id "FOO2" () :type :constant) 1))

And when generating a .cxx wrapper

enum_wrap.cxx:

EXPORT const int ACL_ENUM___RED__SWIG_0 = RED;
EXPORT const int ACL_ENUM___GREEN__SWIG_0 = GREEN;
EXPORT const int ACL_ENUM___BLUE__SWIG_0 = BLUE;
EXPORT const int ACL_ENUM___FOO1__SWIG_0 = FOO1;
EXPORT const int ACL_ENUM___FOO2__SWIG_0 = FOO2;
EXPORT const int ACL_ENUM___FOO3__SWIG_0 = FOO3;

    and

enum.cl:

(swig-def-foreign-type "COL" :int)
(swig-defvar "RED" "ACL_ENUM___RED__SWIG_0" :type :constant)
(swig-defvar "GREEN" "ACL_ENUM___GREEN__SWIG_0" :type :constant)
(swig-defvar "BLUE" "ACL_ENUM___BLUE__SWIG_0" :type :constant)

(swig-def-foreign-type "FOO" :int)
(swig-defvar "FOO1" "ACL_ENUM___FOO1__SWIG_0" :type :constant)
(swig-defvar "FOO2" "ACL_ENUM___FOO2__SWIG_0" :type :constant)
(swig-defvar "FOO3" "ACL_ENUM___FOO3__SWIG_0" :type :constant)

18.3.5 Arrays

    One limitation in the Allegro CL foreign-types module, is that,
    without macrology, expressions may not be used to specify the
    dimensions of an array declaration. This is not a horrible
    drawback unless it is necessary to allocate foreign structures
    based on the array declaration using ff:allocate-fobject. When it
    can be determined that an array bound is a valid numeric value,
    SWIG will include this in the generated array declaration on the
    lisp side, otherwise the value will be included, but commented out.

      Below is a comprehensive example, showing a number of legal
      C/C++ array declarations and how they are translated
      into foreign-type specifications in the generated lisp code.

array.h

#define MAX_BUF_SIZE 1024

namespace FOO {
  int global_var1[13];
  float global_var2[MAX_BUF_SIZE];

}

enum COLOR { RED = 10, GREEN = 20, BLUE, PURPLE = 50, CYAN };

namespace BAR {
  char global_var3[MAX_BUF_SIZE + 1];
  float global_var4[MAX_BUF_SIZE][13];
  signed short global_var5[MAX_BUF_SIZE + MAX_BUF_SIZE];

  int enum_var5[GREEN];
  int enum_var6[CYAN];

  COLOR enum_var7[CYAN][MAX_BUF_SIZE];
}

    Generates:

array.cl

(in-package #.*swig-module-name*)

(swig-defpackage ("FOO"))
(swig-defpackage ("BAR"))

(swig-in-package ())
(swig-def-foreign-type "COLOR" :int)
(swig-defvar "RED" "ACL_ENUM___RED__SWIG_0" :type :constant)
(swig-defvar "GREEN" "ACL_ENUM___GREEN__SWIG_0" :type :constant)
(swig-defvar "BLUE" "ACL_ENUM___BLUE__SWIG_0" :type :constant)
(swig-defvar "PURPLE" "ACL_ENUM___PURPLE__SWIG_0" :type :constant)
(swig-defvar "CYAN" "ACL_ENUM___CYAN__SWIG_0" :type :constant)

(swig-in-package ())

(swig-defconstant "MAX_BUF_SIZE" 1024)
(swig-in-package ("FOO"))

(swig-defun ("global_var1" "ACL_FOO__global_var1_get__SWIG_0" :type :getter)
  (:void)
  (:returning ((* :int) )
   :strings-convert t)
  (make-instance 'ff:foreign-pointer :foreign-address (swig-ff-call)))

(swig-defun ("global_var2" "ACL_FOO__global_var2_set__SWIG_0" :type :setter)
  ((global_var2  (:array :float 1024) ))
  (:returning (:void )
   :strings-convert t)
  (let ((SWIG_arg0 global_var2))
  (swig-ff-call SWIG_arg0)))

(swig-in-package ())
(swig-in-package ("BAR"))
(swig-defun ("global_var3" "ACL_BAR__global_var3_set__SWIG_0" :type :setter)
  ((global_var3  (:array :char #|1024+1|#) ))
  (:returning (:void )
   :strings-convert t)
  (let ((SWIG_arg0 global_var3))
  (swig-ff-call SWIG_arg0)))

(swig-defun ("global_var4" "ACL_BAR__global_var4_set__SWIG_0" :type :setter)
  ((global_var4  (:array (:array :float 13) 1024) ))
  (:returning (:void )
   :strings-convert t)
  (let ((SWIG_arg0 global_var4))
  (swig-ff-call SWIG_arg0)))

(swig-defun ("global_var4" "ACL_BAR__global_var4_get__SWIG_0" :type :getter)
  (:void)
  (:returning ((* (:array :float 13)) )
   :strings-convert t)
  (make-instance 'ff:foreign-pointer :foreign-address (swig-ff-call)))

(swig-defun ("global_var5" "ACL_BAR__global_var5_set__SWIG_0" :type :setter)
  ((global_var5  (:array :short #|1024+1024|#) ))
  (:returning (:void )
   :strings-convert t)
  (let ((SWIG_arg0 global_var5))
  (swig-ff-call SWIG_arg0)))

(swig-defun ("enum_var5" "ACL_BAR__enum_var5_set__SWIG_0" :type :setter)
  ((enum_var5  (:array :int #|GREEN|#) ))
  (:returning (:void )
   :strings-convert t)
  (let ((SWIG_arg0 enum_var5))
  (swig-ff-call SWIG_arg0)))

(swig-defun ("enum_var6" "ACL_BAR__enum_var6_set__SWIG_0" :type :setter)
  ((enum_var6  (:array :int #|CYAN|#) ))
  (:returning (:void )
   :strings-convert t)
  (let ((SWIG_arg0 enum_var6))
  (swig-ff-call SWIG_arg0)))

(swig-defun ("enum_var7" "ACL_BAR__enum_var7_set__SWIG_0" :type :setter)
  ((enum_var7  (:array (:array #.(swig-insert-id "COLOR" ()) 1024) #|CYAN|#) ))
  (:returning (:void )
   :strings-convert t)
  (let ((SWIG_arg0 enum_var7))
  (swig-ff-call SWIG_arg0)))

(swig-defun ("enum_var7" "ACL_BAR__enum_var7_get__SWIG_0" :type :getter)
  (:void)
  (:returning ((* (:array #.(swig-insert-id "COLOR" ()) 1024)) )
   :strings-convert t)
  (make-instance 'ff:foreign-pointer :foreign-address (swig-ff-call)))

18.3.6 Classes and Structs and Unions (oh my!)

18.3.6.1 CLOS wrapping of

      Classes, unions, and structs are all treated the same way by the
      interface generator. For any of these objects, a
      def-foreign-type and a defclass form are generated.  For every
      function that returns an object (or pointer/reference) of C/C++
      type <tt>X</tt>, the wrapping defun (or defmethod) on the Lisp
      side will automatically wrap the pointer returned in an instance
      of the appropriate class. This makes it much easier to write and
      debug code than if pointers were passed around as a jumble of
      integer values.

18.3.6.2 CLOS Inheritance

      The CLOS class schema generated by the interface mirrors the
      inheritance of the classes in foreign code, with the
      ff:foreign-pointer class at its root. ff:foreign-pointer is a thin
      wrapper for pointers that is made available by the foreign function
      interface. Its key benefit is that it may be passed as an argument
      to any ff:def-foreign-call that is expecting a pointer as the
      parameter.

18.3.6.3 Member fields and functions

      All public fields will have accessor getter/setter functions
      generated for them, as appropriate. All public member functions
      will have wrapper functions generated.

      We currently ignore anything that isn't <tt>public</tt> (i.e.
      <tt>private</tt> or <tt>protected</tt>), because the C++ compiler
      won't allow the wrapper functions to access such fields. Likewise,
      the interface does nothing for <tt>friend</tt> directives,

18.3.6.4 Why not directly access C++ classes using foreign types?

      The def-foreign-type generated by the SWIG interface is
      currently incomplete. We can reliably generate the object layout
      of simple structs and unions; they can be allocated via
      ff:allocate-fobject, and their member variables accessed
      directly using the various ff:fslot-value-* functions. However,
      the layout of C++ classes is more complicated. Different
      compilers adjust class layout based on inheritance patterns, and
      the presence of virtual member functions. The size of member
      function pointers vary across compilers as well. As a result, it
      is recommended that users of any generated interface not attempt
      to access C++ instances via the foreign type system, but instead
      use the more robust wrapper functions.

18.3.7 Templates

18.3.7.1 Generating wrapper code for templates

	SWIG provides support for dealing with templates, but by
	default, it will not generate any member variable or function
	wrappers for templated classes. In order to create these
	wrappers, you need to explicitly tell SWIG to instantiate
	them. This is done via the
	<tt>%template</tt>
	directive.

18.3.7.2 Implicit Template instantiation

	While no wrapper code is generated for accessing member
	variables, or calling member functions, type code is generated
	to include these templated classes in the foreign-type and CLOS
	class schema.

18.3.8 Typedef, Templates, and Synonym Types

      In C/C++ it is possible, via typedef, to have many names refer to
      the same <tt>type</tt>. In general, this is not a problem, though
      it can lead to confusion.  Assume the below C++ header file:

synonyms.h

class A {
   int x;
   int y;
};

typedef A Foo;

A *xxx(int i);         /* sets A->x = A->y = i */
Foo *yyy(int i);       /* sets Foo->x = Foo->y = i */

int zzz(A *inst = 0);  /* return inst->x + inst->y */

      The function <tt>zzz</tt> is an overloaded functions; the
      foreign function call to it will be wrapped in a
      generic-function whose argument will be checked against a type
      of <tt>A</tt>. Assuming a simple implementation, a call
      to <tt>xxx(1)</tt> will return a pointer to an A object, which
      will be wrapped in a CLOS instance of class <tt>A</tt>, and a
      call to <tt>yyy(1)</tt> will result in a CLOS instance of
      type <tt>Foo</tt> being returned.  Without establishing a clear
      type relationship between <tt>Foo</tt> and <tt>A</tt>, an
      attempt to call <tt>zzz(yyy(1))</tt> will result in an error.

      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
      definition, we generate a form that expands to:

	<tt>(setf (find-class <synonym>) <primary>)</tt>

      The result is that all references to synonym types in foreign
      code, are wrapped in the same CLOS wrapper, and, in particular,
      method specialization in wrapping generic functions works as
      expected.

      Given the above header file, synonym.h, a Lisp session would
      appear as follows:

CL-USER> (load "synonym.dll")
; Foreign loading synonym.dll.
t
CL-USER> (load "synonym.cl")
; Loading c:\mikel\src\swig\test\synonym.cl
t
CL-USER>
synonym> (setf a (xxx 3))
#<A nil #x3261a0 @ #x207299da>
synonym> (setf foo (yyy 10))
#<A nil #x3291d0 @ #x2072e982>
synonym> (zzz a)
6
synonym> (zzz foo)
20
synonym>

18.3.8.1 Choosing a primary type

      The choice of a primary type is selected by the following
      criteria from a set of synonym types.

	  If a synonym type has a class definition, it is the primary type.

	  If a synonym type is a class template and has been explicitly
	  instantiated via <tt>%template</tt>, it is the primary type.

	  For all other sets of synonymous types, the synonym which is
	  parsed first becomes the primary type.

18.3.9 Function overloading/Parameter defaulting

      For each possible argument combination, a distinct wrapper
      function is created in the .cxx file. On the Lisp side, a
      generic functions is defined for each possible arity the
      overloaded/defaulted call may have. Each distinct wrapper is
      then called from within a defmethod on the appropriate generic
      function. These are further wrapped inside a dispatch function
      that checks the number of arguments it is called with and passes
      them via apply to the appropriate generic-function. This allows
      for a single entry point to overloaded functions on the lisp
      side.

Example:

overload.h:

class A {
 public:
  int x;
  int y;
};

float xxx(int i, int x = 0);   /* return i * x */
float xxx(A *inst, int x);     /* return x + A->x + A->y */

Creates the following three wrappers, for each of the possible argument
      combinations

overload_wrap.cxx

EXPORT void ACL___delete_A__SWIG_0 (A *larg1) {
    A *arg1 = (A *) 0 ;

    arg1 = larg1;
    try {
        delete arg1;

    } catch (...) {

    }
}

EXPORT float ACL___xxx__SWIG_0 (int larg1, int larg2) {
    float lresult = (float)0 ;
    int arg1 ;
    int arg2 ;
    float result;

    arg1 = larg1;
    arg2 = larg2;
    try {
        result = (float)xxx(arg1,arg2);

        lresult = result;
        return lresult;
    } catch (...) {
        return (float)0;
    }
}

EXPORT float ACL___xxx__SWIG_1 (int larg1) {
    float lresult = (float)0 ;
    int arg1 ;
    float result;

    arg1 = larg1;
    try {
        result = (float)xxx(arg1);

        lresult = result;
        return lresult;
    } catch (...) {
        return (float)0;
    }
}

EXPORT float ACL___xxx__SWIG_2 (A *larg1, int larg2) {
    float lresult = (float)0 ;
    A *arg1 = (A *) 0 ;
    int arg2 ;
    float result;

    arg1 = larg1;
    arg2 = larg2;
    try {
        result = (float)xxx(arg1,arg2);

        lresult = result;
        return lresult;
    } catch (...) {
        return (float)0;
    }
}

      And the following foreign-function-call and method definitions on the
      lisp side:

overload.cl

(swig-defmethod ("xxx" "ACL___xxx__SWIG_0" :type :function :arity 2)
  ((PARM0_i cl:integer :int )
   (PARM1_x cl:integer :int ))
  (:returning (:float )
   :strings-convert t)
  (let ((SWIG_arg0 PARM0_i))
  (let ((SWIG_arg1 PARM1_x))
  (swig-ff-call SWIG_arg0 SWIG_arg1))))

(swig-defmethod ("xxx" "ACL___xxx__SWIG_1" :type :function :arity 1)
  ((PARM0_i cl:integer :int ))
  (:returning (:float )
   :strings-convert t)
  (let ((SWIG_arg0 PARM0_i))
  (swig-ff-call SWIG_arg0)))

(swig-defmethod ("xxx" "ACL___xxx__SWIG_2" :type :function :arity 2)
  ((PARM0_inst #.(swig-insert-id "A" () :type :class) (* #.(swig-insert-id "A" ())) )
   (PARM1_x cl:integer :int ))
  (:returning (:float )
   :strings-convert t)
  (let ((SWIG_arg0 PARM0_inst))
  (let ((SWIG_arg1 PARM1_x))
  (swig-ff-call SWIG_arg0 SWIG_arg1))))

(swig-dispatcher ("xxx" :type :function :arities (1 2)))

And their usage in a sample lisp session:

overload> (setf a (new_A))
#<A nil #x329268 @ #x206cf612>
overload> (setf (A_x a) 10)
10
overload> (setf (A_y a) 20)
20
overload> (xxx 1)
0.0
overload> (xxx 3 10)
30.0
overload> (xxx a 1)
31.0
overload> (xxx a 2)
32.0
overload>

18.3.10 Operator wrapping and Operator overloading

      Wrappers to defined C++ Operators are automatically renamed, using
      <tt>%rename</tt>, to the following defaults:

/* name conversion for overloaded operators. */
#ifdef __cplusplus
%rename(__add__)	     *::operator+;
%rename(__pos__)	     *::operator+();
%rename(__pos__)	     *::operator+() const;

%rename(__sub__)	     *::operator-;
%rename(__neg__)	     *::operator-() const;
%rename(__neg__)	     *::operator-();

%rename(__mul__)	     *::operator*;
%rename(__deref__)	     *::operator*();
%rename(__deref__)	     *::operator*() const;

%rename(__div__)	     *::operator/;
%rename(__mod__)	     *::operator%;
%rename(__logxor__)	     *::operator^;
%rename(__logand__)	     *::operator&;
%rename(__logior__)	     *::operator|;
%rename(__lognot__)	     *::operator~();
%rename(__lognot__)	     *::operator~() const;

%rename(__not__)	     *::operator!();
%rename(__not__)	     *::operator!() const;

%rename(__assign__)	     *::operator=;

%rename(__add_assign__)      *::operator+=;
%rename(__sub_assign__)	     *::operator-=;
%rename(__mul_assign__)	     *::operator*=;
%rename(__div_assign__)	     *::operator/=;
%rename(__mod_assign__)	     *::operator%=;
%rename(__logxor_assign__)   *::operator^=;
%rename(__logand_assign__)   *::operator&=;
%rename(__logior_assign__)   *::operator|=;

%rename(__lshift__)	     *::operator<<;
%rename(__lshift_assign__)   *::operator<<=;
%rename(__rshift__)	     *::operator>>;
%rename(__rshift_assign__)   *::operator>>=;

%rename(__eq__)		     *::operator==;
%rename(__ne__)		     *::operator!=;
%rename(__lt__)		     *::operator<;
%rename(__gt__)		     *::operator>;
%rename(__lte__)	     *::operator<=;
%rename(__gte__)	     *::operator>=;

%rename(__and__)	     *::operator&&;
%rename(__or__)		     *::operator||;

%rename(__preincr__)	     *::operator++();
%rename(__postincr__)	     *::operator++(int);
%rename(__predecr__)	     *::operator--();
%rename(__postdecr__)	     *::operator--(int);

%rename(__comma__)	     *::operator,();
%rename(__comma__)	     *::operator,() const;

%rename(__member_ref__)      *::operator->;
%rename(__member_func_ref__) *::operator->*;

%rename(__funcall__)	     *::operator();
%rename(__aref__)	     *::operator[];

      Name mangling occurs on all such renamed identifiers, so that wrapper name
      generated by <tt>B::operator=</tt> will be <tt>B___eq__</tt>, i.e.
      <tt><class-or-namespace>_</tt> has been added. Users may modify
      these default names by adding <tt>%rename</tt> directives in their own .i files.

      Operator overloading can be achieved by adding functions based
      on the mangled names of the function. In the following example,
      a class B is defined with a Operator== method defined. The
      swig <tt>%extend</tt> directive is used to add an overload method
      on Operator==.

opoverload.h

class B {
 public:
  int x;
  int y;
  bool operator==(B const& other) const;
};

    and

opoverload.i

%module opoverload

%{
#include <fstream>
#include "opoverload.h"
%}

%{
bool B___eq__(B const *inst, int const x)
{
  // insert the function definition into the wrapper code before
  // the wrapper for it.
  // ... do stuff ...
}
%}

%include "opoverload.h"

%extend B {
 public:
  bool __eq__(int const x) const;
};

      Either operator can be called via a single call
      to the dispatch function:

opoverload> (B___eq__ x1 x2)
nil
opoverload> (B___eq__ x1 3)
nil
opoverload>

18.3.11 Varargs

      Variable length argument lists are not supported, by default. If
      such a function is encountered, a warning will generated to
      stderr. Varargs are supported via the SWIG <tt>%varargs</tt>
      directive. This directive allows you to specify a (finite)
      argument list which will be inserted into the wrapper in place
      of the variable length argument indicator.  As an example,
      consider the function <tt>printf()</tt>. Its declaration would
      appear as follows:

      See the following section
      on Variable Length arguments
      provides examples on how <tt>%varargs</tt> can be used, along
      with other ways such functions can be wrapped.

18.3.12 C++ Exceptions

      Each C++ wrapper includes a handler to catch any exceptions that may
      be thrown while in foreign code. This helps prevent simple C++ errors
      from killing the entire lisp process. There is currently no mechanism
      to have these exceptions forwarded to the lisp condition system, nor
      has any explicit support of the exception related SWIG typemaps been
      implemented.

18.3.13 Pass by value, pass by reference

      Allegro CL does not support the passing of non-primitive foreign
      structures by value. As a result, SWIG must automatically detect
      and convert function parameters and return values to pointers
      whenever necessary. This is done via the use of <tt>typemaps</tt>,
      and should not require any fine tuning by the user, even for
      newly defined types.

18.4 Typemaps

  SWIG Typemaps provide a powerful tool for automatically generating
  code to handle various menial tasks required of writing an interface
  to foreign code. The purpose of this section is to describe each of
  the typemaps used by the Allegro CL module. Please read the chapter
  on Typemaps for more information.

18.4.1 Code Generation in the C++ Wrapper

      Every C++ wrapper generated by SWIG takes the following form:

return-val wrapper-name(parm0, parm1, ..., parmN)
{
   return-val lresult;   /* return value from wrapper */
   <local-declaration>
   ... results;          /* return value from function call */

   <binding locals to parameters>

   try {
      result = function-name(local0, local1, ..., localN);

      <convert and bind result to lresult>

      return lresult;
   catch (...) {
      return (int)0;
   }

18.4.1.1 IN Typemap

      the <tt>in</tt> typemap is used to generate code to convert parameters
      passed to C++ wrapper functions into the arguments desired for the
      call being wrapped. That is, it fills in the code for the
      <tt><binding locals to parameters></tt> section above. We
      use this map to automatically convert parameters passed by
      reference to the wrapper function into by-value arguments for
      the wrapped call, and also to convert boolean values, which are
      passed as integers from lisp (by default), into the appropriate
      type for the language of code being wrapped.

These are the default specifications for the IN typemap. Here,
      <tt>$input</tt> refers to the parameter code is being generated
      for, and <tt>$1</tt> is the local variable to which it is
      being assigned. The default settings of this typemap are as follows:

%typemap(in) bool                          "$1 = (bool)$input;";
%typemap(in) char, unsigned char, signed char,
             short, signed short, unsigned short,
             int, signed int, unsigned int,
             long, signed long, unsigned long,
             float, double, long double, char *, void *, void,
             enum SWIGTYPE, SWIGTYPE *,
             SWIGTYPE[ANY], SWIGTYPE &     "$1 = $input;";
%typemap(in) SWIGTYPE                      "$1 = *$input;";

18.4.1.2 OUT Typemap

      The <tt>out</tt> typemap is used to generate code to form the
      return value of the wrapper from the return value of the wrapped
      function. This code is placed in the <convert and bind result to lresult>
      section of the above code diagram. Its default mapping is as follows:

%typemap(out) bool                          "$result = (int)$1;";
%typemap(out) char, unsigned char, signed char,
              short, signed short, unsigned short,
              int, signed int, unsigned int,
              long, signed long, unsigned long,
              float, double, long double, char *, void *, void,
              enum SWIGTYPE, SWIGTYPE *,
              SWIGTYPE[ANY], SWIGTYPE &    "$result = $1;";
%typemap(out) SWIGTYPE                     "$result = new $1_type($1);";

18.4.1.3 CTYPE Typemap

      This typemap is not used for code generation, but purely for the
      transformation of types in the parameter list of the wrapper function.
      Its primary use is to handle by-value to by-reference conversion in the
      wrappers parameter list. Its default settings are:

%typemap(ctype) bool                       "int";
%typemap(ctype) char, unsigned char, signed char,
                short, signed short, unsigned short,
                int, signed int, unsigned int,
                long, signed long, unsigned long,
                float, double, long double, char *, void *, void,
                enum SWIGTYPE, SWIGTYPE *,
                SWIGTYPE[ANY], SWIGTYPE &  "$1_ltype";
%typemap(ctype) SWIGTYPE                   "$&1_type";

      These three typemaps are specifically employed by the
      Allegro CL interface generator. SWIG also implements a number of
      other typemaps that can be used for generating code in the C/C++
      wrappers. You can read about
      these common typemaps here.

18.4.2 Code generation in Lisp wrappers

      A number of custom typemaps have also been added to facilitate
      the generation of code in the lisp side of the interface. These
      are described below. The basic code generation structure is
      applied as a series of nested expressions, one for each
      parameter, then one for manipulating the return value, and last,
      the foreign function call itself.

      Note that the typemaps below use fully qualified symbols where
      necessary. Users writing their own typemaps should do likewise.
      See the explanation in the last paragraph of
      16.3.1 Namespaces for details.

18.4.2.1 LIN Typemap

      The LIN typemap allows for the manipulating the lisp objects
      passed as arguments to the wrapping defun before passing them to
      the foreign function call. For example, when passing lisp
      strings to foreign code, it is often necessary to copy the
      string into a foreign structure of type (:char *) of appropriate
      size, and pass this copy to the foreign call. Using the LIN
      typemap, one could arrange for the stack-allocation of a foreign
      char array, copy your string into it, and not have to worry
      about freeing the copy after the function returns.

The LIN typemap accepts the following <tt>$variable</tt> references.

<tt>$in</tt> - expands to the name of the parameter being
	  applied to this typemap

<tt>$out</tt> - expands to the name of the local variable
	  assigned to this typemap

<tt>$in_fftype</tt> - the foreign function type of the C type.

<tt>$*in_fftype</tt> - the foreign function type of the C type
	  with one pointer removed. If there is no pointer, then $*in_fftype
	  is the same as $in_fftype.

<tt>$body</tt> - very important. Instructs SWIG where
	  subsequent code generation steps should be inserted into the
	  current typemap.  Leaving out a <tt>$body</tt> reference
	  will result in lisp wrappers that do very little by way of
	  calling into foreign code. Not recommended.

%typemap(lin)	SWIGTYPE 	"(cl:let (($out $in))\n  $body)";

18.4.2.2 LOUT Typemap

      The LOUT typemap is the means by which we effect the wrapping of
      foreign pointers in CLOS instances. It is applied after all LIN
      typemaps, and immediately before the actual foreign-call.

The LOUT typemap uses the following $variable

<tt>$lclass</tt> - Expands to the CLOS class that
	  represents foreign-objects of the return type matching this
	  typemap.

<tt>$body</tt> - Same as for the LIN map. Place this
	  variable where you want the foreign-function call to occur.

<tt>$ldestructor</tt> - Expands to the symbol naming the destructor for this
	  class ($lclass) of object. Allows you to insert finalization or automatic garbage
	  collection into the wrapper code (see default mappings below).

%typemap(lout) bool, char, unsigned char, signed char,
               short, signed short, unsigned short,
               int, signed int, unsigned int,
               long, signed long, unsigned long,
               float, double, long double, char *, void *, void,
               enum SWIGTYPE    "$body";
%typemap(lout) SWIGTYPE[ANY], SWIGTYPE *,
               SWIGTYPE &       "(cl:make-instance '$lclass :foreign-address $body)";
%typemap(lout) SWIGTYPE    "(cl:let* ((address $body)\n
                            (ACL_result (cl:make-instance '$lclass :foreign-address address)))\n
                            (cl:unless (cl::zerop address)\n
                            (excl:schedule-finalization ACL_result #'$ldestructor))\n
                             ACL_result)";

18.4.2.3 FFITYPE Typemap

      The FFITYPE typemap works as a helper for a body of code that
      converts C/C++ type specifications into Allegro CL foreign-type
      specifications. These foreign-type specifications appear in
      ff:def-foreing-type declarations, and in the argument list and
      return values of ff:def-foreign-calls. You would modify this
      typemap if you want to change how the FFI passes through
      arguments of a given type. For example, if you know that a
      particular compiler represents booleans as a single byte, you
      might add an entry for:

%typemap(ffitype) bool ":unsigned-char";

      Note that this typemap is pure type transformation, and is not
      used in any code generations step the way the LIN and LOUT
      typemaps are. The default mappings for this typemap are:

%typemap(ffitype) bool ":int";
%typemap(ffitype) char ":char";
%typemap(ffitype) unsigned char ":unsigned-char";
%typemap(ffitype) signed char ":char";
%typemap(ffitype) short, signed short ":short";
%typemap(ffitype) unsigned short ":unsigned-short";
%typemap(ffitype) int, signed int ":int";
%typemap(ffitype) unsigned int ":unsigned-int";
%typemap(ffitype) long, signed long ":long";
%typemap(ffitype) unsigned long ":unsigned-long";
%typemap(ffitype) float ":float";
%typemap(ffitype) double ":double";
%typemap(ffitype) char * "(* :char)";
%typemap(ffitype) void * "(* :void)";
%typemap(ffitype) void ":void";
%typemap(ffitype) enum SWIGTYPE ":int";
%typemap(ffitype) SWIGTYPE & "(* :void)";

18.4.2.4 LISPTYPE Typemap

      This is another type only transformation map, and is used to
      provide the lisp-type, which is the optional third argument in
      argument specifier in a ff:def-foreign-call form. Specifying a
      lisp-type allows the foreign call to perform type checking on
      the arguments passed in. The default entries in this typemap are:

%typemap(lisptype) bool "cl:boolean";
%typemap(lisptype) char "cl:character";
%typemap(lisptype) unsigned char "cl:integer";
%typemap(lisptype) signed char "cl:integer";

18.4.2.5 LISPCLASS Typemap

      The LISPCLASS typemap is used to generate the method signatures
      for the generic-functions which wrap overloaded functions and
      functions with defaulted arguments. The default entries are:

%typemap(lispclass) bool "t";
%typemap(lispclass) char "cl:character";
%typemap(lispclass) unsigned char, signed char,
                    short, signed short, unsigned short,
                    int, signed int, unsigned int,
                    long, signed long, unsigned long,
                    enum SWIGTYPE       "cl:integer";
%typemap(lispclass) float "cl:single-float";
%typemap(lispclass) double "cl:double-float";
%typemap(lispclass) char * "cl:string";

18.4.3 Modifying SWIG behavior using typemaps

      The following example shows how we made use of the above
      typemaps to add support for the wchar_t type.

%typecheck(SWIG_TYPECHECK_UNICHAR) wchar_t { $1 = 1; };

%typemap(in)        wchar_t "$1 = $input;";
%typemap(lin)       wchar_t "(cl:let (($out (cl:char-code $in)))\n  $body)";
%typemap(lin)       wchar_t* "(excl:with-native-string
                                         ($out $in
                                          :external-format #+little-endian :fat-le
                                                           #-little-endian :fat)\n
                                 $body)"

%typemap(out)       wchar_t "$result = $1;";
%typemap(lout)      wchar_t "(cl:code-char $body)";
%typemap(lout)      wchar_t* "(excl:native-to-string $body
                                          :external-format #+little-endian :fat-le
                                                           #-little-endian :fat)";

%typemap(ffitype)   wchar_t ":unsigned-short";
%typemap(lisptype)  wchar_t "";
%typemap(ctype)     wchar_t "wchar_t";
%typemap(lispclass) wchar_t "cl:character";
%typemap(lispclass) wchar_t* "cl:string";

18.5 Identifier Converter functions

18.5.1 Creating symbols in the lisp environment

  Various symbols must be generated in the lisp environment to which
  class definitions, functions, constants, variables, etc. must be
  bound. Rather than force a particular convention for naming these
  symbols, an identifier (to symbol) conversion function is used. A
  user-defined identifier-converter can then implement any symbol
  naming, case-modifying, scheme desired.

  In generated SWIG code, whenever some interface object must be
  referenced by its lisp symbol, a macro is inserted that calls the
  identifier-converter function to generate the appropriate symbol
  reference. It is therefore expected that the identifier-converter
  function reliably return the same (eq) symbol given the same set
  of arguments.

18.5.2 Existing identifier-converter functions

Two basic identifier routines have been defined.

18.5.2.1 identifier-convert-null

      No modification of the identifier string is performed. Based on
      other arguments, the identifier may be concatenated with other
      strings, from which a symbol will be created.

18.5.2.2 identifier-convert-lispify

      All underscores in the identifier string are converted to
      hyphens. Otherwise, identifier-convert-lispify performs the
      same symbol transformations.

18.5.2.3 Default identifier to symbol conversions

      Check the definitions of the above two default
      identifier-converters in <tt>Lib/allegrocl/allegrocl.swg</tt> for
      default naming conventions.

18.5.3 Defining your own identifier-converter

  A user-defined identifier-converter function should conform to the following
  specification:

(defun identifier-convert-fn (id &key type class arity) ...body...)
result ==> symbol or (setf symbol)

The <tt>ID</tt> argument is a string representing an identifier in the
foreign environment.

The :type keyword argument provides more information on the type of
identifier. Its value is a symbol. This allows the
identifier-converter to apply different heuristics when mapping
different types of identifiers to symbols. SWIG will generate calls
to your identifier-converter using the following types.

:class - names a CLOS class.

:constant - names a defconstant

:constructor - names a function for creating a foreign object

:destructor - names a function for freeing a foreign object

:function - names a CLOS wrapping defmethod or defun.

:ff-operator - names a foreign call defined via ff:def-foreign-call

:getter - getter function

:namespace - names a C++ namespace

:setter - names a setter function. May return a (setf symbol) reference

:operator - names a C++ operator, such as Operator=, Operator*.

:slot - names a slot in a struct/class/union declaration.

:type - names a foreign-type defined via ff:def-foreign-type.

:variable - names a variable defined via ff:def-foreign-variable.

The :class keyword argument is a string naming a foreign
class. When non-nil, it indicates that the current identifier has
scope in the specified class.

The :arity keyword argument only appears in swig:swig-defmethod forms
generated for overloaded functions. Its value is an integer
indicating the number of arguments passed to the routine indicated by
this identifier.

18.5.4 Instructing SWIG to use a particular identifier-converter

  By default, SWIG will use identifier-converter-null. To specify
  another convert function, use the <tt>-identifier-converter</tt>
  command-line argument. The value should be a string naming the
  function you wish the interface to use instead, when generating
  symbols. ex:

% swig -allegrocl -c++ -module mymodule -identifier-converter my-identifier-converter

redpajama_set_name: RedPajamaGithub


Product prices and availability are accurate as of 2019-03-07 20:00:20 UTC and are subject to change. Any price and availability information displayed on http://www.amazon.com/ at the time of purchase will apply to the purchase of this product.
Experience the enjoyable of Thomas & Pals in a whole new method with Rail Rollers toys from Fisher-Price! Solely designed to resemble your preferred Thomas & Pals characters, these little engines provide a distinct play pattern and an adorable make over! This 3-pack includes Percy, Gordon and Toby Rail Rollers toys. Toss them, roll them, gather them, or utilize them in the Rail Rollers Spiral Station (offered individually and subject to accessibility). Young children ages 12M+.


text:
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE erlref SYSTEM "erlref.dtd">

<erlref>

  <copyright>
    <year>2020</year><year>2021</year>
    <holder>wxWidgets team.</holder></copyright>
  <legalnotice>Licensed under the wxWindows Free Documentation Licence, Version 3
  </legalnotice>
  <title>wxSizer</title>

<module>wxSizer</module>
<modulesummary>Functions for wxSizer class</modulesummary>
<description>
<seeerl marker="wxSizer"><c>wxSizer</c></seeerl> is the abstract base class used for laying out subwindows in a window. You cannot use <seeerl marker="wxSizer"><c>wxSizer</c></seeerl> directly; instead, you will have to use one of the sizer classes derived from it. Currently there are <seeerl marker="wxBoxSizer"><c>wxBoxSizer</c></seeerl>, <seeerl marker="wxStaticBoxSizer"><c>wxStaticBoxSizer</c></seeerl>, <seeerl marker="wxGridSizer"><c>wxGridSizer</c></seeerl>, <seeerl marker="wxFlexGridSizer"><c>wxFlexGridSizer</c></seeerl>, <c>wxWrapSizer</c> (not implemented in wx) and <seeerl marker="wxGridBagSizer"><c>wxGridBagSizer</c></seeerl>.

The layout algorithm used by sizers in wxWidgets is closely related to layout in other GUI toolkits, such as Java's AWT, the GTK toolkit or the Qt toolkit. It is based upon the idea of the individual subwindows reporting their minimal required size and their ability to get stretched if the size of the parent window has changed.

This will most often mean that the programmer does not set the original size of a dialog in the beginning, rather the dialog will be assigned a sizer and this sizer will be queried about the recommended size. The sizer in turn will query its children, which can be normal windows, empty space or other sizers, so that a hierarchy of sizers can be constructed. Note that <seeerl marker="wxSizer"><c>wxSizer</c></seeerl> does not derive from <seeerl marker="wxWindow"><c>wxWindow</c></seeerl> and thus does not interfere with tab ordering and requires very little resources compared to a real window on screen.

What makes sizers so well fitted for use in wxWidgets is the fact that every control reports its own minimal size and the algorithm can handle differences in font sizes or different window (dialog item) sizes on different platforms without problems. If e.g. the standard font as well as the overall design of Motif widgets requires more space than on Windows, the initial dialog size will automatically be bigger on Motif than on Windows.

Sizers may also be used to control the layout of custom drawn items on the window. The <seemfa marker="#add/4"><c>add/4</c></seemfa>, <seemfa marker="#insert/5"><c>insert/5</c></seemfa>, and <seemfa marker="#prepend/4"><c>prepend/4</c></seemfa> functions return a pointer to the newly added <seeerl marker="wxSizerItem"><c>wxSizerItem</c></seeerl>. Just add empty space of the desired size and attributes, and then use the <seemfa marker="wxSizerItem#getRect/1"><c>wxSizerItem:getRect/1</c></seemfa> method to determine where the drawing operations should take place.

Please notice that sizers, like child windows, are owned by the library and will be deleted by it which implies that they must be allocated on the heap. However if you create a sizer and do not add it to another sizer or window, the library wouldn't be able to delete such an orphan sizer and in this, and only this, case it should be deleted explicitly.

wxSizer flags

The "flag" argument accepted by <seeerl marker="wxSizerItem"><c>wxSizerItem</c></seeerl> constructors and other functions, e.g. <seemfa marker="#add/4"><c>add/4</c></seemfa>, is an OR-combination of the following flags. Two main behaviours are defined using these flags. One is the border around a window: the border parameter determines the border width whereas the flags given here determine which side(s) of the item that the border will be added. The other flags determine how the sizer item behaves when the space allotted to the sizer changes, and is somewhat dependent on the specific kind of sizer used.

See: <url href="https://docs.wxwidgets.org/3.1/overview_sizer.html#overview_sizer">Overview sizer</url>

wxWidgets docs: <url href="https://docs.wxwidgets.org/3.1/classwx_sizer.html">wxSizer</url>

  </description>
<datatypes><datatype><name name="wxSizer"/></datatype></datatypes>

<funcs>
  <func>
    <name name="add" arity="2" clause_i="1" since=""/>
    <fsummary>See: <c>add/3</c></fsummary>
  </func>

  <func>
    <name name="add" arity="3" clause_i="1" since=""/>

    <name name="add" arity="3" clause_i="2" since=""/>

    <name name="add" arity="3" clause_i="3" since=""/>
    <fsummary>Appends a child to the sizer. </fsummary>
    <desc>
Appends a child to the sizer.

<seeerl marker="wxSizer"><c>wxSizer</c></seeerl> itself is an abstract class, but the parameters are equivalent in the derived classes that you will instantiate to use it so they are described here:

</desc>
  </func>

  <func>
    <name name="add" arity="4" clause_i="1" since=""/>

    <name name="add" arity="4" clause_i="2" since=""/>
    <fsummary>Appends a spacer child to the sizer. </fsummary>
    <desc>
Appends a spacer child to the sizer.

</desc>
  </func>

  <func>
    <name name="addSpacer" arity="2" clause_i="1" since=""/>
    <fsummary>This base function adds non-stretchable space to both the horizontal and vertical orientation of the sizer. </fsummary>
    <desc>
This base function adds non-stretchable space to both the horizontal and vertical orientation of the sizer.

More readable way of calling:

See: <seemfa marker="#addSpacer/2"><c>addSpacer/2</c></seemfa>

</desc>
  </func>

  <func>
    <name name="addStretchSpacer" arity="1" clause_i="1" since=""/>
    <fsummary>See: <c>addStretchSpacer/2</c></fsummary>
  </func>

  <func>
    <name name="addStretchSpacer" arity="2" clause_i="1" since=""/>
    <fsummary>Adds stretchable space to the sizer. </fsummary>
    <desc>
Adds stretchable space to the sizer.

More readable way of calling:

</desc>
  </func>

  <func>
    <name name="calcMin" arity="1" clause_i="1" since=""/>
    <fsummary>This method is abstract and has to be overwritten by any derived class. </fsummary>
    <desc>
This method is abstract and has to be overwritten by any derived class.

Here, the sizer will do the actual calculation of its children's minimal sizes.

</desc>
  </func>

  <func>
    <name name="clear" arity="1" clause_i="1" since=""/>
    <fsummary>See: <c>clear/2</c></fsummary>
  </func>

  <func>
    <name name="clear" arity="2" clause_i="1" since=""/>
    <fsummary>Detaches all children from the sizer. </fsummary>
    <desc>
Detaches all children from the sizer.

If <c>delete_windows</c> is true then child windows will also be deleted.

Notice that child sizers are always deleted, as a general consequence of the principle that sizers own their sizer children, but don't own their window children (because they are already owned by their parent windows).

</desc>
  </func>

  <func>
    <name name="detach" arity="2" clause_i="1" since=""/>

    <name name="detach" arity="2" clause_i="2" since=""/>
    <fsummary>Detach a item at position <c>index</c> from the sizer without destroying it. </fsummary>
    <desc>
Detach a item at position <c>index</c> from the sizer without destroying it.

This method does not cause any layout or resizing to take place, call <seemfa marker="#layout/1"><c>layout/1</c></seemfa> to update the layout "on screen" after detaching a child from the sizer. Returns true if the child item was found and detached, false otherwise.

See: <seemfa marker="#remove/2"><c>remove/2</c></seemfa>

</desc>
  </func>

  <func>
    <name name="fit" arity="2" clause_i="1" since=""/>
    <fsummary>Tell the sizer to resize the <c>window</c> so that its client area matches the sizer's minimal size (<c>ComputeFittingClientSize()</c> (not implemented in wx) is called to determine it). </fsummary>
    <desc>
Tell the sizer to resize the <c>window</c> so that its client area matches the sizer's minimal size (<c>ComputeFittingClientSize()</c> (not implemented in wx) is called to determine it).

This is commonly done in the constructor of the window itself, see sample in the description of <seeerl marker="wxBoxSizer"><c>wxBoxSizer</c></seeerl>.

Return: The new window size.

See: <c>ComputeFittingClientSize()</c> (not implemented in wx), <c>ComputeFittingWindowSize()</c> (not implemented in wx)

</desc>
  </func>

  <func>
    <name name="setVirtualSizeHints" arity="2" clause_i="1" since=""/>
    <fsummary>See: <c>fitInside/2</c></fsummary>
    <desc>
See: <seemfa marker="#fitInside/2"><c>fitInside/2</c></seemfa>.

    </desc>
  </func>

  <func>
    <name name="fitInside" arity="2" clause_i="1" since=""/>
    <fsummary>Tell the sizer to resize the virtual size of the <c>window</c> to match the sizer's minimal size. </fsummary>
    <desc>
Tell the sizer to resize the virtual size of the <c>window</c> to match the sizer's minimal size.

This will not alter the on screen size of the window, but may cause the addition/removal/alteration of scrollbars required to view the virtual area in windows which manage it.

See: <seemfa marker="wxScrolledWindow#setScrollbars/6"><c>wxScrolledWindow:setScrollbars/6</c></seemfa>, <seemfa marker="#setVirtualSizeHints/2"><c>setVirtualSizeHints/2</c></seemfa>

</desc>
  </func>

  <func>
    <name name="getChildren" arity="1" clause_i="1" since=""/>
    <fsummary/>
    <desc/>
  </func>

  <func>
    <name name="getItem" arity="2" clause_i="1" since=""/>

    <name name="getItem" arity="2" clause_i="2" since=""/>
    <fsummary>Finds <c>wxSizerItem</c> which is located in the sizer at position <c>index</c>. </fsummary>
    <desc>
Finds <seeerl marker="wxSizerItem"><c>wxSizerItem</c></seeerl> which is located in the sizer at position <c>index</c>.

Use parameter <c>recursive</c> to search in subsizers too. Returns pointer to item or NULL.

</desc>
  </func>

  <func>
    <name name="getItem" arity="3" clause_i="1" since=""/>
    <fsummary>Finds <c>wxSizerItem</c> which holds the given <c>window</c>. </fsummary>
    <desc>
Finds <seeerl marker="wxSizerItem"><c>wxSizerItem</c></seeerl> which holds the given <c>window</c>.

Use parameter <c>recursive</c> to search in subsizers too. Returns pointer to item or NULL.

</desc>
  </func>

  <func>
    <name name="getSize" arity="1" clause_i="1" since=""/>
    <fsummary>Returns the current size of the sizer. </fsummary>
    <desc>
Returns the current size of the sizer.

</desc>
  </func>

  <func>
    <name name="getPosition" arity="1" clause_i="1" since=""/>
    <fsummary>Returns the current position of the sizer. </fsummary>
    <desc>
Returns the current position of the sizer.

</desc>
  </func>

  <func>
    <name name="getMinSize" arity="1" clause_i="1" since=""/>
    <fsummary>Returns the minimal size of the sizer. </fsummary>
    <desc>
Returns the minimal size of the sizer.

This is either the combined minimal size of all the children and their borders or the minimal size set by <seemfa marker="#setMinSize/3"><c>setMinSize/3</c></seemfa>, depending on which is bigger. Note that the returned value is client size, not window size. In particular, if you use the value to set toplevel window's minimal or actual size, use <c>wxWindow::SetMinClientSize()</c> (not implemented in wx) or <seemfa marker="wxWindow#setClientSize/3"><c>wxWindow:setClientSize/3</c></seemfa>, not <seemfa marker="wxWindow#setMinSize/2"><c>wxWindow:setMinSize/2</c></seemfa> or <seemfa marker="wxWindow#setSize/6"><c>wxWindow:setSize/6</c></seemfa>.

</desc>
  </func>

  <func>
    <name name="hide" arity="2" clause_i="1" since=""/>

    <name name="hide" arity="2" clause_i="2" since=""/>
    <fsummary>Hides the item at position <c>index</c>. </fsummary>
    <desc>
Hides the item at position <c>index</c>.

To make a sizer item disappear, use <seemfa marker="#hide/3"><c>hide/3</c></seemfa> followed by <seemfa marker="#layout/1"><c>layout/1</c></seemfa>.

Use parameter <c>recursive</c> to hide elements found in subsizers. Returns true if the child item was found, false otherwise.

See: <seemfa marker="#isShown/2"><c>isShown/2</c></seemfa>, <seemfa marker="#show/3"><c>show/3</c></seemfa>

</desc>
  </func>

  <func>
    <name name="hide" arity="3" clause_i="1" since=""/>
    <fsummary>Hides the child <c>window</c>. </fsummary>
    <desc>
Hides the child <c>window</c>.

To make a sizer item disappear, use <seemfa marker="#hide/3"><c>hide/3</c></seemfa> followed by <seemfa marker="#layout/1"><c>layout/1</c></seemfa>.

Use parameter <c>recursive</c> to hide elements found in subsizers. Returns true if the child item was found, false otherwise.

See: <seemfa marker="#isShown/2"><c>isShown/2</c></seemfa>, <seemfa marker="#show/3"><c>show/3</c></seemfa>

</desc>
  </func>

  <func>
    <name name="insert" arity="3" clause_i="1" since=""/>
    <fsummary/>
    <desc/>
  </func>

  <func>
    <name name="insert" arity="4" clause_i="1" since=""/>

    <name name="insert" arity="4" clause_i="2" since=""/>

    <name name="insert" arity="4" clause_i="3" since=""/>
    <fsummary>Insert a child into the sizer before any existing item at <c>index</c>. </fsummary>
    <desc>
Insert a child into the sizer before any existing item at <c>index</c>.

See <seemfa marker="#add/4"><c>add/4</c></seemfa> for the meaning of the other parameters.

</desc>
  </func>

  <func>
    <name name="insert" arity="5" clause_i="1" since=""/>

    <name name="insert" arity="5" clause_i="2" since=""/>
    <fsummary>Insert a child into the sizer before any existing item at <c>index</c>. </fsummary>
    <desc>
Insert a child into the sizer before any existing item at <c>index</c>.

See <seemfa marker="#add/4"><c>add/4</c></seemfa> for the meaning of the other parameters.

</desc>
  </func>

  <func>
    <name name="insertSpacer" arity="3" clause_i="1" since=""/>
    <fsummary>Inserts non-stretchable space to the sizer. </fsummary>
    <desc>
Inserts non-stretchable space to the sizer.

More readable way of calling wxSizer::Insert(index, size, size).

</desc>
  </func>

  <func>
    <name name="insertStretchSpacer" arity="2" clause_i="1" since=""/>
    <fsummary>See: <c>insertStretchSpacer/3</c></fsummary>
  </func>

  <func>
    <name name="insertStretchSpacer" arity="3" clause_i="1" since=""/>
    <fsummary>Inserts stretchable space to the sizer. </fsummary>
    <desc>
Inserts stretchable space to the sizer.

More readable way of calling wxSizer::Insert(0, 0, prop).

</desc>
  </func>

  <func>
    <name name="isShown" arity="2" clause_i="1" since=""/>

    <name name="isShown" arity="2" clause_i="2" since=""/>
    <fsummary>Returns true if the item at <c>index</c> is shown. </fsummary>
    <desc>
Returns true if the item at <c>index</c> is shown.

See: <seemfa marker="#hide/3"><c>hide/3</c></seemfa>, <seemfa marker="#show/3"><c>show/3</c></seemfa>, <seemfa marker="wxSizerItem#isShown/1"><c>wxSizerItem:isShown/1</c></seemfa>

</desc>
  </func>

  <func>
    <name name="recalcSizes" arity="1" clause_i="1" since=""/>
    <fsummary>See: <c>layout/1</c></fsummary>
    <desc>
See: <seemfa marker="#layout/1"><c>layout/1</c></seemfa>.

    </desc>
  </func>

  <func>
    <name name="layout" arity="1" clause_i="1" since=""/>
    <fsummary>Call this to force layout of the children anew, e.g. after having added a child to or removed a child (window, other sizer or space) from the sizer while keeping the current dimension. </fsummary>
    <desc>
Call this to force layout of the children anew, e.g. after having added a child to or removed a child (window, other sizer or space) from the sizer while keeping the current dimension.

</desc>
  </func>

  <func>
    <name name="prepend" arity="2" clause_i="1" since=""/>
    <fsummary/>
    <desc/>
  </func>

  <func>
    <name name="prepend" arity="3" clause_i="1" since=""/>

    <name name="prepend" arity="3" clause_i="2" since=""/>

    <name name="prepend" arity="3" clause_i="3" since=""/>
    <fsummary>Same as <c>add/4</c>, but prepends the items to the beginning of the list of items (windows, subsizers or spaces) owned by this sizer. </fsummary>
    <desc>
Same as <seemfa marker="#add/4"><c>add/4</c></seemfa>, but prepends the items to the beginning of the list of items (windows, subsizers or spaces) owned by this sizer.

</desc>
  </func>

  <func>
    <name name="prepend" arity="4" clause_i="1" since=""/>

    <name name="prepend" arity="4" clause_i="2" since=""/>
    <fsummary>Same as <c>add/4</c>, but prepends the items to the beginning of the list of items (windows, subsizers or spaces) owned by this sizer. </fsummary>
    <desc>
Same as <seemfa marker="#add/4"><c>add/4</c></seemfa>, but prepends the items to the beginning of the list of items (windows, subsizers or spaces) owned by this sizer.

</desc>
  </func>

  <func>
    <name name="prependSpacer" arity="2" clause_i="1" since=""/>
    <fsummary>Prepends non-stretchable space to the sizer. </fsummary>
    <desc>
Prepends non-stretchable space to the sizer.

More readable way of calling wxSizer::Prepend(size, size, 0).

</desc>
  </func>

  <func>
    <name name="prependStretchSpacer" arity="1" clause_i="1" since=""/>
    <fsummary>See: <c>prependStretchSpacer/2</c></fsummary>
  </func>

  <func>
    <name name="prependStretchSpacer" arity="2" clause_i="1" since=""/>
    <fsummary>Prepends stretchable space to the sizer. </fsummary>
    <desc>
Prepends stretchable space to the sizer.

More readable way of calling wxSizer::Prepend(0, 0, prop).

</desc>
  </func>

  <func>
    <name name="remove" arity="2" clause_i="1" since=""/>

    <name name="remove" arity="2" clause_i="2" since=""/>
    <fsummary>Removes a sizer child from the sizer and destroys it. </fsummary>
    <desc>
Removes a sizer child from the sizer and destroys it.

Note: This method does not cause any layout or resizing to take place, call <seemfa marker="#layout/1"><c>layout/1</c></seemfa> to update the layout "on screen" after removing a child from the sizer.

Return: true if the child item was found and removed, false otherwise.

</desc>
  </func>

  <func>
    <name name="replace" arity="3" clause_i="1" since=""/>

    <name name="replace" arity="3" clause_i="2" since=""/>
    <fsummary>Detaches the given item at position <c>index</c> from the sizer and replaces it with the given <c>wxSizerItem</c> <c>newitem</c>. </fsummary>
    <desc>
Detaches the given item at position <c>index</c> from the sizer and replaces it with the given <seeerl marker="wxSizerItem"><c>wxSizerItem</c></seeerl> <c>newitem</c>.

The detached child is deleted <c>only</c> if it is a sizer or a spacer (but not if it is a <seeerl marker="wxWindow"><c>wxWindow</c></seeerl> because windows are owned by their parent window, not the sizer).

This method does not cause any layout or resizing to take place, call <seemfa marker="#layout/1"><c>layout/1</c></seemfa> to update the layout "on screen" after replacing a child from the sizer.

Returns true if the child item was found and removed, false otherwise.

</desc>
  </func>

  <func>
    <name name="replace" arity="4" clause_i="1" since=""/>
    <fsummary>Detaches the given <c>oldwin</c> from the sizer and replaces it with the given <c>newwin</c>. </fsummary>
    <desc>
Detaches the given <c>oldwin</c> from the sizer and replaces it with the given <c>newwin</c>.

The detached child window is <c>not</c> deleted (because windows are owned by their parent window, not the sizer).

Use parameter <c>recursive</c> to search the given element recursively in subsizers.

This method does not cause any layout or resizing to take place, call <seemfa marker="#layout/1"><c>layout/1</c></seemfa> to update the layout "on screen" after replacing a child from the sizer.

Returns true if the child item was found and removed, false otherwise.

</desc>
  </func>

  <func>
    <name name="setDimension" arity="3" clause_i="1" since=""/>
    <fsummary>This is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts. </fsummary>
    <desc>
This is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts.

</desc>
  </func>

  <func>
    <name name="setDimension" arity="5" clause_i="1" since=""/>
    <fsummary>Call this to force the sizer to take the given dimension and thus force the items owned by the sizer to resize themselves according to the rules defined by the parameter in the <c>add/4</c> and <c>prepend/4</c> methods. </fsummary>
    <desc>
Call this to force the sizer to take the given dimension and thus force the items owned by the sizer to resize themselves according to the rules defined by the parameter in the <seemfa marker="#add/4"><c>add/4</c></seemfa> and <seemfa marker="#prepend/4"><c>prepend/4</c></seemfa> methods.

</desc>
  </func>

  <func>
    <name name="setMinSize" arity="2" clause_i="1" since=""/>
    <fsummary>Call this to give the sizer a minimal size. </fsummary>
    <desc>
Call this to give the sizer a minimal size.

Normally, the sizer will calculate its minimal size based purely on how much space its children need. After calling this method <seemfa marker="#getMinSize/1"><c>getMinSize/1</c></seemfa> will return either the minimal size as requested by its children or the minimal size set here, depending on which is bigger.

</desc>
  </func>

  <func>
    <name name="setMinSize" arity="3" clause_i="1" since=""/>
    <fsummary>This is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts. </fsummary>
    <desc>
This is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts.

</desc>
  </func>

  <func>
    <name name="setItemMinSize" arity="3" clause_i="1" since=""/>

    <name name="setItemMinSize" arity="3" clause_i="2" since=""/>
    <fsummary/>
    <desc/>
  </func>

  <func>
    <name name="setItemMinSize" arity="4" clause_i="1" since=""/>

    <name name="setItemMinSize" arity="4" clause_i="2" since=""/>
    <fsummary/>
    <desc/>
  </func>

  <func>
    <name name="setSizeHints" arity="2" clause_i="1" since=""/>
    <fsummary>This method first calls <c>fit/2</c> and then <c>setSizeHints/2</c> on the <c>window</c> passed to it. </fsummary>
    <desc>
This method first calls <seemfa marker="#fit/2"><c>fit/2</c></seemfa> and then <seemfa marker="#setSizeHints/2"><c>setSizeHints/2</c></seemfa> on the <c>window</c> passed to it.

This only makes sense when <c>window</c> is actually a <seeerl marker="wxTopLevelWindow"><c>wxTopLevelWindow</c></seeerl> such as a <seeerl marker="wxFrame"><c>wxFrame</c></seeerl> or a <seeerl marker="wxDialog"><c>wxDialog</c></seeerl>, since SetSizeHints only has any effect in these classes. It does nothing in normal windows or controls.

This method is implicitly used by <seemfa marker="wxWindow#setSizerAndFit/3"><c>wxWindow:setSizerAndFit/3</c></seemfa> which is commonly invoked in the constructor of a toplevel window itself (see the sample in the description of <seeerl marker="wxBoxSizer"><c>wxBoxSizer</c></seeerl>) if the toplevel window is resizable.

</desc>
  </func>

  <func>
    <name name="show" arity="2" clause_i="1" since=""/>

    <name name="show" arity="2" clause_i="2" since=""/>

    <name name="show" arity="2" clause_i="3" since=""/>
    <fsummary/>
    <desc/>
  </func>

  <func>
    <name name="show" arity="3" clause_i="1" since=""/>

    <name name="show" arity="3" clause_i="2" since=""/>
    <fsummary>Shows the item at <c>index</c>. </fsummary>
    <desc>
Shows the item at <c>index</c>.

To make a sizer item disappear or reappear, use <seemfa marker="#show/3"><c>show/3</c></seemfa> followed by <seemfa marker="#layout/1"><c>layout/1</c></seemfa>.

Returns true if the child item was found, false otherwise.

See: <seemfa marker="#hide/3"><c>hide/3</c></seemfa>, <seemfa marker="#isShown/2"><c>isShown/2</c></seemfa>

</desc>
  </func>

  <func>
    <name name="showItems" arity="2" clause_i="1" since=""/>
    <fsummary>Show or hide all items managed by the sizer. </fsummary>
    <desc>
Show or hide all items managed by the sizer.

</desc>
  </func>
  </funcs>
</erlref>


text:
Social Sciences Human Geography
Mediated Geographies and Geographies of Media
Editors: Mains, Susan P., Cupples, Julie, Lukinbeal, Chris (Eds.)
Offers comprehensive coverage of current trends in Geographies of Media research
Explores a variety of media types as well as the processes through which media reflects and shapes our conceptualization of key geographical issues
Provides a unique crucible for emerging debates about the interconnections between media, space, power, and changing identities Features coverage that is international in scope
This is the first comprehensive volume to explore and engage with current trends in Geographies of Media research. It reviews how conceptualizations of mediated geographies have evolved. Followed by an examination of diverse media contexts and locales, the book illustrates key issues through the integration of theoretical and empirical case studies, and reflects on the future challenges and opportunities faced by scholars in this field. The contributions by an international team of experts in the field, address theoretical perspectives on mediated geographies, methodological challenges and opportunities posed by geographies of media, the role and significance of different media forms and organizations in relation to socio-spatial relations, the dynamism of media in local-global relations, and in-depth case studies of mediated locales. Given the theoretical and methodological diversity of this book, it will provide an important reference for geographers and other interdisciplinary scholars working in cultural and media studies, researchers in environmental studies, sociology, visual anthropology, new technologies, and political science, who seek to understand and explore the interconnections of media, space and place through the examples of specific practices and settings.
Susan P. Mains is a Lecturer in Human Geography at the University of Dundee. Her work explores transnational identities and media representations of mobility, borders, and security in the context of Caribbean migration, creative industries in Jamaica and Scotland, and heritage tourism. She has published in a range of international journals including Social and Cultural Geography, GeoJournal, Journal of Geography in Higher Education, The Singapore Journal of Tropical Geography, Small Axe: A Caribbean Journal of Criticism, and Caribbean Geography. Her previous work has been funded through the University of the West Indies, the Association of American Geographers and the American Geographical Society. Currently she is the coordinator for a Carnegie Trust funded project, "Ties to the Tay," which utilises participatory filmmaking as part of an interdisciplinary project between a group of academics at the University of Dundee, the Nethergate Writers, artists, and community organisations. She is also a partner in a Royal Society of Edinburgh funded collaborative project exploring representations of place and landscape connections between the Scottish Highlands and the Caribbean. Julie Cupples is Reader in Human Geography and Co-Director of the Global Development Academy at the University of Edinburgh. She joined the University of Edinburgh in 2013 after more than a decade working at the University of Canterbury in New Zealand. Her research interests span cultural geography, development studies and media and cultural studies. Since the early 1990s, she has been working in Central America, primarily Nicaragua, and has published widely on questions of development/postdevelopment; revolution and conflict; neoliberal economic policies; gender; disasters and environmental risk; electoral geographies and municipal governance. She is currently engaged in a collaborative research project exploring the geographic dimensions of media convergence, funded by the Marsden Fund of the Royal Society of New Zealand. This project is exploring the democratizing and decolonizing dimensions of the new media environment, with a focus on mainstream entertainment media as well as community and indigenous media operations. She is the author of Latin American Development (Routledge, 2013) and the co-author of Media/Communications/Geographies: Interdisciplinary Perspectives (forthcoming with Routledge). Chris Lukinbeal holds a B.S., M.A., and Ph.D. in Geography. He is an Associate Professor and Associate Director in the School of Geography and Development at The University of Arizona and the Director of Geographic Information Systems Technology programs and of the Geospatial Innovation Science and Technology center. He has published over 50 academic papers and book chapters related to topics ranging from representation, media, GIS, remote sensing, cartography, urban geography, mental maps and GIS, landscape studies, and education.
Introducing Mediated Geographies and Geographies of Media
Cupples, Julie (et al.)
Film Geography: A Review and Prospectus
Sharp, Laura (et al.)
TV and the Spaces of Everyday Life
Spigel, Lynn
Cultural Industries and the (Geographical) Political Economy of the Media
Christophers, Brett
A Brief History of Mediated, Sensational and Virtual Geographies
Aitken, Stuart C. (et al.)
Chinese Cinema Cities: From the Margins to the Middle Kingdom
Curtin, Michael
US Television Travels Abroad: Global TV and the Formatting Trend
Fletchall, Ann
Geographies of the News
Gasher, Mike
Remember the Alamo: A Place of Cinematic Experience
Zonn, Leo
Vertical Mediation: Geospatial Imagery and the US Wars in Afghanistan and Iraq
Parks, Lisa
The Digital Globe and New Mediations of the Environment
Gurevitch, Leon
GIS as Media Through the Geoweb
Sui, Daniel (et al.)
GIS as Media?
Wilson, Matthew W. (et al.)
Crowd-Sourced Augmented Realities: Social Media and the Power of Digital Representation
Zook, Matthew (et al.)
Science Blogging Below-the-Line: A Progressive Sense of Place?
Mendel, Jonathan (et al.)
From Webcams to Facebook: Gay/Queer Men and the Performance of Situatedness-in-Displacement
Hillis, Ken (et al.)
Placing Satellite Radio in the Contemporary Radio Landscape
Keough, Sara Beth, Ph.D.
Visibility, Media Events and Convergence Culture: Struggles for the Meaning of 9/11
Glynn, Kevin
The Case of the Missing Laureate: The Communication Geography of the 2010 Nobel Peace Prize
Adams, Paul C.
From Bolt to Brand: Olympic Celebrations, Tourist Destinations and Media Landscapes
Mains, Susan P.
Development Communication, Popular Pleasure and Media Convergence
Cupples, Julie
Indigenous Media: Linking the Local, Translocal, Global and Virtual
Wilson, Pamela
Salsation: Affective Encounters and the Right to the City
Johnson, Tamara M.
Mediated Geographies Across Arizona: Learning Literacy Skills Through Filmmaking
Lukinbeal, Chris (et al.)
Indigenous Media and Postcolonial Pedagogy
Smith, Laurel C.
Owning and Sharing Experiences of Adventure: Tourism, Video and Editing Practices
Laurier, Eric
Susan P. Mains
Julie Cupples
Chris Lukinbeal
Springer Science+Business Media Dordrecht
IX, 470

redpajama_set_name: RedPajamaCommonCrawl


11/06/2013 · same problem here... i too downloaded the game... the guys talk in english but everything else[the text] is in russian... i saw this forum bfore too and tried changing the xml file but even after changing it to english nothing happnd, everthin's still in russian... and in the game files, under the local folder, there are two folders english and how to change french keyboard to english windows 8 I can not figure out how to change audio. It lists it as an option in the Language part of the settings, but you can not click it or anything. It lists it as an option in the Language part of the settings, but you can not click it or anything.


Democrat Aimee Belgard, a Burlington County freeholder, and Republican businessman Tom MacArthur, former mayor of Randolph in Morris County, are running for the seat left open by Jon Runyan.
Watch videos of Aimee Belgard and Tom MacArthur on issues including legalization of marijuana, education, energy vs. environment and college loan restructuring.
3rd Congressional District candidate Aimee Belgard offers a brief introduction and some of her background.
What are your thoughts on college loan and college cost restructuring?
What are your thoughts on Joint Base McGuire-Dix-Lakehurst?
How do you plan to balance energy concerns with environmental concerns?
What is the biggest issue with education in the 3rd Congressional District and how would you address it?
Where do you stand with public school reform and the rise of charter schools?
Where do you stand on the legalization of marijuana and medical marijuana?
What would you like to see change, in terms of womens health issues?
Other than armed services, what congressional committees would you be interested in serving on?
What are your thoughts on immigration reform?
The role of government and infrastructure on a state level.
Who from the other side do you think has had good ideas over the years?
You say you're running for the future. What do you see your children's future looking like?
Talk about how John Adler, the previous Democrat to hold this seat, influenced you.
Where do you stand on issues of equality?
Do you think the gridlock in government is necessary?
Who in Congress do you consider a role model?
Who do you see as role models; someone who has worked across the table.


Description: I speak fluent ENGLISH,and french and spanish. I am originally from Puerto Rico. I am working hard to build a stable life, that I can share with someone. I like to hang out, watch movies, and go to the mall. Call me or email me to say hi! Description in Spanish: Description in Spanish: Hablo el INGLES fluido, y el frances y el espanol. Soy al de Puerto Rico. Trabajo mucho para construir una vida estable, que puedo compartir con alguien. Me gusta andar, mirar peliculas, e ir a la alameda. Llameme o envieme por correo electronico para decir hola!
Christina Reyes is an attractive latin american girl from United States looking for a relationship with a man. You can buy the contact details of this latin american girl in order to contact her today. If you like Christina Reyes, you can search for other latin american girls from Detroit and nearby. You can browse many more beautiful latin american women on LatinRomantic today. If you are interested in dating latin american women like Christina Reyes, our website will help you find your match.


Set to launch on September 8, this world's first ocean cleanup system consists of pipes that float at the surface of the water with netting below, and will collect trash in the center of a U-shaped design, with the aid of the ocean's currents.
The goal is to essentially rid plastic pollution in this particular area and prevent it from spreading in all directions of the ocean landscape, as plastic waste can harm and even kill whales, dolphins, seals, fish and other type of marine life that will consume it or become entangled in it.
You can learn more about the initiative, its progress and how it works in the videos below, as well as the featured clip above.
[36 days to launch] The crew has started lowering the system into the lagoon. This operation will progress in sync with the skirt assembly. Once completed, we will proceed with the installation of stabilizers and electronics.
For even more details, head over to The Ocean Cleanup's YouTube channel and official website by clicking the bars below.
Now, is sustainable fashion completely pointless? Read our exclusive op-ed here.


text:
Q: Login authentication with Ember-cli, Rails and ember-cli-simple-auth-token I have created an ember-cli project (v 0.1.12) with ember.js (v 1.8.1) and Rails. Than I tried to install:
https://www.npmjs.com/package/ember-cli-simple-auth-token
but when I run the login POST the server responds to me with this error:

Can't verify CSRF token authenticity.

I notice that it sends only username and password, without token. What's going on here?

A: The short answer is that you can fix that issue in the development setting by disabling CSRF tokens all together. You wouldn't use that in production but you can at least disable it to confirm that the issue gets fixed. In the application_controller.rb file, remove: protect_from_forgery line. Also go to your session_store.rb file in initializers and set:
# Be sure to restart your server when you modify this file.

Rails.application.config.session_store :disabled

Once you get things working, you can re-add the protect_from_forgery line as so:
protect_from_forgery with: :null_session

redpajama_set_name: RedPajamaStackExchange


Adare Villas is situated in the picturesque village of Adare, Co. Limerick - the gateway to Southwest Ireland. Europe's famous Shannon International Airport is just a 30-minute drive away, Cork Airport a 90-minute drive and Dublin Airport 2 hours and 30 minutes from us. And with connecting flights to most major European and US cities from all three airports, we really are at the heart of the action.
Adare Villas is the ideal base from which to explore some of Ireland's most notable visitor attractions and the world's most beautiful sights such as breath-taking Cliffs of Moher (an hour and a half drive), the stunning Dingle Penninsula (a two hour drive), the 15th century Bunratty Castle & Folk Park (a 20 minute drive) and the unmissable Killarney town (an hour and fifteen minutes drive).


text:
Q: Compare 2 columns in excel using python Hello I have an excel file (.xlsx) with 2 columns of data I want to compare the rows in column A with column B and output the value of column B in another generated excel file where the rows column A are  empty.
Any Help would be greatly appreciated
Excel file showing data in column A and column B

A: This code snippet should do the trick:
import pandas as pd

df = pd.read_excel(io="file.xlsx", header=0)
df = df[df['A'].isna()]
df.to_excel("new_file.xlsx", columns=['B'], index=False)