From andrew at sweger.net Fri Jan 8 08:07:01 2010 From: andrew at sweger.net (Andrew Sweger) Date: Fri, 8 Jan 2010 08:07:01 -0800 (PST) Subject: SPUG: January meeting Message-ID: Yes? Very likely, yes. Details are being gathered for a talk on PostgreSQL performance tweaks. January 19th at 6:30 pm at Marchex. Stay tuned. -- Andrew B. Sweger -- The great thing about multitasking is that several things can go wrong at once. From choward at indicium.us Mon Jan 11 17:27:10 2010 From: choward at indicium.us (Christopher Howard) Date: Mon, 11 Jan 2010 16:27:10 -0900 Subject: SPUG: Pull out of a blocking subroutine? Message-ID: <4B4BCFEE.2050002@indicium.us> Hi. I'm still working on integrating LEGO::NXT into my project. Problem I've hit though is that apparently there are no actual functions for checking communication status with the robot. There is other function I thought I could use to detect (implicitly) if communication is still established. Problem is that they are /all/ blocking. Documentation basically says that the author hasn't got around to making non-blocking functions yet, and I don't really have time to reprogram his module myself. So, my perverted, evil question: Is there some hackish way to pull out of a blocking subroutine? Say, if it has returned after three seconds or something like that? -- Christopher Howard http://indicium.us http://theologia.indicium.us http://robots.arsc.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From skylos at gmail.com Mon Jan 11 17:31:41 2010 From: skylos at gmail.com (Skylos) Date: Mon, 11 Jan 2010 17:31:41 -0800 Subject: SPUG: Pull out of a blocking subroutine? In-Reply-To: <4B4BCFEE.2050002@indicium.us> References: <4B4BCFEE.2050002@indicium.us> Message-ID: <3650cdc01001111731k58cef650p5f4123235159d96e@mail.gmail.com> Sure. http://www.sdsc.edu/~moreland/courses/IntroPerl/docs/manual/pod/perlfunc/alarm.html eval { local $SIG{ALRM} = sub { die "alarm\n" }; # NB: \n required alarm $timeout; $nread = sysread SOCKET, $buffer, $size; alarm 0; }; if ($@) { die unless $@ eq "alarm\n"; # propagate unexpected errors # timed out } else { # didn't } Skylos "If only I could get rid of hunger by rubbing my belly" - Diogenes On Mon, Jan 11, 2010 at 5:27 PM, Christopher Howard wrote: > Hi. I'm still working on integrating LEGO::NXT into my project. Problem > I've hit though is that apparently there are no actual functions for > checking communication status with the robot. > > There is other function I thought I could use to detect (implicitly) if > communication is still established. Problem is that they are /all/ > blocking. Documentation basically says that the author hasn't got around > to making non-blocking functions yet, and I don't really have time to > reprogram his module myself. > > So, my perverted, evil question: Is there some hackish way to pull out > of a blocking subroutine? Say, if it has returned after three seconds or > something like that? > > -- > Christopher Howard > http://indicium.us > http://theologia.indicium.us > http://robots.arsc.edu > > > _____________________________________________________________ > 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From choward at indicium.us Mon Jan 11 18:19:24 2010 From: choward at indicium.us (Christopher Howard) Date: Mon, 11 Jan 2010 17:19:24 -0900 Subject: SPUG: Pull out of a blocking subroutine? In-Reply-To: <3650cdc01001111731k58cef650p5f4123235159d96e@mail.gmail.com> References: <4B4BCFEE.2050002@indicium.us> <3650cdc01001111731k58cef650p5f4123235159d96e@mail.gmail.com> Message-ID: <4B4BDC2C.8010908@indicium.us> Skylos wrote: > Sure. > > http://www.sdsc.edu/~moreland/courses/IntroPerl/docs/manual/pod/perlfunc/alarm.html > > eval { > local $SIG{ALRM} = sub { die "alarm\n" }; # NB: \n required > alarm $timeout; > $nread = sysread SOCKET, $buffer, $size; > alarm 0; > }; > if ($@) { > die unless $@ eq "alarm\n"; # propagate unexpected errors > # timed out > } > else { > # didn't > } > > Skylos > > "If only I could get rid of hunger by rubbing my belly" - Diogenes > > > On Mon, Jan 11, 2010 at 5:27 PM, Christopher Howard > wrote: > > Hi. I'm still working on integrating LEGO::NXT into my project. Problem > I've hit though is that apparently there are no actual functions for > checking communication status with the robot. > > There is other function I thought I could use to detect (implicitly) if > communication is still established. Problem is that they are /all/ > blocking. Documentation basically says that the author hasn't got around > to making non-blocking functions yet, and I don't really have time to > reprogram his module myself. > > So, my perverted, evil question: Is there some hackish way to pull out > of a blocking subroutine? Say, if it has returned after three seconds or > something like that? > > -- > Christopher Howard > http://indicium.us > http://theologia.indicium.us > http://robots.arsc.edu > > > _____________________________________________________________ > 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/ > > This sounds like exactly what I need, but it doesn't seem to be working. It still freezes at the call to Does it make any difference that I am not making a simple system call, but instead a call to a function in a module? while(1) { eval { local $SIG{ALRM} = sub { die "alarm\n" }; # NB: \n required alarm 5; # $Scoop_a is my robot object $ret = $Scoop_a->nxt->get_battery_level($LEGO::NXT::Constants::NXT_RET); alarm 0; }; if ($@) { die unless $@ eq "alarm\n"; # propagate unexpected errors # timed out } else { # didn't } print "We made it through!"; sleep 2; } -- Christopher Howard http://indicium.us http://theologia.indicium.us http://robots.arsc.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From derykus at gmail.com Mon Jan 11 19:18:16 2010 From: derykus at gmail.com (Charles DeRykus) Date: Mon, 11 Jan 2010 19:18:16 -0800 Subject: SPUG: Pull out of a blocking subroutine? In-Reply-To: <4B4BDC2C.8010908@indicium.us> References: <4B4BCFEE.2050002@indicium.us> <3650cdc01001111731k58cef650p5f4123235159d96e@mail.gmail.com> <4B4BDC2C.8010908@indicium.us> Message-ID: <175825721001111918m705f35fbi5ae2aad5fbad6e0@mail.gmail.com> > > This sounds like exactly what I need, but it doesn't seem to > be working. > > It still freezes at the call to Does it make any difference that I am > > not making a simple system call, but instead a call to a function in a > > module? > perlipc's POSIX workaround can help if the function has a networking call with its own timeout which interferes with the timeout you've set. Here's a couple of changes to demo the fix although perlipc warns this will bypass safe signals: use POSIX qw(SIGALRM); # <--- > while(1) > > { > > eval { > > > > # local $SIG{ALRM} = sub { die "alarm\n" }; # NB: \n required > POSIX::sigaction(SIGALRM, # <--- POSIX::SigAction->new(sub { die "alarm"; } ) ) or die "Error setting SIGALRM handler: $!\n"; > alarm 5; > # $Scoop_a is my robot object > $ret = > $Scoop_a->nxt->get_battery_level( > $LEGO::NXT::Constants:: NXT_RET); > alarm 0; >}; > ... Of course,nothing helps if the function does this: local $SIG{ALRM} = 'IGNORE'; -- Charles DeRykus -------------- next part -------------- An HTML attachment was scrubbed... URL: From skylos at gmail.com Mon Jan 11 19:24:18 2010 From: skylos at gmail.com (Skylos) Date: Mon, 11 Jan 2010 19:24:18 -0800 Subject: SPUG: Pull out of a blocking subroutine? In-Reply-To: <4B4BDC2C.8010908@indicium.us> References: <4B4BCFEE.2050002@indicium.us> <3650cdc01001111731k58cef650p5f4123235159d96e@mail.gmail.com> <4B4BDC2C.8010908@indicium.us> Message-ID: <3650cdc01001111924w249f57b2r9430d770e439b207@mail.gmail.com> On Mon, Jan 11, 2010 at 6:19 PM, Christopher Howard wrote: > > > This sounds like exactly what I need, but it doesn't seem to be working. > It still freezes at the call to Does it make any difference that I am > not making a simple system call, but instead a call to a function in a > module? > BlueComm.pm line 91 looks famliar. 91 eval 92 { 93 local $SIG{ALRM} = sub { die "alarm\n" }; 94 alarm 1; 95 $nread = sysread $fh, $char, 1; 96 alarm 0; 97 }; 98 $rbuff .= $char; 99 } Listen to Mr. DeRykus. :) Skylos > while(1) > { > eval { > > local $SIG{ALRM} = sub { die "alarm\n" }; # NB: \n required > > > alarm 5; > # $Scoop_a is my robot object > > $ret = > $Scoop_a->nxt->get_battery_level($LEGO::NXT::Constants::NXT_RET); > alarm 0; > }; > if ($@) { > die unless $@ eq "alarm\n"; # propagate unexpected errors > > > # timed out > > > } > else { > # didn't > > > } > print "We made it through!"; > sleep 2; > } > > -- > Christopher Howard > http://indicium.us > http://theologia.indicium.us > http://robots.arsc.edu > > > _____________________________________________________________ > 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at sweger.net Tue Jan 12 12:03:48 2010 From: andrew at sweger.net (Andrew Sweger) Date: Tue, 12 Jan 2010 12:03:48 -0800 (PST) Subject: SPUG: January meeting In-Reply-To: Message-ID: A meeting next Tuesday is a certainty at this point. The real announcement should be ready this afternoon. Just fact-checking a couple small details. On Fri, 8 Jan 2010, Andrew Sweger wrote: > Yes? Very likely, yes. Details are being gathered for a talk on PostgreSQL > performance tweaks. January 19th at 6:30 pm at Marchex. Stay tuned. > > -- Andrew B. Sweger -- The great thing about multitasking is that several things can go wrong at once. From choward at indicium.us Tue Jan 12 12:50:12 2010 From: choward at indicium.us (Christopher Howard) Date: Tue, 12 Jan 2010 11:50:12 -0900 Subject: SPUG: Pull out of a blocking subroutine? In-Reply-To: <3650cdc01001111924w249f57b2r9430d770e439b207@mail.gmail.com> References: <4B4BCFEE.2050002@indicium.us> <3650cdc01001111731k58cef650p5f4123235159d96e@mail.gmail.com> <4B4BDC2C.8010908@indicium.us> <3650cdc01001111924w249f57b2r9430d770e439b207@mail.gmail.com> Message-ID: <4B4CE084.7090404@indicium.us> Skylos wrote: > On Mon, Jan 11, 2010 at 6:19 PM, Christopher Howard > wrote: > > > > This sounds like exactly what I need, but it doesn't seem to be working. > It still freezes at the call to Does it make any difference that I am > not making a simple system call, but instead a call to a function in a > module? > > > BlueComm.pm line 91 looks famliar. > > 91 eval > 92 { > 93 local $SIG{ALRM} = sub { die "alarm\n" }; > 94 alarm 1; > 95 $nread = sysread $fh, $char, 1; > 96 alarm 0; > 97 }; > 98 $rbuff .= $char; > 99 } > > > Listen to Mr. DeRykus. :) > > Skylos > > I've tried DeRykus' suggestion and it didn't seem to have any effect. I'm thinking, now that you pointed out this BlueComm.pm code, perhaps I can just modify this _do_cmd() function in BlueComm.pm to break after a certain number of tries. -- Christopher Howard http://indicium.us http://theologia.indicium.us http://robots.arsc.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From skylos at gmail.com Tue Jan 12 13:26:39 2010 From: skylos at gmail.com (Skylos) Date: Tue, 12 Jan 2010 13:26:39 -0800 Subject: SPUG: Pull out of a blocking subroutine? In-Reply-To: <4B4CE084.7090404@indicium.us> References: <4B4BCFEE.2050002@indicium.us> <3650cdc01001111731k58cef650p5f4123235159d96e@mail.gmail.com> <4B4BDC2C.8010908@indicium.us> <3650cdc01001111924w249f57b2r9430d770e439b207@mail.gmail.com> <4B4CE084.7090404@indicium.us> Message-ID: <3650cdc01001121326j2176e294ia43ef77e483eaea8@mail.gmail.com> On Tue, Jan 12, 2010 at 12:50 PM, Christopher Howard wrote: > Skylos wrote: > > On Mon, Jan 11, 2010 at 6:19 PM, Christopher Howard > > wrote: > > > > > > > > This sounds like exactly what I need, but it doesn't seem to be > working. > > It still freezes at the call to Does it make any difference that I > am > > not making a simple system call, but instead a call to a function in > a > > module? > > > > > > BlueComm.pm line 91 looks famliar. > > > > 91 eval > > 92 { > > 93 local $SIG{ALRM} = sub { die "alarm\n" }; > > 94 alarm 1; > > 95 $nread = sysread $fh, $char, 1; > > 96 alarm 0; > > 97 }; > > 98 $rbuff .= $char; > > 99 } > > > > > > Listen to Mr. DeRykus. :) > > > > Skylos > > > > > > I've tried DeRykus' suggestion and it didn't seem to have any effect. > > I'm thinking, now that you pointed out this BlueComm.pm code, perhaps I > can just modify this _do_cmd() function in BlueComm.pm to break after a > certain number of tries. > I think its worth an experiment, but I'm sure this loops this way for some kind of reason... like its using a non-blocking call for a blocking situation. Skylos "If only I could get rid of hunger by rubbing my belly" - Diogenes -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at sweger.net Tue Jan 12 14:17:19 2010 From: andrew at sweger.net (Andrew Sweger) Date: Tue, 12 Jan 2010 14:17:19 -0800 (PST) Subject: SPUG: January 2010 Seattle Perl Users Group (SPUG) Meeting Message-ID: January 2010 Seattle Perl Users Group (SPUG) Meeting ==================================================== Topic: Dumb Simple PostgreSQL Performance Speaker: Joshua D. Drake Meeting Date: Tuesday, 19 January 2010 Meeting Time: 6:30 - 8:30 p.m. Location: Marchex - 520 Pike Street Cost: Admission is free and open to the public Info: http://seattleperl.org/ ==================================================== Tuesday, January 19, is the next meeting of the THE SEATTLE PERL USERS GROUP. This Month's Talk ----------------- NEW MEETING LOCATION Please note that our meeting location has changed. See below for details. A one hour presentation on the essentials on the optimization of PostgreSQL. The talk focuses on hardware, operating system and configuration for the database. Although performance optimization is a life long maintenance for any application, this presentation will allow you to hit the ground running. Specific topics covered are memory configuration, RAID, partitioning, and application specific changes that can be made to help efficiency. About Joshua D. Drake --------------------- Joshua D. Drake is the lead consultant for Command Prompt, Inc. the oldest PostgreSQL professional services provider in North America. He is also a PostgreSQL.Org Major Contributor, United States PostgreSQL President and a Director for Software in the Public Interest. Pre-Meeting =========== If you are so inclined, please come to the pre-meeting at the nearby Elephant & Castle pub on 5th & Union (see map below). We'll be there from 5:00 pm to 6:19 pm. Meeting Location ================ Marchex 520 Pike Street, Suite 1800 Seattle, WA 98101 The building is just East of Westlake Center. Enter from Pike Street. http://xrl.us/spugmap 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. Attendees will need to wait near the elevators in the lobby and a Marchex employee will provide access to the 18th floor where the meeting room is located. If no one shows up to let you in, call (425) 533-2964 to let them know you're in the lobby. See you there! -- Andrew B. Sweger -- The great thing about multitasking is that several things can go wrong at once. From jobs-noreply at seattleperl.org Thu Jan 14 08:16:47 2010 From: jobs-noreply at seattleperl.org (SPUG Jobs) Date: Thu, 14 Jan 2010 08:16:47 -0800 (PST) Subject: SPUG: JOB: Perl Dev contract in Healthcare Message-ID: JOB DESCRIPTION: Seattle area health insurance organization is looking for a senior level Perl Developer to join the team for a two month contract starting in January 2010. They are working on a new enhancement of a print application that handles all the EOBs (explanation of benefits), vouchers, commissions, checks, bulk processing, and statements.. This new project is called "EOB Preference" where people can choose electronic communication instead of paper statements. This new option has required us to update our processes to present statements and information on line instead of printing. We will be using StreamWeaver to stream the docs and Perl scripting is the wrapper for these StreamWeaver jobs. Specific files will be sent through HTML streams rather than creating a hard document. There are no functional specs on this project, although there is technical design and a proof of concept complete. There is also only one person who has expertise in Perl on this team, so there is a need for a contract resource who can bring the Perl expertise not only to this project, but to the documentation and the team to support this new functionality once it goes live. This project will be located in either Seattle or Portland interacting with a team in both locations. SKILLS: Strong Perl and scripting development experience and ability to take limited documentation, define technical specs and be the Perl SME on the team completing the project single-handedly. Required Skill Sets: Strong Perl Development background and excellent knowledge of it's interworkings... needs to be able to answers questions from multiple groups regarding Perl and move the company's project towards completion. This position needs a candidate strong enough in Perl to be a SME (Subject Matter Expert) Position Length: 2 month contract position (possible extension opportunities) Pay: $45-50/hr. W2 Placement: The candidate hired for this position will be an employee of my company (Kforce), not the end client. Location: This position can sit in either Seattle, WA or Portland, OR Telecommuting Possibilities: No Company Product: Healthcare Jim Grimaldi Dedicated Healthcare/IT Recruiter, National Recruiting Center KForce Healthcare Staffing 813.552.3695 Direct 877.258.2085 x3695 Toll Free 866.470.6790 Fax www.kforce.com http://www.linkedin.com/in/jimgrimaldi From michaelrwolf at att.net Thu Jan 14 09:07:02 2010 From: michaelrwolf at att.net (Michael R. Wolf) Date: Thu, 14 Jan 2010 09:07:02 -0800 Subject: SPUG: Too long to find bug: Fat comma and assignment look similar, and have some similar meaning Message-ID: <2CE3C44F-3B5D-41AF-8133-6A98E3F973B8@att.net> This (distillation of a bug) took me way too long to notice, especially since it compiled OK without a warning. use warnings; use strict; my $x => rand; die 'Did you notice fat comma instead of assignment? Variable did not get set' unless defined $x; In retrospect, what had me miss it was: 1 - the visual similarity between '=' and '=>' 2 - the similarity of meaning between "gets" (assignment) and "gets associated with" (fat comma's common use in creating hash key/value pairs) Can you think of a good use of fat comma (or skinny comma, for that matter) in this context? Or, framed differently, why shouldn't (or can't) it get a warning like "Strange mixture of declaration, stringification, and function call in void context"? -- Michael R. Wolf All mammals learn by playing! MichaelRWolf at att.net From derykus at gmail.com Thu Jan 14 11:50:26 2010 From: derykus at gmail.com (Charles DeRykus) Date: Thu, 14 Jan 2010 11:50:26 -0800 Subject: SPUG: Too long to find bug: Fat comma and assignment look similar, and have some similar meaning In-Reply-To: <2CE3C44F-3B5D-41AF-8133-6A98E3F973B8@att.net> References: <2CE3C44F-3B5D-41AF-8133-6A98E3F973B8@att.net> Message-ID: <175825721001141150o3c15450en40ee6bc0ed105ad7@mail.gmail.com> On Thu, Jan 14, 2010 at 9:07 AM, Michael R. Wolf wrote: > use strict; > use warnings; > ... > my $x => rand; > die 'Did you notice fat comma instead of assignment? Variable did not > get set' unless defined $x; > In retrospect, what had me miss it was: > 1 - the visual similarity between '=' and '=>' > 2 - the similarity of meaning between "gets" (assignment) and "gets > associated with" (fat comma's common use in creating hash key/value > pairs) > Can you think of a good use of fat comma (or skinny comma, for that > matter) in this context? Or, framed differently, why shouldn't (or can't) it > get a warning like "Strange mixture of declaration, stringification, and > function call in void context"? I can't think of good use for fat/skinny comma in that context but maybe a more devious mind is needed.. It does seem odd that rand (srand too) don't warn since other arithmetic functions do: perl -wle 'my $x => sin' Useless use of sin in void context ... Use of uninitialized value $_ in sin ... and similiar warnings for cos, exp, int, log .. -- Charles DeRykus -------------- next part -------------- An HTML attachment was scrubbed... URL: From MichaelRWolf at att.net Thu Jan 14 11:59:58 2010 From: MichaelRWolf at att.net (Michael R. Wolf) Date: Thu, 14 Jan 2010 11:59:58 -0800 Subject: SPUG: Too long to find bug: Fat comma and assignment look similar, and have some similar meaning In-Reply-To: <175825721001141150o3c15450en40ee6bc0ed105ad7@mail.gmail.com> References: <2CE3C44F-3B5D-41AF-8133-6A98E3F973B8@att.net> <175825721001141150o3c15450en40ee6bc0ed105ad7@mail.gmail.com> Message-ID: <805FC48F-651F-43C6-BCDC-92C076D233FA@att.net> On Jan 14, 2010, at 11:50 AM, Charles DeRykus wrote: > I can't think of good use for fat/skinny comma in that context but > maybe a more devious mind is needed.. > > It does seem odd that rand (srand too) don't warn since other > arithmetic functions do: > > perl -wle 'my $x => sin' > Useless use of sin in void context ... > Use of uninitialized value $_ in sin ... > > and similiar warnings for cos, exp, int, log .. And similar warnings for other bare words... my $x => my_func; # Warning my $x => my_func(); # No warning -- Michael R. Wolf All mammals learn by playing! MichaelRWolf at att.net From iheffner at gmail.com Fri Jan 15 16:11:58 2010 From: iheffner at gmail.com (Ivan Heffner) Date: Fri, 15 Jan 2010 16:11:58 -0800 Subject: SPUG: Too long to find bug: Fat comma and assignment look similar, and have some similar meaning In-Reply-To: <805FC48F-651F-43C6-BCDC-92C076D233FA@att.net> References: <2CE3C44F-3B5D-41AF-8133-6A98E3F973B8@att.net> <175825721001141150o3c15450en40ee6bc0ed105ad7@mail.gmail.com> <805FC48F-651F-43C6-BCDC-92C076D233FA@att.net> Message-ID: This is a contrived example, but since Perl doesn't actually distinguish between fat and skinny comma (or translates the fat commas into skinny commas and it is purely human brains that give "special meaning" to fat commas) this is syntactically and semantically valid, even though it is idiomatically misleading. use strict; use warnings; my $x; # some more complicated stuff (my $y => $x) = get_stuff(); print "x: $x; y: $y;\n"; sub get_stuff { return rand 2, rand 3; } -- Ivan On Thu, Jan 14, 2010 at 11:59 AM, Michael R. Wolf wrote: > > On Jan 14, 2010, at 11:50 AM, Charles DeRykus wrote: > >> I can't think of good use for fat/skinny comma in that context but >> maybe a more devious mind is needed.. >> >> It does seem odd that rand (srand too) don't warn since other >> arithmetic functions do: >> >> ?perl -wle 'my $x => sin' >> ?Useless use of sin in void context ... >> ?Use of uninitialized value $_ in sin ... >> >> ?and similiar warnings for cos, exp, int, log .. > > > And similar warnings for other bare words... > > my $x => my_func; ? ? ? ? ? ? ? # Warning > my $x => my_func(); ? ? # No warning > > -- > Michael R. Wolf > ? ?All mammals learn by playing! > ? ? ? ?MichaelRWolf at att.net > > > > > _____________________________________________________________ > 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 dbenhur at whitepages.com Fri Jan 15 17:30:19 2010 From: dbenhur at whitepages.com (Devin Ben-Hur) Date: Fri, 15 Jan 2010 17:30:19 -0800 Subject: SPUG: Too long to find bug: Fat comma and assignment look similar, and have some similar meaning In-Reply-To: References: <2CE3C44F-3B5D-41AF-8133-6A98E3F973B8@att.net> <175825721001141150o3c15450en40ee6bc0ed105ad7@mail.gmail.com> <805FC48F-651F-43C6-BCDC-92C076D233FA@att.net> Message-ID: <4B5116AB.2020101@whitepages.com> Ivan Heffner wrote: > This is a contrived example, but since Perl doesn't actually > distinguish between fat and skinny comma (or translates the fat commas > into skinny commas and it is purely human brains that give "special > meaning" to fat commas) This is not strictly true. => has the syntactic effect of turning a bareword to its left into a string. $ perl -e 'use constant FOO => 1; print FOO, 2, "\n", FOO => 2, "\n";' 12 FOO2 -- -Devin From andrew at sweger.net Mon Jan 18 08:56:48 2010 From: andrew at sweger.net (Andrew Sweger) Date: Mon, 18 Jan 2010 08:56:48 -0800 (PST) Subject: SPUG: REMINDER January 2010 Seattle Perl Users Group (SPUG) Meeting Message-ID: January 2010 Seattle Perl Users Group (SPUG) Meeting ==================================================== Topic: Dumb Simple PostgreSQL Performance Speaker: Joshua D. Drake Meeting Date: Tuesday, 19 January 2010 Meeting Time: 6:30 - 8:30 p.m. Location: Marchex - 520 Pike Street Cost: Admission is free and open to the public Info: http://seattleperl.org/ ==================================================== Tuesday, January 19, is the next meeting of the THE SEATTLE PERL USERS GROUP. This Month's Talk ----------------- NEW MEETING LOCATION Please note that our meeting location has changed. See below for details. A one hour presentation on the essentials on the optimization of PostgreSQL. The talk focuses on hardware, operating system and configuration for the database. Although performance optimization is a life long maintenance for any application, this presentation will allow you to hit the ground running. Specific topics covered are memory configuration, RAID, partitioning, and application specific changes that can be made to help efficiency. About Joshua D. Drake --------------------- Joshua D. Drake is the lead consultant for Command Prompt, Inc. the oldest PostgreSQL professional services provider in North America. He is also a PostgreSQL.Org Major Contributor, United States PostgreSQL President and a Director for Software in the Public Interest. Pre-Meeting =========== If you are so inclined, please come to the pre-meeting at the nearby Elephant & Castle pub on 5th & Union (see map below). We'll be there from 5:00 pm to 6:19 pm. Meeting Location ================ Marchex 520 Pike Street, Suite 1800 Seattle, WA 98101 The building is just East of Westlake Center. Enter from Pike Street. http://xrl.us/spugmap 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. Attendees will need to wait near the elevators in the lobby and a Marchex employee will provide access to the 18th floor where the meeting room is located. If no one shows up to let you in, call (425) 533-2964 to let them know you're in the lobby. See you there! -- Andrew B. Sweger -- The great thing about multitasking is that several things can go wrong at once. _____________________________________________________________ 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 m3047 at m3047.net Mon Jan 18 12:04:07 2010 From: m3047 at m3047.net (Fred Morris) Date: Mon, 18 Jan 2010 12:04:07 -0800 Subject: SPUG: idioms of late In-Reply-To: <175825721001141150o3c15450en40ee6bc0ed105ad7@mail.gmail.com> References: <2CE3C44F-3B5D-41AF-8133-6A98E3F973B8@att.net> <175825721001141150o3c15450en40ee6bc0ed105ad7@mail.gmail.com> Message-ID: <201001181204.07129.m3047@m3047.net> Lately I've found myself doing a lot of processing of lists... usually either listrefs, or a list of keys which can be looked up in a hashref. I've found myself using a few idioms in place of for/while loops repeatedly, and I thought I'd share. $foo->{names} = [ map { my $x = $_; $x =~ s/\.$//o; $x; } @{$foo->{names}} ]; That one munges a listref, stripping trailing dots off of all of the elements. The initial "$x = $_;" seems to be necessary. That one seems rather pythonic to me. Generally speaking they prefer that I use perl. printf "%s\n", join( "\t", @{$foo}{@FIELDS} ); ..or.. printf "%s\n", join( "\t", @{$foo}{qw/ fee fie foe /}); That's kind of an interesting one because $foo is actually a hashref. Another variant of that which is useful is as part of, for instance, enforcing a "no quotes in SQL literals" rule: my ($name, $address, $city) = map $dbh->quote($_), @{$self}{qw/ name address city /}; my $sql .= "VALUES ($name, $address, $city)"; Nothing major, maybe food for thought. -- Fred Morris, internet plumber From jjuran at gmail.com Mon Jan 18 15:39:39 2010 From: jjuran at gmail.com (Joshua Juran) Date: Mon, 18 Jan 2010 15:39:39 -0800 Subject: SPUG: idioms of late In-Reply-To: <201001181204.07129.m3047@m3047.net> References: <2CE3C44F-3B5D-41AF-8133-6A98E3F973B8@att.net> <175825721001141150o3c15450en40ee6bc0ed105ad7@mail.gmail.com> <201001181204.07129.m3047@m3047.net> Message-ID: <740AF03C-8A11-42D3-8249-55EACAC29F04@gmail.com> On Jan 18, 2010, at 12:04 PM, Fred Morris wrote: > Lately I've found myself doing a lot of processing of lists... usually > either listrefs, or a list of keys which can be looked up in a > hashref. > I've found myself using a few idioms in place of for/while loops > repeatedly, and I thought I'd share. > > $foo->{names} = [ map { my $x = $_; $x =~ s/\.$//o; $x; } > @{$foo->{names}} > ]; > > That one munges a listref, stripping trailing dots off of all of the > elements. The initial "$x = $_;" seems to be necessary. That one seems > rather pythonic to me. Generally speaking they prefer that I use perl. First of all, let me note that your use of /o does nothing, since the pattern doesn't contain any variables and therefore doesn't need to be recompiled in the first place. You have to use a copy of $_ because $_ is read-only in map. $ time perl -e 'my @x = 0 .. 1000000; @x = map { my $x = $_; $x =~ s/ \.$//o; $x; } @x' real 0m2.357s user 0m2.078s sys 0m0.271s $ time perl -e 'my @x = 0 .. 1000000; @x = map { my $x = $_; $x =~ s/ \.$//; $x; } @x' real 0m2.355s user 0m2.076s sys 0m0.271s The operation you're repeating either shortens the value or does nothing to it. There's no reason for any allocations whatsoever. But your example makes lots of copies, not even only to put them back where they came from, but replacing the original array with a newly constructed one. The anti-functional-style for loop is well over twice as fast and less than a third of the keystrokes (for the loop itself). $ time perl -e 'my @x = 0 .. 1000000; s/\.$// for @x' real 0m0.950s user 0m0.823s sys 0m0.121s I spend a lot of time in C++, and a little in assembler. > printf "%s\n", join( "\t", @{$foo}{@FIELDS} ); > > ..or.. > > printf "%s\n", join( "\t", @{$foo}{qw/ fee fie foe /}); > > That's kind of an interesting one because $foo is actually a hashref. > > Another variant of that which is useful is as part of, for instance, > enforcing a "no quotes in SQL literals" rule: > > my ($name, $address, $city) = > map $dbh->quote($_), @{$self}{qw/ name address city /}; > > my $sql .= "VALUES ($name, $address, $city)"; Please don't do this. Let DBI generate your SQL statement for you. I hope this sort of critique is what you were looking for. Cheers, Josh From jwkrahn at shaw.ca Mon Jan 18 15:46:39 2010 From: jwkrahn at shaw.ca (John W. Krahn) Date: Mon, 18 Jan 2010 15:46:39 -0800 Subject: SPUG: idioms of late In-Reply-To: <740AF03C-8A11-42D3-8249-55EACAC29F04@gmail.com> References: <2CE3C44F-3B5D-41AF-8133-6A98E3F973B8@att.net> <175825721001141150o3c15450en40ee6bc0ed105ad7@mail.gmail.com> <201001181204.07129.m3047@m3047.net> <740AF03C-8A11-42D3-8249-55EACAC29F04@gmail.com> Message-ID: <4B54F2DF.5050202@shaw.ca> Joshua Juran wrote: > On Jan 18, 2010, at 12:04 PM, Fred Morris wrote: > >> Lately I've found myself doing a lot of processing of lists... usually >> either listrefs, or a list of keys which can be looked up in a hashref. >> I've found myself using a few idioms in place of for/while loops >> repeatedly, and I thought I'd share. >> >> $foo->{names} = [ map { my $x = $_; $x =~ s/\.$//o; $x; } >> @{$foo->{names}} >> ]; >> >> That one munges a listref, stripping trailing dots off of all of the >> elements. The initial "$x = $_;" seems to be necessary. That one seems >> rather pythonic to me. Generally speaking they prefer that I use perl. > > First of all, let me note that your use of /o does nothing, since the > pattern doesn't contain any variables and therefore doesn't need to be > recompiled in the first place. You have to use a copy of $_ because $_ > is read-only in map. Incorrect. You can modify $_ but that will just modify the contents of the original array because, as in a foreach loop, $_ is an alias to the current element of the original array. John -- The programmer is fighting against the two most destructive forces in the universe: entropy and human stupidity. -- Damian Conway From skylos at gmail.com Mon Jan 18 16:01:26 2010 From: skylos at gmail.com (Skylos) Date: Mon, 18 Jan 2010 16:01:26 -0800 Subject: SPUG: idioms of late In-Reply-To: <201001181204.07129.m3047@m3047.net> References: <2CE3C44F-3B5D-41AF-8133-6A98E3F973B8@att.net> <175825721001141150o3c15450en40ee6bc0ed105ad7@mail.gmail.com> <201001181204.07129.m3047@m3047.net> Message-ID: <3650cdc01001181601m705f4157xa93a58fcb61c3f8f@mail.gmail.com> On Mon, Jan 18, 2010 at 12:04 PM, Fred Morris wrote: > > Another variant of that which is useful is as part of, for instance, > enforcing a "no quotes in SQL literals" rule: > > my ($name, $address, $city) = > map $dbh->quote($_), @{$self}{qw/ name address city /}; > > my $sql .= "VALUES ($name, $address, $city)"; > > If you have a rule 'no quote sin sql literals' rule, you're violating the spirit by simply interpolating them in, don't you think? Just because they're not in the literal doesn't mean they're not in the string that goes to the server. It sounds like a poorly stated concept formed into a rule. Regardless of that, among the reasons not to do this is the fact that the database will try to remember your queries for optimization (queries repeat frequently) when you do the dbh->quote method, the sql is different every single time. If you use binding instead, something like $dbh->do('... VALUES (?, ?, ?)', undef, $name, $address, $city); to the database this query looks the same regardless of what name, address, and city may be. If its new sql, then the db has to recompile it and recreate an execution plan - incurring significant overhead that could have been avoided entirely had you bound the variables. I recently worked a project where a set of non-binding queries in rapid succession would kill the mysql database reliably. rewrote the queries, and it is much happier now. David -- "If only I could get rid of hunger by rubbing my belly" - Diogenes -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjuran at gmail.com Mon Jan 18 16:04:53 2010 From: jjuran at gmail.com (Joshua Juran) Date: Mon, 18 Jan 2010 16:04:53 -0800 Subject: SPUG: idioms of late In-Reply-To: <4B54F2DF.5050202@shaw.ca> References: <2CE3C44F-3B5D-41AF-8133-6A98E3F973B8@att.net> <175825721001141150o3c15450en40ee6bc0ed105ad7@mail.gmail.com> <201001181204.07129.m3047@m3047.net> <740AF03C-8A11-42D3-8249-55EACAC29F04@gmail.com> <4B54F2DF.5050202@shaw.ca> Message-ID: On Jan 18, 2010, at 3:46 PM, John W. Krahn wrote: > Joshua Juran wrote: >> On Jan 18, 2010, at 12:04 PM, Fred Morris wrote: >>> Lately I've found myself doing a lot of processing of lists... >>> usually >>> either listrefs, or a list of keys which can be looked up in a >>> hashref. >>> I've found myself using a few idioms in place of for/while loops >>> repeatedly, and I thought I'd share. >>> >>> $foo->{names} = [ map { my $x = $_; $x =~ s/\.$//o; $x; } >>> @{$foo->{names}} >>> ]; >>> >>> That one munges a listref, stripping trailing dots off of all of the >>> elements. The initial "$x = $_;" seems to be necessary. That one >>> seems >>> rather pythonic to me. Generally speaking they prefer that I use >>> perl. >> First of all, let me note that your use of /o does nothing, since >> the pattern doesn't contain any variables and therefore doesn't >> need to be recompiled in the first place. You have to use a copy >> of $_ because $_ is read-only in map. > > Incorrect. You can modify $_ but that will just modify the > contents of the original array because, as in a foreach loop, $_ is > an alias to the current element of the original array. True. Unless the original is read-only: $ perl -le 'print join " ", map { my $x = $_; $x =~ s/\.$//; $x; } qw ( foo bar. baz.. )' foo bar baz. $ perl -le 'print join " ", map { s/\.$//o; $_; } qw( foo bar. baz.. )' Modification of a read-only value attempted at -e line 1. Josh From jd at commandprompt.com Mon Jan 18 18:24:35 2010 From: jd at commandprompt.com (Joshua D. Drake) Date: Mon, 18 Jan 2010 18:24:35 -0800 Subject: SPUG: Dumb Simple PostgreSQL Performance Message-ID: <1263867875.9199.127.camel@jd-desktop.unknown.charter.com> Hey, I just wanted to throw out a preemptive thanks for having me speak. I am looking forward to it. See you guys tomorrow. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. From rjk-spug at tamias.net Mon Jan 18 19:04:13 2010 From: rjk-spug at tamias.net (Ronald J Kimball) Date: Mon, 18 Jan 2010 22:04:13 -0500 Subject: SPUG: idioms of late In-Reply-To: <201001181204.07129.m3047@m3047.net> References: <2CE3C44F-3B5D-41AF-8133-6A98E3F973B8@att.net> <175825721001141150o3c15450en40ee6bc0ed105ad7@mail.gmail.com> <201001181204.07129.m3047@m3047.net> Message-ID: <20100119030413.GA47755@penkwe.pair.com> On Mon, Jan 18, 2010 at 12:04:07PM -0800, Fred Morris wrote: > $foo->{names} = [ map { my $x = $_; $x =~ s/\.$//o; $x; } > @{$foo->{names}} > ]; > > That one munges a listref, stripping trailing dots off of all of the > elements. The initial "$x = $_;" seems to be necessary. That one seems > rather pythonic to me. Generally speaking they prefer that I use perl. If you want to edit the list in place, I think you might as well just edit it in place. s/\.$// foreach @{$foo->{names}}; Ronald From andrew at sweger.net Mon Jan 18 20:10:19 2010 From: andrew at sweger.net (Andrew Sweger) Date: Mon, 18 Jan 2010 20:10:19 -0800 (PST) Subject: SPUG: idioms of late In-Reply-To: <201001181204.07129.m3047@m3047.net> Message-ID: On Mon, 18 Jan 2010, Fred Morris wrote: > $foo->{names} = [ map { my $x = $_; $x =~ s/\.$//o; $x; } > @{$foo->{names}} > ]; I prefer (because of munging the original items): s/\.$// for @{$foo->{names}}; > printf "%s\n", join( "\t", @{$foo}{@FIELDS} ); I love hash slices! ...to the consternation of some coworkers (heavy comments always provided). But does this behave correctly? Did you mean: printf "%s\n" for join "\t", @{$foo}{@FIELDS}; I use a similar technique of hash slices for dealing with mapping to/from my hashes and SQL insert/update statements. I use the @FIELDS to control the field list so it only has to be stated once. (The legacy code resorts to explicit numeric array indices to tease out the data for each field. Oy!) > my ($name, $address, $city) = > map $dbh->quote($_), @{$self}{qw/ name address city /}; Boo! Parameter binding is your friend, Fred. But partial points for using the DBI/DBD quote method (as opposed to the insane DIY one I found in some legacy code!). -- Andrew B. Sweger -- The great thing about multitasking is that several things can go wrong at once. From MichaelRWolf at att.net Mon Jan 18 23:51:43 2010 From: MichaelRWolf at att.net (Michael R. Wolf) Date: Mon, 18 Jan 2010 23:51:43 -0800 Subject: SPUG: idioms of late In-Reply-To: <201001181204.07129.m3047@m3047.net> References: <2CE3C44F-3B5D-41AF-8133-6A98E3F973B8@att.net> <175825721001141150o3c15450en40ee6bc0ed105ad7@mail.gmail.com> <201001181204.07129.m3047@m3047.net> Message-ID: <5BCC8AF1-00C2-480C-8D66-459D10136C53@att.net> On Jan 18, 2010, at 12:04 PM, Fred Morris wrote: > Lately I've found myself doing a lot of processing of lists... usually > either listrefs, or a list of keys which can be looked up in a > hashref. > I've found myself using a few idioms in place of for/while loops > repeatedly, and I thought I'd share. Thanks. It's great to hear success stories and follklore... > $foo->{names} = [ map { my $x = $_; $x =~ s/\.$//o; $x; } > @{$foo->{names}} > ]; Did you try this? $foo->{names} = [ map { s/\.$//o; $_; } @{$foo->{names}} ]; > The initial "$x = $_;" seems to be necessary. -- Michael R. Wolf All mammals learn by playing! MichaelRWolf at att.net From MichaelRWolf at att.net Mon Jan 18 23:53:23 2010 From: MichaelRWolf at att.net (Michael R. Wolf) Date: Mon, 18 Jan 2010 23:53:23 -0800 Subject: SPUG: idioms of late In-Reply-To: <5BCC8AF1-00C2-480C-8D66-459D10136C53@att.net> References: <2CE3C44F-3B5D-41AF-8133-6A98E3F973B8@att.net> <175825721001141150o3c15450en40ee6bc0ed105ad7@mail.gmail.com> <201001181204.07129.m3047@m3047.net> <5BCC8AF1-00C2-480C-8D66-459D10136C53@att.net> Message-ID: On Jan 18, 2010, at 11:51 PM, Michael R. Wolf wrote: > > Did you try this? > Never mind. Thanks, Joshua. -- Michael R. Wolf All mammals learn by playing! MichaelRWolf at att.net From MichaelRWolf at att.net Mon Jan 18 23:59:10 2010 From: MichaelRWolf at att.net (Michael R. Wolf) Date: Mon, 18 Jan 2010 23:59:10 -0800 Subject: SPUG: idioms of late In-Reply-To: <740AF03C-8A11-42D3-8249-55EACAC29F04@gmail.com> References: <2CE3C44F-3B5D-41AF-8133-6A98E3F973B8@att.net> <175825721001141150o3c15450en40ee6bc0ed105ad7@mail.gmail.com> <201001181204.07129.m3047@m3047.net> <740AF03C-8A11-42D3-8249-55EACAC29F04@gmail.com> Message-ID: <1D508906-FCAB-4D9D-A8DD-60AA436A3ED6@att.net> On Jan 18, 2010, at 3:39 PM, Joshua Juran wrote: > You have to use a copy of $_ because $_ is read-only in map. Thanks for the reminder. I, too, have started using a bit more functional-style Perl of late. It's good to be reminded of the limitations. And I'm also weighing the functional map and grep versus (as you say) non-functional foreach loops. I'm still on the fence for some uses, but trying to grow into the (Higher Order Perl) way of doing some list processing. Thanks for the thread and comments, all.... -- Michael R. Wolf All mammals learn by playing! MichaelRWolf at att.net From MichaelRWolf at att.net Tue Jan 19 00:17:12 2010 From: MichaelRWolf at att.net (Michael R. Wolf) Date: Tue, 19 Jan 2010 00:17:12 -0800 Subject: SPUG: idioms of late In-Reply-To: References: Message-ID: On Jan 18, 2010, at 8:10 PM, Andrew Sweger wrote: [...] > for using > the DBI/DBD quote method (as opposed to the insane DIY one I found > in some > legacy code!). And, while you're talking about DIY in maintained code, remember that Gisle has created a bunch of great URI manipulation routines, so there's no need to escape them yourself... $ perl -MURI::Escape -e 'print uri_escape(chr($_)) foreach 0..0x7F' %00%01%02%03%04%05%06%07%08%09%0A%0B%0C%0D%0E%0F %10%11%12%13%14%15%16%17%18%19%1A%1B%1C%1D%1E%1F%20!%22%23%24%25%26'()* %2B%2C-.%2F0123456789%3A%3B%3C%3D%3E%3F%40ABCDEFGHIJKLMNOPQRSTUVWXYZ%5B %5C%5D%5E_%60abcdefghijklmnopqrstuvwxyz%7B%7C%7D~%7F $ (It'll go up to 0xFF without needing to use uri_escape_utf8(), but it's not really interesting above 0x7F) Who's got the time to look 'em all up and get 'em right? Not me. Great set of routines, those URI::* modules. I've seen some code that has to munge this to conform to PHP conventions (e.g. s/%20/+/g), but I'd still rather start with the standard instead of a DIY. -- Michael R. Wolf All mammals learn by playing! MichaelRWolf at att.net From rjk-spug at tamias.net Tue Jan 19 09:18:39 2010 From: rjk-spug at tamias.net (Ronald J Kimball) Date: Tue, 19 Jan 2010 12:18:39 -0500 Subject: SPUG: idioms of late In-Reply-To: <1D508906-FCAB-4D9D-A8DD-60AA436A3ED6@att.net> References: <2CE3C44F-3B5D-41AF-8133-6A98E3F973B8@att.net> <175825721001141150o3c15450en40ee6bc0ed105ad7@mail.gmail.com> <201001181204.07129.m3047@m3047.net> <740AF03C-8A11-42D3-8249-55EACAC29F04@gmail.com> <1D508906-FCAB-4D9D-A8DD-60AA436A3ED6@att.net> Message-ID: <20100119171839.GA4888@penkwe.pair.com> On Mon, Jan 18, 2010 at 11:59:10PM -0800, Michael R. Wolf wrote: > > On Jan 18, 2010, at 3:39 PM, Joshua Juran wrote: > > >You have to use a copy of $_ because $_ is read-only in map. > > Thanks for the reminder. I, too, have started using a bit more > functional-style Perl of late. It's good to be reminded of the > limitations. *rolls eyes* Again, $_ is not read-only in map. It is aliased to the original value. Changes made to $_ will affect the original value. The original code could have been written as: map { s/\.$// } @{$foo->{names}}; (If the original value is read-only, then $_ will be read-only, but that's true for any approach that involves aliasing, not just map.) Ronald From m3047 at m3047.net Tue Jan 19 10:55:08 2010 From: m3047 at m3047.net (Fred Morris) Date: Tue, 19 Jan 2010 10:55:08 -0800 Subject: SPUG: idioms of late In-Reply-To: <740AF03C-8A11-42D3-8249-55EACAC29F04@gmail.com> References: <2CE3C44F-3B5D-41AF-8133-6A98E3F973B8@att.net> <201001181204.07129.m3047@m3047.net> <740AF03C-8A11-42D3-8249-55EACAC29F04@gmail.com> Message-ID: <201001191055.08649.m3047@m3047.net> On Monday 18 January 2010 15:39, Joshua Juran wrote: > [...] > First of all, let me note that your use of /o does nothing [...] Let it do nothing, then, but to mark the expression as invariant. > I hope this sort of critique is what you were looking for. Sure. Yah, same concerns about "efficiency". There are different kinds of efficiency. They would frown, I think, more on things like "s/x/y/ for @a" where I work. Plus my example only included a single (contrived) modification, I didn't want to share actual code. In any case, our computational limitations are not CPU. I like the pythonic "look" of doing something inside of "[ ]". Of course if it smites your eye I suppose (haven't tried it) you could "do {} for @a". I am not claiming one is more "elegant" than the other (eliding the implied "liking"), just that having programmed in a number of languages, one is more pleasing to my eye than the other. Also $x->{a} = [ f($x->{a} ] does indeed replace the original $x->{a} *reference*, just in case someone else needs the reference unmunged somewhere else. I wish preparing SQL statements made more sense in our processing environment, but mostly it doesn't for reasons which are complicated to go into. We don't write mega-epic perl scripts (or we try not to but accept failure), we try and write smaller things which do something and then go away (oftentimes that "thing" has nothing whatsoever to do with the database and is very large) so preparing SQL statements has limited (f)utility. Actually I don't know the answer to this: does preparing statements when using MySQL+InnoDB do anything to reduce disk I/O, or is it just reducing CPU overhead? BTW, my first language was Pascal, and my second was MACRO-32 running on VAX/VMS (I wrote an entire RSTS block I/O emulator engine with interprocess locking support for VAX/VMS in MACRO-32, with a management API in BASIC of all things). If something really needed to be computationally efficient, I'd probably write it with Inline::C... I've done it before. -- Fred From andrew at sweger.net Fri Jan 22 14:06:06 2010 From: andrew at sweger.net (Andrew Sweger) Date: Fri, 22 Jan 2010 14:06:06 -0800 (PST) Subject: SPUG: February SPUG meeting, need a star Message-ID: Any takers to be the star of the upcoming blockbuster SPUG meeting on February 16th? Just think of the fame and glory. Come share your Perl. -- Andrew B. Sweger -- The great thing about multitasking is that several things can go wrong at once. From jd at commandprompt.com Fri Jan 22 19:42:41 2010 From: jd at commandprompt.com (Joshua D. Drake) Date: Fri, 22 Jan 2010 19:42:41 -0800 Subject: SPUG: Thanks for having me Message-ID: <1264218161.1864.3.camel@jd-laptop.pragmaticzealot.org> Hello, Thanks for having me speak. A couple of things: 1. Attached are the slides. Enjoy them. 2. Where PostgreSQL keeps the settings after restart is pg_settings. I have know idea why I blanked on that. 3. You may also want to consider coming to East: http://www.postgresqlconference.org/ Remember that on these slides, the idea is the mass populous of installations. It is not designed for fine tuning. Joshua D. Drake -------------- next part -------------- A non-text attachment was scrubbed... Name: postgresql_performance.pdf Type: application/pdf Size: 333983 bytes Desc: not available URL: From skylos at gmail.com Sat Jan 23 13:41:52 2010 From: skylos at gmail.com (Skylos) Date: Sat, 23 Jan 2010 13:41:52 -0800 Subject: SPUG: Thoughts on DBIx::Class presentation? Message-ID: <3650cdc01001231341n24267958o83f6fe00463f0d0d@mail.gmail.com> I dunno if any of you have worked with DBIx::Class - its a way to program up db interfaces where you define the tables and columns and it uses SQL::Abstract to generate the sql. I worked with it intensely for about 9 months at a job, and am currently starting a new interface using it as well. Its a fairly new perl module, uses C3 inheritance pattern, and can get you out of having to embed language (sql) in language (perl). Is there any interest in hearing about how to use DBIx::Class to do database interfacing for perl applications? Skylos -- "If only I could get rid of hunger by rubbing my belly" - Diogenes -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjuran at gmail.com Sat Jan 23 14:22:54 2010 From: jjuran at gmail.com (Joshua Juran) Date: Sat, 23 Jan 2010 14:22:54 -0800 Subject: SPUG: Thoughts on DBIx::Class presentation? In-Reply-To: <3650cdc01001231341n24267958o83f6fe00463f0d0d@mail.gmail.com> References: <3650cdc01001231341n24267958o83f6fe00463f0d0d@mail.gmail.com> Message-ID: On Jan 23, 2010, at 1:41 PM, Skylos wrote: > I dunno if any of you have worked with DBIx::Class - its a way to > program up db interfaces where you define the tables and columns > and it uses SQL::Abstract to generate the sql. I worked with it > intensely for about 9 months at a job, and am currently starting a > new interface using it as well. > > Its a fairly new perl module, uses C3 inheritance pattern, and can > get you out of having to embed language (sql) in language (perl). > > Is there any interest in hearing about how to use DBIx::Class to do > database interfacing for perl applications? +1 I would also be interested in the file equivalent -- a language for describing the format of a file, and a processor that takes that file as input and returns a data structure as output. Josh From cjac at colliertech.org Sat Jan 23 16:00:56 2010 From: cjac at colliertech.org (C.J. Adams-Collier) Date: Sat, 23 Jan 2010 16:00:56 -0800 Subject: SPUG: Thoughts on DBIx::Class presentation? In-Reply-To: <3650cdc01001231341n24267958o83f6fe00463f0d0d@mail.gmail.com> References: <3650cdc01001231341n24267958o83f6fe00463f0d0d@mail.gmail.com> Message-ID: <1264291256.5904.7.camel@calcifer> Yeah, I'd love to get more familiar with it. We're using it for our work on the Liquid Web Storm on Demand product, and I'm certain I'm not making full use of it. Cheers, C.J. On Sat, 2010-01-23 at 13:41 -0800, Skylos wrote: > > I dunno if any of you have worked with DBIx::Class - its a way to > program up db interfaces where you define the tables and columns and > it uses SQL::Abstract to generate the sql. I worked with it intensely > for about 9 months at a job, and am currently starting a new interface > using it as well. > > Its a fairly new perl module, uses C3 inheritance pattern, and can get > you out of having to embed language (sql) in language (perl). > > Is there any interest in hearing about how to use DBIx::Class to do > database interfacing for perl applications? > > Skylos > > -- > "If only I could get rid of hunger by rubbing my belly" - Diogenes > _____________________________________________________________ > 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From klevin at eskimo.com Sat Jan 23 14:28:42 2010 From: klevin at eskimo.com (=?ISO-8859-1?Q?Noah_R=F8mer?=) Date: Sat, 23 Jan 2010 14:28:42 -0800 Subject: SPUG: Thoughts on DBIx::Class presentation? In-Reply-To: <3650cdc01001231341n24267958o83f6fe00463f0d0d@mail.gmail.com> References: <3650cdc01001231341n24267958o83f6fe00463f0d0d@mail.gmail.com> Message-ID: <4B5B781A.6090602@eskimo.com> Skylos wrote: > Is there any interest in hearing about how to use DBIx::Class to do > database interfacing for perl applications? I'd be interested in such a presentation. -- Noah Romer | The only person Palladium protects your klevin at eskimo.com | computer from - is you. PGP key available | --NTK by finger or email | From gigabo at gmail.com Mon Jan 25 08:40:09 2010 From: gigabo at gmail.com (Bo Borgerson) Date: Mon, 25 Jan 2010 08:40:09 -0800 Subject: SPUG: Thoughts on DBIx::Class presentation? In-Reply-To: <3650cdc01001231341n24267958o83f6fe00463f0d0d@mail.gmail.com> References: <3650cdc01001231341n24267958o83f6fe00463f0d0d@mail.gmail.com> Message-ID: <4B5DC969.9090008@gmail.com> Skylos wrote: > Is there any interest in hearing about how to use DBIx::Class to do > database interfacing for perl applications? > Definitely! Very interested. BTW - New to the list (/Seattle). Nice to meet you. Bo From andrew at sweger.net Fri Jan 29 15:39:23 2010 From: andrew at sweger.net (Andrew Sweger) Date: Fri, 29 Jan 2010 15:39:23 -0800 (PST) Subject: SPUG: February 2010 Seattle Perl Users Group (SPUG) Meeting Message-ID: February 2010 Seattle Perl Users Group (SPUG) Meeting ==================================================== Topic: DBIx::Class, why and how Speaker: David Ihnen Meeting Date: Tuesday, 16 February 2010 Meeting Time: 6:30 - 8:30 p.m. Location: Marchex - 520 Pike Street Cost: Admission is free and open to the public Info: http://seattleperl.org/ ==================================================== Tuesday, February 16, is the next meeting of the THE SEATTLE PERL USERS GROUP. This must be some kind of record. It's not even February yet and I'm sending this announcement out. Mark your calendar! This Month's Talk ----------------- - Why and how to use DBIx::Class. - How to set up your classes, either DBIx::Class::Loader, or manual configuration. - Class::C3 basics - Creating plugins for inflate - Creating plugins for triggers - Transactions and assumptions regarding AutoCommit and shared handles - Advanced 'Complex Query' workarounds - Application of Null pattern About David Ihnen ----------------- David Ihnen has over ten years experience with progressively more object-oriented Perl programming. He learned DBIx::Class for the interview questions for a job in Flagstaff, Arizona at a urine analysis lab where he helped build a web-based lab result management system for use by their clients. Now he is back in Seattle at Amazon (for the third time), where he builds test frameworks and untangles the vagaries of complex financial perl scripts. He currently lives in Issaquah with his 15-year partner, Dhugal, and two german shepherd dogs, Akando and Banshee. http://dogpawz.com/photos/Akando/AkandoSkylosBanshee.jpg Pre-Meeting =========== If you are so inclined, please come to the pre-meeting at the nearby Elephant & Castle pub on 5th & Union (see map link below). Come enjoy some friendly conversation and perhaps a favorite beverage (they have a full restaurant too). We can usually be found at the back under the TV near the rear entrance that goes up into the hotel (if you enter through the front doors, just go straight back past the bar). We'll be there from 5:00 pm to 6:19 pm. Meeting Location ================ Marchex 520 Pike Street, Suite 1800 Seattle, WA 98101 The building is just East of Westlake Center. Enter from Pike Street. http://xrl.us/spugmap 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. There is also a parking garage in the building, but check the rates and closing time (subject to change due to downtown events)! Attendees will need to wait near the elevators in the lobby and a Marchex employee will provide access to the 18th floor where the meeting room is located. If no one shows up to let you in, call (425) 533-2964 to let them know you're in the lobby. See you there!