Front page | perl.perl5.porters |
Postings from May 2016
On Sat, May 14, 2016 at 02:39:54PM +0100, Dave Mitchell wrote: > I've never been entirely clear what the *actual* point of mathoms.c is. > I had always assumed it was to allow binary compatibility: i.e. > when something is converted from a function to a macro, XS code that > had been compiled to use that function would still dynamically link > against a newer perl in the same series. > > But if this is the case, I think we should be emptying out mathoms.c > just before every major release, which we don't appear to do. It's as much source compatibility. There was (and still is some) XS code on CPAN that referred to functions by their "full name" rather than relying on the "embedding" macro. Hence when the macro gets changed to call something else, that code doesn't see the change. Whatever we *said* we were going to do, I believe that we also never actually marked them deprecated in any way. Hence there's still a bunch of code on CPAN that references them. After 154 tabs on grep.cpan.me I find Sys::Signal, Convert::Binary::C's tests, and the Devel::NYTProf .gdbinit: http://grep.cpan.me/?q=-file%3Amathoms.c+-file%3Appport.h+-file%3Aproto.h+-file%3Aembed.h+\bPerl_sv_setsv\b http://grep.cpan.me/?q=-file%3Amathoms.c+-file%3Appport.h+-file%3Aproto.h+-file%3Aembed.h+\bPerl_hv_fetch\b Convert::Binary::C's tests: http://grep.cpan.me/?q=-file%3Amathoms.c+-file%3Appport.h+-file%3Aproto.h+-file%3Aembed.h+\bPerl_hv_store\b Embperl: http://grep.cpan.me/?q=-file%3Amathoms.c+-file%3Appport.h+-file%3Aproto.h+-file%3Aembed.h+\bPerl_newAV\b optimizer: http://grep.cpan.me/?q=-file%3Amathoms.c+-file%3Appport.h+-file%3Aproto.h+-file%3Aembed.h+\bPerl_save_op\b The Devel::NYTProf .gdbinit: http://grep.cpan.me/?q=-file%3Amathoms.c+-file%3Appport.h+-file%3Aproto.h+-file%3Aembed.h+\bPerl_sv_2bool\b Tk: http://grep.cpan.me/?q=-file%3Amathoms.c+-file%3Appport.h+-file%3Aproto.h+-file%3Aembed.h+\bPerl_to_utf8_lower\b http://grep.cpan.me/?q=-file%3Amathoms.c+-file%3Appport.h+-file%3Aproto.h+-file%3Aembed.h+\bPerl_to_utf8_upper\b http://grep.cpan.me/?q=-file%3Amathoms.c+-file%3Appport.h+-file%3Aproto.h+-file%3Aembed.h+\bPerl_is_uni_alnum\b http://grep.cpan.me/?q=-file%3Amathoms.c+-file%3Appport.h+-file%3Aproto.h+-file%3Aembed.h+\bPerl_is_uni_alpha\b http://grep.cpan.me/?q=-file%3Amathoms.c+-file%3Appport.h+-file%3Aproto.h+-file%3Aembed.h+\bPerl_is_uni_space\b http://grep.cpan.me/?q=-file%3Amathoms.c+-file%3Appport.h+-file%3Aproto.h+-file%3Aembed.h+\bPerl_is_uni_upper\b Class::AutoDB, Data::Dumper::Limited: http://grep.cpan.me/?q=-file%3Amathoms.c+-file%3Appport.h+-file%3Aproto.h+-file%3Aembed.h+\bPerl_utf8_to_uvchr\b On Wed, May 18, 2016 at 01:27:22PM -0000, Father Chrysostomos wrote: > Dave Mitchell wrote: > > Unless anyone objects, I think we should > > > > 1) empty mathoms in blead now; > > 2) if no problems occur, add it as a new post-major-release step in the > > RMG. > > How about being kind to the release manager and waiting until after > Friday's release? Otherwise, I have no objection. At least then. And smoke the test first on Win32. Because I have a suspicion it might break: http://grep.cpan.me/?q=-file%3Amathoms.c+-file%3Appport.h+-file%3Aproto.h+-file%3Aembed.h+\bPerl_fprintf_nocontext\b So, I think I am objecting, in as much as I'm objecting to just doing it without checking whether the above stuff breaks, and if so considering how to pre-empt breakage. (And I apologise for not having the time to check the above.) Nicholas ClarkThread Previous | Thread Next