bdxStrings: string processing modules for OpenDX

bdxStrings is a set of modules (runtime loadables and macros) designed to enhance string processing capabilities in OpenDX. This distribution includes the source code, documentation, and test scripts for the following modules. (See documentation.) 
    strCompare	 m	Compares strings lexicographically.
    strContains	 m	Tests for substring containment.
    strFormat	 r	Formats data as strings; Format() on steroids.
    strJoin	 r	Concatenates a list of strings.
    strLength	 m	Returns the lengths of strings.
    strParse	 r	Parses values from strings; Parse() on steroids.
    strRegex	 r	Finds regular expression matches in strings.
    strRegSplit	 r	Splits strings at matches to regular expressions.
    strRegSub	 r	Replaces regular expression matches with replacement strings
    strSplice	 r	Splices strings into strings; substring extractor.
    strTranslate r	Translates strings, character-for-character.
    strTrim	 m	Removes whitespace from the ends of strings.
(r=runtime loadable module; m=macro)
These modules came about because I wanted to use OpenDX to visualize bioinformatics data. This domain deals heavily in string data (and I'm not even referring to DNA sequences here), so OpenDX's lack of string processing functions was a real problem. I wrote these modules as a result. Some of them (like strFormat and strParse) are reimplementations of standard modules providing expanded functionality. Some (like strSplice and strRegex) are wholly new. And some (like strLength and strCompare) are included merely for completeness and a bit of convenience.

This is a beta release. Please suggest changes and improvements, and report any bugs to me. Thanks!

Joel Richardson, Ph.D.
Sr. Research Scientist
Mouse Genome Informatics
The Jackson Laboratory
Bar Harbor, Maine 04609
jer@informatics.jax.org.

Downloads

These modules have been built and tested under Solaris 8 and Mac OS X 10.3.9. I have not built them under Windows, though I have no reason to think this would be any trouble for someone familiar with that environment (I'm not). The loadables only call standard C library functions.
StringModules.pdf Documentation. (Also included in the tarballs.)
bdxmods-beta-1.0.tar.gz Just the source.
bdxmods-beta-1.0-macos-10.3.tar.gz Prebuilt binary for Mac OS X 10.3.
bdxmods-beta-1.0-solaris-8.tar.gz Prebuilt binary for Solaris 8.

Installation

I'd definitely like to improve the following installation process and to include a Windows build. Any help will be much appeciated and gratefully acknowledged. 

To build the string modules from source:

1. Unpack the tarball:
	% gunzip bdxmods-1.0.tar.gz
	% tar xvf bdxmods-1.0.tar
   This creates a subdirectory tree, named 'bdxmods', rooted
   in the current directory. If you downloaded one of the 
   prebuilt binaries, the files you need are already in the
   build subdirectory, and you should skip to step 5.

2. Go down to the top-level directory:
	% cd bdxmods

3. Be sure DXROOT is defined, and run the configure script:
	% Configure
   This generates a Makefile.

4. Run make, with the argument TARGET=strings
	% make TARGET=strings
   This creates two files in the build directory: bdxModules.so
   and bdxModules.mdf. It also copies the macros into this directory.

5. To complete the installation, you'll need to move these files
   (bdxModules.so, bdxModules.mdf and the macros) and/or 
   set some environment variables. Unfortunately, there is no standard 
   installation procedure for dx extensions. The following is only an
   outline of one possible recipe. You will need to adapt this
   to your own environment and taste.

   You should be familiar with the OpenDX User's Guide Sections 5.1, 9.2, and Appendix C.1. 

   To use the new modules, you have to tell DX where they are. 
   One way to do this is by defining environment variables. 
   Leaving everything in the build directory, we could do the
   following. (Assume the installation directory is
   /Users/you/dxstuff/bdxmods).

   a. Add /Users/you/dxstuff/bdxmods/build to DXMODULES. This
   tells dx where to find the runtime loadables. 
   b. Set DXMDF to /Users/you/dxstuff/bdxmods/build/bdxModules.mdf.
   This tells dx to load the runtime loadables automatically at startup.
   You can also do this manually from within the VPE by going to
   File->Load Module(s), and selecting this file.
   c. Add /Users/you/dxstuff/bdxmods/build to DXMACROS. This
   tells dx where to find the macros.

   Under Solaris (and, I assume, Linux though I've not tested it),
   you can define the variables in your .cshrc or .bashrc or whatever. 
   For example, in .bashrc:

	export DXMODULES=/Users/you/dxstuff/bdxmods/build
	export DXMDF=/Users/you/dxstuff/bdxmods/build/bdxModules.mdf
	export DXMACROS=/Users/you/dxstuff/bdxmods/build

   Under Mac OS X, this works as long as you launch dx from the command line. 
   If you launch it from the task bar, you have to define these variables in the 
   file $(HOME)/.MacOSX/environment.plist.
   You also have to log out and back in for the changes to take effect.
   For example,

        <key>DXMODULES</key>
        <string>/Users/you/dxstuff/bdxmods/build</string>
        <key>DXMDF</key>
        <string>/Users/you/dxstuff/bdxmods/build/bdxModules.mdf</string>
        <key>DXMACROS</key>
        <string>/Users/you/dxstuff/bdxmods/build</string>

6. Test the installation. In the ./tests directory are several nets
   you can run to test that the installation was successful. The tests
   also serve as demos.