FAQ

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 Clark

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 8 of 10 | next ›
Discussion Overview
groupperl5-porters @
categoriesperl
postedMay 13, '16 at 4:34a
activeMay 23, '16 at 4:08p
posts10
users5
websiteperl.org

People

Translate

site design / logo © 2017 Grokbase