From enobacon at gmail.com Wed Mar 3 22:22:24 2010 From: enobacon at gmail.com (Seven till Seven) Date: Wed, 3 Mar 2010 22:22:24 -0800 Subject: [Pdx-pm] XML with Xtra X -- March meeting next week Message-ID: <201003032222.25046.enobacon@gmail.com> see http://pdx.pm.org/kwiki/ Wed. March 10th, 6:53pm at FreeGeek -- 1731 SE 10th Ave. How to learn to parse huge XML documents by doing it wrong for 5 years Speaker: Tyler Riddle When XML documents can't fit into memory the vast majority of solutions available on CPAN are no longer available to you; when the XML documents are so large they take up to 16 hours to process with the standard tools for handling large documents your hands are tied even more. Tyler will cover his learning experiences creating the Parse::MediaWikiDump and MediaWiki::DumpFile modules which are made to handle the 24 gigabyte English Wikipedia dump files in a reasonable time frame. 1) Real world benchmarks of C and perl libraries used to process huge XML documents. 2) The dirty little secret about XS and what it means for you in this context. 3) The evolution of the implementation of a nice interface around event oriented (SAX style) XML parsing. 4) Why XML::LibXML::Reader and XML::CompactTree are your friends and how to tame them. As always, the meeting will be followed by social hour at the LuckyLab. -- http://pdx.pm.org From perl-pm at joshheumann.com Thu Mar 4 16:04:44 2010 From: perl-pm at joshheumann.com (Josh Heumann) Date: Thu, 4 Mar 2010 16:04:44 -0800 Subject: [Pdx-pm] Hiring Down Under! Message-ID: <20100305000444.GA28112@joshheumann.com> Trans-hemispheric hello, Portlanders! Love Perl? Good at it? Looking for Perl work? Looking to do a little travelling? Then come on down! The company I work for, Strategic Data, is looking to hire one or two more Perl folks, and Portland's reputation for having good Perl folks is well known down here, and not just because I won't shut up about it. We're a small company with under 10 programmers and various other folks doing work for governments and universities. Web services, web surveys, data munging, that's us! There are no pointy-haired bosses, and most people cycle to work. Also, there's a dart board in the office. We're looking for new hires in this order: - Someone interested in living down here. And why wouldn't you be? The weather's nice, there's public transportation, the economy's doing well, there's amazing street art, and everyone talks funny! - Someone interested in doing ~3 months here, and then doing longer-term work back home. - Someone interested in doing just ~3 months of work here. Strategic Data will help with moving costs and visas, of course. If you're interested, drop me a line and a resume, and I'll get the ball rolling. Your erstwhile leader, Josh PS. Just to save you the search: http://www.strategicdata.com.au/ From exodist7 at gmail.com Thu Mar 4 19:10:33 2010 From: exodist7 at gmail.com (Chad Granum) Date: Thu, 4 Mar 2010 19:10:33 -0800 Subject: [Pdx-pm] Modern testing in perl Message-ID: <40ce9e661003041910j71d891e4n1480ec89b0aad992@mail.gmail.com> Recently there have been a couple movements to 'modernize' parts of perl. Two immediate examples are Moose which is a more modern OO system (like perl6), the other is perl5i which Schwern is heading. perl5i is intended to fix all kinds of gripes. Thus far I have not seen any similar movement in the area of perl testing. After a discussion which compared and contrasted perl's testing tools with another set of test tools it occurred to me that there is probably room for significant improvement. I have decided to try to fill this void in modernization of perl testing. I have started the fennec project (http://github.com/exodist/Fennec) before the name scares you let it be known that the original name was to be Test::Suite, and I have just obtained that namespace (it was previously owned by someone else) so the name may change back. I am requesting that anyone and everyone put there 2 cents in on what is amazing, good, bad, ugly, or impossible with the current perl testing tools. How they can be improved, etc. I also encourage anyone interested to add issues, look for bugs, add feature requests, submit patches, fork the repo, etc. Here is a simple bulleted list of desired features, most of these have a current (bu maybe in need of improvement) implementation. * Group tests into sets which can be run multiple times under different scenarios * Every test file should create an object that is run * Test sets should be run in random order by default, as should cases (scenarios) and even test files. * Writing tester function libraries (think Test::More, Test::Exception, etc) should be very simplified * Test results should be reported to the tester in object form, unlike Test::Builder which just outputs any results directly to TAP. * Ability to create result handlers for cases where you want to get results directly instead of going straight to TAP. * TAP output plugin used by default * Database output plugin (record results to a simple database) * Test::Builder output plugin (If you really want to go through Test::Builder, this is also the first output plugin for quickstart of the project) * Ability to use multiple output plugins at once. * Ability to wrap existing Test::Builder plugins (like Test::More) into Fennec tester libraries (this is already done for Test::More, Test::Warn) * Ability to run just a specified case/set * More helpful output in some current testers (is_deeply for example) * Ability to define tests both in separate files, and inline with the objects being tested * When not in testing mode these definitions should be ignored and minimal overhead should occur as a result of their being present. * Inline tests are purely optional * Perhaps tests be defined after __END__? Test result objects need to contain the following information: * Name, * Result (ok, not ok), * Case run under, * Set run under, * Line tester was called from, * File tester was called from, * todo (false or reason), * skip (false or reason), * diagnostics messages, Defining tests and cases should be moose like: case name => sub {}; case name => ( code => sub {}, partition => 'name', ..options.., ); set name => sub {}; Tests should also be definable by creating subs prefixed with 'test' or 'case' sub test_something {} sub case_prepare_things {} There will also be an init method that will be called just once prior to running the cases. The base principal for Fennec is that test will be grouped into sets, each of these sets can be run against multiple cases. Essentially a case is a method on a test object you define that creates a scenario, once the scenario is ready all your test sets will be run under that scenario, once the sets are all completed the next scenario will be run and the sets will be run again. You can mark an entire case or set as todo or skip. You also can also specify that sets should only run under certain cases, or not under others. You can also group sets and cases into a 'partition' so that only sets in that partition will be run under the cases in the same partition. Currently there are 2 types of plugins, output plugins which take results and do stuff with them, and tester plugins with provide functionality such as ok, like, is, diag, etc. I appreciate any feedback anyone wants to provide! -Chad Granum From ben.prew at gmail.com Fri Mar 5 17:04:41 2010 From: ben.prew at gmail.com (Ben Prew) Date: Fri, 5 Mar 2010 17:04:41 -0800 Subject: [Pdx-pm] Modern testing in perl In-Reply-To: <40ce9e661003041910j71d891e4n1480ec89b0aad992@mail.gmail.com> References: <40ce9e661003041910j71d891e4n1480ec89b0aad992@mail.gmail.com> Message-ID: <24f4b2e81003051704q3073faf0xbc097bf77b04aabf@mail.gmail.com> Chad, If you're considering re-imagining what unit testing looks like, I'm a fan of the spec format of testing (rspec (ruby), screwunit (javascript)), but I'd be happy to have any good xUnit-style testing framework for Perl, regardless of syntax/format. Thanks On Thu, Mar 4, 2010 at 7:10 PM, Chad Granum wrote: > Recently there have been a couple movements to 'modernize' parts of > perl. Two immediate examples are Moose which is a more modern OO > system (like perl6), the other is perl5i which Schwern is heading. > perl5i is intended to fix all kinds of gripes. Thus far I have not > seen any similar movement in the area of perl testing. After a > discussion which compared and contrasted perl's testing tools with > another set of test tools it occurred to me that there is probably > room for significant improvement. I have decided to try to fill this > void in modernization of perl testing. > > I have started the fennec project (http://github.com/exodist/Fennec) > before the name scares you let it be known that the original name was > to be Test::Suite, and I have just obtained that namespace (it was > previously owned by someone else) so the name may change back. > > I am requesting that anyone and everyone put there 2 cents in on what > is amazing, good, bad, ugly, or impossible with the current perl > testing tools. How they can be improved, etc. I also encourage anyone > interested to add issues, look for bugs, add feature requests, submit > patches, fork the repo, etc. > > Here is a simple bulleted list of desired features, most of these have > a current (bu maybe in need of improvement) implementation. > > ?* Group tests into sets which can be run multiple times under > different scenarios > ?* Every test file should create an object that is run > ?* Test sets should be run in random order by default, as should cases > (scenarios) and even test files. > ?* Writing tester function libraries (think Test::More, > Test::Exception, etc) should be very simplified > ?* Test results should be reported to the tester in object form, > unlike Test::Builder which just outputs any results directly to TAP. > ?* Ability to create result handlers for cases where you want to get > results directly instead of going straight to TAP. > ?* TAP output plugin used by default > ?* Database output plugin (record results to a simple database) > ?* Test::Builder output plugin (If you really want to go through > Test::Builder, this is also the first output plugin for quickstart of > the project) > ?* Ability to use multiple output plugins at once. > ?* Ability to wrap existing Test::Builder plugins (like Test::More) > into Fennec tester libraries (this is already done for Test::More, > Test::Warn) > ?* Ability to run just a specified case/set > ?* More helpful output in some current testers (is_deeply for example) > ?* Ability to define tests both in separate files, and inline with the > objects being tested > ?* When not in testing mode these definitions should be ignored and > minimal overhead should occur as a result of their being present. > ?* Inline tests are purely optional > ?* Perhaps tests be defined after __END__? > > Test result objects need to contain the following information: > ?* Name, > ?* Result (ok, not ok), > ?* Case run under, > ?* Set run under, > ?* Line tester was called from, > ?* File tester was called from, > ?* todo (false or reason), > ?* skip (false or reason), > ?* diagnostics messages, > > Defining tests and cases should be moose like: > > case name => sub {}; > case name => ( > ? code => sub {}, > ? partition => 'name', > ? ..options.., > ); > set name => sub {}; > > Tests should also be definable by creating subs prefixed with 'test' or 'case' > sub test_something {} > sub case_prepare_things {} > > There will also be an init method that will be called just once prior > to running the cases. > > The base principal for Fennec is that test will be grouped into sets, > each of these sets can be run against multiple cases. Essentially a > case is a method on a test object you define that creates a scenario, > once the scenario is ready all your test sets will be run under that > scenario, once the sets are all completed the next scenario will be > run and the sets will be run again. You can mark an entire case or set > as todo or skip. You also can also specify that sets should only run > under certain cases, or not under others. You can also group sets and > cases into a 'partition' so that only sets in that partition will be > run under the cases in the same partition. > > Currently there are 2 types of plugins, output plugins which take > results and do stuff with them, and tester plugins with provide > functionality such as ok, like, is, diag, etc. > > I appreciate any feedback anyone wants to provide! > > -Chad Granum > _______________________________________________ > Pdx-pm-list mailing list > Pdx-pm-list at pm.org > http://mail.pm.org/mailman/listinfo/pdx-pm-list > -- --Ben From publiustemp-pdxpm at yahoo.com Sat Mar 6 10:00:51 2010 From: publiustemp-pdxpm at yahoo.com (Ovid) Date: Sat, 6 Mar 2010 10:00:51 -0800 (PST) Subject: [Pdx-pm] Modern testing in perl In-Reply-To: <24f4b2e81003051704q3073faf0xbc097bf77b04aabf@mail.gmail.com> References: <40ce9e661003041910j71d891e4n1480ec89b0aad992@mail.gmail.com> <24f4b2e81003051704q3073faf0xbc097bf77b04aabf@mail.gmail.com> Message-ID: <169103.70409.qm@web65706.mail.ac4.yahoo.com> ----- Original Message ---- > From: Ben Prew > If you're considering re-imagining what unit testing looks like, I'm a > fan of the spec format of testing (rspec (ruby), screwunit > (javascript)), but I'd be happy to have any good xUnit-style testing > framework for Perl, regardless of syntax/format. For that, I humbly (ha!) recommend my Test::Class::Most. Instead of: use strict; use warnings; use Test::Exception; use Test::Differences; use Test::Deep; use Test::Warn; use Test::More; use parent 'My::Test::Class'; You just write: use Test::Class::Most parent => 'My::Test::Class'; And you're off and running for xUnit style tests. (Yes, you even get strict and warnings with it). If you struggle with Test::Class -- many do since it needs better docs -- I wrote a five part tutorial for it: * http://www.modernperlbooks.com/mt/2009/03/organizing-test-suites-with-testclass.html * http://www.modernperlbooks.com/mt/2009/03/reusing-test-code-with-testclass.html * http://www.modernperlbooks.com/mt/2009/03/making-your-testing-life-easier.html * http://www.modernperlbooks.com/mt/2009/03/using-test-control-methods-with-testclass.html * http://www.modernperlbooks.com/mt/2009/03/working-with-testclass-test-suites.html Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 From enobacon at gmail.com Sat Mar 6 13:01:28 2010 From: enobacon at gmail.com (Eric Wilhelm) Date: Sat, 6 Mar 2010 13:01:28 -0800 Subject: [Pdx-pm] Modern testing in perl In-Reply-To: <40ce9e661003041910j71d891e4n1480ec89b0aad992@mail.gmail.com> References: <40ce9e661003041910j71d891e4n1480ec89b0aad992@mail.gmail.com> Message-ID: <201003061301.28365.enobacon@gmail.com> # from Chad Granum # on Thursday 04 March 2010 19:10: Interesting. You're touching both sides of the TAP wall here though and I think it might be useful to consider what can be done from each side (and implicitly: why keeping the wall is a good thing.) These things sound rather consumer/harness-related: >?* Group tests into sets which can be run multiple times under > different scenarios >?* Every test file should create an object that is run >?* Test results should be reported to the tester in object form, > unlike Test::Builder which just outputs any results directly to TAP. > * Ability to run just a specified case/set Where these sound more producer-related: > * Writing tester function libraries (think Test::More, > Test::Exception, etc) should be very simplified >?* Ability to create result handlers for cases where you want to get > results directly instead of going straight to TAP. >?* More helpful output in some current testers (is_deeply for example) >?* Ability to define tests both in separate files, and inline with the > objects being tested They interrelate, but I'm just suggesting that it might be useful to view them from two directions like this. If you can structure your tests in a way that allows them to be introspected, the harness (given sufficient knobs) can be made to run parts or groups of them regardless of what's in which *.t files. You might have another tool which e.g. lets you REPL into a single process (which may even be enabled while running under the harness.) Don't forget about parallelism. On a related note: preloading code in a single process and peeling off a fork for each test (for one instance: a daemon which just forks and dumps the requested test's TAP out through a client socket in the *.t files.) Hope that gives you something to think about. I've never really had a chance to organize my thoughts on these matters into code, but you're welcome to try! http://www.nntp.perl.org/group/perl.qa/2007/12/msg10035.html http://www.nntp.perl.org/group/perl.qa/2007/08/msg8998.html --Eric -- I arise in the morning torn between a desire to improve the world and a desire to enjoy the world. This makes it hard to plan the day. --E.B. White --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From exodist7 at gmail.com Sat Mar 6 14:59:44 2010 From: exodist7 at gmail.com (Chad Granum) Date: Sat, 6 Mar 2010 14:59:44 -0800 Subject: [Pdx-pm] Modern testing in perl In-Reply-To: <8E80E1FB-587D-4609-9253-2991CE7C5382@gmail.com> References: <40ce9e661003041910j71d891e4n1480ec89b0aad992@mail.gmail.com> <201003061301.28365.enobacon@gmail.com> <8E80E1FB-587D-4609-9253-2991CE7C5382@gmail.com> Message-ID: <40ce9e661003061459t6e0764b3h113add79f9009768@mail.gmail.com> Ooops, accidently only sent this to Eric, If you look at my fork branch you will see the beginnings of my parallelism, there will be one main process producing all output. Essentially every tester function should produce a result object giving the result and some context. These all funnel down to the main process where they are sent to output plugins. Subprocesses (forked code) only use the subprocess plugin which send result objects the the main process. The main process them uses whatever output plugin you want, currently there is a tap output plugin, and others are in the works. The tester object is aware of it's pid, if the user forks and then issues a result the tester automatically knows to switch to the subprocesses output plugin. So really it becomes easy as can be to write plugins for what to do with results and other plugins for how to produce results. The user has complete freedom. I also want to reduce boilerplate as much as possible. Test::class looks amazing, but the boiler plate is putting me off. It should be as simple as declaring a package and test methods, the tools should do the rest. Also test::builder is Great and has opened the doors to the amazing testing perl can already accomplish, but aside from producers it's hard to extend. And you are bound to tap output with t::b. True tap is what you want almost all the time, but when it is not what you want their is a serious hindrance. By making result objects thy contain the result, line number, file, diag, and other info, then letting the user output whatever they want you provide a better opening for useful tools. Tap is only one possible thing to do with results, it also means not relying on t:b to find the line number and other context for the result, which is proving problematic for me sometimes. Anyway my goal here is complete flexability and plugability while solving problems I have experienced. Sent from my iPhone On Mar 6, 2010, at 1:01 PM, Eric Wilhelm wrote: > # from Chad Granum > # on Thursday 04 March 2010 19:10: > > Interesting. ?You're touching both sides of the TAP wall here though and > I think it might be useful to consider what can be done from each side > (and implicitly: why keeping the wall is a good thing.) > > These things sound rather consumer/harness-related: >> >> ?* Group tests into sets which can be run multiple times under >> ?different scenarios >> ?* Every test file should create an object that is run >> ?* Test results should be reported to the tester in object form, >> ?unlike Test::Builder which just outputs any results directly to TAP. >> * Ability to run just a specified case/set > > > Where these sound more producer-related: >> >> * Writing tester function libraries (think Test::More, >> ?Test::Exception, etc) should be very simplified >> ?* Ability to create result handlers for cases where you want to get >> ?results directly instead of going straight to TAP. >> ?* More helpful output in some current testers (is_deeply for example) >> ?* Ability to define tests both in separate files, and inline with the >> ?objects being tested > > They interrelate, but I'm just suggesting that it might be useful to > view them from two directions like this. > > If you can structure your tests in a way that allows them to be > introspected, the harness (given sufficient knobs) can be made to run > parts or groups of them regardless of what's in which *.t files. ?You > might have another tool which e.g. lets you REPL into a single process > (which may even be enabled while running under the harness.) > > Don't forget about parallelism. ?On a related note: preloading code in a > single process and peeling off a fork for each test (for one instance: > a daemon which just forks and dumps the requested test's TAP out > through a client socket in the *.t files.) > > Hope that gives you something to think about. ?I've never really had a > chance to organize my thoughts on these matters into code, but you're > welcome to try! > > ?http://www.nntp.perl.org/group/perl.qa/2007/12/msg10035.html > ?http://www.nntp.perl.org/group/perl.qa/2007/08/msg8998.html > > --Eric > -- > I arise in the morning torn between a desire to improve the world and a > desire to enjoy the world. This makes it hard to plan the day. > --E.B. White > --------------------------------------------------- > ? http://scratchcomputing.com > --------------------------------------------------- > _______________________________________________ > Pdx-pm-list mailing list > Pdx-pm-list at pm.org > http://mail.pm.org/mailman/listinfo/pdx-pm-list From ingy at ingy.net Sat Mar 6 23:25:00 2010 From: ingy at ingy.net (Ingy dot Net) Date: Sat, 6 Mar 2010 23:25:00 -0800 Subject: [Pdx-pm] Modern testing in perl In-Reply-To: <40ce9e661003041910j71d891e4n1480ec89b0aad992@mail.gmail.com> References: <40ce9e661003041910j71d891e4n1480ec89b0aad992@mail.gmail.com> Message-ID: <9eb4914f1003062325l36cf4c80ic5598e3950906c2c@mail.gmail.com> Chad, I just wanted to add that I started TestML (see http://www.testml.org) about a year ago. It is a unit testing language for all programming languages. You write tests in TestML and then write your software in any language. It is inspired by FIT, but not tied to a weird tabular harness like FIT. (In fact it's not even tied to any harness in a given language. It just needs a Runner subclass to tie it to a given harness/testing framework. So far I have implementations in Perl and Python. It's still in its infancy.) My main reason for starting TestML is that I believe programmers need to start writing modules that can be used in many programming languages. If they can pass the same test suite, that is something of an insurance that they truly are the same. I think think is critical for modules that get ported from Perl5 to Perl6. Wouldn't you want both versions to pass the same tests? I believe that great programmers should share their ideas (in code) with all people, not just the people in their language. I call this belief Acmeism (because I think that good ideas need a name). I am also working on a new programming language called C'Dent that lets modules be compiled to from your language to a dozen or more others. Acmeism is fueled by the weird feeling I get at conferences like OSCON and OSDC where great programmers of many languages come together to one place at one time, only to go off to their own corners and talk about their own things. None of these languages is so good that it's going to make the others obsolete. So why not work on things above the language level? I would encourage anyone as brave as you, for starting a new technology movement, to think bigger than Perl. Think as big as you can. Respectfully, Ingy d?t Net On Thu, Mar 4, 2010 at 7:10 PM, Chad Granum wrote: > Recently there have been a couple movements to 'modernize' parts of > perl. Two immediate examples are Moose which is a more modern OO > system (like perl6), the other is perl5i which Schwern is heading. > perl5i is intended to fix all kinds of gripes. Thus far I have not > seen any similar movement in the area of perl testing. After a > discussion which compared and contrasted perl's testing tools with > another set of test tools it occurred to me that there is probably > room for significant improvement. I have decided to try to fill this > void in modernization of perl testing. > > I have started the fennec project (http://github.com/exodist/Fennec) > before the name scares you let it be known that the original name was > to be Test::Suite, and I have just obtained that namespace (it was > previously owned by someone else) so the name may change back. > > I am requesting that anyone and everyone put there 2 cents in on what > is amazing, good, bad, ugly, or impossible with the current perl > testing tools. How they can be improved, etc. I also encourage anyone > interested to add issues, look for bugs, add feature requests, submit > patches, fork the repo, etc. > > Here is a simple bulleted list of desired features, most of these have > a current (bu maybe in need of improvement) implementation. > > * Group tests into sets which can be run multiple times under > different scenarios > * Every test file should create an object that is run > * Test sets should be run in random order by default, as should cases > (scenarios) and even test files. > * Writing tester function libraries (think Test::More, > Test::Exception, etc) should be very simplified > * Test results should be reported to the tester in object form, > unlike Test::Builder which just outputs any results directly to TAP. > * Ability to create result handlers for cases where you want to get > results directly instead of going straight to TAP. > * TAP output plugin used by default > * Database output plugin (record results to a simple database) > * Test::Builder output plugin (If you really want to go through > Test::Builder, this is also the first output plugin for quickstart of > the project) > * Ability to use multiple output plugins at once. > * Ability to wrap existing Test::Builder plugins (like Test::More) > into Fennec tester libraries (this is already done for Test::More, > Test::Warn) > * Ability to run just a specified case/set > * More helpful output in some current testers (is_deeply for example) > * Ability to define tests both in separate files, and inline with the > objects being tested > * When not in testing mode these definitions should be ignored and > minimal overhead should occur as a result of their being present. > * Inline tests are purely optional > * Perhaps tests be defined after __END__? > > Test result objects need to contain the following information: > * Name, > * Result (ok, not ok), > * Case run under, > * Set run under, > * Line tester was called from, > * File tester was called from, > * todo (false or reason), > * skip (false or reason), > * diagnostics messages, > > Defining tests and cases should be moose like: > > case name => sub {}; > case name => ( > code => sub {}, > partition => 'name', > ..options.., > ); > set name => sub {}; > > Tests should also be definable by creating subs prefixed with 'test' or > 'case' > sub test_something {} > sub case_prepare_things {} > > There will also be an init method that will be called just once prior > to running the cases. > > The base principal for Fennec is that test will be grouped into sets, > each of these sets can be run against multiple cases. Essentially a > case is a method on a test object you define that creates a scenario, > once the scenario is ready all your test sets will be run under that > scenario, once the sets are all completed the next scenario will be > run and the sets will be run again. You can mark an entire case or set > as todo or skip. You also can also specify that sets should only run > under certain cases, or not under others. You can also group sets and > cases into a 'partition' so that only sets in that partition will be > run under the cases in the same partition. > > Currently there are 2 types of plugins, output plugins which take > results and do stuff with them, and tester plugins with provide > functionality such as ok, like, is, diag, etc. > > I appreciate any feedback anyone wants to provide! > > -Chad Granum > _______________________________________________ > Pdx-pm-list mailing list > Pdx-pm-list at pm.org > http://mail.pm.org/mailman/listinfo/pdx-pm-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From exodist7 at gmail.com Sat Mar 6 23:42:34 2010 From: exodist7 at gmail.com (Chad Granum) Date: Sat, 6 Mar 2010 23:42:34 -0800 Subject: [Pdx-pm] Modern testing in perl In-Reply-To: <40ce9e661003062341p72147183l6af17419477b51a2@mail.gmail.com> References: <40ce9e661003041910j71d891e4n1480ec89b0aad992@mail.gmail.com> <9eb4914f1003062325l36cf4c80ic5598e3950906c2c@mail.gmail.com> <40ce9e661003062341p72147183l6af17419477b51a2@mail.gmail.com> Message-ID: <40ce9e661003062342n76810918n4583ee7add1e48a6@mail.gmail.com> Ingy, I like parts of what your suggesting. My goal is to make Fennec very flexible. I am thinking it may be possible to write a plugin for TestML and Fennec to work together. After I have Fennec to a point where I consider it usable would you be interested in working with me to work in support for TestML test files? I will continue on from here keeping in mind that I might want to support test files from TestML in the future. Thank you. -Chad On Sat, Mar 6, 2010 at 11:25 PM, Ingy dot Net wrote: > Chad, > > I just wanted to add that I started TestML (see http://www.testml.org) about > a year ago. It is a unit testing language for all programming languages. You > write tests in TestML and then write your software in any language. It is > inspired by FIT, but not tied to a weird tabular harness like FIT. (In fact > it's not even tied to any harness in a given language. It just needs a > Runner subclass to tie it to a given harness/testing framework. So far I > have implementations in Perl and Python. It's still in its infancy.) > > My main reason for starting TestML is that I believe programmers need to > start writing modules that can be used in many programming languages. If > they can pass the same test suite, that is something of an insurance that > they truly are the same. I think think is critical for modules that get > ported from Perl5 to Perl6. Wouldn't you want both versions to pass the same > tests? > > I believe that great programmers should share their ideas (in code) with all > people, not just the people in their language. I call this belief Acmeism > (because I think that good ideas need a name). I am also working on a new > programming language called C'Dent that lets modules be compiled to from > your language to a dozen or more others. > > Acmeism is fueled by the weird feeling I get at conferences like OSCON and > OSDC where great programmers of many languages come together to one place at > one time, only to go off to their own corners and talk about their own > things. None of these languages is so good that it's going to make the > others obsolete. So why not work on things above the language level? > > I would encourage anyone as brave as you, for starting a new technology > movement, to think bigger than Perl. Think as big as you can. > > Respectfully, Ingy d?t Net > > On Thu, Mar 4, 2010 at 7:10 PM, Chad Granum wrote: >> >> Recently there have been a couple movements to 'modernize' parts of >> perl. Two immediate examples are Moose which is a more modern OO >> system (like perl6), the other is perl5i which Schwern is heading. >> perl5i is intended to fix all kinds of gripes. Thus far I have not >> seen any similar movement in the area of perl testing. After a >> discussion which compared and contrasted perl's testing tools with >> another set of test tools it occurred to me that there is probably >> room for significant improvement. I have decided to try to fill this >> void in modernization of perl testing. >> >> I have started the fennec project (http://github.com/exodist/Fennec) >> before the name scares you let it be known that the original name was >> to be Test::Suite, and I have just obtained that namespace (it was >> previously owned by someone else) so the name may change back. >> >> I am requesting that anyone and everyone put there 2 cents in on what >> is amazing, good, bad, ugly, or impossible with the current perl >> testing tools. How they can be improved, etc. I also encourage anyone >> interested to add issues, look for bugs, add feature requests, submit >> patches, fork the repo, etc. >> >> Here is a simple bulleted list of desired features, most of these have >> a current (bu maybe in need of improvement) implementation. >> >> ?* Group tests into sets which can be run multiple times under >> different scenarios >> ?* Every test file should create an object that is run >> ?* Test sets should be run in random order by default, as should cases >> (scenarios) and even test files. >> ?* Writing tester function libraries (think Test::More, >> Test::Exception, etc) should be very simplified >> ?* Test results should be reported to the tester in object form, >> unlike Test::Builder which just outputs any results directly to TAP. >> ?* Ability to create result handlers for cases where you want to get >> results directly instead of going straight to TAP. >> ?* TAP output plugin used by default >> ?* Database output plugin (record results to a simple database) >> ?* Test::Builder output plugin (If you really want to go through >> Test::Builder, this is also the first output plugin for quickstart of >> the project) >> ?* Ability to use multiple output plugins at once. >> ?* Ability to wrap existing Test::Builder plugins (like Test::More) >> into Fennec tester libraries (this is already done for Test::More, >> Test::Warn) >> ?* Ability to run just a specified case/set >> ?* More helpful output in some current testers (is_deeply for example) >> ?* Ability to define tests both in separate files, and inline with the >> objects being tested >> ?* When not in testing mode these definitions should be ignored and >> minimal overhead should occur as a result of their being present. >> ?* Inline tests are purely optional >> ?* Perhaps tests be defined after __END__? >> >> Test result objects need to contain the following information: >> ?* Name, >> ?* Result (ok, not ok), >> ?* Case run under, >> ?* Set run under, >> ?* Line tester was called from, >> ?* File tester was called from, >> ?* todo (false or reason), >> ?* skip (false or reason), >> ?* diagnostics messages, >> >> Defining tests and cases should be moose like: >> >> case name => sub {}; >> case name => ( >> ? code => sub {}, >> ? partition => 'name', >> ? ..options.., >> ); >> set name => sub {}; >> >> Tests should also be definable by creating subs prefixed with 'test' or >> 'case' >> sub test_something {} >> sub case_prepare_things {} >> >> There will also be an init method that will be called just once prior >> to running the cases. >> >> The base principal for Fennec is that test will be grouped into sets, >> each of these sets can be run against multiple cases. Essentially a >> case is a method on a test object you define that creates a scenario, >> once the scenario is ready all your test sets will be run under that >> scenario, once the sets are all completed the next scenario will be >> run and the sets will be run again. You can mark an entire case or set >> as todo or skip. You also can also specify that sets should only run >> under certain cases, or not under others. You can also group sets and >> cases into a 'partition' so that only sets in that partition will be >> run under the cases in the same partition. >> >> Currently there are 2 types of plugins, output plugins which take >> results and do stuff with them, and tester plugins with provide >> functionality such as ok, like, is, diag, etc. >> >> I appreciate any feedback anyone wants to provide! >> >> -Chad Granum >> _______________________________________________ >> Pdx-pm-list mailing list >> Pdx-pm-list at pm.org >> http://mail.pm.org/mailman/listinfo/pdx-pm-list > > From ingy at ingy.net Sat Mar 6 23:52:49 2010 From: ingy at ingy.net (Ingy dot Net) Date: Sat, 6 Mar 2010 23:52:49 -0800 Subject: [Pdx-pm] Modern testing in perl In-Reply-To: <40ce9e661003062342n76810918n4583ee7add1e48a6@mail.gmail.com> References: <40ce9e661003041910j71d891e4n1480ec89b0aad992@mail.gmail.com> <9eb4914f1003062325l36cf4c80ic5598e3950906c2c@mail.gmail.com> <40ce9e661003062341p72147183l6af17419477b51a2@mail.gmail.com> <40ce9e661003062342n76810918n4583ee7add1e48a6@mail.gmail.com> Message-ID: <9eb4914f1003062352g6975b93k878f65370591a529@mail.gmail.com> On Sat, Mar 6, 2010 at 11:42 PM, Chad Granum wrote: > Ingy, > > I like parts of what your suggesting. My goal is to make Fennec very > flexible. I am thinking it may be possible to write a plugin for > TestML and Fennec to work together. After I have Fennec to a point > where I consider it usable would you be interested in working with me > to work in support for TestML test files? > Absolutely. I'll keep my eyes on Fennec as well. Cheers, Ingy > I will continue on from here > keeping in mind that I might want to support test files from TestML in > the future. > > Thank you. > > -Chad > > On Sat, Mar 6, 2010 at 11:25 PM, Ingy dot Net wrote: > > Chad, > > > > I just wanted to add that I started TestML (see http://www.testml.org) > about > > a year ago. It is a unit testing language for all programming languages. > You > > write tests in TestML and then write your software in any language. It is > > inspired by FIT, but not tied to a weird tabular harness like FIT. (In > fact > > it's not even tied to any harness in a given language. It just needs a > > Runner subclass to tie it to a given harness/testing framework. So far I > > have implementations in Perl and Python. It's still in its infancy.) > > > > My main reason for starting TestML is that I believe programmers need to > > start writing modules that can be used in many programming languages. If > > they can pass the same test suite, that is something of an insurance that > > they truly are the same. I think think is critical for modules that get > > ported from Perl5 to Perl6. Wouldn't you want both versions to pass the > same > > tests? > > > > I believe that great programmers should share their ideas (in code) with > all > > people, not just the people in their language. I call this belief Acmeism > > (because I think that good ideas need a name). I am also working on a new > > programming language called C'Dent that lets modules be compiled to from > > your language to a dozen or more others. > > > > Acmeism is fueled by the weird feeling I get at conferences like OSCON > and > > OSDC where great programmers of many languages come together to one place > at > > one time, only to go off to their own corners and talk about their own > > things. None of these languages is so good that it's going to make the > > others obsolete. So why not work on things above the language level? > > > > I would encourage anyone as brave as you, for starting a new technology > > movement, to think bigger than Perl. Think as big as you can. > > > > Respectfully, Ingy d?t Net > > > > On Thu, Mar 4, 2010 at 7:10 PM, Chad Granum wrote: > >> > >> Recently there have been a couple movements to 'modernize' parts of > >> perl. Two immediate examples are Moose which is a more modern OO > >> system (like perl6), the other is perl5i which Schwern is heading. > >> perl5i is intended to fix all kinds of gripes. Thus far I have not > >> seen any similar movement in the area of perl testing. After a > >> discussion which compared and contrasted perl's testing tools with > >> another set of test tools it occurred to me that there is probably > >> room for significant improvement. I have decided to try to fill this > >> void in modernization of perl testing. > >> > >> I have started the fennec project (http://github.com/exodist/Fennec) > >> before the name scares you let it be known that the original name was > >> to be Test::Suite, and I have just obtained that namespace (it was > >> previously owned by someone else) so the name may change back. > >> > >> I am requesting that anyone and everyone put there 2 cents in on what > >> is amazing, good, bad, ugly, or impossible with the current perl > >> testing tools. How they can be improved, etc. I also encourage anyone > >> interested to add issues, look for bugs, add feature requests, submit > >> patches, fork the repo, etc. > >> > >> Here is a simple bulleted list of desired features, most of these have > >> a current (bu maybe in need of improvement) implementation. > >> > >> * Group tests into sets which can be run multiple times under > >> different scenarios > >> * Every test file should create an object that is run > >> * Test sets should be run in random order by default, as should cases > >> (scenarios) and even test files. > >> * Writing tester function libraries (think Test::More, > >> Test::Exception, etc) should be very simplified > >> * Test results should be reported to the tester in object form, > >> unlike Test::Builder which just outputs any results directly to TAP. > >> * Ability to create result handlers for cases where you want to get > >> results directly instead of going straight to TAP. > >> * TAP output plugin used by default > >> * Database output plugin (record results to a simple database) > >> * Test::Builder output plugin (If you really want to go through > >> Test::Builder, this is also the first output plugin for quickstart of > >> the project) > >> * Ability to use multiple output plugins at once. > >> * Ability to wrap existing Test::Builder plugins (like Test::More) > >> into Fennec tester libraries (this is already done for Test::More, > >> Test::Warn) > >> * Ability to run just a specified case/set > >> * More helpful output in some current testers (is_deeply for example) > >> * Ability to define tests both in separate files, and inline with the > >> objects being tested > >> * When not in testing mode these definitions should be ignored and > >> minimal overhead should occur as a result of their being present. > >> * Inline tests are purely optional > >> * Perhaps tests be defined after __END__? > >> > >> Test result objects need to contain the following information: > >> * Name, > >> * Result (ok, not ok), > >> * Case run under, > >> * Set run under, > >> * Line tester was called from, > >> * File tester was called from, > >> * todo (false or reason), > >> * skip (false or reason), > >> * diagnostics messages, > >> > >> Defining tests and cases should be moose like: > >> > >> case name => sub {}; > >> case name => ( > >> code => sub {}, > >> partition => 'name', > >> ..options.., > >> ); > >> set name => sub {}; > >> > >> Tests should also be definable by creating subs prefixed with 'test' or > >> 'case' > >> sub test_something {} > >> sub case_prepare_things {} > >> > >> There will also be an init method that will be called just once prior > >> to running the cases. > >> > >> The base principal for Fennec is that test will be grouped into sets, > >> each of these sets can be run against multiple cases. Essentially a > >> case is a method on a test object you define that creates a scenario, > >> once the scenario is ready all your test sets will be run under that > >> scenario, once the sets are all completed the next scenario will be > >> run and the sets will be run again. You can mark an entire case or set > >> as todo or skip. You also can also specify that sets should only run > >> under certain cases, or not under others. You can also group sets and > >> cases into a 'partition' so that only sets in that partition will be > >> run under the cases in the same partition. > >> > >> Currently there are 2 types of plugins, output plugins which take > >> results and do stuff with them, and tester plugins with provide > >> functionality such as ok, like, is, diag, etc. > >> > >> I appreciate any feedback anyone wants to provide! > >> > >> -Chad Granum > >> _______________________________________________ > >> Pdx-pm-list mailing list > >> Pdx-pm-list at pm.org > >> http://mail.pm.org/mailman/listinfo/pdx-pm-list > > > > > _______________________________________________ > Pdx-pm-list mailing list > Pdx-pm-list at pm.org > http://mail.pm.org/mailman/listinfo/pdx-pm-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From enobacon at gmail.com Sun Mar 7 00:57:15 2010 From: enobacon at gmail.com (Eric Wilhelm) Date: Sun, 7 Mar 2010 00:57:15 -0800 Subject: [Pdx-pm] Modern testing in perl In-Reply-To: <40ce9e661003061459t6e0764b3h113add79f9009768@mail.gmail.com> References: <40ce9e661003041910j71d891e4n1480ec89b0aad992@mail.gmail.com> <8E80E1FB-587D-4609-9253-2991CE7C5382@gmail.com> <40ce9e661003061459t6e0764b3h113add79f9009768@mail.gmail.com> Message-ID: <201003070057.15928.enobacon@gmail.com> # from Chad Granum # on Saturday 06 March 2010 14:59: >I also want to reduce boilerplate as much as possible. Test::class >looks amazing, but the boiler plate is putting me off. It should be as >simple as declaring a package and test methods, the tools should do >the rest. I think a lot of the boilerplate has to do with fitting into the *.t framework and the "done thing" for `make test`. You can, of course, subclass Module::Build and make your `./Build test` do whatever you want (would be nice to have plugins to do this sort of thing so you don't have to paste your subclass code into multiple distros.) It's possible that generating some *.t files would be a good transition mechanism to fit what you're doing into that framework. >Also test::builder is Great and has opened the doors to the amazing >testing perl can already accomplish, but aside from producers it's >hard to extend. And you are bound to tap output with t::b. True tap is >what you want almost all the time, but when it is not what you want >their is a serious hindrance. What happened to Test::Builder 2? Output format is one thing, but IMO the main hangup in Test::Builder is the ad-hoc nature of "what is a test" in relation to diagnostics and introspection. >By making result objects thy contain the result, line number, file, >diag, and other info, then letting the user output whatever they want >you provide a better opening for useful tools. Tap is only one >possible thing to do with results, it also means not relying on t:b to >find the line number and other context for the result, which is >proving problematic for me sometimes. This sounds a lot like what the next generation of TAP is trying to express. The info is, of course, passing through serialization. The TAP producers and consumers have room for improvement, but the decoupling is nice because you can improve one at a time. It's also a pain if you're trying to innovate because you have to go through TAP format and try to get what you're doing into the standard, supported in the tools on the other side, etc. >If you look at my fork branch you will see the beginnings of my >parallelism, there will be one main process producing all output. >Essentially every tester function should produce a result object >giving the result and some context. These all funnel down to the main >process where they are sent to output plugins. Subprocesses (forked >code) only use the subprocess plugin which send result objects the the >main process That sounds a lot like what the TAP::Harness parallelism does, except you're working off of in-memory data from the parent? That could give you a preload/copy-on-write boost, but potentially at the cost of flexibility and maybe with a bottleneck on formatting output. --Eric -- "But as to modern architecture, let us drop it and let us take modernistic out and shoot it at sunrise." --F.L. Wright --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From keithl at kl-ic.com Mon Mar 8 13:57:20 2010 From: keithl at kl-ic.com (Keith Lofstrom) Date: Mon, 8 Mar 2010 13:57:20 -0800 Subject: [Pdx-pm] Locking Kwiki pages Message-ID: <20100308215720.GA11332@gate.kl-ic.com> Although I am moving most of my wikis to MoinMoin, I still have a few running Kwiki, which is not very spam-resistant. How do you lock down pages in Kwiki? Change permissions, as root? BTW, the spammer looks like a Filipino using Ubuntu and Firefox, adding pointers to school-fraud paper/essay sites. The timing in the logs is slower and more erratic than I would expect from a bot. I would sure like to shut those child abusers down ... Keith -- Keith Lofstrom keithl at keithl.com Voice (503)-520-1993 KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon" Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs From jaleto at gmail.com Mon Mar 8 22:13:02 2010 From: jaleto at gmail.com (Jonathan Leto) Date: Mon, 8 Mar 2010 22:13:02 -0800 Subject: [Pdx-pm] Calling All Google Summer of Code Mentors In-Reply-To: <9aaadf9c1003082155m77eec966q386e854aeed56a2f@mail.gmail.com> References: <9aaadf9c1003082155m77eec966q386e854aeed56a2f@mail.gmail.com> Message-ID: <9aaadf9c1003082213h6df5322cwf83a0564cbeb5121@mail.gmail.com> Howdy, I am working on the application for The Perl Foundation and Parrot Foundation to participate in Google Summer of Code 2010 [0]. GSoC is a program where Google funds eligible students to hack on open source projects for a summer. It is a great opportunity for the students and the communities that mentor them. You also may be interested in this summary of our involvement last year [1]. Our application will be submitted by the end of this week. Please join us in getting prepared for this year. There is a page for possible mentors to volunteer [2]* as well as a page for project ideas [3]. If you would like to help with the wiki, our main GSoC page [4] is the best place to start. You are also invited to join our mailing list [5] and come ask question in #soc-help on irc.perl.org . Thanks! Duke [0] http://socghop.appspot.com/ [1] http://google-opensource.blogspot.com/2009/10/perls-of-wisdom-perl-foundation-parrots.html [2] http://www.perlfoundation.org/perl5/index.cgi?gsoc_mentors [3] http://www.perlfoundation.org/perl5/index.cgi?gsoc_2010_projects [4] http://www.perlfoundation.org/perl5/index.cgi?gsoc [5] http://groups.google.com/group/tpf-gsoc * If you listed yourself as a mentor last year and you are not interested this year, please remove yourself from the page. -- Jonathan "Duke" Leto jonathan at leto.net http://leto.net From enobacon at gmail.com Wed Mar 10 08:40:28 2010 From: enobacon at gmail.com (Seven till Seven) Date: Wed, 10 Mar 2010 08:40:28 -0800 Subject: [Pdx-pm] meeting tonight: XML with Xtra X Message-ID: <201003100840.29278.enobacon@gmail.com> see http://pdx.pm.org/kwiki/ Wed. March 10th, 6:53pm at FreeGeek -- 1731 SE 10th Ave. How to learn to parse huge XML documents by doing it wrong for 5 years Speaker: Tyler Riddle When XML documents can't fit into memory the vast majority of solutions available on CPAN are no longer available to you; when the XML documents are so large they take up to 16 hours to process with the standard tools for handling large documents your hands are tied even more. Tyler will cover his learning experiences creating the Parse::MediaWikiDump and MediaWiki::DumpFile modules which are made to handle the 24 gigabyte English Wikipedia dump files in a reasonable time frame. 1) Real world benchmarks of C and perl libraries used to process huge XML documents. 2) The dirty little secret about XS and what it means for you in this context. 3) The evolution of the implementation of a nice interface around event oriented (SAX style) XML parsing. 4) Why XML::LibXML::Reader and XML::CompactTree are your friends and how to tame them. As always, the meeting will be followed by social hour at the LuckyLab. -- http://pdx.pm.org From merlyn at stonehenge.com Wed Mar 10 08:48:01 2010 From: merlyn at stonehenge.com (Randal L. Schwartz) Date: Wed, 10 Mar 2010 08:48:01 -0800 Subject: [Pdx-pm] meeting tonight: XML with Xtra X In-Reply-To: <201003100840.29278.enobacon@gmail.com> (Seven till Seven's message of "Wed, 10 Mar 2010 08:40:28 -0800") References: <201003100840.29278.enobacon@gmail.com> Message-ID: <868wa0dsxq.fsf@blue.stonehenge.com> >>>>> "Seven" == Seven till Seven writes: Seven> see http://pdx.pm.org/kwiki/ Seven> Wed. March 10th, 6:53pm at FreeGeek -- 1731 SE 10th Ave. Seven> How to learn to parse huge XML documents by doing it wrong for 5 years Seven> Speaker: Tyler Riddle And if there's no objection, I'll be coming by with my livestreaming gear, so watch twitter.com/merlyn for announcements, or you can camp on the chat room at http://ustre.am/p0 to see when I'm going live. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion From triddle at gmail.com Wed Mar 10 15:25:57 2010 From: triddle at gmail.com (Tyler Riddle) Date: Wed, 10 Mar 2010 15:25:57 -0800 Subject: [Pdx-pm] meeting tonight: XML with Xtra X In-Reply-To: <868wa0dsxq.fsf@blue.stonehenge.com> References: <201003100840.29278.enobacon@gmail.com> <868wa0dsxq.fsf@blue.stonehenge.com> Message-ID: There's no complaints from me; should be fun. Tyler On Wed, Mar 10, 2010 at 8:48 AM, Randal L. Schwartz wrote: >>>>>> "Seven" == Seven till Seven writes: > > Seven> see http://pdx.pm.org/kwiki/ > Seven> ? Wed. March 10th, 6:53pm at FreeGeek -- 1731 SE 10th Ave. > > Seven> How to learn to parse huge XML documents by doing it wrong for 5 years > Seven> Speaker: Tyler Riddle > > And if there's no objection, I'll be coming by with my livestreaming gear, > so watch twitter.com/merlyn for announcements, or you can camp > on the chat room at http://ustre.am/p0 to see when I'm going live. > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion > _______________________________________________ > Pdx-pm-list mailing list > Pdx-pm-list at pm.org > http://mail.pm.org/mailman/listinfo/pdx-pm-list > -- If you wish to make an apple pie from scratch you must first invent the universe. -- Carl Sagan From merlyn at stonehenge.com Thu Mar 11 10:21:32 2010 From: merlyn at stonehenge.com (Randal L. Schwartz) Date: Thu, 11 Mar 2010 10:21:32 -0800 Subject: [Pdx-pm] meeting tonight: XML with Xtra X In-Reply-To: <868wa0dsxq.fsf@blue.stonehenge.com> (Randal L. Schwartz's message of "Wed, 10 Mar 2010 08:48:01 -0800") References: <201003100840.29278.enobacon@gmail.com> <868wa0dsxq.fsf@blue.stonehenge.com> Message-ID: <86ljdyen2r.fsf@blue.stonehenge.com> >>>>> "Randal" == Randal L Schwartz writes: Randal> And if there's no objection, I'll be coming by with my livestreaming gear, Randal> so watch twitter.com/merlyn for announcements, or you can camp Randal> on the chat room at http://ustre.am/p0 to see when I'm going live. The video is available at http://www.ustream.tv/recorded/5349583. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion From jkeroes at gmail.com Fri Mar 12 13:02:47 2010 From: jkeroes at gmail.com (Joshua Keroes) Date: Fri, 12 Mar 2010 13:02:47 -0800 Subject: [Pdx-pm] job opening - anybody interested? In-Reply-To: <64e2f6fe1003121121u614fd4d5x47092ab59d560eec@mail.gmail.com> References: <64e2f6fe1003121121u614fd4d5x47092ab59d560eec@mail.gmail.com> Message-ID: Want a job that requires C & Perl experience? Contact Greg. Thanks Greg and good luck, Joshua On Fri, Mar 12, 2010 at 11:21 AM, gregory benison wrote: > Hi Joshua - > > I just got an email from a recruiter looking for somebody with > experience in C and perl. I just started a new job myself so I'm not > applying. If you know anybody who may be interested, feel free to > send me their email address and I'll forward it along. Otherwise, I > hope all is well - > > Greg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kellert at ohsu.edu Fri Mar 12 14:59:50 2010 From: kellert at ohsu.edu (Tom Keller) Date: Fri, 12 Mar 2010 14:59:50 -0800 Subject: [Pdx-pm] dyld error with DBD::mysql Message-ID: Greetings, This driver is apparently looking for a symbol in a library file that either doesn't exist or is in an unexpected location. ... or something else. The solutions suggested on the web at various formats don't seem to solve the problem: I get the same error regardless of which MySQL (32 or 64 bit) I install (as a package .dmg file on OS X 10.6.2) Have any of you seen this and figured out a workaround? dyld: lazy symbol binding failed: Symbol not found: _mysql_init Referenced from: /Library/Perl/5.10.0/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle Expected in: flat namespace dyld: Symbol not found: _mysql_init Referenced from: /Library/Perl/5.10.0/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle Expected in: flat namespace Trace/BPT trap thanks, Tom kellert at ohsu.edu 503-494-2442 ######################################## $ perl -V Summary of my perl5 (revision 5 version 10 subversion 0) configuration: Platform: osname=darwin, osvers=10.0, archname=darwin-thread-multi-2level uname='darwin b79.apple.com 10.0 darwin kernel version 10.0.0d8: tue may 5 19:29:59 pdt 2009; root:xnu-1437.2~2release_i386 i386 ' config_args='-ds -e -Dprefix=/usr -Dccflags=-g -pipe -Dldflags= -Dman3ext=3pm -Duseithreads -Duseshrplib -Dinc_version_list=none -Dcc=gcc-4.2' 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=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc-4.2', ccflags ='-arch x86_64 -arch i386 -arch ppc -g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -I/usr/local/include', optimize='-Os', cppflags='-g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='4.2.1 (Apple Inc. build 5646)', 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='gcc-4.2 -mmacosx-version-min=10.6', ldflags ='-arch x86_64 -arch i386 -arch ppc -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=true, libperl=libperl.dylib gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-arch x86_64 -arch i386 -arch ppc -bundle -undefined dynamic_lookup -L/usr/local/lib' 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_PERLIO USE_REENTRANT_API Locally applied patches: /Library/Perl/Updates/ comes before system perl directories installprivlib and installarchlib points to the Updates directory Built under darwin Compiled at Jun 25 2009 21:54:25 @INC: /Library/Perl/Updates/5.10.0/darwin-thread-multi-2level /Library/Perl/Updates/5.10.0 /System/Library/Perl/5.10.0/darwin-thread-multi-2level /System/Library/Perl/5.10.0 /Library/Perl/5.10.0/darwin-thread-multi-2level /Library/Perl/5.10.0 /Network/Library/Perl/5.10.0/darwin-thread-multi-2level /Network/Library/Perl/5.10.0 /Network/Library/Perl /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level /System/Library/Perl/Extras/5.10.0 . -------------- next part -------------- An HTML attachment was scrubbed... URL: From clone206 at gmail.com Fri Mar 12 15:14:46 2010 From: clone206 at gmail.com (Kevin) Date: Fri, 12 Mar 2010 15:14:46 -0800 Subject: [Pdx-pm] dyld error with DBD::mysql In-Reply-To: References: Message-ID: <911780FE-40B9-43CE-9702-0F6E8AC87D1D@gmail.com> I mentioned at a meeting I came to once that I had that exact same error message when installing SVN::Client on my mac. If I recall, the only way I was able to get around it was installing svn from source and specifying the library paths as part of the ./configure. So I wonder if installing mysql from source instead of a .dmg file, using a similar process would help. - Kevin Witmer On Mar 12, 2010, at 2:59 PM, Tom Keller wrote: > Greetings, > This driver is apparently looking for a symbol in a library file > that either doesn't exist or is in an unexpected location. ... or > something else. > > The solutions suggested on the web at various formats don't seem to > solve the problem: I get the same error regardless of which MySQL > (32 or 64 bit) I install (as a package .dmg file on OS X 10.6.2) > > > Have any of you seen this and figured out a workaround? > dyld: lazy symbol binding failed: Symbol not found: _mysql_init > Referenced from: /Library/Perl/5.10.0/darwin-thread-multi-2level/ > auto/DBD/mysql/mysql.bundle > Expected in: flat namespace > > dyld: Symbol not found: _mysql_init > Referenced from: /Library/Perl/5.10.0/darwin-thread-multi-2level/ > auto/DBD/mysql/mysql.bundle > Expected in: flat namespace > > Trace/BPT trap > > thanks, > Tom > kellert at ohsu.edu > 503-494-2442 > ######################################## > $ perl -V > Summary of my perl5 (revision 5 version 10 subversion 0) > configuration: > Platform: > osname=darwin, osvers=10.0, archname=darwin-thread-multi-2level > uname='darwin b79.apple.com 10.0 darwin kernel version 10.0.0d8: > tue may 5 19:29:59 pdt 2009; root:xnu-1437.2~2release_i386 i386 ' > config_args='-ds -e -Dprefix=/usr -Dccflags=-g -pipe - > Dldflags= -Dman3ext=3pm -Duseithreads -Duseshrplib - > Dinc_version_list=none -Dcc=gcc-4.2' > 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=undef > usemymalloc=n, bincompat5005=undef > Compiler: > cc='gcc-4.2', ccflags ='-arch x86_64 -arch i386 -arch ppc -g - > pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -I/usr/local/ > include', > optimize='-Os', > cppflags='-g -pipe -fno-common -DPERL_DARWIN -fno-strict- > aliasing -I/usr/local/include' > ccversion='', gccversion='4.2.1 (Apple Inc. build 5646)', > 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='gcc-4.2 -mmacosx-version-min=10.6', ldflags ='-arch x86_64 - > arch i386 -arch ppc -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=true, > libperl=libperl.dylib > gnulibc_version='' > Dynamic Linking: > dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' > cccdlflags=' ', lddlflags='-arch x86_64 -arch i386 -arch ppc - > bundle -undefined dynamic_lookup -L/usr/local/lib' > > > 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_PERLIO USE_REENTRANT_API > Locally applied patches: > /Library/Perl/Updates/ comes before system perl directories > installprivlib and installarchlib points to the Updates directory > Built under darwin > Compiled at Jun 25 2009 21:54:25 > @INC: > /Library/Perl/Updates/5.10.0/darwin-thread-multi-2level > /Library/Perl/Updates/5.10.0 > /System/Library/Perl/5.10.0/darwin-thread-multi-2level > /System/Library/Perl/5.10.0 > /Library/Perl/5.10.0/darwin-thread-multi-2level > /Library/Perl/5.10.0 > /Network/Library/Perl/5.10.0/darwin-thread-multi-2level > /Network/Library/Perl/5.10.0 > /Network/Library/Perl > /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level > /System/Library/Perl/Extras/5.10.0 > . > > _______________________________________________ > Pdx-pm-list mailing list > Pdx-pm-list at pm.org > http://mail.pm.org/mailman/listinfo/pdx-pm-list From enobacon at gmail.com Sun Mar 14 10:53:09 2010 From: enobacon at gmail.com (Eric Wilhelm) Date: Sun, 14 Mar 2010 10:53:09 -0700 Subject: [Pdx-pm] dyld error with DBD::mysql In-Reply-To: References: Message-ID: <201003141053.09758.enobacon@gmail.com> # from Tom Keller # on Friday 12 March 2010 14:59: >Have any of you seen this and figured out a workaround? >dyld: lazy symbol binding failed: Symbol not found: _mysql_init >? Referenced from: > /Library/Perl/5.10.0/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle Searching for "Symbol not found: _mysql_init" seems to indicate that you might have a 32 vs 64-bit issue. Did you build DBD::mysql from a tarball? If there's a .dylib next to that .bundle, or something you could run ldd on to see the linkage? --Eric -- The only thing that could save UNIX at this late date would be a new $30 shareware version that runs on an unexpanded Commodore 64. --Don Lancaster (1991) --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From kellert at ohsu.edu Mon Mar 15 11:44:50 2010 From: kellert at ohsu.edu (Tom Keller) Date: Mon, 15 Mar 2010 11:44:50 -0700 Subject: [Pdx-pm] dyld error with DBD::mysql In-Reply-To: <201003141053.09758.enobacon@gmail.com> References: <201003141053.09758.enobacon@gmail.com> Message-ID: Thanks for the good suggestions. There is a problem with word size incompatibility. But I reinstalled MySQL (dmg file for 64-bit intel) to match my Perl (both are 64-bit now) and this did not fix the library problem when using CPAN to install DBD::mysql. I found a solution at http://bixsolutions.net/forum/thread-8.html Basically, just use cpan to get the module, then install "by hand" so you can give Makefile.PL the test user and password for MySQL, and one other modification. It turned out to be necessary to run make (and make test) as root; at least on my system. thanks again folks, Tom kellert at ohsu.edu 503-494-2442 On Mar 14, 2010, at 10:53 AM, Eric Wilhelm wrote: # from Tom Keller # on Friday 12 March 2010 14:59: Have any of you seen this and figured out a workaround? dyld: lazy symbol binding failed: Symbol not found: _mysql_init Referenced from: /Library/Perl/5.10.0/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle Searching for "Symbol not found: _mysql_init" seems to indicate that you might have a 32 vs 64-bit issue. Did you build DBD::mysql from a tarball? If there's a .dylib next to that .bundle, or something you could run ldd on to see the linkage? --Eric -- The only thing that could save UNIX at this late date would be a new $30 shareware version that runs on an unexpanded Commodore 64. --Don Lancaster (1991) --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- _______________________________________________ Pdx-pm-list mailing list Pdx-pm-list at pm.org http://mail.pm.org/mailman/listinfo/pdx-pm-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.hengst at gmail.com Mon Mar 22 09:16:29 2010 From: ben.hengst at gmail.com (benh) Date: Mon, 22 Mar 2010 09:16:29 -0700 Subject: [Pdx-pm] [Open Source Bridge] CfP ends March 25th!!!! Message-ID: <85ddf48b1003220916g2e241178pa030d00ac95c526b@mail.gmail.com> Open Source Bridge http://opensourcebridge.org Open Source Bridge is a conference for developers working with open source technologies. It will take place June 1?4, 2010, in Portland, Oregon, with five tracks connecting people across projects, languages and experience to explore how we do our work and why we participate in open source. The conference structure is designed to provide developers with an opportunity to learn from people they might not connect with at other events. Attendees will learn and interact at three days of traditional conference presentations, a day of free-form unconference sessions, and our 24-hour Hacker Lounge. This year we are thrilled to have an excellent downtown location at the Portland Art Museum ( http://pam.org/ ), an extra day packed full of open source goodness, and an on-site 24-hour Hacker Lounge! As a user group member, you can use the coupon code "osbugluv" to register for only $200 when you select either an Early Bird Registration (through April 1st), or a Regular Registration (after April 1st). Learn more and register today at http://opensourcebridge.org/attend/ The conference is run entirely by volunteers who believe in the need for an open source event that focuses on the culture of being an open source citizen, regardless of where in the stack you choose to code. All proceeds from conference registration and sponsorship go directly to the costs of the conference. Our event shares in-depth knowledge about using, creating and contributing to open source as citizens of a greater community. You?ll find relevant information whether you write web apps for the cloud, tinker with operating system internals, create hardware, run a startup, or blog about technology. We're still seeking proposals ? and we've just extended the deadline through March 25th ? so submit yours before time runs out at http://opensourcebridge.org/proposals/ Visit http://opensourcebridge.org/ to learn more about the conference, see our session proposals, and register to attend. Thanks! -- benh~ http://three.sentenc.es/ From stephen at enterity.com Sat Mar 27 10:15:22 2010 From: stephen at enterity.com (Stephen Howard) Date: Sat, 27 Mar 2010 10:15:22 -0700 Subject: [Pdx-pm] Looking for developer(s) for a new project. Message-ID: <412C69CE-6D20-4807-819F-6F54404B3644@enterity.com> Hello fellow perl mongers, I?ve recently started a project via the Startup Weekend phenomenon, and find myself the only developer on a very cool team. I?d like to convince someone in the PDX.pm community to join me on the development end of things and really make this software rock. The project is called CluePad (www.cluepad.com) and we?re looking to use data culled from multiple sources (web crawling and the Google Analytics API for starters) to make simple-to-follow tips that small business owners can use to improve their websites in ways that help their bottom line. Right now the options for these small business owners are either to a) spend a lot of time learning and sifting through data on their own, or b) hiring someone on a pricy monthly retainer to handle it for them. CluePad would be a low-cost, low-time- investment alternative to both of these. We?re using Catalyst/Template Toolkit and DBIx Class for the site. The goal is to spin this into a profitable company, but there?s no money in it yet. I?ve got the first generation of the site built and am fine tuning it this week before we let in some early adopters. I?m looking for someone familiar with the modules above, and who is used to maintaining a test suite as a matter of course. Bonus points for being fluent with jQuery on the client side, or for experience with scaling and parallelizing data collection and analysis on the back end. This will primarily be a telecommuting project. If you?re interested we?ll have an initial period working together to see whether we?re a good fit for each other, and when that goes well we?ll have a discussion about equity. We've got over 30 people waiting to try the software out from some minimal pre-release marketing, and have a couple team members who are ready and able to get this in front of a lot more people in our target market. This idea was also the winner at Startup Weekend Corvallis in December and the startup weekend folks are eager to put their muscle behind promoting our success. thanks, Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From enobacon at gmail.com Mon Mar 29 15:20:22 2010 From: enobacon at gmail.com (Eric Wilhelm) Date: Mon, 29 Mar 2010 15:20:22 -0700 Subject: [Pdx-pm] Google Summer of Code and TPF call for students Message-ID: <201003291520.22530.enobacon@gmail.com> Hi all, TPF is participating in GSoC 2010 and is accepting applications from students until the 9th. Please share this info with your academic contacts. If you are a college student interested in Open Source software, now is the time to get involved. http://code.google.com/soc/ Each year, Google offers students the opportunity to spend their summer coding on open source projects. You propose a project, and if selected, you're assigned a mentor and provided a $5000 stipend. It is a competitive program to get into, but offers an amazing amount of real-world experience and the ability to get seriously involved in an open source project of your choosing. The Perl Foundation spans a wide variety of projects including Perl 5, Perl 6, and Parrot with many great mentors knowledgeable in areas ranging from language design, virtual machines, and compilers through web and desktop applications. This program is a great chance to get more involved in the Perl community and put a substantial project worth of source code in your portfolio. Applications are due April 9th. http://www.perlfoundation.org/perl5/index.cgi?gsoc Thanks, Eric -- http://pdx.pm.org From publiustemp-pdxpm at yahoo.com Tue Mar 30 00:15:40 2010 From: publiustemp-pdxpm at yahoo.com (Ovid) Date: Tue, 30 Mar 2010 00:15:40 -0700 (PDT) Subject: [Pdx-pm] Google Summer of Code and TPF call for students In-Reply-To: <201003291520.22530.enobacon@gmail.com> Message-ID: <302569.62817.qm@web65711.mail.ac4.yahoo.com> --- On Mon, 29/3/10, Eric Wilhelm wrote: > From: Eric Wilhelm > TPF is participating in GSoC 2010 and is accepting > applications > from students until the 9th.? Please share this info > with your academic > contacts. Eric, Just in case no one else has (or even if they have), I just want to say thank you for all of your hard work on this. You're helping the Perl community and giving students a great opportunity to get involved in open source. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 From enobacon at gmail.com Tue Mar 30 08:30:09 2010 From: enobacon at gmail.com (Eric Wilhelm) Date: Tue, 30 Mar 2010 08:30:09 -0700 Subject: [Pdx-pm] Google Summer of Code and TPF call for students In-Reply-To: <302569.62817.qm@web65711.mail.ac4.yahoo.com> References: <302569.62817.qm@web65711.mail.ac4.yahoo.com> Message-ID: <201003300830.09650.enobacon@gmail.com> # from Ovid # on Tuesday 30 March 2010 00:15: >I just want to say thank you for all of your hard work on this. > ?You're helping the Perl community and giving students a great > opportunity to get involved in open source. I appreciate the recognition. Thank Jonathan, Jerry, and all of the mentors. I'm really just the messenger anymore. --Eric -- Turns out the optimal technique is to put it in reverse and gun it. --Steven Squyres (on challenges in interplanetary robot navigation) --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From raanders at cyber-office.net Tue Mar 30 11:56:02 2010 From: raanders at cyber-office.net (Roderick A. Anderson) Date: Tue, 30 Mar 2010 11:56:02 -0700 Subject: [Pdx-pm] Custom CentOS RPM of Perl Message-ID: <4BB24942.1000003@cyber-office.net> I have seen postings (mostly on the Catalyst list) that the Perl RPM for the Redhat based distributions is pretty bad. I've seen stuff that makes me agree. An @INC the gives me a head ache to look at and can't be good when searching for modules. I'd like to build (or find) a Perl RPM that replaces the one provided. This is for CentOS systems. Is this something a mostly sane person :-) should try? Anyone have experience doing this and can point me in the right direction? TIA, Rod -- From db at kavod.com Tue Mar 30 12:10:50 2010 From: db at kavod.com (Daniel Browning) Date: Tue, 30 Mar 2010 12:10:50 -0700 Subject: [Pdx-pm] Custom CentOS RPM of Perl In-Reply-To: <4BB24942.1000003@cyber-office.net> References: <4BB24942.1000003@cyber-office.net> Message-ID: <201003301210.50574.db@kavod.com> On Tuesday 30 March 2010 11:56:02 am Roderick A. Anderson wrote: > I have seen postings (mostly on the Catalyst list) that the Perl RPM for > the Redhat based distributions is pretty bad. I agree. For one, I prefer a non-threaded perl. > I'd like to build (or find) a Perl RPM that replaces the one provided. > This is for CentOS systems. Here is one that I use and recommend: http://packages.endpoint.com/ The catch is that it does not replace the system perl, it only supercedes it by installing in /usr/local/ (which is generally ahead of /usr/). The RPM files are named local-perl-* instead of perl-* to keep them separate. If part of your motivation for replacing the system perl is due to hard- coded paths to /usr/bin/perl, I suggest replacing them with this: #!/usr/bin/env perl Then they will automatically use /usr/local/ in a standard environment configuration. (Or they can all be switched to something else just by changing the environment, and you don't have to modify a host of paths. DRY principle and all that.) > Is this something a mostly sane person :-) should try? Personally, I wouldn't try to replace the system perl because the other software linked to it probably depends on the very things I want to change, such as threadiness. Theoretically, if you descend deep enough into the dependencies (e.g. Apache, MySQL, etc.), you could resolve all of that, but I would predict the loss of at least some sanity. Hope that helps, -- DB From jshirley at gmail.com Tue Mar 30 12:16:40 2010 From: jshirley at gmail.com (J. Shirley) Date: Tue, 30 Mar 2010 12:16:40 -0700 Subject: [Pdx-pm] Custom CentOS RPM of Perl In-Reply-To: <4BB24942.1000003@cyber-office.net> References: <4BB24942.1000003@cyber-office.net> Message-ID: <756703691003301216x59379928i3c62051beba87dc9@mail.gmail.com> On Tue, Mar 30, 2010 at 11:56 AM, Roderick A. Anderson wrote: > I have seen postings (mostly on the Catalyst list) that the Perl RPM for the > Redhat based distributions is pretty bad. ?I've seen stuff that makes me > agree. ?An @INC the gives me a head ache to look at and can't be good when > searching for modules. > > I'd like to build (or find) a Perl RPM that replaces the one provided. This > is for CentOS systems. ?Is this something a mostly sane person :-) should > try? > > Anyone have experience doing this and can point me in the right direction? > > > TIA, > Rod > -- I'd recommend checking out perlbrew. http://search.cpan.org/~gugod/App-perlbrew-0.03/lib/App/perlbrew.pm It will let you build out multiple perl binaries and their own lib paths. I never use vendor-supplied perls, instead built my own and then combine that with local::lib. This means I don't ever worry about me breaking the OS, or the OS breaking my code. Perlbrew simplifies all of this, though, and I'd highly recommend looking at it. -J From raanders at cyber-office.net Tue Mar 30 13:17:31 2010 From: raanders at cyber-office.net (Roderick A. Anderson) Date: Tue, 30 Mar 2010 13:17:31 -0700 Subject: [Pdx-pm] Custom CentOS RPM of Perl In-Reply-To: <201003301210.50574.db@kavod.com> References: <4BB24942.1000003@cyber-office.net> <201003301210.50574.db@kavod.com> Message-ID: <4BB25C5B.7080001@cyber-office.net> Daniel Browning wrote: > On Tuesday 30 March 2010 11:56:02 am Roderick A. Anderson wrote: > I have seen postings (mostly on the Catalyst list) that the Perl RPM for > the Redhat based distributions is pretty bad. > Thanks Daniel, and Keith Lofstrom, and J. Shirley for you insights. Especially about not replacing (or using) the distribution Perl. > I agree. For one, I prefer a non-threaded perl. > >> I'd like to build (or find) a Perl RPM that replaces the one provided. >> This is for CentOS systems. > > Here is one that I use and recommend: > > http://packages.endpoint.com/ Thank you! > The catch is that it does not replace the system perl, it only supercedes it > by installing in /usr/local/ (which is generally ahead of /usr/). The RPM > files are named local-perl-* instead of perl-* to keep them separate. > > If part of your motivation for replacing the system perl is due to hard- > coded paths to /usr/bin/perl, I suggest replacing them with this: > > #!/usr/bin/env perl > > Then they will automatically use /usr/local/ in a standard environment > configuration. (Or they can all be switched to something else just by > changing the environment, and you don't have to modify a host of paths. DRY > principle and all that.) Thanks again. >> Is this something a mostly sane person :-) should try? > > Personally, I wouldn't try to replace the system perl because the other > software linked to it probably depends on the very things I want to change, > such as threadiness. Theoretically, if you descend deep enough into the > dependencies (e.g. Apache, MySQL, etc.), you could resolve all of that, but > I would predict the loss of at least some sanity. Oh yeah. I descended into that recursive existence before. No thanks. Dealing with CPAN dependencies is enough. > Hope that helps, It does. \\||/ Rod -- > -- > DB > _______________________________________________ > Pdx-pm-list mailing list > Pdx-pm-list at pm.org > http://mail.pm.org/mailman/listinfo/pdx-pm-list