Mailing List Archive

https://perl.apache.org/contribute/svn_howto.html
For detailled information

And specifically, the svn repo is over here :
https://svn.apache.org/repos/asf/perl/modperl/trunk/

Sent from the depths of my mind on an iPhone

> On Feb 17, 2017, at 2:58 PM, Tom Browder <tom.browder@gmail.com> wrote:
>
> Is the mod_perl source code repo publicly available? If so, I can't find a link on the website.
>
> Thanks.
>
> Best regards,
>
> -Tom

On Fri, Feb 17, 2017 at 14:58 Philippe Chiasson <gozer@ectoplasm.org> wrote:

https://perl.apache.org/contribute/svn_howto.html
For detailled information

And specifically, the svn repo is over here :
https://svn.apache.org/repos/asf/perl/modperl/trunk/


Thanks, Philippe, I didn't look on that page long enough.

Any plans to support Perl 6?

Best regards,

-Tom

<https://svn.apache.org/repos/asf/perl/modperl/trunk/>

>>>>> "Tom" == Tom Browder <tom.browder@gmail.com> writes:

Tom> Any plans to support Perl 6?

You mean, "Any plans to rewrite it from scratch?"

You do realize that Perl 6 is an entirely different language, yes?

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

On 02/19/2017 01:44 AM, Randal L. Schwartz wrote:
>>>>>> "Tom" == Tom Browder <tom.browder@gmail.com> writes:
>
> Tom> Any plans to support Perl 6?
>
> You mean, "Any plans to rewrite it from scratch?"
>
> You do realize that Perl 6 is an entirely different language, yes?
>

Is Lincoln Stein still around?

--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013

On Sun, Feb 19, 2017 at 00:44 Randal L. Schwartz <merlyn@stonehenge.com>
wrote:

> >>>>> "Tom" == Tom Browder <tom.browder@gmail.com> writes:

...

>
Randall, I do know that, and I love Perl 6! I also feel comfortable
writing CGI programs, so how can I use both most efficiently with my apache
web server.?

Best regards,

-Tom

P.S. I enjoyed meeting you and shaking hands with you at YAPC::NA::2016.
Thanks for all your contributions to the Perl community!

Many years ago Jeff Horwitz had a proof of concept mod_parrot, which allowed a mod_perl6. He did some talks about it at YAPC. Lots of things have changed since then though. Notably perl6 is mostly using moarVM these days, which might mean that effort isn't useful any more, but I don't really know.

At any rate, there hasn't been any effort from the mod_perl PMC to port/rewrite/support perl6 at this time.

Adam

> On Feb 19, 2017, at 7:49 AM, Tom Browder <tom.browder@gmail.com> wrote:
>
>> On Sun, Feb 19, 2017 at 00:44 Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>> >>>>> "Tom" == Tom Browder <tom.browder@gmail.com> writes:
> ...
>
> Randall, I do know that, and I love Perl 6! I also feel comfortable writing CGI programs, so how can I use both most efficiently with my apache web server.?
>
> Best regards,
>
> -Tom
>
> P.S. I enjoyed meeting you and shaking hands with you at YAPC::NA::2016. Thanks for all your contributions to the Perl community!

On Sun, Feb 19, 2017 at 2:11 PM, Adam Prime <adam.prime@utoronto.ca> wrote:
> Many years ago Jeff Horwitz had a proof of concept mod_parrot, which allowed
> a mod_perl6. He did some talks about it at YAPC. Lots of things have changed
> since then though. Notably perl6 is mostly using moarVM these days, which
> might mean that effort isn't useful any more, but I don't really know.
>
> At any rate, there hasn't been any effort from the mod_perl PMC to
> port/rewrite/support perl6 at this time.

Thanks, Adam.

Best regards,

-Tom

Explore the idea of wrapping your app as an fcgid endpoint. Httpd has two
options (mod_fcgid managing the pool, and mod_proxy_fcgi with your own
choice of independent pool management.)

This offers the best of both... Larger number of httpd endpoints and less
contention between fcgi processes. It is now the recommended approach to
PHP and other scripting endpoints.

On Feb 19, 2017 06:50, "Tom Browder" <tom.browder@gmail.com> wrote:

On Sun, Feb 19, 2017 at 00:44 Randal L. Schwartz <merlyn@stonehenge.com>
wrote:

> >>>>> "Tom" == Tom Browder <tom.browder@gmail.com> writes:

...

>
Randall, I do know that, and I love Perl 6! I also feel comfortable
writing CGI programs, so how can I use both most efficiently with my apache
web server.?

Best regards,

-Tom

P.S. I enjoyed meeting you and shaking hands with you at YAPC::NA::2016.
Thanks for all your contributions to the Perl community!

Hello.

I am catching this at the end, but the general subject interests me, and I'd like to know
more. Should I start a new thread ? and what best to name it ?

My situation : I am not a hot-shot programmer nor perl expert, but over time I have
written quite a few mod_perl-based pieces of code, roughly in 2 categories :
1) one category which interacts quite heavily with the Apache request processing phases
and with the Request object, such as authentication, various kinds of proxying, wraps
around DAV to make it do what I want, output filters etc.
2) another category of things which could have been done using CGI and Apache::Registry
(processing <form> submits etc.), but since I was already doing the first kind above, I've
done these by creating add-on mod_perl modules instead. (Which do sometimes rely on
something that has been done by the first category, like $r->pnotes).

But if really "It is now the recommended approach to PHP and other scripting endpoints"
(including, I suppose, perl), it looks like I would slowly have to change my strategy.

If I understand the general idea correctly, it consists of no longer running complicated
and memory-hungry things directly in Apache through mod_perl, but to use Apache as a
front-end reverse proxy, and proxy such calls to one or more back-end processes having
their own persistent perl (or other) interpreter. Is that correct ?

Intuitively, I would imagine that the approach below fits my second category more than the
first, right ?
So, for the second type, where could I best start reading ?

(Contrarily to the original poster, I am perfectly happy with Perl 5, and not looking at
Perl 6 yet. I am also not really a fan of very abstract "frameworks", because of their
general "all or nothing" approach. Template::Toolkit is about my limit).



On 09.03.2017 04:30, William A Rowe Jr wrote:
> Explore the idea of wrapping your app as an fcgid endpoint. Httpd has two
> options (mod_fcgid managing the pool, and mod_proxy_fcgi with your own
> choice of independent pool management.)
>
> This offers the best of both... Larger number of httpd endpoints and less
> contention between fcgi processes. It is now the recommended approach to
> PHP and other scripting endpoints.
>
> On Feb 19, 2017 06:50, "Tom Browder" <tom.browder@gmail.com> wrote:
>
> On Sun, Feb 19, 2017 at 00:44 Randal L. Schwartz <merlyn@stonehenge.com>
> wrote:
>
>>>>>>> "Tom" == Tom Browder <tom.browder@gmail.com> writes:
>
> ...
>
>>
> Randall, I do know that, and I love Perl 6! I also feel comfortable
> writing CGI programs, so how can I use both most efficiently with my apache
> web server.?
>
> Best regards,
>
> -Tom
>
> P.S. I enjoyed meeting you and shaking hands with you at YAPC::NA::2016.
> Thanks for all your contributions to the Perl community!
>

On 3/9/17 2:52 AM, André Warnier wrote:

> If I understand the general idea correctly, it consists of no longer
> running complicated and memory-hungry things directly in Apache through
> mod_perl, but to use Apache as a front-end reverse proxy, and proxy such
> calls to one or more back-end processes having their own persistent perl
> (or other) interpreter. Is that correct ?

Pretty much.

Except its much more common to see something like nginx acting as the
proxy than Apache due to nginx's lighter footprint and better handling
of large numbers of concurrent connections.

If you are writing a Perl (5) web app these days, you should probably
write it using Plack/PSGI compatible framework (dancer, mojo, catalyst
etc) and run it under something like starman behind nginx (or apache or
any other http proxy that you prefer).

If you do not wish to use a framework, then just write it in plain
Plack/PSGI.

Regards,
Michael Schout

On Thu, 9 Mar 2017 09:52:27 +0100
Andr? Warnier <aw@ice-sa.com> wrote:


> If I understand the general idea correctly, it consists of no longer running complicated
> and memory-hungry things directly in Apache through mod_perl, but to use Apache as a
> front-end reverse proxy, and proxy such calls to one or more back-end processes having
> their own persistent perl (or other) interpreter. Is that correct ?
>

What is your use case? If this is for a high traffic site serving lots of static pages, or your databases are huge and require long running queries, it may be worth it.

My situation is the opposite, no static content, low traffic, all of it hitting small databases with 5 or six queries on average per page (for CRM type apps).

This is what top looks like on a dedibox serving about 20 users :

top - 16:25:21 up 11 days, 44 min, 1 user, load average: 0,00, 0,00, 0,00
Tasks: 128 total, 1 running, 127 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,0 us, 0,1 sy, 0,0 ni, 99,9 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 4041248 total, 1112512 used, 2928736 free, 134504 buffers
KiB Swap: 4094972 total, 0 used, 4094972 free. 661944 cached Mem

Tests with ab show 50 requests/second, and I don't see a memory problem that would warrant the overhead of a front-end reverse proxy.

--
Bien ? vous, Vincent Veyron

https://marica.fr/
Gestion des sinistres assurances, des dossiers contentieux et des contrats pour le service juridique