Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

clscott (4354)

clscott
  (email not shown publicly)

Journal of clscott (4354)

Saturday November 15, 2008
12:33 PM

Apache Olio: Can we see a couple of different perl versions?

I just ran across a new Apache project called Olio.

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 yahoo.com/upcoming) 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.

Olio provides a project description, raw data and relationships plus html and css mockups for each screen of the application.

The project is looking for alternate implementations which leads me to the actual point of this post:
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.

Will anyone besides the Mojo camp actually do this though?

Tuesday October 02, 2007
08:57 AM

Seen on Mashable: 20+ tools for perl development

http://mashable.com/2007/10/02/perl-toolbox/

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?

I have never heard of their 1st choice for online perl tutorials PageResource.com or half of the others, and I've doing (at least) weekly web searches on perl related topics for 10 years.

The Perl community can produce a much better list but could it boiled down to just 20 tools?

Friday June 22, 2007
12:35 AM

Perl too smart require()ing libs

Background

At $work we have a bunch of perl 4 style libraries that get required into apps when we need their functionality.

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.

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.

As these types of things usually do, there are interdependencies between the libraries, for example bar.pl calls a sub defined in foo.pl so the package for bar.pl (BarWrapper.pm) needs to require both bar.pl and foo.pl

The problem

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.

The Question

How the heck can I work around or overcome this?

Or what's an alternate solution that meets my goals?

Code and discussion on PerlMonks