Stas Bekman wrote:
yes, please submit a verbose run's output only for:
t/TEST -v t/apr-ext/uuid.t
It's not finding perlloadmodule5.pm, but the file exists :
/data/src/modperl-2.0/t/response/TestDirective/perlloadmodule5.pm
Looks like a syntax error in httpd.conf, the line :
1670: PerlLoadModu
Geoffrey Young wrote:
What do you mean it has no clear utility, you've just heard John
complaining on the users list that 'apachectl configtest' wasn't
invoking mod_perl setup. Unless you think that suggesting to use the
section hack is the best we can come up with.
actually, I think that his ex
> What do you mean it has no clear utility, you've just heard John
> complaining on the users list that 'apachectl configtest' wasn't
> invoking mod_perl setup. Unless you think that suggesting to use the
> section hack is the best we can come up with.
actually, I think that his expectations are
Geoffrey Young wrote:
[...]
Meaning that you need
to document that one needs to do:
PerlLoadModule Foo
which is just as well, could be documented as:
PerlStartNow
PerlModule Foo
especially if we are going to add PerlStartNow anyway (are we?).
well, something about that strikes me as dangerou
> That's exactly what will happen if a user will use PerlModule instead of
> PerlLoadModule at the moment. It'll silently fail.
yes. but in some circumstances the failure might not be silent - directive
handlers would fail because httpd would croak, for example. but you're
right, there is a dan
Geoffrey Young wrote:
In which case why having two directives, if they do the same thing? Drop
PerlLoadModule completely and have a new directive that will start the
interpreter on demand, add the new API to Apache::Module. Won't that
solve the problem?
not really. the issue that started this d
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>> continuing from modperl@
>>
>>
>>> In this thread you were trying to make
>>> PerlLoadModule do what it wasn't designed for.
>>
>>
>>
>> that's an oversimplification and somewhat belittling.
>>
>> PerlLoadModule does a few things:
>>
>> - starts
Philippe M. Chiasson wrote:
It's been a long awaited feature, to bring back something similar to the old
mod_perl option to have mod_perl statically linked to httpd. Here is my attempt
at it.
You rock, this looks so simple :)
The original way I attempted this was to hook into the new httpd build s
Geoffrey Young wrote:
continuing from modperl@
In this thread you were trying to make
PerlLoadModule do what it wasn't designed for.
that's an oversimplification and somewhat belittling.
PerlLoadModule does a few things:
- starts up an interpreter
That's a side effect, not the design goal.
Geoffrey Young wrote:
But ideally I'd just have this simple API:
my $buf = $sock->recv($len);
my $wrote = $sock->send($buf);
since modifying the variable that you pass to the function is going to
be very confusing to many users. We code in perl, not C.
yeah, I think this is better. I fluxua
>>Stas came up with a workaround solution for mp2, but it didn't get
>>applied because we figured that the problem will go away from 2.0.50
>>onwards anyway.
>
>
> Thanks, Steve - I'd forgotten that that patch didn't make it
> into 2.0.49.
yeah, bill had forgotten about it, but it was the first
> But ideally I'd just have this simple API:
>
> my $buf = $sock->recv($len);
> my $wrote = $sock->send($buf);
>
> since modifying the variable that you pass to the function is going to
> be very confusing to many users. We code in perl, not C.
yeah, I think this is better. I fluxuate be
Philippe M. Chiasson wrote:
> It's been a long awaited feature, to bring back something similar to the old
> mod_perl option to have mod_perl statically linked to httpd. Here is my attempt
> at it.
whee!
> There is currently one bug with mod_perl compiled statically. It tries to add
> the MODPE
It's been a long awaited feature, to bring back something similar to the old
mod_perl option to have mod_perl statically linked to httpd. Here is my attempt
at it.
The original way I attempted this was to hook into the new httpd build system,
but, one issue about that is that it would require auto
Dorothy
Would you refinance if you knew it
could save you several thousand dollars?
Refinance today to as low as 2.95%!
or buy the home of your dreams!
http://www.expeditemortgage.net/?num5
Thanks Stefanie Padilla
No http://www.expeditemortgage.net/100/
piotr cabin
continuing from modperl@
> In this thread you were trying to make
> PerlLoadModule do what it wasn't designed for.
that's an oversimplification and somewhat belittling.
PerlLoadModule does a few things:
- starts up an interpreter
- requires a module, thus running module init code
- insert
Didn't quite do the trick: $error needs to be chomp()'ed like $val
itself was a line or two earlier, otherwise $error contains a newline
and evaluates as "true". This fixes it for me:
Excellent, Steve, committed.
__
Stas Bekman
Stas Bekman wrote:
>Randy Kobes wrote:
>
>
>>But the port of apxs that I did does have an EXTRA_CPPFLAGS,
>>it's just that
>> apxs -q EXTRA_CPPFLAGS
>>returns nothing. That's to be compared to, eg,
>> apxs -q FOO_BAR
>>which gives an apxs error.
>>
>>
>
>Yes, sorry Randy, you are right,
On Monday 26 April 2004 04:17 am, Geoffrey Young wrote:
> CCing to the dev list :)
>
> Beau E. Cox wrote:
> > On Monday 26 April 2004 03:43 am, you wrote:
> >>Beau E. Cox wrote:
> >>>Hi -
> >>>
> >>>It looks like 2.1 is going through a big update tonight,
> >>>and the cvs sources are unstable.
> >>
can you submit a bug-report for this?
I think the echo & str_con test failures are known problems.
(they have to do with non-blocking/blocking sockets, and what state
they are open in)
the uuid.t one is a new one.
http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
regards
Ia
I had some issues when I ran a 'make test' on the
t/filter/both_str_con_add test..
it caused the httpd process to grow to 1.7g of memory when I ran it.
I'm rebuilding mod-perl (after a make clean) and hoping it goes away.
--I
On 27/04/2004, at 12:01 PM, Carl Brewer wrote:
Stas Bekman wrote:
> Car
I'm thinking to make recv/send perlish, similar to read()/print()
my $read = $sock->recv($buf, $len);
my $wrote = $sock->send($buf, $len);
the only difference will be that we will croak on error. I know I'm going to
break someone's code but better early than later.
But ideally I'd just have
Stas Bekman wrote:
[...]
are known and Joe promised to take care of them, at least on Solaris:
but not that one:
t/protocol/echo_block.t
I just added it a day before. So it's a new one. But probably related to
blocking (bugs?) in Apache 2.0.49.
Actually, no, echo_timeout is the new one. t/pro
23 matches
Mail list logo
