module-build-general

[Module::Build] notes on notes

[Uri G. <ur...@st...>]

ok, i rtfm'ed and see what the notes method does. so my first question
is why does new even handle a passed in args attribute (especially as it
is not documented nor meant to be used)?

the second question is how do we punish that scalawag dave for using an
undocumented feature and leading me down that evil path?

on a related note (sic), i have been looking at prompt and y_n. i had
written very similar subs in my soon to be deleted stem install script
and i had transplanted them to my build stuff. so i will replace them
with build's method (almost a drop in replacement). my prompts can ber
very long (using here docs of course) since i sometime describe the
queries in detail. now, i noticed that the example does the config
queries in Build.PL and stores the results in notes in the build
object. i was doing the queries in the install action. is there a reason
to do it one way or another? the only time i seem to need those values
is in the install action. also dave wrote something that writes out
those values into a stem module. if i need them in test script or
whatever, i could just use that module.

finally, in looking at y_n:

  my $answer;
  while (1) {
    $answer = $self->prompt(@_);
    return 1 if $answer =~ /^y/i;
    return 0 if $answer =~ /^n/i;
    print "Please answer 'y' or 'n'.\n";
  }

any reason why the assignment to $answer isn't my'ed instead of doing it
before the loop?

inquiring minds want to know,

uri

-- 
Uri Guttman  ------  ur...@st...  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org

Re: [Module::Build] notes on notes

[Randy W. S. <Ra...@Th...>]

On 12/31/2003 2:31 AM, Uri Guttman wrote:
> ok, i rtfm'ed and see what the notes method does. so my first question
> is why does new even handle a passed in args attribute (especially as it
> is not documented nor meant to be used)?

I think Ken did this so that different actions can handle their own 
arguments. For example, the 'ppd' action takes an optional 'codebase' 
argument from the commandline. It opens the door so that action authors 
can similarly handle their own args, keeping arg handling near the code 
that uses it.

> the second question is how do we punish that scalawag dave for using an
> undocumented feature and leading me down that evil path?

I leave dave's punishment to your imagination (sorry dave), but I 
suspect you opened yourself to similar punishment when you *chose* to 
act without RTFM. ;-)

> on a related note (sic), i have been looking at prompt and y_n. i had
> written very similar subs in my soon to be deleted stem install script
> and i had transplanted them to my build stuff. so i will replace them
> with build's method (almost a drop in replacement). my prompts can ber
> very long (using here docs of course) since i sometime describe the
> queries in detail. now, i noticed that the example does the config
> queries in Build.PL and stores the results in notes in the build
> object. i was doing the queries in the install action. is there a reason
> to do it one way or another? the only time i seem to need those values
> is in the install action. also dave wrote something that writes out
> those values into a stem module. if i need them in test script or
> whatever, i could just use that module.

I think the primary value in doing the interactive stuff up front is 
that if you have to debug other parts of the build process, you will not 
have to keep answering the prompts. Additionally, it might be beneficial 
later if, say the interactive functions were instrumented to allow for 
scripts to supply answers to the interactive queries, so that debugging 
multiple configs could be automated. I imagine if everyone put the 
interactive stuff up front, this would be easier to implement.

> finally, in looking at y_n:
> 
>   my $answer;
>   while (1) {
>     $answer = $self->prompt(@_);
>     return 1 if $answer =~ /^y/i;
>     return 0 if $answer =~ /^n/i;
>     print "Please answer 'y' or 'n'.\n";
>   }
> 
> any reason why the assignment to $answer isn't my'ed instead of doing it
> before the loop?
> 
> inquiring minds want to know,
> 
> uri
> 

I'm guessing evolution, but Ken may have ulterior motives :-)

Regards,
Randy.

Re: [Module::Build] notes on notes

[Uri G. <ur...@st...>]

>>>>> "RWS" == Randy W Sims <Ra...@Th...> writes:

  RWS> On 12/31/2003 2:31 AM, Uri Guttman wrote:
  >> ok, i rtfm'ed and see what the notes method does. so my first question
  >> is why does new even handle a passed in args attribute (especially as it
  >> is not documented nor meant to be used)?

  RWS> I think Ken did this so that different actions can handle their own
  RWS> arguments. For example, the 'ppd' action takes an optional 'codebase'
  RWS> argument from the commandline. It opens the door so that action
  RWS> authors can similarly handle their own args, keeping arg handling near
  RWS> the code that uses it.

i think you may have misunderstood my question. the new constructor
handles an 'args' attribute passed into it but that is not documented
and is what dave used to set defaults. look at this code:

sub new {
  my $self = shift()->_construct(@_);

  $self->cull_args(@ARGV);


sub _construct {
  my ($package, %input) = @_;

  my $args   = delete $input{args}   || {};

<snip>

  my $self = bless {
		    args => {%$args},


anything passed with 'args' in new is stored in the object and then
command line args can override those values. so the 'args' passed to new
are effectively defaults for the command line. this is actually more
like what i want than just notes (though i could get the command line
args before i set notes and use those).

also that args => {%$args} does a useless extra copy AFAICT. it doesn't
check that args is actually a hash ref either so if you pass something
else in (still undocumented), it will die.

  >> on a related note (sic), i have been looking at prompt and y_n. i had
  >> written very similar subs in my soon to be deleted stem install script
  >> and i had transplanted them to my build stuff. so i will replace them
  >> with build's method (almost a drop in replacement). my prompts can ber
  >> very long (using here docs of course) since i sometime describe the
  >> queries in detail. now, i noticed that the example does the config
  >> queries in Build.PL and stores the results in notes in the build
  >> object. i was doing the queries in the install action. is there a reason
  >> to do it one way or another? the only time i seem to need those values
  >> is in the install action. also dave wrote something that writes out
  >> those values into a stem module. if i need them in test script or
  >> whatever, i could just use that module.

  RWS> I think the primary value in doing the interactive stuff up front is
  RWS> that if you have to debug other parts of the build process, you will
  RWS> not have to keep answering the prompts. Additionally, it might be
  RWS> beneficial later if, say the interactive functions were instrumented
  RWS> to allow for scripts to supply answers to the interactive queries, so
  RWS> that debugging multiple configs could be automated. I imagine if
  RWS> everyone put the interactive stuff up front, this would be easier to
  RWS> implement.

good answer about the up front stuff. i have been hitting a lot of
returns to get to the parts i am testing. the interactive stuff could be
done for the install phase just as well as the Build.PL phase IMO.
so i will move the question stuff to Build.PL and use the build prompt
and y_n instead of my own. it will actually clean up the code some as it
splits the query stuff from the install and action stuff.

another thing i mentioned that dave did was to write out the args to a
stem config file. he also read it back in in Build.PL and passed it to
the default args hash. so it was sorta like a persistant set of config
args if you rebuilt Build. would the notes stuff be persistant at that
level too? or are notes only persistant after Build.PL is run? the
feature dave seemed to want was to use the past install config values as
the new defaults for the query phase. how would this be done with notes?
i think they are written to the _build dir stuff but are they read in
when Build.PL is run? and if so, can i get at them before i do the
queries? i will experiment and study the code to see what i can do but
if you can answer it now, it will save me from having to do more
dispicable rtfming. :)

  RWS> I'm guessing evolution, but Ken may have ulterior motives :-)

i just do code review whenever i look at code. like i spotted the bogus
args copy above. :)

thanx,

uri

-- 
Uri Guttman  ------  ur...@st...  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org

Re: [Module::Build] notes on notes

[Randy W. S. <Ra...@Th...>]

On 12/31/2003 4:42 AM, Uri Guttman wrote:

>>>>>>"RWS" == Randy W Sims <Ra...@Th...> writes:
> 
> 
>   RWS> On 12/31/2003 2:31 AM, Uri Guttman wrote:
>   >> ok, i rtfm'ed and see what the notes method does. so my first question
>   >> is why does new even handle a passed in args attribute (especially as it
>   >> is not documented nor meant to be used)?
> 
>   RWS> I think Ken did this so that different actions can handle their own
>   RWS> arguments. For example, the 'ppd' action takes an optional 'codebase'
>   RWS> argument from the commandline. It opens the door so that action
>   RWS> authors can similarly handle their own args, keeping arg handling near
>   RWS> the code that uses it.
> 
> i think you may have misunderstood my question. the new constructor
> handles an 'args' attribute passed into it but that is not documented
> and is what dave used to set defaults. look at this code:
> 
> sub new {
>   my $self = shift()->_construct(@_);
> 
>   $self->cull_args(@ARGV);
> 
> 
> sub _construct {
>   my ($package, %input) = @_;
> 
>   my $args   = delete $input{args}   || {};
> 
> <snip>
> 
>   my $self = bless {
> 		    args => {%$args},
> 
> 
> anything passed with 'args' in new is stored in the object and then
> command line args can override those values. so the 'args' passed to new
> are effectively defaults for the command line. this is actually more
> like what i want than just notes (though i could get the command line
> args before i set notes and use those).
> 
> also that args => {%$args} does a useless extra copy AFAICT. it doesn't
> check that args is actually a hash ref either so if you pass something
> else in (still undocumented), it will die.
>   >> on a related note (sic), i have been looking at prompt and y_n. i had
>   >> written very similar subs in my soon to be deleted stem install script
>   >> and i had transplanted them to my build stuff. so i will replace them
>   >> with build's method (almost a drop in replacement). my prompts can ber
>   >> very long (using here docs of course) since i sometime describe the
>   >> queries in detail. now, i noticed that the example does the config
>   >> queries in Build.PL and stores the results in notes in the build
>   >> object. i was doing the queries in the install action. is there a reason
>   >> to do it one way or another? the only time i seem to need those values
>   >> is in the install action. also dave wrote something that writes out
>   >> those values into a stem module. if i need them in test script or
>   >> whatever, i could just use that module.
> 
>   RWS> I think the primary value in doing the interactive stuff up front is
>   RWS> that if you have to debug other parts of the build process, you will
>   RWS> not have to keep answering the prompts. Additionally, it might be
>   RWS> beneficial later if, say the interactive functions were instrumented
>   RWS> to allow for scripts to supply answers to the interactive queries, so
>   RWS> that debugging multiple configs could be automated. I imagine if
>   RWS> everyone put the interactive stuff up front, this would be easier to
>   RWS> implement.
> 
> good answer about the up front stuff. i have been hitting a lot of
> returns to get to the parts i am testing. the interactive stuff could be
> done for the install phase just as well as the Build.PL phase IMO.
> so i will move the question stuff to Build.PL and use the build prompt
> and y_n instead of my own. it will actually clean up the code some as it
> splits the query stuff from the install and action stuff.
> 
> another thing i mentioned that dave did was to write out the args to a
> stem config file. he also read it back in in Build.PL and passed it to
> the default args hash. so it was sorta like a persistant set of config
> args if you rebuilt Build. would the notes stuff be persistant at that
> level too? or are notes only persistant after Build.PL is run?

I believe notes are persisted when Build.PL is first run and persist 
until the 'realclean' action is invoked.

> feature dave seemed to want was to use the past install config values as
> the new defaults for the query phase. how would this be done with notes?

I don't think it can be done with notes. I think this is pretty much the 
same thing I was talking about before when I refered to being able to 
script the interactive stuff by supplying an answer file. It would work 
sort of like configure. When you answer interactive queries, the answers 
are stored in an answer file for later reuse to create the exact same 
config. Or you write (or generate) an answer file to automate the config 
process. This feature is not currently explicitly provided by M::B, 
although I think it a very desirable one. Is this what you are talking 
about? If so, it would be best to add this feature to M::B than to try 
and work around M::B to get the results you want or to reproduce the 
functionality in multiple distributions.

> i think they are written to the _build dir stuff but are they read in
> when Build.PL is run?  and if so, can i get at them before i do the
> queries? i will experiment and study the code to see what i can do but
> if you can answer it now, it will save me from having to do more
> dispicable rtfming. :)

As above, notes are created in the _build dir at the time Build.PL is 
run and are thus only available afterwards. I.e. they are available when 
actions are invoked.

>   RWS> I'm guessing evolution, but Ken may have ulterior motives :-)
> 
> i just do code review whenever i look at code. like i spotted the bogus
> args copy above. :)
> 
> thanx,
> 
> uri

Re: [Module::Build] notes on notes

[Randy W. S. <Ra...@Th...>]

On 12/31/2003 4:42 AM, Uri Guttman wrote:

> another thing i mentioned that dave did was to write out the args to a
> stem config file. he also read it back in in Build.PL and passed it to
> the default args hash. so it was sorta like a persistant set of config
> args if you rebuilt Build. would the notes stuff be persistant at that
> level too? or are notes only persistant after Build.PL is run? the
> feature dave seemed to want was to use the past install config values as
> the new defaults for the query phase. how would this be done with notes?
> i think they are written to the _build dir stuff but are they read in
> when Build.PL is run? and if so, can i get at them before i do the
> queries? i will experiment and study the code to see what i can do but
> if you can answer it now, it will save me from having to do more
> dispicable rtfming. :)

I don't know if I'm completely understanding what your talking about, 
but I went ahead and wrote some code. =) The attached patch for M::B 
provides support for answer scripts. It was extremely easy to implement 
thanks to M::B's great architecture. Currently, it will create an answer 
script from the answers to prompt() and y_n() queries, store the answers 
in 'Build.ans' (configurable). The next run will use those answers as 
defaults. You can also edit the answer file, taking out the '?? 
interactive' line (lines begin with '??' for flags or '?? #' for 
comments), so that the prompts are answered non-interactively which 
means you can easily automate testing of multiple configs.

The obvious extension to this would be to provide for storing answers to 
non-interactive queries. For example, if you write a Build.PL that does 
a lot of probing, you might want to store the results of the first probe 
in order to save time on subsequent runs. But I'll let you play with 
this and see what Ken thinks before I do anymore.

Regards,
Randy.

Re: [Module::Build] notes on notes

[Randy W. S. <Ra...@Th...>]

On 1/1/2004 4:12 AM, Randy W. Sims wrote:

> The obvious extension to this would be to provide for storing answers to 
> non-interactive queries. For example, if you write a Build.PL that does 
> a lot of probing, you might want to store the results of the first probe 
> in order to save time on subsequent runs. But I'll let you play with 
> this and see what Ken thinks before I do anymore.

Here is an extended version:

Example:

?? interactive
?? no_clobber
John Doe
jd...@so...
y
?? force Hello, World!
?? # store these so we don't have to look em up again.
?? set ftp = /usr/local/bin/ncftp
?? set cc = /usr/bin/gcc
?? eof


Answer script format:

Each line represent an answer to a fixed sequence of prompts unless the 
line begins with '??' in which case it is a command or flag.

The flags are:

'interactive' => means the answers in the script are to be used as 
defaults for an interactive session instead of as an automated answer 
script.

'no_clobber' => prevents M::B from overwritting the answer file. 
Normally, in interactive mode M::B records the answers to prompts and 
then saves a new answer file so that on the next run the new answers 
will be used as the new defaults.

The commands are:

'default' => use the default specified to the prompt() or y_n() functions.

'alt <value>' => use the default specified to the prompt() or y_n() 
functions if available, other wise use <value>.

'force <value>' => in interactive mode, skip the prompt using <value> as 
the answer.

'set <key> = <value>' => stores (key, value) pairs that can be retrieved 
with the retrieve_answer() api. see below.

'#' => a comment. ignored.

The api:

store_answer(<key>, <value>) => stores the (key, value) pair to be 
written to the answer file. Can be used to store info that may otherwise 
be time consuming to gather, like a cache.

retrieve_answer(<key>) => retrieves the value stored in <key> from the 
answer file.


Regards,
Randy.

Re: [Module::Build] notes on notes

[Randy W. S. <Ra...@Th...>]

On 1/1/2004 11:19 PM, Randy W. Sims wrote:

> Example:
> 
> ?? interactive
> ?? no_clobber
> John Doe
> jd...@so...
> y
> ?? force Hello, World!
> ?? # store these so we don't have to look em up again.
> ?? set ftp = /usr/local/bin/ncftp
> ?? set cc = /usr/bin/gcc
> ?? eof
> 
> 
> Answer script format:
> 
> Each line represent an answer to a fixed sequence of prompts unless the 
> line begins with '??' in which case it is a command or flag.

Aw, no one commented on all the question marks in an answer script. I 
thought it was at least worth a grin... <g>

Randy.

Re: [Module::Build] notes on notes

[Ken W. <ke...@ma...>]

On Thursday, January 8, 2004, at 07:05  PM, Randy W. Sims wrote:
>
> Aw, no one commented on all the question marks in an answer script. I 
> thought it was at least worth a grin... <g>

I grinned, but only in the privacy of my own home. ;-)

Let's keep this topic open for the new release track 0.23.

  -Ken

Re: [Module::Build] notes on notes

[Uri G. <ur...@st...>]

>>>>> "RWS" == Randy W Sims <Ra...@Th...> writes:


  RWS> I don't know if I'm completely understanding what your talking about,
  RWS> but I went ahead and wrote some code. =) The attached patch for M::B
  RWS> provides support for answer scripts. It was extremely easy to
  RWS> implement thanks to M::B's great architecture. Currently, it will
  RWS> create an answer script from the answers to prompt() and y_n()
  RWS> queries, store the answers in 'Build.ans' (configurable). The next run
  RWS> will use those answers as defaults. You can also edit the answer file,
  RWS> taking out the '?? interactive' line (lines begin with '??' for flags
  RWS> or '?? #' for comments), so that the prompts are answered
  RWS> non-interactively which means you can easily automate testing of
  RWS> multiple configs.

ok, i see the communication problem here. let me take a step back.

dave wrote a first pass for the stem install and took the config params
answers and wrote them out to the Stem::InstallConfig module. i don't
have any reason currently to use those config values in any stem
application but i am sure someone will one day so that is fine with
me. but dave also read in that config file in Build.PL to use as a
persistant set of default config values. also since he used the 'args'
feature, command line args could override the default values. now dave's
motives (as well and his morals and dna) for this are suspect. i don't
see any need for persistant config params in this install as stem will
probably not be reinstalled (often) from the same tarball. it doesn't
have build variations like some other modules do.

so the story is that is has persistant config params but it doesn't need
them and i will keep them anyway since it seems kinda cool. :)

now, there are several ways to to this and notes is one of them. but
since we already write out the config params to that stem module,
loading that is very easy and i will prolly stay with it.

side question: since that config module is generated at build/install
time it should be deleted with realclean. but it won't be seen that way
by the default realclean action. do i need to write my own realclean
action, delete that config file and then call SUPER::ACTION_real_clean?
it isn't hard but is there a standard way to add things to realclean?

  RWS> The obvious extension to this would be to provide for storing
  RWS> answers to non-interactive queries. For example, if you write a
  RWS> Build.PL that does a lot of probing, you might want to store the
  RWS> results of the first probe in order to save time on subsequent
  RWS> runs. But I'll let you play with this and see what Ken thinks
  RWS> before I do anymore.

well, as i said i didn't need this for non-interactive queries. but i
will add a command line arg like 'no_questions' or 'use_defaults' which
will force build to use the default values and not prompt for anything. 

my current code does this as a wrapper to prompt:

sub query_valuex {

	my( $self, $query, $key ) = @_ ;

	my $default = $build->{args}{$key} ;
	$default = $defaults{ $key } unless defined $default ;

	my $val = $self->prompt( $query, $default ) ;

#	$self->notes( $key, $val ) ;
	$defaults{ $key } = $val ;

}

so you can see that it keeps the result from the query and it will store
that in the stem config module (maybe it should store that in the object
and not in a file lexical). 

side question: notes has a simple interface but i am not sure if it is
easy to use in this case. i could store each param in its own key in
notes. but what if a value in notes needs to be a hash ref? then you
have to access it, update it and set the ref back into notes. also there
is no way to set all the notes in one call (when you want to build up
your own notes hash and just assign it) as there is a way to get the
entire ref in one call. this may be why i skip the notes interface as i
am not sure what i will want to store/access there. i have the
persistance via the config module and can mung the config/defaults hash
directly.

<snip of code>

so i won't be testing this as i don't really need it for this right
now. but i can see users wanting it for multiple installations and
similar situations. also i sometimes wish i could crank out the code
like i used to. :)

uri

-- 
Uri Guttman  ------  ur...@st...  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org

Re: [Module::Build] notes on notes

[Dave R. <au...@ur...>]

On Thu, 1 Jan 2004, Uri Guttman wrote:

> motives (as well and his morals and dna) for this are suspect. i don't
> see any need for persistant config params in this install as stem will
> probably not be reinstalled (often) from the same tarball. it doesn't
> have build variations like some other modules do.

It's useful if someone installs Stem 0.10 and later goes to install 0.11.
That way the previous values are presented as defaults.

> now, there are several ways to to this and notes is one of them. but
> since we already write out the config params to that stem module,
> loading that is very easy and i will prolly stay with it.

notes is not persistent after a "./Build clean", so it's only for "during
the build/install" data.

> side question: since that config module is generated at build/install
> time it should be deleted with realclean. but it won't be seen that way
> by the default realclean action. do i need to write my own realclean
> action, delete that config file and then call SUPER::ACTION_real_clean?
> it isn't hard but is there a standard way to add things to realclean?

 $build->add_to_cleanup($path_to_file);


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Re: [Module::Build] notes on notes

[Uri G. <ur...@st...>]

>>>>> "DR" == Dave Rolsky <au...@ur...> writes:

  DR> On Thu, 1 Jan 2004, Uri Guttman wrote:
  >> motives (as well and his morals and dna) for this are suspect. i don't
  >> see any need for persistant config params in this install as stem will
  >> probably not be reinstalled (often) from the same tarball. it doesn't
  >> have build variations like some other modules do.

  DR> It's useful if someone installs Stem 0.10 and later goes to install 0.11.
  DR> That way the previous values are presented as defaults.

hmm. never thought of it that way. this would also only work if the new
install used the same perl (or shared the same perl lib tree) and the
previous one. but i will note it and write it up in the INSTALL
doc. also with the option to just use the defaults, it will make
installing new stem versions faster as well. 

  >> now, there are several ways to to this and notes is one of them. but
  >> since we already write out the config params to that stem module,
  >> loading that is very easy and i will prolly stay with it.

  DR> notes is not persistent after a "./Build clean", so it's only for "during
  DR> the build/install" data.

so that confirms my not using notes.

  >> side question: since that config module is generated at build/install
  >> time it should be deleted with realclean. but it won't be seen that way
  >> by the default realclean action. do i need to write my own realclean
  >> action, delete that config file and then call SUPER::ACTION_real_clean?
  >> it isn't hard but is there a standard way to add things to realclean?

  DR>  $build->add_to_cleanup($path_to_file);

so this will clean it up in the build tree which is good and leave it in
the installed lib dir. i will add it to the sub that makes the config
file as it has the path. i have to check if the default install command
will install a generated .pm file that is not in the manifest.

thanx,

uri

-- 
Uri Guttman  ------  ur...@st...  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org

Re: [Module::Build] notes on notes

[Randy W. S. <Ra...@Th...>]

On 1/1/2004 11:08 PM, Uri Guttman wrote:

> so i won't be testing this as i don't really need it for this right
> now. but i can see users wanting it for multiple installations and
> similar situations.

Ok, I guess the extended version I just posted is unneccessary also <<:-\

But I still think it usefull addition to M::B to aid testing and automation.

Randy.

Re: [Module::Build] notes on notes

[Uri G. <ur...@st...>]

>>>>> "RWS" == Randy W Sims <Ra...@th...> writes:

  RWS> On 1/1/2004 11:08 PM, Uri Guttman wrote:
  >> so i won't be testing this as i don't really need it for this right
  >> now. but i can see users wanting it for multiple installations and
  >> similar situations.

  RWS> Ok, I guess the extended version I just posted is unneccessary
  RWS> also <<:-\

  RWS> But I still think it usefull addition to M::B to aid testing and
  RWS> automation.

it looks like a good tool for that so don't erase it. i just don't need
it now. there are plenty of uses for an automated way to answer install
scripts.

uri

-- 
Uri Guttman  ------  ur...@st...  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org