On Friday, May 31, 2002, at 02:30 , Sharan Hiremath wrote:
[..]
> It is not the config file which will be used via require.
I'm Gonna toss this back into the list - since this is a
'design issue' that I fear can frag other folks as well...
{ I think we all abuse the 'use', 'require' , 'do' sequences
at times - and perchance shouldn't - I know , I had to do a
'require foo' trick in a subroutine - so that it would ONLY
be invoked on the machine where foo was installed... Since
I could not do a 'use foo' as I would normally have done.}
So clearly scoping out jeff's idea of
perldoc -f do
would be a first place to play.
> I have some n testcases, I will be reading testcase one by one, checking
> and modifying certain syntax in it and copying to /tmp/test.pl and there
> one subroutine called "executeTest" in all the files. So after require I
> just execute this function.
Interesting Idea...
eg something like:
my $file = "/tmp/testMePlease.pl";
for my $testCase (@testCaseList) {
GrovelCase($testCase, $file); # where we hid the process of taking
# input
stuff and making our $file
# ripped off from perldoc -f do
unless ( my $return = do $file ) {
warn "Do of $testCase fragged with ";
warn "couldn't parse $file: $@" if $@;
warn "couldn't do $file: $!" unless defined $return;
warn "couldn't run $file" unless $return;
next; # we will not be able to execute it so next File
}
print "Spinning up testCase $testCase\n";
executeTest(@baseArgs);
} # end of for testCase in CaseList....
The idea here being that we are in essence either
a) rewriting the function 'executeTest' each time we
GrovelCase() from the testCase list into our file here
b) we really have only one 'function' that has a common
call that is re-written n-times.... Not that unlike
the problem of all 'objects' need to have a 'new'
and a DESTROY method in them...
Not sure I like either strategy per se. But I guess it is
one way to check perl syntax 'autoMajikally'????
Is this a QA test harness of some sort????
The other approach would be to look at the data sets that
you are playing with and resolve if there is a more reasonable
relationship between the input data and the code that does stuff
with the data....
If you peek at my re-write of Lance's code from yesterday:
http://www.wetware.com/drieux/pbl/Auslanders/alt300.txt
I converted it into a basic 'hash over' so that we can move to
the next round of experimentation where we change the relationships
inside the two Hash's and see how the behavior of the core
algorithm works itself out....
> So I was using require do load the test file and calling executeTest,
> problem with that is as the file /tmp/test.pl is loaded once, will not
> consider the later require calls. So I was not able to execute further
> testcases.
clearly you will want to scope out
perldoc -f require
and you will notice that semantically that is precisely what it
should be doing as it is checking to see IF it has already seen
$filename in %INC - as part of it's way of not 'resourcing' the
library more than once...
Jason - remember this is a part of what bit you in the butt with
the idea of having a package like thinging that we source once
in the application, and once in the perl module that also needs
to know about function foo()....
Think about this happy Kampfr's - for those with any 'c' code
time you will always remember seeing skank like
#ifndef _SEEN_THIS_HEADER_FILE
#define _SEEN_THIS_HEADER_FILE 1
..... /* the actual include foo header stuff */
#endif /*only need to have seen this once */
since let us be honest, compilers are not god's brightest children.
[..]
ciao
drieux
---
Software - it was a bad idea to begin with,
and it just has not improved with age....
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
