http://qs321.pair.com?node_id=1192880


in reply to Re^2: pack and unpack multiple arrays with one common repeat prefix
in thread pack and unpack multiple arrays with one common repeat prefix

Speaking of the solution in two steps, it can be written like this: 

$count = unpack "C", $str;
@values = unpack "x C$count (V$count)2"

[download]

my table driven decoder is just too dumb to do it in two steps...
I have no idea what you mean by "table driven decoder", but maybe we can help you make it work in two steps instead? Or is there some code that you can't modify that can just be fed a pack template and nothing else?

I suppose you can't change the way the data is packed either? Because if you pack only V values, you just have: my (@values) = unpack "C/(V3)", $str;

Replies are listed 'Best First'.
Re^4: pack and unpack multiple arrays with one common repeat prefix
by hexcoder (Curate) on Jun 15, 2017 at 21:56 UTC
    I wrote a decoder that reads binary telegrams (or messages) with different types (meaning different structures) from a log file. For each telegram type the table has an unpack template that defines the structure of the telegram and a list of names for its fields. The structure is unpacked and the values are formatted with their names to make a readable string representation describing the content of the telegrams.

    Currently this works well with simple types and single arrays prefixed with their length. The structure of the telegrams are given and part of an interface. I agree, there could be simpler unified packings, but that is what I have to deal with.

    Maybe it is a good idea to allow 'two step unpacking', in order to enable the decoding of more complex structures. Thanks, I have to think about it.
[reply]

      G'day hexcoder,

      Perhaps, instead of a table of just templates, you could use a table of coderefs whose functionality includes preprocessing, unpacking, formatting, and anything else you need.

      Here's a highly contrived and primitive example just to show the technique. 

      #!/usr/bin/env perl -l

use strict;
use warnings;

my %decode_type = (
    A => sub { "Do TypeA stuff with '$_[0]'" },
    B => sub { "Do TypeB stuff with '$_[0]'" },
);

while (<DATA>) {
    chomp;
    my ($type, $msg) = split /\s+/, $_, 2;
    my $decoded = $decode_type{$type}->($msg);
    print $decoded;
}

__DATA__
B message B1
A more complex message A1
B message B2

      [download]

      Output:

      Do TypeB stuff with 'message B1'
Do TypeA stuff with 'more complex message A1'
Do TypeB stuff with 'message B2'

      [download]

      I don't know how useful that might be; however, your general description suggested this approach.

      — Ken

[reply]
[d/l]
[select]
        The idea/goal was to seperate the decoding engine (code) from the data structure descriptions (templates) in order to
      • decrease (inter)dependencies
      • reduce code by avoiding (slightly different) duplicates for different structures

        • So, I see your approach as the next best method, when I fail to express the structures with templates in a table. Using a table with handler functions is certainly the most flexible way allowing for very special decoding tasks.

        Thanks, hexcoder
[reply]

In Section Seekers of Perl Wisdom