From fred at redhotpenguin.com  Sat Feb  2 16:04:57 2013
From: fred at redhotpenguin.com (Fred Moyer)
Date: Sat, 2 Feb 2013 16:04:57 -0800
Subject: [sf-perl] [meeting] Module show and tell
Message-ID: <CAHrynWDX8UWq-hWszGAQSp0WqyB-Ut3=HoDXFpUpL2FV_UoU5g@mail.gmail.com>

Come eat pizza at Craigslist on Tuesday, February 26, 2013 at 7pm and
give a show and tell presentation of your favorite module.

Suggest making your presentation web accessible, bringing a laptop
with a VGA compatible connector, or be able to hop onto a terminal
window for a laptop hooked to the projector and take it from there.
Hope to see you there!

http://www.meetup.com/San-Francisco-Perl-Mongers/events/102582122

From russt at releasetools.org  Mon Feb  4 09:48:05 2013
From: russt at releasetools.org (Russ Tremain)
Date: Mon, 4 Feb 2013 09:48:05 -0800
Subject: [sf-perl] nice rebuttal to the "perl-is-dead" argument
Message-ID: <p06240801cd35a46ccf38@[10.0.101.154]>

see:  http://twitpic.com/c00pop (CPAN upload trends).

cheers.

From fred at redhotpenguin.com  Mon Feb  4 11:28:22 2013
From: fred at redhotpenguin.com (Fred Moyer)
Date: Mon, 4 Feb 2013 11:28:22 -0800
Subject: [sf-perl] nice rebuttal to the "perl-is-dead" argument
In-Reply-To: <p06240801cd35a46ccf38@10.0.101.154>
References: <p06240801cd35a46ccf38@10.0.101.154>
Message-ID: <CAHrynWCKd0bocTs=s_-66-Ag-3Cu_7OVcUz6aqam=f+wb=wXGg@mail.gmail.com>

On Mon, Feb 4, 2013 at 9:48 AM, Russ Tremain <russt at releasetools.org> wrote:
> see:  http://twitpic.com/c00pop (CPAN upload trends).

Great find. Here's another one I posted on the twitter feed a month
ago. The Perl Foundation sent out a prospectus to anyone who donated.

https://twitter.com/sfperlmongers/status/289934715086073856

>
> cheers.
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm

From russt at releasetools.org  Mon Feb  4 13:25:29 2013
From: russt at releasetools.org (Russ Tremain)
Date: Mon, 4 Feb 2013 13:25:29 -0800
Subject: [sf-perl] nice rebuttal to the "perl-is-dead" argument
In-Reply-To: <CAHrynWCKd0bocTs=s_-66-Ag-3Cu_7OVcUz6aqam=f+wb=wXGg@mail.gmail.com>
References: <p06240801cd35a46ccf38@10.0.101.154>
	<CAHrynWCKd0bocTs=s_-66-Ag-3Cu_7OVcUz6aqam=f+wb=wXGg@mail.gmail.com>
Message-ID: <p06240803cd35d63b7bc5@[10.0.101.154]>

there is an 
<http://www.linkedin.com/e/eupmwe-hcrzwv1q-5p/vaq/209768813/106254/117707601/view_disc/?hs=false&tok=3T_z0G-Qb_TlA1>ongoing 
disccussion on linked-In (you have to login, unfortunately).

and the original Info World article is here:

	https://www.infoworld.com/d/data-center/perl-isnt-going-anywhere-better-or-worse-211580

Fred, not sure what a picture of the Perl Foundation prospectus does 
for me, unless it is a subtle hint that we all should donate?

cheers.

At 11:28 AM -0800 2/4/13, Fred Moyer wrote:
>On Mon, Feb 4, 2013 at 9:48 AM, Russ Tremain <russt at releasetools.org> wrote:
>>  see:  http://twitpic.com/c00pop (CPAN upload trends).
>
>Great find. Here's another one I posted on the twitter feed a month
>ago. The Perl Foundation sent out a prospectus to anyone who donated.
>
>https://twitter.com/sfperlmongers/status/289934715086073856
>
>>
>>  cheers.
>>  _______________________________________________
>>  SanFrancisco-pm mailing list
>>  SanFrancisco-pm at pm.org
>>  http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20130204/743a578c/attachment.html>

From jeff at imaginative-software.com  Mon Feb  4 14:02:24 2013
From: jeff at imaginative-software.com (Jeffrey Ryan Thalhammer)
Date: Mon, 4 Feb 2013 14:02:24 -0800
Subject: [sf-perl] nice rebuttal to the "perl-is-dead" argument
In-Reply-To: <CAHrynWCKd0bocTs=s_-66-Ag-3Cu_7OVcUz6aqam=f+wb=wXGg@mail.gmail.com>
References: <p06240801cd35a46ccf38@10.0.101.154>
	<CAHrynWCKd0bocTs=s_-66-Ag-3Cu_7OVcUz6aqam=f+wb=wXGg@mail.gmail.com>
Message-ID: <8B657812-5823-46D7-AF5A-25E3800C07C0@imaginative-software.com>

Russ' comment on the linked-in thread got me thinking?

One of the nice things about Ruby is that it comes with all the scaffolding for making, shipping, and distributing finished work (i.e. gems).

Leaves me wishing Perl shipped with Dist::Zilla.  Regardless of how you feel about their implementation, I think making those kind of tools easier to get would do a lot to help the cause.

Ironically,  I'm usually in the "thin core" camp.

-Jeff

From hartzell at alerce.com  Thu Feb  7 22:11:51 2013
From: hartzell at alerce.com (George Hartzell)
Date: Thu, 7 Feb 2013 22:11:51 -0800
Subject: [sf-perl] I used to have 99 problems, now....
Message-ID: <20756.38695.777731.365262@gargle.gargle.HOWL>


  http://imgs.xkcd.com/comics/perl_problems.png

g.

From jeff at imaginative-software.com  Thu Feb  7 22:40:15 2013
From: jeff at imaginative-software.com (Jeffrey Ryan Thalhammer)
Date: Thu, 7 Feb 2013 22:40:15 -0800
Subject: [sf-perl] Maybe "Perl5" is just like "OS X"
Message-ID: <D1A91C53-C47C-400F-AA76-C2069974821A@imaginative-software.com>

If you haven't already, do check out the discussion on Perl version numbers at http://blogs.perl.org.  Here's an additional thought...

Mac OS was (and still is) in the same situation as Perl.  For years, the official version number has been 10.something.  But from the very beginning, they disguised it as "Mac OS X $feline".  The "X" is a clear nod to the original 0..9 ancestry but it doesn't overtly express any kind of sequence.  Instead, the sequence is expressed as $felines, which are much more exciting to talk about than numbers like "16.2".

Perl could do exactly the same thing to construct a marketing version that is both accurate and exciting.  Say we change the "5" to "V" and use cities of the world rather than cats.  Imagine: "Perl V Moscow" or "Perl V Sydney".  Only trouble is that "V" still seems tied to "5", more so than "X" does to 10.  But maybe that's just because I'm so used to "5".  Internally, it would still just be 5.whatever.

Anyway, that's just an idea.  I do like the "cities" idea though -- it gives it a nice global appeal.

-Jeff

From fred at redhotpenguin.com  Thu Feb  7 23:43:07 2013
From: fred at redhotpenguin.com (Fred Moyer)
Date: Thu, 7 Feb 2013 23:43:07 -0800
Subject: [sf-perl] Maybe "Perl5" is just like "OS X"
In-Reply-To: <D1A91C53-C47C-400F-AA76-C2069974821A@imaginative-software.com>
References: <D1A91C53-C47C-400F-AA76-C2069974821A@imaginative-software.com>
Message-ID: <CAHrynWBXjr1xKfNMcjEf8t+=cJqmdSzghix3oKTerEY_MRyxoA@mail.gmail.com>

On Thu, Feb 7, 2013 at 10:40 PM, Jeffrey Ryan Thalhammer
<jeff at imaginative-software.com> wrote:
> Perl could do exactly the same thing to construct a marketing version that is both accurate and exciting.  Say we change the "5" to > "V" and use cities of the world rather than cats.

I don't know that the cats on the internet will like it, but it sounds
good to me.

> Imagine: "Perl V Moscow" or "Perl V Sydney".  Only trouble is that "V" still seems tied to "5", more so than "X" does to 10.  But maybe that's just because I'm so used to "5".  Internally, it would still just be 5.whatever.

Something like:

my $num_ver = 5.16
my ($major, $minor) = split(/\./, $num_ver);
my @cities = ( qw( Athens Boston Chicago Damascus Edinburgh ... ) );
my $city = $cities[$minor];

# porting to perl 6 is left as an exercise for the reader
my $market_version = sprintf('Perl V %s', $city);

say "Welcome to '$market_version'!";

Welcome to 'Perl V Paris'!


>
> Anyway, that's just an idea.  I do like the "cities" idea though -- it gives it a nice global appeal.
>
> -Jeff
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm

From david at fetter.org  Fri Feb  8 09:32:06 2013
From: david at fetter.org (David Fetter)
Date: Fri, 8 Feb 2013 09:32:06 -0800
Subject: [sf-perl] I used to have 99 problems, now....
In-Reply-To: <20756.38695.777731.365262@gargle.gargle.HOWL>
References: <20756.38695.777731.365262@gargle.gargle.HOWL>
Message-ID: <20130208173206.GK2054@fetter.org>

URL with hilarious alt-text, which is at least half the xkcd story:

https://xkcd.com/1171/

Another, built for devices without hover:

https://m.xkcd.com/1171/

Cheers,
David.
On Thu, Feb 07, 2013 at 10:11:51PM -0800, George Hartzell wrote:
> 
>   http://imgs.xkcd.com/comics/perl_problems.png
> 
> g.
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm

-- 
David Fetter <david at fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter at gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

From doom at kzsu.stanford.edu  Fri Feb  8 10:31:50 2013
From: doom at kzsu.stanford.edu (Joseph Brenner)
Date: Fri, 8 Feb 2013 10:31:50 -0800
Subject: [sf-perl] Maybe "Perl5" is just like "OS X"
In-Reply-To: <D1A91C53-C47C-400F-AA76-C2069974821A@imaginative-software.com>
References: <D1A91C53-C47C-400F-AA76-C2069974821A@imaginative-software.com>
Message-ID: <CAFfgvXX32bfhVCeFtNTJ2mtdwdnOHcWCrick6oT8c+sHtPphLQ@mail.gmail.com>

Jeffrey Ryan Thalhammer <jeff at imaginative-software.com> wrote:
> If you haven't already, do check out the discussion on Perl version numbers at http://blogs.perl.org.  Here's an additional thought...
>
> Mac OS was (and still is) in the same situation as Perl.  [...]
> Instead, the sequence is expressed as $felines, which are much more exciting to talk about than numbers like "16.2".

The cat names still don't mean anything to people on the outside (like
myself) and arguably that's what the whole issue is about, talking to
outsiders (and convincing the insiders that they need to think about
talking to outsiders... good luck there, eh?).

I'm a fan of the "Perl <YYYY>" idea, though it could be that "Perl
2013" isn't the most auspicious year to try it out.

The central trouble with the "Perl 7" idea is that few people want to
thumb their nose at Perl 6 for (arguably) stalling out, and yet many
people would like some way to express that the original Perl is still
moving forward.

It could be that your idea of using separate schemes internally and
externally is a good
idea for bringing along the guys who are hostile to any thoughts of marketing.

From doom at kzsu.stanford.edu  Fri Feb  8 10:33:10 2013
From: doom at kzsu.stanford.edu (Joseph Brenner)
Date: Fri, 8 Feb 2013 10:33:10 -0800
Subject: [sf-perl] Maybe "Perl5" is just like "OS X"
In-Reply-To: <CAHrynWBXjr1xKfNMcjEf8t+=cJqmdSzghix3oKTerEY_MRyxoA@mail.gmail.com>
References: <D1A91C53-C47C-400F-AA76-C2069974821A@imaginative-software.com>
	<CAHrynWBXjr1xKfNMcjEf8t+=cJqmdSzghix3oKTerEY_MRyxoA@mail.gmail.com>
Message-ID: <CAFfgvXWSqHNYkArMoLZLK_eLArBJP+9aeDN-tn9CeEWE7HwXYQ@mail.gmail.com>

Fred Moyer <fred at redhotpenguin.com> wrote:
> Jeffrey Ryan Thalhammer <jeff at imaginative-software.com> wrote:

>> Imagine: "Perl V Moscow" or "Perl V Sydney".  Only trouble is that "V" still seems tied to "5", more so than "X" does to 10.  But maybe that's just because I'm so used to "5".  Internally, it would still just be 5.whatever.
>
> Something like:
>
> my $num_ver = 5.16
> my ($major, $minor) = split(/\./, $num_ver);
> my @cities = ( qw( Athens Boston Chicago Damascus Edinburgh ... ) );
> my $city = $cities[$minor];

Yeah, I was just thinking about the Ubuntu naming scheme: in addition
to numbers, they use animal names in alphabetic order, so you know
that Ocelot is after Narwhal.

Though I think after they started using names like "Narwhal" people
started referring to releases by number.

From extasia at extasia.org  Fri Feb  8 11:32:32 2013
From: extasia at extasia.org (David Alban)
Date: Fri, 8 Feb 2013 11:32:32 -0800
Subject: [sf-perl] cgi question
Message-ID: <CALDD_=k6mhTM7WcSkm2GZuTnjQJjdYKoh+V8ABgqCoCTS+2VYA@mail.gmail.com>

greetings,

a cgi program i'm writing calls an external perl program.  when run
from the command line, the external program runs correctly, but via
cgi, it doesn't, complaining about not being able to find JSON.pm.

command line invocation of external program works as expected:

[root at srwd00reg011 ~]# jenkins-build-data  --help
usage: jenkins-build-data [ options ]

options:
  -h,--help            List usage and exit

  -b,--branch Branch      Process using branch Branch

  --list-branches      List branches that have available jenkins builds

  --list-builds        List build numbers for given branch.  Requires --branch.

  --list-artifacts     List url's for artifacts in a given build.
Requires --branch and --build.

  -u,--build Build     Process using build number Build

then, from error_log:

[Fri Feb 08 19:19:13 2013] [error] [client 10.249.134.215] 2013-02-08
19:19:13 +0000 srwd00reg011
jenkins-build-changes-from-jenkins-build-data.cgi[26068]
PRIORITY=ERROR [*] command returned non-zero status (2); cmd =>
'jenkins-build-data --list-branches' ; output => 'command returned
non-zero status; command => 'jenkins-build-data --list-branches';
status => 2; command output => Can't locate JSON/XS.pm in @INC (@INC
contains: /nas/reg/lib/perl/x86_64-linux-thread-multi
/nas/reg/lib/perl/5.8.8 /nas/reg/lib/perl/5.8.5 /nas/reg/lib/perl
/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8
.) at /nas/reg/bin/jenkins-build-data line 11.
[Fri Feb 08 19:19:13 2013] [error] [client 10.249.134.215] 2013-02-08
19:19:13 +0000 srwd00reg011
jenkins-build-changes-from-jenkins-build-data.cgi[26068]
PRIORITY=ERROR BEGIN failed--compilation aborted at
/nas/reg/bin/jenkins-build-data line 11.
[Fri Feb 08 19:19:13 2013] [error] [client 10.249.134.215] 2013-02-08
19:19:13 +0000 srwd00reg011
jenkins-build-changes-from-jenkins-build-data.cgi[26068]
PRIORITY=ERROR '
[Fri Feb 08 19:19:13 2013] [error] [client 10.249.134.215] Premature
end of script headers:
jenkins-build-changes-from-jenkins-build-data.cgi
[Fri Feb 08 19:19:13 2013] [error] [client 10.249.134.215] File does
not exist: /var/www/html/favicon.ico

i get "Can't locate JSON/XS.pm in @INC".

another test:

[root at srwd00reg011 ~]# sudo -H -u apache perl
/nas/reg/bin/jenkins-build-data --help
Can't locate JSON/XS.pm in @INC (@INC contains:
/nas/reg/lib/perl/x86_64-linux-thread-multi /nas/reg/lib/perl/5.8.8
/nas/reg/lib/perl/5.8.5 /nas/reg/lib/perl
/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8
.) at /nas/reg/bin/jenkins-build-data line 11.
BEGIN failed--compilation aborted at /nas/reg/bin/jenkins-build-data line 11.

and we have:

$ find /nas/reg/lib/perl/x86_64-linux-thread-multi/JSON/ -ls
3336992448    4 drwxr-sr-x   3 root     regauto      2048 Jan 19 00:48
/nas/reg/lib/perl/x86_64-linux-thread-multi/JSON/
2825141390    4 drwxr-sr-x   2 root     regauto      2048 Jan 19 00:48
/nas/reg/lib/perl/x86_64-linux-thread-multi/JSON/XS
1173004200    4 -r--r--r--   1 root     regauto       386 Jul  3  2007
/nas/reg/lib/perl/x86_64-linux-thread-multi/JSON/XS/Boolean.pm
967325435   56 -r--r--r--   1 root     regauto     57085 Aug  1  2012
/nas/reg/lib/perl/x86_64-linux-thread-multi/JSON/XS.pm

and:

$ find /nas/reg/lib/perl/JSON -ls
4275598264    4 drwxr-sr-x   3 relmgt   regauto      2048 Sep 26  2011
/nas/reg/lib/perl/JSON
215538142    4 drwxr-sr-x   2 relmgt   regauto      2048 Sep 26  2011
/nas/reg/lib/perl/JSON/PP
504904387    4 -r--r--r--   1 relmgt   regauto      3939 Sep 26  2011
/nas/reg/lib/perl/JSON/PP/Compat5006.pm
3961032869    4 -r--r--r--   1 relmgt   regauto       425 Feb  8  2008
/nas/reg/lib/perl/JSON/PP/Boolean.pm
3051093964   16 -r-xr-xr-x   1 relmgt   regauto     14104 Jul  5  2008
/nas/reg/lib/perl/JSON/Any.pm
1481989354   84 -r--r--r--   1 relmgt   regauto     82227 Sep 26  2011
/nas/reg/lib/perl/JSON/PP.pm
185846595    4 -r--r--r--   1 relmgt   regauto      3913 Jun  3  2008
/nas/reg/lib/perl/JSON/PP5005.pm
4178796837    8 -r--r--r--   1 relmgt   regauto      4438 Jun  4  2008
/nas/reg/lib/perl/JSON/PP56.pm
3956507192    4 -r--r--r--   1 relmgt   regauto      1972 Jun  4  2008
/nas/reg/lib/perl/JSON/PP58.pm

what am i missing?

thanks,
david
-- 
Live in a world of your own, but always welcome visitors.
***
Rule of law is for the little people.
http://www.amazon.com/Liberty-Justice-Some-Equality-Powerful/dp/0805092056

From quinn at pgexperts.com  Fri Feb  8 11:42:49 2013
From: quinn at pgexperts.com (Quinn Weaver)
Date: Fri, 8 Feb 2013 11:42:49 -0800
Subject: [sf-perl] cgi question
In-Reply-To: <CALDD_=k6mhTM7WcSkm2GZuTnjQJjdYKoh+V8ABgqCoCTS+2VYA@mail.gmail.com>
References: <CALDD_=k6mhTM7WcSkm2GZuTnjQJjdYKoh+V8ABgqCoCTS+2VYA@mail.gmail.com>
Message-ID: <FC5C9895-5134-4C1D-95EE-FB415238BED7@pgexperts.com>

If JSON.pm is indeed in one of the directories listed for @INC, then I would check permissions. Maybe the CGI user, who is running the new perl process, doesn't have permission to read JSON.pm or its ancestor directories.

On Feb 8, 2013, at 11:32 AM, David Alban wrote:

> greetings,
> 
> a cgi program i'm writing calls an external perl program.  when run
> from the command line, the external program runs correctly, but via
> cgi, it doesn't, complaining about not being able to find JSON.pm.
> 
> command line invocation of external program works as expected:
> 
> [root at srwd00reg011 ~]# jenkins-build-data  --help
> usage: jenkins-build-data [ options ]
> 
> options:
>  -h,--help            List usage and exit
> 
>  -b,--branch Branch      Process using branch Branch
> 
>  --list-branches      List branches that have available jenkins builds
> 
>  --list-builds        List build numbers for given branch.  Requires --branch.
> 
>  --list-artifacts     List url's for artifacts in a given build.
> Requires --branch and --build.
> 
>  -u,--build Build     Process using build number Build
> 
> then, from error_log:
> 
> [Fri Feb 08 19:19:13 2013] [error] [client 10.249.134.215] 2013-02-08
> 19:19:13 +0000 srwd00reg011
> jenkins-build-changes-from-jenkins-build-data.cgi[26068]
> PRIORITY=ERROR [*] command returned non-zero status (2); cmd =>
> 'jenkins-build-data --list-branches' ; output => 'command returned
> non-zero status; command => 'jenkins-build-data --list-branches';
> status => 2; command output => Can't locate JSON/XS.pm in @INC (@INC
> contains: /nas/reg/lib/perl/x86_64-linux-thread-multi
> /nas/reg/lib/perl/5.8.8 /nas/reg/lib/perl/5.8.5 /nas/reg/lib/perl
> /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi
> /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl
> /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl
> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8
> .) at /nas/reg/bin/jenkins-build-data line 11.
> [Fri Feb 08 19:19:13 2013] [error] [client 10.249.134.215] 2013-02-08
> 19:19:13 +0000 srwd00reg011
> jenkins-build-changes-from-jenkins-build-data.cgi[26068]
> PRIORITY=ERROR BEGIN failed--compilation aborted at
> /nas/reg/bin/jenkins-build-data line 11.
> [Fri Feb 08 19:19:13 2013] [error] [client 10.249.134.215] 2013-02-08
> 19:19:13 +0000 srwd00reg011
> jenkins-build-changes-from-jenkins-build-data.cgi[26068]
> PRIORITY=ERROR '
> [Fri Feb 08 19:19:13 2013] [error] [client 10.249.134.215] Premature
> end of script headers:
> jenkins-build-changes-from-jenkins-build-data.cgi
> [Fri Feb 08 19:19:13 2013] [error] [client 10.249.134.215] File does
> not exist: /var/www/html/favicon.ico
> 
> i get "Can't locate JSON/XS.pm in @INC".
> 
> another test:
> 
> [root at srwd00reg011 ~]# sudo -H -u apache perl
> /nas/reg/bin/jenkins-build-data --help
> Can't locate JSON/XS.pm in @INC (@INC contains:
> /nas/reg/lib/perl/x86_64-linux-thread-multi /nas/reg/lib/perl/5.8.8
> /nas/reg/lib/perl/5.8.5 /nas/reg/lib/perl
> /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi
> /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl
> /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl
> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8
> .) at /nas/reg/bin/jenkins-build-data line 11.
> BEGIN failed--compilation aborted at /nas/reg/bin/jenkins-build-data line 11.
> 
> and we have:
> 
> $ find /nas/reg/lib/perl/x86_64-linux-thread-multi/JSON/ -ls
> 3336992448    4 drwxr-sr-x   3 root     regauto      2048 Jan 19 00:48
> /nas/reg/lib/perl/x86_64-linux-thread-multi/JSON/
> 2825141390    4 drwxr-sr-x   2 root     regauto      2048 Jan 19 00:48
> /nas/reg/lib/perl/x86_64-linux-thread-multi/JSON/XS
> 1173004200    4 -r--r--r--   1 root     regauto       386 Jul  3  2007
> /nas/reg/lib/perl/x86_64-linux-thread-multi/JSON/XS/Boolean.pm
> 967325435   56 -r--r--r--   1 root     regauto     57085 Aug  1  2012
> /nas/reg/lib/perl/x86_64-linux-thread-multi/JSON/XS.pm
> 
> and:
> 
> $ find /nas/reg/lib/perl/JSON -ls
> 4275598264    4 drwxr-sr-x   3 relmgt   regauto      2048 Sep 26  2011
> /nas/reg/lib/perl/JSON
> 215538142    4 drwxr-sr-x   2 relmgt   regauto      2048 Sep 26  2011
> /nas/reg/lib/perl/JSON/PP
> 504904387    4 -r--r--r--   1 relmgt   regauto      3939 Sep 26  2011
> /nas/reg/lib/perl/JSON/PP/Compat5006.pm
> 3961032869    4 -r--r--r--   1 relmgt   regauto       425 Feb  8  2008
> /nas/reg/lib/perl/JSON/PP/Boolean.pm
> 3051093964   16 -r-xr-xr-x   1 relmgt   regauto     14104 Jul  5  2008
> /nas/reg/lib/perl/JSON/Any.pm
> 1481989354   84 -r--r--r--   1 relmgt   regauto     82227 Sep 26  2011
> /nas/reg/lib/perl/JSON/PP.pm
> 185846595    4 -r--r--r--   1 relmgt   regauto      3913 Jun  3  2008
> /nas/reg/lib/perl/JSON/PP5005.pm
> 4178796837    8 -r--r--r--   1 relmgt   regauto      4438 Jun  4  2008
> /nas/reg/lib/perl/JSON/PP56.pm
> 3956507192    4 -r--r--r--   1 relmgt   regauto      1972 Jun  4  2008
> /nas/reg/lib/perl/JSON/PP58.pm
> 
> what am i missing?
> 
> thanks,
> david
> -- 
> Live in a world of your own, but always welcome visitors.
> ***
> Rule of law is for the little people.
> http://www.amazon.com/Liberty-Justice-Some-Equality-Powerful/dp/0805092056
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm


Regards,

--
Quinn Weaver
PostgreSQL Experts, Inc.
http://pgexperts.com/
1-888-743-9778 (my extension: 510)



From fobispo at isc.org  Fri Feb  8 11:45:06 2013
From: fobispo at isc.org (Francisco Obispo)
Date: Fri, 8 Feb 2013 11:45:06 -0800
Subject: [sf-perl] cgi question
In-Reply-To: <CALDD_=k6mhTM7WcSkm2GZuTnjQJjdYKoh+V8ABgqCoCTS+2VYA@mail.gmail.com>
References: <CALDD_=k6mhTM7WcSkm2GZuTnjQJjdYKoh+V8ABgqCoCTS+2VYA@mail.gmail.com>
Message-ID: <4D5A5E61-9E95-4E4C-8C9D-8D0E432BAC38@isc.org>

If JSON::XS is not in @INC, but you know exactly where it is, just include:

use lib '/path/to/lib';

cheers. 


On Feb 8, 2013, at 11:32 AM, David Alban <extasia at extasia.org> wrote:

> greetings,
> 
> a cgi program i'm writing calls an external perl program.  when run
> from the command line, the external program runs correctly, but via
> cgi, it doesn't, complaining about not being able to find JSON.pm.
> 
> command line invocation of external program works as expected:
> 
> [root at srwd00reg011 ~]# jenkins-build-data  --help
> usage: jenkins-build-data [ options ]
> 
> options:
>  -h,--help            List usage and exit
> 
>  -b,--branch Branch      Process using branch Branch
> 
>  --list-branches      List branches that have available jenkins builds
> 
>  --list-builds        List build numbers for given branch.  Requires --branch.
> 
>  --list-artifacts     List url's for artifacts in a given build.
> Requires --branch and --build.
> 
>  -u,--build Build     Process using build number Build
> 
> then, from error_log:
> 
> [Fri Feb 08 19:19:13 2013] [error] [client 10.249.134.215] 2013-02-08
> 19:19:13 +0000 srwd00reg011
> jenkins-build-changes-from-jenkins-build-data.cgi[26068]
> PRIORITY=ERROR [*] command returned non-zero status (2); cmd =>
> 'jenkins-build-data --list-branches' ; output => 'command returned
> non-zero status; command => 'jenkins-build-data --list-branches';
> status => 2; command output => Can't locate JSON/XS.pm in @INC (@INC
> contains: /nas/reg/lib/perl/x86_64-linux-thread-multi
> /nas/reg/lib/perl/5.8.8 /nas/reg/lib/perl/5.8.5 /nas/reg/lib/perl
> /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi
> /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl
> /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl
> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8
> .) at /nas/reg/bin/jenkins-build-data line 11.
> [Fri Feb 08 19:19:13 2013] [error] [client 10.249.134.215] 2013-02-08
> 19:19:13 +0000 srwd00reg011
> jenkins-build-changes-from-jenkins-build-data.cgi[26068]
> PRIORITY=ERROR BEGIN failed--compilation aborted at
> /nas/reg/bin/jenkins-build-data line 11.
> [Fri Feb 08 19:19:13 2013] [error] [client 10.249.134.215] 2013-02-08
> 19:19:13 +0000 srwd00reg011
> jenkins-build-changes-from-jenkins-build-data.cgi[26068]
> PRIORITY=ERROR '
> [Fri Feb 08 19:19:13 2013] [error] [client 10.249.134.215] Premature
> end of script headers:
> jenkins-build-changes-from-jenkins-build-data.cgi
> [Fri Feb 08 19:19:13 2013] [error] [client 10.249.134.215] File does
> not exist: /var/www/html/favicon.ico
> 
> i get "Can't locate JSON/XS.pm in @INC".
> 
> another test:
> 
> [root at srwd00reg011 ~]# sudo -H -u apache perl
> /nas/reg/bin/jenkins-build-data --help
> Can't locate JSON/XS.pm in @INC (@INC contains:
> /nas/reg/lib/perl/x86_64-linux-thread-multi /nas/reg/lib/perl/5.8.8
> /nas/reg/lib/perl/5.8.5 /nas/reg/lib/perl
> /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi
> /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl
> /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl
> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8
> .) at /nas/reg/bin/jenkins-build-data line 11.
> BEGIN failed--compilation aborted at /nas/reg/bin/jenkins-build-data line 11.
> 
> and we have:
> 
> $ find /nas/reg/lib/perl/x86_64-linux-thread-multi/JSON/ -ls
> 3336992448    4 drwxr-sr-x   3 root     regauto      2048 Jan 19 00:48
> /nas/reg/lib/perl/x86_64-linux-thread-multi/JSON/
> 2825141390    4 drwxr-sr-x   2 root     regauto      2048 Jan 19 00:48
> /nas/reg/lib/perl/x86_64-linux-thread-multi/JSON/XS
> 1173004200    4 -r--r--r--   1 root     regauto       386 Jul  3  2007
> /nas/reg/lib/perl/x86_64-linux-thread-multi/JSON/XS/Boolean.pm
> 967325435   56 -r--r--r--   1 root     regauto     57085 Aug  1  2012
> /nas/reg/lib/perl/x86_64-linux-thread-multi/JSON/XS.pm
> 
> and:
> 
> $ find /nas/reg/lib/perl/JSON -ls
> 4275598264    4 drwxr-sr-x   3 relmgt   regauto      2048 Sep 26  2011
> /nas/reg/lib/perl/JSON
> 215538142    4 drwxr-sr-x   2 relmgt   regauto      2048 Sep 26  2011
> /nas/reg/lib/perl/JSON/PP
> 504904387    4 -r--r--r--   1 relmgt   regauto      3939 Sep 26  2011
> /nas/reg/lib/perl/JSON/PP/Compat5006.pm
> 3961032869    4 -r--r--r--   1 relmgt   regauto       425 Feb  8  2008
> /nas/reg/lib/perl/JSON/PP/Boolean.pm
> 3051093964   16 -r-xr-xr-x   1 relmgt   regauto     14104 Jul  5  2008
> /nas/reg/lib/perl/JSON/Any.pm
> 1481989354   84 -r--r--r--   1 relmgt   regauto     82227 Sep 26  2011
> /nas/reg/lib/perl/JSON/PP.pm
> 185846595    4 -r--r--r--   1 relmgt   regauto      3913 Jun  3  2008
> /nas/reg/lib/perl/JSON/PP5005.pm
> 4178796837    8 -r--r--r--   1 relmgt   regauto      4438 Jun  4  2008
> /nas/reg/lib/perl/JSON/PP56.pm
> 3956507192    4 -r--r--r--   1 relmgt   regauto      1972 Jun  4  2008
> /nas/reg/lib/perl/JSON/PP58.pm
> 
> what am i missing?
> 
> thanks,
> david
> -- 
> Live in a world of your own, but always welcome visitors.
> ***
> Rule of law is for the little people.
> http://www.amazon.com/Liberty-Justice-Some-Equality-Powerful/dp/0805092056
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm

Francisco Obispo 
Director of Applications and Services - ISC
email: fobispo at isc.org
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE


From quinn at pgexperts.com  Fri Feb  8 11:49:33 2013
From: quinn at pgexperts.com (Quinn Weaver)
Date: Fri, 8 Feb 2013 11:49:33 -0800
Subject: [sf-perl] cgi question
In-Reply-To: <4D5A5E61-9E95-4E4C-8C9D-8D0E432BAC38@isc.org>
References: <CALDD_=k6mhTM7WcSkm2GZuTnjQJjdYKoh+V8ABgqCoCTS+2VYA@mail.gmail.com>
	<4D5A5E61-9E95-4E4C-8C9D-8D0E432BAC38@isc.org>
Message-ID: <0A3144A5-890F-4B9B-A2C5-A92322530B39@pgexperts.com>

On Feb 8, 2013, at 11:45 AM, Francisco Obispo wrote:

> If JSON::XS is not in @INC, but you know exactly where it is, just include:
> 
> use lib '/path/to/lib';

That works, but it's better to put /path/to in your PERL5LIB by changing
your webserver config. That way you don't have to put 'use lib' statements
in every script you write. DRY.

Regards,

--
Quinn Weaver
PostgreSQL Experts, Inc.
http://pgexperts.com/
1-888-743-9778 (my extension: 510)


From earl at ruby.org  Fri Feb  8 12:34:05 2013
From: earl at ruby.org (Earl Ruby)
Date: Fri, 8 Feb 2013 12:34:05 -0800
Subject: [sf-perl] Maybe "Perl5" is just like "OS X"
In-Reply-To: <CAFfgvXWSqHNYkArMoLZLK_eLArBJP+9aeDN-tn9CeEWE7HwXYQ@mail.gmail.com>
References: <D1A91C53-C47C-400F-AA76-C2069974821A@imaginative-software.com>
	<CAHrynWBXjr1xKfNMcjEf8t+=cJqmdSzghix3oKTerEY_MRyxoA@mail.gmail.com>
	<CAFfgvXWSqHNYkArMoLZLK_eLArBJP+9aeDN-tn9CeEWE7HwXYQ@mail.gmail.com>
Message-ID: <CAPBkEsgnV=dZrueRcAuzHm4nkngzN3kcmtEYCZaWab7=t8n3XA@mail.gmail.com>

Alternately, Perl5's next release could be called Perl7, and the Perl6
code base could simply be renamed to PerlZ.

Numeric releases would be "production/mainstream" releases, showing
the public that Perl is moving forward, keeping the current
major/minor version numbering scheme (for packages that rely on
knowing what versions they're running for compatibility reasons).
People who want to work on porting PerlZ's features and code into
mainstream Perl# releases could keep doing so. People who want to work
on the future of Perl could still work on PerlZ with the understanding
that once PerlZ is stable then it would be assigned a number and it
would become the code base for the next "production/mainstream"
release.

Everyone wins.

On Fri, Feb 8, 2013 at 10:33 AM, Joseph Brenner <doom at kzsu.stanford.edu> wrote:
> Fred Moyer <fred at redhotpenguin.com> wrote:
>> Jeffrey Ryan Thalhammer <jeff at imaginative-software.com> wrote:
>
>>> Imagine: "Perl V Moscow" or "Perl V Sydney".  Only trouble is that "V" still seems tied to "5", more so than "X" does to 10.  But maybe that's just because I'm so used to "5".  Internally, it would still just be 5.whatever.
>>
>> Something like:
>>
>> my $num_ver = 5.16
>> my ($major, $minor) = split(/\./, $num_ver);
>> my @cities = ( qw( Athens Boston Chicago Damascus Edinburgh ... ) );
>> my $city = $cities[$minor];
>
> Yeah, I was just thinking about the Ubuntu naming scheme: in addition
> to numbers, they use animal names in alphabetic order, so you know
> that Ocelot is after Narwhal.
>
> Though I think after they started using names like "Narwhal" people
> started referring to releases by number.
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm



--
Earl Ruby
http://earlruby.org/
http://www.linkedin.com/in/earlruby
@earlruby

From extasia at extasia.org  Fri Feb  8 13:48:55 2013
From: extasia at extasia.org (David Alban)
Date: Fri, 8 Feb 2013 13:48:55 -0800
Subject: [sf-perl] cgi question
In-Reply-To: <FC5C9895-5134-4C1D-95EE-FB415238BED7@pgexperts.com>
References: <CALDD_=k6mhTM7WcSkm2GZuTnjQJjdYKoh+V8ABgqCoCTS+2VYA@mail.gmail.com>
	<FC5C9895-5134-4C1D-95EE-FB415238BED7@pgexperts.com>
Message-ID: <CALDD_==h=TosdX_19WX6dFPqbrVQZ7o3WhLcg_HjVwroj8YVZA@mail.gmail.com>

geez...   how long have i been using unix?

drwxr-sr-- 26 relmgt regauto 4096 Jan 19 00:48
/nas/reg/lib/perl/x86_64-linux-thread-multi/

solution:

$ sudo find /nas/reg/lib/perl/x86_64-linux-thread-multi -type d -exec
chmod o+x {} \;

thanks quinn.

On Fri, Feb 8, 2013 at 11:42 AM, Quinn Weaver <quinn at pgexperts.com> wrote:
> If JSON.pm is indeed in one of the directories listed for @INC, then I would check permissions. Maybe the CGI user, who is running the new perl process, doesn't have permission to read JSON.pm or its ancestor directories.

-- 
Live in a world of your own, but always welcome visitors.
***
Rule of law is for the little people.
http://www.amazon.com/Liberty-Justice-Some-Equality-Powerful/dp/0805092056

From quinn at pgexperts.com  Fri Feb  8 13:52:59 2013
From: quinn at pgexperts.com (Quinn Weaver)
Date: Fri, 8 Feb 2013 13:52:59 -0800
Subject: [sf-perl] cgi question
In-Reply-To: <CALDD_==h=TosdX_19WX6dFPqbrVQZ7o3WhLcg_HjVwroj8YVZA@mail.gmail.com>
References: <CALDD_=k6mhTM7WcSkm2GZuTnjQJjdYKoh+V8ABgqCoCTS+2VYA@mail.gmail.com>
	<FC5C9895-5134-4C1D-95EE-FB415238BED7@pgexperts.com>
	<CALDD_==h=TosdX_19WX6dFPqbrVQZ7o3WhLcg_HjVwroj8YVZA@mail.gmail.com>
Message-ID: <171418A1-6F77-4485-A986-938F48914154@pgexperts.com>

On Feb 8, 2013, at 1:48 PM, David Alban wrote:

> geez...   how long have i been using unix?
> 
> drwxr-sr-- 26 relmgt regauto 4096 Jan 19 00:48
> /nas/reg/lib/perl/x86_64-linux-thread-multi/
> 
> solution:
> 
> $ sudo find /nas/reg/lib/perl/x86_64-linux-thread-multi -type d -exec
> chmod o+x {} \;
> 
> thanks quinn.

Yay! Glad it worked.

--
Quinn Weaver
PostgreSQL Experts, Inc.
http://pgexperts.com/
1-888-743-9778 (my extension: 510)



From fred at redhotpenguin.com  Fri Feb  8 14:37:17 2013
From: fred at redhotpenguin.com (Fred Moyer)
Date: Fri, 8 Feb 2013 14:37:17 -0800
Subject: [sf-perl] Maybe "Perl5" is just like "OS X"
In-Reply-To: <CAFfgvXX32bfhVCeFtNTJ2mtdwdnOHcWCrick6oT8c+sHtPphLQ@mail.gmail.com>
References: <D1A91C53-C47C-400F-AA76-C2069974821A@imaginative-software.com>
	<CAFfgvXX32bfhVCeFtNTJ2mtdwdnOHcWCrick6oT8c+sHtPphLQ@mail.gmail.com>
Message-ID: <CAHrynWC_woWiCzR3Rx72s92jeLbRZWT34wgbK1tqoc5BjOin=A@mail.gmail.com>

On Fri, Feb 8, 2013 at 10:31 AM, Joseph Brenner <doom at kzsu.stanford.edu> wrote:
> The cat names still don't mean anything to people on the outside (like
> myself) and arguably that's what the whole issue is about, talking to
> outsiders (and convincing the insiders that they need to think about
> talking to outsiders... good luck there, eh?).

To people who use Perl casually, and to those who aren't familiar with
the versioning system, I think it makes a lot of sense. Giving the
release a name tells them that significant changes have occurred, and
shows progression through the lifetime of the major version.

How long until Perl 6? With this schema it would be right after 'Perl
V Zebulon' (or your choice of city Z). Which would correspond to the
5.26 numeric version.

From doom at kzsu.stanford.edu  Fri Feb  8 16:17:47 2013
From: doom at kzsu.stanford.edu (Joseph Brenner)
Date: Fri, 8 Feb 2013 16:17:47 -0800
Subject: [sf-perl] Maybe "Perl5" is just like "OS X"
In-Reply-To: <CAHrynWC_woWiCzR3Rx72s92jeLbRZWT34wgbK1tqoc5BjOin=A@mail.gmail.com>
References: <D1A91C53-C47C-400F-AA76-C2069974821A@imaginative-software.com>
	<CAFfgvXX32bfhVCeFtNTJ2mtdwdnOHcWCrick6oT8c+sHtPphLQ@mail.gmail.com>
	<CAHrynWC_woWiCzR3Rx72s92jeLbRZWT34wgbK1tqoc5BjOin=A@mail.gmail.com>
Message-ID: <CAFfgvXVmEa-Ek8to1bQhjauCT+UimJDP-oyeVqNPhs7JcUVZpA@mail.gmail.com>

Fred Moyer <fred at redhotpenguin.com> wrote:
>Joseph Brenner <doom at kzsu.stanford.edu> wrote:

>> The cat names still don't mean anything to people on the outside (like
>> myself) and arguably that's what the whole issue is about, talking to
>> outsiders (and convincing the insiders that they need to think about
>> talking to outsiders... good luck there, eh?).
>
> To people who use Perl casually, and to those who aren't familiar with
> the versioning system, I think it makes a lot of sense. Giving the
> release a name tells them that significant changes have occurred, and
> shows progression through the lifetime of the major version.

Well, it might very well be an improvement in some sense, but the way
the advocates for "Perl 7" usually argue it is they want a name that
conveys "Here's the Latest!" (which is one reason I think versioning
with years makes a lot of sense).

My objection to the OS X naming scheme is just that the names don't
have any implied sequence, and don't give me any feel for what the
latest is.  Like, I have a vague feeling that "Snow Leopard" is
probably pretty old at this point, because I heard people talking
about it way back, but I'd have to consult Uncle Wikipedia to know if
Cheetah came after Jaguar (or even if there was a Jaguar, which is
unlikely because of the car company).

Using city names in alphabetic sequence might be okay, but I forsee
some problems... like do you name a release "Los Angeles"?

From doomvox at gmail.com  Fri Feb  8 16:20:29 2013
From: doomvox at gmail.com (Joseph Brenner)
Date: Fri, 8 Feb 2013 16:20:29 -0800
Subject: [sf-perl] cgi question
In-Reply-To: <CALDD_==h=TosdX_19WX6dFPqbrVQZ7o3WhLcg_HjVwroj8YVZA@mail.gmail.com>
References: <CALDD_=k6mhTM7WcSkm2GZuTnjQJjdYKoh+V8ABgqCoCTS+2VYA@mail.gmail.com>
	<FC5C9895-5134-4C1D-95EE-FB415238BED7@pgexperts.com>
	<CALDD_==h=TosdX_19WX6dFPqbrVQZ7o3WhLcg_HjVwroj8YVZA@mail.gmail.com>
Message-ID: <CAFfgvXUveWkNJ2xAHWGGPHfqJ3030tg0N7NPuP2cb+sL1Dk0mw@mail.gmail.com>

David Alban <extasia at extasia.org> wrote:
> geez...   how long have i been using unix?

Probably roughly as long as I have, but unix permissions still throw
me curves.  I've got a situation right now where my crons can create a
file by redirecting output to it, but they can't actually write
anything.  There's a difference?

From rdm at cfcl.com  Fri Feb  8 18:05:47 2013
From: rdm at cfcl.com (Rich Morin)
Date: Fri, 8 Feb 2013 18:05:47 -0800
Subject: [sf-perl] cgi question
In-Reply-To: <CAFfgvXUveWkNJ2xAHWGGPHfqJ3030tg0N7NPuP2cb+sL1Dk0mw@mail.gmail.com>
References: <CALDD_=k6mhTM7WcSkm2GZuTnjQJjdYKoh+V8ABgqCoCTS+2VYA@mail.gmail.com>
	<FC5C9895-5134-4C1D-95EE-FB415238BED7@pgexperts.com>
	<CALDD_==h=TosdX_19WX6dFPqbrVQZ7o3WhLcg_HjVwroj8YVZA@mail.gmail.com>
	<CAFfgvXUveWkNJ2xAHWGGPHfqJ3030tg0N7NPuP2cb+sL1Dk0mw@mail.gmail.com>
Message-ID: <89C7824D-D2D1-4AA7-A510-FC60A5335F97@cfcl.com>

On Feb 8, 2013, at 16:20, Joseph Brenner wrote:
> David Alban <extasia at extasia.org> wrote:
>> geez...   how long have i been using unix?
> 
> Probably roughly as long as I have, but unix permissions still throw
> me curves.  I've got a situation right now where my crons can create a
> file by redirecting output to it, but they can't actually write
> anything.  There's a difference?

In order to create a file, you need write permission for the directory
it will reside in.  In order to open an existing file for writing, you
need write permission for the file.
 
-r

 -- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Software system design, development, and documentation



From rick at linuxmafia.com  Fri Feb  8 18:29:09 2013
From: rick at linuxmafia.com (Rick Moen)
Date: Fri, 8 Feb 2013 18:29:09 -0800
Subject: [sf-perl] I used to have 99 problems, now....
In-Reply-To: <20130208173206.GK2054@fetter.org>
References: <20756.38695.777731.365262@gargle.gargle.HOWL>
	<20130208173206.GK2054@fetter.org>
Message-ID: <20130209022909.GX17635@linuxmafia.com>

Quoting David Fetter (david at fetter.org):

> URL with hilarious alt-text, which is at least half the xkcd story:
> 
> https://xkcd.com/1171/

An old joke, but an endlessly serviceable one.

-- 
Cheers,             A programmer had a problem. He thought to himself, "I know,
Rick Moen           I'll solve it with threads!".  has Now problems. two he
rick at linuxmafia.com                                        -- Davidlohr Bueso 
McQ! (4x80)

From frimicc at gmail.com  Mon Feb 11 10:31:30 2013
From: frimicc at gmail.com (Michael Friedman)
Date: Mon, 11 Feb 2013 10:31:30 -0800
Subject: [sf-perl] perltidy frustration
Message-ID: <8924BF2D-D827-4E72-A921-145684B841ED@gmail.com>

I'm trying to get my new office (Polyvore.com -- we're hiring, BTW) to adopt perltidy for their existing, but complicated, code style standards. I've managed to get it relatively close, but I'm running into a wall with two particular cases. Since a number of SFPM members seem to be masters of perltidy, I wondered if anyone might have an idea of what I can try to get these to work. (My .perltidyrc is at the bottom of this email.)

Thanks for any advice!
-- Mike Friedman

First case: How do I get perltidy to line up equal signs with other equal-like things, like ||=, //=, and so on? The lining-up-of-equals doesn't seem to be controllable by any of the flags I could find. The BEFORE code is turned into the AFTER code by perltidy with my options.

BEFORE:
$params->{_default_sort} = '-count';                                                                                         
$params->{_sort_map}     = TAG_SORT;
$params->{_limit}      ||= Cons::MAX_CLEAN_TAGS;
$sql                     = _limit_order($sql, $params);

AFTER:
$params->{_default_sort} = '-count';                                                                                             
$params->{_sort_map}     = TAG_SORT;
$params->{_limit} ||= Cons::MAX_CLEAN_TAGS;
$sql = _limit_order($sql, $params);



Second case: The BEFORE code is turned into the AFTER code. The statement about 'mod_stack_layer' is arguably more readable before than after, but I can't get perltidy to not merge the lines as it does. For other reasons I'm not allowed to shorten the line length < 120 characters or to make all lists vertical. I know I could put in a format-skipping marker (#<<<  do not let perltidy touch this), but this construction occurs often enough to make that painful.

Any ideas on how I can get this to stay broken the old way? 

BEFORE:
sub render_stack {
    my ($resp, $item, $options) = @_;
    my $req = $resp->request();

    my $size = $options->{size} || 's';
    my $class = $options->{class} || '';
    my $renderer = $options->{renderer} || \&render_item;

    my $content = &$renderer($resp, $item, { size => $size });

    my $id = $options->{id} || Request::dom_unique_id();

    return $req->div({
            id => $id,
            class => "mod_stack $class size_$size",
        },
        $req->div({ class => 'mod_stack_layer' },
            $req->div({ class => 'mod_stack_layer' },
                $req->div({ class => 'mod_stack_content' }, $content),
            ),
        ),
    );
}

AFTER:
sub render_stack {
    my ($resp, $item, $options) = @_;
    my $req = $resp->request(); 
    
    my $size     = $options->{size}     || 's';
    my $class    = $options->{class}    || '';
    my $renderer = $options->{renderer} || \&render_item;
    
    my $content = &$renderer($resp, $item, { size => $size });
    
    my $id = $options->{id} || Request::dom_unique_id();                                                                        
    
    return $req->div({
            id    => $id,
            class => "mod_stack $class size_$size",
        },  
        $req->div(
            { class => 'mod_stack_layer' },
            $req->div({ class => 'mod_stack_layer' }, $req->div({ class => 'mod_stack_content' }, $content),),
        ),  
    );  
}   





.perltidyrc:
-l=120      # Max line width of 120 cols                                                                                        
-i=4        # Indent is 4 spaces
-ci=2       # Continuation indent is also 4
#-st        # Output to STDOUT
-se         # Errors to STDERR
-vt=2       # Max vertical tightness for opening blocks
-cti=0      # No extra indentation for closing brackets
-ce         # Use "cuddled" else
-bar        # Open brace always on right
-pt=2       # Max parens tightness
-bt=1       # Medium brace tightness
-bvt=0      # Min non-code-block brace tightness
-sbt=2      # Max square bracket tightness 
-bbt=1      # Medium block brace tightness
-sot        # Stack opening tokens
-sct        # Stack closing tokens
-nsfs       # No space before semicolons
-nolq       # Don't outdent long quoted strings
-nbbc       # No blank line before comment line
-msc=1      # Minimum space to trailing comment
-wbb="% + - * / x != == >= <= =~ !~ < > | & = **= += *= &= <<= &&= -= /= |= >>= ||= .= %= ^= x="
            # Break before all operators, not just the defaults


From biztos at mac.com  Mon Feb 11 15:11:53 2013
From: biztos at mac.com (Kevin Frost)
Date: Tue, 12 Feb 2013 00:11:53 +0100
Subject: [sf-perl] perltidy frustration
In-Reply-To: <8924BF2D-D827-4E72-A921-145684B841ED@gmail.com>
References: <8924BF2D-D827-4E72-A921-145684B841ED@gmail.com>
Message-ID: <9857DBB5-D7CE-4624-8380-9466B4130EC3@mac.com>

For your second example, are you worried about it merging lines on that $req->div call?

I find this pretty readable, from the latest perltidy on 5.12.3 with PBP options:

    return $req->div(
        {   id    => $id,
            class => "mod_stack $class size_$size",
        },
        $req->div(
            { class => 'mod_stack_layer' },
            $req->div(
                { class => 'mod_stack_layer' },
                $req->div( { class => 'mod_stack_content' }, $content ),
            ),
        ),
    );

So that last div() method call is not quite as bunched up.

As for your .perltidyrc, I have after many years come to the conclusion that, while I am sure I am capable of writing The World's Best Perltidyrc, so are a bunch of other people and we'd never really agree.  Thus best to use the Perl Best Practices defaults, because they are well-known and well-documented and you can spend the energy coding instead of arguing about style.  Yes, this means using some policies you may disagree with, but it's for the greater good!

You may of course disagree with that statement, but if you have control over the policies or perhaps are just laboring under some legacy prima donna's code style standards I really encourage you to give it some serious thought.

cheers

-- frosty

On Feb 11, 2013, at 7:31 PM, Michael Friedman wrote:

> I'm trying to get my new office (Polyvore.com -- we're hiring, BTW) to adopt perltidy for their existing, but complicated, code style standards. I've managed to get it relatively close, but I'm running into a wall with two particular cases. Since a number of SFPM members seem to be masters of perltidy, I wondered if anyone might have an idea of what I can try to get these to work. (My .perltidyrc is at the bottom of this email.)
> 
> Thanks for any advice!
> -- Mike Friedman
> 
> First case: How do I get perltidy to line up equal signs with other equal-like things, like ||=, //=, and so on? The lining-up-of-equals doesn't seem to be controllable by any of the flags I could find. The BEFORE code is turned into the AFTER code by perltidy with my options.
> 
> BEFORE:
> $params->{_default_sort} = '-count';                                                                                         
> $params->{_sort_map}     = TAG_SORT;
> $params->{_limit}      ||= Cons::MAX_CLEAN_TAGS;
> $sql                     = _limit_order($sql, $params);
> 
> AFTER:
> $params->{_default_sort} = '-count';                                                                                             
> $params->{_sort_map}     = TAG_SORT;
> $params->{_limit} ||= Cons::MAX_CLEAN_TAGS;
> $sql = _limit_order($sql, $params);
> 
> 
> 
> Second case: The BEFORE code is turned into the AFTER code. The statement about 'mod_stack_layer' is arguably more readable before than after, but I can't get perltidy to not merge the lines as it does. For other reasons I'm not allowed to shorten the line length < 120 characters or to make all lists vertical. I know I could put in a format-skipping marker (#<<<  do not let perltidy touch this), but this construction occurs often enough to make that painful.
> 
> Any ideas on how I can get this to stay broken the old way? 
> 
> BEFORE:
> sub render_stack {
>    my ($resp, $item, $options) = @_;
>    my $req = $resp->request();
> 
>    my $size = $options->{size} || 's';
>    my $class = $options->{class} || '';
>    my $renderer = $options->{renderer} || \&render_item;
> 
>    my $content = &$renderer($resp, $item, { size => $size });
> 
>    my $id = $options->{id} || Request::dom_unique_id();
> 
>    return $req->div({
>            id => $id,
>            class => "mod_stack $class size_$size",
>        },
>        $req->div({ class => 'mod_stack_layer' },
>            $req->div({ class => 'mod_stack_layer' },
>                $req->div({ class => 'mod_stack_content' }, $content),
>            ),
>        ),
>    );
> }
> 
> AFTER:
> sub render_stack {
>    my ($resp, $item, $options) = @_;
>    my $req = $resp->request(); 
> 
>    my $size     = $options->{size}     || 's';
>    my $class    = $options->{class}    || '';
>    my $renderer = $options->{renderer} || \&render_item;
> 
>    my $content = &$renderer($resp, $item, { size => $size });
> 
>    my $id = $options->{id} || Request::dom_unique_id();                                                                        
> 
>    return $req->div({
>            id    => $id,
>            class => "mod_stack $class size_$size",
>        },  
>        $req->div(
>            { class => 'mod_stack_layer' },
>            $req->div({ class => 'mod_stack_layer' }, $req->div({ class => 'mod_stack_content' }, $content),),
>        ),  
>    );  
> }   
> 
> 
> 
> 
> 
> .perltidyrc:
> -l=120      # Max line width of 120 cols                                                                                        
> -i=4        # Indent is 4 spaces
> -ci=2       # Continuation indent is also 4
> #-st        # Output to STDOUT
> -se         # Errors to STDERR
> -vt=2       # Max vertical tightness for opening blocks
> -cti=0      # No extra indentation for closing brackets
> -ce         # Use "cuddled" else
> -bar        # Open brace always on right
> -pt=2       # Max parens tightness
> -bt=1       # Medium brace tightness
> -bvt=0      # Min non-code-block brace tightness
> -sbt=2      # Max square bracket tightness 
> -bbt=1      # Medium block brace tightness
> -sot        # Stack opening tokens
> -sct        # Stack closing tokens
> -nsfs       # No space before semicolons
> -nolq       # Don't outdent long quoted strings
> -nbbc       # No blank line before comment line
> -msc=1      # Minimum space to trailing comment
> -wbb="% + - * / x != == >= <= =~ !~ < > | & = **= += *= &= <<= &&= -= /= |= >>= ||= .= %= ^= x="
>            # Break before all operators, not just the defaults
> 
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm


From frimicc at gmail.com  Mon Feb 11 15:16:55 2013
From: frimicc at gmail.com (Michael Friedman)
Date: Mon, 11 Feb 2013 15:16:55 -0800
Subject: [sf-perl] perltidy frustration
In-Reply-To: <9857DBB5-D7CE-4624-8380-9466B4130EC3@mac.com>
References: <8924BF2D-D827-4E72-A921-145684B841ED@gmail.com>
	<9857DBB5-D7CE-4624-8380-9466B4130EC3@mac.com>
Message-ID: <E1BD8256-ECC6-415B-8953-6CEBC4DFAC54@gmail.com>

Kevin,

I'm 100% with you. My last office used PBP style. Alas, I'm not in control of the style at my new office and have to conform to their idiosyncratic existing system. I've tried to convince them to change, but to no avail. Maybe when I've been here a bit longer I'll have more pull, but I just started a couple of months ago.

The main impediment to the PBP kind of stacking you point out is the 120 character line length. Shortening it makes the code wrap much better, to my eyes, but I'm not allowed to change that setting. Maybe I'll bring up that issue again...

Thanks,
-- Mike

On Feb 11, 2013, at 3:11 PM, Kevin Frost <biztos at mac.com> wrote:

> For your second example, are you worried about it merging lines on that $req->div call?
> 
> I find this pretty readable, from the latest perltidy on 5.12.3 with PBP options:
> 
>    return $req->div(
>        {   id    => $id,
>            class => "mod_stack $class size_$size",
>        },
>        $req->div(
>            { class => 'mod_stack_layer' },
>            $req->div(
>                { class => 'mod_stack_layer' },
>                $req->div( { class => 'mod_stack_content' }, $content ),
>            ),
>        ),
>    );
> 
> So that last div() method call is not quite as bunched up.
> 
> As for your .perltidyrc, I have after many years come to the conclusion that, while I am sure I am capable of writing The World's Best Perltidyrc, so are a bunch of other people and we'd never really agree.  Thus best to use the Perl Best Practices defaults, because they are well-known and well-documented and you can spend the energy coding instead of arguing about style.  Yes, this means using some policies you may disagree with, but it's for the greater good!
> 
> You may of course disagree with that statement, but if you have control over the policies or perhaps are just laboring under some legacy prima donna's code style standards I really encourage you to give it some serious thought.
> 
> cheers
> 
> -- frosty
> 
> On Feb 11, 2013, at 7:31 PM, Michael Friedman wrote:
> 
>> I'm trying to get my new office (Polyvore.com -- we're hiring, BTW) to adopt perltidy for their existing, but complicated, code style standards. I've managed to get it relatively close, but I'm running into a wall with two particular cases. Since a number of SFPM members seem to be masters of perltidy, I wondered if anyone might have an idea of what I can try to get these to work. (My .perltidyrc is at the bottom of this email.)
>> 
>> Thanks for any advice!
>> -- Mike Friedman
>> 
>> First case: How do I get perltidy to line up equal signs with other equal-like things, like ||=, //=, and so on? The lining-up-of-equals doesn't seem to be controllable by any of the flags I could find. The BEFORE code is turned into the AFTER code by perltidy with my options.
>> 
>> BEFORE:
>> $params->{_default_sort} = '-count';                                                                                         
>> $params->{_sort_map}     = TAG_SORT;
>> $params->{_limit}      ||= Cons::MAX_CLEAN_TAGS;
>> $sql                     = _limit_order($sql, $params);
>> 
>> AFTER:
>> $params->{_default_sort} = '-count';                                                                                             
>> $params->{_sort_map}     = TAG_SORT;
>> $params->{_limit} ||= Cons::MAX_CLEAN_TAGS;
>> $sql = _limit_order($sql, $params);
>> 
>> 
>> 
>> Second case: The BEFORE code is turned into the AFTER code. The statement about 'mod_stack_layer' is arguably more readable before than after, but I can't get perltidy to not merge the lines as it does. For other reasons I'm not allowed to shorten the line length < 120 characters or to make all lists vertical. I know I could put in a format-skipping marker (#<<<  do not let perltidy touch this), but this construction occurs often enough to make that painful.
>> 
>> Any ideas on how I can get this to stay broken the old way? 
>> 
>> BEFORE:
>> sub render_stack {
>>   my ($resp, $item, $options) = @_;
>>   my $req = $resp->request();
>> 
>>   my $size = $options->{size} || 's';
>>   my $class = $options->{class} || '';
>>   my $renderer = $options->{renderer} || \&render_item;
>> 
>>   my $content = &$renderer($resp, $item, { size => $size });
>> 
>>   my $id = $options->{id} || Request::dom_unique_id();
>> 
>>   return $req->div({
>>           id => $id,
>>           class => "mod_stack $class size_$size",
>>       },
>>       $req->div({ class => 'mod_stack_layer' },
>>           $req->div({ class => 'mod_stack_layer' },
>>               $req->div({ class => 'mod_stack_content' }, $content),
>>           ),
>>       ),
>>   );
>> }
>> 
>> AFTER:
>> sub render_stack {
>>   my ($resp, $item, $options) = @_;
>>   my $req = $resp->request(); 
>> 
>>   my $size     = $options->{size}     || 's';
>>   my $class    = $options->{class}    || '';
>>   my $renderer = $options->{renderer} || \&render_item;
>> 
>>   my $content = &$renderer($resp, $item, { size => $size });
>> 
>>   my $id = $options->{id} || Request::dom_unique_id();                                                                        
>> 
>>   return $req->div({
>>           id    => $id,
>>           class => "mod_stack $class size_$size",
>>       },  
>>       $req->div(
>>           { class => 'mod_stack_layer' },
>>           $req->div({ class => 'mod_stack_layer' }, $req->div({ class => 'mod_stack_content' }, $content),),
>>       ),  
>>   );  
>> }   
>> 
>> 
>> 
>> 
>> 
>> .perltidyrc:
>> -l=120      # Max line width of 120 cols                                                                                        
>> -i=4        # Indent is 4 spaces
>> -ci=2       # Continuation indent is also 4
>> #-st        # Output to STDOUT
>> -se         # Errors to STDERR
>> -vt=2       # Max vertical tightness for opening blocks
>> -cti=0      # No extra indentation for closing brackets
>> -ce         # Use "cuddled" else
>> -bar        # Open brace always on right
>> -pt=2       # Max parens tightness
>> -bt=1       # Medium brace tightness
>> -bvt=0      # Min non-code-block brace tightness
>> -sbt=2      # Max square bracket tightness 
>> -bbt=1      # Medium block brace tightness
>> -sot        # Stack opening tokens
>> -sct        # Stack closing tokens
>> -nsfs       # No space before semicolons
>> -nolq       # Don't outdent long quoted strings
>> -nbbc       # No blank line before comment line
>> -msc=1      # Minimum space to trailing comment
>> -wbb="% + - * / x != == >= <= =~ !~ < > | & = **= += *= &= <<= &&= -= /= |= >>= ||= .= %= ^= x="
>>           # Break before all operators, not just the defaults
>> 
>> _______________________________________________
>> SanFrancisco-pm mailing list
>> SanFrancisco-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
> 


From biztos at mac.com  Mon Feb 11 15:30:18 2013
From: biztos at mac.com (Kevin Frost)
Date: Tue, 12 Feb 2013 00:30:18 +0100
Subject: [sf-perl] perltidy frustration
In-Reply-To: <E1BD8256-ECC6-415B-8953-6CEBC4DFAC54@gmail.com>
References: <8924BF2D-D827-4E72-A921-145684B841ED@gmail.com>
	<9857DBB5-D7CE-4624-8380-9466B4130EC3@mac.com>
	<E1BD8256-ECC6-415B-8953-6CEBC4DFAC54@gmail.com>
Message-ID: <6BD36742-7B0D-484D-90EF-D1FBB964A3FB@mac.com>

FWIW YMMV and all that, but: my main argument, separate from PBP, for a 78-char line width has always been this:

There *will* be situations where you are studying code *diffs* in narrow and/or unpredictable-width environments.

The most common are:

* Overhead projectors.

* E-mails.

* Printouts.

If you go with 78 characters you have 80 including the diffing symbol and space, you have a very good chance of having legible and consistent output in the different environments.

Granted, this argument is equally applicable to 77 and 81 character widths, but 80 (with diff) is just easier to remember, at least for anyone over a certain age.  As an exact number it is arbitrary, but as a ballpark figure (really, within a couple characters) it is not at all arbitrary.

Damian's version of the argument goes like this, as you probably already know:

> In these modern days of high-resolution 30-inch screens, anti-aliased fonts, and laser eyesight correction, it's entirely possible to program in a terminal window that's 300 columns wide.
> 
> Please don't.
> 
> Given the limitations of printed documents, legacy VGA display devices, presentation software, and unreconstructed managerial optics, it isn't reasonable to format code to a width greater than 80 columns. And even an 80-column line width is not always safe, given the text-wrapping characteristics of some terminals, editors, and mail systems.
> 
> Setting your right margin at 78 columns maximizes the usable width of each code line whilst ensuring that those lines appear consistently on the vast majority of display devices.

If you haven't tried the diff-reviewing argument you might want to.  I think it would be pretty easy to show why 78 beats 120 in that context.

Or you might want to just suffer through the existing standards until you have more clout. ;-)

cheers

-- f.




On Feb 12, 2013, at 12:16 AM, Michael Friedman wrote:

> Kevin,
> 
> I'm 100% with you. My last office used PBP style. Alas, I'm not in control of the style at my new office and have to conform to their idiosyncratic existing system. I've tried to convince them to change, but to no avail. Maybe when I've been here a bit longer I'll have more pull, but I just started a couple of months ago.
> 
> The main impediment to the PBP kind of stacking you point out is the 120 character line length. Shortening it makes the code wrap much better, to my eyes, but I'm not allowed to change that setting. Maybe I'll bring up that issue again...
> 
> Thanks,
> -- Mike
> 
> On Feb 11, 2013, at 3:11 PM, Kevin Frost <biztos at mac.com> wrote:
> 
>> For your second example, are you worried about it merging lines on that $req->div call?
>> 
>> I find this pretty readable, from the latest perltidy on 5.12.3 with PBP options:
>> 
>>   return $req->div(
>>       {   id    => $id,
>>           class => "mod_stack $class size_$size",
>>       },
>>       $req->div(
>>           { class => 'mod_stack_layer' },
>>           $req->div(
>>               { class => 'mod_stack_layer' },
>>               $req->div( { class => 'mod_stack_content' }, $content ),
>>           ),
>>       ),
>>   );
>> 
>> So that last div() method call is not quite as bunched up.
>> 
>> As for your .perltidyrc, I have after many years come to the conclusion that, while I am sure I am capable of writing The World's Best Perltidyrc, so are a bunch of other people and we'd never really agree.  Thus best to use the Perl Best Practices defaults, because they are well-known and well-documented and you can spend the energy coding instead of arguing about style.  Yes, this means using some policies you may disagree with, but it's for the greater good!
>> 
>> You may of course disagree with that statement, but if you have control over the policies or perhaps are just laboring under some legacy prima donna's code style standards I really encourage you to give it some serious thought.
>> 
>> cheers
>> 
>> -- frosty
>> 
>> On Feb 11, 2013, at 7:31 PM, Michael Friedman wrote:
>> 
>>> I'm trying to get my new office (Polyvore.com -- we're hiring, BTW) to adopt perltidy for their existing, but complicated, code style standards. I've managed to get it relatively close, but I'm running into a wall with two particular cases. Since a number of SFPM members seem to be masters of perltidy, I wondered if anyone might have an idea of what I can try to get these to work. (My .perltidyrc is at the bottom of this email.)
>>> 
>>> Thanks for any advice!
>>> -- Mike Friedman
>>> 
>>> First case: How do I get perltidy to line up equal signs with other equal-like things, like ||=, //=, and so on? The lining-up-of-equals doesn't seem to be controllable by any of the flags I could find. The BEFORE code is turned into the AFTER code by perltidy with my options.
>>> 
>>> BEFORE:
>>> $params->{_default_sort} = '-count';                                                                                         
>>> $params->{_sort_map}     = TAG_SORT;
>>> $params->{_limit}      ||= Cons::MAX_CLEAN_TAGS;
>>> $sql                     = _limit_order($sql, $params);
>>> 
>>> AFTER:
>>> $params->{_default_sort} = '-count';                                                                                             
>>> $params->{_sort_map}     = TAG_SORT;
>>> $params->{_limit} ||= Cons::MAX_CLEAN_TAGS;
>>> $sql = _limit_order($sql, $params);
>>> 
>>> 
>>> 
>>> Second case: The BEFORE code is turned into the AFTER code. The statement about 'mod_stack_layer' is arguably more readable before than after, but I can't get perltidy to not merge the lines as it does. For other reasons I'm not allowed to shorten the line length < 120 characters or to make all lists vertical. I know I could put in a format-skipping marker (#<<<  do not let perltidy touch this), but this construction occurs often enough to make that painful.
>>> 
>>> Any ideas on how I can get this to stay broken the old way? 
>>> 
>>> BEFORE:
>>> sub render_stack {
>>>  my ($resp, $item, $options) = @_;
>>>  my $req = $resp->request();
>>> 
>>>  my $size = $options->{size} || 's';
>>>  my $class = $options->{class} || '';
>>>  my $renderer = $options->{renderer} || \&render_item;
>>> 
>>>  my $content = &$renderer($resp, $item, { size => $size });
>>> 
>>>  my $id = $options->{id} || Request::dom_unique_id();
>>> 
>>>  return $req->div({
>>>          id => $id,
>>>          class => "mod_stack $class size_$size",
>>>      },
>>>      $req->div({ class => 'mod_stack_layer' },
>>>          $req->div({ class => 'mod_stack_layer' },
>>>              $req->div({ class => 'mod_stack_content' }, $content),
>>>          ),
>>>      ),
>>>  );
>>> }
>>> 
>>> AFTER:
>>> sub render_stack {
>>>  my ($resp, $item, $options) = @_;
>>>  my $req = $resp->request(); 
>>> 
>>>  my $size     = $options->{size}     || 's';
>>>  my $class    = $options->{class}    || '';
>>>  my $renderer = $options->{renderer} || \&render_item;
>>> 
>>>  my $content = &$renderer($resp, $item, { size => $size });
>>> 
>>>  my $id = $options->{id} || Request::dom_unique_id();                                                                        
>>> 
>>>  return $req->div({
>>>          id    => $id,
>>>          class => "mod_stack $class size_$size",
>>>      },  
>>>      $req->div(
>>>          { class => 'mod_stack_layer' },
>>>          $req->div({ class => 'mod_stack_layer' }, $req->div({ class => 'mod_stack_content' }, $content),),
>>>      ),  
>>>  );  
>>> }   
>>> 
>>> 
>>> 
>>> 
>>> 
>>> .perltidyrc:
>>> -l=120      # Max line width of 120 cols                                                                                        
>>> -i=4        # Indent is 4 spaces
>>> -ci=2       # Continuation indent is also 4
>>> #-st        # Output to STDOUT
>>> -se         # Errors to STDERR
>>> -vt=2       # Max vertical tightness for opening blocks
>>> -cti=0      # No extra indentation for closing brackets
>>> -ce         # Use "cuddled" else
>>> -bar        # Open brace always on right
>>> -pt=2       # Max parens tightness
>>> -bt=1       # Medium brace tightness
>>> -bvt=0      # Min non-code-block brace tightness
>>> -sbt=2      # Max square bracket tightness 
>>> -bbt=1      # Medium block brace tightness
>>> -sot        # Stack opening tokens
>>> -sct        # Stack closing tokens
>>> -nsfs       # No space before semicolons
>>> -nolq       # Don't outdent long quoted strings
>>> -nbbc       # No blank line before comment line
>>> -msc=1      # Minimum space to trailing comment
>>> -wbb="% + - * / x != == >= <= =~ !~ < > | & = **= += *= &= <<= &&= -= /= |= >>= ||= .= %= ^= x="
>>>          # Break before all operators, not just the defaults
>>> 
>>> _______________________________________________
>>> SanFrancisco-pm mailing list
>>> SanFrancisco-pm at pm.org
>>> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>> 
> 


From josh at agliodbs.com  Mon Feb 11 17:09:40 2013
From: josh at agliodbs.com (Josh Berkus)
Date: Mon, 11 Feb 2013 17:09:40 -0800
Subject: [sf-perl] Looking for passenger for SCALE
Message-ID: <51199654.5080300@agliodbs.com>

Folks,

As usual, I'm driving down to SCALE and the pgDay there.  I'm looking
for a passenger to ride with me.  I don't want you to pay gas, or even
drive; I just want someone to help keep me awake and change CDs.

Ping me offlist if you want to go to pgDay LA and SCALE, and save
yourself some plane fare.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

From earl at ruby.org  Fri Feb 15 15:58:11 2013
From: earl at ruby.org (Earl Ruby)
Date: Fri, 15 Feb 2013 15:58:11 -0800
Subject: [sf-perl] Unusual Perl "feature"
Message-ID: <CAPBkEsia8FgP5kj_jXQyX+sU-EGLt07GyZRR1rgcKFyMbZOs1w@mail.gmail.com>

I made a typo and found a new feature.

I have no idea what this feature is for:

> perl -e 'use strict; my $name = - "NAME"; print "$name\n"; print "Perl prepended a minus sign to my string\n" if $name eq "-NAME";'
-NAME
Perl prepended a minus sign to my string

Interesting behavior. Can anyone give me an example of what is this used for?

--
Earl Ruby
http://earlruby.org/
http://www.linkedin.com/in/earlruby
@earlruby

From kvale at phy.ucsf.edu  Fri Feb 15 16:14:25 2013
From: kvale at phy.ucsf.edu (Mark Kvale)
Date: Fri, 15 Feb 2013 16:14:25 -0800
Subject: [sf-perl] Unusual Perl "feature"
In-Reply-To: <CAPBkEsia8FgP5kj_jXQyX+sU-EGLt07GyZRR1rgcKFyMbZOs1w@mail.gmail.com>
References: <CAPBkEsia8FgP5kj_jXQyX+sU-EGLt07GyZRR1rgcKFyMbZOs1w@mail.gmail.com>
Message-ID: <511ECF61.1020903@phy.ucsf.edu>

On 02/15/2013 03:58 PM, Earl Ruby wrote:
> I made a typo and found a new feature.
>
> I have no idea what this feature is for:
>
>> perl -e 'use strict; my $name = - "NAME"; print "$name\n"; print "Perl prepended a minus sign to my string\n" if $name eq "-NAME";'
> -NAME
> Perl prepended a minus sign to my string
>
> Interesting behavior. Can anyone give me an example of what is this used for?
>
> --
> Earl Ruby
> http://earlruby.org/
> http://www.linkedin.com/in/earlruby
> @earlruby
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>

This is documented behavior; see

http://perldoc.perl.org/perlop.html#Symbolic-Unary-Operators

My guess on use? As the man says, '-bareword is equivalent to the string 
"-bareword"', allowing for fat comma keys without needing quotes, e.g.

(-bareword => 1, -title => 2)


Mark

From quinn at pgexperts.com  Sun Feb 17 18:40:41 2013
From: quinn at pgexperts.com (Quinn Weaver)
Date: Sun, 17 Feb 2013 18:40:41 -0800
Subject: [sf-perl] Unusual Perl "feature"
In-Reply-To: <511ECF61.1020903@phy.ucsf.edu>
References: <CAPBkEsia8FgP5kj_jXQyX+sU-EGLt07GyZRR1rgcKFyMbZOs1w@mail.gmail.com>
	<511ECF61.1020903@phy.ucsf.edu>
Message-ID: <F1AF1CE7-F07E-475E-9D72-484A86FE1D5A@pgexperts.com>

On Feb 15, 2013, at 4:14 PM, Mark Kvale wrote:

> This is documented behavior; see
> 
> http://perldoc.perl.org/perlop.html#Symbolic-Unary-Operators
> 
> My guess on use? As the man says, '-bareword is equivalent to the string "-bareword"', allowing for fat comma keys without needing quotes, e.g.
> 
> (-bareword => 1, -title => 2)

But you don't need to quote keys anyway. This feature must exist for some other reason.

Perl is like hobbits, to paraphrase Gabdalf: you can know it for years, and yet still it can surprise you. :)

Regards,

--
Quinn Weaver
PostgreSQL Experts, Inc.
http://pgexperts.com/
1-888-743-9778 (my extension: 510)



From doherty at cs.dal.ca  Sun Feb 17 18:50:14 2013
From: doherty at cs.dal.ca (Mike Doherty)
Date: Sun, 17 Feb 2013 22:50:14 -0400
Subject: [sf-perl] Unusual Perl "feature"
In-Reply-To: <F1AF1CE7-F07E-475E-9D72-484A86FE1D5A@pgexperts.com>
References: <CAPBkEsia8FgP5kj_jXQyX+sU-EGLt07GyZRR1rgcKFyMbZOs1w@mail.gmail.com>
	<511ECF61.1020903@phy.ucsf.edu>
	<F1AF1CE7-F07E-475E-9D72-484A86FE1D5A@pgexperts.com>
Message-ID: <512196E6.5090702@cs.dal.ca>

It also lets you flip the sign of the string:

perl -E 'say -$_ for qw( test -test +test )'

Why you would want to, I've no idea.

-Mike Doherty

From el.dodgero at gmail.com  Tue Feb 19 03:11:50 2013
From: el.dodgero at gmail.com (Sean Dodger Cannon)
Date: Tue, 19 Feb 2013 03:11:50 -0800
Subject: [sf-perl] Unusual Perl "feature"
In-Reply-To: <511ECF61.1020903@phy.ucsf.edu>
References: <CAPBkEsia8FgP5kj_jXQyX+sU-EGLt07GyZRR1rgcKFyMbZOs1w@mail.gmail.com>
	<511ECF61.1020903@phy.ucsf.edu>
Message-ID: <CAGRpCMTyWSxMw10AviVv47jDGL_iJzB6Lr6rPexT9hrhXUmd-Q@mail.gmail.com>

Technically those aren't barewords in your example. Everything on the
left of a => is implicitly double quotish.

On 15 February 2013 16:14, Mark Kvale <kvale at phy.ucsf.edu> wrote:
> On 02/15/2013 03:58 PM, Earl Ruby wrote:
>>
>> I made a typo and found a new feature.
>>
>> I have no idea what this feature is for:
>>
>>> perl -e 'use strict; my $name = - "NAME"; print "$name\n"; print "Perl
>>> prepended a minus sign to my string\n" if $name eq "-NAME";'
>>
>> -NAME
>> Perl prepended a minus sign to my string
>>
>> Interesting behavior. Can anyone give me an example of what is this used
>> for?
>>
>> --
>> Earl Ruby
>> http://earlruby.org/
>> http://www.linkedin.com/in/earlruby
>> @earlruby
>> _______________________________________________
>> SanFrancisco-pm mailing list
>> SanFrancisco-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>>
>
> This is documented behavior; see
>
> http://perldoc.perl.org/perlop.html#Symbolic-Unary-Operators
>
> My guess on use? As the man says, '-bareword is equivalent to the string
> "-bareword"', allowing for fat comma keys without needing quotes, e.g.
>
> (-bareword => 1, -title => 2)
>
>
> Mark
>
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm



-- 
Sean "Dodger" Cannon

From doom at kzsu.stanford.edu  Tue Feb 19 07:58:39 2013
From: doom at kzsu.stanford.edu (Joseph Brenner)
Date: Tue, 19 Feb 2013 07:58:39 -0800
Subject: [sf-perl] Unusual Perl "feature"
In-Reply-To: <CAGRpCMTyWSxMw10AviVv47jDGL_iJzB6Lr6rPexT9hrhXUmd-Q@mail.gmail.com>
References: <CAPBkEsia8FgP5kj_jXQyX+sU-EGLt07GyZRR1rgcKFyMbZOs1w@mail.gmail.com>
	<511ECF61.1020903@phy.ucsf.edu>
	<CAGRpCMTyWSxMw10AviVv47jDGL_iJzB6Lr6rPexT9hrhXUmd-Q@mail.gmail.com>
Message-ID: <CAFfgvXVcaSqvGtoLTWMytBGpntUJ=iJjs7u+Bm5Uu6j+uHY=+w@mail.gmail.com>

Sean Dodger Cannon <el.dodgero at gmail.com> wrote:
> Technically those aren't barewords in your example. Everything on the
> left of a => is implicitly double quotish.

Really?

  my $suffix = 'alpha';
  my %fried =
    ( name => 'okonomiyaki',
      mystery_field_$suffix => 'tonkatsu',
      );

    # Can't locate object method "mystery_field_" via package "alpha"
(perhaps you forgot to load "alpha"?) at
/home/doom/bin/testes-double_quotish_to_left_of_fat_comma line 56.



> Mark Kvale <kvale at phy.ucsf.edu> wrote:
>>  Earl Ruby wrote:
>>>
>>> I made a typo and found a new feature.
>>>
>>> I have no idea what this feature is for:
>>>
>>>> perl -e 'use strict; my $name = - "NAME"; print "$name\n"; print "Perl
>>>> prepended a minus sign to my string\n" if $name eq "-NAME";'
>>>
>>> -NAME
>>> Perl prepended a minus sign to my string
>>>
>>> Interesting behavior. Can anyone give me an example of what is this used
>>> for?
>>
>> This is documented behavior; see
>>
>> http://perldoc.perl.org/perlop.html#Symbolic-Unary-Operators
>>
>> My guess on use? As the man says, '-bareword is equivalent to the string
>> "-bareword"', allowing for fat comma keys without needing quotes, e.g.
>>
>> (-bareword => 1, -title => 2)

From kvale at phy.ucsf.edu  Tue Feb 19 08:51:19 2013
From: kvale at phy.ucsf.edu (Mark Kvale)
Date: Tue, 19 Feb 2013 08:51:19 -0800
Subject: [sf-perl] Unusual Perl "feature"
In-Reply-To: <F1AF1CE7-F07E-475E-9D72-484A86FE1D5A@pgexperts.com>
References: <CAPBkEsia8FgP5kj_jXQyX+sU-EGLt07GyZRR1rgcKFyMbZOs1w@mail.gmail.com>
	<511ECF61.1020903@phy.ucsf.edu>
	<F1AF1CE7-F07E-475E-9D72-484A86FE1D5A@pgexperts.com>
Message-ID: <5123AD87.3080902@phy.ucsf.edu>

On 02/17/2013 06:40 PM, Quinn Weaver wrote:
> On Feb 15, 2013, at 4:14 PM, Mark Kvale wrote:
>
>> This is documented behavior; see
>>
>> http://perldoc.perl.org/perlop.html#Symbolic-Unary-Operators
>>
>> My guess on use? As the man says, '-bareword is equivalent to the
>> string "-bareword"', allowing for fat comma keys without needing
>> quotes, e.g.
>>
>> (-bareword => 1, -title => 2)
>
> But you don't need to quote keys anyway. This feature must exist for
> some other reason.
>
> Perl is like hobbits, to paraphrase Gabdalf: you can know it for
> years, and yet still it can surprise you. :)
>
> Regards,
>
> -- Quinn Weaver PostgreSQL Experts, Inc. http://pgexperts.com/
> 1-888-743-9778 (my extension: 510)

Sorry for not being clear. You do need the quotes if you want a leading 
'-', unless there is a special rule. From perlop, comma 
(http://perldoc.perl.org/perlop.html#Comma-Operator):

"The => operator is a synonym for the comma except that it causes a word 
on its left to be interpreted as a string if it begins with a letter or 
underscore and is composed only of letters, digits and underscores."

My guess is that the interpreter sees -title as '-' and 'title', 
converts 'title' to a string because it starts with a letter, then 
prepends '-' to the string according to the special rule.

Regards,
Mark




From uri at stemsystems.com  Mon Feb 18 13:09:11 2013
From: uri at stemsystems.com (Uri Guttman)
Date: Mon, 18 Feb 2013 16:09:11 -0500
Subject: [sf-perl] Unusual Perl "feature"
In-Reply-To: <F1AF1CE7-F07E-475E-9D72-484A86FE1D5A@pgexperts.com>
References: <CAPBkEsia8FgP5kj_jXQyX+sU-EGLt07GyZRR1rgcKFyMbZOs1w@mail.gmail.com>
	<511ECF61.1020903@phy.ucsf.edu>
	<F1AF1CE7-F07E-475E-9D72-484A86FE1D5A@pgexperts.com>
Message-ID: <51229877.80105@stemsystems.com>

On 02/17/2013 09:40 PM, Quinn Weaver wrote:
> On Feb 15, 2013, at 4:14 PM, Mark Kvale wrote:
>
>> This is documented behavior; see
>>
>> http://perldoc.perl.org/perlop.html#Symbolic-Unary-Operators
>>
>> My guess on use? As the man says, '-bareword is equivalent to the string "-bareword"', allowing for fat comma keys without needing quotes, e.g.
>>
>> (-bareword => 1, -title => 2)
>
> But you don't need to quote keys anyway. This feature must exist for some other reason.
>

it was allowed because of perl/tk where all the keys (as in regular tk) 
are -foo style. so perl allows barewords of -foo to be autoquoted by =>. 
  this also allowed the - prefix to be a simple prefix - to the string 
op which is useful for those types of keys.

uri

From uri at stemsystems.com  Tue Feb 19 09:39:20 2013
From: uri at stemsystems.com (Uri Guttman)
Date: Tue, 19 Feb 2013 12:39:20 -0500
Subject: [sf-perl] Unusual Perl "feature"
In-Reply-To: <5123AD87.3080902@phy.ucsf.edu>
References: <CAPBkEsia8FgP5kj_jXQyX+sU-EGLt07GyZRR1rgcKFyMbZOs1w@mail.gmail.com>
	<511ECF61.1020903@phy.ucsf.edu>
	<F1AF1CE7-F07E-475E-9D72-484A86FE1D5A@pgexperts.com>
	<5123AD87.3080902@phy.ucsf.edu>
Message-ID: <5123B8C8.1080402@stemsystems.com>

someone asked why the prefix - was allowed in => word quoting. there is 
a strong reason and history for this. it comes from perl/tk (even back 
in perl4 days before the => existed). keys in perl/tk are all prefixed 
by - as is the case with some other apis. not as common anymore but it 
was common enough that prefix - was just a way to put a leading - on a 
string. - 'foo' is the same as '-foo'. and when => came into perl and it 
autoquoted barewords on its left side, it also allowed those words to 
have a prefix -. so you can always do this:

	-foo	=> 1,
	-bar	=> 3,

same as quoting the left sides.

uri


From quinn at pgexperts.com  Tue Feb 19 10:09:16 2013
From: quinn at pgexperts.com (Quinn Weaver)
Date: Tue, 19 Feb 2013 10:09:16 -0800
Subject: [sf-perl] Unusual Perl "feature"
In-Reply-To: <51229877.80105@stemsystems.com>
References: <CAPBkEsia8FgP5kj_jXQyX+sU-EGLt07GyZRR1rgcKFyMbZOs1w@mail.gmail.com>
	<511ECF61.1020903@phy.ucsf.edu>
	<F1AF1CE7-F07E-475E-9D72-484A86FE1D5A@pgexperts.com>
	<51229877.80105@stemsystems.com>
Message-ID: <1E0E4042-48CA-439E-B8B6-9A2C1640F131@pgexperts.com>

Nice catch! That makes total sense. I wrote a Perl/Tk app once, but I'd forgotten all about the -key convention. It Just Worked, so I never really thought about it. DWIM for the win.

--
Quinn Weaver
PostgreSQL Experts, Inc.  http://pgexperts.com/
1-888-743-9778 (my extension: 510)
Sent from my phone; pardon my brevity.

On Feb 18, 2013, at 1:09 PM, Uri Guttman <uri at stemsystems.com> wrote:

> On 02/17/2013 09:40 PM, Quinn Weaver wrote:
>> On Feb 15, 2013, at 4:14 PM, Mark Kvale wrote:
>> 
>>> This is documented behavior; see
>>> 
>>> http://perldoc.perl.org/perlop.html#Symbolic-Unary-Operators
>>> 
>>> My guess on use? As the man says, '-bareword is equivalent to the string "-bareword"', allowing for fat comma keys without needing quotes, e.g.
>>> 
>>> (-bareword => 1, -title => 2)
>> 
>> But you don't need to quote keys anyway. This feature must exist for some other reason.
> 
> it was allowed because of perl/tk where all the keys (as in regular tk) are -foo style. so perl allows barewords of -foo to be autoquoted by =>.  this also allowed the - prefix to be a simple prefix - to the string op which is useful for those types of keys.
> 
> uri
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm

From fred at redhotpenguin.com  Wed Feb 20 11:11:24 2013
From: fred at redhotpenguin.com (Fred Moyer)
Date: Wed, 20 Feb 2013 11:11:24 -0800
Subject: [sf-perl] [meeting] Module show and tell
In-Reply-To: <CAHrynWDX8UWq-hWszGAQSp0WqyB-Ut3=HoDXFpUpL2FV_UoU5g@mail.gmail.com>
References: <CAHrynWDX8UWq-hWszGAQSp0WqyB-Ut3=HoDXFpUpL2FV_UoU5g@mail.gmail.com>
Message-ID: <CAHrynWAks7KA-TMtVR4ptbiXGTOqBO=RxQLHGwQgut4_rm_R+A@mail.gmail.com>

Just a reminder to come eat Paxti's pizza next Tuesday and talk about
Perl modules next Tuesday. We have 8 rsvp spots remaining, and I
expect we'll fill all of them before Tuesday.

http://www.meetup.com/San-Francisco-Perl-Mongers/events/102582122/

On Sat, Feb 2, 2013 at 4:04 PM, Fred Moyer <fred at redhotpenguin.com> wrote:
> Come eat pizza at Craigslist on Tuesday, February 26, 2013 at 7pm and
> give a show and tell presentation of your favorite module.
>
> Suggest making your presentation web accessible, bringing a laptop
> with a VGA compatible connector, or be able to hop onto a terminal
> window for a laptop hooked to the projector and take it from there.
> Hope to see you there!
>
> http://www.meetup.com/San-Francisco-Perl-Mongers/events/102582122

From doom at kzsu.stanford.edu  Wed Feb 20 11:20:26 2013
From: doom at kzsu.stanford.edu (Joseph Brenner)
Date: Wed, 20 Feb 2013 11:20:26 -0800
Subject: [sf-perl] [meeting] Module show and tell
In-Reply-To: <CAHrynWAks7KA-TMtVR4ptbiXGTOqBO=RxQLHGwQgut4_rm_R+A@mail.gmail.com>
References: <CAHrynWDX8UWq-hWszGAQSp0WqyB-Ut3=HoDXFpUpL2FV_UoU5g@mail.gmail.com>
	<CAHrynWAks7KA-TMtVR4ptbiXGTOqBO=RxQLHGwQgut4_rm_R+A@mail.gmail.com>
Message-ID: <CAFfgvXUwhPyrO23CY4x9O5QqZgqzK1FkUjUDV7-xTnrtfe6XPw@mail.gmail.com>

Fred Moyer <fred at redhotpenguin.com> wrote:
> Just a reminder to come eat Paxti's pizza next Tuesday and talk about
> Perl modules next Tuesday. We have 8 rsvp spots remaining, and I
> expect we'll fill all of them before Tuesday.

Indeed, and I just wanted to ask folks who are planning on talking
about their favorite modules to send me a note...  I think we may have
a few timeslots open and I'd like to know if I should be doing some
recruiting.

But then,  I suspect we'll have some volunteers on-the-spot... (it's
difficult to prevent perl programmers from talking about modules).



Fred Moyer <fred at redhotpenguin.com> wrote:
> Just a reminder to come eat Paxti's pizza next Tuesday and talk about
> Perl modules next Tuesday. We have 8 rsvp spots remaining, and I
> expect we'll fill all of them before Tuesday.
>
> http://www.meetup.com/San-Francisco-Perl-Mongers/events/102582122/
>
> Fred Moyer <fred at redhotpenguin.com> wrote:
>> Come eat pizza at Craigslist on Tuesday, February 26, 2013 at 7pm and
>> give a show and tell presentation of your favorite module.
>>
>> Suggest making your presentation web accessible, bringing a laptop
>> with a VGA compatible connector, or be able to hop onto a terminal
>> window for a laptop hooked to the projector and take it from there.
>> Hope to see you there!
>>
>> http://www.meetup.com/San-Francisco-Perl-Mongers/events/102582122

From earl at ruby.org  Sat Feb 23 14:23:56 2013
From: earl at ruby.org (Earl Ruby)
Date: Sat, 23 Feb 2013 14:23:56 -0800
Subject: [sf-perl] Unusual Perl "feature"
In-Reply-To: <1E0E4042-48CA-439E-B8B6-9A2C1640F131@pgexperts.com>
References: <CAPBkEsia8FgP5kj_jXQyX+sU-EGLt07GyZRR1rgcKFyMbZOs1w@mail.gmail.com>
	<511ECF61.1020903@phy.ucsf.edu>
	<F1AF1CE7-F07E-475E-9D72-484A86FE1D5A@pgexperts.com>
	<51229877.80105@stemsystems.com>
	<1E0E4042-48CA-439E-B8B6-9A2C1640F131@pgexperts.com>
Message-ID: <CAPBkEshZYh0o7W_2_=8C9WOUtLSWnOoEcegcxg4TuganmpzsNg@mail.gmail.com>

While this is all interesting, I wasn't using the => operator in the
example I gave, just =


On Tue, Feb 19, 2013 at 10:09 AM, Quinn Weaver <quinn at pgexperts.com> wrote:
> Nice catch! That makes total sense. I wrote a Perl/Tk app once, but I'd forgotten all about the -key convention. It Just Worked, so I never really thought about it. DWIM for the win.
>
> --
> Quinn Weaver
> PostgreSQL Experts, Inc.  http://pgexperts.com/
> 1-888-743-9778 (my extension: 510)
> Sent from my phone; pardon my brevity.
>
> On Feb 18, 2013, at 1:09 PM, Uri Guttman <uri at stemsystems.com> wrote:
>
>> On 02/17/2013 09:40 PM, Quinn Weaver wrote:
>>> On Feb 15, 2013, at 4:14 PM, Mark Kvale wrote:
>>>
>>>> This is documented behavior; see
>>>>
>>>> http://perldoc.perl.org/perlop.html#Symbolic-Unary-Operators
>>>>
>>>> My guess on use? As the man says, '-bareword is equivalent to the string "-bareword"', allowing for fat comma keys without needing quotes, e.g.
>>>>
>>>> (-bareword => 1, -title => 2)
>>>
>>> But you don't need to quote keys anyway. This feature must exist for some other reason.
>>
>> it was allowed because of perl/tk where all the keys (as in regular tk) are -foo style. so perl allows barewords of -foo to be autoquoted by =>.  this also allowed the - prefix to be a simple prefix - to the string op which is useful for those types of keys.
>>
>> uri
>> _______________________________________________
>> SanFrancisco-pm mailing list
>> SanFrancisco-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm



--
Earl Ruby
http://earlruby.org/
http://www.linkedin.com/in/earlruby
@earlruby

From quinn at pgexperts.com  Sun Feb 24 08:50:25 2013
From: quinn at pgexperts.com (Quinn Weaver)
Date: Sun, 24 Feb 2013 08:50:25 -0800
Subject: [sf-perl] Unusual Perl "feature"
In-Reply-To: <CAPBkEshZYh0o7W_2_=8C9WOUtLSWnOoEcegcxg4TuganmpzsNg@mail.gmail.com>
References: <CAPBkEsia8FgP5kj_jXQyX+sU-EGLt07GyZRR1rgcKFyMbZOs1w@mail.gmail.com>
	<511ECF61.1020903@phy.ucsf.edu>
	<F1AF1CE7-F07E-475E-9D72-484A86FE1D5A@pgexperts.com>
	<51229877.80105@stemsystems.com>
	<1E0E4042-48CA-439E-B8B6-9A2C1640F131@pgexperts.com>
	<CAPBkEshZYh0o7W_2_=8C9WOUtLSWnOoEcegcxg4TuganmpzsNg@mail.gmail.com>
Message-ID: <97008AC6-8D6E-4CF0-9400-86C796949D40@pgexperts.com>

Indeed, it seems odd that the feature would be "turned on" in other contexts besides far commas. My guess is that the perlguts implementation of operators doesn't allow them to be context-sensitive, so that an operator like unary '-' must work everywhere, even in places where it has no use case.

--
Quinn Weaver
PostgreSQL Experts, Inc.  http://pgexperts.com/
1-888-743-9778 (my extension: 510)
Sent from my phone; pardon my brevity.

On Feb 23, 2013, at 2:23 PM, Earl Ruby <earl at ruby.org> wrote:

> While this is all interesting, I wasn't using the => operator in the
> example I gave, just =
> 
> 
> On Tue, Feb 19, 2013 at 10:09 AM, Quinn Weaver <quinn at pgexperts.com> wrote:
>> Nice catch! That makes total sense. I wrote a Perl/Tk app once, but I'd forgotten all about the -key convention. It Just Worked, so I never really thought about it. DWIM for the win.
>> 
>> --
>> Quinn Weaver
>> PostgreSQL Experts, Inc.  http://pgexperts.com/
>> 1-888-743-9778 (my extension: 510)
>> Sent from my phone; pardon my brevity.
>> 
>> On Feb 18, 2013, at 1:09 PM, Uri Guttman <uri at stemsystems.com> wrote:
>> 
>>> On 02/17/2013 09:40 PM, Quinn Weaver wrote:
>>>> On Feb 15, 2013, at 4:14 PM, Mark Kvale wrote:
>>>> 
>>>>> This is documented behavior; see
>>>>> 
>>>>> http://perldoc.perl.org/perlop.html#Symbolic-Unary-Operators
>>>>> 
>>>>> My guess on use? As the man says, '-bareword is equivalent to the string "-bareword"', allowing for fat comma keys without needing quotes, e.g.
>>>>> 
>>>>> (-bareword => 1, -title => 2)
>>>> 
>>>> But you don't need to quote keys anyway. This feature must exist for some other reason.
>>> 
>>> it was allowed because of perl/tk where all the keys (as in regular tk) are -foo style. so perl allows barewords of -foo to be autoquoted by =>.  this also allowed the - prefix to be a simple prefix - to the string op which is useful for those types of keys.
>>> 
>>> uri
>>> _______________________________________________
>>> SanFrancisco-pm mailing list
>>> SanFrancisco-pm at pm.org
>>> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>> _______________________________________________
>> SanFrancisco-pm mailing list
>> SanFrancisco-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
> 
> 
> 
> --
> Earl Ruby
> http://earlruby.org/
> http://www.linkedin.com/in/earlruby
> @earlruby

From earl at ruby.org  Wed Feb 27 10:24:36 2013
From: earl at ruby.org (Earl Ruby)
Date: Wed, 27 Feb 2013 10:24:36 -0800
Subject: [sf-perl] HTML::Mason and jQuery
Message-ID: <CAPBkEsgza_0ODSd098btFVdt628o=y+A5FFip+4yyB48OCHr+g@mail.gmail.com>

A couple of people asked for links to the jQuery tools I mentioned
last night. Here they are:

droppy.js ? For drop-down menus

jqGrid ? Grid control for displaying and editing tabular data

d3.js ? For charts and graphs

http://net.tutsplus.com/tutorials/javascript-ajax/inettuts/ -- for the
dashboard layout

jWizard ? Step-by-step wizard to walk users through complex configurations

We use HTML::Mason components to generate the data to drive the jQuery
code, but you could just as easily use whatever Perl web framework you
like.

--
Earl Ruby
http://earlruby.org/
http://www.linkedin.com/in/earlruby
@earlruby

From hartzell at alerce.com  Wed Feb 27 10:35:35 2013
From: hartzell at alerce.com (George Hartzell)
Date: Wed, 27 Feb 2013 10:35:35 -0800
Subject: [sf-perl] Links my talk last night.
Message-ID: <20782.20983.112589.963702@gargle.gargle.HOWL>


Here's the work-in-progress DSL library I mentioned last night:

  https://github.com/hartzell/dsl-tiny

Comments on functionality, packages, testing, etc... are welcome.

And here's a link to Ricardo's Sub::Exporter, from the first part:

  https://metacpan.org/module/Sub::Exporter

g.