options: add "-o base=2"

[mikez]

Add experimental support for base 2 (bits).

For example:
$ fq -o base=2 '.frames[0].header' example.mp3

Also, add various comments to make sense of the dump.go code.

[wader]

I wonder if the header in base 2 should be something like 01234567890123456789....? so bit offset instead of byte offset?

And i apologies for the mess in dump.go, lots of things to keep track of and hard to come up with good names :) and i would like to refactor it into something that "renders" per column somehow, now all is done i one go. That would also prepare for allowing a user to configure columns.

[wader]

Based on the failing tests it seems like some kind of stop bit position etc ends up wrong (too far?) for hex

[mikez]

I wonder if the header in base 2 should be something like 01234567890123456789....? so bit offset instead of byte offset?

Seeing the bit offset address could be nice, especially to do slicing [3:12]-like operations. On the other hand, we have line_bytes, always show a multiple of 8 bits, and I find it helpful to see some sort of 8-bit grid. Maybe the headers could be configurable?

Based on the failing tests it seems like some kind of stop bit position etc ends up wrong (too far?) for hex

I haven't tested this well. I'll take a look.

[wader]

I wonder if the header in base 2 should be something like 01234567890123456789....? so bit offset instead of byte offset?

Seeing the bit offset address could be nice, especially to do slicing [3:12]-like operations. On the other hand, we have line_bytes, always show a multiple of 8 bits, and I find it helpful to see some sort of 8-bit grid. Maybe the headers could be configurable?

Would it look strange to show binary in 8 bit groups somehow? 🤔

Based on the failing tests it seems like some kind of stop bit position etc ends up wrong (too far?) for hex

I haven't tested this well. I'll take a look.

No worries, just so you know why it might show wrong value

About go test there are some tricks you can do for convenience:

# runs only the TestInterp/testdata/hexdump.fqtest test
$ go test -run TestInterp/testdata/hexdump.fqtest ./pkg/interp
# test name is a / separated regexps so you can do
# also -v makes i print nam of tests
$ go test -v -run "TestInterp/testdata/.*\.fqtest" ./pkg/interp
# all tests under TestInterp/testdata/
$ go test -v -run TestInterp/testdata/ ./pkg/interp

Also maybe good to know that fq has kind of two types of go test tests, just normal go tests but then also fqtest files which is a kind of "script" run with command and excepted output. Those tests can be run with the env variable WRITE_ACTUAL=1 to rewrite the fqtest files replacing expected output with current actual output.

[mikez]

Would it look strange to show binary in 8 bit groups somehow? 🤔

I checked HexFiend. It has an option called "Byte Grouping".

Similarly, it also has "line number format" (maybe you have this already?).

Based on the failing tests it seems like some kind of stop bit position etc ends up wrong (too far?) for hex

yes, that was it. I added a missing conditional. It solved most failing tests, but some remain. Maybe you can help me with those?

[mikez]

Some options. I like D most.

[mikez]

make test passes locally now.

[wader]

Sorry for the delay, work and life happening. They all look very nice, hard to decide :)

For variant D+E would it make sense that the line address would be 0x<line offset>+<bit offset in line>? could be confusing otherwise?

Similarly, it also has "line number format" (maybe you have this already?).

Guess that would be addrbase now? but it's also used in some other places for addresses also

yes, that was it. I added a missing conditional. It solved most failing tests, but some remain. Maybe you can help me with those?

Yeap will do

[mikez]

For variant D+E would it make sense that the line address would be 0x<line offset>+<bit offset in line>? could be confusing otherwise?

A mix of hex and decimal offset "feels" confusing to me... :-/
To clarify: could the line address not be a Y-coordinate of kinds? That is, it points to the start address of the field? I'm likely missing something though... what's the benefit of having the same address repeat again and again?
Or... maybe the line addresses could have two different colors... one for the start of the line and one for the field address?

yes, that was it. I added a missing conditional. It solved most failing tests, but some remain. Maybe you can help me with those?

Yeap will do

It seems I fixed the tests (at least the make test ones) with the earlier commit.

[wader]

A mix of hex and decimal offset "feels" confusing to me... :-/ To clarify: could the line address not be a Y-coordinate of kinds? That is, it points to the start address of the field? I'm likely missing something though... what's the benefit of having the same address repeat again and again? Or... maybe the line addresses could have two different colors... one for the start of the line and one for the field address?

Currently it's mostly that addresses are default hex, other things decimal. But yeah showing number of bits in hex maybe is confusing :)

About line address, does it make sense to "offset" for each line if the line address is the field start address? i do like that number base controls that line address is in bits instead of bytes. But i wonder if it should be communicated somehow? 0b-prefix?

Think i will have to play around with this a bit to get a feeling, haven't had much quailty fq-time the last days :)

It seems I fixed the tests (at least the make test ones) with the earlier commit.

🥳