Live data from Hacker News

Hexyl: A command-line hex viewer

github.com

91–100 of 119 posts

Re: Hexyl: A command-line hex viewer

#91
post #44

Sorry to ask, but what is he use case for a hex viewer like this? What are the kinds of projects you might be working on when you use something like this?

This isn't very common, but I was trying to build a common CLI tool in the browser to use in an internal application at work. I compared output from my implementation with the CLI tool until I got to feature parity (and to clear up confusing things in the spec/source code).

For other things, I've used it for examining network packets (binary protocols), mystery files, and proprietary data formats. I've also used a hex editor to hack executables (most notably hacking in a dark theme into Unity3D).

Re: Hexyl: A command-line hex viewer

#92
post #44

Sorry to ask, but what is he use case for a hex viewer like this? What are the kinds of projects you might be working on when you use something like this?

One (of many) uses I used xxd for: viewing a byte stream that is supposed to be utf-8 text, but the non-ascii characters in the file are not displaying properly. Hex viewers will let you see exactly what bytes are present, without interpretation. As for the utf-8 stream, it turned out to have been double encoded into utf-8.

Re: Hexyl: A command-line hex viewer

#94
post #81

Earlier quoted context omitted.

The same author also wrote hyperfine, a tool to compare performance of various program runs. hyperfine './target/release/hexyl ./target/release/hexyl' 'xxd ./target/release/hexyl' 'hexdump ./target/release/hexyl' Benchmark #1: ./target/release/hexyl ./target/release/hexyl Time (mean ± σ): 1.529 s ± 0.028 s [User: 1.476 s, System: 0.050 s] Range (min … max): 1.491 s … 1.581 s 10 runs Benchmark #2: xxd ./target/release…

... and I have already used hyperfine to benchmark hexyl as well :-) Yes, it's a shame. But I don't think there is too much we can do about it. We have to print much more to the console due to the ANSI escape codes and we also have to do some conditional checks ON EACH BYTE in order to colorize them correctly. Surely there are some ways to speed everything up a little bit, but in the end I don't think its a real issu…

You may be able to speed things up by using a lookup table instead of branching.

(If it's spending a lot of time in Rust's format function you could also use a (or the same) lookup table to convert to hex/dec/oct.)

Re: Hexyl: A command-line hex viewer

#95
post #7

Earlier quoted context omitted.

I have to admit, my first question in mind was how to disable colors because I do not use syntax highlighting at all.

I'm also not a fan of the colouring, especially in this application, because when you're looking at a hexdump chances are you don't care about ASCII or whitespace --- and it's not as if you couldn't tell whether something is in the ASCII range, given the character representation in the right column anyway. The border lines don't help much either and seem more like decoration; addresses to the left and an indexing hea…

How can you tell the difference between an unprintable character and whatever encodes them (I've most often seen '.'), in a single character cell, without color?

Re: Hexyl: A command-line hex viewer

#96

Earlier quoted context omitted.

We have to print much more to the console due to the ANSI escape codes and we also have to do some conditional checks ON EACH BYTE in order to colorize them correctly. A few extra comparisons and output for each byte shouldn't be that much slower; fortunately the function of this program is extremely well-defined, so we can calculate some estimates. Assuming a billion instructions per second, taking ~1.5s to hexdump…

Rust binaries can be large because unlike C, the standard library is statically linked, as well as jemalloc. Jemalloc will no longer be the default as of the next release, so that will shave off ~300k...

What's replacing Jemalloc?

Re: Hexyl: A command-line hex viewer

#97
post #81

Earlier quoted context omitted.

... and I have already used hyperfine to benchmark hexyl as well :-) Yes, it's a shame. But I don't think there is too much we can do about it. We have to print much more to the console due to the ANSI escape codes and we also have to do some conditional checks ON EACH BYTE in order to colorize them correctly. Surely there are some ways to speed everything up a little bit, but in the end I don't think its a real issu…

You may be able to speed things up by using a lookup table instead of branching. (If it's spending a lot of time in Rust's format function you could also use a (or the same) lookup table to convert to hex/dec/oct.)

The format function is going to end up allocating a string for every single byte. That's a huge overhead.

Edit: Turns out to be about 22% overhead, see https://github.com/sharkdp/hexyl/pull/23. Also it was 2 strings per byte, not 1.

Re: Hexyl: A command-line hex viewer

#99
post #39

Earlier quoted context omitted.

Cross-platform terminal coloring was solved in the 1980s with termcap and then terminfo, for every terminal that's even come close to seeing mainstream use and which had colors in the first place. The libraries are part of the ncurses library and are shipped with every OS this stuff would build on to begin with. This also solves the problem of moving the cursor and drawing a screen in general.

termcap/terminfo styling is limited to features like underline, bold and reverse. No coloring, per se.

"man terminfo | grep color" shows that pretty clearly to not be the case. There's plenty of codes for setting colors.
Post reply on HN