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

NWCLARK TPF grant report #89

Nicholas Clark
July 26, 2013 13:48
NWCLARK TPF grant report #89
Message ID:
[Hours]		[Activity]
2013/05/13	Monday
 0.25		5.18.0 RCs
 2.00		Floating point stringification (RT #108378, RT #115800)
 1.25		PVHV (critbit)
 0.50		RT #117793
 0.25		RT #117967
 0.25		RT #117977
 2.00		process, scalability, mentoring
 1.50		reading/responding to list mail

2013/05/14	Tuesday
 0.25		HP-UX smoke
 1.50		reading/responding to list mail
 0.25		used only once

2013/05/15	Wednesday
 0.50		a2p
 8.00		makedepend.SH, x2p/Makefile.SH
 0.50		process, scalability, mentoring
 0.25		reading/responding to list mail

2013/05/16	Thursday
 0.25		Floating point stringification (RT #108378, RT #115800)
 0.50		RC testing
 3.75		reading/responding to list mail

2013/05/17	Friday
 0.25		RT #117967
 1.00		Unicode Names
 0.75		reading/responding to list mail

2013/05/18	Saturday
 0.50		Floating point stringification (RT #108378, RT #115800)
 0.25		RT #5087
 1.75		Unicode Names

Which I calculate is 28.25 hours

The main activity of note this week was simplifying the build infrastructure
for the x2p/ subdirectory. x2p/ contains the various "to Perl" utilities,
along with tools needed to build them. In x2p/ it seems that the only
consistency is inconsistency. The names are a2p, s2p and find2perl (not
f2p). The sed and find converters are written in Perl. The awk converter is
written in C. So it's not simply repeat the same build rules for 3 things.

I think I've read somewhere that Larry considered the awk to Perl converter
sufficiently important for Perl adoption that he delayed the Perl 1 release
until a2p was done. The C code itself uses a yacc grammar to parse awk, and
looks suspiciously like Perl 1, down to using the same data structures for
scalars and the same stdio cheating code for fgets().
(See if you're interested)

However useful it was 25 years ago to drive Perl adoption, it's not needed
for that these days, but it is still the only awk to Perl converter, so it
would be nice to ship it independently somehow. Frustratingly, it's not at
all obvious how to do this. It's not XS code linking against the core, so
ExtUtils::MakeMaker doesn't have anything helpful. In fact, the situation is
worse than this - the shipped x2p/Makefile.SH is only used for the build on
*nix systems. It's not a true little self contained sub-perl, as VMS and
Win32 include rules directly in their top level Makefiles to build the
contents of the x2p directory. Additionally, it has no tests - for some
reason I feel more uncomfortable with the idea of shipping something to CPAN
with no tests than I do with the status quo. Maybe it's because if it's an
independent distribution it is completely obvious that it has no tests.

Tests would be useful. I've searched and failed to find any suitably
licensed for inclusion in the core. Effectively to ship dual APL/GPL code
needs to be either exactly that (unlikely), or BSD licensed, or public
domain. Which seems surprising, as there are BSD licensed awk

So as it seems that evicting a2p is actually more work than continuing to
host it in the core distribution, I attempted to reduce duplication in the
build setup, even if that means I've bound it a bit more tightly. In that,
for the past 25 years x2p has been shipping a *second* copy of the
makedepend shell script that automates calculation of C file dependencies to
generate Makefile rules, and a second copy of the cflags shell script used
to invoke the compiler. This seems wasteful. However, it took a bit of
untangling to remove some assumptions from the top-level versions of each
about only dealing with the current directory. But once that was fixed it
was possible to rework x2p's Makefile to use the versions at the top level,
and delete its private forks.

I was also easily able to move running makedepend on x2p into its own rule
in the main Makefile, so that it can happen in parallel with C compilation
for miniperl. Previously it ran as part of the main makedepend, which
happens before make is invoked, meaning it's bottle necked on only one
core. Now a little more can happen concurrently, and maybe a second is
shaved off the elapsed build time for a parallel make.

Finally, I spotted a few more tentacles of dead things that need purging -
rules that turned out to be for deleting files generated when building on
VM/ESA (an obsolete platform we have removed support for), rules for
generating targets related to the Perl compiler (removed in 2006), and rules
related to man page targets deleted by 5.000. They're not the first dead
things (eg installperl rules related to 5.000 to 5.001 changes), and they
won't be the last. But in something this complex, it's never easy to spot
what's actually dead, versus what's obscure but still needed.

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