Some examples of adding a code to the build procedure and converting to a Pyre component

From DANSE

• The Pyre tutorial at http://www.cacr.caltech.edu/projects/pyre/ has examples of basic Pyre component structure and usage. There is also a section on modifying Pyre properties.

• The "templates" package provides a means for automatically generating a template package. Although there are no Pyre components created, "templates" demonstrates how to structure code objects using the build procedure. You can checkout "templates" from :pserver:pyre@cvs.cacr.caltech.edu:/pyre (see instructions for Installing build procedure and framework). By typing "package.sh foo", a new package "foo" is created. In the "foo" directory, you should now see

   examples/ foo/ foomodule/ libfoo/ Make.mm tests/ 

  where the structure is defined as follows:
  • examples == This is where scripts and components that use your "foo" components should go. There are no templated examples, but the Make.mm file for this directory is already generated for you and only needs the names of your example scipts to be added to it.
  • foo == This is where the main python code for the package lives. Note that a "python" code directory needs a "__init__.py" file, and the "Make.mm" file to tell the directory how to build. The "__init__.py" file only provides the "copyright" function, however other functions or python code can be easily added.
  • foomodule == This is the bindings directory. The code that defines how Python handles "bindings", "exceptions", and "misc" with the lower-level language resides here. Note that "non-python" (i.e. C, Fortran, ...) directories require both a "local.def" and a "Make.mm" file. A "local.def" file adds any additional include/compile/build flags for the directory. If you are only writing in python, you will not need this directory.
  • libfoo == This is where the pure lower-level language code resides. This is where your legacy code should be deposited. The "Make.mm" file in this directory directs a shared object library to be built from the included sources.
  • tests == This is where the (unit) tests should reside. Note that the code is NOT exported from this directory. Also note that "signon.py" tests both a function call of 'copyright' (from the python code) and 'hello' (from the bound lower-level language library).

• The directory "phonon_calcs/multiphonon" in the repository on arcs.cacr.caltech.edu has a simple example of how to convert a python script to a Pyre component (checkout "phonon_calcs"). The file "Multiphonon.py" is the original source, and has "run" as the main function that controlls execution of the code. "PyreMultiphonon.py" is the Pyre implementation of the original code. Note that 'Multiphonon.run' is exactly reproduced in 'PyreMultiphonon.run' (between the "### MAIN CODE BLOCK ###" comments), and the rest of the code in "PyreMultiphonon.py" is fairly reusable as a template for other Pyre components. There is also a very simple example of how to use "PyreMultiphonon.py" from within another script or component; you can find it at "phonon_calcs/multiphonon/example/simple.py" (refer here for a more extensive discussion on components calling other components). There is also the beginnings of a unit test suite at "phonon_calcs/multiphonon/tests/PyreMultiphononTests.py" (there are _much_ better examples of unit testing in the arcs.cacr.caltech.edu repository under "packages/ins/reduction/tests" and "packages/phonons/bvkfit-0.2/tests").

• Some generic file readers and writers can be found in the repository on arcs.cacr.caltech.edu in tutorials/reader-writer. A discussion of these applications can also be found here.