Remove dependency on Scalar::Util

EvanCarroll commented 5 years ago

autodie is currently using Fatal which is using Scalar::Util but just for access to set_prototype.
Scalar::Util is simply grabbing that from Sub::Util
set_prototype doesn't call any other files in that XS.

If I'm reading this right if we broke about that XS file, or reimplemented it in autodie we wouldn't have to load List::Utils, or Scalar::Utils, and we would have joy?

What would autodie save? In minimal cases at the very least we wouldn't have to map in these three pages from List/Util/Util.so (we'd still have to map in one page from Util.so but we'd reduce that by 3).

7efcc3ce7000-7efcc3cf1000 r-xp 00000000 fd:01 878942                     /usr/local/cpanel/3rdparty/perl/528/lib/perl5/5.28.0/x86_64-linux-64int/auto/List/Util/Util.so
7efcc3cf1000-7efcc3ef0000 ---p 0000a000 fd:01 878942                     /usr/local/cpanel/3rdparty/perl/528/lib/perl5/5.28.0/x86_64-linux-64int/auto/List/Util/Util.so
7efcc3ef0000-7efcc3ef1000 r--p 00009000 fd:01 878942                     /usr/local/cpanel/3rdparty/perl/528/lib/perl5/5.28.0/x86_64-linux-64int/auto/List/Util/Util.so
7efcc3ef1000-7efcc3ef2000 rw-p 0000a000 fd:01 878942                     /usr/local/cpanel/3rdparty/perl/528/lib/perl5/5.28.0/x86_64-linux-64int/auto/List/Util/Util.so

Perhaps we could get with Sub::Util, and have them break out the one function from the XS so Sub::Util doesn't require List::Util, and then we could update our own dependencies?

EvanCarroll commented 5 years ago

I filed an issue here which would be a better idea -- that is to have Sub::Util (which is in the suite of ::Util stuff) break off the XS for set_prototype then we could just use that directly (without touching List::Util or Scalar::Util, and have a reduction in the overhead associated with autodie.

toddr commented 1 year ago

I'll happily take a PR for this @EvanCarroll

EvanCarroll commented 1 year ago

@toddr I filed that bug in parallel on Sub::Util if that's accepted I wouldn't mind trying my hand at breaking apart ListUtils.xs.

https://rt.cpan.org/Public/Bug/Display.html?id=129216

I think that's the right way to go. Then we could use set_prototype in Sub::Util without carrying the weight of List::Utils. However, I think you know why I was interested in this =) and I'm not sure this is still a pressing concern. I think we're unified now not caring about RSS.

EvanCarroll commented 1 year ago

Update from IRC.

< mauke> recent versions of EU:MM support XSMULTI
< mst> yeah
< mst> LeoNerd is just allergic to learning how to use EUMM :P
< LeoNerd> Hmmm is that a recent thing?
< mauke> not just recent, but also experimental
< LeoNerd> Ah.. hmm
< LeoNerd> I don't want to put too much effort into it - any effort is better placed just migrating the things into core's builtin:: where they always should have been
< LeoNerd> So .. meh
< mst> LeoNerd: recent in the sense of it was implemented in 2015
< mauke> ExtUtils::MakeMaker::FAQ describes an alternative of putting each .xs file in its own subdirectory with its own Makefile.PL
< mauke> not sure what that will end up doing, since the third alternative is effectively just loading one xs file from another
< mauke> so the answer is not overly concerned with saving memory
< LeoNerd> Ooooh right... Multiple .xs files is not sufficient here
< LeoNerd> To get what EvanCarroll wants, you'd need to generate multiple .so files
< LeoNerd> I think all XSMULTI does is lets you write multiple .xs files that get squashed up together into a single .so
< mst> oh, hrm, quite possibly
< mst> one .so per dist is kinda the usual way
< LeoNerd> Yah other than memory speedrun optimisations I can't imagine anyone really needing it
< EvanCarroll> I didn't know multiple xs files compile into one .so
< EvanCarroll> fun.
< EvanCarroll> but I do agree, I have no idea why set_prototype isn't in builtin::
< LeoNerd> It isn't because I haven't found time to be bothered to move it yet
< EvanCarroll> fair enough
< LeoNerd> It's probably not even ten lines of C code in builtin.c, If you want to add it I'll review the PR
< ilmari> builtin:: runs the risk of becoming rather clutered. should it have subnamespaces?
< LeoNerd> Actually.. fair
< LeoNerd> I suggested it in the meta:: space instead
< LeoNerd> Someone should nudge that PR forward
< mauke> php::
< ilmari> builtin::bool::{true,false,is_bool}, builtin::ref::{blessed,addr,type}
< mst> mauke: http://trout.me.uk/mstcat3.jpg
< ilmari> buildin::str::trim, builtin::maths::{ceil,floor} etc.
< mauke> builtin::gender
< mauke> ( https://old.reddit.com/r/lolphp/comments/wmrbqh/php_gender_constants_is_your_gender_east_frisia/ )
< Paperbot> Link title(s): [ PHP Gender constants. Is your gender EAST_FRISIA? : lolphp ]
< LeoNerd> I think at the start we said we won't namespace them, because that would be worse
< mst> mauke: an old housemate's wife is from frisia, she makes moocow jokes about herself on a semi-regular basis
< LeoNerd> Butyah; builtin::set_prototype is not a great idea. Would be better to put it in the meta:: space.

So what's wanted here is

the meta:: namespace
move Sub::Util into that.
have Fatal do the right thing if meta::set_prototype exists.

The proposal for meta:: is here https://github.com/Perl/RFCs/pull/25

Dual-Life / autodie

Remove dependency on Scalar::Util #86