111–119 of 119 posts
Earlier quoted context omitted.
What's replacing Jemalloc?
The system malloc implementation. Users who want to use jemalloc have to opt in, but doing so is relatively easy (using the jemallocator crate from crates.io).
Did rust become less dependent on allocator performance, or did system allocators improve enough? IIRC glibc malloc has improved a lot over the last few years, particularly for multithreaded use, but I don't know about windows / macOS.
the author appears to be a true rust master, he wrote quite a few neat programs in rust, very impressive and that actually got me interested in rust lang
Same here, I like small and neat Rust projects like this, the source code is concise and easy to read. He also authors https://github.com/sharkdp/bat , which is also worth to check out.
Earlier quoted context omitted.
The system malloc implementation. Users who want to use jemalloc have to opt in, but doing so is relatively easy (using the jemallocator crate from crates.io).
Why was this done? Did rust become less dependent on allocator performance, or did system allocators improve enough? IIRC glibc malloc has improved a lot over the last few years, particularly for multithreaded use, but I don't know about windows / macOS.
So, now that we have a stable way to let you use jemalloc, the right default for a systems language is to use the system allocator. If jemalloc makes sense for you, you can still use it, but if not, you save a non-significant amount of binary size, which matters to a lot of people. See the parent I originally replied to for an example of a very common response when looking at Rust binary sizes.
It's really more about letting you choose the tradeoff than it is about specific improvements between the allocators.
Earlier quoted context omitted.
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.
https://github.com/sjmulder/hxl
Most of the improvement came from not using printf, fputs, and putchar in favour of operating directly on an array for the line that can be fwritten in one call.
While reading this my hope was it not being written in JavaScript. I'm not disappointed ;)
Yeah! -- Because prejudice rocks and JavaScript sucks right?
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?
Slow compiles have the same effect for me, I get pushed out of flow and into reactive mode.
The only way to write good code is to be proactive, and any features that interfere with that process are worse than whatever "problems" they "solve".
Earlier quoted context omitted.
I'm struggling to even find the canonical source code for xxd, let alone a way to provide a patch. You could probably email the address in the man page, but that's from 1997 so I wouldn't be too optimistic about getting a response. And even then it's quite likely that the original author considers xxd finished and would be reluctant to accept patches for it anyway. On top of all that the hard part of this work (cross…
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.
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.
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.
Eh, A lot of modern terminal emulators don't seem to bother providing termcap/info entries, or setting their own $TERM variables. In reality, most code just fires off ANSI sequences and hopes for the best. Looking quickly at the source for Hexyl, I think that's what the ansi_term library it uses does. If anything, I've found doing this works better then trying to muck around with ncurses, which often gets actively mi…