Monday, January 26, 2009

Another Discussion of Python Plugins

Here's a nice discussion and comparison of Python plugin frameworks that I ran across today: Design Docs Plugins - PiTiViWiKi. This notes that a big difference between Zope and Trac plugins is that Zope defines interfaces which allows for checking interface implementation/definition, as well as facilities for plugin adapters. In this respect, the Envisage Core plugins are similar to Zope.

Python Plugin Frameworks

Updated to include pointers to the PyUtilib Component Architecture and PnP.

Various Python projects I am working on could benefit from the use of a Plug-in framework.  However, there does not appear to be a standard Python plug-in framework, though there are some mature packages that support plug-ins.

Here's a summary of my recent web research:
  • yapsy - This is a simple plug-in framework that was designed specifically to support plug-ins with no external dependencies.
  • Mary Alchin describes a simple plugin framework, with a similar goal.  His classes provide an API for the plugins, with few supporting features (e.g. searching for plugins).
  • AndrĂ© Roberge has a series of posts that describe the application of plugins to refactor a simple calculator application.  The goal of this is to illustrate the requirements for plugin frameworks, with the goal of identifying best practices for plugins. There are some interesting replies to this post, which consider implementations of the plugins he proposes in zope and grok. Both of these pull in quite a few libraries, which begs the question of whether it makes sense for external users to rely on these components for only plugin support.
  • Enthought's Envisage project includes a framework for building extensible, pluggable applications.  The enthough.envisage package defines these capabilities, and there is nice documentation here.
  • Trac and Zope are frameworks that incorporate plug-ins, and these capabilities may be modular enough for use in other applications. Trac's component architecture is detailed in the Trac wiki pages. Zope's plug-ins appear to be called products (see also here). Martin Aspeli describes his experience writing Trac plug-ins and contrasts them with Zope.
  • The PyUtilib Component Architecture (PCA) is a component architecture in Python that is derived from the Trac component framework. One important extension was to support both singleton and non-singleton plugins. Singleton plugins are created immediately when the plugin module is loaded, which is well-suited for persistent applications like Trac. However, many other applications need to employ plugins "on demand", which need to be explicitly constructed by the end-user. (See the PyUtilib wiki for further details.)
  • Plug n' PLay (PnP) is a Generic plug-in system inspired by Trac's internal component management. PnP is roughly a implementation of the Observer pattern (http://en.wikipedia.org/wiki/Observer_pattern).
     
These resources highlight one reason why there is not a standard Python plug-in framework: there are a variety of different capabilities that a user may want, and the complexity of the framework generally increases as these new capabilities are added (e.g. security, API validation, etc). Another item that seems clear is that while a variety of packages support plug-ins, many of them do not use them in a modular fashion.  Thus, it is difficult to reuse sophisticated plug-in frameworks without incorporating a lot of extraneous code.

Tuesday, January 20, 2009

A Python Trick: Adding a Lambda Method to a Class

It does not take much to add a lambda function to a Python class. For example, consider the following:

>>> class A: pass
>>> f = lambda self,x:x
>>> setattr(A,"f",f)

This code adds the method f to class A. For example:

>>> a=A()
>>> a.f(1)
1

However, the f method created this way does not have the expected Python name:

>>> A.f.__name__
''

Further, defining this value is not possible; the instancemethod f does not have a __name__ attribute.

The trick is to name the lambda function before defining the class method:

>>> class A: pass
>>> f = lambda self,x:x
>>> f.__name__ = "f"
>>> setattr(A,"f",f)
>>> f.__name__
'f'

This is simple, but it took too long to figure this out...

Interrupting the UNIX time command

Consider the following use of the standard Unix time command:
/usr/bin/time ls -R /

If the SIGTERM signal is sent to the time process, then the ls process will continue! This is an unexpected behavior, which is not well-documented.

Normally, this is not much of an issue; the process that is monitored will simply terminate quietly. However, when the time utility is used in interactive applications, process interrupts can lead to many unexpected rogue processes.

The timer command is a modification of the UNIX timing utility that behaves as expected. When using timer, the SIGTERM signal is sent to the process, which terminates it as expected. The timer command is available in the UTILIB software library, but it can be compiled independently.

Monday, January 19, 2009

Monitoring Maximum Memory Usage in Linux

There are many tools available that can be used to monitor memory usage in computer programs. However, there are few tools that can be applied to monitor the memory usage of a specific process in an automated manner. Most memory monitoring tools provide a gui that a user can monitor.

However, these tools are not useful in contexts where memory must be monitored repeatedly. For example, automated software tests may require checks to validate that the memory usage does not exceed expected limits.

The memmon command is a new memory monitoring tool that is included in the UTILIB software library. memmon provides a convenient mechanism to report the maximum amount of memory that a process uses.

The memmon command requires the absolute path to the command that will be executed. Beyond that, its default syntax is quite simple:
$ ./memmon /bin/sleep 1
53768 Kb used


The memmon command can also be used to terminate a process whose memory exceeds a specified threshold:

$ ./memmon -k 10 /bin/sleep 1
./memmon: Error: memory exceeded
53764 Kb used


At present, memmon only supports memory monitoring on Linux platforms. However, it is not clear how its capability could be ported to other operating systems. I am particularly interested in this capability on MS Windows, if anyone has ideas for how to do that...

Software Releases

I have not blogged much this fall because I have been busy managing a variety of software releases.  I plan to include further details in upcoming blogs, but I thought I would summarize these releases here:
  • acro 2.0 - Acro is A Common Repository for Optimizers that integrates a rich variety of optimization libraries and solvers that have been developed for large-scale engineering and scientific applications. Acro was developed to facilitate the design, development, integration and support of optimization software libraries. Thus, Acro includes both individual optimization solvers as well as optimization frameworks that provide abstract interfaces for flexible interoperability of solver components. Furthermore, many solvers included in Acro can exploit parallel computing resources to solve optimization problems more quickly.

  • utilib 4.0 - Utilib is a library of general-purpose C++ utilities, similar in spirit to the Boost libraries. While generally treated as an Acro package, Utilib is hosted in a separate subversion repository to facilitate use by projects outside of Acro.

  • PyUtilib 1.0 - PyUtilib is yet another a Python utility library. PyUtilib supports several Python projects under development at Sandia National Laboratories, including Acro, Coopr and FAST.

  • FAST 2.0 - FAST provides a collection of Python tools that support software testing. In it's current form, this does not really constitute a framework, but the plan is to develop a set of tools that support comprehensive testing of software tools.

  • Coopr 1.0 - The Coopr Python package integrates a variety of Python optimization-related packages. Most of these packages rely on externally built optimization solvers. In particular, the Acro software builds many optimizers used by Coopr packages.

The Trac wikis for these packages contain a variety of tools that I'll describe in more detail later...