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

NWCLARK TPF grant report #45

Nicholas Clark
July 25, 2012 05:57
NWCLARK TPF grant report #45
Message ID:
[Hours]		[Activity]
2012/07/09	Monday
 0.25		RT #113930
 0.25		RT #114022
 0.25		RT #24652
 0.75		smoke-me/require
 0.75		reading/responding to list mail

2012/07/10	Tuesday
 2.00		Old RT tickets
 3.00		RT #77536
 1.00		linklist
 0.50		reading/responding to list mail

2012/07/11	Wednesday
 0.25		smoke-me/require
 1.25		build process
 0.25		ck_select
 2.50		fold_constants
 2.00		linklist
 0.75		reading/responding to list mail
 0.50		scalarvoid

2012/07/12	Thursday
 1.50		smoke-me/require
 1.75		build process
 1.75		decoupling version
 0.50		reading/responding to list mail

2012/07/13	Friday
 2.00		reading/responding to list mail

Which I calculate is 23.75 hours

This week finally something clicked and I finally understood the subtleties
and assumptions of fold_constants(), op_linklist(), which it calls.

fold_constants() dates back to perl 5.000, but really it would have been
better named "various mandatory and optional optree fixups that we need to do
at this point", which is neither very terse, nor shorter than the 32
characters that ANSI guarantees as acceptable for a symbol. Since 5.000,
various refactorings have moved the code unrelated to constant folding to
other routines, leaving fold_constants() pretty much true to its name.

However, fold_constants() is not as general as its name might suggest. It is
only able to analyse and fold a tree consisting of just a single op and
entirely constant arguments. It can't fold anything more complex, such as
this optree:

     /  \
    1    *
        /  \
       2    3

This doesn't matter to perl's parser, as the optree is constructed from the
bottom up, with fold_constants() is called immediately as each op is built,
hence the above would be folded as 2 * 3 and then 1 + 6. But this does mean
that fold_constants() isn't that useful as a general-purpose constant
folding API.

As part of this enlightenment, I refactored op_linklist() to be slightly
terser, improved the documentation of its wrapper macro LINKLIST(), and
removed needless duplicate calls from fold_constants() to LINKLIST(). I've
removed 9 gotos (all vestigial) from fold_constants(), and documented it. I
also spotted a long-standing error in perlguts.pod, and fixed that too.

Rather less successful was an attempt to untangle a bit more of the build
process. The distribution 'version' on CPAN ships XS code for dealing with
version objects and parsing v-syntax essentially identical to the code in
the perl core. However, because that code is needed early in the core
bootstrap (specifically, for miniperl, so before the core is able to process
XS code), the code for version objects etc has to be shipped as C code. The
code in question is within util.c and universal.c, which obviously makes it
a real pain for keeping it in sync with the CPAN version.

I had a possible insight - the version distribution also ships with a pure
perl implementation, version::vpp - could we use that to bootstrap miniperl?
Sadly the answer is no, because "pure perl" has its usual CPAN meaning - "no
need to install XS code". version::vpp uses B to extract raw version object
metadata from magic attached to the scalar. Even trying to bodge things by
forcing that code to return "not found" doesn't work - the build process
grinds to a halt with a failure whilst it tries to build lib/ - ie
pretty much the first step after miniperl is ready to run.  So, this isn't
going to work out. However, it looks like it might be possible to
disentangle things using a potentially simpler approach - refactor the
version distribution's XS code to split the pertinent C out into separate
files, and then #include those directly from universal.c and util.c. John
Peacock hopes to be able to look into this further, but can't currently as
his time is otherwise spoken for.

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