Re: [mp1] 1.28 release candidate #2
Maybe for 1.29 we could even talk about deprecating/removing Apache::StatINC alltogether, for example. I expect there would be some objections to removing Apache::StatINC altogether (at least for while yet). Deprecating it is certainly a good idea once the "UndefOnReload" option is added to Apache::Reload; until then, some may actually prefer Apache::StatINC. definitely -1 on removal. it doesn't take much place. it's already not in 2.0, so there is no issues with it really. What would be really nice if someone will update http://perl.apache.org/docs/1.0/guide/ to replace any references to StatINC with Reload and also mention the new features it has added. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp1] 1.28 release candidate #2
On Wed, 2003-06-25 at 16:32, Steve Hay wrote:
> Hi Philippe,
>
> Philippe M. Chiasson wrote:
>
> >On Wed, 2003-06-25 at 00:12, Steve Hay wrote:
> >
> >
> >>Philippe M. Chiasson wrote:
> >>[...]
> >>
> >>
> >>>If you feel like submitting a back-port of Apache::Reload (with or
> >>>without my new namespace deletion code), that has a few decents tests
> >>>for it and works with perl 5.5.3 up to bleadperl, I would be happy to
> >>>slip it into mp 1.28 with a version of 1.0_0 or similar to make sure
> >>>CPAN won't be fooled into installing it for now. Just noticed there is
> >>>Apache::Reload 0.07 on CPAN, so it would be safe.
> >>>
> >>>
> >>>
> >>The last patch that I submitted
> >>(http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=105595499417788&w=2)
> >>almost fits the bill -- just remove the "if (MOD_PERL2)" stuff at the
> >>top for a mp1-only version.
> >>
> >>However, that uses the B module, which is only available from 5.005_03
> >>up. That's all that you're asking for above, but when I previously
> >>pointed out that the current mp1 Makefile.PL specifies 5.003_97 up (in
> >>general, different on Win32/cygwin), you said that you didn't want to
> >>have to up the minimum requirement to 5.005_03.
> >>
> >>I also currently have no idea how to write tests for Apache modules and
> >>I'm unlikely to learn in the next couple of days, so unless you're happy
> >>with a 5.005_03 requirement for Apache::Reload and either don't mind
> >>having no tests or else can write some yourself then it looks like I'll
> >>have to wait until 1.29.
> >>
> >>
> >
> >Here is what I think I am going to do in light of all this and a high
> >level of cafeeine...
> >
> >Take Apache::Reload from mp2 as-is (it's 0.9), and mod_perl1-ify it.
> >
> >Dump it in mod_perl 1
> >
> >Change it's version number to 0.8_1 so CPAN won't pick it up.
> >
> >Release 1.28 (eventually...)
> >
> >Then work on the added functionnality for Apache::Reload and solve all
> >other issues of dependencies on B, ModPerl::Util::symbol_undef_code,
> >etc.
> >
> Good idea! We've had so many ideas flying around about how to implement
> the new "UndefOnReload" feature and where to put the code that I'd
> completely forgotten that there is an existing module that already works
> (without that feature)! Getting that into mp1 as a first step is an
> excellent move.
So I'll do exactly that !
> >
> >I don't want this issue to slow down the long-awaited release of 1.28.
> >But at the same time , StatINC is quite old and users of mp1 should be
> >'motivated' to upgrade to Apache::Reload, so it makes sense to go in mp1
> >as well.
> >
> >Maybe for 1.29 we could even talk about deprecating/removing
> >Apache::StatINC alltogether, for example.
> >
> I expect there would be some objections to removing Apache::StatINC
> altogether (at least for while yet). Deprecating it is certainly a good
> idea once the "UndefOnReload" option is added to Apache::Reload; until
> then, some may actually prefer Apache::StatINC.
I am aware of that. I was pointing a possibility I would consider if I
were to be RM for 1.29 ;-)
> Steve
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
Re: [mp1] 1.28 release candidate #2
Hi Philippe, Philippe M. Chiasson wrote: On Wed, 2003-06-25 at 00:12, Steve Hay wrote: Philippe M. Chiasson wrote: [...] If you feel like submitting a back-port of Apache::Reload (with or without my new namespace deletion code), that has a few decents tests for it and works with perl 5.5.3 up to bleadperl, I would be happy to slip it into mp 1.28 with a version of 1.0_0 or similar to make sure CPAN won't be fooled into installing it for now. Just noticed there is Apache::Reload 0.07 on CPAN, so it would be safe. The last patch that I submitted (http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=105595499417788&w=2) almost fits the bill -- just remove the "if (MOD_PERL2)" stuff at the top for a mp1-only version. However, that uses the B module, which is only available from 5.005_03 up. That's all that you're asking for above, but when I previously pointed out that the current mp1 Makefile.PL specifies 5.003_97 up (in general, different on Win32/cygwin), you said that you didn't want to have to up the minimum requirement to 5.005_03. I also currently have no idea how to write tests for Apache modules and I'm unlikely to learn in the next couple of days, so unless you're happy with a 5.005_03 requirement for Apache::Reload and either don't mind having no tests or else can write some yourself then it looks like I'll have to wait until 1.29. Here is what I think I am going to do in light of all this and a high level of cafeeine... Take Apache::Reload from mp2 as-is (it's 0.9), and mod_perl1-ify it. Dump it in mod_perl 1 Change it's version number to 0.8_1 so CPAN won't pick it up. Release 1.28 (eventually...) Then work on the added functionnality for Apache::Reload and solve all other issues of dependencies on B, ModPerl::Util::symbol_undef_code, etc. Good idea! We've had so many ideas flying around about how to implement the new "UndefOnReload" feature and where to put the code that I'd completely forgotten that there is an existing module that already works (without that feature)! Getting that into mp1 as a first step is an excellent move. I don't want this issue to slow down the long-awaited release of 1.28. But at the same time , StatINC is quite old and users of mp1 should be 'motivated' to upgrade to Apache::Reload, so it makes sense to go in mp1 as well. Maybe for 1.29 we could even talk about deprecating/removing Apache::StatINC alltogether, for example. I expect there would be some objections to removing Apache::StatINC altogether (at least for while yet). Deprecating it is certainly a good idea once the "UndefOnReload" option is added to Apache::Reload; until then, some may actually prefer Apache::StatINC. Steve
Re: [mp1] 1.28 release candidate #2
On Wed, 2003-06-25 at 00:12, Steve Hay wrote:
> Philippe M. Chiasson wrote:
> [...]
> >If you feel like submitting a back-port of Apache::Reload (with or
> >without my new namespace deletion code), that has a few decents tests
> >for it and works with perl 5.5.3 up to bleadperl, I would be happy to
> >slip it into mp 1.28 with a version of 1.0_0 or similar to make sure
> >CPAN won't be fooled into installing it for now. Just noticed there is
> >Apache::Reload 0.07 on CPAN, so it would be safe.
> >
> The last patch that I submitted
> (http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=105595499417788&w=2)
> almost fits the bill -- just remove the "if (MOD_PERL2)" stuff at the
> top for a mp1-only version.
>
> However, that uses the B module, which is only available from 5.005_03
> up. That's all that you're asking for above, but when I previously
> pointed out that the current mp1 Makefile.PL specifies 5.003_97 up (in
> general, different on Win32/cygwin), you said that you didn't want to
> have to up the minimum requirement to 5.005_03.
>
> I also currently have no idea how to write tests for Apache modules and
> I'm unlikely to learn in the next couple of days, so unless you're happy
> with a 5.005_03 requirement for Apache::Reload and either don't mind
> having no tests or else can write some yourself then it looks like I'll
> have to wait until 1.29.
Here is what I think I am going to do in light of all this and a high
level of cafeeine...
Take Apache::Reload from mp2 as-is (it's 0.9), and mod_perl1-ify it.
Dump it in mod_perl 1
Change it's version number to 0.8_1 so CPAN won't pick it up.
Release 1.28 (eventually...)
Then work on the added functionnality for Apache::Reload and solve all
other issues of dependencies on B, ModPerl::Util::symbol_undef_code,
etc.
I don't want this issue to slow down the long-awaited release of 1.28.
But at the same time , StatINC is quite old and users of mp1 should be
'motivated' to upgrade to Apache::Reload, so it makes sense to go in mp1
as well.
Maybe for 1.29 we could even talk about deprecating/removing
Apache::StatINC alltogether, for example.
> Steve
>
> >
> >I guess for now the simplest thing would be to _strictly_ backwards port
> >Apache::Reload with no mp2 specific code in there, just so it can be
> >shipped in 1.28, then in the 1.29-dev cycle, I can worry about getting
> >it either on CPAN or synced between both mp1 and mp2, as per the ongoign
> >discussion with you and Stas on the matter.
> >
> >So, if you feel you can whip up a complete patch within the next few
> >days, go for it. Otherwise, I'll delay this for inclusion in 1.29 (and
> >remember, I would target that one quite soon after 1.28)
> >
> >Gozer out.
> >
> >
> >
> >
> >>Steve
> >>
> >>
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
Re: [mp1] 1.28 release candidate #2
Hi Randy, Randy Kobes wrote: On Tue, 24 Jun 2003, Steve Hay wrote: Philippe M. Chiasson wrote: On Tue, 2003-06-24 at 23:00, Steve Hay wrote: Philippe M. Chiasson wrote: Now bringing you the second mod_perl 1.28 release candidate. [snip] Windows XP, Apache 1.3.27, Perl 5.8.0: Failed Test Stat Wstat Total Fail Failed List of Failed --- modules/request.t 106 60.00% 3-8 Is it possible that you have an older version of Apache::Request lying around that was not recompiled against this new mod_perl ? (hapenned to me more than once) I did initially have libapreq-1.1 compiled against mp-1.27. I've now tried 1.2 compiled against the new mod_perl, and I still get the same result. (I have Apache-Test 1.03 in place, if that's at all relevant.) Did the libapreq-1.2 tests pass? Yes -- all successful. Also, what's your 'perl -V'? mod_perl 1 with ActivePerl 8xx (based on perl-5.8) doesn't build, due to the addition of LARGE_FILES support, so you must have disabled that. Yes, you're right - I've built Perl myself using ActivePerl 806 sources, and I've disabled USE_LARGE_FILES (and also USE_MULTI, USE_ITHREADS and USE_IMP_SYS, and I've enabled PERL_MALLOC and PERL_DEBUGGING_MSTATS). Here's my perl -V: Summary of my perl5 (revision 5 version 8 subversion 0) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-perlio uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=y, bincompat5005=undef Compiler: cc='cl', ccflags ='-nologo -Gf -W3 -MD -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_DEBUGGING_MSTATS -DUSE_PERLIO -DPERL_MSVCRT_READFIX', optimize='-MD -DNDEBUG -O1', cppflags='-DWIN32' ccversion='', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -release -libpath:"C:\perl5\lib\CORE" -machine:x86' libpth=C:\PROGRA~1\MICROS~2\VC98\lib C:\openssl\lib libs=libeay32.lib oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib perllibs=libeay32.lib oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib gnulibc_version='undef' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release -libpath:"C:\perl5\lib\CORE" -machine:x86' Characteristics of this binary (from libperl): Compile-time options: Built under MSWin32 Compiled at May 1 2003 14:48:19 @INC: C:/perl5/lib C:/perl5/site/lib .
Re: [mp1] 1.28 release candidate #2
On Tue, 24 Jun 2003, Steve Hay wrote: > Philippe M. Chiasson wrote: > > >On Tue, 2003-06-24 at 23:00, Steve Hay wrote: > > > >>Philippe M. Chiasson wrote: > >> > >>>Now bringing you the second mod_perl 1.28 release candidate. > >>>[snip] > >>Windows XP, Apache 1.3.27, Perl 5.8.0: > >> > >>Failed Test Stat Wstat Total Fail Failed List of Failed > >>--- > >>modules/request.t 106 60.00% 3-8 > > > >Is it possible that you have an older version of > >Apache::Request lying around that was not recompiled against > >this new mod_perl ? (hapenned to me more than once) > > > I did initially have libapreq-1.1 compiled against mp-1.27. > I've now tried 1.2 compiled against the new mod_perl, and I > still get the same result. (I have Apache-Test 1.03 in place, > if that's at all relevant.) Did the libapreq-1.2 tests pass? Also, what's your 'perl -V'? mod_perl 1 with ActivePerl 8xx (based on perl-5.8) doesn't build, due to the addition of LARGE_FILES support, so you must have disabled that. -- best regards, randy kobes
Re: [mp1] 1.28 release candidate #2
Philippe M. Chiasson wrote: On Tue, 2003-06-24 at 23:00, Steve Hay wrote: Philippe M. Chiasson wrote: Now bringing you the second mod_perl 1.28 release candidate. [snip] Please give this release a spin and report back any problems or failed tests to: [EMAIL PROTECTED] as soon as possible. The more platforms & configurations, the merrier! Windows XP, Apache 1.3.27, Perl 5.8.0: Failed Test Stat Wstat Total Fail Failed List of Failed --- modules/request.t 106 60.00% 3-8 Is it possible that you have an older version of Apache::Request lying around that was not recompiled against this new mod_perl ? (hapenned to me more than once) I did initially have libapreq-1.1 compiled against mp-1.27. I've now tried 1.2 compiled against the new mod_perl, and I still get the same result. (I have Apache-Test 1.03 in place, if that's at all relevant.) What's in the error_log? Loads of stuff -- I've attached it (gzipped). Philippe: Is the Apache::Reload stuff not going to make it into 1.28? I think it would be well worth waiting a little longer for 1.28 if that could make it in. Well, maybe, maybe not. In any case, I am planning to go at a mp 1.29 release fairly soon after 1.28 hits the decks. There are still quite a few itty-gritty bugs I want to hammer out of mod_perl 1, but that are yet a bit too touchy to roll up in a release without letting the CVS user some time to see it work/break for them. If you feel like submitting a back-port of Apache::Reload (with or without my new namespace deletion code), that has a few decents tests for it and works with perl 5.5.3 up to bleadperl, I would be happy to slip it into mp 1.28 with a version of 1.0_0 or similar to make sure CPAN won't be fooled into installing it for now. Just noticed there is Apache::Reload 0.07 on CPAN, so it would be safe. The last patch that I submitted (http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=105595499417788&w=2) almost fits the bill -- just remove the "if (MOD_PERL2)" stuff at the top for a mp1-only version. However, that uses the B module, which is only available from 5.005_03 up. That's all that you're asking for above, but when I previously pointed out that the current mp1 Makefile.PL specifies 5.003_97 up (in general, different on Win32/cygwin), you said that you didn't want to have to up the minimum requirement to 5.005_03. I also currently have no idea how to write tests for Apache modules and I'm unlikely to learn in the next couple of days, so unless you're happy with a 5.005_03 requirement for Apache::Reload and either don't mind having no tests or else can write some yourself then it looks like I'll have to wait until 1.29. Steve I guess for now the simplest thing would be to _strictly_ backwards port Apache::Reload with no mp2 specific code in there, just so it can be shipped in 1.28, then in the 1.29-dev cycle, I can worry about getting it either on CPAN or synced between both mp1 and mp2, as per the ongoign discussion with you and Stas on the matter. So, if you feel you can whip up a complete patch within the next few days, go for it. Otherwise, I'll delay this for inclusion in 1.29 (and remember, I would target that one quite soon after 1.28) Gozer out. Steve mod_perl_error_log.gz Description: GNU Zip compressed data
Re: [mp1] 1.28 release candidate #2
Steve Hay <[EMAIL PROTECTED]> writes: [...] > Windows XP, Apache 1.3.27, Perl 5.8.0: > > Failed Test Stat Wstat Total Fail Failed List of Failed > --- > modules/request.t 106 60.00% 3-8 I think tests 3-8 are the old Apache::test upload tests for Apache::Request (they do pass on RH 8). Does t/logs/error_log say anything interesting? Also, what version of libapreq are you using? -- Joe Schaefer
Re: [mp1] 1.28 release candidate #2
On Tue, 2003-06-24 at 23:00, Steve Hay wrote:
> Philippe M. Chiasson wrote:
>
> >Now bringing you the second mod_perl 1.28 release candidate.
> >[snip]
> >Please give this release a spin and report back any problems or failed tests to:
> >[EMAIL PROTECTED] as soon as possible. The more platforms & configurations, the
> >merrier!
> >
> Windows XP, Apache 1.3.27, Perl 5.8.0:
>
> Failed Test Stat Wstat Total Fail Failed List of Failed
> ---
> modules/request.t 106 60.00% 3-8
Is it possible that you have an older version of Apache::Request lying
around that was not recompiled against this new mod_perl ? (hapenned to
me more than once)
What's in the error_log?
> Philippe: Is the Apache::Reload stuff not going to make it into 1.28? I
> think it would be well worth waiting a little longer for 1.28 if that
> could make it in.
Well, maybe, maybe not. In any case, I am planning to go at a mp 1.29
release fairly soon after 1.28 hits the decks. There are still quite a
few itty-gritty bugs I want to hammer out of mod_perl 1, but that are
yet a bit too touchy to roll up in a release without letting the CVS
user some time to see it work/break for them.
If you feel like submitting a back-port of Apache::Reload (with or
without my new namespace deletion code), that has a few decents tests
for it and works with perl 5.5.3 up to bleadperl, I would be happy to
slip it into mp 1.28 with a version of 1.0_0 or similar to make sure
CPAN won't be fooled into installing it for now. Just noticed there is
Apache::Reload 0.07 on CPAN, so it would be safe.
I guess for now the simplest thing would be to _strictly_ backwards port
Apache::Reload with no mp2 specific code in there, just so it can be
shipped in 1.28, then in the 1.29-dev cycle, I can worry about getting
it either on CPAN or synced between both mp1 and mp2, as per the ongoign
discussion with you and Stas on the matter.
So, if you feel you can whip up a complete patch within the next few
days, go for it. Otherwise, I'll delay this for inclusion in 1.29 (and
remember, I would target that one quite soon after 1.28)
Gozer out.
> Steve
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
Re: [mp1] 1.28 release candidate #2
Philippe M. Chiasson wrote: Now bringing you the second mod_perl 1.28 release candidate. [snip] Please give this release a spin and report back any problems or failed tests to: [EMAIL PROTECTED] as soon as possible. The more platforms & configurations, the merrier! Windows XP, Apache 1.3.27, Perl 5.8.0: Failed Test Stat Wstat Total Fail Failed List of Failed --- modules/request.t 106 60.00% 3-8 Philippe: Is the Apache::Reload stuff not going to make it into 1.28? I think it would be well worth waiting a little longer for 1.28 if that could make it in. Steve
[mp1] 1.28 release candidate #2
Now bringing you the second mod_perl 1.28 release candidate. It can be
downloaded here:
http://www.apache.org/~gozer/mp1/mod_perl-1.27_01-dev-rc2.tar.gz
MD5 : 90e339d8d8131df518e7ecb66a45693d
SHA1 : eeafa156777623326edc056aad6940abf698e785
What has changed since RC #1 :
+ Add Mac OS X support to Apache::SizeLimit
+ Apache::FakeRequest now isa Apache so code that is careful about
$r and checks that $r->isa('Apache') will not fail
What has changed since 1.27 can be reviewed here:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=105513561720441&w=2
A more detailed review of each patch included in this release candidate
can be found here:
http://www.apache.org/~gozer/mp1/1.27-dev/
Please give this release a spin and report back any problems or failed tests to:
[EMAIL PROTECTED] as soon as possible. The more platforms & configurations, the
merrier!
RC1 has received a relatively low volume of tests, but all of them were positive,
So unless an important bug is reported soon, this will most likely be mod_perl 1.28.
Thank you, and tests away!
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQA++FtzyzKhB4jDpaURAkdrAJ0W3IhOQG6bsYOJAOp+HnwxCN6GRACfdass
J3nVYrAiY5ElPf9DCrk6/Wk=
=sDbB
-END PGP SIGNATURE-
signature.asc
Description: This is a digitally signed message part
