Since Steve Hay asked for trunk vs 5.24 and 2.4 reports, I
gave it a whirl on Omnios/Illumos.
t/filter/in_bbs_inject_header.t is my only fail with
useithreads=undef perl and -with-mpm=prefork httpd.
John
groenv...@acm.org
$ env
PATH=/opt/apache24/bin:/opt/apache24/perl-5.24.0/bin:/usr/bin:/usr/
Thanks for the heads up ... will definitely put that on the roadmap. For
now I will stick to 2.2 to reduce the number of things that might go
wrong, but once we get stable on this version I'll look into 2.4
Bill
On 7/22/2016 12:27 PM, John D Groenveld wrote:
In message
, William A Rowe Jr w
In message
, William A Rowe Jr writes:
>Note that httpd 2.4.23 announcement warned of the imminent end of httpd 2.2
>as well. You would do well to build your httpd 2.4 / perl 5.24 / mod
>perl.next that should be tagged soon as your next stack.
http://mail-archives.apache.org/mod_mbox/httpd-announ
On Jul 21, 2016 8:24 PM, "William Ward" wrote:
>
> OK I will give that a try. Unfortunate, as 5.24.0 has been blessed with
LTS status by the Perl gods. Hopefully a new mod_perl will come out that
includes this fix.
Note that httpd 2.4.23 announcement warned of the imminent end of httpd 2.2
as wel
Sorry, with all the things we're upgrading I don't want to add the
variable of experimental code into the mix. I'll just run 5.20.3 for now.
Bill
On 7/22/2016 12:12 AM, Steve Hay wrote:
Yes, I intend to make a new mod_perl release with the fix very soon
after two maint perl releases (5.22.3 /
I thought I saw somewhere the term LTS used with respect to Perl 5.24
but can't find it now... however they do push pretty hard to run the
latest version:
* On https://www.perl.org/get.html it says, "We recommend that you
always run the latest stable version, currently 5.24.0. If you're
I think it really depends on what the handler is doing. If it is mainly
executing some db queries rewriting it in C won't make much of a
difference. If the handler is doing some expensive computation it might
be worth it. Before you rewrite the whole handler though you should look
at the option
yes I totally agree with you, modperl is also perl, it has the big
advantage of using CPAN. for example, we have used these modules in the
project,
Data::Validate::Domain
Data::Validate::Email
Data::Validate::IP
I don't think they are easy to port into C language.
So perl is great, modperl is
On 22.07.2016 11:00, yhp...@orange.fr wrote:
Hello,
We have some handlers which were written by modperl for API endpoints.
yes developing a apache handler with modperl is so easy and quick.
but for better performance we also consider the C handler.
(one of the APIs has got 1,500,000 accesses by
Hello,
We have some handlers which were written by modperl for API endpoints.
yes developing a apache handler with modperl is so easy and quick.
but for better performance we also consider the C handler.
(one of the APIs has got 1,500,000 accesses by unique clients)
Do you think if it's valuable
On Thu, Jul 21, 2016 at 06:24:05PM -0700, William Ward wrote:
> OK I will give that a try. Unfortunate, as 5.24.0 has been blessed with LTS
> status by the Perl gods. Hopefully a new mod_perl will come out that
> includes this fix.
Where do you find a reference to LTS support for perl 5.24.0? As f
Yes, I intend to make a new mod_perl release with the fix very soon
after two maint perl releases (5.22.3 / 5.24.1) are done. Sorry this
fix has languished so long.
In the meantime, if you're able to grab the latest SVN source and try
it then that would be a great help: It should be good to go, bu
12 matches
Mail list logo
