Re: No more Perl "compiler"
by perrin (Chancellor) on Sep 12, 2006 at 20:52 UTC
|
I think you'll have more luck with approaches more like FastCGI/mod_perl. There are things like PPerl which should be adaptable to installation on ISPs. The large CGI system MiniVend used an approach with a Perl daemon and a tiny stub CGI that calls it to avoid the overhead of compiling. | [reply] [Watch: Dir/Any] |
Re: No more Perl "compiler"
by gellyfish (Monsignor) on Sep 13, 2006 at 08:37 UTC
|
PAR uses B::Bytecode if you want compiled code
Given the CAVEATS in PAR::Filter::Bytecode:
This backend exhibits all bugs listed in B::Bytecode, and then some.
Bytecode support is considered to be extremely fragile on Perl versions earlier than 5.8.1, and is still far from robust (as of this writing).
I'm actually surprised that anyone uses that facility. I guess that if anyone cares enough to keep B::Bytecode going after it has been removed from the core then they will step up to the plate to maintain it independently on CPAN.
The B suite of modules are always going to suffer from accelerated bit-rot if no-one is interested in looking after them because they have to keep pace with the changes in the internals and not just the published API. Whilst they have been in the core it appears people have been doing just enough to keep them passing the tests but no more (a reworking three years ago not withstanding:) certain comments on p5p would suggest that some changes in bleadperl have probably broken stuff that is not being tested for.
Of course the very fact that the module is tied so very closely to perl's internals and thus almost certainly to specific version ranges would probably suggest that it would need a massive overhaul if it were to be maintained on CPAN and work across a range of Perl versions, this in itself might be sufficient disincentive to anyone volunteering to do so.
A cursory examination of perlbug would seem to indicate that there have only been a handful of bug reports against B::Bytecode ever, which either indicates that there are no bugs (unlikely) or people just aren't using it enough to discover any bugs - and given the EXPERIMENTAL label scattered throughout the documentation, I would suggest the latter.
/J\
| [reply] [Watch: Dir/Any] [d/l] |
|
Well, my current company uses B::Bytecode, but after a bit of discussion, I convinced them to drop it. Whew!
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
Re: No more Perl "compiler"
by diotalevi (Canon) on Sep 12, 2006 at 19:54 UTC
|
I'd never even seen the thing work. If it works for you perhaps you'd consider maintaining it? You never commented to my p5p post of several months ago about removing it.
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
If it works for you perhaps you'd consider maintaining it? You're joking, right? Just because I used it successfully as advertised doesn't mean that I'm familiar enough with its internal workings to be able to maintain/fix/improve it. (Otherwise, I would have considered breaking it out as a separate CPAN module.) No, I wasn't joking. I think you're really capable and could do it.My post was meant to inform others of its removal, and to query about possible alternatives. For your purpose you'd switch to some persistent environment like what you already suggested or pperl.
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
Re: No more Perl "compiler"
by derby (Abbot) on Sep 13, 2006 at 12:23 UTC
|
Then again, maybe I'm deluding myself
So stop thinking you may be deluding yourself and check to ensure you are. I'd do some benchmarking.
I think you'll find that the speed up is either not there or neglible given other factors (network latency) ... but then again maybe I'm delusional.
| [reply] [Watch: Dir/Any] |
Re: No more Perl "compiler"
by Lu. (Hermit) on Sep 16, 2006 at 10:22 UTC
|
Well if you're in need of compiling PErl, you could take a look at PerlBIN.
It's still in development, but it works on any platform. | [reply] [Watch: Dir/Any] |
Re: No more Perl "compiler"
by shmem (Chancellor) on Sep 16, 2006 at 19:34 UTC
|
Have you considered using AutoLoader? For each CGI run, you certainly don't need every and all functions in such scripts as Oddmuse.
--shmem
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
| [reply] [Watch: Dir/Any] |
Re: No more Perl "compiler"
by Anonymous Monk on Sep 13, 2006 at 07:35 UTC
|
perl2exe/PAR won't speed up | [reply] [Watch: Dir/Any] |