convert last small purpose of builtin.pm to C and NOOP require's I/O #22699
Conversation
| hv_store(inc_hv, "builtin.pm", STRLENs("builtin.pm"), newSVpvs(__FILE__), 0); | ||
| ver_gv = gv_fetchpvs("builtin::VERSION", GV_ADDMULTI, SVt_PV); | ||
| ver_sv = GvSV(ver_gv); | ||
| /* Remember to keep $VERSION in this file and $VERSION in builtin.pm synced. */ |
There was a problem hiding this comment.
Is it possible to have a test for that?
There was a problem hiding this comment.
the test is in this patch already. Change either side to 0.017 and test fails.
There was a problem hiding this comment.
Apologies, I missed that.
-builtin.pm is now primarily for POD and .pm indexing tools, core, CPAN or user written. It also is a backup mechanism for very strange %INC localization, clearing, or manipulation done by users, probably in a .t, and whatever %INC manipulation is being done is probably developer error. -This removes all the libc/kernel I/O calls for builtin.pm, and Perl code parser overhead. -A large benefit is, this commit is 50% of the work, to make perl -E 'say "hi";' "/lib"-less or not dependent on any file I/O. perl.bin, libperl.so, and miniperl.bin should be able to execute as a standalone binary. If perl -e "1;" doesn't need a dozen separate library files, perl -E "1;" also shouldn't need a dozen files. perl -E "say 'Hello world';" should work, even with a broken perl installation or unreachable "/lib/*.pm"s or broken "portable" perls. Only a feature.pm dep is left, for -E to be lib-less. That is for another patch and PR in the the future.
bulk88
force-pushed
the
remove_builtin_package_IO_dep_on_dot_pm
branch
from
d5208db to
eb882bf
Compare
|
repushed,, forgot to stage an extra sentence comment in the .pm |
builtin.c
Outdated
| @@ -774,6 +774,9 @@ XS(XS_builtin_import) | |||
| void | |||
| Perl_boot_core_builtin(pTHX) | |||
| { | |||
| HV * inc_hv; | |||
| GV * ver_gv; | |||
| SV * ver_sv; | |||
| I32 i; | |||
There was a problem hiding this comment.
Can we fold these declarations into the assignments below now that we're C99? That would seem more readable to me. The loop index should probably also move but that might be considered out of scope for this PR.
There was a problem hiding this comment.
done in latestest .rev
|
This would mean %INC would no longer by empty at startup, right? That will actually break code of mine. I suspect there will be tests broken by this too. |
Cperl had a dozen things in %INC on startup. I dont remember any bug reports from back then and nothing comes up on google/GH with bug reports or complaints, but sample size of people who would write a ticket, is small, for that fork, but I wouldve found a ticket of some kind if it was a common pattern to depend on deep compare of %INC against a const hash.
Or idea 3 Another argument is, hard coding string_eq skips into pp_require() is fine. Another argument, the upstream dep list of any CPAN/Core module is UB. There is no API contract that a module will never add or remove a upstream dep between released. And the interp is a Line 1235 in 9a9d70c |
|
Another idea, P5P modules upstream or p5p not shipped on CPAN, The "no updates unless you install new major release kinds of module I propose p5p modules, from now they are blacklisted from %INC and should only appear in new ``%^INC` global hash, the hash should be RO from day. light foot steps towards code signing/DRM/Security/tampering with .pm files by a maids/ |
-builtin.pm is now primarily for POD and .pm indexing tools, core, CPAN or user written. It also is a backup mechanism for very strange %INC localization, clearing, or manipulation done by users, probably in a .t, and whatever %INC manipulation is being done is probably developer error. -This removes all the libc/kernel I/O calls for builtin.pm, and Perl code parser overhead. -A large benefit is, this commit is 50% of the work, to make perl -E 'say "hi";' "/lib"-less or not dependent on any file I/O. perl.bin, libperl.so, and miniperl.bin should be able to execute as a standalone binary. If perl -e "1;" doesn't need a dozen separate library files, perl -E "1;" also shouldn't need a dozen files. perl -E "say 'Hello world';" should work, even with a broken perl installation or unreachable "/lib/*.pm"s or broken "portable" perls. Only a feature.pm dep is left, for -E to be lib-less. That is for another patch and PR in the the future. -silence nearby MSVC x64 only truncation warnings
|
The original specification of builtin suggested we might ship builtin as a module on CPAN that implemented backports of at least some of the builtins. From what I can see this change prevents such an implementation from working. |
You bring up a good question here. So I need to do more thinking on my side now. NOTE NOTE NOTE!!!!!! This is a long @#$ post. I'm probably just going to add 5-10 more lines of new C code in this PR, for a simple non-contraversal quick engineering "fix", regarding TonyCs question, vs waiting for a social or legal or policy or management "fix" for this PR. The rest of this post is about very important "policy" and "direction" problems, with the Perl 5 lang/grammer, and the PAUSE SQL DB, and not about C/PP source code or engineering. The "policy" or "direction" problems/concerns need to be answered "officially", whatever "officially" means here. I did read https://github.com/Perl/PPCs/blob/f22f090f1a77002d7f9b3af38717b2067e495e9a/ppcs/ppc0009-builtin-namespace.md all the way to the end just now. Yes, Revision 1 (or current/last as of writing) disables the provision, for a CPAN builtin.tar.gz installed in But I see conflicts with the text inside PPC-0009 and current established P5P policies/practices. Quoting PPC-0009 Now, lets look at P5P's official policies https://github.com/Perl/perl5/blob/blead/pod/perlpolicy.pod#maintenance-and-support https://github.com/Perl/perl5/blob/blead/pod/perlpolicy.pod#maintenance-branches P5P over many years, has reduced further and futher, the count of, release frequency per year, and commit counts, of stable perl, to near zero except for CVE fixes. In 2024/2025, nothing except a SEGV from PP code, no CPAN XS allowed, or a CVE qualifies for EOL/legacy "support" from P5P. Whether by policy, or just cherry pick votes by P5P devs with a commit bit, the truth is maint perls tar.gz'es at 5.4X.1 or 5.4X.2, just don't exist anymore, and if they exist, they offer little value to bother installing and redeploy all your production code. A perl user needs to wait till next June of next year, or use blead perl in production. Thats the real P5P maint policy. So the text in PPC-0009 wants to ship a My PR can only change what a blead perl/future perl does going forwards, it can't change what happens on legacy libperl.so'es already deployed in the field. This write up by me is so long, because it brings a serious design question, of what the "pragmas" in Perl 5 language really are. All of the Perl 5 language pragmas today are mis-use of Larry's/Perl's Larry Wall's official language extension mechanism in Perl 1-5.000 alpha, which is https://perldoc.perl.org/perlvar has been obsolete for decades. I don't personally, and nobody on WWW thinks, that historic "extension mechanism" is correct and proper, and shoud be "expanded". Anyone can chime in on I'm not advocating for The above isn't my idea. Its someone elses. And there is Artisic 2.0 licensed C code out there, implementing all of Perl 5's all-lowercase pragmas, as test passing PPC-0009 was written on Oct 16, 2021. This is April 2025. AFAIK, that provision of PPC-0009 hasn't been done by now. But there are multiple imitations/copy-cats of that provision on CPAN right now. Its been 4 years, nobody wrote the official CPAN code for https://metacpan.org/pod/builtin::compat Is that provision from PPC-0009 even applicable anymore if Is there a legitimate reason for P5P to ship a
Will Knop (the person) suddenly become adversarial/ideological over his Thats fantasy talk IMO. There isn't a reason for that current CPAN module and its PAUSE package namespace, to turn into a war zone requiring There is also PPC-0009's sponsors/authors module at https://metacpan.org/release/PEVANS/builtin-Backport-0.02 and while I do see this file and this line of source code https://metacpan.org/release/PEVANS/builtin-Backport-0.02/source/lib/builtin.pm#L3 according to https://metacpan.org/dist/builtin-Backport/permissions that is not the "official" But it looks abandoned by its CPAN/PAUSE owner, and it doesn't have a GH repo published anywhere. I tried searching for it. Dont think it exists. And it looks like the Perl community agreed on the CPAN module located at https://metacpan.org/pod/builtin::compat as the implementation of PPC-0009's text that talks about backporting through CPAN to anicient perls. https://github.com/haarg/builtin-compat/commits/master/ shows https://metacpan.org/pod/builtin::compat has very many updates, and its owner easily accepts other people's patches, and does quick releases on CPAN of new .TGZs. But lets discuss this provision, as if it will happen, or someone will write the code in the next 3 months and ship P5P PAUSE account doesn't have namespace ownership of package builtin Some other people do For purpose of this discussion, lets pretend LeoNerd had a tragic interaction with a public transit vehicle 12 hours ago. So he isnt alive to write new code going into the future. So what person with a P5P commit bit, is going to write the code, and release a future How does a https://github.com/Perl/perl5/blob/blead/pod/perlpolicy.pod#maintenance-branches The only prior talk I've found at https://groups.google.com/g/perl.perl5.porters/c/5V2aK9OSb5g/m/JKlpRWvHBgAJ https://www.nntp.perl.org/group/perl.perl5.porters/2023/07/msg266763.html (same link) suggests PEVANS was told its a policy violation to do what PPC-0009 says. But that is 1 persons (James E Keenan) P5P ML post. Which is someones personal opinion, and not a "decision", because its 1 person ML post. And PEVANS called his module Someone correct me if the kid51 Keenan ML post from 2023 was the "official decision", which said PPC-0009's I can't find any other prior talk about an official P5P sponsored and controlled Now lets say, its not a maint policy violation, won't all future updates/changes to If future Those paragraphs in PPC-0009 need official clarification, if those paragraphs about Also official clarification is needed, is CPAN module called https://metacpan.org/pod/builtin::compat the actual deployed production implementation of that provision inside PPC-0009, or did Knop create an unauthorized, unofficial, not P5P connected, CPAN module, for their personal/private day job needs, or is PEVAN's CPAN already has a bug ticket at https://rt.cpan.org/Public/Bug/Display.html?id=158702 describing a runtime bug, with his So official clarification is needed, does PEVANS as the author of PPC-0009, have legal or social or moral ownership of 4 different things.
It can be argued P5P, looses control of obsolete stable "Perl 5" releases when P5P according to its own policy, drops "maint" for old stable Perl 5 interps after 24 months, so what his
Im writing all of this up, since its a good topic that needs a final deciscion by someone, who controls or what group "owns" PP src code ASCII string If an end user for some reason really wants to runtime replace the P5P C code at runtime in their perl process (monkey patching), they can just delete the The cPerl fork decided to always keep the P5P PP versions of the core pragmas around for miniperl.exe reasons and testing its own .c code implementations of the P5P PP code as a sanity/back compat test during its interp core self-make-test. I agree with leaving a monkey patch hole open at runtime if for some crazy reason an end user wants to monkey patch their perl binary and their perl process. Perl 5 isn't a WWW HTML browser app with mandatory extreme security rules for end user code. Perl 5 lang will always give end users a box of bullets and a long rope. Its their address space, their OS process, and their PP/C source code. Perl isn't a mobile app store or a OS hypervisor project. |
See commit text. Embedding modern Perl's near universal .pm'es/pragmas into static XS/C to avoid parsing/IO, is advantageous for all perl CI everywhere. builtin.pm was very easy to do, b/c it already was 99% static XS. And its part of the .pm dep tree of
-E"".-E say is supposed to be shorter to type, but whats the point if it requires typing a
-I../libevery time for core hacking.More philosophically, I want the
-E"say();"from my first-e"print();"many years ago. I only do perl, because I couldn't get the C compiler to ever work, after loaning a big purple C book from my middle school library. Don't know why the book even was there in that library.Many decades ago, perl5 was supposed to be a better shell script, or batch file. And perl was promised to be a single executable disk binary. Not 100s or 1000s of disk files for the C++ STL/.NET/Node/Java base class libraries, just to do hello world. A broken first ever newbie dev perl install that can do atleast
-E"say()"will maybe keep someone in the perl community. A "features.pm file not found" error, well, that person moves onto another programing language in a few minutes and never looks back at perl.node.bin is a fat packed pre-compiled pre-jitted ~70 MB single OS binary file with the basic class library burned in (
undump()sort of). No env var or broken install problems on that platform. The .js files on disk from the installer are only for the JS debugger to use. Node can't be compared to P5, but P5 can atleast knock the low hanging fruit off and embed the basic .pm/pragmas or primary execution paths of them/lazy load pragma .pm'es etc.