[Dirvish] the Options hash, and a testing dilemma (2)

Keith Lofstrom keithl at kl-ic.com
Thu Feb 10 17:38:20 PST 2005


On Fri, Feb 11, 2005 at 12:00:46AM +0100, Eric Mountain wrote:

> The install script is something that needs to go away in its present form.  
> OK, maybe keep it in the next stable release, but deprecate it and remove it 
> in the following stable release.  We really need to target a "standard" 
> install method along the lines of what has previously been discussed on the 
> list.
> 
> This means finding a nice way to deal with $CONFDIR, and factoring it out into 
> a separate Perl module so that at least if we have to keep it there is just 
> one place to look (and update when installing the code, rather than updating 
> every script).

My plan is to put $CONFDIR it in dirvishlib.pm for now.  I like the idea of
looking for an environmental variable;  I suggest we have a default $CONFDIR,
but look for an environmental variable FIRST.  That way, a test script, or
a cron script, can set the variable before running dirvish.

Keith wrote:
> > I suggest adding an additional option, --cleanoptions .  When this
> > option is encountered, we run an anonymous subroutine that cleans
> > out the $Options hash (and any previous options - we restore to
> > the original $Options contents.   

Keith adds:
I am working on some code with --reset=default.  This makes a second call
to a routine "reset-options()" [ maybe that should be "init-options()" ]
that puts everything back.

Keith wrote:
> > I would like to see GetOptions processed
> > before we read any configuration files at all, but I cannot see how
> > to do that without changing the existing runtime behavior.  That would
> > be unacceptable.

Eric writes:
> Dirvish's behaviour in this respect is totally non-standard and off-putting.  
> It may be in Dirvish's interest to eventually break backward compatibility 
> one day to fix this.

Keith responds:
There are advantages to being able to stack configs the way jw set things
up.  I have quite a fear of messing up someone's carefully piled up stack
of configs by changing the way the code works.  OTOH, if we move enough
standard behavior into the library, and keep the strangeness confined
to portions of the dirvish app itself, then maintaining a "Classic"
version and a "New" version should be easy.

On the subject of testing:

Last night at Portland Perl Mongers, I got some good advice from chromatic . 
He suggested that we use a feature of the Test::Module library which
allows tests to reach inside an app and replace the contents of variables
during runtime.  This means that, for example, we can build tests that
force the time variables to take particular values so we can get
repeatable test results.

The meeting was focused on using Devel::Cover as part of the Phalanx
project to improve the popular CPAN modules.  Devel::Cover measures test
coverage, and tells you whether your tests are testing all the logic
and branches in the program.  I hope we can use that sometime in the
future.

Keith

-- 
Keith Lofstrom          keithl at keithl.com         Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs


More information about the Dirvish mailing list