From fred at redhotpenguin.com Wed Feb 3 11:25:26 2010 From: fred at redhotpenguin.com (Fred Moyer) Date: Wed, 3 Feb 2010 11:25:26 -0800 Subject: [sf-perl] February Meeting - "Why you should create CPAN distros" [meeting] Message-ID: On February 23rd at 7pm at Six Apart World Headquarters in San Francisco, Jeff Thalhammer will speak on why you should create CPAN distros, even for proprietary code. He has worked on worked on several projects where all the private code was organized into CPAN-style distros, and then injected into a local copy of CPAN. They then used the CPAN tool chain to manage the entire build, test, and release process. Jeff Thalhammer's CPAN page: http://search.cpan.org/~thaljef/ Please RSVP at Meetup - http://www.meetup.com/San-Francisco-Perl-Mongers/calendar/12509158/ Announcement posted via App::PM::Announce From fred at redhotpenguin.com Wed Feb 3 13:21:05 2010 From: fred at redhotpenguin.com (Fred Moyer) Date: Wed, 3 Feb 2010 13:21:05 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] Message-ID: I'll start: 5.8.8, Snow Leopard. Have been trying to get the bugs worked out of 5.10.1 for my toolchain still. From diederich at gmail.com Wed Feb 3 13:24:47 2010 From: diederich at gmail.com (Dana Diederich) Date: Wed, 3 Feb 2010 13:24:47 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: References: Message-ID: Perl 5.10.1 on CentOS 4 and 5 Cheers, -Dana On Wed, Feb 3, 2010 at 1:21 PM, Fred Moyer wrote: > I'll start: > > 5.8.8, Snow Leopard. ?Have been trying to get the bugs worked out of > 5.10.1 for my toolchain still. > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > From fred at redhotpenguin.com Wed Feb 3 13:26:30 2010 From: fred at redhotpenguin.com (Fred Moyer) Date: Wed, 3 Feb 2010 13:26:30 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: References: Message-ID: On Wed, Feb 3, 2010 at 1:24 PM, Dana Diederich wrote: > Perl 5.10.1 on CentOS 4 and 5 Do you compile it yourself? (forgot to answer yes to that) > > Cheers, > -Dana > > On Wed, Feb 3, 2010 at 1:21 PM, Fred Moyer wrote: >> I'll start: >> >> 5.8.8, Snow Leopard. ?Have been trying to get the bugs worked out of >> 5.10.1 for my toolchain still. >> _______________________________________________ >> 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 > From diederich at gmail.com Wed Feb 3 13:30:15 2010 From: diederich at gmail.com (Dana Diederich) Date: Wed, 3 Feb 2010 13:30:15 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: References: Message-ID: I did; in fact, I use the same binary toolchain for CentOS4 and CentOS5, which is a huge relief! That covers 100% of our boxes. Cheers, -Dana On Wed, Feb 3, 2010 at 1:26 PM, Fred Moyer wrote: > On Wed, Feb 3, 2010 at 1:24 PM, Dana Diederich wrote: >> Perl 5.10.1 on CentOS 4 and 5 > > Do you compile it yourself? ?(forgot to answer yes to that) > >> >> Cheers, >> -Dana >> >> On Wed, Feb 3, 2010 at 1:21 PM, Fred Moyer wrote: >>> I'll start: >>> >>> 5.8.8, Snow Leopard. ?Have been trying to get the bugs worked out of >>> 5.10.1 for my toolchain still. >>> _______________________________________________ >>> 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 >> > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > From friedman at highwire.stanford.edu Wed Feb 3 13:36:24 2010 From: friedman at highwire.stanford.edu (Michael Friedman) Date: Wed, 3 Feb 2010 13:36:24 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: References: Message-ID: <82089F6B-0984-4152-941C-7DA781FC85EF@highwire.stanford.edu> Personally, I use perl 5.10.0 (threaded) on OS X 10.6. At the office we use a motley collection of 5.8.5 and 5.8.6 (unthreaded) on Solaris and Red Hat machines. It occasionally causes trouble, but a single point difference is usually not a problem. Why do you ask? -- Mike ______________________________________________________________________________ Mike Friedman | HighWire Press, Stanford Univ | friedman at highwire.stanford.edu On Feb 3, 2010, at 1:21 PM, Fred Moyer wrote: > I'll start: > > 5.8.8, Snow Leopard. Have been trying to get the bugs worked out of > 5.10.1 for my toolchain still. > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm From diederich at gmail.com Wed Feb 3 13:30:15 2010 From: diederich at gmail.com (Dana Diederich) Date: Wed, 3 Feb 2010 13:30:15 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: References: Message-ID: I did; in fact, I use the same binary toolchain for CentOS4 and CentOS5, which is a huge relief! That covers 100% of our boxes. Cheers, -Dana On Wed, Feb 3, 2010 at 1:26 PM, Fred Moyer wrote: > On Wed, Feb 3, 2010 at 1:24 PM, Dana Diederich wrote: >> Perl 5.10.1 on CentOS 4 and 5 > > Do you compile it yourself? ?(forgot to answer yes to that) > >> >> Cheers, >> -Dana >> >> On Wed, Feb 3, 2010 at 1:21 PM, Fred Moyer wrote: >>> I'll start: >>> >>> 5.8.8, Snow Leopard. ?Have been trying to get the bugs worked out of >>> 5.10.1 for my toolchain still. >>> _______________________________________________ >>> 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 >> > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > From fred at redhotpenguin.com Wed Feb 3 13:48:15 2010 From: fred at redhotpenguin.com (Fred Moyer) Date: Wed, 3 Feb 2010 13:48:15 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: <82089F6B-0984-4152-941C-7DA781FC85EF@highwire.stanford.edu> References: <82089F6B-0984-4152-941C-7DA781FC85EF@highwire.stanford.edu> Message-ID: On Wed, Feb 3, 2010 at 1:36 PM, Michael Friedman wrote: > Personally, I use perl 5.10.0 (threaded) on OS X 10.6. Any reason you don't compile your own binary? > > At the office we use a motley collection of 5.8.5 and 5.8.6 (unthreaded) on Solaris and Red Hat machines. It occasionally causes trouble, but a single point difference is usually not a problem. > > Why do you ask? This is a Perl list, we talk about Perl :) ________________________________________________ > Mike Friedman | HighWire Press, Stanford Univ | friedman at highwire.stanford.edu > > On Feb 3, 2010, at 1:21 PM, Fred Moyer wrote: > >> I'll start: >> >> 5.8.8, Snow Leopard. ?Have been trying to get the bugs worked out of >> 5.10.1 for my toolchain still. >> _______________________________________________ >> 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 > From friedman at highwire.stanford.edu Wed Feb 3 13:55:35 2010 From: friedman at highwire.stanford.edu (Michael Friedman) Date: Wed, 3 Feb 2010 13:55:35 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: References: <82089F6B-0984-4152-941C-7DA781FC85EF@highwire.stanford.edu> Message-ID: <971F84C6-A9D3-4423-8B31-755CB8D12C5C@highwire.stanford.edu> > Any reason you don't compile your own binary? I haven't needed to. The one that came with OS X has been just fine. I see the every-couple-of-years "upgrade" of OS X as an excuse to look through what CPAN modules I actually use and reinstall them all from scratch again. It's a nice house cleaning, except for that damn Sybase stuff... >> Why do you ask? > > This is a Perl list, we talk about Perl :) Heh. More generally, except for some spiffy syntax features that I haven't learned about yet, most everything runs on most versions of perl after 5.8, right? So how much does the version really matter? I've seen version problems with various CPAN modules, but not yet with perl itself. -- Mike ______________________________________________________________________________ Mike Friedman | HighWire Press, Stanford Univ | friedman at highwire.stanford.edu From barko192 at gmail.com Wed Feb 3 14:00:31 2010 From: barko192 at gmail.com (Matt Barkovich) Date: Wed, 3 Feb 2010 14:00:31 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: <971F84C6-A9D3-4423-8B31-755CB8D12C5C@highwire.stanford.edu> References: <82089F6B-0984-4152-941C-7DA781FC85EF@highwire.stanford.edu> <971F84C6-A9D3-4423-8B31-755CB8D12C5C@highwire.stanford.edu> Message-ID: Snow leopard, 5.10.1 on my own machine. Debian and 5.8.8 on my servers. Reason: I'm always reluctant to upgrade server software that is working fine when I don't need any new features. On my own computer, I'll upgrade just for kicks. Matt On Wed, Feb 3, 2010 at 1:55 PM, Michael Friedman wrote: >> Any reason you don't compile your own binary? > > I haven't needed to. The one that came with OS X has been just fine. > > I see the every-couple-of-years "upgrade" of OS X as an excuse to look through what CPAN modules I actually use and reinstall them all from scratch again. It's a nice house cleaning, except for that damn Sybase stuff... > >>> Why do you ask? >> >> This is a Perl list, we talk about Perl :) > > > Heh. > > More generally, except for some spiffy syntax features that I haven't learned about yet, most everything runs on most versions of perl after 5.8, right? So how much does the version really matter? I've seen version problems with various CPAN modules, but not yet with perl itself. > > -- Mike > ______________________________________________________________________________ > Mike Friedman | HighWire Press, Stanford Univ | friedman at highwire.stanford.edu > > > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > From fred at redhotpenguin.com Wed Feb 3 14:02:40 2010 From: fred at redhotpenguin.com (Fred Moyer) Date: Wed, 3 Feb 2010 14:02:40 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: References: <82089F6B-0984-4152-941C-7DA781FC85EF@highwire.stanford.edu> <971F84C6-A9D3-4423-8B31-755CB8D12C5C@highwire.stanford.edu> Message-ID: On Wed, Feb 3, 2010 at 2:00 PM, Matt Barkovich wrote: > Snow leopard, 5.10.1 on my own machine. ?Debian and 5.8.8 on my > servers. ?Reason: I'm always reluctant to upgrade server software that > is working fine when I don't need any new features. ?On my own > computer, I'll upgrade just for kicks. Did you compile perl with -fPIC? Here's my perl -V: Summary of my perl5 (revision 5 version 10 subversion 1) configuration: Platform: osname=darwin, osvers=10.2.0, archname=darwin-2level uname='darwin pooky.redhotpenguin.com 10.2.0 darwin kernel version 10.2.0: tue nov 3 10:37:10 pst 2009; root:xnu-1486.2.11~1release_i386 i386 i386 ' config_args='-Dprefix=/Users/phred/dev/perl-5.10.1' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include', optimize='-O3', cppflags='-no-cpp-precomp -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.2.1 (Apple Inc. build 5646) (dot 1)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-ldbm -ldl -lm -lutil -lc perllibs=-ldl -lm -lutil -lc libc=/usr/lib/libc.dylib, so=dylib, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector' Characteristics of this binary (from libperl): Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO Built under darwin Compiled at Feb 3 2010 13:03:28 @INC: /Users/phred/dev/perl-5.10.1/lib/5.10.1/darwin-2level /Users/phred/dev/perl-5.10.1/lib/5.10.1 /Users/phred/dev/perl-5.10.1/lib/site_perl/5.10.1/darwin-2level /Users/phred/dev/perl-5.10.1/lib/site_perl/5.10.1 . > > Matt > > On Wed, Feb 3, 2010 at 1:55 PM, Michael Friedman > wrote: >>> Any reason you don't compile your own binary? >> >> I haven't needed to. The one that came with OS X has been just fine. >> >> I see the every-couple-of-years "upgrade" of OS X as an excuse to look through what CPAN modules I actually use and reinstall them all from scratch again. It's a nice house cleaning, except for that damn Sybase stuff... >> >>>> Why do you ask? >>> >>> This is a Perl list, we talk about Perl :) >> >> >> Heh. >> >> More generally, except for some spiffy syntax features that I haven't learned about yet, most everything runs on most versions of perl after 5.8, right? So how much does the version really matter? I've seen version problems with various CPAN modules, but not yet with perl itself. >> >> -- Mike >> ______________________________________________________________________________ >> Mike Friedman | HighWire Press, Stanford Univ | friedman at highwire.stanford.edu >> >> >> _______________________________________________ >> 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 > From fred at redhotpenguin.com Wed Feb 3 14:21:39 2010 From: fred at redhotpenguin.com (Fred Moyer) Date: Wed, 3 Feb 2010 14:21:39 -0800 Subject: [sf-perl] New Devel::NYTProf Message-ID: For those of us lucky enough to have bottlenecks in our code: http://blog.timbunce.org/2009/12/24/nytprof-v3-worth-the-wait/ From shlomif at iglu.org.il Wed Feb 3 14:32:52 2010 From: shlomif at iglu.org.il (Shlomi Fish) Date: Thu, 4 Feb 2010 00:32:52 +0200 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: References: Message-ID: <201002040032.53275.shlomif@iglu.org.il> On Wednesday 03 Feb 2010 23:21:05 Fred Moyer wrote: > I'll start: > > 5.8.8, Snow Leopard. Have been trying to get the bugs worked out of > 5.10.1 for my toolchain still. I'm normally using perl-5.10.1-8mdv2010.1 (the /usr/bin/perl ) on Mandriva Linux Cooker. I have various other versions of Perl installed on my Virtual Machines, my Debian Testing partition, and on various Internet servers on which I have an account. Regards, Shlomi Fish -- ----------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ "Star Trek: We, the Living Dead" - http://shlom.in/st-wtld Deletionists delete Wikipedia articles that they consider lame. Chuck Norris deletes deletionists whom he considers lame. Please reply to list if it's a mailing list post - http://shlom.in/reply . From bryan at beeley.org Wed Feb 3 14:34:44 2010 From: bryan at beeley.org (Bryan Beeley) Date: Wed, 03 Feb 2010 14:34:44 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: References: Message-ID: <4B69FA04.6090008@beeley.org> 5.10.0, Ubuntu 9.10 64bit - From Ubuntu package (not compiled) 5.8.8, CentOS 5 64bit - Compiled since it gave our Ops people a warm fuzzy feeling 5.10.0, CentOS 5.2 64bit - Compiled for the same reason Bryan Fred Moyer wrote: > I'll start: > > 5.8.8, Snow Leopard. Have been trying to get the bugs worked out of > 5.10.1 for my toolchain still. > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > From jackofnotrades at gmail.com Wed Feb 3 14:39:54 2010 From: jackofnotrades at gmail.com (Jeff Bragg) Date: Wed, 3 Feb 2010 14:39:54 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: References: Message-ID: <2f8a56f71002031439q6cc020bfq2d4f63087d4f23fb@mail.gmail.com> Perl 5.10.0 on Ubuntu 9.10 On Wed, Feb 3, 2010 at 1:21 PM, Fred Moyer wrote: > I'll start: > > 5.8.8, Snow Leopard. Have been trying to get the bugs worked out of > 5.10.1 for my toolchain still. > _______________________________________________ > 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: From eruby at knowledgematters.net Wed Feb 3 15:11:19 2010 From: eruby at knowledgematters.net (Earl Ruby) Date: Wed, 3 Feb 2010 15:11:19 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: <971F84C6-A9D3-4423-8B31-755CB8D12C5C@highwire.stanford.edu> References: <82089F6B-0984-4152-941C-7DA781FC85EF@highwire.stanford.edu> <971F84C6-A9D3-4423-8B31-755CB8D12C5C@highwire.stanford.edu> Message-ID: On Wed, Feb 3, 2010 at 1:55 PM, Michael Friedman wrote: > More generally, except for some spiffy syntax features that I haven't learned about yet, most everything runs on most versions of perl after 5.8, right? So how much does the version really matter? I've seen version problems with various CPAN modules, but not yet with perl itself. I had some code that broke under 5.10, ran fine on 5.8. The code was written to make use of Perl's OO features circa 1999/2000 (not by me), and hadn't been changed since. After finding and fixing the bug, I was surprised that it worked at all under 5.8. perl v5.10.0 on Ubuntu 9.04, SUSE 11.1 perl v5.8.8 on hosted Linux systems I've compiled from source when I've needed to, but these days I don't usually need to. I'm also interested to know how people manage Perl in their production environments, that is, how you make sure that all of the CPAN modules you need are installed and how you verify that all production servers are using the same module versions. I usually build modules on a dev server, then use cpan2rpm to create RPMs, then install from the RPM files in production. -- Earl Ruby http://earlruby.org/ From extasia at extasia.org Wed Feb 3 15:36:36 2010 From: extasia at extasia.org (David Alban) Date: Wed, 3 Feb 2010 15:36:36 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: References: <82089F6B-0984-4152-941C-7DA781FC85EF@highwire.stanford.edu> <971F84C6-A9D3-4423-8B31-755CB8D12C5C@highwire.stanford.edu> Message-ID: <4c714a9c1002031536s72a8742euc157487707da6e16@mail.gmail.com> tangentially related to your question... i do tools for (mostly) the release engineering group at work. my company is a java shop, so not too many of us use perl. rather than getting sysadmins to install new modules when i need one, i decided a while back to keep all of our tools / libraries / etc in a single tree on our nas (which is mounted to all the machines which matter). so all folks have to do to use our tools is to mount that nas partition. home grown modules go under . cpan modules that i need go there, too. (reg is an acronym which stands for release engineering group.) so any programs that want to use these modules include the use statement: use lib '/nas/reg/lib/perl'; (/nas/reg/lib/perl is a symlink to /nas/reg/lib/perl5) what i like is that i can maintain the contents in / updates to our nas partition. On Wed, Feb 3, 2010 at 3:11 PM, Earl Ruby wrote: > I'm also interested to know how people manage Perl in their production > environments, that is, how you make sure that all of the CPAN modules > you need are installed and how you verify that all production servers > are using the same module versions. I usually build modules on a dev > server, then use cpan2rpm to create RPMs, then install from the RPM > files in production. -- Live in a world of your own, but always welcome visitors. From bryan at beeley.org Wed Feb 3 15:50:46 2010 From: bryan at beeley.org (Bryan Beeley) Date: Wed, 03 Feb 2010 15:50:46 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: <4c714a9c1002031536s72a8742euc157487707da6e16@mail.gmail.com> References: <82089F6B-0984-4152-941C-7DA781FC85EF@highwire.stanford.edu> <971F84C6-A9D3-4423-8B31-755CB8D12C5C@highwire.stanford.edu> <4c714a9c1002031536s72a8742euc157487707da6e16@mail.gmail.com> Message-ID: <4B6A0BD6.5050403@beeley.org> We do something similar. We compile everything on a single tree then rsync it to all our servers. We usually add modules to our production servers as soon as we start using them in development, just to make sure we aren't out of sync when we push out the next code release. Bryan David Alban wrote: > tangentially related to your question... > > i do tools for (mostly) the release engineering group at work. my > company is a java shop, so not too many of us use perl. rather than > getting sysadmins to install new modules when i need one, i decided a > while back to keep all of our tools / libraries / etc in a single tree > on our nas (which is mounted to all the machines which matter). so > all folks have to do to use our tools is to mount that nas partition. > > home grown modules go under . cpan modules that > i need go there, too. (reg is an acronym which stands for release > engineering group.) so any programs that want to use these modules > include the use statement: > > use lib '/nas/reg/lib/perl'; > > (/nas/reg/lib/perl is a symlink to /nas/reg/lib/perl5) > > what i like is that i can maintain the contents in / updates to our > nas partition. > > On Wed, Feb 3, 2010 at 3:11 PM, Earl Ruby wrote: > >> I'm also interested to know how people manage Perl in their production >> environments, that is, how you make sure that all of the CPAN modules >> you need are installed and how you verify that all production servers >> are using the same module versions. I usually build modules on a dev >> server, then use cpan2rpm to create RPMs, then install from the RPM >> files in production. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From swartz at pobox.com Wed Feb 3 16:01:54 2010 From: swartz at pobox.com (Jonathan Swartz) Date: Wed, 3 Feb 2010 16:01:54 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: <4B6A0BD6.5050403@beeley.org> References: <82089F6B-0984-4152-941C-7DA781FC85EF@highwire.stanford.edu> <971F84C6-A9D3-4423-8B31-755CB8D12C5C@highwire.stanford.edu> <4c714a9c1002031536s72a8742euc157487707da6e16@mail.gmail.com> <4B6A0BD6.5050403@beeley.org> Message-ID: At my latest job, I've started to treat critical vendor software (Perl, Apache, and all CPAN modules) the same way as the web code: it is all under version control, and it all gets rsynced out to production during a release. Still too early to tell whether this is overkill. But I do feel highly organized and it's nice not to have to worry about which modules are installed where. On Feb 3, 2010, at 3:50 PM, Bryan Beeley wrote: > We do something similar. We compile everything on a single tree > then rsync it to all our servers. We usually add modules to our > production servers as soon as we start using them in development, > just to make sure we aren't out of sync when we push out the next > code release. > > Bryan > > David Alban wrote: >> >> tangentially related to your question... >> >> i do tools for (mostly) the release engineering group at work. my >> company is a java shop, so not too many of us use perl. rather than >> getting sysadmins to install new modules when i need one, i decided a >> while back to keep all of our tools / libraries / etc in a single >> tree >> on our nas (which is mounted to all the machines which matter). so >> all folks have to do to use our tools is to mount that nas partition. >> >> home grown modules go under . cpan modules that >> i need go there, too. (reg is an acronym which stands for release >> engineering group.) so any programs that want to use these modules >> include the use statement: >> >> use lib '/nas/reg/lib/perl'; >> >> (/nas/reg/lib/perl is a symlink to /nas/reg/lib/perl5) >> >> what i like is that i can maintain the contents in / updates to our >> nas partition. >> >> On Wed, Feb 3, 2010 at 3:11 PM, Earl Ruby >> wrote: >> >>> I'm also interested to know how people manage Perl in their >>> production >>> environments, that is, how you make sure that all of the CPAN >>> modules >>> you need are installed and how you verify that all production >>> servers >>> are using the same module versions. I usually build modules on a dev >>> server, then use cpan2rpm to create RPMs, then install from the RPM >>> files in production. >>> >> >> > > _______________________________________________ > 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: From barko192 at gmail.com Wed Feb 3 16:18:55 2010 From: barko192 at gmail.com (Matt Barkovich) Date: Wed, 3 Feb 2010 16:18:55 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: References: <82089F6B-0984-4152-941C-7DA781FC85EF@highwire.stanford.edu> <971F84C6-A9D3-4423-8B31-755CB8D12C5C@highwire.stanford.edu> Message-ID: On Feb 3, 2010, at 2:02 PM, Fred Moyer wrote: > Did you compile perl with -fPIC? Here's my perl -V: No I didn't, but I've been compiling with slightly different flags to see what works best. Here's my perl -V of my most recent build. Summary of my perl5 (revision 5 version 10 subversion 1) configuration: Platform: osname=darwin, osvers=10.6.2, archname=darwin-thread-multi-ld-2level uname='darwin delta12.local 10.2.0 darwin kernel version 10.2.0: tue nov 3 10:37:10 pst 2009; root:xnu-1486.2.11~1release_i386 i386 ' config_args='' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=define usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include', optimize='-O3', cppflags='-no-cpp-precomp -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.2.1 (Apple Inc. build 5646) (dot 1)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='long double', nvsize=16, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='env MACOSX_DEPLOYMENT_TARGET=10.6 cc', ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-ldbm -ldl -lm -lutil -lc perllibs=-ldl -lm -lutil -lc libc=, so=dylib, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_LONG_DOUBLE USE_PERLIO Built under darwin Compiled at Feb 1 2010 15:23:37 @INC: /Users/mbarko/build/lib/perl5/5.10.1/darwin-thread-multi-ld-2level /Users/mbarko/build/lib/perl5/5.10.1 /Users/mbarko/build/lib/perl5/site_perl/5.10.1/darwin-thread-multi-ld-2level /Users/mbarko/build/lib/perl5/site_perl/5.10.1 . From eruby at knowledgematters.net Wed Feb 3 16:45:26 2010 From: eruby at knowledgematters.net (Earl Ruby) Date: Wed, 3 Feb 2010 16:45:26 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: References: <82089F6B-0984-4152-941C-7DA781FC85EF@highwire.stanford.edu> <971F84C6-A9D3-4423-8B31-755CB8D12C5C@highwire.stanford.edu> <4c714a9c1002031536s72a8742euc157487707da6e16@mail.gmail.com> <4B6A0BD6.5050403@beeley.org> Message-ID: 2010/2/3 Jonathan Swartz : > At my latest job, I've started to treat critical vendor software (Perl, > Apache, and all CPAN modules) the same way as the web code: it is all under > version control, and it all gets rsynced out to production during a release. > Still too early to tell whether this is overkill. But I do feel highly > organized and it's nice not to have to worry about which modules are > installed where. Doesn't sound like overkill to me. If you find you're outgrowing rsync, you might want to check out Puppet: http://reductivelabs.com/products/puppet/ -- Earl Ruby http://earlruby.org/ From bob.goolsby at gmail.com Thu Feb 4 03:55:49 2010 From: bob.goolsby at gmail.com (Bob goolsby) Date: Thu, 4 Feb 2010 03:55:49 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: References: <82089F6B-0984-4152-941C-7DA781FC85EF@highwire.stanford.edu> <971F84C6-A9D3-4423-8B31-755CB8D12C5C@highwire.stanford.edu> <4c714a9c1002031536s72a8742euc157487707da6e16@mail.gmail.com> <4B6A0BD6.5050403@beeley.org> Message-ID: <1a208dd1002040355s1ea92c2crca162d2874becec8@mail.gmail.com> On the Windows boxen: XP+Service Packs; Perl 5.10.1 on win-alfa; perl 5.8.x on win-beta On the Linux boxen: Ubuntu 9.07, Perl 5.10.0; Fedora Core 11, Perl 5.8.0 On the BSD box: PC-BSD 1.3, perl 5.8x and 5.10.1 Bob G On Wed, Feb 3, 2010 at 4:45 PM, Earl Ruby wrote: > 2010/2/3 Jonathan Swartz : >> At my latest job, I've started to treat critical vendor software (Perl, >> Apache, and all CPAN modules) the same way as the web code: it is all under >> version control, and it all gets rsynced out to production during a release. >> Still too early to tell whether this is overkill. But I do feel highly >> organized and it's nice not to have to worry about which modules are >> installed where. > > Doesn't sound like overkill to me. > > If you find you're outgrowing rsync, you might want to check out Puppet: > http://reductivelabs.com/products/puppet/ > > -- > Earl Ruby > http://earlruby.org/ > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > From jackofnotrades at gmail.com Thu Feb 4 09:41:33 2010 From: jackofnotrades at gmail.com (Jeff Bragg) Date: Thu, 4 Feb 2010 09:41:33 -0800 Subject: [sf-perl] New Devel::NYTProf In-Reply-To: References: Message-ID: <2f8a56f71002040941j6bacfddcl1db2f253fe39ccf9@mail.gmail.com> Hard to believe they added so much to an already excellent package. On Wed, Feb 3, 2010 at 2:21 PM, Fred Moyer wrote: > For those of us lucky enough to have bottlenecks in our code: > > http://blog.timbunce.org/2009/12/24/nytprof-v3-worth-the-wait/ > _______________________________________________ > 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: From blum.stephen at gmail.com Thu Feb 4 12:07:19 2010 From: blum.stephen at gmail.com (Stephen Blum) Date: Thu, 4 Feb 2010 12:07:19 -0800 Subject: [sf-perl] Perl & OS Version Message-ID: v5.10.0 on Ubuntu 9.10 which based on Debian's unstable branch I believe. Stephen On Thu, Feb 4, 2010 at 12:00 PM, wrote: > Send SanFrancisco-pm mailing list submissions to > sanfrancisco-pm at pm.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > or, via email, send a message with subject or body 'help' to > sanfrancisco-pm-request at pm.org > > You can reach the person managing the list at > sanfrancisco-pm-owner at pm.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SanFrancisco-pm digest..." > > > Today's Topics: > > 1. Re: What version of perl and what OS do you use? [poll] > (Jonathan Swartz) > 2. Re: What version of perl and what OS do you use? [poll] > (Matt Barkovich) > 3. Re: What version of perl and what OS do you use? [poll] > (Earl Ruby) > 4. Re: What version of perl and what OS do you use? [poll] > (Bob goolsby) > 5. Re: New Devel::NYTProf (Jeff Bragg) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 3 Feb 2010 16:01:54 -0800 > From: Jonathan Swartz > Subject: Re: [sf-perl] What version of perl and what OS do you use? > [poll] > To: San Francisco Perl Mongers User Group > Message-ID: > Content-Type: text/plain; charset="us-ascii"; Format="flowed"; > DelSp="yes" > > At my latest job, I've started to treat critical vendor software > (Perl, Apache, and all CPAN modules) the same way as the web code: it > is all under version control, and it all gets rsynced out to > production during a release. Still too early to tell whether this is > overkill. But I do feel highly organized and it's nice not to have to > worry about which modules are installed where. > > On Feb 3, 2010, at 3:50 PM, Bryan Beeley wrote: > > > We do something similar. We compile everything on a single tree > > then rsync it to all our servers. We usually add modules to our > > production servers as soon as we start using them in development, > > just to make sure we aren't out of sync when we push out the next > > code release. > > > > Bryan > > > > David Alban wrote: > >> > >> tangentially related to your question... > >> > >> i do tools for (mostly) the release engineering group at work. my > >> company is a java shop, so not too many of us use perl. rather than > >> getting sysadmins to install new modules when i need one, i decided a > >> while back to keep all of our tools / libraries / etc in a single > >> tree > >> on our nas (which is mounted to all the machines which matter). so > >> all folks have to do to use our tools is to mount that nas partition. > >> > >> home grown modules go under . cpan modules that > >> i need go there, too. (reg is an acronym which stands for release > >> engineering group.) so any programs that want to use these modules > >> include the use statement: > >> > >> use lib '/nas/reg/lib/perl'; > >> > >> (/nas/reg/lib/perl is a symlink to /nas/reg/lib/perl5) > >> > >> what i like is that i can maintain the contents in / updates to our > >> nas partition. > >> > >> On Wed, Feb 3, 2010 at 3:11 PM, Earl Ruby > >> wrote: > >> > >>> I'm also interested to know how people manage Perl in their > >>> production > >>> environments, that is, how you make sure that all of the CPAN > >>> modules > >>> you need are installed and how you verify that all production > >>> servers > >>> are using the same module versions. I usually build modules on a dev > >>> server, then use cpan2rpm to create RPMs, then install from the RPM > >>> files in production. > >>> > >> > >> > > > > _______________________________________________ > > 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/20100203/ff441d9d/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Wed, 3 Feb 2010 16:18:55 -0800 > From: Matt Barkovich > Subject: Re: [sf-perl] What version of perl and what OS do you use? > [poll] > To: San Francisco Perl Mongers User Group > Message-ID: > Content-Type: text/plain; charset=us-ascii > > On Feb 3, 2010, at 2:02 PM, Fred Moyer wrote: > > > Did you compile perl with -fPIC? Here's my perl -V: > > No I didn't, but I've been compiling with slightly different flags to see > what works best. > > Here's my perl -V of my most recent build. > > Summary of my perl5 (revision 5 version 10 subversion 1) configuration: > > Platform: > osname=darwin, osvers=10.6.2, archname=darwin-thread-multi-ld-2level > uname='darwin delta12.local 10.2.0 darwin kernel version 10.2.0: tue nov > 3 10:37:10 pst 2009; root:xnu-1486.2.11~1release_i386 i386 ' > config_args='' > hint=recommended, useposix=true, d_sigaction=define > useithreads=define, usemultiplicity=define > useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef > use64bitint=define, use64bitall=define, uselongdouble=define > usemymalloc=n, bincompat5005=undef > Compiler: > cc='cc', ccflags ='-fno-common -DPERL_DARWIN -no-cpp-precomp > -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include', > optimize='-O3', > cppflags='-no-cpp-precomp -fno-common -DPERL_DARWIN -no-cpp-precomp > -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' > ccversion='', gccversion='4.2.1 (Apple Inc. build 5646) (dot 1)', > gccosandvers='' > intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 > ivtype='long', ivsize=8, nvtype='long double', nvsize=16, Off_t='off_t', > lseeksize=8 > alignbytes=8, prototype=define > Linker and Libraries: > ld='env MACOSX_DEPLOYMENT_TARGET=10.6 cc', ldflags =' -fstack-protector > -L/usr/local/lib' > libpth=/usr/local/lib /usr/lib > libs=-ldbm -ldl -lm -lutil -lc > perllibs=-ldl -lm -lutil -lc > libc=, so=dylib, useshrplib=false, libperl=libperl.a > gnulibc_version='' > Dynamic Linking: > dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' > cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup > -L/usr/local/lib -fstack-protector' > > > Characteristics of this binary (from libperl): > Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV > PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP > USE_64_BIT_ALL > USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES > USE_LONG_DOUBLE USE_PERLIO > Built under darwin > Compiled at Feb 1 2010 15:23:37 > @INC: > /Users/mbarko/build/lib/perl5/5.10.1/darwin-thread-multi-ld-2level > /Users/mbarko/build/lib/perl5/5.10.1 > > /Users/mbarko/build/lib/perl5/site_perl/5.10.1/darwin-thread-multi-ld-2level > /Users/mbarko/build/lib/perl5/site_perl/5.10.1 > . > > > > ------------------------------ > > Message: 3 > Date: Wed, 3 Feb 2010 16:45:26 -0800 > From: Earl Ruby > Subject: Re: [sf-perl] What version of perl and what OS do you use? > [poll] > To: San Francisco Perl Mongers User Group > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > 2010/2/3 Jonathan Swartz : > > At my latest job, I've started to treat critical vendor software (Perl, > > Apache, and all CPAN modules) the same way as the web code: it is all > under > > version control, and it all gets rsynced out to production during a > release. > > Still too early to tell whether this is overkill. But I do feel highly > > organized and it's nice not to have to worry about which modules are > > installed where. > > Doesn't sound like overkill to me. > > If you find you're outgrowing rsync, you might want to check out Puppet: > http://reductivelabs.com/products/puppet/ > > -- > Earl Ruby > http://earlruby.org/ > > > ------------------------------ > > Message: 4 > Date: Thu, 4 Feb 2010 03:55:49 -0800 > From: Bob goolsby > Subject: Re: [sf-perl] What version of perl and what OS do you use? > [poll] > To: San Francisco Perl Mongers User Group > Message-ID: > <1a208dd1002040355s1ea92c2crca162d2874becec8 at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On the Windows boxen: XP+Service Packs; Perl 5.10.1 on win-alfa; perl > 5.8.x on win-beta > > On the Linux boxen: Ubuntu 9.07, Perl 5.10.0; Fedora Core 11, Perl 5.8.0 > > On the BSD box: PC-BSD 1.3, perl 5.8x and 5.10.1 > > Bob G > > On Wed, Feb 3, 2010 at 4:45 PM, Earl Ruby > wrote: > > 2010/2/3 Jonathan Swartz : > >> At my latest job, I've started to treat critical vendor software (Perl, > >> Apache, and all CPAN modules) the same way as the web code: it is all > under > >> version control, and it all gets rsynced out to production during a > release. > >> Still too early to tell whether this is overkill. But I do feel highly > >> organized and it's nice not to have to worry about which modules are > >> installed where. > > > > Doesn't sound like overkill to me. > > > > If you find you're outgrowing rsync, you might want to check out Puppet: > > http://reductivelabs.com/products/puppet/ > > > > -- > > Earl Ruby > > http://earlruby.org/ > > _______________________________________________ > > SanFrancisco-pm mailing list > > SanFrancisco-pm at pm.org > > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > > > > > ------------------------------ > > Message: 5 > Date: Thu, 4 Feb 2010 09:41:33 -0800 > From: Jeff Bragg > Subject: Re: [sf-perl] New Devel::NYTProf > To: San Francisco Perl Mongers User Group > Message-ID: > <2f8a56f71002040941j6bacfddcl1db2f253fe39ccf9 at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hard to believe they added so much to an already excellent package. > > On Wed, Feb 3, 2010 at 2:21 PM, Fred Moyer wrote: > > > For those of us lucky enough to have bottlenecks in our code: > > > > http://blog.timbunce.org/2009/12/24/nytprof-v3-worth-the-wait/ > > _______________________________________________ > > 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/20100204/cea42c05/attachment-0001.html > > > > ------------------------------ > > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > > > End of SanFrancisco-pm Digest, Vol 61, Issue 4 > ********************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From not.com at gmail.com Thu Feb 4 12:23:30 2010 From: not.com at gmail.com (yary) Date: Thu, 4 Feb 2010 12:23:30 -0800 Subject: [sf-perl] Perl & OS Version In-Reply-To: References: Message-ID: <75cbfa571002041223w705224aexdc03488df532f587@mail.gmail.com> FWIW- a server I don't control $ perl -v This is perl, v5.6.1 built for sun4-solaris-64int (with 48 registered patches, see perl -V for more detail) another server I don't control (and which will soon be decomissioned) $ perl -v This is perl, v5.8.8 built for amd64-freebsd (with 1 registered patch, see perl -V for more detail) a laptop (strawberry) >perl -v This is perl, v5.10.1 (*) built for MSWin32-x86-multi-thread same laptop >\cygwin\bin\perl.exe -v This is perl, v5.10.1 (*) built for i686-cygwin-thread-multi-64int (with 12 registered patches, see perl -V for more detail) a different laptop (Activestate) C:\Documents and Settings\Friend>perl -v This is perl, v5.10.1 built for MSWin32-x86-multi-thread (with 2 registered patches, see perl -V for more detail) a different server $ perl -v This is perl, v5.10.1 (*) built for OpenBSD.i386-openbsd-thread-multi another server $ perl -v This is perl, v5.10.1 (*) built for i386-netbsd Looks like I've been pretty good about keeping things up-to-date (and about using every major flavor of BSD!). I was "scared" into upgrading from 5.10.0 by reading about a performance regression on subroutine calls that happened between 5.8 and 5.10.0, though I didn't really follow the discussion. From mehryar at mehryar.com Thu Feb 4 12:24:41 2010 From: mehryar at mehryar.com (mehryar) Date: Thu, 4 Feb 2010 12:24:41 -0800 (PST) Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: References: Message-ID: 5.10.1 Leopard (personal) 5.8.8 RedHat 4 !!! (work) 5.8.0 Slackware 9 (circa 2003!!!) (website) On Wed, 3 Feb 2010, Fred Moyer wrote: > I'll start: > > 5.8.8, Snow Leopard. Have been trying to get the bugs worked out of > 5.10.1 for my toolchain still. > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > From greg at blekko.com Thu Feb 4 14:42:21 2010 From: greg at blekko.com (Greg Lindahl) Date: Thu, 4 Feb 2010 14:42:21 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: References: Message-ID: <20100204224221.GB23177@bx9.net> We run 5.8.8 supplied by CentoOS 5. We install some stuff using cpan2rpm, but more often our developers just add it to our build, which is distributed via rsync. We don't update to the latest versions of new CPAN modules very often since that's caused some regressions that annoyed us. I'd be curious how other people who run big production websites deal with versioning. -- greg From friedman at highwire.stanford.edu Thu Feb 4 14:57:01 2010 From: friedman at highwire.stanford.edu (Michael Friedman) Date: Thu, 4 Feb 2010 14:57:01 -0800 Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: <20100204224221.GB23177@bx9.net> References: <20100204224221.GB23177@bx9.net> Message-ID: <304ACD10-C914-4CAB-8D8F-C0E6FBEC4E6B@highwire.stanford.edu> On Feb 4, 2010, at 2:42 PM, Greg Lindahl wrote: > We don't update to the latest versions of new CPAN modules very often > since that's caused some regressions that annoyed us. > > I'd be curious how other people who run big production websites deal > with versioning. Yeah, we've run into some regressions too. After the first disaster or so, we decided that we'd do all CPAN installing on a totally separate machine and then run a bunch of tests against it to make sure it didn't break anything. The downside is that this procedure can take a week or more for something big or which has installation problems. So we only bother with the whole procedure for big things. For example, we've tried to upgrade our 5-year-old copy of libxml2/XML::LibXML for a couple of years now, but every time we have compile errors, regression problems, and just painful testing, so we haven't actually succeeded yet. This is problematic because our version (1.58) doesn't have any XPath support in it and the developers (me!) really want that. But, since we can't make it install and not break things, we can't do it. I'm sure we'll try again this summer and maybe it'll get through this time. On the other hand, adding new modules we do directly on our master copy. I give it a little test and then distribute out to all the servers. Then the developer can give it a whirl and make sure everything works fine. Since it's brand new, we know that nothing else is using it yet. I would highly recommend keeping around one extra production-setup server to do this sort of testing on. We use whatever "hot spare" we have at the time. If it has to go into production, the sysadmins wipe out my CPAN testing by recopying over the master perl libs and then I have to start from scratch again with the next free machine. But we can't afford to have a complete server just sitting around doing nothing, so oh, well. -- Mike ______________________________________________________________________________ Mike Friedman | HighWire Press, Stanford Univ | friedman at highwire.stanford.edu From cfuhrman at panix.com Thu Feb 4 15:22:58 2010 From: cfuhrman at panix.com (Chris Fuhrman) Date: Thu, 4 Feb 2010 15:22:58 -0800 (PST) Subject: [sf-perl] What version of perl and what OS do you use? [poll] In-Reply-To: References: Message-ID: At past employers: * perl <5.6, HP-UX * perl 5.6, Solaris 8 * perl 5.8*, Solaris 9, Solaris 10 * perl 5.8*, Ubuntu Linux * Activestate Perl, winXP * perl 5.8*, VMWare ESX(i) 4.x At my present employer: * perl 5.10, OpenSuSE 11.1 For personal use, I've used OpenBSD 3.x w/ perl 5.8 in the past. Cheers! On Wed, 3 Feb 2010 at 1:21pm, Fred Moyer wrote: > Date: Wed, 3 Feb 2010 13:21:05 > From: Fred Moyer > Reply-To: San Francisco Perl Mongers User Group > To: San Francisco Perl Mongers User Group > Subject: [sf-perl] What version of perl and what OS do you use? [poll] > > I'll start: > > 5.8.8, Snow Leopard. Have been trying to get the bugs worked out of > 5.10.1 for my toolchain still. > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > > -- Chris Fuhrman cfuhrman at panix.com From rdm at cfcl.com Tue Feb 9 14:57:34 2010 From: rdm at cfcl.com (Rich Morin) Date: Tue, 9 Feb 2010 14:57:34 -0800 Subject: [sf-perl] "Why you should create CPAN distros" In-Reply-To: <901694013.1265753511582.JavaMail.root@jobs.meetup.com> References: <901694013.1265753511582.JavaMail.root@jobs.meetup.com> Message-ID: This seems a bit like a motherhood and apple pie question, but the devil is in the details. Like, what distros should folks create, how to integrate with existing distros, etc. More generally, I am quite interested in the question of how to index and document all sorts of open source software, including the CPAN, Ruby Gems, and far more. Might anyone be interested in a sub-session on what we'd like to see in infrastructure for this sort of thing and how we might try to get there? -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 Technical editing and writing, programming, and web development From fred at redhotpenguin.com Tue Feb 9 18:52:34 2010 From: fred at redhotpenguin.com (Fred Moyer) Date: Tue, 9 Feb 2010 18:52:34 -0800 Subject: [sf-perl] "Why you should create CPAN distros" In-Reply-To: References: <901694013.1265753511582.JavaMail.root@jobs.meetup.com> Message-ID: On Tue, Feb 9, 2010 at 2:57 PM, Rich Morin wrote: > This seems a bit like a motherhood and apple pie question, but > the devil is in the details. ?Like, what distros should folks > create, how to integrate with existing distros, etc. > > More generally, I am quite interested in the question of how to > index and document all sorts of open source software, including > the CPAN, Ruby Gems, and far more. ?Might anyone be interested > in a sub-session on what we'd like to see in infrastructure for > this sort of thing and how we might try to get there? I would think that you could index and document just with your system tools. I tend to pull all source code for a project into a directory in something like $HOME/dev/project_or_customer/foo_repo/trunk. I then use App::Ack to search the codebase; it provides some great search functionality. Plus it isn't a shared resource that can be crashed occasionally by developers. From doom at kzsu.stanford.edu Tue Feb 9 18:54:08 2010 From: doom at kzsu.stanford.edu (Joe Brenner) Date: Tue, 09 Feb 2010 18:54:08 -0800 Subject: [sf-perl] "Why you should create CPAN distros" In-Reply-To: References: <901694013.1265753511582.JavaMail.root@jobs.meetup.com> Message-ID: <201002100254.o1A2s8nY037272@kzsu.stanford.edu> Rich Morin wrote: > This seems a bit like a motherhood and apple pie question, but > the devil is in the details. Well, I think Jeffrey's focus here is that he wants to argue that *all* of your perl development should be done in the form of cpan distros whether or not you intend on publishing them on CPAN. > Like, what distros should folks create, how to integrate > with existing distros, etc. Sure. The kind of scheme under discussion (I would guess) is: (a) develop modules as cpan distros (b) automatically convert them into native OS packages (e.g. *.deb or *.rpm) (c) use your OS's package management (apt, yum, etc) to sort out dependencies during installation (d) update your servers using the OS package manager. (Actually, I just double-checked the talk summary, and it looks like Jeffrey may favor just using CPAN.pm to do installation, without getting into the OS package management level...). Anyway, I can see how this sort of approach could be a good way to go... but I would guess that a good distributed version control system would fit the bill fairly well also. > More generally, I am quite interested in the question of how to > index and document all sorts of open source software, including > the CPAN, Ruby Gems, and far more. Might anyone be interested > in a sub-session on what we'd like to see in infrastructure for > this sort of thing and how we might try to get there? This sounds like an interesting topic to me... I *think* it's a different topic though. From fred at redhotpenguin.com Tue Feb 9 19:00:39 2010 From: fred at redhotpenguin.com (Fred Moyer) Date: Tue, 9 Feb 2010 19:00:39 -0800 Subject: [sf-perl] "Why you should create CPAN distros" In-Reply-To: <201002100254.o1A2s8nY037272@kzsu.stanford.edu> References: <901694013.1265753511582.JavaMail.root@jobs.meetup.com> <201002100254.o1A2s8nY037272@kzsu.stanford.edu> Message-ID: On Tue, Feb 9, 2010 at 6:54 PM, Joe Brenner wrote: > > Rich Morin wrote: > >> Like, what distros should folks create, how to integrate >> with existing distros, etc. > > Sure. > > The kind of scheme under discussion (I would guess) is: > > ?(a) develop modules as cpan distros This is an excellent way to develop a loosely coupled application that still allows for dependency management using perl build tools. > ?(b) automatically convert them into native OS packages > ? ? ?(e.g. *.deb or *.rpm) > ?(c) use your OS's package management (apt, yum, etc) > ? ? ?to sort out dependencies during installation > ?(d) update your servers using the OS package manager. I think these steps are essential in any sort of environment where system oriented people are managing the production environment (vs programming oriented people). Personally though, with a small team I favor just using version control to update the code on production. > Anyway, I can see how this sort of approach could be a good > way to go... but I would guess that a good distributed > version control system would fit the bill fairly well also. I'd love to see a talk on managing perl module development using git. From greg at blekko.com Tue Feb 9 20:26:52 2010 From: greg at blekko.com (Greg Lindahl) Date: Tue, 9 Feb 2010 20:26:52 -0800 Subject: [sf-perl] "Why you should create CPAN distros" In-Reply-To: References: <901694013.1265753511582.JavaMail.root@jobs.meetup.com> <201002100254.o1A2s8nY037272@kzsu.stanford.edu> Message-ID: <20100210042652.GB4546@bx9.net> > > ?(b) automatically convert them into native OS packages > > ? ? ?(e.g. *.deb or *.rpm) > > ?(c) use your OS's package management (apt, yum, etc) > > ? ? ?to sort out dependencies during installation > > ?(d) update your servers using the OS package manager. > > I think these steps are essential in any sort of environment where > system oriented people are managing the production environment (vs > programming oriented people). Well said. People can advocate for pure CPAN all you like, but many people work in environments which concentrate on using the OS package manager as much as possible. -- greg From fred at redhotpenguin.com Wed Feb 17 09:12:58 2010 From: fred at redhotpenguin.com (Fred Moyer) Date: Wed, 17 Feb 2010 09:12:58 -0800 Subject: [sf-perl] Impromptu Social at Naan 'n Curry tomorrow evening Message-ID: Greetings, We'll be holding an impromptu social tomorrow evening at 7pm at Naan 'n Curry. brian d foy is in town and will be joining us as a guest. brian was the creator of Perl Mongers, and we are pleased to have this opportunity to break Naan with him. http://www.naancurry.com/ Hope to see you there! From fred at redhotpenguin.com Wed Feb 17 10:13:29 2010 From: fred at redhotpenguin.com (Fred Moyer) Date: Wed, 17 Feb 2010 10:13:29 -0800 Subject: [sf-perl] Impromptu Social at Naan 'n Curry tomorrow evening In-Reply-To: References: Message-ID: Whoops, I should have indicated that this will be at the O'Farrell location in SF. 336 O Farrell Street,SF On Wed, Feb 17, 2010 at 9:12 AM, Fred Moyer wrote: > Greetings, > > We'll be holding an impromptu social tomorrow evening at 7pm at Naan > 'n Curry. ?brian d foy is in town and will be joining us as a guest. > brian was the creator of Perl Mongers, and we are pleased to have this > opportunity to break Naan with him. > > http://www.naancurry.com/ > > Hope to see you there! > From doom at kzsu.stanford.edu Wed Feb 17 11:37:15 2010 From: doom at kzsu.stanford.edu (Joe Brenner) Date: Wed, 17 Feb 2010 11:37:15 -0800 Subject: [sf-perl] Impromptu Social at Naan 'n Curry tomorrow evening In-Reply-To: References: Message-ID: <201002171937.o1HJbFpO094396@kzsu.stanford.edu> So join us for indian food with "brian d foy", Thursday night at 7pm, at... "Naan-N-Curry" 336 O'Farrell Street, between Mason and Taylor. (but unless you're feeling adventurous, always approach along O'Farrell street): http://naancurry.com/branches.php?brn=5 It's only a few blocks from the Powell Street Bart/MUNI station. Just walk north on Powell, and west on O'Farrell. This is across the street from the Hilton. The buffet is $10, chai is free. Fred Moyer wrote: > Whoops, I should have indicated that this will be at the O'Farrell > location in SF. > > 336 O Farrell Street,SF > > > Fred Moyer wrote: > > Greetings, > > > > We'll be holding an impromptu social tomorrow evening at 7pm at Naan > > 'n Curry. brian d foy is in town and will be joining us as a guest. > > brian was the creator of Perl Mongers, and we are pleased to have this > > opportunity to break Naan with him. > > > > http://www.naancurry.com/ > > > > Hope to see you there! From fred at redhotpenguin.com Mon Feb 22 11:18:59 2010 From: fred at redhotpenguin.com (Fred Moyer) Date: Mon, 22 Feb 2010 11:18:59 -0800 Subject: [sf-perl] Reminder - "Why you should create CPAN distros" is tomorrow Message-ID: Tomorrow at 7pm at Six Apart World Headquarters Jeff Thalhammer will speak on why you should create CPAN distros, even for proprietary code. He has worked on worked on several projects where all the private code was organized into CPAN-style distros, and then injected into a local copy of CPAN. They then used the CPAN tool chain to manage the entire build, test, and release process. Please RSVP at Meetup: http://www.meetup.com/San-Francisco-Perl-Mongers/calendar/12509158/ Hope to see you there! From miyagawa at gmail.com Mon Feb 22 11:22:10 2010 From: miyagawa at gmail.com (Tatsuhiko Miyagawa) Date: Mon, 22 Feb 2010 11:22:10 -0800 Subject: [sf-perl] Reminder - "Why you should create CPAN distros" is tomorrow In-Reply-To: References: Message-ID: <693254b91002221122h3fa59267rc59fc9030adf2341@mail.gmail.com> Hi, May I plug my recent super-tiny and less-sucky CPAN installer 'cpanminus' before/during/after the talk? This is to change the landscape of CPAN toolchain ecosystem. http://github.com/miyagawa/cpanminus http://marcus.nordaaker.com/2010/02/cpanminus-the-new-cpan-superstar/ http://www.reddit.com/r/perl/comments/b4ryf/cpanminus_the_new_cpan_superstar/ On Mon, Feb 22, 2010 at 11:18 AM, Fred Moyer wrote: > Tomorrow at 7pm at Six Apart World Headquarters Jeff Thalhammer will > speak on why you should create CPAN distros, even for proprietary > code. He has worked on worked on several projects where all the > private code was organized into CPAN-style distros, and then injected > into a local copy of CPAN. They then used the CPAN tool chain to > manage the entire build, test, and release process. > > Please RSVP at Meetup: -- Tatsuhiko Miyagawa From fred at redhotpenguin.com Mon Feb 22 11:26:32 2010 From: fred at redhotpenguin.com (Fred Moyer) Date: Mon, 22 Feb 2010 11:26:32 -0800 Subject: [sf-perl] Reminder - "Why you should create CPAN distros" is tomorrow In-Reply-To: <693254b91002221122h3fa59267rc59fc9030adf2341@mail.gmail.com> References: <693254b91002221122h3fa59267rc59fc9030adf2341@mail.gmail.com> Message-ID: On Mon, Feb 22, 2010 at 11:22 AM, Tatsuhiko Miyagawa wrote: > Hi, > > May I plug my recent super-tiny and less-sucky CPAN installer > 'cpanminus' before/during/after the talk? This is to change the > landscape of CPAN toolchain ecosystem. Yeah, that looks interesting. We'll grab five minutes either before or after. Do you have a cpanplus plugin for it? :) > > http://github.com/miyagawa/cpanminus > http://marcus.nordaaker.com/2010/02/cpanminus-the-new-cpan-superstar/ > http://www.reddit.com/r/perl/comments/b4ryf/cpanminus_the_new_cpan_superstar/ > > On Mon, Feb 22, 2010 at 11:18 AM, Fred Moyer wrote: >> Tomorrow at 7pm at Six Apart World Headquarters Jeff Thalhammer will >> speak on why you should create CPAN distros, even for proprietary >> code. He has worked on worked on several projects where all the >> private code was organized into CPAN-style distros, and then injected >> into a local copy of CPAN. They then used the CPAN tool chain to >> manage the entire build, test, and release process. >> >> Please RSVP at Meetup: > > > > > -- > Tatsuhiko Miyagawa > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > From miyagawa at gmail.com Mon Feb 22 11:34:01 2010 From: miyagawa at gmail.com (Tatsuhiko Miyagawa) Date: Mon, 22 Feb 2010 11:34:01 -0800 Subject: [sf-perl] Reminder - "Why you should create CPAN distros" is tomorrow In-Reply-To: References: <693254b91002221122h3fa59267rc59fc9030adf2341@mail.gmail.com> Message-ID: <693254b91002221134i29aa8861t957b45fa99ee3a5b@mail.gmail.com> > > Yeah, that looks interesting. ?We'll grab five minutes either before or after. > > Do you have a cpanplus plugin for it? ?:) No, if you're fine with cpanplus then there's no point using cpanminus :) >> http://github.com/miyagawa/cpanminus >> http://marcus.nordaaker.com/2010/02/cpanminus-the-new-cpan-superstar/ >> http://www.reddit.com/r/perl/comments/b4ryf/cpanminus_the_new_cpan_superstar/ >> >> On Mon, Feb 22, 2010 at 11:18 AM, Fred Moyer wrote: >>> Tomorrow at 7pm at Six Apart World Headquarters Jeff Thalhammer will >>> speak on why you should create CPAN distros, even for proprietary >>> code. He has worked on worked on several projects where all the >>> private code was organized into CPAN-style distros, and then injected >>> into a local copy of CPAN. They then used the CPAN tool chain to >>> manage the entire build, test, and release process. >>> >>> Please RSVP at Meetup: >> >> >> >> >> -- >> Tatsuhiko Miyagawa >> _______________________________________________ >> 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 > -- Tatsuhiko Miyagawa From fred at redhotpenguin.com Mon Feb 22 11:55:48 2010 From: fred at redhotpenguin.com (Fred Moyer) Date: Mon, 22 Feb 2010 11:55:48 -0800 Subject: [sf-perl] Reminder - "Why you should create CPAN distros" is tomorrow In-Reply-To: <693254b91002221134i29aa8861t957b45fa99ee3a5b@mail.gmail.com> References: <693254b91002221122h3fa59267rc59fc9030adf2341@mail.gmail.com> <693254b91002221134i29aa8861t957b45fa99ee3a5b@mail.gmail.com> Message-ID: On Mon, Feb 22, 2010 at 11:34 AM, Tatsuhiko Miyagawa wrote: >> >> Yeah, that looks interesting. ?We'll grab five minutes either before or after. >> >> Do you have a cpanplus plugin for it? ?:) > > No, if you're fine with cpanplus then there's no point using cpanminus :) That was a little joke. Extremely little :) Saw some of your tweets yesterday about it, look forward to hearing more. From doom at kzsu.stanford.edu Mon Feb 22 14:45:42 2010 From: doom at kzsu.stanford.edu (Joe Brenner) Date: Mon, 22 Feb 2010 14:45:42 -0800 Subject: [sf-perl] running multiple perl versions In-Reply-To: References: Message-ID: <201002222245.o1MMjgV8003598@kzsu.stanford.edu> By the way, the other night brian d foy was asking me if there was a way for a debian-based distro to manage the dependencies of multiple perl versions. I thought about it a bit, and I think the answer is essentially "no". It *could* be done, but it would require doing what the postgresql folks have been doing: they put the version number in the package name, so you can install different versions of postgresql simultaneously. And in the case of perl, that would mean creating new packages for every (or at least many) perl modules, also with the version in the name. Myself, what I tend to do is leave the system's version of perl alone, and build my own. I also then need to do seperate installations of any perl modules I want to use with the different versions. So if need be I create "autobundles" using CPAN.pm or CPANPLUS.pm to clone an entire installation: http://www.perlmonks.org/?node_id=726221 From cweyl at alumni.drew.edu Mon Feb 22 16:12:15 2010 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 22 Feb 2010 16:12:15 -0800 Subject: [sf-perl] running multiple perl versions In-Reply-To: <201002222245.o1MMjgV8003598@kzsu.stanford.edu> References: <201002222245.o1MMjgV8003598@kzsu.stanford.edu> Message-ID: <7dd7ab491002221612r3a0ba7b0k5b27aa36416251ab@mail.gmail.com> On Mon, Feb 22, 2010 at 2:45 PM, Joe Brenner wrote: > > By the way, the other night brian d foy was asking me if there > was a way for a debian-based distro to manage the dependencies > of multiple perl versions. ?I thought about it a bit, and I think > the answer is essentially "no". > > It *could* be done, but it would require doing what the postgresql folks > have been doing: they put the version number in the package name, so you > can install different versions of postgresql simultaneously. And in the > case of perl, that would mean creating new packages for every (or at > least many) perl modules, also with the version in the name. I've done this at $work for RHEL/Fedora/SLES boxes, and every time I've had to do some pretty serious rework to the rpm specs to 1) not clobber the system perl or each other and 2) implement a dependency system that works independently of the system perl. Since regaining what was left of my sanity, I've pretty much given up on that approach: I tend to install "our" perl into /opt/perl and then manage the installation via git. It allows for easier testing of code w/updates from the CPAN, as well as making deployment easier ("git pull; git co new-production" against a bunch of s390x boxen, for instance). It "feels" a little messier, but it does the job quite well with a minimum of fuss -- and an easy, known backout plan if Something Bad happens. -Chris -- Chris Weyl Ex astris, scientia From miyagawa at gmail.com Mon Feb 22 16:16:46 2010 From: miyagawa at gmail.com (Tatsuhiko Miyagawa) Date: Mon, 22 Feb 2010 16:16:46 -0800 Subject: [sf-perl] running multiple perl versions In-Reply-To: <7dd7ab491002221612r3a0ba7b0k5b27aa36416251ab@mail.gmail.com> References: <201002222245.o1MMjgV8003598@kzsu.stanford.edu> <7dd7ab491002221612r3a0ba7b0k5b27aa36416251ab@mail.gmail.com> Message-ID: <693254b91002221616h7809acb2y66e124c402699714@mail.gmail.com> On Mon, Feb 22, 2010 at 4:12 PM, Chris Weyl wrote: > Since regaining what was left of my sanity, I've pretty much given up > on that approach: I tend to install "our" perl into /opt/perl and then > manage the installation via git. ?It allows for easier testing of code > w/updates from the CPAN, as well as making deployment easier ("git > pull; git co new-production" against a bunch of s390x boxen, for > instance). ?It "feels" a little messier, but it does the job quite > well with a minimum of fuss -- and an easy, known backout plan if > Something Bad happens. cpanminus has plugins branch on git and I have 'git_site_perl' plugin to exactly do this: whenever you install a new module using cpanminus, your site_perl (local::lib configured path or $Config{installsitelib}) files will be committed to git for versioning. http://github.com/miyagawa/cpanminus/blob/plugins/plugins/git_site_perl This is a rip off of nothingmuch's git-site-perl hook and actually works well with local::lib while his doesn't. http://blog.woobling.org/2009/10/versioned-sitelib.html -- Tatsuhiko Miyagawa From greg at blekko.com Mon Feb 22 18:06:30 2010 From: greg at blekko.com (Greg Lindahl) Date: Mon, 22 Feb 2010 18:06:30 -0800 Subject: [sf-perl] CentOS 5 victims needed Message-ID: <20100223020630.GD9399@bx9.net> Speaking of updating perl: we want to update to perl 5.10, but install everything the CentOS/Red Hat way, that is, in rpms. The benefit is keeping your sysadmin happy, with all of his rpm-based consistency and install tools. The minus is potential bugs with the gazillion packages that have perl code or use embedded perl. Our initial testing says that the OS doesn't really care what version of perl is installed; if you upgrade all the 5.8.8 rpms to 5.10, everything continues to work. We aren't quite to the place where we can give you a pointer to a repo and say "Have at it!", but I'd like to find out if anyone on this list might be interested in testing. Our goal is to maintain these rpms actively until we switch to CentOS 6. -- greg From fred at redhotpenguin.com Tue Feb 23 10:54:34 2010 From: fred at redhotpenguin.com (Fred Moyer) Date: Tue, 23 Feb 2010 10:54:34 -0800 Subject: [sf-perl] Reminder - "Why you should create CPAN distros" is tomorrow In-Reply-To: References: Message-ID: Please RSVP by 5:30pm if you plan to attend so I can use the Yes count to determine how much pizza to order. If you're on the fence about attending, ask yourself these questions: 1) Do I ship one giant rpm for releases containing many changes? 2) Is my development codebase one big root directory? 3) Do I have a hard time figuring out where parts of my application start, and where they end? If you answered yes to any of those questions, you should look at creating CPAN distros. On Mon, Feb 22, 2010 at 11:18 AM, Fred Moyer wrote: > Tomorrow at 7pm at Six Apart World Headquarters Jeff Thalhammer will > speak on why you should create CPAN distros, even for proprietary > code. He has worked on worked on several projects where all the > private code was organized into CPAN-style distros, and then injected > into a local copy of CPAN. They then used the CPAN tool chain to > manage the entire build, test, and release process. > > Please RSVP at Meetup: > > http://www.meetup.com/San-Francisco-Perl-Mongers/calendar/12509158/ > > Hope to see you there! > From doom at kzsu.stanford.edu Tue Feb 23 13:33:50 2010 From: doom at kzsu.stanford.edu (Joe Brenner) Date: Tue, 23 Feb 2010 13:33:50 -0800 Subject: [sf-perl] running multiple perl versions In-Reply-To: <201002222245.o1MMjgV8003598@kzsu.stanford.edu> References: <201002222245.o1MMjgV8003598@kzsu.stanford.edu> Message-ID: <201002232133.o1NLXoBQ023766@kzsu.stanford.edu> Joe Brenner wrote: > Myself, what I tend to do is leave the system's version of perl > alone, and build my own. I also then need to do seperate installations > of any perl modules I want to use with the different versions. > > So if need be I create "autobundles" using CPAN.pm or CPANPLUS.pm > to clone an entire installation: > > http://www.perlmonks.org/?node_id=726221 Thinking about this a bit more: What I'd be interested in myself is a variation of CPAN/CPANPLUS that installs modules for multiple perl versions simultaneously. They key might be a simple engine that runs the same code repeatedly using a list of perl binaries. It might also be useful in running a test suite against a whole range of perl's... From doom at kzsu.stanford.edu Tue Feb 23 13:36:18 2010 From: doom at kzsu.stanford.edu (Joe Brenner) Date: Tue, 23 Feb 2010 13:36:18 -0800 Subject: [sf-perl] Reminder - "Why you should create CPAN distros" is tomorrow In-Reply-To: References: Message-ID: <201002232136.o1NLaIFh023831@kzsu.stanford.edu> By the way... it seems to me that one major advantage of developing using a CPAN framework is that it's at least A Standard. The perl world doesn't have a lot in the way of standard practices, and it's worth thinking about embracing what little we've got in that direction. Fred Moyer wrote: > Please RSVP by 5:30pm if you plan to attend so I can use the Yes count > to determine how much pizza to order. > > If you're on the fence about attending, ask yourself these questions: > > 1) Do I ship one giant rpm for releases containing many changes? > > 2) Is my development codebase one big root directory? > > 3) Do I have a hard time figuring out where parts of my application > start, and where they end? > > If you answered yes to any of those questions, you should look at > creating CPAN distros. > > On Mon, Feb 22, 2010 at 11:18 AM, Fred Moyer wrote: > > Tomorrow at 7pm at Six Apart World Headquarters Jeff Thalhammer will > > speak on why you should create CPAN distros, even for proprietary > > code. He has worked on worked on several projects where all the > > private code was organized into CPAN-style distros, and then injected > > into a local copy of CPAN. They then used the CPAN tool chain to > > manage the entire build, test, and release process. > > > > Please RSVP at Meetup: > > > > http://www.meetup.com/San-Francisco-Perl-Mongers/calendar/12509158/ > > > > Hope to see you there! > > > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm From eruby at knowledgematters.net Tue Feb 23 14:51:07 2010 From: eruby at knowledgematters.net (Earl Ruby) Date: Tue, 23 Feb 2010 14:51:07 -0800 Subject: [sf-perl] Perl Standards / Perl Best Practices Message-ID: Have you read _Perl Best Practices_? Appendix A & B are a quick read, and give you a feel for the book's contents: http://oreilly.com/catalog/9780596001735/preview On Tue, Feb 23, 2010 at 1:36 PM, Joe Brenner wrote: > By the way... it seems to me that one major advantage of developing > using a CPAN framework is that it's at least A Standard. ?The perl world > doesn't have a lot in the way of standard practices, and it's worth > thinking about embracing what little we've got in that direction. -- Earl Ruby http://earlruby.org/ From miyagawa at gmail.com Tue Feb 23 15:42:41 2010 From: miyagawa at gmail.com (Tatsuhiko Miyagawa) Date: Tue, 23 Feb 2010 15:42:41 -0800 Subject: [sf-perl] running multiple perl versions In-Reply-To: <201002232133.o1NLXoBQ023766@kzsu.stanford.edu> References: <201002222245.o1MMjgV8003598@kzsu.stanford.edu> <201002232133.o1NLXoBQ023766@kzsu.stanford.edu> Message-ID: <693254b91002231542w5de35bj2d8e49cd0412cda1@mail.gmail.com> On Tue, Feb 23, 2010 at 1:33 PM, Joe Brenner wrote: > > Thinking about this a bit more: > > What I'd be interested in myself is a variation of CPAN/CPANPLUS that > installs modules for multiple perl versions simultaneously. Take a look at the latest cpanminus. It has a developer option to specify perl path (which defaults to $^X). So you can easily shell script it to iterate over multiple perls. > They key might be a simple engine that runs the same code repeatedly > using a list of perl binaries. > > It might also be useful in running a test suite against a whole range > of perl's... > > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > -- Tatsuhiko Miyagawa From bob.goolsby at gmail.com Tue Feb 23 15:44:06 2010 From: bob.goolsby at gmail.com (Bob goolsby) Date: Tue, 23 Feb 2010 15:44:06 -0800 Subject: [sf-perl] Perl Standards / Perl Best Practices In-Reply-To: References: Message-ID: <1a208dd1002231544i55c54ff2ka1829685349c6e1c@mail.gmail.com> Why yes I have; cover to cover; twice. There is a lot of Damian that I agree with, and there are some things that I don't. We had an interesting hall-way track at PerlCon a couple of years ago..... On Tue, Feb 23, 2010 at 2:51 PM, Earl Ruby wrote: > Have you read _Perl Best Practices_? > > Appendix A & B are a quick read, and give you a feel for the book's > contents: http://oreilly.com/catalog/9780596001735/preview > > On Tue, Feb 23, 2010 at 1:36 PM, Joe Brenner wrote: >> By the way... it seems to me that one major advantage of developing >> using a CPAN framework is that it's at least A Standard. ?The perl world >> doesn't have a lot in the way of standard practices, and it's worth >> thinking about embracing what little we've got in that direction. > > -- > Earl Ruby > http://earlruby.org/ > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > -- B Bob Goolsby bob.goolsby at gmail.com From quinn at fairpath.com Tue Feb 23 16:11:43 2010 From: quinn at fairpath.com (Quinn Weaver) Date: Tue, 23 Feb 2010 16:11:43 -0800 Subject: [sf-perl] Perl Standards / Perl Best Practices In-Reply-To: <1a208dd1002231544i55c54ff2ka1829685349c6e1c@mail.gmail.com> References: <1a208dd1002231544i55c54ff2ka1829685349c6e1c@mail.gmail.com> Message-ID: <6ebbd8771002231611j7f120e36q5297b1e1c1794e5f@mail.gmail.com> I swear by most of that book, but I swear *at* some of the modules Damian's written. Class::Std in particular once really dorked me with its lack of thread safety. Then I graduated to Object::InsideOut, and, finally (?), Moose. On Tue, Feb 23, 2010 at 3:44 PM, Bob goolsby wrote: > Why yes I have; cover to cover; twice. > > There is a lot of Damian that I agree with, and there are some things > that I don't. ?We had an interesting hall-way track at PerlCon a > couple of years ago..... > > > > > On Tue, Feb 23, 2010 at 2:51 PM, Earl Ruby wrote: >> Have you read _Perl Best Practices_? >> >> Appendix A & B are a quick read, and give you a feel for the book's >> contents: http://oreilly.com/catalog/9780596001735/preview >> >> On Tue, Feb 23, 2010 at 1:36 PM, Joe Brenner wrote: >>> By the way... it seems to me that one major advantage of developing >>> using a CPAN framework is that it's at least A Standard. ?The perl world >>> doesn't have a lot in the way of standard practices, and it's worth >>> thinking about embracing what little we've got in that direction. >> >> -- >> Earl Ruby >> http://earlruby.org/ >> _______________________________________________ >> SanFrancisco-pm mailing list >> SanFrancisco-pm at pm.org >> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm >> > > > > -- > B > > Bob Goolsby > bob.goolsby at gmail.com > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > -- Quinn Weaver Consulting, LLC Full-stack web design and development http://quinnweaver.com/ 510-520-5217 From rjray at blackperl.com Tue Feb 23 16:17:36 2010 From: rjray at blackperl.com (Randy J. Ray) Date: Tue, 23 Feb 2010 16:17:36 -0800 Subject: [sf-perl] Perl Standards / Perl Best Practices In-Reply-To: <6ebbd8771002231611j7f120e36q5297b1e1c1794e5f@mail.gmail.com> References: <1a208dd1002231544i55c54ff2ka1829685349c6e1c@mail.gmail.com> <6ebbd8771002231611j7f120e36q5297b1e1c1794e5f@mail.gmail.com> Message-ID: <4B847020.20000@blackperl.com> Quinn Weaver wrote: > I swear by most of that book, but I swear *at* some of the modules > Damian's written. Class::Std in particular once really dorked me with > its lack of thread safety. Then I graduated to Object::InsideOut, > and, finally (?), Moose. I have some Class::Std code that I've been meaning to port to Moose, but have found the learning curve just steep-enough to discourage me thus far. Any recommendations? Randy -- """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" Randy J. Ray Sunnyvale, CA http://www.rjray.org rjray at blackperl.com Silicon Valley Scale Modelers: http://www.svsm.org From swartz at pobox.com Tue Feb 23 16:31:25 2010 From: swartz at pobox.com (Jonathan Swartz) Date: Tue, 23 Feb 2010 16:31:25 -0800 Subject: [sf-perl] Perl Standards / Perl Best Practices In-Reply-To: <4B847020.20000@blackperl.com> References: <1a208dd1002231544i55c54ff2ka1829685349c6e1c@mail.gmail.com> <6ebbd8771002231611j7f120e36q5297b1e1c1794e5f@mail.gmail.com> <4B847020.20000@blackperl.com> Message-ID: <9F38286E-8003-4B4F-BD24-6BFABFE07020@pobox.com> > Quinn Weaver wrote: >> I swear by most of that book, but I swear *at* some of the modules >> Damian's written. Class::Std in particular once really dorked me >> with >> its lack of thread safety. Then I graduated to Object::InsideOut, >> and, finally (?), Moose. > > I have some Class::Std code that I've been meaning to port to Moose, > but have found the learning curve just steep-enough to discourage me > thus far. Any recommendations? > The basic Moose usage is pretty simple, I've always thought. Have you checked out the cookbook: http://search.cpan.org/~drolsky/Moose/lib/Moose/Cookbook.pod and the manual: http://search.cpan.org/~drolsky/Moose-0.98/lib/Moose/Manual.pod What in particular did you get stuck on? Jon From bob.goolsby at gmail.com Tue Feb 23 16:44:35 2010 From: bob.goolsby at gmail.com (Bob goolsby) Date: Tue, 23 Feb 2010 16:44:35 -0800 Subject: [sf-perl] Perl Standards / Perl Best Practices In-Reply-To: <6ebbd8771002231611j7f120e36q5297b1e1c1794e5f@mail.gmail.com> References: <1a208dd1002231544i55c54ff2ka1829685349c6e1c@mail.gmail.com> <6ebbd8771002231611j7f120e36q5297b1e1c1794e5f@mail.gmail.com> Message-ID: <1a208dd1002231644n7165f80eoc226c40dad1d2164@mail.gmail.com> Moose++ On Tue, Feb 23, 2010 at 4:11 PM, Quinn Weaver wrote: > I swear by most of that book, but I swear *at* some of the modules > Damian's written. ?Class::Std in particular once really dorked me with > its lack of thread safety. ?Then I graduated to Object::InsideOut, > and, finally (?), Moose. > > On Tue, Feb 23, 2010 at 3:44 PM, Bob goolsby wrote: >> Why yes I have; cover to cover; twice. >> >> There is a lot of Damian that I agree with, and there are some things >> that I don't. ?We had an interesting hall-way track at PerlCon a >> couple of years ago..... >> >> >> >> >> On Tue, Feb 23, 2010 at 2:51 PM, Earl Ruby wrote: >>> Have you read _Perl Best Practices_? >>> >>> Appendix A & B are a quick read, and give you a feel for the book's >>> contents: http://oreilly.com/catalog/9780596001735/preview >>> >>> On Tue, Feb 23, 2010 at 1:36 PM, Joe Brenner wrote: >>>> By the way... it seems to me that one major advantage of developing >>>> using a CPAN framework is that it's at least A Standard. ?The perl world >>>> doesn't have a lot in the way of standard practices, and it's worth >>>> thinking about embracing what little we've got in that direction. >>> >>> -- >>> Earl Ruby >>> http://earlruby.org/ >>> _______________________________________________ >>> SanFrancisco-pm mailing list >>> SanFrancisco-pm at pm.org >>> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm >>> >> >> >> >> -- >> B >> >> Bob Goolsby >> bob.goolsby at gmail.com >> _______________________________________________ >> SanFrancisco-pm mailing list >> SanFrancisco-pm at pm.org >> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm >> > > > > -- > Quinn Weaver Consulting, LLC > Full-stack web design and development > http://quinnweaver.com/ > 510-520-5217 > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > -- B Bob Goolsby bob.goolsby at gmail.com From quinn at fairpath.com Tue Feb 23 17:00:34 2010 From: quinn at fairpath.com (Quinn Weaver) Date: Tue, 23 Feb 2010 17:00:34 -0800 Subject: [sf-perl] Perl Standards / Perl Best Practices In-Reply-To: <9F38286E-8003-4B4F-BD24-6BFABFE07020@pobox.com> References: <1a208dd1002231544i55c54ff2ka1829685349c6e1c@mail.gmail.com> <6ebbd8771002231611j7f120e36q5297b1e1c1794e5f@mail.gmail.com> <4B847020.20000@blackperl.com> <9F38286E-8003-4B4F-BD24-6BFABFE07020@pobox.com> Message-ID: <6ebbd8771002231700o3e1a6edcu74931146543d27c3@mail.gmail.com> On Tue, Feb 23, 2010 at 4:31 PM, Jonathan Swartz wrote: >> Quinn Weaver wrote: >>> >>> I swear by most of that book, but I swear *at* some of the modules >>> Damian's written. ?Class::Std in particular once really dorked me with >>> its lack of thread safety. ?Then I graduated to Object::InsideOut, >>> and, finally (?), Moose. >> >> I have some Class::Std code that I've been meaning to port to Moose, but >> have found the learning curve just steep-enough to discourage me thus far. >> Any recommendations? >> > > The basic Moose usage is pretty simple, I've always thought. Have you > checked out the cookbook: > > ? ?http://search.cpan.org/~drolsky/Moose/lib/Moose/Cookbook.pod > > and the manual: > > ? ?http://search.cpan.org/~drolsky/Moose-0.98/lib/Moose/Manual.pod I agree. I used those very same pages. I just picked up Moose recently, and it wasn't hard. One thing I have yet to find is a good Moose singleton module. MooseX::Singleton has been failing, complaining that new has already been called (today, actually). That sort of defeats the purpose of a singleton. ;) Also, I'm a bit peeved that protected and private methods aren't part of the base system. But practically it's not really an issue to have everything rw publicly. After all, Perl programmers have been doing it for years. :P -- Quinn Weaver Consulting, LLC Full-stack web design and development http://quinnweaver.com/ 510-520-5217 From bryan at beeley.org Tue Feb 23 17:07:19 2010 From: bryan at beeley.org (Bryan Beeley) Date: Tue, 23 Feb 2010 17:07:19 -0800 Subject: [sf-perl] Perl Standards / Perl Best Practices In-Reply-To: <9F38286E-8003-4B4F-BD24-6BFABFE07020@pobox.com> References: <1a208dd1002231544i55c54ff2ka1829685349c6e1c@mail.gmail.com> <6ebbd8771002231611j7f120e36q5297b1e1c1794e5f@mail.gmail.com> <4B847020.20000@blackperl.com> <9F38286E-8003-4B4F-BD24-6BFABFE07020@pobox.com> Message-ID: <4B847BC7.2030800@beeley.org> I read through the Manual and Cookbook, but the syntax and concepts were different enough from standard Perl to make it hard to get my arms around. I think my attempt at writing code from scratch using Moose made it hard to digest. What finally got me over the hump was writing Catalyst and HTML::FormHandler based code that made use of the fact that both packages are now written in Moose. Once I started to read Moose code and write code for Moose APIs, things started to click. Now that I have, I would much rather write Moose code than standard OOP. Bryan Jonathan Swartz wrote: >> Quinn Weaver wrote: >>> I swear by most of that book, but I swear *at* some of the modules >>> Damian's written. Class::Std in particular once really dorked me with >>> its lack of thread safety. Then I graduated to Object::InsideOut, >>> and, finally (?), Moose. >> >> I have some Class::Std code that I've been meaning to port to Moose, >> but have found the learning curve just steep-enough to discourage me >> thus far. Any recommendations? >> > > The basic Moose usage is pretty simple, I've always thought. Have you > checked out the cookbook: > > http://search.cpan.org/~drolsky/Moose/lib/Moose/Cookbook.pod > > and the manual: > > http://search.cpan.org/~drolsky/Moose-0.98/lib/Moose/Manual.pod > > What in particular did you get stuck on? > > Jon > > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm From hartzell at alerce.com Tue Feb 23 17:58:55 2010 From: hartzell at alerce.com (George Hartzell) Date: Tue, 23 Feb 2010 17:58:55 -0800 Subject: [sf-perl] Perl Standards / Perl Best Practices In-Reply-To: <4B847020.20000@blackperl.com> References: <1a208dd1002231544i55c54ff2ka1829685349c6e1c@mail.gmail.com> <6ebbd8771002231611j7f120e36q5297b1e1c1794e5f@mail.gmail.com> <4B847020.20000@blackperl.com> Message-ID: <19332.34783.712805.407314@gargle.gargle.HOWL> Randy J. Ray writes: > Quinn Weaver wrote: > > I swear by most of that book, but I swear *at* some of the modules > > Damian's written. Class::Std in particular once really dorked me with > > its lack of thread safety. Then I graduated to Object::InsideOut, > > and, finally (?), Moose. > > I have some Class::Std code that I've been meaning to port to Moose, but have > found the learning curve just steep-enough to discourage me thus far. Any > recommendations? > I find Dave Rolksky's Moose class notes useful (I actually took the class at YAPC, but I think that you can work through the notes and do the exercises): http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=gitmo/moose-presentations.git;a=tree;f=moose-class And Shawn Moore's talk from frozen perl is useful too. http://sartak.org/talks/frozen-perl-2009/moose/ although it still refers to MooseX::AttributeHelpers instead of the newer core version (Moose::Meta::...) of the same functionality. These may be a bit more of an overview though. What are you stumbling on? g. From doom at kzsu.stanford.edu Wed Feb 24 10:15:59 2010 From: doom at kzsu.stanford.edu (Joe Brenner) Date: Wed, 24 Feb 2010 10:15:59 -0800 Subject: [sf-perl] Perl Standards / Perl Best Practices In-Reply-To: <1a208dd1002231544i55c54ff2ka1829685349c6e1c@mail.gmail.com> References: <1a208dd1002231544i55c54ff2ka1829685349c6e1c@mail.gmail.com> Message-ID: <201002241816.o1OIFxxL042086@kzsu.stanford.edu> Bob goolsby wrote: > Why yes I have; cover to cover; twice. Yes, myself I'm up to three times. > There is a lot of Damian that I agree with, and there are some > things that I don't. My last time through, I categorized all the recommendations: do I disagree or agree, and if I did agree, did it require me to change what I do? I like the book quite a bit, but I have problems with around a third of the recommendations. Anyway, the sort of thing I was talking about is stuff that Damien doesn't touch on... little things like: wouldn't it be nice if when you dive into a new perl code base if you always knew where to look for the tests for the module you have open? From fred at redhotpenguin.com Wed Feb 24 14:09:07 2010 From: fred at redhotpenguin.com (Fred Moyer) Date: Wed, 24 Feb 2010 14:09:07 -0800 Subject: [sf-perl] Perl Standards / Perl Best Practices In-Reply-To: <1a208dd1002231544i55c54ff2ka1829685349c6e1c@mail.gmail.com> References: <1a208dd1002231544i55c54ff2ka1829685349c6e1c@mail.gmail.com> Message-ID: On Tue, Feb 23, 2010 at 3:44 PM, Bob goolsby wrote: > Why yes I have; cover to cover; twice. > > There is a lot of Damian that I agree with, and there are some things > that I don't. ?We had an interesting hall-way track at PerlCon a > couple of years ago..... It is worth considering that Damian made a point of doing 256 best practices (2**8). So an indeterminate number of those may only be there 'because'. Some I think are critical (such as using bare returns from subs instead of returning undefined), but others are window dressing. In my experience, I think there is a lot of good practices in there, but trying to implement all of the practices in that book for a multiple person development is insanity. The overhead of debating the merits of controversial practices is more harmful than the practices themselves. > On Tue, Feb 23, 2010 at 2:51 PM, Earl Ruby wrote: >> Have you read _Perl Best Practices_? >> >> Appendix A & B are a quick read, and give you a feel for the book's >> contents: http://oreilly.com/catalog/9780596001735/preview >> >> On Tue, Feb 23, 2010 at 1:36 PM, Joe Brenner wrote: >>> By the way... it seems to me that one major advantage of developing >>> using a CPAN framework is that it's at least A Standard. ?The perl world >>> doesn't have a lot in the way of standard practices, and it's worth >>> thinking about embracing what little we've got in that direction. >> >> -- >> Earl Ruby >> http://earlruby.org/ >> _______________________________________________ >> SanFrancisco-pm mailing list >> SanFrancisco-pm at pm.org >> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm >> > > > > -- > B > > Bob Goolsby > bob.goolsby at gmail.com > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm > From quinn at fairpath.com Wed Feb 24 21:34:28 2010 From: quinn at fairpath.com (Quinn Weaver) Date: Wed, 24 Feb 2010 21:34:28 -0800 Subject: [sf-perl] Perl Standards / Perl Best Practices In-Reply-To: <201002241816.o1OIFxxL042086@kzsu.stanford.edu> References: <1a208dd1002231544i55c54ff2ka1829685349c6e1c@mail.gmail.com> <201002241816.o1OIFxxL042086@kzsu.stanford.edu> Message-ID: <6ebbd8771002242134q28ec86a9je468bbf6fa5bc54b@mail.gmail.com> On Wed, Feb 24, 2010 at 10:15 AM, Joe Brenner wrote: > > Bob goolsby wrote: > >> Why yes I have; cover to cover; twice. > > Yes, myself I'm up to three times. > >> There is a lot of Damian that I agree with, and there are some >> things that I don't. > > My last time through, I categorized all the recommendations: > do I disagree or agree, and if I did agree, did it require me to > change what I do? I did this, then wrote a custom .perlcriticrc, then still found myself doing ## no critic sometimes to override a given rule. As in art, so in code: sometimes you know the rules but choose to break them for good reasons. > Anyway, the sort of thing I was talking about is stuff that > Damien doesn't touch on... little things like: wouldn't it be > nice if when you dive into a new perl code base if you always > knew where to look for the tests for the module you have open? Yeah. I use Module::Foo::Bar, $TOP_LEVEL/t/Module-Foo-Bar.t , but not everyone does that. -- Quinn Weaver Consulting, LLC Full-stack web design and development http://quinnweaver.com/ 510-520-5217 From brian.friday at gmail.com Thu Feb 25 07:34:49 2010 From: brian.friday at gmail.com (Brian Friday) Date: Thu, 25 Feb 2010 07:34:49 -0800 Subject: [sf-perl] Related to Perl Best Practices / a Perl::Critic Rule Message-ID: There is one specific Perl::Critic rule that confounds me and I am wondering if anyone can shed any light into the why of it. You have a Perl program with: print "Something\n"; Run it through Perl::Critic and you get the following error: Return value of flagged function ignored - print at line 27, column 1. See pages 208,278 of PBP. (Severity: 1) Change the line to: print "Something\n" or croak "blah\n"; Perl::Critic no longer has any issues with the code, life continues on. If the print had a $var call in it, this croak does not stop you from printing on uninitialized values. I have been mulling it over but for print itself I have not been able to find a definitive "this is a good idea because...." . Thoughts? I treat the PBP and Perl::Critic as a guide to good Perl coding behavior and not a book of rules. That said I like to understand a rule before I throw it out. This rule just happens to be one I come back to because no answer I have come up with pushes me over the use it side or lose it side of the fence. - Brian From danlyke at flutterby.com Thu Feb 25 08:29:04 2010 From: danlyke at flutterby.com (Dan Lyke) Date: Thu, 25 Feb 2010 08:29:04 -0800 Subject: [sf-perl] Related to Perl Best Practices / a Perl::Critic Rule In-Reply-To: References: Message-ID: <20100225082904.2a474bcf@danlyke-laptop> On Thu, 25 Feb 2010 07:34:49 -0800 Brian Friday wrote: > If the print had a $var call in it, this croak does not stop you from > printing on uninitialized values. I have been mulling it over but for > print itself I have not been able to find a definitive "this is a > good idea because...." . Just a guess: You're basically not checking the return call from "write". If you were printing to a socket or a file, it might be important to know if that call failed. And almost always, I think you want a "die" if that call fails, but I can see where asking daemon coders to wrap socket prints in eval{} statements isn't the right thing. Dan From quinn at fairpath.com Thu Feb 25 10:48:23 2010 From: quinn at fairpath.com (Quinn Weaver) Date: Thu, 25 Feb 2010 10:48:23 -0800 Subject: [sf-perl] Related to Perl Best Practices / a Perl::Critic Rule In-Reply-To: References: Message-ID: <94785ADF-1A36-4ABB-9D0E-5D7D444B4D85@fairpath.com> Damian thinks you should always check return values of builtins (or throw exceptions?the theory is that halting is safer than continuing in case things go pear-shaped). I tend to use autodie; for this kind of thing. I also tend to have a top-level eval that catches any otherwise uncaught exception and bails appropriately (if I'm not already working in a framework that does that for me). -- Quinn Weaver Consulting, LLC Full-stack web design and development http://quinnweaver.com/ 510-520-5217 On Feb 25, 2010, at 7:34 AM, Brian Friday wrote: > > There is one specific Perl::Critic rule that confounds me and I am > wondering if anyone can shed any light into the why of it. > > You have a Perl program with: > > print "Something\n"; > > Run it through Perl::Critic and you get the following error: > > Return value of flagged function ignored - print at line 27, > column 1. See pages 208,278 of PBP. (Severity: 1) > > Change the line to: > > print "Something\n" or croak "blah\n"; > > Perl::Critic no longer has any issues with the code, life continues > on. > > If the print had a $var call in it, this croak does not stop you > from printing on uninitialized values. I have been mulling it over > but for print itself I have not been able to find a definitive "this > is a good idea because...." . > > Thoughts? > > I treat the PBP and Perl::Critic as a guide to good Perl coding > behavior and not a book of rules. That said I like to understand a > rule before I throw it out. This rule just happens to be one I come > back to because no answer I have come up with pushes me over the use > it side or lose it side of the fence. > > - Brian > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm From swartz at pobox.com Thu Feb 25 10:58:09 2010 From: swartz at pobox.com (Jonathan Swartz) Date: Thu, 25 Feb 2010 10:58:09 -0800 Subject: [sf-perl] Related to Perl Best Practices / a Perl::Critic Rule In-Reply-To: <94785ADF-1A36-4ABB-9D0E-5D7D444B4D85@fairpath.com> References: <94785ADF-1A36-4ABB-9D0E-5D7D444B4D85@fairpath.com> Message-ID: <12514A8E-2B45-404E-B372-055CD5E61281@pobox.com> Ok - but seriously - print "Something\n"; ??? Seems like there ought to be an exception to the rule for that. I've never noticed critic complaining about this, but I run at level 3. On Feb 25, 2010, at 10:48 AM, Quinn Weaver wrote: > Damian thinks you should always check return values of builtins (or > throw exceptions?the theory is that halting is safer than continuing > in case things go pear-shaped). > > I tend to use autodie; for this kind of thing. I also tend to have a > top-level eval that catches any otherwise uncaught exception and > bails appropriately (if I'm not already working in a framework that > does that for me). > > -- > Quinn Weaver Consulting, LLC > Full-stack web design and development > http://quinnweaver.com/ > 510-520-5217 > > > On Feb 25, 2010, at 7:34 AM, Brian Friday > wrote: > >> >> There is one specific Perl::Critic rule that confounds me and I am >> wondering if anyone can shed any light into the why of it. >> >> You have a Perl program with: >> >> print "Something\n"; >> >> Run it through Perl::Critic and you get the following error: >> >> Return value of flagged function ignored - print at line 27, >> column 1. See pages 208,278 of PBP. (Severity: 1) >> >> Change the line to: >> >> print "Something\n" or croak "blah\n"; >> >> Perl::Critic no longer has any issues with the code, life continues >> on. >> >> If the print had a $var call in it, this croak does not stop you >> from printing on uninitialized values. I have been mulling it over >> but for print itself I have not been able to find a definitive >> "this is a good idea because...." . >> >> Thoughts? >> >> I treat the PBP and Perl::Critic as a guide to good Perl coding >> behavior and not a book of rules. That said I like to understand a >> rule before I throw it out. This rule just happens to be one I come >> back to because no answer I have come up with pushes me over the >> use it side or lose it side of the fence. >> >> - Brian >> _______________________________________________ >> 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 From quinn at fairpath.com Thu Feb 25 11:40:04 2010 From: quinn at fairpath.com (Quinn Weaver) Date: Thu, 25 Feb 2010 11:40:04 -0800 Subject: [sf-perl] Related to Perl Best Practices / a Perl::Critic Rule In-Reply-To: <12514A8E-2B45-404E-B372-055CD5E61281@pobox.com> References: <94785ADF-1A36-4ABB-9D0E-5D7D444B4D85@fairpath.com> <12514A8E-2B45-404E-B372-055CD5E61281@pobox.com> Message-ID: <6ebbd8771002251140m379c59f7n5c3a32665d83e98d@mail.gmail.com> On Thu, Feb 25, 2010 at 10:58 AM, Jonathan Swartz wrote: > Ok - but seriously - > > ? print "Something\n"; > > ??? Yeah, it's a little over-the-top. Love it or hate it, this is Damian's style: he takes an idea and pushes it as far as he can. The results are sometimes really interesting, sometimes overengineered, but usually both. Have you ever checked out Getopt::Declare? or Lingua::Romana::Perligata? -- Quinn Weaver Consulting, LLC Full-stack web design and development http://quinnweaver.com/ 510-520-5217 From Paul.Makepeace at realprogrammers.com Thu Feb 25 22:03:56 2010 From: Paul.Makepeace at realprogrammers.com (Paul Makepeace) Date: Fri, 26 Feb 2010 14:03:56 +0800 Subject: [sf-perl] Related to Perl Best Practices / a Perl::Critic Rule In-Reply-To: <94785ADF-1A36-4ABB-9D0E-5D7D444B4D85@fairpath.com> References: <94785ADF-1A36-4ABB-9D0E-5D7D444B4D85@fairpath.com> Message-ID: On Fri, Feb 26, 2010 at 02:48, Quinn Weaver wrote: > Damian thinks you should always check return values of builtins (or throw > exceptions?the theory is that halting is safer than continuing in case > things go pear-shaped). There is definitely some mileage to checking print & close(!) when doing IPC. That stuff can really be a PITA to debug. Knowing your close failed, i.e. exactly where can really save a lot of time. On the whole though it definitely strikes me as counter-pragmatic... (or yet another reason to have native exceptions in a language ;)) > > I tend to use autodie; for this kind of thing. I also tend to have a > top-level eval that catches any otherwise uncaught exception and bails > appropriately (if I'm not already working in a framework that does that for > me). > > -- > Quinn Weaver Consulting, LLC > Full-stack web design and development > http://quinnweaver.com/ > 510-520-5217 > > > On Feb 25, 2010, at 7:34 AM, Brian Friday wrote: > >> >> There is one specific Perl::Critic rule that confounds me and I am >> wondering if anyone can shed any light into the why of it. >> >> You have a Perl program with: >> >> ? print "Something\n"; >> >> Run it through Perl::Critic and you get the following error: >> >> ? Return value of flagged function ignored - print at line 27, column 1. >> ?See pages 208,278 of PBP. ?(Severity: 1) >> >> Change the line to: >> >> ? print "Something\n" or croak "blah\n"; >> >> Perl::Critic no longer has any issues with the code, life continues on. >> >> If the print had a $var call in it, this croak does not stop you from >> printing on uninitialized values. I have been mulling it over but for print >> itself I have not been able to find a definitive "this is a good idea >> because...." . >> >> Thoughts? >> >> I treat the PBP and Perl::Critic as a guide to good Perl coding behavior >> and not a book of rules. That said I like to understand a rule before I >> throw it out. This rule just happens to be one I come back to because no >> answer I have come up with pushes me over the use it side or lose it side of >> the fence. >> >> - Brian >> _______________________________________________ >> 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 > From fred at redhotpenguin.com Fri Feb 26 14:13:44 2010 From: fred at redhotpenguin.com (Fred Moyer) Date: Fri, 26 Feb 2010 14:13:44 -0800 Subject: [sf-perl] cpanminus Message-ID: I got around to installing cpanminus via github today after CPAN borked the install. Best thing since 'use strict'. From extasia at extasia.org Fri Feb 26 14:21:11 2010 From: extasia at extasia.org (David Alban) Date: Fri, 26 Feb 2010 14:21:11 -0800 Subject: [sf-perl] [OT] shell signal question Message-ID: <4c714a9c1002261421r73fe3a30k2254be3eb608ce5a@mail.gmail.com> greetings, spent a little time web searching, and looking through the bash man page but can't find an answer yet.... when in a bash function called as a result of a trap, how does one identify the signal caught? tried running: #!/bin/bash foo () { set 2>&1 | sed "s/^/set: /" env 2>&1 | sed "s/^/env: /" exit 42 } # foo #======================================================================= trap foo 1 2 3 11 15 echo pid=$$ echo sleeping... sleep 60 exit 0 and interrupting it and looking for any clue in set and env output. couldn't find anything indicating which signal the program received. what am i missing? thanks, david -- Live in a world of your own, but always welcome visitors. From jeff at imaginative-software.com Fri Feb 26 16:40:20 2010 From: jeff at imaginative-software.com (Jeffrey Thalhammer) Date: Fri, 26 Feb 2010 16:40:20 -0800 Subject: [sf-perl] Slides from Tuesday's talk Message-ID: Hi Everyone- Thank you so much for inviting me to speak this past Tuesday. The slides for my presentation on using CPAN For Private Code are available on Slideshare here: http://www.slideshare.net/thaljef/cpan-for-private-code Special thanks to Fred Moyer and SixApart for another fabulous Perl Monger meeting. See you all again next month! Jeffrey Thalhammer Imaginative Software Systems vcard: http://www.imaginative-software.com/contact/jeff.vcf From hartzell at alerce.com Fri Feb 26 18:02:19 2010 From: hartzell at alerce.com (George Hartzell) Date: Fri, 26 Feb 2010 18:02:19 -0800 Subject: [sf-perl] cpanminus In-Reply-To: References: Message-ID: <19336.32043.491525.659171@gargle.gargle.HOWL> Fred Moyer writes: > I got around to installing cpanminus via github today after CPAN > borked the install. cpanminus looks really neat, except for the part where it screen scrapes to find things. We just had brian d foy help us set up a local dpan and it doesn't seem like there's any way to point cpanminus at it.... g. From miyagawa at gmail.com Sat Feb 27 00:57:58 2010 From: miyagawa at gmail.com (Tatsuhiko Miyagawa) Date: Sat, 27 Feb 2010 00:57:58 -0800 Subject: [sf-perl] cpanminus In-Reply-To: <19336.32043.491525.659171@gargle.gargle.HOWL> References: <19336.32043.491525.659171@gargle.gargle.HOWL> Message-ID: <693254b91002270057m8fe2b34od5f2e0a31950aea8@mail.gmail.com> On Fri, Feb 26, 2010 at 6:02 PM, George Hartzell wrote: > Fred Moyer writes: > ?> I got around to installing cpanminus via github today after CPAN > ?> borked the install. > > cpanminus looks really neat, except for the part where it screen > scrapes to find things. As it's documented, I'm working with people running CPAN to address this. There are plugins (in the dev release and on github) to enable hitting database service run by BinGOs and mst instead of screen scraping. >?We just had brian d foy help us set up a > local dpan and it doesn't seem like there's any way to point cpanminus > at it.... Take a look at 'minicpan' plugin -- which adds a fallback to look at your local CPAN::Mini mirrors. There's a plan to write 'dpan' plugin based on that. cpanminus should work great for 90% of the people (normal people) by default. Plugins should work with the other 9.9% advanced users like me. And I don't care about the rest 0.1%. -- Tatsuhiko Miyagawa From extasia at extasia.org Sat Feb 27 21:04:21 2010 From: extasia at extasia.org (David Alban) Date: Sat, 27 Feb 2010 21:04:21 -0800 Subject: [sf-perl] [OT] shell signal question In-Reply-To: <75cbfa571002261444k52958bb9s3abd7b163cacb157@mail.gmail.com> References: <4c714a9c1002261421r73fe3a30k2254be3eb608ce5a@mail.gmail.com> <75cbfa571002261444k52958bb9s3abd7b163cacb157@mail.gmail.com> Message-ID: <4c714a9c1002272104i52cc0292se7a0a3e48f1fd87e@mail.gmail.com> thanks! On Fri, Feb 26, 2010 at 2:44 PM, yary wrote: > Not obvious to me either. If you have an immediate need, set up one > signal trap wrapper for each signal you need to distinguish between, > which can call your mail signal handler with the signal number as an > argument. > > eg. > ?trap foo1 1 > trap foo2 2 > trap foo3 3 > trap foo11 11 > trap foo15 15 > > foo1() { foo 1} > foo2() {foo 2} > etc. -- Live in a world of your own, but always welcome visitors. From gatorreina at gmail.com Sun Feb 28 08:40:51 2010 From: gatorreina at gmail.com (Richard Reina) Date: Sun, 28 Feb 2010 10:40:51 -0600 Subject: [sf-perl] writing a hylafax client in perl Message-ID: <489cf9d1002280840w38752cecr2bdd607a9023041f@mail.gmail.com> I am in need of a program that allows users on our all linux LAN to view, save, print and delete incoming faxes. People on the Hylafax list have recommended a java client called YaJHFC. I did take a look at it looks nice, but does not really suit my needs --besides it's written in java :). What I need is something that helps users on the LAN associate faxes with various database records so they can be archived correctly. Accordingly, I am off to write my own GUI with perl->evince->mysql. I've got a lot of it done. However, I am looking for some input on one area of complication, accessing the received files on the Hylafax server. Essentially they need to be viewed associated with a record and saved on a local file server. To view them and save I assume I need to bring (copy) the file to the local machine where it can be viewed and the user can match it to a database record so that it can be renamed and archived. The complicated part seems that I need to (I guess) scp, ncftpget or rsync the files from the hylafax server. I guess what I would like to ask is: Does anyone know how other hylafax cleint deal with this? Are the files somehow viewed directly on the hylafax server through local machines via ssh? (something I have not yet been able to figure out how to do) Or are the files bounced around to be viewed and then saved? Thanks for any help. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From bferrell at baywinds.org Sun Feb 28 09:22:11 2010 From: bferrell at baywinds.org (Bruce Ferrell) Date: Sun, 28 Feb 2010 09:22:11 -0800 Subject: [sf-perl] writing a hylafax client in perl In-Reply-To: <489cf9d1002280840w38752cecr2bdd607a9023041f@mail.gmail.com> References: <489cf9d1002280840w38752cecr2bdd607a9023041f@mail.gmail.com> Message-ID: <4B8AA643.6040508@baywinds.org> Have you looked at Fax::Hylafax::Client on CPAN. it seems to have all the bits you'd need. On 02/28/2010 08:40 AM, Richard Reina wrote: > I am in need of a program that allows users on our all linux LAN to > view, save, print and delete incoming faxes. People on the Hylafax > list have recommended a java client called YaJHFC. I did take a look > at it looks nice, but does not really suit my needs --besides it's > written in java :). What I need is something that helps users on the > LAN associate faxes with various database records so they can be > archived correctly. Accordingly, I am off to write my own GUI with > perl->evince->mysql. I've got a lot of it done. However, I am > looking for some input on one area of complication, accessing the > received files on the Hylafax server. Essentially they need to be > viewed associated with a record and saved on a local file server. To > view them and save I assume I need to bring (copy) the file to the > local machine where it can be viewed and the user can match it to a > database record so that it can be renamed and archived. The > complicated part seems that I need to (I guess) scp, ncftpget or rsync > the files from the hylafax server. I guess what I would like to ask > is: Does anyone know how other hylafax cleint deal with this? Are the > files somehow viewed directly on the hylafax server through local > machines via ssh? (something I have not yet been able to figure out > how to do) Or are the files bounced around to be viewed and then saved? > > Thanks for any help. > > Richard > > > _______________________________________________ > 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: From gatorreina at gmail.com Sun Feb 28 11:09:46 2010 From: gatorreina at gmail.com (Richard Reina) Date: Sun, 28 Feb 2010 13:09:46 -0600 Subject: [sf-perl] writing a hylafax client in perl In-Reply-To: <4B8AA643.6040508@baywinds.org> References: <489cf9d1002280840w38752cecr2bdd607a9023041f@mail.gmail.com> <4B8AA643.6040508@baywinds.org> Message-ID: <489cf9d1002281109w3291056eldd690201a1510156@mail.gmail.com> No I have not. Thank you very much for the idea. I will check it out. 2010/2/28 Bruce Ferrell > > Have you looked at Fax::Hylafax::Client on CPAN. it seems to have all the > bits you'd need. > > > On 02/28/2010 08:40 AM, Richard Reina wrote: > > I am in need of a program that allows users on our all linux LAN to view, > save, print and delete incoming faxes. People on the Hylafax list have > recommended a java client called YaJHFC. I did take a look at it looks nice, > but does not really suit my needs --besides it's written in java :). What I > need is something that helps users on the LAN associate faxes with various > database records so they can be archived correctly. Accordingly, I am off > to write my own GUI with perl->evince->mysql. I've got a lot of it done. > However, I am looking for some input on one area of complication, accessing > the received files on the Hylafax server. Essentially they need to be viewed > associated with a record and saved on a local file server. To view them and > save I assume I need to bring (copy) the file to the local machine where it > can be viewed and the user can match it to a database record so that it can > be renamed and archived. The complicated part seems that I need to (I > guess) scp, ncftpget or rsync the files from the hylafax server. I guess > what I would like to ask is: Does anyone know how other hylafax cleint deal > with this? Are the files somehow viewed directly on the hylafax server > through local machines via ssh? (something I have not yet been able to > figure out how to do) Or are the files bounced around to be viewed and then > saved? > > Thanks for any help. > > Richard > > > _______________________________________________ > SanFrancisco-pm mailing listSanFrancisco-pm at pm.orghttp://mail.pm.org/mailman/listinfo/sanfrancisco-pm > > > > _______________________________________________ > 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: From gatorreina at gmail.com Sun Feb 28 18:22:06 2010 From: gatorreina at gmail.com (Richard Reina) Date: Sun, 28 Feb 2010 20:22:06 -0600 Subject: [sf-perl] determining console or xwindows mode Message-ID: <489cf9d1002281822v15e08490geb86dbc465dc669d@mail.gmail.com> I have a program that must run differently in xwindows then it would on a linux console. I was wondering if there's a function to determine if a program is running in a linux console or in xwindows so that upon execute it can make the necessary accommodations? Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From doom at kzsu.stanford.edu Sun Feb 28 18:58:13 2010 From: doom at kzsu.stanford.edu (Joe Brenner) Date: Sun, 28 Feb 2010 18:58:13 -0800 Subject: [sf-perl] determining console or xwindows mode In-Reply-To: <489cf9d1002281822v15e08490geb86dbc465dc669d@mail.gmail.com> References: <489cf9d1002281822v15e08490geb86dbc465dc669d@mail.gmail.com> Message-ID: <201003010258.o212wD33037712@kzsu.stanford.edu> Richard Reina wrote: > I have a program that must run differently in xwindows then it would on a > linux console. I was wondering if there's a function to determine if a > program is running in a linux console or in xwindows so that upon execute > it can make the necessary accommodations? My first thought is to just check the TERM environment variable: my $term = $ENV{TERM}; If that's defined as "xterm" or "dumb" or something, then you're running in some sort of terminal window. I'm not sure if that's the Right Way to do it, but I'm pretty sure it would work. From quinn at fairpath.com Sun Feb 28 18:58:20 2010 From: quinn at fairpath.com (Quinn Weaver) Date: Sun, 28 Feb 2010 18:58:20 -0800 Subject: [sf-perl] determining console or xwindows mode In-Reply-To: <489cf9d1002281822v15e08490geb86dbc465dc669d@mail.gmail.com> References: <489cf9d1002281822v15e08490geb86dbc465dc669d@mail.gmail.com> Message-ID: <0816EB8D-A828-4C77-95AA-36B42CE5E703@fairpath.com> If you're running under X, the DISPLAY environment variable should be set. So do: if ($ENV{DISPLAY}) { ... -- Quinn Weaver Consulting, LLC Full-stack web design and development http://quinnweaver.com/ 510-520-5217 On Feb 28, 2010, at 6:22 PM, Richard Reina wrote: > I have a program that must run differently in xwindows then it would > on a linux console. I was wondering if there's a function to > determine if a program is running in a linux console or in xwindows > so that upon execute it can make the necessary accommodations? > > Thanks, > > Richard > _______________________________________________ > SanFrancisco-pm mailing list > SanFrancisco-pm at pm.org > http://mail.pm.org/mailman/listinfo/sanfrancisco-pm From gatorreina at gmail.com Sun Feb 28 19:13:42 2010 From: gatorreina at gmail.com (Richard Reina) Date: Sun, 28 Feb 2010 21:13:42 -0600 Subject: [sf-perl] determining console or xwindows mode In-Reply-To: <0816EB8D-A828-4C77-95AA-36B42CE5E703@fairpath.com> References: <489cf9d1002281822v15e08490geb86dbc465dc669d@mail.gmail.com> <0816EB8D-A828-4C77-95AA-36B42CE5E703@fairpath.com> Message-ID: <489cf9d1002281913g21ad46d3pcf6f0c7cbc1d82a4@mail.gmail.com> Perfect. Thank you. It looks like both suggestions will work. 2010/2/28 Quinn Weaver > If you're running under X, the DISPLAY environment variable should be set. > So do: > > if ($ENV{DISPLAY}) { > ... > > -- > Quinn Weaver Consulting, LLC > Full-stack web design and development > http://quinnweaver.com/ > 510-520-5217 > > > > On Feb 28, 2010, at 6:22 PM, Richard Reina wrote: > > I have a program that must run differently in xwindows then it would on a >> linux console. I was wondering if there's a function to determine if a >> program is running in a linux console or in xwindows so that upon execute it >> can make the necessary accommodations? >> >> Thanks, >> >> Richard >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doom at kzsu.stanford.edu Sun Feb 28 22:14:49 2010 From: doom at kzsu.stanford.edu (Joe Brenner) Date: Sun, 28 Feb 2010 22:14:49 -0800 Subject: [sf-perl] determining console or xwindows mode In-Reply-To: <489cf9d1002281913g21ad46d3pcf6f0c7cbc1d82a4@mail.gmail.com> References: <489cf9d1002281822v15e08490geb86dbc465dc669d@mail.gmail.com> <0816EB8D-A828-4C77-95AA-36B42CE5E703@fairpath.com> <489cf9d1002281913g21ad46d3pcf6f0c7cbc1d82a4@mail.gmail.com> Message-ID: <201003010614.o216Enrl040006@kzsu.stanford.edu> Richard Reina wrote: > Quinn Weaver > > > Richard Reina wrote: > >> I have a program that must run differently in xwindows then it > >> would on a linux console. I was wondering if there's a function to > >> determine if a program is running in a linux console or in xwindows > > If you're running under X, the DISPLAY environment variable should be set. > > So do: > > > > if ($ENV{DISPLAY}) { > > ... > > Perfect. Thank you. It looks like both suggestions will work. Also, you might want to look at the Perl Cookbook, 2nd edition, recipe 15.2 "Testing Whether a Progam Is Running Interactively" They suggest: use POSIX qw( getpgrp tcgetpgrp ); sub i_am_interactive { my $tty; open( $tty, '<', "/dev/tty") or die "$!"; my $tpgrp = tcgetpgrp( fileno( $tty ) ); my $pgrp = getpgrp(); close $tty; return ($tpgrp == $pgrp); } Or, in the increasingly unlikely event that you're not on a POSIX system: sub i_am_interactive { return -t STDIN && -t STDOUT; }