Live data from Hacker News

Hexyl: A command-line hex viewer

github.com

71–80 of 119 posts

Re: Hexyl: A command-line hex viewer

#71
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.

Me neither. I did use it religiously for a long, long time; then tried without for a week and never went back. It's not like telling the difference between string literals and keywords was ever a major issue for me. I guess it could help short term when learning a new language, but I'm pretty sure it slows down overall progress.

How does it slow down progress?

Re: Hexyl: A command-line hex viewer

#74
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.

Aren't termcap and terminfo linux (or maybe unix) only?

termcap is supported on FreeBSD, at the least.

Re: Hexyl: A command-line hex viewer

#75

Earlier quoted context omitted.

Me neither. I did use it religiously for a long, long time; then tried without for a week and never went back. It's not like telling the difference between string literals and keywords was ever a major issue for me. I guess it could help short term when learning a new language, but I'm pretty sure it slows down overall progress.

How does it slow down progress?

For me it doesn't. It's a quick way to see that I made a typo when a keyword doesn't turn the right color, or that I closed a strong with the wrong quote Mark.

Re: Hexyl: A command-line hex viewer

#77
post #53

Earlier quoted context omitted.

Your lab manager goes "hey, can you generate these proprietary binary files (currently made with a horrible gui) to control this robot programmatically".

But shouldn't one use an editor, like vim, in those cases?

Uh, vim doesn't open binary files very well, and the initial goal is to just display them to figure out how they work not to edit them.

Afterwards you will probably want to run experiments with a hex editor, but I found that xxd + vim was better for reading then doing so directly in a hex editor at the time. If I did it again I'd likely start with this because of the color.

Re: Hexyl: A command-line hex viewer

#78
post #3

I admit, my first thought on seeing the title was "What's wrong with xxd?" This is nice! I like the colorization a lot -- it's like with source code, you don't realize how much you rely on the colors until you get a new computer and need to download syntax definitions for your editor again. Only feature I really think is missing is line numbers. Nicely done!

Since back in my DOS programming days, I've lived in several different Hex editors when analysing data streams. Some great, some ordinary. I would have killed for colour highlighting like Hexyl seems to have.

I wonder though, whether I can colour code 'blocks' to differentiate them? One of the things I seemed to do a lot in hex editors was to check out the differentiation in, for example, 72 byte blocks of data, so to be able to delineate 72 byte blocks in different colours in the hex editor would make it easier to see where each block starts/ends.

Re: Hexyl: A command-line hex viewer

#79
post #6

While reading this my hope was it not being written in JavaScript. I'm not disappointed ;)

It's comparably slow though :p xxd `which hexyl` > /dev/null 0.12s user 0.09s system 99% cpu 0.219 total hexdump `which hexyl` > /dev/null 0.19s user 0.05s system 91% cpu 0.256 total hexyl `which hexyl` > /dev/null 1.69s user 0.39s system 95% cpu 2.175 total

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/hexyl
      Time (mean ± σ):      70.5 ms ±   0.5 ms    [User: 68.0 ms, System: 1.2 ms]
      Range (min … max):    69.5 ms …  72.3 ms    41 runs

    Benchmark #3: hexdump ./target/release/hexyl
      Time (mean ± σ):     262.4 ms ±   2.8 ms    [User: 260.1 ms, System: 1.5 ms]
      Range (min … max):   259.8 ms … 268.8 ms    11 runs

    Summary
      'xxd ./target/release/hexyl' ran
        3.72 ± 0.05 times faster than 'hexdump ./target/release/hexyl'
       21.70 ± 0.43 times faster than './target/release/hexyl ./target/release/hexyl'
Currently hexyl seems nearly 22x slower than xxd.

Re: Hexyl: A command-line hex viewer

#80
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.

Aren't termcap and terminfo linux (or maybe unix) only?

Both of them long predate Linux. They're definitely Unix-flavored, but so's the Berkeley sockets library, and that's available everywhere, too. Ultimately, they're a library which is packaged with a database, and nothing about them is very system-specific except the terminal information in the database.

https://en.wikipedia.org/wiki/Terminfo

Post reply on HN