PDL::PP::pp_def: HdrCode is ignored when PMCode is present

[jo-37]

When defining a pp function using pp_def, the code in a HdrCode block is ignored if a PMCode block exists.

Here is a pd file to reproduce the behaviour. In the PMCode block, the argument k is multiplied by 3 and in the HdrCode block it is multiplied by 5.

our $VERSION = '0.01';
pp_setversion($VERSION);

pp_def('foo',
	Pars => 'a(n); [o]b(n);',
	OtherPars => 'int k;',
	PMCode => q{sub PDL::foo {
			return PDL::_foo_int(@_[0, 1], $_[2] * 3);
		}
	},
	HdrCode => q{
		k *= 5;
	},
	Code => q{
		loop(n) %{
			$b() = $a() * $COMP(k);
		%}
	},
);

pp_done();

Accompanied by a corresponding test program: With a = 1, and k = 2, the result should be 30, but the HdrCode factor is missing in the result.

#!/usr/bin/perl

use v5.16;
use Test2::V0 '!float';
use PDL;
use PDL::Foo;

plan 1;

foo(pdl(1), my $b = null, 2);
is $b->sclr, 30, '2 * 3 * 5';

1..1
not ok 1 - 2 * 3 * 5
# Failed test '2 * 3 * 5'
# at test.pl line 11.
# +-----+----+-------+
# | GOT | OP | CHECK |
# +-----+----+-------+
# | 6   | eq | 30    |
# +-----+----+-------+

[mohawk2]

Thanks for following up with this! Take a look at the linked commit, which I believe solves this issue. If you agree, go ahead and close this. But do have a read of the commit, since it shows how easy it is to update PP once one gets an idea of how it works (it's a sort of pull-based lazy evaluation system).

To get a further idea, you can run make core && perl -Mblib Examples/doc-pp pp.png to see what rules (square boxes) set (incoming arrows) and depend on (outgoing arrows, optionally if dashed) values supplied to pp_def.

[jo-37]

Fixed. Thanks @mohawk2 !

The rules picture is very impressive. I'll take a closer look at it.

[mohawk2]

Please feel free to ask questions on the mailing list(s)!