Re^6: a *working* JSON module (Perl's Debugger), related issues

Aldebaran++ that's really cool addition you got there!

Q2) How would I turn the above script into "monolithic" foreign code?

Turn your additions into a sub (a subroutine aka function) which will be a complete black box. It will take some inputs, and return some outputs (print if you must but don't forget to return all you need to return to the caller so that your sub is useful). For example:

sub func {
my ($event, @planet_names) = @_; # read in parameters supplied by call
+er as in func($xyz)
# check that we have some names and that event contains the fields we 
+need
# return undef on error.
# caller must check if received undef!
return undef unless @planet_names;
return undef unless exists $event->{epoch};
...
my %returned_planets = ();
for my $a_planet_name (@planet_names){
my $planet = Astro::Coords->new( planet => $name );
...
$returned_planets{$a_planet_name} = $planet;
}
# return to the caller results as a hashref
# I always use refs for params and results. others may not.
return \%returned_planets;
} # end of my function

# example use
my $ret = func($anevent, "venus", "saturn");
die "func() failed" unless defined $ret;
# and now do what you like with the results.
[download]

I am referring to the code you presented above about here:

for my $event (@events) {
  my $epoch = parse_event($event);

  my ( $MoonPhase, $MoonIllum, $MoonAge, $MoonDist, $MoonAng, $SunDist
+,
    $SunAng ) = phase($epoch);
[download]

Then build some test cases to test your sub. Edge cases (e.g. empty planet names, wrong names) and also cases you know the result. And you are good to go :)

Todo: at this stage it is a prototype. When final, we can turn this into OO, with $event being a class. But that's much later.

Let me know how you convert your additions into a sub.

Q3) Does Data::Roundtrip cover the same ground that JSON::XS did? I can't disambiguate what XS means.

It's just a wrapper around many great modules to implement things like json2perl, perl2yaml with (hopefully correct) unicode suppprt. Don't worry about it. But you can safely replace it with calls to JSON's decode() etc. (which, as stevieb said, switches between XS or PP depending what is installed on your system) so that you have one less dependency.

BTW, I think you also provided me with an answer as to why I never use the debugger :)

bw, bliako

Comment on Re^6: a working JSON module (Perl's Debugger), related issues Select or Download Code

Replies are listed 'Best First'.

Re^7: a *working* JSON module (Perl's Debugger), related issues
by Aldebaran (Curate) on Oct 31, 2021 at 22:08 UTC

Let me know how you convert your additions into a sub.

I'll work on that. I appreciate the concrete Anweisungen

Ok, it helps to know that PP is the alternative, and PP stands for, wait for it, pure perl.

BTW, I think you also provided me with an answer as to why I never use the debugger :)

I'm happy to provide you with certainty, a rare commodity in this world. :) Like I say, for me it's usually when I'm hooking up parts that are new to me, and I have to figure out what is not happening with values. With hippo's help, I've figured out parts of your debugging scheme, and see how it's built. I wasn't calling it correctly.

>> p @_
43.61-116.20
>> p $debug
0
[download]

I had been passing a bare zero (a hasty stubout) as the third argument to this routine. this was undefined on arrival. Now I have improved it to hook into your debugging scheme, as you define $debug in the caller:

  my $return = get_elevation_from_coordinates( $event->{location}->{la
+t},
    $event->{location}->{lon}, $debug );
[download]

Then I get the internals of the exchange with google, and everything makes even more sense:

./6.mp.pl : latitude=-15.6325&longitude=-141&application_max_assets_mt
+ime=1559625591
./6.mp.pl : sending above payload, of 72 bytes...
INFO: return from the google is 0 meters
[download]

When I hit M in the debugger too see what version of JSON I was running, I was surprised to see that

/usr/local/lib/x86_64-linux-gnu/perl/5.30.0/JSON/XS.pm

was among the loaded modules. I take that to mean that perl is covering its bases for backwards compatibility. I wonder how I might determine whether execution ran through it(?) What's more, I found my PP.pm module, and read it mod 1:

locate *JSON/PP.pm

, wherein is:

     # Note that JSON version 2.0 and above will automatically use
     # JSON::XS or JSON::PP, so you should be able to just:
 
     use JSON;
[download]

Again, with the M command, I see that my version is way north of 2.0:

'JSON.pm' => '4.03 from /usr/local/share/perl/5.30.0/JSON.pm'
'JSON/XS.pm' => '4.03 from /usr/local/lib/x86_64-linux-gnu/perl/5.30.0
+/JSON/XS.pm'
[download]

So, after all this, I see that it is not of any practical concern for what I do with json. What's more, I would be hesitant to fire a cannon of requests in compiled c to the same server. It might exceed what many consider polite. Love them or hate them, I don't want to be on the wrong side of the google.

[reply]
[d/l]
[select]


Think about Loose Coupling
	PerlMonks