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. |
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.