From jarich at perltraining.com.au Sun Mar 5 22:02:06 2006 From: jarich at perltraining.com.au (Jacinta Richardson) Date: Mon, 06 Mar 2006 17:02:06 +1100 Subject: [Canberra-pm] Meeting: Thursday 9th March Message-ID: <440BD05E.3020400@perltraining.com.au> G'day everyone, One more reminder that there's a Canberra Perl Monger meeting on Thursday evening. Date: 9th March 2006 (Second Thursday of the month) Time: 18:30 - 21:00 (or when it finishes) Venue: Canberra City Pancake Parlour Send your talk offers to this list or to Steve ( steve at nerdvana.org.au ) All the best, Jacinta -- ("`-''-/").___..--''"`-._ | Jacinta Richardson | `6_ 6 ) `-. ( ).`-.__.`) | Perl Training Australia | (_Y_.)' ._ ) `._ `. ``-..-' | +61 3 9354 6001 | _..`--'_..-_/ /--'_.' ,' | contact at perltraining.com.au | (il),-'' (li),' ((!.-' | www.perltraining.com.au | From jarich at perltraining.com.au Mon Mar 6 14:39:10 2006 From: jarich at perltraining.com.au (Jacinta Richardson) Date: Tue, 07 Mar 2006 09:39:10 +1100 Subject: [Canberra-pm] Talk for Meeting - 9th March Message-ID: <440CBA0E.8020806@perltraining.com.au> Many thanks to Steve. CLUG Programmers' Special Interest Group Meeting - 9th March 2006 ================================================================= Date: 9th March 2006 (Second Thursday of the month) Time: 18:30 - 21:00 (or when it finishes) Speaker: Paul Wayper Abstract: Paul's willing to put his head on a block and give a talk on Object-Oriented Perl - designing an object.He'll be using an object he designed which does simple text progress bars, with Estimated Time to Completion, percentages, '3 of 12', titles, bars, and a possibly nifty interface to save you calling it so often.In other words, it's a shameless plug for something he's written. People can download the source to look at it either by going to http://tangram.dnsalias.net:8008/~paulway/Progressor.pm or by using 'svn checkout svn://tangram.dnsalias.net/Progressor/trunk'. Talk time is about 30 minutes Venue: Canberra City Pancake Parlour Find platform 4 in the City Interchange (see map below) and then look for the Pancake Parlour sandwich board. At the bottom of the stairs, look for the PSIG sign on the counter and a stuffed penguin in the indicated direction. http://tinyurl.com/dyexl Food/drink: The Pancake Parlour has a large variety of food and drink available, so bring some cash and grab a bite to eat or drink. If you would like to give a talk at a future meeting, please email me. From Michael.James at csiro.au Wed Mar 29 18:21:27 2006 From: Michael.James at csiro.au (Michael James) Date: Thu, 30 Mar 2006 13:21:27 +1100 Subject: [Canberra-pm] do read-local.config Message-ID: <200603301321.27585.Michael.James@csiro.au> In the perl cookbook it suggests a good way to keep local configuration details out of a larger and messier script is to put normal perl code into a separate file and "do" it. But in a throwaway line (middle of page 328) it says, of course neither the doer nor the done will have access to the other's lexical (my) variables. Hang ON! Lets get this clear, the done.config file can't create a variable visible to the calling program, nor see a pre-existing variable to change it. What's the point? Can any of you lexicographers explain a way around this, to a bear of limited scope? -- Michael James michael.james at csiro.au System Administrator voice: 02 6246 5040 CSIRO Bioinformatics Facility fax: 02 6246 5166 PS: the IN-elegance of: eval `cat done` has already been noted. From andrew-pm at andrew.net.au Wed Mar 29 21:43:26 2006 From: andrew-pm at andrew.net.au (Andrew Pollock) Date: Thu, 30 Mar 2006 15:43:26 +1000 Subject: [Canberra-pm] do read-local.config In-Reply-To: <200603301321.27585.Michael.James@csiro.au> References: <200603301321.27585.Michael.James@csiro.au> Message-ID: <20060330054326.GW24548@daedalus.andrew.net.au> On Thu, Mar 30, 2006 at 01:21:27PM +1100, Michael James wrote: > In the perl cookbook it suggests a good way to keep > local configuration details out of a larger and messier script > is to put normal perl code into a separate file and "do" it. > > But in a throwaway line (middle of page 328) it says, > of course neither the doer nor the done will have access > to the other's lexical (my) variables. > > Hang ON! Lets get this clear, the done.config file > can't create a variable visible to the calling program, > nor see a pre-existing variable to change it. > > What's the point? > > Can any of you lexicographers explain > a way around this, to a bear of limited scope? Reading the output of a perldoc -f do, it doesn't say anything about the variables defined in the file being "done" not being visible to the caller, but I could imagine anything declared with "my" wouldn't be visible, so just don't use "my" in the config file being "done"? regards Andrew From Michael.James at csiro.au Wed Mar 29 22:20:59 2006 From: Michael.James at csiro.au (Michael James) Date: Thu, 30 Mar 2006 17:20:59 +1100 Subject: [Canberra-pm] do read-local.config In-Reply-To: <20060330054326.GW24548@daedalus.andrew.net.au> References: <200603301321.27585.Michael.James@csiro.au> <20060330054326.GW24548@daedalus.andrew.net.au> Message-ID: <200603301720.59795.Michael.James@csiro.au> On Thu, 30 Mar 2006 04:43 pm, Andrew Pollock wrote: > On Thu, Mar 30, 2006 at 01:21:27PM +1100, Michael James wrote: > > In the perl cookbook it suggests a good way to keep > > local configuration details out of a larger and messier script > > is to put normal perl code into a separate file and "do" it. > > > > But in a throwaway line (middle of page 328) it says, > > of course neither the doer nor the done will have access > > to the other's lexical (my) variables. > > > > Hang ON! Lets get this clear, the done.config file > > can't create a variable visible to the calling program, > > nor see a pre-existing variable to change it. > > > > What's the point? > > > > Can any of you lexicographers explain > > a way around this, to a bear of limited scope? > > Reading the output of a perldoc -f do, it doesn't say anything > about the variables defined in the file being "done" > not being visible to the caller, but I could imagine > anything declared with "my" wouldn't be visible, > so just don't use "my" in the config file being "done"? Some experimentation shows how it used to work: ONLY if neither doer nor done "use strict;", AND the variable doesn't already exist, does the value from "done" appear in "doer". Not satisfying, I don't mind living without strict in the config file, but want it in the main program. I also want to use this for a CGI script to call another perl program without passing heaps of user supplied info on the command line. In the past I've done this by writing it all into a configuration file and passing that, but it's more of a pain than saying "do second-half.pl". -- Michael James michael.james at csiro.au System Administrator voice: 02 6246 5040 CSIRO Bioinformatics Facility fax: 02 6246 5166 No matter how much you pay for software, you always get less than you hoped. Unless you pay nothing, then you get more. From jarich at perltraining.com.au Wed Mar 29 22:31:43 2006 From: jarich at perltraining.com.au (Jacinta Richardson) Date: Thu, 30 Mar 2006 17:31:43 +1100 Subject: [Canberra-pm] do read-local.config In-Reply-To: <200603301321.27585.Michael.James@csiro.au> References: <200603301321.27585.Michael.James@csiro.au> Message-ID: <442B7B4F.8010208@perltraining.com.au> You can always use package variables: ------ config.pl $::etc_path = "/some/path"; ------ main.pl use strict; BEGIN { do "./config.pl"; } use lib "$::etc_path/lib"; ------------------------------------ Which is something I found useful for a bunch of CGI scripts which all needed to know where the lib was, except that lib's location varied depending on whether it was production or development. Lexical variables exist only for their enclosing block. The biggest enclosing block is a file, so had $etc_path been declared with "my" there would be no result after calling "do". Obviously there are drawbacks to using package variables, they never go out of scope. If you need something that is even a little bit more complicated than what I wrote above, I'd suggest moving to something like Config::General rather than "do"ing a file. All the best, Jacinta -- ("`-''-/").___..--''"`-._ | Jacinta Richardson | `6_ 6 ) `-. ( ).`-.__.`) | Perl Training Australia | (_Y_.)' ._ ) `._ `. ``-..-' | +61 3 9354 6001 | _..`--'_..-_/ /--'_.' ,' | contact at perltraining.com.au | (il),-'' (li),' ((!.-' | www.perltraining.com.au | From jepri at babylon.alphacomplex.org Thu Mar 30 02:23:33 2006 From: jepri at babylon.alphacomplex.org (Jepri) Date: Thu, 30 Mar 2006 20:23:33 +1000 Subject: [Canberra-pm] do read-local.config In-Reply-To: <200603301321.27585.Michael.James@csiro.au> References: <200603301321.27585.Michael.James@csiro.au> Message-ID: <442BB1A5.3070502@babylon.alphacomplex.org> The do.config file can still call functions, which is the right way to be doing it. Altering variables in other modules is somewhat naughty. Michael James wrote: > In the perl cookbook it suggests a good way to keep > local configuration details out of a larger and messier script > is to put normal perl code into a separate file and "do" it. > > But in a throwaway line (middle of page 328) it says, > of course neither the doer nor the done will have access > to the other's lexical (my) variables. > > Hang ON! Lets get this clear, the done.config file > can't create a variable visible to the calling program, > nor see a pre-existing variable to change it. > > What's the point? > > Can any of you lexicographers explain > a way around this, to a bear of limited scope? > > From pjf at perltraining.com.au Thu Mar 30 03:28:45 2006 From: pjf at perltraining.com.au (Paul Fenwick) Date: Thu, 30 Mar 2006 22:28:45 +1100 Subject: [Canberra-pm] do read-local.config In-Reply-To: <200603301321.27585.Michael.James@csiro.au> References: <200603301321.27585.Michael.James@csiro.au> Message-ID: <442BC0ED.5050006@perltraining.com.au> G'day Michael, Michael James wrote: > Hang ON! Lets get this clear, the done.config file > can't create a variable visible to the calling program, > nor see a pre-existing variable to change it. That's absolutely correct. Lexical scope is very strict, and never crosses file boundaries. > What's the point? The file that is being "done" can *return* a value to the calling code: my $config = do "configuration.pl"; If the configuration file happens to return a hash-reference, then we can return a whole bunch of useful configuration at once. For example, 'configuration.pl' may contain: return { directory => "/usr/local/example", timeout => 30, hostname => "www.example.com", } This is much less error-prone than creating or modifying variables and expecting the other file to know what they're called. By using: my $config = do "configuration.pl"; we may it very clear to anyone reading the code that we expect to store the result of our file in the $config variable. More notes can be found at http://perl.net.au/wiki/Using_do_for_configuration . Please feel free to improve or adjust as you see fit. All the very best, Paul -- Paul Fenwick | http://perltraining.com.au/ Director of Training | Ph: +61 3 9354 6001 Perl Training Australia | Fax: +61 3 9354 2681 From Michael.James at csiro.au Thu Mar 30 19:39:46 2006 From: Michael.James at csiro.au (Michael James) Date: Fri, 31 Mar 2006 14:39:46 +1100 Subject: [Canberra-pm] do read-local.config In-Reply-To: <442BC0ED.5050006@perltraining.com.au> References: <200603301321.27585.Michael.James@csiro.au> <442BC0ED.5050006@perltraining.com.au> Message-ID: <200603311439.47166.Michael.James@csiro.au> I asked: > > What's the point of "do"ing a config file > > if it can't pass variables? On Thu, 30 Mar 2006 10:28 pm, you wrote: > The file that is being "done" > can *return* a value to the calling code: > > my $config = do "configuration.pl"; > > If the configuration file happens to return a hash-reference, > then we can return a whole bunch of useful configuration at once. > For example, 'configuration.pl' may contain: > > return { > directory => "/usr/local/example", > timeout => 30, > hostname => "www.example.com", > } > > This is much less error-prone than creating or modifying variables > and expecting the other file to know what they're called. > By using: > > my $config = do "configuration.pl"; > > we may it very clear to anyone reading the code > that we expect to store the result of our file > in the $config variable. > > More notes can be found at: > http://perl.net.au/wiki/Using_do_for_configuration . Excellent! Thanks, that's made it clear. But what if I want the "doer" perl script to pass configuration to the "done" script? In the code I've been given, they've used a "system" call, adding all the (user supplied) parameters to the string executed. Very insecure. One way would be to add the second file to the end of the first, but for historical reasons, I'd prefer to keep them separate files. Is there a way for the "doer" script to pass variables to the "done"? Or is some variant of "system" still the best way? -- Michael James michael.james at csiro.au System Administrator voice: 02 6246 5040 CSIRO Bioinformatics Facility fax: 02 6246 5166 No matter how much you pay for software, you always get less than you hoped. Unless you pay nothing, then you get more. From jarich at perltraining.com.au Thu Mar 30 20:23:08 2006 From: jarich at perltraining.com.au (Jacinta Richardson) Date: Fri, 31 Mar 2006 15:23:08 +1100 Subject: [Canberra-pm] do read-local.config In-Reply-To: <200603311439.47166.Michael.James@csiro.au> References: <200603301321.27585.Michael.James@csiro.au> <442BC0ED.5050006@perltraining.com.au> <200603311439.47166.Michael.James@csiro.au> Message-ID: <442CAEAC.9060203@perltraining.com.au> Michael James wrote: > But what if I want the "doer" perl script > to pass configuration to the "done" script? > > In the code I've been given, they've used a "system" call, > adding all the (user supplied) parameters to the string executed. > Very insecure. > > One way would be to add the second file to the end of the first, > but for historical reasons, I'd prefer to keep them separate files. > > Is there a way for the "doer" script to pass variables to the "done"? > Or is some variant of "system" still the best way? It's very hard to answer this question without seeing your code. But I suspect the correct answer is for you to wrap the whole thing up as a subroutine, give the file a useful name and package, and then "use" that module and call the subroutine where-ever you need it, passing in the parameters as arguments. It depends on what's in the file, but for the by and large such a procedure would work: ------------------- main.pl #!/usr/bin/perl -w use strict; use Second; # Usual code. # Do second half: my $return = Second::second_half($arg1, $arg2, $arg3, ... ); # finish up. ----------------------- Second.pm package Second; sub second_half { my ($arg1, $arg2, $arg3, ...) = @_; # check arguments # all the previous stuff return $something; } 1; # must appear at end of module ----------------------------- Of course if you have the time, skill and power to refactor the two scripts into one then that may well be easier for future maintainers. Jacinta -- ("`-''-/").___..--''"`-._ | Jacinta Richardson | `6_ 6 ) `-. ( ).`-.__.`) | Perl Training Australia | (_Y_.)' ._ ) `._ `. ``-..-' | +61 3 9354 6001 | _..`--'_..-_/ /--'_.' ,' | contact at perltraining.com.au | (il),-'' (li),' ((!.-' | www.perltraining.com.au | From jarich at perltraining.com.au Thu Mar 30 20:58:48 2006 From: jarich at perltraining.com.au (Jacinta Richardson) Date: Fri, 31 Mar 2006 15:58:48 +1100 Subject: [Canberra-pm] Talk at next Canberra PM meeting? (was Re: do read-local.config) In-Reply-To: <200603301321.27585.Michael.James@csiro.au> References: <200603301321.27585.Michael.James@csiro.au> Message-ID: <442CB708.8060907@perltraining.com.au> G'day Michael, I forgot to say Welcome! It appears you're pretty new to Canberra PM, and I'm really glad to have you here! I don't know if you're aware, but Canberra PM has quarterly meetings and the next one to be scheduled is in June. Would you be interested in presenting a 10 minute talk on what you've learned on this topic, the things you tried, the problems you had and your final solution? It's always good to see how someone went when the problem was finally solved. It would be really good to have you and other Perl Mongers thinking about talk topics for that meeting. With a bit of luck Paul Fenwick will be in town too, probably presenting a talk on "Human Interfaces for Geeks", but we'd certainly be able to take at *least* 3 talks of 10 minutes long! All the best, Jacinta PS: If you've never given a talk at such an event and find the idea a little intimidating take heart(!), it's *very* hard to send your audience to sleep within 10 minutes, so even if you were to do really badly (which you won't) your 10 minutes will be up in no time at all. -- ("`-''-/").___..--''"`-._ | Jacinta Richardson | `6_ 6 ) `-. ( ).`-.__.`) | Perl Training Australia | (_Y_.)' ._ ) `._ `. ``-..-' | +61 3 9354 6001 | _..`--'_..-_/ /--'_.' ,' | contact at perltraining.com.au | (il),-'' (li),' ((!.-' | www.perltraining.com.au |