You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Philippe M. Chiasson" <go...@ectoplasm.org> on 2005/01/06 02:50:19 UTC

[ANNOUNCE] mod_perl 1.99_20 (2.0.0-RC3)

mod_perl 1.99_20 (2.0.0-RC3) is out:

http://perl.apache.org/dist/mod_perl-2.0.0-RC3.tar.gz
http://perl.apache.org/dist/mod_perl-2.0.0-RC3.tar.gz.asc (gpg sig)

CPAN:

    file: $CPAN/authors/id/G/GO/GOZER/mod_perl-2.0.0-RC3.tar.gz
    size: 1416964 bytes
     md5: 395897082d4e026effcf0160838989e2
    sha1: 09ca86e46bb8660b0daf64a278123ae234320ae3

Changes since 1.99_19:

the autogenerated modules (and some implemented in xs/ modules) are
now getting the same version number as $mod_perl::VERSION (the
exception are APR modules which get 0.009_000 for now). [Stas]

until we figure out how to tell PAUSE index about versions of the
autogenerated modules, create a fake module which lists all the
autogenerated modules and their versions and include that in the
distro. [Stas]

moving to the triplet version notation, which requires us to bump 1.99
=> 1.999 so 1.999020 (mp2) > 1.29 (mp1). [Stas]
Now we are gong to have:
   $mod_perl::VERSION        : "1.099020"
   int $mod_perl::VERSION    : 1.09902
   $mod_perl::VERSION_TRIPLET: 1.99.20

<Perl> and PerlPostConfigRequires were leaking some memory at
startup. Use parms->temp_pool instead of parms->pool for temporary
memory allocations. [Gozer]

deal with a situation where an object is used to construct another
object, but it's then auto-DESTROYed by perl rendering the object that
used it corrupted. the solution is to make the newly created objects
refer to the underlying object via magic attachment. only objects
using objects that have DESTROY are effected. This concerns some of
the methods accepting the custom APR::Pool object (not native pools
like $r->pool). [Stas]
Adjusted:
- APR::Brigade: new
- APR::Finfo: stat
- APR::IpSubnet: new
- APR::Table: copy, overlay, make
- APR::ThreadMutex: new
- APR::URI: parse
- Apache::RequestUtil: new
- APR::Pool: new
- APR::BucketAlloc: new

APR::Bucket::alloc_create moved  to APR::BucketAlloc::new
APR::Bucket::alloc_destroy moved to APR::BucketAlloc::destroy [Stas]

prefork handlers optimisation: don't dup the handler struct unless
this is a threaded-mpm [Stas]

speed up the 'perl Makefile.PL' stage [Randy Kobes]:
  - reduce the number of calls to build_config() of
    Apache::Build within ModPerl::BuildMM
  - cache the results of the calls to apxs_cflags, apxs_extra_cflags,
    and apxs_extra_cppflags in Apache::Build
  - in apxs of Apache::Build, return a cached result only when defined

move ModPerl::Util::exit() into mod_perl.so, since it needs to work,
even if ModPerl::Util wasn't loaded [Stas]

--------------------------------------------------------------------------------
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

Re: [PATCH] Re: [ANNOUNCE] mod_perl 1.99_20 (2.0.0-RC3)

Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Philippe M. Chiasson wrote:
> 
> 
>>mod_perl 1.99_20 (2.0.0-RC3) is out:
>> 
>>
> 
> All tests OK on WinXP/VC++ with perl-5.8.5 and apache-2.0.50.
> 
> Are the t/perl/ithreads*.t tests going to be reinstated into the distro 
> sometime?  

Not any time soon, I still get random failures on linux.

> The current SVN (rev 124479) still works fine for me with 
> these tests in, although I had to fix another code-before-declaration 
> error when compiling modperl_cmd.c:
> 
> Index: src/modules/perl/modperl_cmd.c
> ===================================================================
> --- src/modules/perl/modperl_cmd.c    (revision 124479)
> +++ src/modules/perl/modperl_cmd.c    (working copy)
> @@ -256,8 +256,8 @@
>  
>      if (APR_SUCCESS == apr_stat(&finfo, arg, APR_FINFO_TYPE, p)) {
>          if (finfo.filetype != APR_NOFILE) {
> +            modperl_require_file_t *require = apr_pcalloc(p, 
> sizeof(*require));
>              MP_TRACE_d(MP_FUNC, "push PerlPostConfigRequire for %s\n", 
> arg);
> -            modperl_require_file_t *require = apr_pcalloc(p, 
> sizeof(*require));
>              require->file = arg;
>              require->dcfg = dcfg;

Thanks applied.

-- 
__________________________________________________________________
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


[PATCH] Re: [ANNOUNCE] mod_perl 1.99_20 (2.0.0-RC3)

Posted by Steve Hay <st...@uk.radan.com>.
Philippe M. Chiasson wrote:

>mod_perl 1.99_20 (2.0.0-RC3) is out:
>  
>
All tests OK on WinXP/VC++ with perl-5.8.5 and apache-2.0.50.

Are the t/perl/ithreads*.t tests going to be reinstated into the distro 
sometime?  The current SVN (rev 124479) still works fine for me with 
these tests in, although I had to fix another code-before-declaration 
error when compiling modperl_cmd.c:

Index: src/modules/perl/modperl_cmd.c
===================================================================
--- src/modules/perl/modperl_cmd.c    (revision 124479)
+++ src/modules/perl/modperl_cmd.c    (working copy)
@@ -256,8 +256,8 @@
 
     if (APR_SUCCESS == apr_stat(&finfo, arg, APR_FINFO_TYPE, p)) {
         if (finfo.filetype != APR_NOFILE) {
+            modperl_require_file_t *require = apr_pcalloc(p, 
sizeof(*require));
             MP_TRACE_d(MP_FUNC, "push PerlPostConfigRequire for %s\n", 
arg);
-            modperl_require_file_t *require = apr_pcalloc(p, 
sizeof(*require));
             require->file = arg;
             require->dcfg = dcfg;
            

>Changes since 1.99_19:
>
>[...]
>speed up the 'perl Makefile.PL' stage [Randy Kobes]:
>
Kudos to Randy for this one!  It seems to make quite a big difference on 
my setup.

- Steve


------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


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