Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <42669458.6020708@stason.org>
Date: Wed, 20 Apr 2005 13:41:44 -0400
From: Stas Bekman <stas@stason.org>
Organization: Hope, Humanized
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050322
MIME-Version: 1.0
To: Geoffrey Young <geoff@modperlcookbook.org>
Cc: mod_perl Dev <dev@perl.apache.org>
Subject: Re: [mp2] new ithreads branch?
References: <42667871.60606@stason.org> <426679AF.3060405@modperlcookbook.org>
 <42668CB5.9060504@stason.org> <42668DC0.7010709@modperlcookbook.org>
In-Reply-To: <42668DC0.7010709@modperlcookbook.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Geoffrey Young wrote:
> 
> Stas Bekman wrote:
> 
>>Geoffrey Young wrote:
>>
>>
>>>Stas Bekman wrote:
>>>
>>>
>>>>I'm working out the details of using the new CLONE_SKIP feature. I was
>>>>thinking that it'd be useful to make a new branch for tha purpose. The
>>>>main problem is that at the moment we can't run the new tests
>>>>conditionally, since there is nothing to condition the support for
>>>>CLONE_SKIP :(
>>>
>>>
>>>
>>>sure, go ahead and create a new branch.  I hope this one merges better,
>>>though ;)
>>
>>
>>Me too :) should we call it 'ithreads'?
>>
>>svn.apache.org/viewcvs.cgi/perl/modperl/branches/ithreads?
> 
> 
> sounds good.  maybe the unstable- prefix like apreq and the rename did is
> also a good

ok

>>I think 5.005_0x is a history now. At least I've noticed that more and
>>more modules on CPAN no longer bother to support it. I've stopped trying
>>to support it in my modules, where it relies on other modules which
>>already don't support it.
> 
> 
> actually, we need T::B 0.49 or greater for things to work, so we probably
> need to bundle it or require it as an external dependency.  IIRC no perl has
> shipped with that version or higher yet.

we have already agreed that we need to bundle it anyway, so we can do even 
a blead version of it.

>>>personally I'm very much in favor of dumping Test.pm if we can make
>>>Test::Builder do what we need.
>>
>>
>>Well, we can't yank Test.pm, because we need special straps under
>>mod_perl. such as 'plan $r, ...'. 
> 
> 
> you can yank Test.pm and still have those straps.  at least I think you can.
>  the current -withtestmore  allows plan() to work properly with $r, for example.

but all the cruft lives in Test.pm, if you yank it how will it work? In 
any case you don't want to break existing modules using it, unless we call 
it Apache-Test-2.0 and then we can change the API.

>>Though we could make Test.pm a proper
>>subclass of Test::More.
> 
> 
> there's already Test::Legacy for that, which might be thing work
> experimenting with and adding our foo to if need be.

Not sure why do we need that. I've meant to make our Apache::Test a 
subclass of Test::More.

In any case, once I have the ithreads-unstable branch of mp2, how do I 
proceed? Do I need to make a separate branch of A-T and then somehow tell 
the ithreads-unstable to use that as externals? Did you by chance document 
the steps you went through when doing the rename branch?


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org