clscott's Journal clscott's use Perl Journal en-us use Perl; is Copyright 1998-2006, Chris Nandor. Stories, comments, journals, and other submissions posted on use Perl; are Copyright their respective owners. 2012-01-25T02:36:43+00:00 pudge Technology hourly 1 1970-01-01T00:00+00:00 clscott's Journal Apache Olio: Can we see a couple of different perl versions? <p>I just ran across a new Apache project called <a href="">Olio</a>.</p><blockquote><div><p>Olio is a is a web2.0 toolkit to help evaluate the suitability, functionality and performance of web technologies. Olio defines an example web2.0 application ( an events site somewhat like and provides three initial implementations : PHP, Java EE and RubyOnRails (ROR). The toolkit also defines ways to drive load against the application in order to measure performance.</p></div> </blockquote><p> Olio provides a project description, raw data and relationships plus html and css mockups for each screen of the application. </p><p> The project is looking for alternate implementations which leads me to the actual point of this post:<br> This looks like a great opportunity for the various perl frameworks to showcase their unique advantages. As such it would also help some folks make the choice between the perl frameworks.</p><p>Will anyone besides the Mojo camp actually do this though?</p> clscott 2008-11-15T17:33:56+00:00 journal Seen on Mashable: 20+ tools for perl development <p></p><p>The toolbox is full of crud. Granted, the CPAN, Catalyst and Mason are listed but WTF are people perpetuating Matt's Script Archive in 2007?</p><p> I have never heard of their 1st choice for online perl tutorials or half of the others, and I've doing (at least) weekly web searches on perl related topics for 10 years.</p><p>The Perl community can produce a much better list but could it boiled down to just 20 tools?</p> clscott 2007-10-02T13:57:57+00:00 journal Perl too smart require()ing libs <b>Background</b> <p> At $work we have a bunch of perl 4 style libraries that get required into apps when we need their functionality. </p><p> As they are not packages they automatically pull a whole pile of subroutine and variable definitions into the main:: namespace. I wasn't feeling very happy about that. </p><p> So in a effort to begin refactoring I wrote packages as wrappers around these libraries. The packages use Exporter and @EXPORT_OK so we could use the package and import only the subroutines our apps actually needed. This allows us to incrementally migrate the code base to the package style as we need to, by keeping the original libraries intact. </p><p>As these types of things usually do, there are interdependencies between the libraries, for example calls a sub defined in so the package for ( needs to require both and </p><p> <b>The problem</b> </p><p> When I "use" two wrapper packages and they both "require" the same lib, the second package gets shafted and doesn't get the subroutines defined and imported into its namespace. </p><p> <b>The Question</b> </p><p>How the heck can I work around or overcome this?</p><p>Or what's an alternate solution that meets my goals?</p><p> <a href="">Code and discussion on PerlMonks</a></p> clscott 2007-06-22T05:35:48+00:00 journal