Re: [MP2] possible pnotes bug?

2006-03-16 Thread Torsten Foertsch
On Thursday 16 March 2006 00:39, Geoffrey Young wrote:
> >>>in order for $o to maintain it's internal state.  is that right?  if so,
> >>> I don't like that very much.
> >
> > It's not right. You are confusing scalars with references in that
> > example.
>
> ook, my bad - I thought the proposed "solution" was to always dereference
> pnotes behind the scenes, making the additional storage a requirement.
>
> but, just in case I'm not the only one confused, I'd propose a path like
> this...
>
>   o create some (many?) additional pnotes tests that exercise the different
> ways we think people will be using pnotes in almost all normal
> circumstances we can think of.  digging through CPAN might be a good idea.
>
>   o offer that any fix shouldn't break the tests

Here are some tests that cover your concerns so far:

package TestPn::pn;

use strict;
use warnings FATAL => 'all';

use Apache::Test;
use Apache::TestUtil;
use Apache2::RequestUtil;
use Apache2::Const -compile => 'OK';

{
package _O;
sub new {bless {}=>__PACKAGE__}
sub member {$_[0]->{x}=$_[1] if @_>1; $_[0]->{x}}
}

sub handler {
my $r = shift;

Apache::Test::test_pm_refresh();
plan $r, tests => 20;

my $x;

# pnotes as hash ref

# this 1st set of tests are all ok, because $r->pnotes returns a normal
# hash ref

$x=1;
$r->pnotes->{x}=$x;
$x++;
ok t_cmp $r->pnotes('x'), 1, q{hash ref1};
ok t_cmp $r->pnotes->{x}, 1, q{hash ref2};
delete $r->pnotes->{x};

# pnotes method interface

# these two fail

$x=1;
$r->pnotes(x=>$x);
$x++;
ok t_cmp $r->pnotes('x'), 1, q{method1};
ok t_cmp $r->pnotes->{x}, 1, q{method2};
delete $r->pnotes->{x};

# pnotes as hash: storing and retrieving objects

my $o1=_O->new;
$o1->member(1);
my $o2=_O->new;
$o2->member(2);

# check if the objects work properly

ok t_cmp $o1->member, 1, q{o1 setup};
ok t_cmp $o2->member, 2, q{o2 setup};

# these tests succeed. they show normal object behavior.

$r->pnotes->{o}=$o1;
$o1->member(10);
ok t_cmp $r->pnotes('o')->member, 10, q{hash ref obj 1};
ok t_cmp $r->pnotes->{o}->member, 10, q{hash ref obj 2};

$r->pnotes('o')->member(100);
ok t_cmp $r->pnotes('o')->member, 100, q{hash ref obj 3};
ok t_cmp $r->pnotes->{o}->member, 100, q{hash ref obj 4};

# the following two succeed only because the hash ref interface
# was used to assing $r->pnotes->{o}.

$o1=$o2;
ok t_cmp $r->pnotes('o')->member, 100, q{hash ref obj 5};
ok t_cmp $r->pnotes->{o}->member, 100, q{hash ref obj 6};
delete $r->pnotes->{o};

# pnotes method interface: storing and retrieving objects

$o1=_O->new;
$o1->member(1);
$o2=_O->new;
$o2->member(2);

ok t_cmp $o1->member, 1, q{o1 setup};
ok t_cmp $o2->member, 2, q{o2 setup};

$r->pnotes(o=>$o1);
$o1->member(10);
ok t_cmp $r->pnotes('o')->member, 10, q{method obj 1};
ok t_cmp $r->pnotes->{o}->member, 10, q{method obj 2};

$r->pnotes('o')->member(100);
ok t_cmp $r->pnotes('o')->member, 100, q{method obj 3};
ok t_cmp $r->pnotes->{o}->member, 100, q{method obj 4};

# these two fail, because the assignment $o1=$o2 modifies $r->pnotes->{o}.

$o1=$o2;
ok t_cmp $r->pnotes('o')->member, 100, q{method obj 5};
ok t_cmp $r->pnotes->{o}->member, 100, q{method obj 6};
delete $r->pnotes->{o};

Apache2::Const::OK;
}

1;


The patch is IMO really simple:

In xs/Apache2/ConnectionUtil/Apache2__ConnectionUtil.h and
xs/Apache2/RequestUtil/Apache2__RequestUtil.h

 if (val) {
 retval = *hv_store(ccfg->pnotes, k, len,
-   SvREFCNT_inc(val), 0);
+   newSVsv(val), 0);
 }
 else if (hv_exists(ccfg->pnotes, k, len)) {
 retval = *hv_fetch(ccfg->pnotes, k, len, FALSE);


The attached patch was made a few days ago. It applies to r384596 with the
connection-pnotes patch applied before. All tests succeed.

Torsten
diff -Naur r384596-cnotes/t/modperl/pnotes.t pnotes/t/modperl/pnotes.t
--- r384596-cnotes/t/modperl/pnotes.t	2006-03-10 21:23:28.465092006 +0100
+++ pnotes/t/modperl/pnotes.t	2006-03-10 21:32:55.647505579 +0100
@@ -10,7 +10,7 @@
 
 t_debug("connecting to $url");
 
-plan tests => (22 * 3);
+plan tests => (24 * 3);
 
 # first with keepalives
 Apache::TestRequest::user_agent(reset => 1, keep_alive => 1);
diff -Naur r384596-cnotes/t/response/TestModperl/pnotes.pm pnotes/t/response/TestModperl/pnotes.pm
--- r384596-cnotes/t/response/TestModperl/pnotes.pm	2006-03-10 21:23:28.462092410 +0100
+++ pnotes/t/response/TestModperl/pnotes.pm	2006-03-10 21:33:07.117987774 +0100
@@ -17,8 +17,8 @@
 
 # make it ok to call ok() here while plan()ing elsewhere
 Apache::Test::init_test_pm($r);
-$Test::ntest   = 1 + (22 * ($r->args - 1));
-$Test::planned = 22;
+$Test::ntest   = 1 + (24 * ($r->args - 1));
+$Test::planned = 24;
 
 my $c 

Re: add_config test

2006-03-16 Thread Philippe M. Chiasson
Randy Kobes wrote:
> On Sat, 11 Mar 2006, Randy Kobes wrote:
> 
> 
>>The t/TestAPI/add_config test fails for me on Win32
>>because the current way of getting the directory in
>>on line 58 of add_config.pm produces an invalid directory
>>name on Windows due the the presence of the drive letter.
>>This diff:
> 
> [ ... ]
> 
>>fixes it for me.
> 
> That diff does fix the problem for me when the test is 
> run once, but in using SMOKE to track down failures
> in perl/ithreads*.t when the full test sequence is run, I 
> found this sequence:
> 
> C:\svn\mp2>perl t/TEST t\api\add_config.t  \
>   t\api\lookup_misc.t t\api\aplog.t   \
>   t\api\internal_redirect.t t\api\add_config.t
> 
> produces a failure when the 2nd t\api\add_config.t is run.
> The message is
> t\api\add_config...# connecting to
>  http://localhost:8561/TestAPI__add_config/
>  request has failed (the response code was: 500)
> but nothing appears in the error log related to this.
> 
> I tried this sequence on linux (prefork), but it was OK.

I've reproduced this on Linux (worker) with

t/TEST t/api/add_config.t t/api/add_config.t

Basically, add_config.t can't be run multiple times, and that needs to be
fixed.


Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5


signature.asc
Description: OpenPGP digital signature


Re: svn commit: r386498 - in /perl/modperl/trunk: Changes lib/ModPerl/BuildMM.pm xs/APR/APR/Makefile.PL

2006-03-16 Thread Stas Bekman

[EMAIL PROTECTED] wrote:

Author: stas
Date: Thu Mar 16 16:40:43 2006
New Revision: 386498

URL: http://svn.apache.org/viewcvs?rev=386498&view=rev
Log:
Make sure that LIBS and other MakeMaker command line flags are not
ignored by the top level Makefile.PL and xs/APR/APR/Makefile.PL


Folks, please test it with the usual setups. Mike Smith was trying to 
build a 64bit mp2 build, just to discover that we are ignoring any 
external arguments like LIBS. So this is why I've applied this fix. We 
have tested only LIBS, hopefully I caught the others, but I haven't tested 
them.


We now have a Linux and Solaris 9 64bit builds of mod_perl - builds and 
works just fine :)


p.s. for the curious and for the archives:

we needed to build 64bit on Solaris, because the 32bit binaries have a 
hardcoded limitation of 256 file descriptors per process (stdio lib), 
which the 64bits version doesn't have. e.g. you can't run this program on 
32bit perl:


% ulimit -n 1000
% ulimit -n
1000
% perl -le 'use Symbol; my $max = shift; for (1..$max) { $fh{$_} = gensym; 
open $fh{$_}, ">/tmp/aaa" or die "$!"}' 512

Too many open files at -e line 1.

Thanks to Alan Burlison for telling us how to fix that (building 64bit 
perl and the rest).


--
_
Stas Bekman mailto:[EMAIL PROTECTED]  http://stason.org/
MailChannels: Assured Messaging(TM) http://mailchannels.com/
The "Practical mod_perl" book   http://modperlbook.org/
http://perl.apache.org/ http://perl.org/ http://logilune.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]