poke-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discussion] Side-by-side dump format


From: Jade Lovelace
Subject: Re: [Discussion] Side-by-side dump format
Date: Mon, 21 Aug 2023 23:16:06 -0700

Hi, I evidently did a little bit of a nerd snipe hahahaha. Thanks for
all your work on this!

On Mon, Aug 21, 2023 at 3:37 PM Jose E. Marchesi <jemarch@gnu.org> wrote:
>
>
> And a last one with a few bugs fixed.  This one also keeps the start of
> the byte dump to the previous aligned 16#B.  It just feels more natural
> to me.
>
> One aspect of this approach that worries me is that there is no visual
> indication of where each field starts/end if poke is built without
> styling support... there ought to be some way to overcome that.  Ideas?

So, fun story, I was wondering why libtextstyle doesn't exist on Arch
Linux and why my poke didn't have styling before: apparently it's
disabled:
  # Do not build libtextstyle, as it depends on libcroco
  # which is now unmaintained and has known security bugs.
  # patch from Fedora
  patch -p1 -i $srcdir/gettext-0.22-disable-libtextstyle.patch
I had to get out Nix to test this one, which was easy enough ^.^
n.b. I wonder if --color=yes should emit a warning if you have a poke
compiled without colour support. I was quite confused earlier having
it not do anything.

Maybe without styling support, it could stick the things below the
lines? At least it's something [could do this with nicer line drawing
characters than I did, ├──┤e.g.].
Algorithm:
- print spans
- go through field by field, place them starting at the first line. if
there's something there already advance a line till there's space.

(poke) dump :val x
76543210  0011 2233 4455 6677 8899 aabb ccdd eeff  0123456789ABCDEF
00000000: 0a0d 0d0a 6000 0000 4d3c 2b1a 0100 0000  ....`...M<+.....
          |-------| |-------| |-------| |--| |--|
          \- typ    \- len    \- byte_order  \- minor
                                        \- major
00000010: ffff ffff ffff ffff 0400 3a00 4564 6974  ..........:.Edit
          |-------|                |-------------
          \- section_len           \- 6=opts
00000020: 6361 7020 2857 6972 6573 6861 726b 2920  cap (Wireshark) 
          ---------------------------------------
00000030: 342e 302e 3520 2847 6974 2076 342e 302e  4.0.5 (Git v4.0.
          ---------------------------------------
00000040: 3520 7061 636b 6167 6564 2061 7320 342e  5 packaged as 4.
          ---------------------------------------
00000050: 302e 352d 3129 0000 0000 0000 6000 0000  0.5-1)......`...
          ----------------------------| |-------|
                                        \- len2

Another idea: make the gutters bigger and use markers in them:

76543210  0011  2233  4455  6677  8899  aabb  ccdd  eeff  0123456789ABCDEF
00000000:<0a0d  0d0a>[6000  0000]«4d3c  2b1a»{0100}<0000> ....`...M<+..... 
<typ> [len] 2=«byte_order» {major} <minor>
00000010:<ffff  ffff  ffff  ffff>[0400  3a00  4564  6974  ..........:.Edit 
<section_len> [6=opts]
00000020: 6361  7020  2857  6972  6573  6861  726b  2920  cap (Wireshark) 
00000030: 342e  302e  3520  2847  6974  2076  342e  302e  4.0.5 (Git v4.0.
00000040: 3520  7061  636b  6167  6564  2061  7320  342e  5 packaged as 4.
00000050: 302e  352d  3129  0000  0000  0000]<6000  0000> 0.5-1)......`... 
<len2>

>
> Will stop now to wait for your feedback :)
>

This honestly looks *really* awesome. I like the format, but I do find
that I sometimes lose track of the structure and types with it. This
might be partially because the terminal I use day to day (I use neovim
:terminal as a terminal multiplexer, because I am weird) doesn't do
hyperlinks, so I haven't tried out that bit yet.

Here's some idle noodling to try to expose more details without
putting too much in: adding braces to try to show the structure,
allowing nested fields to appear. I also stuck the structure type on
top of the first line because there was free space there, and for some
reason I tend to forget the types of things immediately.

76543210  0011 2233 4455 6677 8899 aabb ccdd eeff  0123456789ABCDEF 
(PCAPNG_Shb) {
00000000: 0a0d 0d0a 6000 0000 4d3c 2b1a 0100 0000  ....`...M<+..... typ len 
2=byte_order major minor
00000010: ffff ffff ffff ffff 0400 3a00 4564 6974  ..........:.Edit section_len 
6=opts={ opts[] { typ len value
00000020: 6361 7020 2857 6972 6573 6861 726b 2920  cap (Wireshark) 
00000030: 342e 302e 3520 2847 6974 2076 342e 302e  4.0.5 (Git v4.0.
00000040: 3520 7061 636b 6167 6564 2061 7320 342e  5 packaged as 4.
00000050: 302e 352d 3129 0000 0000 0000 6000 0000  0.5-1)......`... } len2 }

Another thing: it's confusing that the ascii part is red when one
colour of the list is also red. Maybe the ascii part should follow the
colours too, that would actually be quite useful since you can answer
immediately "what's this string".


~Jade



reply via email to

[Prev in Thread] Current Thread [Next in Thread]