Quote: "Are you idiot?"
Well Slava, whatever your programming skills and depth of experience
amount to, you blew your chances right there. You just can't talk to
potential employers (or their agents) in such a manner.
At this point, I wouldn't even have afforded you the courtesy of a reply
if I h
Nick Phillips wrote:
Thanks to all who responded; it looks like I may have misled myself about
what Apache::Test will let me do. I do however have another problem now --
when I 'perl Makefile.PL' for Apache::Test, it warns that it will remove
/usr/lib/perl5/Apache/test.pm during the install. This i
Thanks to all who responded; it looks like I may have misled myself
about
what Apache::Test will let me do. I do however have another problem now
--
when I 'perl Makefile.PL' for Apache::Test, it warns that it will remove
/usr/lib/perl5/Apache/test.pm during the install. This is despite the
fact
I've been recently looking for a telecommute job in order to provide
some Christmas support to my family. Obviously, I tried one ad from the
Perl Telecommuting Job List. Negotiations took not a long time. Full
listing is provided. Especially, I would underline the funny way that
Laurie J. Roth - Di
On Mon, 08 Dec 2003 11:27:36 -0800, Stas Bekman <[EMAIL PROTECTED]> wrote:
>Jan Dubois wrote:
>> We observe the following mod_perl test failures on HP-UX 11.00 on PA-RISC,
>> with both HP C and GCC in both 32 bit and 64 bit mode. They are not
>> present on IPF systems in any of these combinations
On Thu, 2003-12-11 at 17:04, Kevin Old wrote:
> Thanks for your reply. I'm explicitly setting them in my startup.pl as
> belowisn't that the same as the PerlPassEnv directive?
Pretty much. I'd suggest modifying your copy of Apache::DBI so that it
logs the value of these %ENV settings wheneve
On Thu, 2003-12-11 at 22:00, Stas Bekman wrote:
> Raul Dias wrote:
> > I did mean to sound as a rant (if I did). I know that's not easy to
> > keep with the documentation.
>
> what can you do with your subconscious which seems to tell the truth of what
> you've really meant ;)
>
>:)
> Doc pat
Raul Dias wrote:
perl-5.8.3-ithread -MApache2 -MModPerl::MethodLookup -e print_object
Apache::RequestRec | wc -l
149
Great. This is a good start point for me.
In that case please see:
http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#top
I did mean to sound as a rant (if I did).
On Thu, 2003-12-11 at 20:43, Stas Bekman wrote:
> Raul Dias wrote:
> > On Thu, 2003-12-11 at 16:30, Stas Bekman wrote:
> >
> >>Raul Dias wrote:
> >>
> >>>On Wed, 2003-12-10 at 20:42, Stas Bekman wrote:
[...]
> > It would really help to have some section about all the methods
> > available to $fil
Hi there,
On Thu, 11 Dec 2003, John Saylor wrote:
> i decided to try and let perl do as much of it as i could. here is my
> makepl_args.mod_perl:
> APACHE_SRC=../apache_1.3.29/src USE_APACI=1 USE_DSO=1 [...]
I'd always start with a statically linked mod_perl if I could.
Is there a reason you nee
Hi there,
On Wed, 10 Dec 2003, Hakan Nilsson wrote:
> Most often we have links like
>
> A link!
>
> which sometimes work and sometimes fails
Have you checked the error_log?
73,
Ged.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Raul Dias wrote:
On Thu, 2003-12-11 at 16:30, Stas Bekman wrote:
Raul Dias wrote:
On Wed, 2003-12-10 at 20:42, Stas Bekman wrote:
Lastly, why does the memory continue to be consumer after the client has
terminated the connection?
Because the server doesn't realize that the connection was abort
On Thu, 2003-12-11 at 16:47, Perrin Harkins wrote:
> On Wed, 2003-12-10 at 22:42, Kevin Old wrote:
> > I am able to setup a DSN and use it successfully via a "regular" perl
> > script, but when I try to have Apache::DBI connect to it in my
> > startup.pl I get a message in the log stating that the
On Tue, 2003-12-09 at 19:38, andrew dunn wrote:
> There is one problem though related to the what seems like caching of
> pages. I'm building each page of categories based on the category id
> passed in, and when I access one page (e.g. cat_id=10), followed quickly
> by another of a different categ
On Wed, 2003-12-10 at 22:42, Kevin Old wrote:
> I am able to setup a DSN and use it successfully via a "regular" perl
> script, but when I try to have Apache::DBI connect to it in my
> startup.pl I get a message in the log stating that the DSN wasn't
> defined in the unixODBC DM. This is correct,
hi
i've been writing back and forth with stas about getting make test to
finish correctly.
i decided to try and let perl do as much of it as i could. here is my
makepl_args.mod_perl:
APACHE_SRC=../apache_1.3.29/src USE_APACI=1 USE_DSO=1 PERL_SSI=0 EVERYTHING=1
APACI_ARGS=--enable-module=ssl,--en
Nick Phillips wrote:
On 12/12/2003, at 8:34 AM, Garrett Goebel wrote:
Nick Phillips wrote:
>
> Just wondering whether anyone here has any cunning ways of
> unit testing code that uses the various Apache:: modules;
> the only vaguely useful thing I've managed to find so far
> is Apache::FakeRequest
John Saylor wrote:
hi
( 03.12.11 11:19 -0800 ) Stas Bekman:
try adding
$INC{"My.pm"} = __FILE__;
just before:
PerlChildInitHandler My::child_init
i did it and it's about the same. here's the error log:
OK, how about:
$INC{"My.pm"} = __FILE__;
$INC{"My/child_init.pm"} = __FILE__;
i apprecia
On Fri, 12 Dec 2003 08:55:43 +1300
Nick Phillips <[EMAIL PROTECTED]> wrote:
> So far as I can see, that is all directed at testing by sending a
> request
> to a server and checking what comes back; that's really not useful for
> testing components of code individually, which is the point. I don't
Title: RE: Testing
Nick Phillips wrote:
> Garrett Goebel wrote:
> > Nick Phillips wrote:
> > >
> > > Just wondering whether anyone here has any cunning ways of
> > > unit testing code that uses the various Apache:: modules;
> > > the only vaguely useful thing I've managed to find so far
> > >
>
> So far as I can see, that is all directed at testing by sending a request
> to a server and checking what comes back; that's really not useful for
> testing components of code individually, which is the point. I don't
> want to test the server, I want to individually test each chunk of my cod
On Thu, 2003-12-11 at 16:30, Stas Bekman wrote:
> Raul Dias wrote:
> > On Wed, 2003-12-10 at 20:42, Stas Bekman wrote:
> >
> >
> >>>Lastly, why does the memory continue to be consumer after the client has
> >>>terminated the connection?
> >>
> >>Because the server doesn't realize that the connect
hi
( 03.12.11 11:19 -0800 ) Stas Bekman:
> try adding
>
> $INC{"My.pm"} = __FILE__;
>
>
> just before:
> PerlChildInitHandler My::child_init
i did it and it's about the same. here's the error log:
[Thu Dec 11 14:59:23 2003] [error] Can't locate My/child_init.pm in @INC (@INC
contains: /usr/
> Effectively testing web apps without messing around with parsing HTML
> is something I've been wondering about for a while. Anyone solve
> this problem well?
Not sure if this falls into your parsing HTML category or not but I've
found it to be quite comprehensive when it comes to testing web
On 12/12/2003, at 8:34 AM, Garrett Goebel wrote:
Nick Phillips wrote:
>
> Just wondering whether anyone here has any cunning ways of
> unit testing code that uses the various Apache:: modules;
> the only vaguely useful thing I've managed to find so far
> is Apache::FakeRequest, but that still leav
> http://search.cpan.org/search?query=Apache+testing&mode=all
>
> http://search.cpan.org/~geoff/Apache-Test-1.06/
>
> http://perl.apache.org/docs/general/testing/testing.html
>
there's also
http://www.perl.com/pub/a/2003/05/22/testing.html
which might help as well. and while it's not nearly
At 8:30 AM +1300 12/12/03, Nick Phillips wrote:
Just wondering whether anyone here has any cunning ways of unit testing code
that uses the various Apache:: modules; the only vaguely useful thing I've
managed to find so far is Apache::FakeRequest, but that still leaves problems
with code that uses A
On Fri, 12 Dec 2003, Nick Phillips wrote:
> Just wondering whether anyone here has any cunning ways of unit testing
> code
> that uses the various Apache:: modules; the only vaguely useful thing
> I've
> managed to find so far is Apache::FakeRequest, but that still leaves
> problems
> with code
Title: RE: Testing
Nick Phillips wrote:
>
> Just wondering whether anyone here has any cunning ways of
> unit testing code that uses the various Apache:: modules;
> the only vaguely useful thing I've managed to find so far
> is Apache::FakeRequest, but that still leaves problems
> with code
Just wondering whether anyone here has any cunning ways of unit testing
code
that uses the various Apache:: modules; the only vaguely useful thing
I've
managed to find so far is Apache::FakeRequest, but that still leaves
problems
with code that uses Apache::Request, Apache::Cookie etc.
Surely *
John Saylor wrote:
hi
( 03.11.26 13:46 -0800 ) Stas Bekman:
and if you add:
$INC{"My/child_init.pm"} = __FILE__;
similar to my previous patch.
This is not the right solution, but something to try. For some reason it
can't see the sub child_init created in startup.pl, and tries to find it in
For those who have been waiting for CGI.pm 3.01, it's finally out and
available from your local CPAN mirrors. Thanks Lincoln.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide
hi
( 03.11.26 13:46 -0800 ) Stas Bekman:
> and if you add:
>
> $INC{"My/child_init.pm"} = __FILE__;
>
> similar to my previous patch.
>
> This is not the right solution, but something to try. For some reason it
> can't see the sub child_init created in startup.pl, and tries to find it in
>
Raul Dias wrote:
On Wed, 2003-12-10 at 20:42, Stas Bekman wrote:
Lastly, why does the memory continue to be consumer after the client has
terminated the connection?
Because the server doesn't realize that the connection was aborted. You can
check that with $c->aborted. It could also be a bug in
Hi
Got rather a shock this morning when I discovered twenty odd emails in
my Inbox!! I can see why open source development moves so fast ;)
;)
The version in CVS looks good. It consumes very little memory now,
starts off at 0.6%. I think there is still a small leak, it creaps up
very slowly at ab
Jacqui,
Thanks for your input. Per your suggestion, I upgraded CGI.pm. It,
unfortunately didn't have any effect. My script (see below) functions
as expected from the command line. It also works in Apache if I set the
MaxRequestsPerChild to 1 (I know this is not a good setting, I was just
tryin
On Wed, 2003-12-10 at 20:42, Stas Bekman wrote:
> > Lastly, why does the memory continue to be consumer after the client has
> > terminated the connection?
>
> Because the server doesn't realize that the connection was aborted. You can
> check that with $c->aborted. It could also be a bug in Apa
Hi Stas,
Got rather a shock this morning when I discovered twenty odd emails in
my Inbox!! I can see why open source development moves so fast ;)
The version in CVS looks good. It consumes very little memory now,
starts off at 0.6%. I think there is still a small leak, it creaps up
very slowly at
I actually went through that page aswell and managed to figure out all of
the problems by tidying up my code and variables. Thanks for the pointer.
Feel bad for you though Simon. It sucks when you don't get to program full
time in the language of your choice. I'm having to write web apps in C# for
- Original Message -
From: "Thomas Klausner" <[EMAIL PROTECTED]>
Subject: Re: mod_perl caching/delay
> Hi!
>
> On Wed, Dec 10, 2003 at 03:34:39PM -, Simon McCaughey wrote:
>
> > This sounds to me like the kinds of problem we had migrating to
mod_perl. It
> > sounds like a global varia
Stas Bekman wrote:
Pringle, Chris (HP-PSG) wrote:
Stas,
I tried the latest version this morning, and it doesn't appear to have
made a great deal of difference. I'm not sure whether it consumes memory
as fast, however, as you said, there are leaks elsewhere. The following
code reproduces it.
Chri
41 matches
Mail list logo
