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-devm=105595499417788w=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 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 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-devm=105595499417788w=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
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
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: 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-devm=105595499417788w=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
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
