develooper Front page | perl.perl5.porters | Postings from October 2013

NWCLARK TPF grant report #97

Nicholas Clark
October 3, 2013 13:26
NWCLARK TPF grant report #97
Message ID:
[Hours]		[Activity]
2013/07/08	Monday
 3.75		ExtUtils::Miniperl

2013/07/11	Thursday
 1.25		Makefile.SH valgrind targets
 2.00		gcc ASAN (merging -DPERL_GLOBAL_STRUCT fixes)

2013/07/12	Friday
 0.25		RT #113932
 0.25		RT #118139
 0.25		RT #70357
 1.00		deterministic Errno and Pod::Functions
 1.75		gcc ASAN (merging -DPERL_GLOBAL_STRUCT fixes)
 0.25		process, scalability, mentoring
 0.50		reading/responding to list mail
 1.25		smoke-me/Makefile-norecurse

2013/07/13	Saturday
 0.25		deterministic Errno and Pod::Functions
 0.50		installperl/installman
 0.25		lib/warnings.t failure
 0.25		run_multiple_progs

Which I calculate is 13.75 hours

Last week's fun with ExtUtils::Miniperl wasn't quite over. It turns out that
there's yet another twist in the tail. As well as all the interaction
between miniperlmain.c and ExtUtils::Miniperl, it turns out that there's yet
another copy of the perlmain.c is in ExtUtils::Embed.

ExtUtils::Embed is a module added to the core back by commit
a2c6f8f14c6bd897 in July 1996. It's described as "Utilities for embedding
Perl in C/C++ applications", including 4 routines to generate the C code to
initialise statically linked extensions. Given that the perl executable is
structured as a trivial main() wrapper around an embedded perl interpreter,
this means that ExtUtils::Embed is doing pretty much the same job as
ExtUtils::Miniperl, and indeed the code was effectively forked off
ExtUtils::Miniperl 17 years ago.

The code hasn't diverged much (and fortunately this also means that there
weren't bugs fixed in one but not the other) so it was relatively simple to
refactor ExtUtils::Miniperl to call routines in ExtUtils::Embed. The result
is that there is now only one copy of Perl code to generate the C for an
xsinit() function, for all the different use cases.

One other little thing I did this week was to add sort to the code which
generates Errno and Pod::Functions so that the same output is always
generated, independent of randomised hash ordering. The alternate orderings
of generated code wasn't a bug, so didn't absolutely *need* fixing, but
being able to compare the generated files and have them byte-for-byte
identical makes debugging and refactoring a lot easier.

Nicholas Clark Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About