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
--Larry Wall in <199911192358.PAA24109@kiev.wall.org>
Did I say I expect Perl to do the right thing? :-)
--Larry Wall in <199911200217.SAA24898@kiev.wall.org>
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
To be fair.. (Score:2)
The blog about this bug wasn't reporting it, it was highlighting the fact that RHEL *still* hadn't fixed it, and gave some interesting background, including links to the thread on the dbic list about it.
We happen to be affected by this bug and it's really annoying - a 10% performance loss from ithreads isn't really an issue as our servers are almost entirely I/O or DB bound, adding DBIx::Class makes for sucky performance on the dev server, but fortunately our production servers don't have the problem.
It's tempting to install our own perl, but compiling perl and recompiling and installing all the CPAN packages on every live server is no small job and one thing we can do without.
@JAPH = qw(Hacker Perl Another Just);
print reverse @JAPH;
Reply to This
Re: (Score:1)
Do you really need to compile the modules on every box?
For the project at work, we install almost all CPAN deps in an app specific directory under a local user account. Those files are version controlled together with the application source.
Release basically consists of tarring up the source tree (including deps), and release is untarring things in the correct place and running a configuration script.
If you have different architectures on your boxes this obviously won't work without some extra maneuvers.
We
Re: (Score:2)