Andreas J Koenig wrote:
On Tue, 28 Dec 2004 00:09:07 -0500, Stas Bekman <[EMAIL PROTECTED]> said:
>> Will it not also affect us who build mod_perl applications and want
>> an easy-to-use installer to just work for people who download our
>> software? Frankly, I don't think that it should be fin
Everybody needs to "STEP BACK" and realize how much work and soul Stas
has put into mod_perl.
He deserves A LOT OF CREDIT. Keep up the Good work Stas.
Paul
Stas Bekman wrote:
Andreas J Koenig wrote:
On Tue, 28 Dec 2004 00:09:07 -0500, Stas Bekman
<[EMAIL PROTECTED]> said:
>> Will it not also
> On Tue, 28 Dec 2004 00:09:07 -0500, Stas Bekman <[EMAIL PROTECTED]> said:
>> Will it not also affect us who build mod_perl applications and want
>> an easy-to-use installer to just work for people who download our
>> software? Frankly, I don't think that it should be fine for just the
>>
Cure wrote:
Everybody needs to "STEP BACK" and realize how much work and soul Stas
has put into mod_perl.
He deserves A LOT OF CREDIT. Keep up the Good work Stas.
Thanks Cure, for the kind words...
but we are talking about a different kind of credit here. Andreas has
put just as much work and soul
On Dec 27, 2004, at 9:58 PM, Stas Bekman wrote:
I think all you need to do is to write an equivalent of WriteMakefile
(and some other bits). The rest of the stuff in it, is a painful
exercise of overriding ExtUtils::MakeMaker MY:: methods.
You make it sound so appealing. I can't wait! But serious
David Wheeler wrote:
On Dec 27, 2004, at 9:58 PM, Stas Bekman wrote:
I think all you need to do is to write an equivalent of WriteMakefile
(and some other bits). The rest of the stuff in it, is a painful
exercise of overriding ExtUtils::MakeMaker MY:: methods.
You make it sound so appealing. I c
David Wheeler wrote:
> On Dec 27, 2004, at 9:58 PM, Stas Bekman wrote:
>
>> I think all you need to do is to write an equivalent of WriteMakefile
>> (and some other bits). The rest of the stuff in it, is a painful
>> exercise of overriding ExtUtils::MakeMaker MY:: methods.
>
>
> You make it so
Geoffrey Young wrote:
at any rate, it's a
big win for people writing mp2 stuff for CPAN, and I can see how M::B folks
could take advantage of a similar tool. however, stas is right, that tool
should be distributed with mp2 core so that developers have access to it.
of course, once that's done we
I personally side with Stas' intentions (if I understand them correctly) on
the matter - it makes it easy for developers to work with both versions of
mod_perl.
I really don't see what the loaded guns are about - each side here deserves
*lot* of credit for pointing out a big problem.
On the on
Issac Goldstand wrote:
[...]
After all, users must set up seperate Apache
distributions for mp 1 and 2. When you think about it, it's really a 2
way relationship: you're "importing the Apache API into Perl", as much
as you're "embedding the Perl interpreter into Apache". Just like you
can't u
On Dec 28, 2004, at 8:17 AM, Stas Bekman wrote:
Why not? I'm not familiar with Module::Build, but doesn't it make
possible to subclass itself? Of course ModPerl::MB is only needed if
there are 3rd party mp2 modules that use M::B. Are there any? May be
David could write a skeleton for a dummy mod
> "Stas" == Stas Bekman <[EMAIL PROTECTED]> writes:
Stas> Unfortunately thanks to Randal, people are now totally confused.
No, I think thanks to me, people are now aware of a problem of
fundamental incompatibility between the "single @INC" historical
legacy of the entire Perl world and toolch
Is it possible to write a program of some sort that can check a module to see
if it may have problems if used with mp2? If a script could grind through a
set of perl directories and "predict" problem areas, then the general
population could move more quickly to mp2. This would also assist i
- Original Message -
From: "Randal L. Schwartz"
To: "Stas Bekman" <[EMAIL PROTECTED]>
Cc: ; "Andreas J Koenig"
<[EMAIL PROTECTED]>; "mod_perl Mailing List"
Sent: Tuesday, December 28, 2004 6:43 PM
Subject: Re: About putting the blame on other shoulders
"Stas" == Stas Bekman <[EMAIL P
> "Issac" == Issac Goldstand <[EMAIL PROTECTED]> writes:
Issac> Which is exactly the point that I was trying to make: This *should* be
Issac> doable. The fact that it's *not* means that Perl is a monolithic
Issac> library and can't have 2 sets of "extensions" in the same site
Issac> installat
- Original Message -
From: "Randal L. Schwartz"
To: "Issac Goldstand" <[EMAIL PROTECTED]>
Cc: ; "Andreas J Koenig"
<[EMAIL PROTECTED]>; "mod_perl Mailing List"
; "Stas Bekman" <[EMAIL PROTECTED]>
Sent: Tuesday, December 28, 2004 7:09 PM
Subject: Re: About putting the blame on other shou
Hello all!
Using apache 1.3.33 with mod_ssl 2.8.22, i want to compile mod_perl
1.29 as a
loadable module.
here is the snippet related to mod_perl installation:
perl Makefile.PL USE_APXS=1 \
WITH_APXS=/usr/local/sbin/apxs \
ENABLE_RULE=EAPI \
E
I am having trouble with Apache::Cookie. I keep getting errors like:
Can't locate object "new" via package "Apache::Cookie"
The code looks like:
sub session {
my $self = shift;
return $self->{_session} if ($self->{_session});
my %cookie = Apache::Cookie->new($self->query)->parse;
On Tuesday 28 December 2004 01:41 pm, Sean Davis wrote:
> I am having trouble with Apache::Cookie. I keep getting errors like:
> Can't locate object "new" via package "Apache::Cookie"
> The code looks like:
Checking the obvious, do you have a "use Apache::Cookie" before:
> sub session {
-
On Tuesday 28 December 2004 11:57 am, Goehring, Chuck, RCI - San Diego wrote:
> Is it possible to write a program of some sort that can check a module to
> see if it may have problems if used with mp2?
Something like Apache::porting?
(http://perl.apache.org/docs/2.0/api/Apache/porting.html)
> If
On Dec 28, 2004, at 1:57 PM, Malcolm J Harwood wrote:
On Tuesday 28 December 2004 01:41 pm, Sean Davis wrote:
I am having trouble with Apache::Cookie. I keep getting errors like:
Can't locate object "new" via package "Apache::Cookie"
The code looks like:
Checking the obvious, do you have a "us
I might have misunderstood , Sorry. I just love mod_perl so much :)
Paul
Andreas J Koenig wrote:
On Tue, 28 Dec 2004 10:54:27 -0500, Stas Bekman <[EMAIL PROTECTED]> said:
> Cure wrote:
>>
Hi all,
I am a new member on this list and after reading the posts from this list in
the last few days, I don't even know if this is the apropriate place for
asking questions about using mod_perl.
If it is not, please tell me if there is another list which could be more
useful for a mod_perl begin
On Dec 28, 2004, at 2:08 PM, Skylos wrote:
Okay, checking another fairly obvious. Do you have libapreq installed?
Skylos
sdavis% perl -MApache::Request -e '0'
sdavis% perl -MApache::Cookie -e '0'
sdavis% perl -MApache::libapreq -e '0'
All execute without errors. Do these need a valid request to b
> On Tue, 28 Dec 2004 10:54:27 -0500, Stas Bekman <[EMAIL PROTECTED]> said:
> Cure wrote:
>> Everybody needs to "STEP BACK" and realize how much work and soul
>> Stas has put into mod_perl.
>> He deserves A LOT OF CREDIT. Keep up the Good work Stas.
Actually, I love Stas. And I'm sure he
Title: Message
Hi,I was hoping that
you could help me. I running Apache 2.0.52/mod_perl
1.99.19/Apache::AuthenNTLM 2.08 on Fedora Core 3 and I'm running into a
problem. In the browser both IE and Firefox
NTLM pass-thru authentication seems to fail and I get prompted for
my username and p
Sean Davis wrote:
On Dec 28, 2004, at 1:57 PM, Malcolm J Harwood wrote:
On Tuesday 28 December 2004 01:41 pm, Sean Davis wrote:
I am having trouble with Apache::Cookie. I keep getting errors like:
Can't locate object "new" via package "Apache::Cookie"
The code looks like:
Checking the obvious
Octavian Rasnita wrote:
Hi all,
I am a new member on this list and after reading the posts from this list in
the last few days, I don't even know if this is the apropriate place for
asking questions about using mod_perl.
If it is not, please tell me if there is another list which could be more
usef
[disconnect this thread from the unrelated noise]
David Wheeler wrote:
> On Dec 28, 2004, at 8:17 AM, Stas Bekman wrote:
>
>> Why not? I'm not familiar with Module::Build, but doesn't it make
>> possible to subclass itself? Of course ModPerl::MB is only needed if
>> there are 3rd party mp2 modules
On Dec 28, 2004, at 12:58 PM, Stas Bekman wrote:
And if we do it the other way around, so you could take
Apache-Filter-HTTPHeadersFixup (the latest is on cpan) add a plain
Build.PL (as if there was no mp2) and then we can add the needed
strings and design ModPerl::MB on the way?
Yes, that should
On Tuesday 28 December 2004 02:21 pm, Octavian Rasnita wrote:
> I am a new member on this list and after reading the posts from this list
> in the last few days, I don't even know if this is the apropriate place for
> asking questions about using mod_perl.
It is. :)
> in preload.pl:
> use Apache
I'm writing a summary of like 300 emails, so we don't have to explain the
issue again and again to each person that joins the threads, or discovers
the problem.
Meanwhile I've found a solution proposed by Andreas 1.5 years ago, which
might work as a better workaround from all the ones proposed
David Wheeler wrote:
On Dec 28, 2004, at 12:58 PM, Stas Bekman wrote:
And if we do it the other way around, so you could take
Apache-Filter-HTTPHeadersFixup (the latest is on cpan) add a plain
Build.PL (as if there was no mp2) and then we can add the needed
strings and design ModPerl::MB on the w
On Dec 28, 2004, at 1:26 PM, Stas Bekman wrote:
it can't be any simpler:
That wasn't the whole script, but I found it on search.cpan.org. Here's
how to get it working with Module::Build right now:
use strict;
use warnings FATAL => 'all';
use Apache2;
use Apache::TestMB;
# prerequisites
my %requir
David Wheeler wrote:
On Dec 28, 2004, at 1:26 PM, Stas Bekman wrote:
it can't be any simpler:
That wasn't the whole script, but I found it on search.cpan.org. Here's
how to get it working with Module::Build right now:
use strict;
use warnings FATAL => 'all';
use Apache2;
>
use Apache::TestMB;
#
what if none exists, should Module::Install be used to require
Module::Build?
that's a tricky one. If ModPerl::MB is added, I suppose a Build.PL writer
should still manually require Module::Build (version) and probably ensure
that it's installed via Module::Install, correct? Then ModPerl::MB co
From: "Malcolm J Harwood" <[EMAIL PROTECTED]>
> [Tue Dec 28 21:07:34 2004] [error] DBD::mysql::db prepare failed: handle 2
> is owned by thread 265c564 not current thread 14ce78c (handles can't be
> shared between threads and your driver may need a CLONE method added) at
> f:/web/presa/modules/Get
On Tuesday 28 December 2004 04:56 pm, Octavian Rasnita wrote:
> Ok, but I have seen an example in a tutorial where the database is accessed
> with the username, and the password from a startup.pl file exactly like
> this:
>
> Apache::DBI->connect_on_init("DBI:mysql:database=presa;host=localhost",
On Dec 28, 2004, at 1:53 PM, Stas Bekman wrote:
'perl' => 6.006,
perl 6? :)
Oops. :-)
why Apache::TestMB? It should be ModPerl::MB when it'll appear, right?
Up to you. I used it as an example because I don't really understand
how Apache::TestMM and ModPerl::MM interact.
why the fall
Malcolm J Harwood wrote:
[...]
This works if you are using the pre-fork MPM (which I understand doesn't work
well under Win32 due to limitations of NT).
It would seem that if you are using the worker MPM then it doesn't make a
connection for each thread, just for the owning process. In which ca
I am running Apache 2.0.52 on a solaris 8 box with mod_perl 1.99_12. Over
the weekend I tried to upgrade to the 1.99_19 version of mod_perl. With
mod_perl 1.99_12 all of the requisite modules reloaded properly when their
contents changed. However, with the 1.99_19 version some modules are not
ge
David Wheeler wrote:
why Apache::TestMB? It should be ModPerl::MB when it'll appear, right?
Up to you. I used it as an example because I don't really understand
how Apache::TestMM and ModPerl::MM interact.
Apache::TestMM is only needed only to add 'make test' and adjust 'make
clean' targets.
w
On Dec 28, 2004, at 2:17 PM, Stas Bekman wrote:
David Wheeler wrote:
why Apache::TestMB? It should be ModPerl::MB when it'll appear,
right?
Up to you. I used it as an example because I don't really understand
how Apache::TestMM and ModPerl::MM interact.
Apache::TestMM is only needed only to add
Vincent Moneymaker wrote:
I am running Apache 2.0.52 on a solaris 8 box with mod_perl 1.99_12. Over
the weekend I tried to upgrade to the 1.99_19 version of mod_perl. With
mod_perl 1.99_12 all of the requisite modules reloaded properly when their
contents changed. However, with the 1.99_19 versi
David Wheeler wrote:
On Dec 28, 2004, at 2:17 PM, Stas Bekman wrote:
David Wheeler wrote:
why Apache::TestMB? It should be ModPerl::MB when it'll appear, right?
Up to you. I used it as an example because I don't really understand
how Apache::TestMM and ModPerl::MM interact.
Apache::TestMM is onl
Realized it just after I hit "send".
Mail is moving rather quickly today...
> -Original Message-
> From: Stas Bekman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 28, 2004 4:48 PM
> To: Barksdale, Ray
> Subject: Re: compile problems
>
> Ray, please followup to the list as a reply
[please don't forget to CC the list in your followups]
Vincent Moneymaker wrote:
sorry, but I've lost you, Vincent. You say that only 1.99_12 works, but
> have you tried other version?. I believe 1.99_16 should work too, please
try:
http://search.cpan.org/~stas/mod_perl-1.99_16/
If 1.99_16 works a
Malcolm,
Thanks, that looks helpful.
Chuck
-Original Message-
From: Malcolm J Harwood [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 28, 2004 11:01 AM
To: modperl@perl.apache.org
Subject: Re: A whole 'nother idea
On Tuesday 28 December 2004 11:57 am, Goehring, Chuck, RCI - San Dieg
Barksdale, Ray wrote:
>>OK, so it has something to do with 64-bit-ness. But I didn't
>>understand.
>>Was this problem seen on a 64-bit CPU or on a 32-bit CPU, but
>>then code
>>was compiled for 64-bit?
>
>
> The problem (more of an observation at this point) was the apparent
> excessive memory usag
On Tue, 28 Dec 2004, Octavian Rasnita wrote:
> Ok, but I have seen an example in a tutorial where the database is accessed
> with the username, and the password from a startup.pl file exactly like
> this:
>
> Apache::DBI->connect_on_init("DBI:mysql:database=presa;host=localhost",
> "ODBC", undef,
> -Original Message-
> From: Stas Bekman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 28, 2004 5:02 PM
> To: Barksdale, Ray
> Cc: modperl@perl.apache.org
> Subject: Re: compile problems
>
> > As far as the memory usage problem I thought I was on to
> the source when
> > I st
> (both without mod_perl) but this resulted in a minimal gain once
> mod_perl was loaded.
How much added in numbers?
Should have said "minimal savings".
From this:
Total: 608169K ( 580M) size, 145465K ( 139M) approx real size (-shared)
down to this:
Total: 600129K ( 572M) size, 131588K (
On Tue, 28 Dec 2004, Randy Kobes wrote:
[ ... ]
> Can you try the
> following patch against Apache::DBI (version 0.94) - if
> you're using ppm on Win32, you can get this from the
> Apache-DBI.ppd package in the
>http://theoryx5.uwinnipeg.ca/ppms/
> repository.
Sorry about this - I missed one
> -Original Message-
> From: Stas Bekman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 28, 2004 5:18 PM
> To: Barksdale, Ray
> Cc: modperl@perl.apache.org
> Subject: Re: compile problems
>
>
> >> > (both without mod_perl) but this resulted in a minimal gain once
> >> > mod_perl
I'd like to put in a request at this point that no one use Module::Build
for any mod_perl-related stuff until it comes with perl. I like Ken's
work on it, and I appreciate how Module::Build makes interactive installs
easier to write, but I don't want to ask people to install another module
in orde
Sean Davis said:
> All execute without errors. Do these need a valid request to be passed
> into new before they work?
Yes, they only work when run under mod_perl.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiqu
Stas Bekman said:
> I'm writing a summary of like 300 emails, so we don't have to explain the
> issue again and again to each person that joins the threads, or discovers
> the problem.
Thank you, that is much appreciated.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info
"Barksdale, Ray" <[EMAIL PROTECTED]> writes:
[...]
>> >>From this:
>> > Total: 608169K ( 580M) size, 145465K ( 139M) approx
>> real size (-shared)
>> >
>> > down to this:
>> > Total: 600129K ( 572M) size, 131588K ( 125M) approx
>> real size (-shared)
Are you sure this isn't just some
Stas Bekman said:
> In fact Perrin gave a perfect counter-example, while looking for an
> example. The fact is C libraries *do not* embed version numbers in their
> API.
Sure they do, when they change the API significantly: SQLite2, Gtk2,
libxml2. Separate API, manpages, headers, etc.
> Perl has
"Perrin Harkins" <[EMAIL PROTECTED]> writes:
> Stas Bekman said:
>> In fact Perrin gave a perfect counter-example, while looking for an
>> example. The fact is C libraries *do not* embed version numbers in their
>> API.
>
> Sure they do, when they change the API significantly: SQLite2, Gtk2,
> lib
If 1.99_16 works and 1.99_17 doesn't that would probably be the change to
blame:
Added ModPerl::Util::unload_package() to remove a loaded package
as thoroughly as possible by clearing it's stash. [Gozer]
Please confirm that first. Next let's take some specific module, put it
in
PerlSetVar ReloadMo
Joe Schaefer said:
>> Sure they do, when they change the API significantly: SQLite2, Gtk2,
>> libxml2. Separate API, manpages, headers, etc.
>
> Not quite. There's a difference between appending a version number
> to library name, and embedding a version number in the function names.
> The former
"Perrin Harkins" <[EMAIL PROTECTED]> writes:
[...]
> Are you saying that using names like "Apache5::" would be a problem
> because of calls to class methods?
Yup, I'm saying version numbers don't belong in the actual
source code (package names, @ISA, whatever), for basically
all the same re
I have tried to install Apache-DBI from TheoryX but ppm gave an error:
Error: no suitable installation target found for package Apache-DBI.
How can I apply that patch manually? Do I need to edit the module
Apache::DBI by hand?
(Under Windows)
Thanks.
Teddy
From: "Randy Kobes" <[EMAIL PROTECTED
64 matches
Mail list logo
