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 ]

jhorwitz (4227)

jhorwitz
  reversethis-{gro.gnihsams} {ta} {ffej}
http://www.smashing.org/

System administrator, Perl hacker, author of "Unix System Management Primer Plus" (SAMS 2003), mod_parrot, extproc_perl, Authen::Krb4, Authen::Krb5.

Journal of jhorwitz (4227)

Monday April 12, 2004
02:43 PM

extproc_perl release

[ #18300 ]
I've just released extproc_perl version 1.99_08. Most of the changes are the result of user input, so there should be much joy in userland. Now I just have to get 2.0 out the door before YAPC.

http://www.smashing.org/extproc_perl

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • If I find the perfect solution to something on CPAN, am I gonna make myself impopular if I suggest using extproc_perl?

    Do you know how it compares to PL/SQL when it comes to performance?
    • *impopular*? :-)

      PL/SQL tends to be faster when using its builtin operations. However, Perl is infinitely more flexible, and the availability of CPAN modules make it a winner when it comes to functionality. Once Perl is parsed and compiled, it's pretty fast. Actual speed really depends on what you're doing and how often you do it. The number one bottleneck is interpreter initialization (see mod_perl), but that's a one-time hit especially if you're using app server connection pools or Apache::DBI. And