From sthoenna at efn.org Thu Jan 1 00:12:05 2009 From: sthoenna at efn.org (Yitzchak Scott-Thoennes) Date: Thu, 1 Jan 2009 00:12:05 -0800 (PST) Subject: SPUG: Predeclaring packages In-Reply-To: References: Message-ID: <57009.97.113.117.187.1230797525.squirrel@webmail.efn.org> On Wed, December 31, 2008 7:36 pm, Christopher Howard wrote: > Question: Is there a way to predeclare packages, without moving the > package to a separate file? > > This is my issue: When I write a script, I like to use packages to keep > everything nice and neat. And I like to have subs and packages after the > 'initializing' part of the program, so it is easy to find. So what I'm > doing now is something like this: > > ### EXAMPLE START ### > This doesn't work because $timer is not predeclared along with the > subroutines. There's something you're missing, but I'm not completely sure what it is. Can you explain more what isn't working? Your example should work just fine, though the predeclarations are unnecessary. Remember that first your entire script is compiled, including the sub definitions, and then it begins executing. From choward at indicium.us Fri Jan 2 15:33:44 2009 From: choward at indicium.us (Christopher Howard) Date: Fri, 2 Jan 2009 14:33:44 -0900 (AKST) Subject: SPUG: Predeclaring packages In-Reply-To: <57009.97.113.117.187.1230797525.squirrel@webmail.efn.org> References: <57009.97.113.117.187.1230797525.squirrel@webmail.efn.org> Message-ID: On Thu, 1 Jan 2009, Yitzchak Scott-Thoennes wrote: > On Wed, December 31, 2008 7:36 pm, Christopher Howard wrote: >> Question: Is there a way to predeclare packages, without moving the >> package to a separate file? >> >> This is my issue: When I write a script, I like to use packages to keep >> everything nice and neat. And I like to have subs and packages after the >> 'initializing' part of the program, so it is easy to find. So what I'm >> doing now is something like this: >> >> ### EXAMPLE START ### > >> This doesn't work because $timer is not predeclared along with the >> subroutines. > > There's something you're missing, but I'm not completely sure > what it is. Can you explain more what isn't working? > > Your example should work just fine, though the predeclarations > are unnecessary. Remember that first your entire script is compiled, > including the sub definitions, and then it begins executing. > > Blah!! You're right, I tried it again and it worked! (Figures...) I did some more experimentation, and I think I know what was confusing me. Maybe you can confirm this: the scoping for an 'our' statement occurs during compiling, but actual variable assignments occur during runtime. For example, I tried this: ### EXAMPLE START ### use strict; use warnings; $Hello::greeting = 'Hello there'; Hello::sayHi(); exit(0); package Hello; { our $greeting; sub sayHi { print $greeting . "\n" } } ### EXAMPLE END ### This program outputs 'Hello there'. But if I move the value assignment inside the package, it doesn't work like I want: ### EXAMPLE START ### use strict; use warnings; Hello::sayHi(); exit(0); package Hello; { our $greeting = 'Hello there'; sub sayHi { print $greeting . "\n" } } ### EXAMPLE END ### That outputs the 'use of an unitialized variable...' warning. I'm guessing that is because nothing has been assigned to the package variable $greeting when sayHi is called, and so 'use warnings' spits out a warning for attempting to use an variable without first initializing it. Am I getting it right? -- Christopher Howard http://indicium.us From charles.e.derykus at boeing.com Fri Jan 2 20:11:22 2009 From: charles.e.derykus at boeing.com (DeRykus, Charles E) Date: Fri, 2 Jan 2009 20:11:22 -0800 Subject: SPUG: Predeclaring packages In-Reply-To: References: <57009.97.113.117.187.1230797525.squirrel@webmail.efn.org> Message-ID: > I did some more experimentation, and I think I know what was confusing me. > Maybe you can confirm this: the scoping for an 'our' statement occurs during > compiling, but actual variable assignments occur during runtime. > use strict; > use warnings; > Hello::sayHi(); > exit(0); > package Hello; > { > our $greeting = 'Hello there'; > sub sayHi { print $greeting . "\n" } > } Um, it's not a compilation vs. runtime issue: "our" just exposes a value for a global variable within a specific scope. Since the in package Hello is not in scope when Hello::sayHi() is called, it's undefined. That's why it only works if you declare <$Hello::greeting = 'Hello there'> before the call to Hello::sayHi. Note though a deckaration such as <"our $greeting = "Hello there'> just prior to Hello::sayHI wouldn't work because the scope of 'our' won't extend into package Hello. And that's why I suggested assigning the global variable to an "our" variable to avoid tediously needing a package qualifier for $greeting when used in other scopes. > That outputs the 'use of an unitialized variable...' warning. I'm guessing that is because > nothing has been assigned to the package variable $greeting when sayHi is called, > and so 'use warnings' spits out a warning for attempting to use an variable without first > initializing it. Correct. -- Charles DeRykus -----Original Message----- From: Christopher Howard [mailto:choward at indicium.us] Sent: Friday, January 02, 2009 3:34 PM To: Yitzchak Scott-Thoennes Cc: Seattle Perl Users Group Subject: Re: SPUG: Predeclaring packages On Thu, 1 Jan 2009, Yitzchak Scott-Thoennes wrote: > On Wed, December 31, 2008 7:36 pm, Christopher Howard wrote: >> Question: Is there a way to predeclare packages, without moving the >> package to a separate file? >> >> This is my issue: When I write a script, I like to use packages to >> keep everything nice and neat. And I like to have subs and packages >> after the 'initializing' part of the program, so it is easy to find. >> So what I'm doing now is something like this: >> >> ### EXAMPLE START ### > >> This doesn't work because $timer is not predeclared along with the >> subroutines. > > There's something you're missing, but I'm not completely sure what it > is. Can you explain more what isn't working? > > Your example should work just fine, though the predeclarations are > unnecessary. Remember that first your entire script is compiled, > including the sub definitions, and then it begins executing. > > Blah!! You're right, I tried it again and it worked! (Figures...) I did some more experimentation, and I think I know what was confusing me. Maybe you can confirm this: the scoping for an 'our' statement occurs during compiling, but actual variable assignments occur during runtime. For example, I tried this: ### EXAMPLE START ### use strict; use warnings; $Hello::greeting = 'Hello there'; Hello::sayHi(); exit(0); package Hello; { our $greeting; sub sayHi { print $greeting . "\n" } } ### EXAMPLE END ### This program outputs 'Hello there'. But if I move the value assignment inside the package, it doesn't work like I want: ### EXAMPLE START ### use strict; use warnings; Hello::sayHi(); exit(0); package Hello; { our $greeting = 'Hello there'; sub sayHi { print $greeting . "\n" } } ### EXAMPLE END ### That outputs the 'use of an unitialized variable...' warning. I'm guessing that is because nothing has been assigned to the package variable $greeting when sayHi is called, and so 'use warnings' spits out a warning for attempting to use an variable without first initializing it. Am I getting it right? -- Christopher Howard http://indicium.us _____________________________________________________________ Seattle Perl Users Group Mailing List POST TO: spug-list at pm.org SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list MEETINGS: 3rd Tuesdays WEB PAGE: http://seattleperl.org/ From rjk-spug at tamias.net Fri Jan 2 20:42:04 2009 From: rjk-spug at tamias.net (Ronald J Kimball) Date: Fri, 2 Jan 2009 23:42:04 -0500 Subject: SPUG: Predeclaring packages In-Reply-To: References: Message-ID: <20090103044204.GB87661@penkwe.pair.com> On Fri, Jan 02, 2009 at 08:11:22PM -0800, DeRykus, Charles E wrote: > > > I did some more experimentation, and I think I know what was confusing me. > > Maybe you can confirm this: the scoping for an 'our' statement occurs during > > compiling, but actual variable assignments occur during runtime. Yes, that is basically correct. > > use strict; > > use warnings; > > > Hello::sayHi(); > > exit(0); > > > package Hello; > > { > > > our $greeting = 'Hello there'; > > > sub sayHi { print $greeting . "\n" } > > > } > > > Um, it's not a compilation vs. runtime issue: "our" just exposes a value > for a global variable within a specific scope. Since the 'Hello there'> in package Hello is not in scope when Hello::sayHi() is > called, it's undefined. That's why it only works if you declare > <$Hello::greeting = 'Hello there'> before the call to Hello::sayHi. Note > though a deckaration such as <"our $greeting = "Hello there'> just prior > to Hello::sayHI wouldn't work because the scope of 'our' won't extend > into package Hello. And that's why I suggested assigning the global > variable to an "our" variable to avoid tediously needing a package > qualifier for $greeting when used in other scopes. In fact, it /is/ a compilation vs. runtime issue. The in package Hello is in the same scope as the sayHi subroutine. If it were a scoping issue, then there would have been an error: Global symbol "$greeting" requires explicit package name. The reason the code results in an uninitialized value warning is that the assignment has not been executed yet when Hello:sayHi() is called. One simple way to resolve this - and to demonstrate that is a compilation vs. runtime issue - is to use a BEGIN or INIT block to ensure that the assignment is executed before runtime. (BEGIN blocks are executed immediately during compilation; INIT blocks are executed between compilation and runtime.) use strict; use warnings; Hello::sayHi(); exit(0); package Hello; INIT { our $greeting = 'Hello there'; sub sayHi { print $greeting . "\n" } } Ronald From charles.e.derykus at boeing.com Sat Jan 3 02:50:09 2009 From: charles.e.derykus at boeing.com (DeRykus, Charles E) Date: Sat, 3 Jan 2009 02:50:09 -0800 Subject: SPUG: Predeclaring packages In-Reply-To: <20090103044204.GB87661@penkwe.pair.com> References: <20090103044204.GB87661@penkwe.pair.com> Message-ID: > ... > > use strict; > > use warnings; > > > Hello::sayHi(); > > exit(0); > > > package Hello; > > { > > > our $greeting = 'Hello there'; > > > sub sayHi { print $greeting . "\n" } > > > } > > > Um, it's not a compilation vs. runtime issue: "our" just exposes a > value for a global variable within a specific scope. Since the $greeting = 'Hello there'> in package Hello is not in scope when > Hello::sayHi() is called, it's undefined. That's why it only works if > you declare <$Hello::greeting = 'Hello there'> before the call to > Hello::sayHi. Note though a deckaration such as <"our $greeting = > "Hello there'> just prior to Hello::sayHI wouldn't work because the > scope of 'our' won't extend into package Hello. And that's why I > suggested assigning the global variable to an "our" variable to avoid > tediously needing a package qualifier for $greeting when used in other scopes. >> In fact, it /is/ a compilation vs. runtime issue. The in package Hello is in the same >> scope as the sayHi subroutine. If it were a scoping issue, then there would have been an >> error: Global symbol "$greeting" requires explicit package name. >> The reason the code results in an uninitialized value warning is that the assignment has not been executed yet when >> Hello:sayHi() is called. >> One simple way to resolve this - and to demonstrate that is a compilation vs. runtime issue - is to use a BEGIN or INIT >> block to ensure that the assignment is executed before runtime. (BEGIN blocks are executed immediately during >> compilation; INIT blocks are executed between compilation and runtime.) >> use strict; >> use warnings; >> Hello::sayHi(); >> exit(0); >> package Hello; >> INIT { >> our $greeting = 'Hello there'; >> sub sayHi { print $greeting . "\n" } >> } Thanks for the explanation but your INIT block also exposes a value for $greeting within the scope of the INIT block, correct...? whereas, without ensuring that $greeting gets set in that particular scope, if you had said this for instance: use strict; use warnings; Hello::sayHi(); exit(0); package Hello; INIT { our $greeting = 'Hello there'; } sub sayHi { print $greeting . "\n" } This'll enerate expected errors ====> Variable "$greeting" is not imported ... Global symbol "$greeting" requires explicit package name ... ? -- Charles DeRykus From rjk-spug at tamias.net Sat Jan 3 09:03:22 2009 From: rjk-spug at tamias.net (Ronald J Kimball) Date: Sat, 3 Jan 2009 12:03:22 -0500 Subject: SPUG: Predeclaring packages In-Reply-To: References: <20090103044204.GB87661@penkwe.pair.com> Message-ID: <20090103170322.GA94121@penkwe.pair.com> On Sat, Jan 03, 2009 at 02:50:09AM -0800, DeRykus, Charles E wrote: > > Thanks for the explanation but your INIT block also exposes a value > for $greeting within the scope of the INIT block, correct...? whereas, > without ensuring that $greeting gets set in that particular scope, if > you had said this for instance: I wouldn't say that $our exposes a value for $greeting - it simply exposes $greeting itself. > use strict; > use warnings; > > Hello::sayHi(); > exit(0); > > package Hello; > INIT { our $greeting = 'Hello there'; } > sub sayHi { print $greeting . "\n" } > > This'll enerate expected errors ====> > Variable "$greeting" is not imported ... > Global symbol "$greeting" requires explicit package name ... > > ? The INIT block is one scope; the sayHi subroutine is another scope. That code sample sets the value of $greeting globally, but only declares $greeting in the INIT block. use strict; use warnings; Hello::sayHi(); exit(0); package Hello; INIT { our $greeting = 'Hello there'; } sub sayHi { our $greeting; print $greeting . "\n" } produces: Hello there Ronald From charles.e.derykus at boeing.com Sat Jan 3 12:14:08 2009 From: charles.e.derykus at boeing.com (DeRykus, Charles E) Date: Sat, 3 Jan 2009 12:14:08 -0800 Subject: SPUG: Predeclaring packages In-Reply-To: <20090103170322.GA94121@penkwe.pair.com> References: <20090103044204.GB87661@penkwe.pair.com> <20090103170322.GA94121@penkwe.pair.com> Message-ID: > Thanks for the explanation but your INIT block also exposes a value > for $greeting within the scope of the INIT block, correct...? whereas, > without ensuring that $greeting gets set in that particular scope, if > you had said this for instance: >> I wouldn't say that $our exposes a value for $greeting - it simply exposes $greeting itself. Not to overdo semantics but the docs say 'our' exposes a value .. maybe just to emphasize that the global value set by 'our', although similar in some ways to a lexical 'my', behaves differently, eg, our $global = 'waiter'; { our $global = 'server'; # code here sees 'server' } # code here still sees server vs. lexical { my $foo = "foo"; # only code here sees 'foo' ... } } > use strict; > use warnings; > > Hello::sayHi(); > exit(0); > > package Hello; > INIT { our $greeting = 'Hello there'; } > sub sayHi { print $greeting . "\n" } > > This'll enerate expected errors ====> > Variable "$greeting" is not imported ... > Global symbol "$greeting" requires explicit package name ... > > ? > The INIT block is one scope; the sayHi subroutine is another scope. That code sample sets the value of $greeting > globally, but only declares $greeting in the INIT block. > use strict; > use warnings; > Hello::sayHi(); > exit(0); > package Hello; > INIT { our $greeting = 'Hello there'; } > sub sayHi { our $greeting; print $greeting . "\n" } > produces: > Hello there You're right but the compile/runtime issues gets confusing to me anyway because setting the global $Hello::greeting at runtime does work but not via 'our'. #our $greeting = 'Hello there'; # not ok $Hello::greeting = 'Hello there'; # ok Hello::sayHi(); exit(0); package Hello; { our $greeting; sub sayHi { our $greeting; print $greeting . "\n" } } -- Charles DeRykus From rjk-spug at tamias.net Sat Jan 3 12:44:09 2009 From: rjk-spug at tamias.net (Ronald J Kimball) Date: Sat, 3 Jan 2009 15:44:09 -0500 Subject: SPUG: Predeclaring packages In-Reply-To: References: <20090103044204.GB87661@penkwe.pair.com> <20090103170322.GA94121@penkwe.pair.com> Message-ID: <20090103204408.GA49778@penkwe.pair.com> On Sat, Jan 03, 2009 at 12:14:08PM -0800, DeRykus, Charles E wrote: > > >> I wouldn't say that $our exposes a value for $greeting - it simply > exposes $greeting itself. > > Not to overdo semantics but the docs say 'our' exposes a value .. > maybe just to emphasize that the global value set by 'our', although > similar in some ways to a lexical 'my', behaves differently, eg, perldoc -f our states: "our" associates a simple name with a package variable in the current package for use within the current scope. If some place in the documentation suggests that 'our' exposes a value, I'd argue that's misleading and should be clarified. :) Not to put too fine a point on it, the global value is set by the assignment, not by 'our'. > You're right but the compile/runtime issues gets confusing > to me anyway because setting the global $Hello::greeting at > runtime does work but not via 'our'. > > > #our $greeting = 'Hello there'; # not ok > $Hello::greeting = 'Hello there'; # ok > Hello::sayHi(); > exit(0); > > package Hello; > { our $greeting; > sub sayHi { our $greeting; print $greeting . "\n" } > } The documentation mentioned the "current package". The commented-out line in your code snippet is in the package main, not the package Hello. our $greeting = 'Hello there'; Hello::sayHi(); exit(0); package Hello; sub sayHi { print $main::greeting . "\n" } Ronald From charles.e.derykus at boeing.com Sat Jan 3 16:18:25 2009 From: charles.e.derykus at boeing.com (DeRykus, Charles E) Date: Sat, 3 Jan 2009 16:18:25 -0800 Subject: SPUG: Predeclaring packages In-Reply-To: <20090103204408.GA49778@penkwe.pair.com> References: <20090103044204.GB87661@penkwe.pair.com> <20090103170322.GA94121@penkwe.pair.com> <20090103204408.GA49778@penkwe.pair.com> Message-ID: On Sat, Jan 03, 2009 at 12:14:08PM -0800, DeRykus, Charles E wrote: > > >> I wouldn't say that $our exposes a value for $greeting - it simply > exposes $greeting itself. > > Not to overdo semantics but the docs say 'our' exposes a value .. > maybe just to emphasize that the global value set by 'our', although > similar in some ways to a lexical 'my', behaves differently, eg, >> perldoc -f our states: >> "our" associates a simple name with a package variable in the current >> package for use within the current scope. >> If some place in the documentation suggests that 'our' exposes a value, I'd argue that's misleading and should be clarified. :) Maybe the word's a bit over-exposed :) > You're right but the compile/runtime issues gets confusing to me > anyway because setting the global $Hello::greeting at runtime does > work but not via 'our'. > > > #our $greeting = 'Hello there'; # not ok > $Hello::greeting = 'Hello there'; # ok > Hello::sayHi(); > exit(0); > > package Hello; > { our $greeting; > sub sayHi { our $greeting; print $greeting . "\n" } } >> The documentation mentioned the "current package". The commented-out line in your code snippet is in the >> package main, not the package Hello. >> our $greeting = 'Hello there'; >> Hello::sayHi(); >> exit(0); >> package Hello; >> sub sayHi { print $main::greeting . "\n" } Ah.. that should explain it but I see in the Camel, pg. 756: An our declaration declares a global variable that will be visible across its entire lexical scope, even across package boundaries. The package in which the variable is located is determined at the point of declaration, not at the point of use. This means the follow- ing behavior holds and is deemed to be a feature: package Foo; our $bar # $bar is $foo::bar for rest of lexical scoope $bar = 582; package Bar; print $bar; # prints 582, just as if "our" had been "my" Hm, seems as if the lexical scope of $greeting should make the package qualification unnecessary ... Stranger yet it appears to work here: perl -wle 'our $x = 3; Foo::foo(); package Foo; sub foo { print $x};' 3 -- Charles DeRykus From sthoenna at efn.org Sat Jan 3 18:01:11 2009 From: sthoenna at efn.org (Yitzchak Scott-Thoennes) Date: Sat, 3 Jan 2009 18:01:11 -0800 (PST) Subject: SPUG: Predeclaring packages In-Reply-To: References: <20090103044204.GB87661@penkwe.pair.com> <20090103170322.GA94121@penkwe.pair.com> <20090103204408.GA49778@penkwe.pair.com> Message-ID: <56733.97.113.117.187.1231034471.squirrel@webmail.efn.org> On Sat, January 3, 2009 4:18 pm, DeRykus, Charles E wrote: > On Sat, Jan 03, 2009 at 12:14:08PM -0800, DeRykus, Charles E wrote: >> #our $greeting = 'Hello there'; # not ok >> $Hello::greeting = 'Hello there'; # ok >> Hello::sayHi(); >> exit(0); >> >> package Hello; { our $greeting; >> sub sayHi { our $greeting; print $greeting . "\n" } } > Stranger yet it appears to work here: > > perl -wle 'our $x = 3; Foo::foo(); package Foo; sub foo { print $x};' > 3 In your earlier example, you had an our later, in package Hello (actually two). Without that, it works: our $greeting = 'Hello there'; # not ok #$Hello::greeting = 'Hello there'; # ok Hello::sayHi(); exit(0); package Hello; sub sayHi { print $greeting . "\n" } From charles.e.derykus at boeing.com Sat Jan 3 19:26:04 2009 From: charles.e.derykus at boeing.com (DeRykus, Charles E) Date: Sat, 3 Jan 2009 19:26:04 -0800 Subject: SPUG: Predeclaring packages In-Reply-To: <56733.97.113.117.187.1231034471.squirrel@webmail.efn.org> References: <20090103044204.GB87661@penkwe.pair.com> <20090103170322.GA94121@penkwe.pair.com> <20090103204408.GA49778@penkwe.pair.com> <56733.97.113.117.187.1231034471.squirrel@webmail.efn.org> Message-ID: On Sat, January 3, 2009 4:18 pm, DeRykus, Charles E wrote: > On Sat, Jan 03, 2009 at 12:14:08PM -0800, DeRykus, Charles E wrote: #our $greeting = 'Hello there'; # not ok $Hello::greeting = 'Hello there'; # ok Hello::sayHi(); exit(0); package Hello; { our $greeting; sub sayHi { our $greeting; print $greeting . "\n" } } > Stranger yet it appears to work here: > > perl -wle 'our $x = 3; Foo::foo(); package Foo; sub foo { print $x};' > 3 >> In your earlier example, you had an our later, in package Hello (actually two). Without that, it works: >> our $greeting = 'Hello there'; # not ok >> #$Hello::greeting = 'Hello there'; # ok >> Hello::sayHi(); >> exit(0); >> package Hello; >> sub sayHi { print $greeting . "\n" } Thanks, yes. Another subtlety. I'm beginning to think 'our' merits a perltrap entry except that most people would run screaming if they looked closely .. :) A summary: Hello::sayHi(); exit(0); package Hello; INIT { our $greeting = 'Hello there'; } # sub sayHi { print $greeting . "\n" }; # not ok sub sayHi { our $greeting; print $greeting . "\n" }; # ok sub sayHi { print $Hello::greeting . "\n" } # ok But the same 'our' declaration apparently occludes the earlier value of 'our' in this variant unless you package qualify: our $greeting = 'Hello there'; Hello::sayHi(); exit(0); package Hello; # sub sayHi { our $greeting; print $greeting; } # not ok sub sayHi { our $greeting; print $main::greeting; } # ok sub sayHi { print $greeting . "\n" }; # ok -- Charles DeRykus From choward at indicium.us Mon Jan 5 12:51:54 2009 From: choward at indicium.us (Christopher Howard) Date: Mon, 5 Jan 2009 11:51:54 -0900 (AKST) Subject: SPUG: Predeclaring packages In-Reply-To: References: <20090103044204.GB87661@penkwe.pair.com> <20090103170322.GA94121@penkwe.pair.com> <20090103204408.GA49778@penkwe.pair.com> <56733.97.113.117.187.1231034471.squirrel@webmail.efn.org> Message-ID: On Sat, 3 Jan 2009, DeRykus, Charles E wrote: Thank you everyone for the help. I think I have this figured out, and everything seems to be working fine in my code. Here's an explanation I posted on my blog: http://www.indicium.us/site_blog/2009/01/placing-a-package-at-the-end-of-the-perl-script.html. If you see any inaccuracies in the block post, please add a comment (for the benefit of the people who read my blog). -- Christopher Howard http://indicium.us From choward at indicium.us Mon Jan 5 12:51:54 2009 From: choward at indicium.us (Christopher Howard) Date: Mon, 5 Jan 2009 11:51:54 -0900 (AKST) Subject: SPUG: Predeclaring packages In-Reply-To: References: <20090103044204.GB87661@penkwe.pair.com> <20090103170322.GA94121@penkwe.pair.com> <20090103204408.GA49778@penkwe.pair.com> <56733.97.113.117.187.1231034471.squirrel@webmail.efn.org> Message-ID: On Sat, 3 Jan 2009, DeRykus, Charles E wrote: Thank you everyone for the help. I think I have this figured out, and everything seems to be working fine in my code. Here's an explanation I posted on my blog: http://www.indicium.us/site_blog/2009/01/placing-a-package-at-the-end-of-the-perl-script.html. If you see any inaccuracies in the block post, please add a comment (for the benefit of the people who read my blog). -- Christopher Howard http://indicium.us From choward at indicium.us Mon Jan 5 16:07:59 2009 From: choward at indicium.us (Christopher Howard) Date: Mon, 5 Jan 2009 15:07:59 -0900 (AKST) Subject: SPUG: Hashes and subroutines Message-ID: I've got this situation where I execute a certain subroutine based on the value of a variable, like so: if($var eq 'play') { sub1() } elsif($var eq 'that') { sub2() } elsif($var eq 'funky') { sub3() } elsif($var eq 'music') { sub4() } ... Is there some way to do this with a hash instead? Say, the possible values of $var are the keys in the hash, and subroutine names (or references or whatever) are the values in the hash? It'd be nice if I could write out one long hash, and then a small piece of code to execute the appropriate subroutine, instead of 20+ elsif statements. -- Christopher Howard http://indicium.us From paul at goracke.org Mon Jan 5 16:19:18 2009 From: paul at goracke.org (Paul Goracke) Date: Mon, 5 Jan 2009 16:19:18 -0800 Subject: SPUG: Hashes and subroutines In-Reply-To: References: Message-ID: <8FAC45AF-9EEE-4ADC-B404-D1B6B5D05DCA@goracke.org> On Jan 5, 2009, at 4:07 PM, Christopher Howard wrote: > I've got this situation where I execute a certain subroutine based > on the value of a variable, like so: > > if($var eq 'play') { sub1() } > elsif($var eq 'that') { sub2() } > elsif($var eq 'funky') { sub3() } > elsif($var eq 'music') { sub4() } > ... > > Is there some way to do this with a hash instead? Say, the possible > values of $var are the keys in the hash, and subroutine names (or > references or whatever) are the values in the hash? It'd be nice if > I could write out one long hash, and then a small piece of code to > execute the appropriate subroutine, instead of 20+ elsif statements. You're on the right track--use subroutine references. ------------------ my %commandMap = ( play => \&sub1, that => \&sub2, funky => \&sub3, music => \&sub4, ); if ( my $cmd = $commandMap{ $var } ) { $cmd->(); } else { print "Unknown command '$var'\n"; } ------------------ If you have parameters to pass, the sub would be called as "$cmd- >(@params)". pg From jerry.gay at gmail.com Mon Jan 5 16:26:40 2009 From: jerry.gay at gmail.com (jerry gay) Date: Mon, 5 Jan 2009 16:26:40 -0800 Subject: SPUG: Hashes and subroutines In-Reply-To: References: Message-ID: <1d9a3f400901051626w57e74facl1c7bdc4cfc070e57@mail.gmail.com> On Mon, Jan 5, 2009 at 16:07, Christopher Howard wrote: > I've got this situation where I execute a certain subroutine based on the > value of a variable, like so: > > if($var eq 'play') { sub1() } > elsif($var eq 'that') { sub2() } > elsif($var eq 'funky') { sub3() } > elsif($var eq 'music') { sub4() } > ... > > Is there some way to do this with a hash instead? Say, the possible values > of $var are the keys in the hash, and subroutine names (or references or > whatever) are the values in the hash? It'd be nice if I could write out one > long hash, and then a small piece of code to execute the appropriate > subroutine, instead of 20+ elsif statements. > yes. this is known as a dispatch table. i use a hash reference instead of a hash, because it's easier and more efficient for passing as a function argument (if you need to pass the dispatch table around--i do it all the time). my $actions = { play => \&sub1, that => \&sub2, funky => \&sub3, music => \&sub4, }; $actions->{$var}->(@arguments); more advanced techniques can be found in chapter 4 of "higher order perl", which i believe is freely available online. ~jerry From MichaelRWolf at att.net Mon Jan 5 18:48:50 2009 From: MichaelRWolf at att.net (Michael R. Wolf) Date: Mon, 5 Jan 2009 18:48:50 -0800 Subject: SPUG: Hashes and subroutines In-Reply-To: <1d9a3f400901051626w57e74facl1c7bdc4cfc070e57@mail.gmail.com> References: <1d9a3f400901051626w57e74facl1c7bdc4cfc070e57@mail.gmail.com> Message-ID: <28127F03-4B84-493E-ABA9-D79E44B73C9B@att.net> On Jan 5, 2009, at 4:26 PM, jerry gay wrote: > > > my $actions = { > play => \&sub1, > that => \&sub2, > funky => \&sub3, > music => \&sub4, > }; > > $actions->{$var}->(@arguments); > > more advanced techniques can be found in chapter 4 of "higher order > perl", which i believe is freely available online. > ~jerry Here's the PDF link. http://hop.perl.plover.com/book/pdf/04Iterators.pdf There's also a MOD (M's Old Documentation?) link, that's an MJD variant of POD elsewhere on his site. -- Michael R. Wolf All mammals learn by playing! MichaelRWolf at att.net From m3047 at inwa.net Mon Jan 5 18:56:47 2009 From: m3047 at inwa.net (Fred Morris) Date: Mon, 5 Jan 2009 18:56:47 -0800 Subject: SPUG: Hash of subs Re: Hashes and subroutines In-Reply-To: References: Message-ID: <200901051856.47036.m3047@inwa.net> Sure, I do it all the time. %H = ( play => sub {}, that=> sub {}, funky=> sub{}, music=> sub{} ); &{$H{play}}('awb'); Somebody will point out how to do it without so many braces. Maybe somebody will step up and show how to do it with the hash blessed and the subs as autoload methods. ;-) Too complicated for my needs though. -- Fred On Monday 05 January 2009 16:07, Christopher Howard wrote: > I've got this situation where I execute a certain subroutine based on the > value of a variable, like so: > > if($var eq 'play') { sub1() } > elsif($var eq 'that') { sub2() } > elsif($var eq 'funky') { sub3() } > elsif($var eq 'music') { sub4() } > ... > > Is there some way to do this with a hash instead? [...] From essuu at ourshack.com Tue Jan 6 00:13:23 2009 From: essuu at ourshack.com (Simon Wilcox) Date: Tue, 06 Jan 2009 08:13:23 +0000 Subject: SPUG: Hashes and subroutines In-Reply-To: References: Message-ID: <496312A3.2090703@ourshack.com> Christopher Howard wrote: > I've got this situation where I execute a certain subroutine based on > the value of a variable, like so: > > if($var eq 'play') { sub1() } > elsif($var eq 'that') { sub2() } > elsif($var eq 'funky') { sub3() } > elsif($var eq 'music') { sub4() } > ... > > Is there some way to do this with a hash instead? As others have said, dispatch tables are what you're looking for. I've always thought this article to be a really good introduction: https://db.usenix.org/publications/login/2002-06/pdfs/turoff.pdf Simon. From jack at foys.net Tue Jan 6 20:16:20 2009 From: jack at foys.net (Jack Foy) Date: Tue, 6 Jan 2009 20:16:20 -0800 Subject: SPUG: Hashes and subroutines In-Reply-To: <8FAC45AF-9EEE-4ADC-B404-D1B6B5D05DCA@goracke.org> References: <8FAC45AF-9EEE-4ADC-B404-D1B6B5D05DCA@goracke.org> Message-ID: <20090107041620.GP16058@foys.net> Paul Goracke wrote: > my %commandMap = ( > play => \&sub1, > that => \&sub2, > funky => \&sub3, > music => \&sub4, > ); > > if ( my $cmd = $commandMap{ $var } ) { > $cmd->(); > } > else { > print "Unknown command '$var'\n"; > } > > If you have parameters to pass, the sub would be called as "$cmd- > >(@params)". That's close to how I would have written it, too. What about this? sub runCommand { my $command = shift; my $rArgs = shift; # or use @_, but see note 1 my %actions = ( play => \&sub1, that => \&sub2, funky => \&sub3, music => \&sub4, ); # See note 2 my $rAction = $actions{$command} or return LogError ("Unknown command '$var'"); return &$rAction ($rArgs); } # Note 1: I avoid using @_ directly. This both makes the code easier to # read by making routine arguments explicit, and avoids accidental # aliasing. # Note 2: We use a logging library whose Log() variants are guaranteed # to return undef. That makes this kind of idiom easy to use. -- Jack Foy From choward at indicium.us Wed Jan 7 11:37:15 2009 From: choward at indicium.us (Christopher Howard) Date: Wed, 7 Jan 2009 10:37:15 -0900 (AKST) Subject: SPUG: Hashes and subroutines In-Reply-To: <871cb25b0901052229raf75864xc503036264558ede@mail.gmail.com> References: <1d9a3f400901051626w57e74facl1c7bdc4cfc070e57@mail.gmail.com> <28127F03-4B84-493E-ABA9-D79E44B73C9B@att.net> <871cb25b0901052229raf75864xc503036264558ede@mail.gmail.com> Message-ID: On Mon, 5 Jan 2009, Bill Warner wrote: > I love Higher Order Perl, and I have nothing against this technique, but chances are it's going to resemble a > class, or a system of classes, before you know it. Have you thought about the problems in terms of an object > model? Then you can just? as easily write 'no strict "refs"; $o->$method(@args)' . > > Thanks, > > ?b > > I'm not entirely against object oriented programming, but I generally try to avoid it until I see a very clear need for it. E.g., a need for multiple instantiations of an object, or a need for inheritance in a class hierarchy. I'm inclined to see a big difference between maintaining separate namespaces, and real object oriented programming. Anyone else feel the same way? -- Christopher Howard http://indicium.us From MichaelRWolf at att.net Wed Jan 7 13:31:56 2009 From: MichaelRWolf at att.net (Michael R. Wolf) Date: Wed, 7 Jan 2009 13:31:56 -0800 Subject: SPUG: argument-less shift - explicit/implicit [was: Hashes and subroutines] In-Reply-To: <20090107041620.GP16058@foys.net> References: <8FAC45AF-9EEE-4ADC-B404-D1B6B5D05DCA@goracke.org> <20090107041620.GP16058@foys.net> Message-ID: <07E1A2E2-DA43-40A6-9A61-6FAE209889C1@att.net> On Jan 6, 2009, at 8:16 PM, Jack Foy wrote: > Paul Goracke wrote: > > sub runCommand { > my $command = shift; > my $rArgs = shift; # or use @_, but see note 1 > [...] > > # Note 1: I avoid using @_ directly. This both makes the code > easier to > # read by making routine arguments explicit, and avoids accidental > # aliasing. This seems backwards to my way of thinking (i.e. my way of reading and writing code for my own and other's use): You use @_ *implicitly*, but state that *explicit* code is easier to read. Since shift without an argument has two different implicit arguments, depending on whether it's inside (@_) or outside (@ARGV) of a subroutine, this is one case where I'm diligent about being explicit about the arguments. I do that for readability. To my eyes, I think the first chunk of code is more explicit, and therefore readable. # EXPLICIT args to shift... my $script_arg = shift @ARGV; sub xxx { my $subroutine_arg = shift @_; } # IMPLICIT args to shift... my $script_arg = shift; sub xxx { my $subroutine_arg = shift; } I actually prefer the unpacking idiom as being much more explicit (for my definition of 'explicit'): sub xxx { my ($first_arg, $second_arg, @remaining_args) = @_; } I think that explicitly stating the argument to shift prevents the reader from having to keep the context in their head, therefore frees their mind for higher level tasks. Call it a "personal preference", or a "well-understood idiom", or a "group standard" if you wish, but I think using an implicit argument is *NOT* more explicit. -- Michael R. Wolf All mammals learn by playing! MichaelRWolf at att.net From rick.croote at philips.com Wed Jan 7 14:58:10 2009 From: rick.croote at philips.com (Croote, Rick) Date: Wed, 7 Jan 2009 23:58:10 +0100 Subject: SPUG: Hashes and subroutines In-Reply-To: References: <1d9a3f40090 1051626w57e74facl1c7bdc4cfc070e57@mail.gmail.com><28127F03-4B84-493E-ABA9-D 79E44B73C9B@att.net><871cb25b0901052229raf75864xc503036264558ede@mail.gmail.com> Message-ID: <6A00D845EC61DF46810F2D5BCB5F6E044BEC39C027@NLCLUEXM06.connect1.local> > -----Original Message----- > From: spug-list-bounces+rick.croote=philips.com at pm.org [mailto:spug- > list-bounces+rick.croote=philips.com at pm.org] On Behalf Of Christopher > Howard > Sent: 2009 Jan 07 11:37 AM > To: Bill Warner > Cc: Seattle Perl Users Group > Subject: Re: SPUG: Hashes and subroutines > > On Mon, 5 Jan 2009, Bill Warner wrote: > > > I love Higher Order Perl, and I have nothing against this technique, > > but chances are it's going to resemble a class, or a system of > > classes, before you know it. Have you thought about the problems in > terms of an object model? Then you can just as easily write 'no strict > "refs"; $o->$method(@args)' . > > > > Thanks, > > > > b > > > > > > I'm not entirely against object oriented programming, but I generally > try to avoid it until I see a very clear need for it. E.g., a need for > multiple instantiations of an object, or a need for inheritance in a > class hierarchy. > > I'm inclined to see a big difference between maintaining separate > namespaces, and real object oriented programming. > > Anyone else feel the same way? > > -- > Christopher Howard > http://indicium.us Totally disagree. I use namespaces only for classes, or the temporary extending of an existing class. In the group I work with all modules are created in object oriented fashion, without exception. It is just too easy to not do it. Further, to wait until there is a clear need is often too late, with too much investment in what "is" or too high of a risk for change. I tell all developers that I work with to never assume that an object will never be used elsewhere, in fact, the opposite, assume it will be used, but do not over develop for the current needs, only implement what is currently needed. This has reaped great benefits for our group, allowing us to create enough business infrastructure that allows for even faster development on projects that were never thought of at the time the infrastructure was put into place. The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From wwarner at gmail.com Wed Jan 7 17:13:41 2009 From: wwarner at gmail.com (Bill Warner) Date: Wed, 7 Jan 2009 17:13:41 -0800 Subject: SPUG: Hashes and subroutines In-Reply-To: References: <1d9a3f400901051626w57e74facl1c7bdc4cfc070e57@mail.gmail.com> <28127F03-4B84-493E-ABA9-D79E44B73C9B@att.net> <871cb25b0901052229raf75864xc503036264558ede@mail.gmail.com> Message-ID: <871cb25b0901071713m2cc9af33tfa773f0aa068f473@mail.gmail.com> We can agree java takes all the fun out of programming. And, yes, Linus hates c++, too http://lwn.net/Articles/249460/. But ask yourself, how is the dispatch table as presented in this thread any different that perl's symbol table? Usually passing around code references like this means that you're trying to create your own symbol table and yet another object model. If that's the case, then you haven't avoided OO programming at all, you've only attempted to reinvent it all by yourself. With respect to when OO is a good way to go, I think Damian Conway's 11 questions are a decent guide: http://perltraining.com.au/tips/2005-01-25.html I like OO and use it often. It makes it much easier for me to reuse my code, and much easier to change my mind. Thanks, b On Wed, Jan 7, 2009 at 11:37 AM, Christopher Howard wrote: > > I'm not entirely against object oriented programming, but I generally try > to avoid it until I see a very clear need for it. E.g., a need for multiple > instantiations of an object, or a need for inheritance in a class hierarchy. > > I'm inclined to see a big difference between maintaining separate > namespaces, and real object oriented programming. > > Anyone else feel the same way? > > > -- > Christopher Howard > http://indicium.us > -------------- next part -------------- An HTML attachment was scrubbed... URL: From choward at indicium.us Wed Jan 7 18:45:54 2009 From: choward at indicium.us (Christopher Howard) Date: Wed, 7 Jan 2009 17:45:54 -0900 (AKST) Subject: SPUG: Hating Java [formerly, Hashes and subroutines] In-Reply-To: <871cb25b0901071713m2cc9af33tfa773f0aa068f473@mail.gmail.com> References: <1d9a3f400901051626w57e74facl1c7bdc4cfc070e57@mail.gmail.com> <28127F03-4B84-493E-ABA9-D79E44B73C9B@att.net> <871cb25b0901052229raf75864xc503036264558ede@mail.gmail.com> <871cb25b0901071713m2cc9af33tfa773f0aa068f473@mail.gmail.com> Message-ID: On Wed, 7 Jan 2009, Bill Warner wrote: > We can agree java takes all the fun out of programming. And, yes, Linus hates c++, too > http://lwn.net/Articles/249460/. > You mean, there is some else out there who also hates Java? I thought I was the only one in the world! =] From jack at foys.net Wed Jan 7 20:55:00 2009 From: jack at foys.net (Jack Foy) Date: Wed, 7 Jan 2009 20:55:00 -0800 Subject: SPUG: argument-less shift - explicit/implicit [was: Hashes and subroutines] In-Reply-To: <07E1A2E2-DA43-40A6-9A61-6FAE209889C1@att.net> References: <8FAC45AF-9EEE-4ADC-B404-D1B6B5D05DCA@goracke.org> <20090107041620.GP16058@foys.net> <07E1A2E2-DA43-40A6-9A61-6FAE209889C1@att.net> Message-ID: <20090108045500.GR16058@foys.net> Michael R. Wolf wrote: > Jack Foy wrote: > >sub runCommand { > > my $command = shift; > > my $rArgs = shift; # or use @_, but see note 1 > > This seems backwards to my way of thinking (i.e. my way of reading and > writing code for my own and other's use): > You use @_ *implicitly*, but state that *explicit* code is easier > to read. You're right, I was unclear. I meant, it's more explicit to call our hypothetical routine like so: runCommand ($command, \@commandArgs); rather than something like this: runCommand ($command, @commandArgs); You gave one example of how that might be implemented: > sub xxx { > my ($first_arg, $second_arg, @remaining_args) = @_; > } I avoid that approach because it makes it much more expensive to pass around and manipulate large data structures (by requiring a copy of every element of @remaining_args). The alternate implementation I was thinking of, but advised against, was to pass the remaining elements of @_ through to the selected caller: sub runCommand { my $command = shift; my %actions = ( play => \&sub1, that => \&sub2, funky => \&sub3, music => \&sub4, ); my $rAction = $actions{$command} or return LogError ("Unknown command '$command'"); return &$rAction (@_); } That's a perfectly acceptable alternative, especially if you want the routine selected from the table to behave (almost) as though it were called directly by runCommand()'s caller. But it carries the twin costs of obscuring the interface to runCommand(), and exposing the original arguments to runCommand() to @_'s aliasing behavior. By the way, note that a further alternative is to use the "magic goto": sub runCommand { my $command = shift; my %actions = ( play => \&sub1, that => \&sub2, funky => \&sub3, music => \&sub4, ); my $rAction = $actions{$command} or return LogError ("Unknown command '$command'"); goto &$rAction; } This really does behave as though the caller to runCommand() actually invoked the selected caller directly! It replaces runCommand() with the selected routine on the call stack, with @_ as the argument. There are rare times when this is the Right Thing. Use with appropriate caution. -- Jack Foy From MichaelRWolf at att.net Thu Jan 8 11:16:18 2009 From: MichaelRWolf at att.net (Michael R. Wolf) Date: Thu, 8 Jan 2009 11:16:18 -0800 Subject: SPUG: argument-less shift - explicit/implicit [was: Hashes and subroutines] In-Reply-To: <20090108045500.GR16058@foys.net> References: <8FAC45AF-9EEE-4ADC-B404-D1B6B5D05DCA@goracke.org> <20090107041620.GP16058@foys.net> <07E1A2E2-DA43-40A6-9A61-6FAE209889C1@att.net> <20090108045500.GR16058@foys.net> Message-ID: <3F7C3548-3115-44F4-8146-5B39A351FB8C@att.net> On Jan 7, 2009, at 8:55 PM, Jack Foy wrote: > Michael R. Wolf wrote: >> Jack Foy wrote: >>> sub runCommand { >>> my $command = shift; >>> my $rArgs = shift; # or use @_, but see note 1 >> >> This seems backwards to my way of thinking (i.e. my way of reading >> and >> writing code for my own and other's use): >> You use @_ *implicitly*, but state that *explicit* code is easier >> to read. > > You're right, I was unclear. I meant, it's more explicit to call our > hypothetical routine like so: > > runCommand ($command, \@commandArgs); > > rather than something like this: > > runCommand ($command, @commandArgs); > > You gave one example of how that might be implemented: > >> sub xxx { >> my ($first_arg, $second_arg, @remaining_args) = @_; >> } > > I avoid that approach because it makes it much more expensive to pass > around and manipulate large data structures (by requiring a copy of > every element of @remaining_args). > OK. Got it. I agree. SImple arguments should come in as a list, but complex or large arguments should come in as a reference. In that case, I typically tack "_ref" to the end of the variable. I typically do *not* like hungarian notation, but since scalars can be used for so many things, it's more readable (for my definition of readable) to differentiate the different kinds of scalars. I guess what I'd call $action_ref, you call $rAction. Since my fingers grew up at Bell Labs (writing C), I tend to use underscore more than the shift key. I still don't like shift without an argument. It's too contextual for my taste. > By the way, note that a further alternative is to use the "magic > goto": > > > sub runCommand { > my $command = shift; > Thanks for *showing* the magic... > > goto &$rAction; > } > > > This really does behave as though the caller to runCommand() actually > invoked the selected caller directly! It replaces runCommand() with > the > selected routine on the call stack, with @_ as the argument. There > are > rare times when this is the Right Thing. Use with appropriate > caution. > ... and thanks for warning about its limited usefulness. Since it's such powerful "magic", I'd be tempted to put in a comment. Factoring in your suggestions, I'd refactor the code to sub runCommand { my $command = shift @_; my %actions = ( play => \&sub1, that => \&sub2, funky => \&sub3, music => \&sub4, 'white boy' => sub { 'lay down the rhythm and play that funky music' until 'you die' } ); my $action_ref = $actions{$command}; # Magic goto... goto &{$action_ref} if $action_ref; return LogError ("Unknown command '$command'"); } Depending on the level of *other* readers, I may or may not augment the "magic goto" comment. -- Michael R. Wolf All mammals learn by playing! MichaelRWolf at att.net From cmeyer at helvella.org Thu Jan 8 12:59:06 2009 From: cmeyer at helvella.org (Colin Meyer) Date: Thu, 8 Jan 2009 12:59:06 -0800 Subject: SPUG: January 2009 Seattle Perl Users Group (SPUG) Meeting Message-ID: <20090108205906.GC27287@infula.helvella.org> January 2009 Seattle Perl Users Group (SPUG) Meeting ==================================================== Topic: Perl in the Amazon Cloud Speaker: Jinesh Varia Meeting Date: Tuesday, 20 January 2009 Meeting Time: 6:30 - 8:30 p.m. Location: Marchex - 4th & Pine Cost: Admission is free and open to the public Info: http://seattleperl.org/ ==================================================== Tuesday, January 20, is the next meeting of the THE SEATTLE PERL USERS GROUP. In this session, Jinesh Varia, Evangelist at Amazon Web Services, will share with you some cool ways to develop, test and run perl applications in the cloud. Amazon Web Services provides Amazon Elastic Compute Cloud (Amazon EC2) that allows requisition of machines on-demand using simple web service call and paying for computation by the hour. Amazon Simple Storage Service (Amazon S3) which is infinite digital storage in the cloud. Amazon SimpleDB which is database in the cloud and Amazon Mechanical Turk which is the on-demand Workforce and how these services can help companies to scale-out and go live quickly without any upfront investment. Jinesh Varia, Technology Evangelist, Amazon Web Services, Amazon.com As a Technology Evangelist at Amazon, Jinesh Varia helps developers take advantage of disruptive technologies that are going to change the way we think about computer applications, and the way businesses compete in the new web world. Jinesh has spoken at more than 50 conferences/UserGroups. He is focused on furthering awareness of web services and often helps developers on 1:1 basis in implementing their own ideas using Amazon's innovative services. Jinesh has over 9 years experience in XML and Web services and has worked with standards-based working groups in XBRL. Prior to joining Amazon as an evangelist, he held several positions in UBmatrix including Solutions Architect, Enterprise Team Lead and Software engineer, working on various financial services projects including Call Modernization Project at FDIC. He was also lead developer at Penn State Data Center, Institute of Regional Affairs. Jinesh's publications have been published in ACM and IEEE. Jinesh is originally from India and holds a Master's degree in Information Systems from Penn State University. He plays tennis and loves to trek. Pre-Meeting ================ If you are so inclined, please come to the pre-meeting at the Elephant & Castle pub on 5th & Union. We'll be there from 5-6:19PM. Meeting Location ================ Pizza and Beer will be provided at the meeting. Marchex 413 Pine St, Suite 500 Seattle, WA 98101 Contact: Jackie Wolfstone - 206-491-8072 The building is just south of Westlake Center. Enter on 4th Avenue, near Pine street. The entry is near the Dog In The Park hotdog stand. http://www.baylis.org/static/marchex.png Due to all of the shopping around us there is plenty of parking available in garages, but it can be hard to find street parking in the evening. See you there! From mail.spammagnet at gmail.com Fri Jan 9 09:54:07 2009 From: mail.spammagnet at gmail.com (BenRifkah Bergsten-Buret) Date: Fri, 9 Jan 2009 09:54:07 -0800 Subject: SPUG: January 2009 Seattle Perl Users Group (SPUG) Meeting In-Reply-To: <20090108205906.GC27287@infula.helvella.org> References: <20090108205906.GC27287@infula.helvella.org> Message-ID: I'm bummed I'll have to miss this. I wonder how many others will be at inauguration parties? I hope that you can make the presentation materials available afterward. -- Ben On Thu, Jan 8, 2009 at 12:59 PM, Colin Meyer wrote: > January 2009 Seattle Perl Users Group (SPUG) Meeting > ==================================================== > > Topic: Perl in the Amazon Cloud > Speaker: Jinesh Varia > Meeting Date: Tuesday, 20 January 2009 > Meeting Time: 6:30 - 8:30 p.m. > Location: Marchex - 4th & Pine > > Cost: Admission is free and open to the public > Info: http://seattleperl.org/ > > ==================================================== > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joel at largest.org Fri Jan 9 10:45:23 2009 From: joel at largest.org (Joel Grow) Date: Fri, 9 Jan 2009 13:45:23 -0500 (EST) Subject: SPUG: programmatically managing cookies Message-ID: <20090109133513.G38598@lepen.pair.com> Hi Perl gurus, I'd like to programmatically access a password-protected site. When I GET the url, I receive back HTML with a javascript relay to a login page, and a cookie. I do have credentials for the site. So I can POST my username/password to the login page, but I need to manage the cookie the site sets so that I can then be forwarded to the password-protected area. Before I dive too deeply into this, does anyone have advice/pointers on the best way to manage this? -J (my problem would ultimately be solved by NY Times opening up their article search API, which is "coming soon"...) From charles.e.derykus at boeing.com Fri Jan 9 11:09:02 2009 From: charles.e.derykus at boeing.com (DeRykus, Charles E) Date: Fri, 9 Jan 2009 11:09:02 -0800 Subject: SPUG: programmatically managing cookies In-Reply-To: <20090109133513.G38598@lepen.pair.com> References: <20090109133513.G38598@lepen.pair.com> Message-ID: > I'd like to programmatically access a password-protected site. When I GET the url, I receive back HTML > with a javascript relay to a login page, and a cookie. I do have credentials for the site. So I can > POST my username/password to the login page, but I need to manage the cookie the site sets so that I can > then be forwarded to the password-protected area. > Before I dive too deeply into this, does anyone have advice/pointers on the best way to manage this? I've used LWP and HTTP::Cookies to navigate a similar setup. -- Charles DeRykus From haircut at gmail.com Fri Jan 9 13:54:32 2009 From: haircut at gmail.com (Adam Monsen) Date: Fri, 9 Jan 2009 15:54:32 -0600 Subject: SPUG: programmatically managing cookies In-Reply-To: <20090109133513.G38598@lepen.pair.com> References: <20090109133513.G38598@lepen.pair.com> Message-ID: <9ebd65110901091354g5e123ce2n1acacaae7be82972@mail.gmail.com> On Fri, Jan 9, 2009 at 12:45 PM, Joel Grow wrote: > I'd like to programmatically access a password-protected site. When I GET > the url, I receive back HTML with a javascript relay to a login page, and a > cookie. I do have credentials for the site. So I can POST my > username/password to the login page, but I need to manage the cookie the > site sets so that I can then be forwarded to the password-protected area. > Before I dive too deeply into this, does anyone have advice/pointers on the > best way to manage this? I'm a fan of WWW::Mechanize, but apparently it can't do JavaScript besides window.open(). Some ideas: * add a JavaScript interpreter to WWW::Mechanize * use Selenium RC and Perl client driver * the Ruby version of WWW::Mechanize might support JavaScript, I'm not sure Out of those, I know that Selenium can handle JavaScript since it drives a bona fide Web browser. Also, you can prototype your Web actions (with record/playback) in the Selenium IDE. I recently gave a talk on Selenium. Slides are available, if you're interested: http://adammonsen.com/talks . The examples are in Python, but there's really nothing fancy--they should be easily portable to Perl. -- Adam Monsen From chesseditor at yahoo.com Fri Jan 9 18:45:11 2009 From: chesseditor at yahoo.com (Eric) Date: Fri, 9 Jan 2009 18:45:11 -0800 (PST) Subject: SPUG: programmatically managing cookies In-Reply-To: <9ebd65110901091354g5e123ce2n1acacaae7be82972@mail.gmail.com> Message-ID: <251313.56506.qm@web50302.mail.re2.yahoo.com> Does anyone know of a web page somewhere that compares the capabilities of all the perl modules for http? I'd love to know the relative strengths and weaknesses of Net:HTTP, LWP, WWW::Mechanize and any other ones I don't know about. Eric Harman QA Engineer --- On Fri, 1/9/09, Adam Monsen wrote: > From: Adam Monsen > Subject: Re: SPUG: programmatically managing cookies > To: "Spug-list" > Date: Friday, January 9, 2009, 1:54 PM > On Fri, Jan 9, 2009 at 12:45 PM, Joel Grow wrote: > > I'd like to programmatically access a > password-protected site. When I GET > > the url, I receive back HTML with a javascript relay > to a login page, and a > > cookie. I do have credentials for the site. So I can > POST my > > username/password to the login page, but I need to > manage the cookie the > > site sets so that I can then be forwarded to the > password-protected area. > > Before I dive too deeply into this, does anyone have > advice/pointers on the > > best way to manage this? > > I'm a fan of WWW::Mechanize, but apparently it > can't do JavaScript > besides window.open(). > > Some ideas: > * add a JavaScript interpreter to WWW::Mechanize > * use Selenium RC and Perl client driver > * the Ruby version of WWW::Mechanize might support > JavaScript, I'm not sure > > Out of those, I know that Selenium can handle JavaScript > since it > drives a bona fide Web browser. Also, you can prototype > your Web > actions (with record/playback) in the Selenium IDE. > > I recently gave a talk on Selenium. Slides are available, > if you're > interested: http://adammonsen.com/talks . The examples are > in Python, > but there's really nothing fancy--they should be easily > portable to > Perl. > > -- > Adam Monsen > _____________________________________________________________ > Seattle Perl Users Group Mailing List > POST TO: spug-list at pm.org > SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list > MEETINGS: 3rd Tuesdays > WEB PAGE: http://seattleperl.org/ From choward at indicium.us Mon Jan 12 13:47:00 2009 From: choward at indicium.us (Christopher Howard) Date: Mon, 12 Jan 2009 12:47:00 -0900 (AKST) Subject: SPUG: Metacharacters in variables in regular expressions Message-ID: I wanted to do something like this: my $answer = <>; chomp $answer; if($some_earlier_var =~ /$answer/) { ### destroy the universe ### } But I need $answer to be 'safe', so the metacharacters aren't interpreted as such in the regex. What is the best thing to do here, then? I read the documentation, but was still a little uncertain. Here's a quote from perlre: ### START QUOTE ### Backslashed metacharacters in Perl are alphanumeric, such as "\b", "\w", "\n". Unlike some other regular expression languages, there are no backslashed symbols that aren?t alphanumeric. So anything that looks like \\, \(, \), \<, \>, \{, or \} is always interpreted as a literal character, not a metacharacter. This was once used in a common idiom to disable or quote the special meanings of regular expression metacharacters in a string that you want to use for a pattern. Simply quote all non-"word" characters: $pattern =~ s/(\W)/\\$1/g; (If "use locale" is set, then this depends on the current locale.) Today it is more common to use the quotemeta() function or the "\Q" metaquoting escape sequence to disable all metacharacters? special meanings like this: /$unquoted\Q$quoted\E$unquoted/ Beware that if you put literal backslashes (those not inside interpolated variables) between "\Q" and "\E", double-quotish backslash interpolation may lead to confusing results. If you need to use literal backslashes within "\Q...\E", consult "Gory details of parsing quoted constructs" in perlop. ### END QUOTE ### So this is what I want, right?: if($some_earlier_var =~ /\Q$answer\E/) { ### destroy the universe ### } -- Christopher Howard http://indicium.us From jarich at perltraining.com.au Mon Jan 12 15:42:54 2009 From: jarich at perltraining.com.au (Jacinta Richardson) Date: Tue, 13 Jan 2009 10:42:54 +1100 Subject: SPUG: Metacharacters in variables in regular expressions In-Reply-To: References: Message-ID: <496BD57E.80903@perltraining.com.au> Christopher Howard wrote: > I wanted to do something like this: > > my $answer = <>; > chomp $answer; > if($some_earlier_var =~ /$answer/) { ### destroy the universe ### } > > But I need $answer to be 'safe', so the metacharacters aren't > interpreted as such in the regex. What is the best thing to do here, then? > So this is what I want, right?: > > if($some_earlier_var =~ /\Q$answer\E/) { ### destroy the universe ### } Yes, that's exactly what you want. J -- ("`-''-/").___..--''"`-._ | Jacinta Richardson | `6_ 6 ) `-. ( ).`-.__.`) | Perl Training Australia | (_Y_.)' ._ ) `._ `. ``-..-' | +61 3 9354 6001 | _..`--'_..-_/ /--'_.' ,' | contact at perltraining.com.au | (il),-'' (li),' ((!.-' | www.perltraining.com.au | From k_clarke at perlprogrammer.net Mon Jan 12 16:07:22 2009 From: k_clarke at perlprogrammer.net (Ken Clarke) Date: Mon, 12 Jan 2009 20:07:22 -0400 Subject: SPUG: Metacharacters in variables in regular expressions References: Message-ID: <40616B51D2F741E784F6B7207E4262A8@kens> > So this is what I want, right?: > > if($some_earlier_var =~ /\Q$answer\E/) { ### destroy the universe ### } Yes. You likely also want to anchor it so the match is not in the middle of the string, which would make it: /^\Q$answer\E\z/ >> Ken Clarke >> Contract Web Programmer / E-commerce Technologist >> www.PerlProgrammer.net From jwkrahn at shaw.ca Mon Jan 12 16:22:31 2009 From: jwkrahn at shaw.ca (John W. Krahn) Date: Mon, 12 Jan 2009 16:22:31 -0800 Subject: SPUG: Metacharacters in variables in regular expressions In-Reply-To: References: Message-ID: <496BDEC7.4020308@shaw.ca> Christopher Howard wrote: > I wanted to do something like this: > > my $answer = <>; > chomp $answer; > if($some_earlier_var =~ /$answer/) { ### destroy the universe ### } > > But I need $answer to be 'safe', so the metacharacters aren't > interpreted as such in the regex. What is the best thing to do here, then? > [ snip ] > > So this is what I want, right?: > > if($some_earlier_var =~ /\Q$answer\E/) { ### destroy the universe ### } Yes, or you could do it like this: if(index{$some_earlier_var, $answer) >= 0) { ### destroy the universe ### } John -- Those people who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov From choward at indicium.us Wed Jan 14 16:09:38 2009 From: choward at indicium.us (Christopher Howard) Date: Wed, 14 Jan 2009 15:09:38 -0900 (AKST) Subject: SPUG: Packaging a Perl app? Message-ID: I'm writing my first real Perl application at work, a Linux console app. It depends on one module outside the core distribution (Term::ReadKey). I was hoping to wrap the app into a tarball package. I currently have a simple Makefile that installs the app to /usr/bin, or to $HOME/bin for a local install, plus documentation. This does not seem like enough, though, because it doesn't check to see whether all needed modules are available before installing, and doesn't adjust to particulars of the user's system. My Question: Can (and should) I use MakeMaker and a Makefile.PL for this? I looked at ExtUtils::MakeMaker::Tutorial, but it seemed like it was meant more for packaging modules for installation, rather than applications. Or is there some other option I should consider? -- Christopher Howard http://indicium.us From breno at rio.pm.org Wed Jan 14 17:41:42 2009 From: breno at rio.pm.org (breno) Date: Wed, 14 Jan 2009 23:41:42 -0200 Subject: SPUG: Packaging a Perl app? In-Reply-To: References: Message-ID: On Wed, Jan 14, 2009 at 10:09 PM, Christopher Howard wrote: > I'm writing my first real Perl application at work, a Linux console app. It > depends on one module outside the core distribution (Term::ReadKey). > > I was hoping to wrap the app into a tarball package. I currently have a > simple Makefile that installs the app to /usr/bin, or to $HOME/bin for a > local install, plus documentation. This does not seem like enough, though, > because it doesn't check to see whether all needed modules are available > before installing, and doesn't adjust to particulars of the user's system. > > My Question: Can (and should) I use MakeMaker and a Makefile.PL for this? I > looked at ExtUtils::MakeMaker::Tutorial, but it seemed like it was meant > more for packaging modules for installation, rather than applications. > > Or is there some other option I should consider? > Check out PAR: http://search.cpan.org/perldoc?PAR Cheers, -b From choward at indicium.us Thu Jan 15 17:44:36 2009 From: choward at indicium.us (Christopher Howard) Date: Thu, 15 Jan 2009 16:44:36 -0900 (AKST) Subject: SPUG: version numbers and MakeMaker Message-ID: I'm creating my first Makefile.PL, and had a question: There is one key/value pair for the version number. I have seen it like this in examples: ... VERSION => 1.4, ... But if the version number of my app is, say 0.1.2, what should the line look like? VERSION => '0.1.2', or VERSION => 0.001.002 Or does it even matter? I'm inclined toward '0.1.2' because I prefer that, and when I tried it with make dist the archive name came out looking the way I prefer. You know, if I ever get really good at MakeMaker, I think I'm going to volunteer to update the documentation with lots of examples. =] -- Christopher Howard http://indicium.us From tyemq at cpan.org Thu Jan 15 18:17:59 2009 From: tyemq at cpan.org (Tye McQueen) Date: Thu, 15 Jan 2009 18:17:59 -0800 Subject: SPUG: version numbers and MakeMaker In-Reply-To: References: Message-ID: I would discourage using version numbers that aren't numbers and that don't sort properly when treated as strings (which means a fixed number of digits per component). version.pm tries to deal with some of the problems caused by such attempts but it still isn't a perfect solution. My version numbers are usually like 1.001, 1.01_001, or 1.001_001 and I skip subversion numbers that are multiples of ten. So version numbers jump from 1.01_019 to 1.01_021. I also leave enough digits per component such that the leading 0 almost never gets incremented. Note that our $VERSION= 1.02_013; is exactly the same as our $VERSION= 1.02013; the underscore disappears from the value and is only apparent in the source code. On Thu, Jan 15, 2009 at 5:44 PM, Christopher Howard wrote: > I'm creating my first Makefile.PL, and had a question: There is one > key/value pair for the version number. I have seen it like this in examples: > > ... > VERSION => 1.4, > ... > > But if the version number of my app is, say 0.1.2, what should the line > look like? > > VERSION => '0.1.2', > > or > > VERSION => 0.001.002 > > Or does it even matter? I'm inclined toward '0.1.2' because I prefer that, > and when I tried it with make dist the archive name came out looking the way > I prefer. > > You know, if I ever get really good at MakeMaker, I think I'm going to > volunteer to update the documentation with lots of examples. =] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From choward at indicium.us Tue Jan 20 12:27:48 2009 From: choward at indicium.us (Christopher Howard) Date: Tue, 20 Jan 2009 11:27:48 -0900 (AKST) Subject: SPUG: File::Basename vs. File::Spec Message-ID: Question: if I know my application is working with Unix filenames, which is better: File::Basename or File::Spec (or some other core module)? Basically, all I want to do is split a full path into directory portion and file portion, make an adjustment to the file portion, and then recombine them back into the full path. -- Christopher Howard http://indicium.us From bill at celestial.com Tue Jan 20 12:54:08 2009 From: bill at celestial.com (Bill Campbell) Date: Tue, 20 Jan 2009 12:54:08 -0800 Subject: SPUG: File::Basename vs. File::Spec In-Reply-To: References: Message-ID: <20090120205408.GA23935@ayn.mi.celestial.com> On Tue, Jan 20, 2009, Christopher Howard wrote: > Question: if I know my application is working with Unix filenames, which > is better: File::Basename or File::Spec (or some other core module)? > > Basically, all I want to do is split a full path into directory portion > and file portion, make an adjustment to the file portion, and then > recombine them back into the full path. If you are going to do this generally, I think you need both. File::Basename to separate into the parts, and File::Spec to put the results back together again. Bill -- INTERNET: bill at celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax: (206) 232-9186 The Income Tax has made more Liars out of American people than Golf has. Will Rogers From bill at celestial.com Tue Jan 20 12:54:08 2009 From: bill at celestial.com (Bill Campbell) Date: Tue, 20 Jan 2009 12:54:08 -0800 Subject: SPUG: File::Basename vs. File::Spec In-Reply-To: References: Message-ID: <20090120205408.GA23935@ayn.mi.celestial.com> On Tue, Jan 20, 2009, Christopher Howard wrote: > Question: if I know my application is working with Unix filenames, which > is better: File::Basename or File::Spec (or some other core module)? > > Basically, all I want to do is split a full path into directory portion > and file portion, make an adjustment to the file portion, and then > recombine them back into the full path. If you are going to do this generally, I think you need both. File::Basename to separate into the parts, and File::Spec to put the results back together again. Bill -- INTERNET: bill at celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax: (206) 232-9186 The Income Tax has made more Liars out of American people than Golf has. Will Rogers From MichaelRWolf at att.net Tue Jan 20 16:17:06 2009 From: MichaelRWolf at att.net (Michael R. Wolf) Date: Tue, 20 Jan 2009 16:17:06 -0800 Subject: SPUG: version numbers and MakeMaker In-Reply-To: References: Message-ID: <3094F85D-CD8D-4D13-9F86-5BAF1AA33734@att.net> On Jan 15, 2009, at 5:44 PM, Christopher Howard wrote: > I'm creating my first Makefile.PL, and had a question: There is one > key/value pair for the version number. I have seen it like this in > examples: On a related note: How do folks handle letting Subversion integrate here? I know you asked a question about Perl's $VERSION, but I've seen folks integrate it with Subversion's Revision keyword. I've seen an idiom like this. It needs to allow svn to replace '$Revision$', but also be OK Perl that sets $VERSION, and can fit on one line. our($VERSION) = ('$Revision$' =~ m/Revision:\s*(\d+)/); Any other idioms? What's your favorite? Or don't you mix Version (e.g. 1.0, 1.1, 2.0) with revisions (2, 3, 4, 5)? -- Michael R. Wolf All mammals learn by playing! MichaelRWolf at att.net From tyemq at cpan.org Tue Jan 20 20:38:18 2009 From: tyemq at cpan.org (Tye McQueen) Date: Tue, 20 Jan 2009 20:38:18 -0800 Subject: SPUG: version numbers and MakeMaker In-Reply-To: <3094F85D-CD8D-4D13-9F86-5BAF1AA33734@att.net> References: <3094F85D-CD8D-4D13-9F86-5BAF1AA33734@att.net> Message-ID: On Tue, Jan 20, 2009 at 4:17 PM, Michael R. Wolf wrote: > > our($VERSION) = ('$Revision$' =~ m/Revision:\s*(\d+)/); > > Any other idioms? What's your favorite? > > Or don't you mix Version (e.g. 1.0, 1.1, 2.0) with revisions (2, 3, 4, 5)? > I don't mix revision control numbers with release numbers. Instead I automate release such that actually releasing increments to the *next* release number and checks that change in such that I can't accidentally release that same release number again. Tye -------------- next part -------------- An HTML attachment was scrubbed... URL: From MichaelRWolf at att.net Tue Jan 20 23:25:44 2009 From: MichaelRWolf at att.net (Michael R. Wolf) Date: Tue, 20 Jan 2009 23:25:44 -0800 Subject: SPUG: More Cloud Computing [was: January 2009 Seattle Perl Users Group (SPUG) Meeting] In-Reply-To: <20090108205906.GC27287@infula.helvella.org> References: <20090108205906.GC27287@infula.helvella.org> Message-ID: On Jan 8, 2009, at 12:59 PM, Colin Meyer wrote: > January 2009 Seattle Perl Users Group (SPUG) Meeting > ==================================================== > > Topic: Perl in the Amazon Cloud > Speaker: Jinesh Varia > Meeting Date: Tuesday, 20 January 2009 Sorry I didn't make it. For those interested in more cloud computing, here's a WTIA (formerly WSA (formerly Washington Software Association)) event... http://www.washingtontechnology.org/pages/events/events_events_wsaevent_directions.asp?EventID=775#location159 Here's a direct quote from that page... The WTIA is pleased to bring to the Puget Sound a comprehensive look at Cloud Computing. Through this multi part series attendees will learn both fundamental and advanced concepts of Cloud Computing as seen through the eyes of industry leaders. Cloud Computing is the buzz of the industry. Whether as a way to lower computing costs, test an application, or provide a more scalable solution, Cloud Computing offers a whole range of new opportunities for software developers and IT professionals. Anyone running a web service business or managing an IT enterprise system should understand the opportunities and challenges of this new computing model. Part I: Cloud Computing Fundamentals Aaron Kimball of Cloudera will be providing a high-level overview of cloud computing and explain how this computing model leads to more effective and flexible methods to deal with data. Aaron will talk about ways that computation has changed and evolved in recent years, as well as discuss examples of commercial and open-source systems that companies currently use to leverage the cloud. After you?ve learned the basics, Jason Lochhead, CTO of Terremark Hosting Services Division will be provide a live demonstration of an Enterprise Cloud platform, showing how servers can be configured, deployed and managed on-demand from a flexible pool of computing resources. He?ll also discuss examples of real-world implementations and showcase how companies are leveraging the cloud for their business. Series Sponsor Terremark -- Michael R. Wolf All mammals learn by playing! MichaelRWolf at att.net From zstephenblum at hotmail.com Wed Jan 21 13:00:51 2009 From: zstephenblum at hotmail.com (Stephen Blum) Date: Wed, 21 Jan 2009 13:00:51 -0800 Subject: SPUG: Jinesh Varia, Technology Evangelist, Amazon Web Services, Amazon.com In-Reply-To: References: Message-ID: Seattle Perl User Group: Jinesh Varia, Technology Evangelist, Amazon Web Services, Amazon.com VIDEO: http://www.vimeo.com/2910256 In this session, Jinesh Varia, Evangelist at Amazon Web Services, will share with you some cool ways to develop, test and run perl applications in the cloud. Amazon Web Services provides Amazon Elastic Compute Cloud aws.amazon.com/ec2 (Amazon EC2) that allows requisition of machines on-demand using simple web service call and paying for computation by the hour. Amazon Simple Storage Service aws.amazon.com/s3 (Amazon S3) which is infinite digital storage in the cloud. Amazon SimpleDB aws.amazon.com/sdb which is database in the cloud and Amazon Mechanical Turk aws.amazon.com/mturk which is the on-demand Workforce and how these services can help companies to scale-out and go live quickly without any upfront investment. Jinesh Varia, Technology Evangelist, Amazon Web Services, Amazon.com As a Technology Evangelist at Amazon, Jinesh Varia helps developers take advantage of disruptive technologies that are going to change the way we think about computer applications, and the way businesses compete in the new web world. Jinesh has spoken at more than 50 conferences/UserGroups. He is focused on furthering awareness of web services and often helps developers on 1:1 basis in implementing their own ideas using Amazon's innovative services. Jinesh has over 9 years experience in XML and Web services and has worked with standards-based working groups in XBRL. Prior to joining Amazon as an evangelist, he held several positions in UBmatrix including Solutions Architect, Enterprise Team Lead and Software engineer, working on various financial services projects including Call Modernization Project at FDIC. He was also lead developer at Penn State Data Center, Institute of Regional Affairs. Jinesh's publications have been published in ACM and IEEE. Jinesh is originally from India and holds a Master's degree in Information Systems from Penn State University. He plays tennis and loves to trek. _________________________________________________________________ Windows Live? Hotmail?:?more than just e-mail. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_explore_012009 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmeyer at helvella.org Wed Jan 21 13:06:24 2009 From: cmeyer at helvella.org (Colin Meyer) Date: Wed, 21 Jan 2009 13:06:24 -0800 Subject: SPUG: Jinesh Varia, Technology Evangelist, Amazon Web Services, Amazon.com In-Reply-To: References: Message-ID: <20090121210623.GC28861@infula.helvella.org> Awesome, Stephen. You rock. -Colin. On Wed, Jan 21, 2009 at 01:00:51PM -0800, Stephen Blum wrote: > > Seattle Perl User Group: Jinesh Varia, Technology Evangelist, Amazon Web Services, Amazon.com > > VIDEO: > http://www.vimeo.com/2910256 > > In this session, Jinesh Varia, Evangelist at Amazon Web Services, will > share with you some cool ways to develop, test and run perl > applications in the cloud. From tim at consultix-inc.com Thu Jan 22 16:06:16 2009 From: tim at consultix-inc.com (Tim Maher) Date: Thu, 22 Jan 2009 16:06:16 -0800 Subject: SPUG: Jinesh Varia, Technology Evangelist, Amazon Web Services, Amazon.com In-Reply-To: <20090121210623.GC28861@infula.helvella.org> References: <20090121210623.GC28861@infula.helvella.org> Message-ID: <20090123000616.GA3774@jumpy.consultix-inc.com> Whatever happened to the practice of including location and time information in meeting announcements? Don't make me come over there and take charge again! 8-} So when was that meeting? Day before yesterday? Tim *----------------------------------------------------------------------* | Tim Maher, PhD (206) 781-UNIX http://www.consultix-inc.com | | tim at ( TeachMePerl, TeachMeLinux, or TeachMeUnix ) dot Com | *-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | > "Minimal Perl for UNIX People" has been an Amazon Best Seller! < | | * Download chapters, read reviews, and order at: MinimalPerl.com * | *----------------------------------------------------------------------* From zstephenblum at hotmail.com Thu Jan 22 19:07:09 2009 From: zstephenblum at hotmail.com (Stephen Blum) Date: Thu, 22 Jan 2009 19:07:09 -0800 Subject: SPUG: Meeting Announcment In-Reply-To: <20090123000616.GA3774@jumpy.consultix-inc.com> References: <20090121210623.GC28861@infula.helvella.org> <20090123000616.GA3774@jumpy.consultix-inc.com> Message-ID: Hey Tim, Every Third Tuesday at 5:00pm-6:19pm (pre-meet) and 6:30pm (meeting start). Located recently @ Marchex downtown Seattle. The announcement was sent in "spug-list Digest, Vol 67, Issue 7" on Thurs-Fri 1/09/08-09. Please check to see if maybe it was eaten by a junk mail monster. Best, Stephen Blum 425-830-6711 > Date: Thu, 22 Jan 2009 16:06:16 -0800 > From: tim at consultix-inc.com > To: cmeyer at helvella.org > CC: zstephenblum at hotmail.com; spug-list at pm.org > Subject: Re: SPUG: Jinesh Varia, Technology Evangelist, Amazon Web Services, Amazon.com > > Whatever happened to the practice of including location and time > information in meeting announcements? Don't make me come over there > and take charge again! 8-} > > So when was that meeting? Day before yesterday? > > Tim > *----------------------------------------------------------------------* > | Tim Maher, PhD (206) 781-UNIX http://www.consultix-inc.com | > | tim at ( TeachMePerl, TeachMeLinux, or TeachMeUnix ) dot Com | > *-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > | > "Minimal Perl for UNIX People" has been an Amazon Best Seller! < | > | * Download chapters, read reviews, and order at: MinimalPerl.com * | > *----------------------------------------------------------------------* _________________________________________________________________ Windows Live? Hotmail??more than just e-mail. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_howitworks_012009 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gryphon.shafer at gmail.com Fri Jan 23 11:31:36 2009 From: gryphon.shafer at gmail.com (Gryphon Shafer) Date: Fri, 23 Jan 2009 11:31:36 -0800 Subject: SPUG: Jinesh Varia, Technology Evangelist, Amazon Web Services, Amazon.com In-Reply-To: References: Message-ID: <45b837a10901231131n43440f70sdbdc5c91b0149be@mail.gmail.com> Also, here's the slide deck: http://jvaria.s3.amazonaws.com/presentations/AWS_Startup_Deck_jvaria.pdf On Wed, Jan 21, 2009 at 1:00 PM, Stephen Blum wrote: > Seattle Perl User Group: Jinesh Varia, Technology Evangelist, Amazon Web > Services, Amazon.com > > VIDEO: > http://www.vimeo.com/2910256 > > In this session, Jinesh Varia, Evangelist at Amazon Web Services, will share > with you some cool ways to develop, test and run perl applications in the > cloud. > > Amazon Web Services provides Amazon Elastic Compute Cloud aws.amazon.com/ec2 > (Amazon EC2) that allows requisition of machines on-demand using simple web > service call and paying for computation by the hour. Amazon Simple Storage > Service aws.amazon.com/s3 (Amazon S3) which is infinite digital storage in > the cloud. Amazon SimpleDB aws.amazon.com/sdb which is database in the cloud > and Amazon Mechanical Turk aws.amazon.com/mturk which is the on-demand > Workforce and how these services can help companies to scale-out and go live > quickly without any upfront investment. > > Jinesh Varia, Technology Evangelist, Amazon Web Services, Amazon.com > > As a Technology Evangelist at Amazon, Jinesh Varia helps developers take > advantage of disruptive technologies that are going to change the way we > think about computer applications, and the way businesses compete in the new > web world. Jinesh has spoken at more than 50 conferences/UserGroups. He is > focused on furthering awareness of web services and often helps developers > on 1:1 basis in implementing their own ideas using Amazon's innovative > services. > > Jinesh has over 9 years experience in XML and Web services and has worked > with standards-based working groups in XBRL. Prior to joining Amazon as an > evangelist, he held several positions in UBmatrix including Solutions > Architect, Enterprise Team Lead and Software engineer, working on various > financial services projects including Call Modernization Project at FDIC. He > was also lead developer at Penn State Data Center, Institute of Regional > Affairs. Jinesh's publications have been published in ACM and IEEE. Jinesh > is originally from India and holds a Master's degree in Information Systems > from Penn State University. He plays tennis and loves to trek. > > ________________________________ > Windows Live? Hotmail(R):?more than just e-mail. Check it out. > _____________________________________________________________ > Seattle Perl Users Group Mailing List > POST TO: spug-list at pm.org > SUBSCRIPTION: http://mail.pm.org/mailman/listinfo/spug-list > MEETINGS: 3rd Tuesdays > WEB PAGE: http://seattleperl.org/ > From sainagendrabhavaniprasad at gmail.com Sun Jan 25 00:29:57 2009 From: sainagendrabhavaniprasad at gmail.com (battipatisainagendra Bhavaniprasad) Date: Sun, 25 Jan 2009 13:59:57 +0530 Subject: SPUG: regarding Perl doubt Message-ID: Hi, I am new to this community.I have question regarding Pattern Matching in Perl. 1.when /ab?/ is given it returns true for "abbbb" but my question is "?" will support zero or one occurrence. 2.When i am giving /[0-9a-zA-Z] it returns true for "0AA" and "9aa" but my question is IT HAS TO ACCEPT ONLLY "0aa"/"9fG"....so on. 3.What is the difference between Pattern Matching and regular expression?Are both same? Please reply ASAP. Rgds, Chinna -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at goracke.org Sun Jan 25 09:58:52 2009 From: paul at goracke.org (Paul Goracke) Date: Sun, 25 Jan 2009 09:58:52 -0800 Subject: SPUG: regarding Perl doubt In-Reply-To: References: Message-ID: On Jan 25, 2009, at 12:29 AM, battipatisainagendra Bhavaniprasad wrote: > Hi, > I am new to this community.I have question regarding Pattern > Matching in Perl. Welcome! > 1.when /ab?/ is given it returns true for "abbbb" but my question is > "?" will support zero or one occurrence. It does, and it did. Match regexes only tell you whether the pattern exists in the string. To find out what the expression actually matched, use capture parentheses: "/(ab?)/" will show that you matched "ab" (in $1 after the match). If you want to _not_ match your example string, you'd need something like /ab?[^b]/ But that will match "abcdefg" as well. If that _still_ isn't what you want, you may need to look at the "\b" word boundaries, or ^ and $ if you're only trying to match an entire string. Welcome to the joys of pattern matching, where it's at least as important what you _don't_ match as what you do. > 2.When i am giving /[0-9a-zA-Z] it returns true for "0AA" and "9aa" > but my question is IT HAS TO ACCEPT ONLLY "0aa"/"9fG"....so on. Break it down to one position at a time: /[0-9][a-z][A-Z]/ And think about what you don't want to match, a la question one. > 3.What is the difference between Pattern Matching and regular > expression?Are both same? Ah, semantics fun time. Pattern matching is the action of matching a desired pattern; regular expressions are just a way of expressing the desired pattern(s) to match. Pattern matching could be applied to colors or shapes, but you would probably need to find a different way of expressing the desired match than regex. pg From jwkrahn at shaw.ca Sun Jan 25 11:41:45 2009 From: jwkrahn at shaw.ca (John W. Krahn) Date: Sun, 25 Jan 2009 11:41:45 -0800 Subject: SPUG: regarding Perl doubt In-Reply-To: References: Message-ID: <497CC079.5020207@shaw.ca> battipatisainagendra Bhavaniprasad wrote: > Hi, Hello, > I am new to this community.I have question regarding Pattern Matching > in Perl. In English, when you ask a question, you end the sentence with a question mark. For example: How do you ask a question? > 1.when /ab?/ is given it returns true for "abbbb" but my question is "?" > will support zero or one occurrence. Quantifiers like ? affect the previous character or grouping, so that pattern matches a 'a' followed by zero or one 'b' characters. Quanifiers are normally greedy so *if possible* the pattern will prefer to match 'ab' instead of 'a'. However, the string is scanned from left to right so the *first* possible match is found instead of the *best* possible match. $ perl -le'"XXXaaccaabb" =~ /ab?/ and print $&' a $ perl -le'"XXXaabbaacc" =~ /ab?/ and print $&' a $ perl -le'"XXXabbaacc" =~ /ab?/ and print $&' ab > 2.When i am giving /[0-9a-zA-Z] it returns true for "0AA" and "9aa" but my > question is IT HAS TO ACCEPT ONLLY "0aa"/"9fG"....so on. The character class [0-9a-zA-Z] matches *one* character. The string "0AA" will match because "0" matches, the rest of the string is irrelevant. > 3.What is the difference between Pattern Matching and regular expression?Are > both same? Patern Matching is a general term that applies to any kind of pattern matching while a regular expression is a specific implementation. John -- Those people who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov From cmeyer at helvella.org Mon Jan 26 15:43:10 2009 From: cmeyer at helvella.org (Colin Meyer) Date: Mon, 26 Jan 2009 15:43:10 -0800 Subject: SPUG: regarding Perl doubt In-Reply-To: <497CC079.5020207@shaw.ca> References: <497CC079.5020207@shaw.ca> Message-ID: <20090126234309.GB29040@infula.helvella.org> John, On Sun, Jan 25, 2009 at 11:41:45AM -0800, John W. Krahn wrote: > battipatisainagendra Bhavaniprasad wrote: > >Hi, > > Hello, > > >I am new to this community.I have question regarding Pattern Matching > >in Perl. > > In English, when you ask a question, you end the sentence with a > question mark. For example: > > How do you ask a question? In English, when you are making a statement, you end the sentence with a period. For example: I have no question that your reply was not only rude, but, worse than useless, it was harmful. [...] > -- > Those people who think they know everything are a great > annoyance to those of us who do. -- Isaac Asimov Holy dang. You should take your own sig into consideration. Not that I claim to know everything; just enough to be dangerous to myself. :) -Colin. From MichaelRWolf at att.net Mon Jan 26 19:39:15 2009 From: MichaelRWolf at att.net (Michael R. Wolf) Date: Mon, 26 Jan 2009 19:39:15 -0800 Subject: SPUG: regarding Perl doubt In-Reply-To: <497CC079.5020207@shaw.ca> References: <497CC079.5020207@shaw.ca> Message-ID: <72992893-F9EF-499E-9899-5C639E03B09A@att.net> On Jan 25, 2009, at 11:41 AM, John W. Krahn wrote: > battipatisainagendra Bhavaniprasad wrote: >> Hi, > > Hello, > >> I am new to this community.I have question regarding Pattern Matching >> in Perl. > > In English, when you ask a question, you end the sentence with a > question mark. For example: > > How do you ask a question? > To (my interpretation of) the tone of the answer... Did you parse that sentence as a question? I parsed it as a declarative statement, appropriately terminated with a period. Larry said "It should be OK to speak baby Perl". It was meant to apply to a apply to the community in addition to the language. All languages are learned by immersing a less-than fluent speaker in a fluent-speaker conversation. It's how we all learn all languages, spoken and executable. To the original question... In my lightening talk last month, I spoke of Test-Driven Training. Using Test::More may be a bit more scaffolding than you want, but I have found it to be helpful to my students (and also myself) to set up a little experiment to exercise the kinds of edge cases and boundary conditions you're trying to understand and declare. What's more, I've found that it's easier to point at a list of test cases and counter- cases than it is to describe it in a "natural language", since spoken languages aren't really as good at the formal mathematical language that's implied by the regex. #! /usr/bin/perl use Test::More qw(no_plan); my $re = qr/ab?/; like('a', $re, 'match a'); like('ab', $re, 'match ab'); like('abb', $re, 'match ab, but leave the following b alone'); like('abbb', $re, 'match ab, but leave the following bb alone'); like('xxxa', $re, 'match a floated after some initial non-a'); like('xxxab', $re, 'match ab floated after some initial non-ab'); like('axxx', $re, 'match a floated before some initial non-a'); like('abxxx', $re, 'match ab floated before some initial non-ab'); If this kind of test script doesn't help you, there are lots of online animations that run a regex against a test input. You type a regex in one window and some test cases in another window. Be careful, however. Many of them are a bit "fragile" (say buggy), and some of them implement non-Perl regex's. They're similar to, but not identical to, Perl with respect to the features and syntax of regex's. Nevertheless, they're instructive if you understand what they do (and do not) do. I found this one (http://osteele.com/tools/reanimator/) a few years ago. Just now, I found another one (http://regex.powertoy.org/) that helps in a different way. Play. Learn. If this doesn't help, come back with a list of strings that you'd like to match and ones that you'd like to *not* match. That list is a great way to start a test-driven discussion, of a test-driven script, that will lead to a well-tested regex in your code. Enjoy, Michael -- Michael R. Wolf All mammals learn by playing! MichaelRWolf at att.net From MichaelRWolf at att.net Mon Jan 26 19:40:32 2009 From: MichaelRWolf at att.net (Michael R. Wolf) Date: Mon, 26 Jan 2009 19:40:32 -0800 Subject: SPUG: Regex animations Message-ID: Apropos my previous posting regarding regex animations, does anyone have a favorite tool to help debug regex's? Here's the 3 in my Delicious, tagged by regex 1. http://osteele.com/tools/reanimator/ 2. http://regex.powertoy.org/ 3. http://www.myregextester.com/index.php#sourcetab Specifically, has anyone used the ActiveState IDE that's got pieces of MJD's code? Is there such a tool in Eclipse? (Full disclosure: Emacs is my IDE. I shall not want. It maketh me.... It maketh my code. I shall not covet thy neighbors IDE. But I'm curious...) One of the reasons I'm interested is that I got a paper accepted at OSCON a few years ago. It was a work in progress called REplay, an environment to play with (i.e. learn) RE's. As I was putting the paper together, I realized that much of it was not new. It was just new to me. That's where I found that MJD's work had gotten subsumed (and contracted) by ActiveState in their "RE debugger". I knew better than to try to "break new trail" behind MJD, so I stopped work, withdrew the paper, and went on to other tasks. It's been years since then. I'm sure there are other animations, debuggers, and the like, in various states of polish or disrepair. Which ones do you use when you're trying to wrap a new regex around some test data? P.S. For those keeping track, the first sentence in this posting is a question, no? P.P.S. For those keeping track, the previous sentence in this posting is a question, yes? P.P.P.S. :-) -- Michael R. Wolf All mammals learn by playing! MichaelRWolf at att.net From rick.croote at philips.com Mon Jan 26 21:06:12 2009 From: rick.croote at philips.com (Croote, Rick) Date: Tue, 27 Jan 2009 06:06:12 +0100 Subject: SPUG: Regex animations In-Reply-To: References: Message-ID: <6A00D845EC61DF46810F2D5BCB5F6E044C52BBD501@NLCLUEXM06.connect1.local> > > Specifically, has anyone used the ActiveState IDE that's got pieces of > MJD's code? I have used the ActiveState IDE Regex Tool. It was very helpful when I had a large expression that was not working correctly. I don't use it regularly, but if I have a problem I like that I have it. Thanks, Rick Croote Software Development Engineer Philips Healthcare - Ultrasound R&D Work: 425.487.7834 Mobile: 425.346.6246 E-mail: rick.croote at philips.com The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. From jarich at perltraining.com.au Tue Jan 27 03:39:33 2009 From: jarich at perltraining.com.au (Jacinta Richardson) Date: Tue, 27 Jan 2009 22:39:33 +1100 Subject: SPUG: Regex animations In-Reply-To: References: Message-ID: <497EF275.7040100@perltraining.com.au> Michael R. Wolf wrote: > Apropos my previous posting regarding regex animations, does anyone have > a favorite tool to help debug regex's? I quite like the Regex Coach: http://www.weitz.de/regex-coach/ The Linux one isn't too good (it's almost the same, but slower). We use the Windows one in our courses. It allows you to build regular expressions and see how they match your sample data, as well as walk through as it attempts to match your data so you can see where your expression might be going wrong. all the best, J -- ("`-''-/").___..--''"`-._ | Jacinta Richardson | `6_ 6 ) `-. ( ).`-.__.`) | Perl Training Australia | (_Y_.)' ._ ) `._ `. ``-..-' | +61 3 9354 6001 | _..`--'_..-_/ /--'_.' ,' | contact at perltraining.com.au | (il),-'' (li),' ((!.-' | www.perltraining.com.au | From twists at gmail.com Fri Jan 30 14:01:37 2009 From: twists at gmail.com (Joshua ben Jore) Date: Fri, 30 Jan 2009 14:01:37 -0800 Subject: SPUG: version numbers and MakeMaker In-Reply-To: References: Message-ID: On Thu, Jan 15, 2009 at 5:44 PM, Christopher Howard wrote: > I'm creating my first Makefile.PL, and had a question: There is one > key/value pair for the version number. I have seen it like this in examples: > > ... > VERSION => 1.4, > ... > > But if the version number of my app is, say 0.1.2, what should the line look > like? > > VERSION => '0.1.2', > > or > > VERSION => 0.001.002 FWIW, you never want to use multi-dot version numbers in perl. It's possible and version.pm goes to some effort to heal the past but there's no point in re-inventing badness. Perl handles three-argument version numbers by just saying that each part is actually three digits. Perl 5.10.0's $] variable holds 5.010000. Right now, it's the best practice for implementing a version number in perl. Josh From ryanc at greengrey.org Fri Jan 30 14:58:49 2009 From: ryanc at greengrey.org (Ryan Corder) Date: Fri, 30 Jan 2009 14:58:49 -0800 Subject: SPUG: version numbers and MakeMaker In-Reply-To: References: Message-ID: <20090130225849.GA8173@greengrey.org> On Fri, Jan 30, 2009 at 02:01:37PM -0800, Joshua ben Jore wrote: | > VERSION => '0.1.2', [snip] | FWIW, you never want to use multi-dot version numbers in perl. It's | possible and version.pm goes to some effort to heal the past but | there's no point in re-inventing badness. use version; our $VERSION = qv("0.1.2"); On one line, just like that -- this is an "Extended Version" as documented in 'perldoc version'. The documentation does state neither Module::Build nor ExtUtils::MakeMaker completely handles version objects natively, then again I use Module::Install as my build-system. Damian Conway goes into detail on why you need to do it this way and why it needs to be on one line in chapter 17 of /Perl Best Practices/. I just read the chapter last night, otherwise I wouldn't be replying to this thread :) later. ryanc -- Ryan Corder || () ASCII ribbon campaign || /\ against HTML email http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1CB59D69 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From tyemq at cpan.org Fri Jan 30 21:07:02 2009 From: tyemq at cpan.org (Tye McQueen) Date: Fri, 30 Jan 2009 21:07:02 -0800 Subject: SPUG: version numbers and MakeMaker In-Reply-To: <20090130225849.GA8173@greengrey.org> References: <20090130225849.GA8173@greengrey.org> Message-ID: On Fri, Jan 30, 2009 at 2:58 PM, Ryan Corder wrote: > On Fri, Jan 30, 2009 at 02:01:37PM -0800, Joshua ben Jore wrote: > > | FWIW, you never want to use multi-dot version numbers in perl. It's > | possible and version.pm goes to some effort to heal the past but > | there's no point in re-inventing badness. > > use version; our $VERSION = qv("0.1.2"); > ... > Damian Conway goes into detail on why you need to do it this way and why it > needs to be on one line in chapter 17 of /Perl Best Practices/. I just > read > the chapter last night, otherwise I wouldn't be replying to this thread :) I takes a special level of hubris to write a brand new module and simultaneously loudly declare it to be a 'best practice'. But Damian has that level of hubris. And several of these modules that he produced along with that book have already become official deprecated. There are problems with version.pm and Josh is right to discourage one from using it to make multi-dot version numbers. He even already mentioned version.pm and noted that it /tries/ to fix the problems. One shouldn't be surprised that Perl Best Practices doesn't mention the problems with version.pm, since version.pm didn't exist before the book was written (which is exactly why one shouldn't declare a "best practice" until enough time and usage has passed for the problems with it to become apparent). For example, check the reviews of version.pm ( http://cpanratings.perl.org/dist/version). A review that gave the module 5 stars still noted: "Unfortunately, because of the pest that are X.Y.Z versions, version.pm by definition can't make comparisons work well in all cases" And it isn't hard to find reports of problems with version.pm. It is easy to try to deal with versions in a way that doesn't work perfectly with version.pm. Lots of key tools had to be changed in order to properly deal with the versions produced by version.pm. Which means there is still the risk of running into tools that have such problems. Please, just say "no" to multi-dot version numbers. Tye -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.dyck at fluke.com Sat Jan 31 10:29:19 2009 From: david.dyck at fluke.com (David Dyck) Date: Sat, 31 Jan 2009 10:29:19 -0800 (PST) Subject: SPUG: version numbers and MakeMaker In-Reply-To: References: <20090130225849.GA8173@greengrey.org> Message-ID: Tye, On Fri, 30 Jan 2009 at 21:07 -0800, tyemq at ... wrote: > On Fri, Jan 30, 2009 at 2:58 PM, Ryan Corder wrote: >> Damian Conway goes into detail on why you need to do it this way and why it >> needs to be on one line in chapter 17 of /Perl Best Practices/. I just read >> the chapter last night, otherwise I wouldn't be replying to this thread :) > > It takes a special level of hubris to write a brand new module and > simultaneously loudly declare it to be a 'best practice'. But Damian > has that level of hubris. And several of these modules that he produced > along with that book have already become official deprecated. My understanding of hubris came from the perl manual So I've often assumed that the actual definition was the second entry in the Perl Glossary definition of hubris perldoc perlglossary hubris Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also "laziness" and "impatience". You've helped me broaden my understanding, thanks. > One shouldn't be surprised that Perl Best Practices doesn't mention > the problems with version.pm, since version.pm didn't exist before the > book was written (which is exactly why one shouldn't declare a "best > practice" until enough time and usage has passed for the problems with > it to become apparent). According to http://oreilly.com/catalog/9780596001735/ the book came out in 2005, but version.pm Changes file has history back to Fri, 13 Sep 2002. >From the earlier statement, and this one, I initially thought that you were saying that Damian was the author of version.pm, but credit should be given to John Peacock, right?. (oh doesn't take credit vor version.pm either) .... The perl core still contains v-strings, which are handy for many things, but if you dig you can find that it warns that v-string in use/require is non-portable, and in perldoc perldata there is the warning Note: Version Strings (v-strings) have been deprecated. They will be removed in some future release after Perl 5.8.1. The marginal benefits of v-strings were greatly outweighed by the potential for Surprise and Confusion. David From tyemq at cpan.org Sat Jan 31 11:07:32 2009 From: tyemq at cpan.org (Tye McQueen) Date: Sat, 31 Jan 2009 11:07:32 -0800 Subject: SPUG: version numbers and MakeMaker In-Reply-To: References: <20090130225849.GA8173@greengrey.org> Message-ID: On Sat, Jan 31, 2009 at 10:29 AM, David Dyck wrote: > According to http://oreilly.com/catalog/9780596001735/ > the book came out in 2005, but version.pm Changes file > has history back to Fri, 13 Sep 2002. > The first I heard of version.pm was in relation to Perl Best Practices. I recall hearing that it was Damian's module. But I don't see any evidence of that. Sorry. But the points about not using it for multi-dot version numbers stand. Thanks, Tye -------------- next part -------------- An HTML attachment was scrubbed... URL: