Front page | perl.perl5.porters |
Postings from March 2000
From: Gurusamy Sarathy [mailto:gsar@ActiveState.com] > On Thu, 16 Mar 2000 10:06:03 GMT, "Moore, Paul" wrote: > >The nasties are > > All three of which are problems in the extensions > themselves... (just to drive home a point :) Yes. Sorry if I didn't make that clear. > cv_undef() and cv_const_sv() are not in the list of public API > functions. I'm not sure why mod_perl needs them, but it seems like > a bad idea to use them. (SvREFCNT_dec() should be used rather than > cv_undef(), because the latter will clobber a CV regardless of how > many people own it. And cv_const_sv() is purely internal.) Urk. I had heard rumours of a newer mod_perl, but couldn't find it on CPAN when I looked. I'll check this one closer, but I don't know anything about mod_perl, so I probably won't find much :-( > >I have to agree with whoever it was who commented that > >releasing 5.6.0 with key modules on CPAN not building > >in the latest version, would be a problem. > > FWIW, I (mildly) disagree. New releases must happen to effect change > in something as big as CPAN--we can't wait around for > everyone to "catch up", because in my experience, very few of them > will "catch up" unless there's a release out to "create" demand for > the changes. It's a close call. But I'd tend to think that there are "big" CPAN modules which ought to work at the point of release. The ones I'd tend to put in this category are mod_perl, DBI, and Tk. And maybe libwin32. But I do agree that with something as big as CPAN, trying to get everything tested and compatible is pretty much a no-hoper. > Thanks for the table. Glad it was of use. I'll try to update it with some more comments, plus a run with ithreads/fork for comparison. Maybe I'll put the results on my web page for general reference. Paul.Thread Next