CADSWES Maintenance Accomplishment Report Compilation -- August 2014
Edit: 9-3-2014 (Phil)
Report contributors:
(II) RiverWare Software Maintenance
|
The following releases were generated in August:
RiverWare 6.5 release notes can be found in:
The following bugs were fixed:
*Bug 5531 Detail:
Distributed MRM was not using the configured index sequential initial offset or the traces first trace when distributing runs. This meant that the distribution always began with trace 1. This has been fixed.
Decomissioning maelstrom
Over the years RiverWare development has migrated from Solaris to Windows and Linux, to the extent that a single Solaris machine (maelstrom) remained. maelstrom was used for a small number of tasks. It was decided to decommision maelstrom and complete the migration from Solaris. Tasks included:
- Deploying our Support Tool (for logging user support time) on Alamosa (linux). The support tool is written in Java and was a fairly straightforward port from Solaris to Linux.
- Deploying "modelcomp" with xmgr -- for comparing model files and plotting differences -- on Alamosa. Attempts to find a Linux xmgr binary which could be installed were unsuccessful. Subsequent attempts to find source code which could be compiled were successful.
- Confirming usability of Flex/Bison (parsing library) tools on Alamosa. These are used within RiverWare for processing files having particular grammars, e.g. RPL ruleset and SCT files.
Windows Development Tools
RiverWare development requires a sophisticated development environment with several third party tools and libraries. Over the years an infrastructure has been developed for configuring Windows machines for RiverWare development. The infrastructure used both CVS (a source control system) and tar files for deploying the development environment. There were two problems with the infrastructure. First, using CVS was a "chicken and the egg" situation - CVS was necessary to install CVS on a Windows machine. Second, portions of the development environment had become fragmented across three directories (bin, bin.reorg and perllib). The reasons for the fragmentation are known to but a single RiverWare developer, and he isn't talking. Anyway, the decision was made to ditch CVS, to combine the three directories into a single directory, and to jettison tools which are no longer being used. This was accomplished and greatly simplified configuring Windows machine for RiverWare development.
Oh Say Can You Not C!
From the beginning RiverWare Windows development has been on the C: partition, in C:\RiverWare. This seems to be counter to "best practices" which separate data from the operating system to facilitate backing up data independently from the operating system. Some RiverWare tools relied on RiverWare development being in C:\RiverWare; the tools were modified to be accepting of other partitions. (They use heuristics to locate directories which are known to be part of the RiverWare development environment).
Creating a Development Environment on Windows 8.1
CADSWES staff configured a Windows 8.1 machine to support RiverWare development and created a document describing the procedures for doing this on other machines. To illustrate, the following are some of the steps involved in configuring a machine for RiverWare development:
- Install the compiler (Visual Studio 2010)
- Install third party software libraries (e.g., Qt and GDAL)
- Install configuration management tools (e.g., the source code versioning application, git, and a custom script for conducting regression tests)
- Configure permissions for access to remote source code repositories
- Create a local copy of the source code repository
As part of this work, problems were identified with the existing script for installing RiverWare libraries and that script was significantly redesigned.
The regression tests continue to be maintained on a daily basis. This involves updating the regression tests to exercise new developments in the code. Also, as new code is added to the development area, the model comparisons performed in the nightly regression tests usually show differences (for example, because a new method category may have been added). When this occurs, the regression tests need to be updated to reflect the current state of the development area so model comparisons do not fail. In addition, every week, the daily history of each regression test is analyzed to determine if the run time or model size has significantly changed because of new development.
None reported for August 2014
None reported for August 2014
--- (end) ---