Ignore:
Timestamp:
Jan 28, 2010 5:53:15 PM (10 years ago)
Author:
wehart
Message:

Merged revisions 2112-2195 via svnmerge from
https://software.sandia.gov/svn/public/coopr/coopr.opt/trunk

........

r2137 | wehart | 2010-01-10 12:17:40 -0700 (Sun, 10 Jan 2010) | 2 lines


Misc documentation updates.

........

r2155 | wehart | 2010-01-12 15:25:13 -0700 (Tue, 12 Jan 2010) | 2 lines


Adding a utility routine: results_attributes.

........

r2167 | jwatson | 2010-01-24 14:06:15 -0700 (Sun, 24 Jan 2010) | 3 lines


Added a _report_timing attribute to the base solver class. If true, it will print out presolve/solve/postsolve timing statistics. The derived shell-based solver will additionally report log and solution file read times.

........

r2173 | wehart | 2010-01-27 10:23:31 -0700 (Wed, 27 Jan 2010) | 2 lines


Misc edits.

........

r2174 | wehart | 2010-01-27 10:31:26 -0700 (Wed, 27 Jan 2010) | 2 lines


Adding a hook for specifying the format for reading/writing IO formats.

........

r2182 | wehart | 2010-01-27 15:39:31 -0700 (Wed, 27 Jan 2010) | 2 lines


Removing colin stuff from coopr.opt.

........

r2186 | wehart | 2010-01-27 17:39:31 -0700 (Wed, 27 Jan 2010) | 2 lines


Renaming results_attributes to results_schema.

........

Location:
coopr.opt/stable/2.2
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • coopr.opt/stable/2.2

  • coopr.opt/stable/2.2/doc/opt/plugins-pca.tex

    r1828 r2196  
    1111Trac~\cite{Trac}, yapsy~\cite{yapsy} and SprinklesPy~\cite{SprinklesPy}.
    1212Although we discuss the design requirements for PCA later, PCA was
    13 initially motivated by the desire to use Trac's plugin framework within
    14 a self-contained packages.  The core of PCA is provided by PyUtilib's
     13initially motivated by the need to have a Trac-like plugin framework that was
     14self-contained.  The core of PCA is provided by PyUtilib's
    1515\code{pyutilib.plugin.core} module.
    1616
     
    2626A software application can declare \textit{extension points} that other
    2727components can \textit{plug in} to. This mechanisms supports a flexible,
    28 modular programming paradigm that enables software applications can
     28modular programming paradigm that enables software applications to
    2929be extended in a dynamic manner. Extension points and the extensions
    3030contributed to them are stored in a global registry, and execution of
     
    3434needing to know the details of how they are employed.
    3535
    36 Extension points are defined with respect to an \textit{interface} class
    37 that implicitly defines the registration type that is used for a
    38 plugin. Further, a plugin class includes a declaration that it implements
     36Extension points are defined with respect to an \textit{interface} class,
     37which defines the type that plugins use to register their capabilies.
     38A plugin class includes declarations that denote that it implements
    3939one-or-more interfaces. An interface is defined by the methods and data
    4040that are used. However, the PCA does not enforce
     
    7474API conformance for plugins, and hence any declaration in the \code{MyInterface}
    7575class would be ignored. Additionally, note that an instance of \code{MyInterface}
    76 is not created; declaring the plugin interface simply requires the
    77 specification of a subclass of \code{Interface}.
     76is not created; the \code{MyInterface} class is simply used to declare a type that is used to index related plugins.
    7877
    7978An instance of \code{ExtensionPoint} can be used to iterate through
     
    102101
    103102#
    104 # This loop iterates over all servicess, including the 'disabled'
     103# This loop iterates over all services, including the 'disabled'
    105104# services.
    106105#
Note: See TracChangeset for help on using the changeset viewer.