Re: Data::Dumper output

[AnomalousMonk]

My interpretation is that Dumper is dumping you a string that was produced from the stringization of a hash reference. Note the single-quotes surrounding the body of the dumped output and the embedded newline.

Win8 Strawberry 5.8.9.5 (32)  Fri 05/07/2021 19:46:25
C:\@Work\Perl\monks
>perl -Mwarnings

use Data::Dumper;

my $hr = { qw(one uno  two dos) };

my $request = "$hr\n"; # stringize a hash ref, end in newline

print Dumper $request;
print Dumper %$request;

^Z
$VAR1 = 'HASH(0x333824)
';

(Update: So I'd say that the unkosher '(' comes from the opening paren in 'HTTP::Request=HASH(0x1c23960)'.)

As to the

print Dumper %$request;

$VAR1 = '4/8
';

part, I can't reproduce it, but note that enabling strictures throws an error for the %$request expression (do you have strict enabled?), and that the following stringization gives the number of hash "bins" used versus those currently allotted for the hash:

Win8 Strawberry 5.8.9.5 (32)  Fri 05/07/2021 20:03:42
C:\@Work\Perl\monks
>perl -Mstrict -Mwarnings

use Data::Dumper;

my $hr = { qw(one uno  two dos) };

my $bins = '' . %$hr;

print Dumper $bins;

^Z
$VAR1 = '2/8';

(Update: I.e., '2/8' is a feature of the stringization of hashes and has nothing to do with Data::Dumper:

Win8 Strawberry 5.8.9.5 (32)  Fri 05/07/2021 20:15:42
C:\@Work\Perl\monks
>perl -Mstrict -Mwarnings

my %hash = qw(one uno  two dos);

print '' . %hash;

^Z
2/8

Note that details of this behavior changed somewhere between versions 5.8 and 5.30.)

[kcott]

G'day AnomalousMonk,

"Note that details of this behavior changed somewhere between versions 5.8 and 5.30.)"

I suspect that's 5.26.0: "perl5260delta: scalar(%hash) return signature changed". I don't have a pre-5.26 version handy to test that.

However, there's other things probably going on prior to the code shown in the OP:

• Why is there a newline appended to the hashref? I'd guess there's some sort of suspect code near where that happens.
• Lack of strict as you already noted.
• Other things we can't see any code for.

I'm able to test this much (on 5.32.0):

# The sort of result that was no doubt expected:
$ perl -e 'use Data::Dumper; my $hr = bless {a=>1}, "H::R"; my $r = $h
+r; print Dumper $r'
$VAR1 = bless( {
                 'a' => 1
               }, 'H::R' );

# Reproduce output with stringification and embedded newline:
$ perl -e 'use Data::Dumper; my $hr = bless {a=>1}, "H::R"; my $r = "$
+hr\n"; print Dumper $r'
$VAR1 = 'H::R=HASH(0x800003b78)
';

# No bucket allocation ratio for me; also no strict to advise of probl
+em:
$ perl -e 'use Data::Dumper; my $hr = bless {a=>1}, "H::R"; my $r = "$
+hr\n"; print Dumper %$r'

# Problem advice when strict is used:
$ perl -e 'use strict; use Data::Dumper; my $hr = bless {a=>1}, "H::R"
+; my $r = "$hr\n"; print Dumper %$r'
Can't use string ("H::R=HASH(0x800003b78)
") as a HASH ref while "strict refs" in use at -e line 1.

Bod, address the dot points above: there may be a solution in there. If that solves nothing, provide more code. Also, what Perl version are you using? (I seem to recall you had different versions on your local machine and your hosted server.)

[Bod]

address the dot points above: there may be a solution in there

Yes - sorry guys...I was doing something very silly
See Re^2: Data::Dumper output

To answer the version question, I am using v5.16.3. I do have 5.32 locally but this is being written and tested on the webserver as that's where the code will ultimately run and I cannot see the Perl version changing anytime soon.

[Bod]

Update: So I'd say that the unkosher '(' comes from the opening paren in 'HTTP::Request=HASH(0x1c23960)'

You were spot on with the stringification causing the problem. I was trying to put some whitespace between the various Dumper outputs so wrote a rather stupid line of code:

print Dumper %$request . "\n";

Culprit found!!! Sorry for the senior moment!

I think you are right about the source of the opening parenthesis. But I am using an existing module, LWP::Authen::OAuth2 that works. I am only adding a Dumper statement to it to try and understand what it needs that I am not giving it. It should take a hashref. This is the code I am using to call it:

open my $fh, '<', "linkedin.json";
my $json;
{
    local $/;
    $json = <$fh>;
}
close $fh;

$params = decode_json($json);

my $header = {
    'X-Restli-Protocol-Version:' => '2.0.0',
};

print Dumper $params;
print "\n\n============\n\n";
my $res = $linkedin->post('https://api.linkedin.com/v2/ugcPosts', $par
+ams, $header);
if ($res) {
    print Dumper $res;
    exit 0;
}

There is an external JSON file so that I can use exactly the example given in the LinkedIn API documentation without introducing data structure errors. The only thing that's changed from that example is the person:id value.

I'm beginning to think that the LinkedIn API is sufficiently recalcitrant to warrant writing a module from scratch for posting to it. Just use the LWP::Authen::OAuth2::ServiceProvider subclass for authentication and not for posting.

[Bod]

Short reply from my mobile...I will reply more fully when I get to a proper keyboard...

Both strict and warnings are enabled. The Dumper line is added to the existing code of the OAuth2 module as suggested on another node. I've checked that the module has strict and warnings turned on. So it is strange that the dereference isn't throwing an error or warning.

I'm using Perl 5.16.3

[AnomalousMonk]

... the module has strict and warnings turned on. So it is strange that the dereference isn't throwing an error or warning.

strict and warnings both support lexical scoping, so it's possible that strict has been locally disabled.

(And it's good to know the version of Perl you're using! :)