|
From: | Jade Lovelace |
Subject: | [Discussion] Side-by-side dump format |
Date: | Sun, 20 Aug 2023 16:46:11 -0700 |
Hi all, Something I would find really useful while writing pickles and looking at corrupt data is a side-by-side dump format that shows the value level information next to the bytes, to quickly debug where things get misaligned. I noodled around with a particular format of this here (I have also attempted to attach it to this email): https://jade.fyi/poke-dump-demo.html It seems that this mockup is more legible than staring at the information separately, so that is a positive. If Poke were a GUI, I could see this information being most easily used by mousing over the bytes, or clicking them, to go right to the field, sort of analogously to how https://typst.app does their live preview of typesetting. For static display, it is probably best to put the information as close as possible without interrupting the visual flow of the hexdump. An alternate format could perhaps be to put the information under each line of hexdump, but I am a little bit worried that would make it hard to follow which pieces are hexdump and what they correspond to. One challenge that this hits is that I can see it being pretty easy to get too much information in one line. Also, the syntax for byte arrays is a little bit bulky :) The rules I used for producing this were: - A field takes the first colour not yet appearing in that line - That colour is retained across multiple lines if the field spans multiple lines - Arrays of primitives are treated as one item, sub structures are treated as new items for each field inside - The only thing that's considered is things generating bytes, rather than the structure. It may be possible to insert structure markers into the dump though; not sure how feasible that would be. Things that are unclear: - Where to put fields that appear in the bytes out of definition order? Any thoughts on other ways to do this? Regards, Jade
(poke) dump :from x'offset :size x'size :ios x'ios 76543210 0011 2233 4455 6677 8899 aabb ccdd eeff 0123456789ABCDEF 00000000: 0a0d 0d0a 6000 0000 4d3c 2b1a 0100 0000 ....`...M<+..... PCAPNG_Shb { typ=0x0a0d0d0aU, len=0x00000060U#B, byte_order=[0x4dUB,0x3cUB,0x2bUB,0x1aUB], major=0x0001UH, minor=0x0000UH, 00000010: ffff ffff ffff ffff 0400 3a00 4564 6974 ..........:.Edit section_len=0xffffffffffffffffUL, opts=PCAPNG_Options { opts=[PCAPNG_Option { typ=0x0004UH, len=0x003aUH#B, value=[0x45UB,0x64UB,0x69UB,0x74UB, 00000020: 6361 7020 2857 6972 6573 6861 726b 2920 cap (Wireshark) 0x63UB,0x61UB,0x70UB,0x20UB,0x28UB,0x57UB,0x69UB,0x72UB,0x65UB,0x73UB,0x68UB,0x61UB,0x72UB,0x6bUB,0x29UB,0x20UB, 00000030: 342e 302e 3520 2847 6974 2076 342e 302e 4.0.5 (Git v4.0. 0x34UB,0x2eUB,0x30UB,0x2eUB,0x35UB,0x20UB,0x28UB,0x47UB,0x69UB,0x74UB,0x20UB,0x76UB,0x34UB,0x2eUB,0x30UB,0x2eUB, 00000040: 3520 7061 636b 6167 6564 2061 7320 342e 5 packaged as 4. 0x35UB,0x20UB,0x70UB,0x61UB,0x63UB,0x6bUB,0x61UB,0x67UB,0x65UB,0x64UB,0x20UB,0x61UB,0x73UB,0x20UB,0x34UB,0x2eUB, 00000050: 302e 352d 3129 0000 0000 0000 6000 0000 0.5-1)......`... 0x30UB,0x2eUB,0x35UB,0x2dUB,0x31UB,0x29UB], padding=[0x00UB,0x00UB] }], endofopt=[0x00UB,0x00UB,0x00UB,0x00UB] }, len2=0x00000060U#B, assertion=[] } |
[Prev in Thread] | Current Thread | [Next in Thread] |