Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

options: add "-o base=2" #703

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Conversation

mikez
Copy link
Contributor

@mikez mikez commented Jun 14, 2023

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.

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.
@mikez mikez mentioned this pull request Jun 14, 2023
@wader
Copy link
Owner

wader commented Jun 14, 2023

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
Copy link
Owner

wader commented Jun 14, 2023

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

@mikez
Copy link
Contributor Author

mikez commented Jun 14, 2023

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
Copy link
Owner

wader commented Jun 14, 2023

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
Copy link
Contributor Author

mikez commented Jun 14, 2023

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

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

image

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
Copy link
Contributor Author

mikez commented Jun 15, 2023

Some options. I like D most.

image

@mikez
Copy link
Contributor Author

mikez commented Jun 15, 2023

make test passes locally now.

@wader
Copy link
Owner

wader commented Jun 15, 2023

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
Copy link
Contributor Author

mikez commented Jun 15, 2023

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
Copy link
Owner

wader commented Jun 15, 2023

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.

🥳

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants