errnoh

Joined 14 years ago

Karma
115
Submissions
71
Member since
Jan 25
[ my public key: https://keybase.io/errnoh; my proof: https://keybase.io/errnoh/sigs/RwTFrVzHYvdz-xb9TyP8Ka-VuFUpHO6GsmMqHNRSXQk ]
View on Hacker News

Recent submissions

Comment · 2 years ago
Ah, my bad for not reading the article before the comments :)

As that's the case it's indeed hard to defend it. Data structure-wise it still kind of makes sense since as you mentioned the slice metadata is changed, but it basically making the old slice invalid is rather annoying.

For the := example sure, it's a bit far fetched example and likely would not pass any code review, but there are cases where shadowing is indeed valid. So is the `s := slices.Compact(s)` in this example not working as expected then?

EDIT: looking at another reply to the parent the := being broken likely is trying to point that using := also modifies the slice and thus the original slice is broken when one tries to use it in the original scope. That's really bad practice, but true indeed.

Comment · 2 years ago
Possibly that's mostly out of familiarity with the language? The only thing in your example that does things in-place (and thus looks out-of-place) is Sort(), but that's the way I'd at least expect it to work? If you take that away from the list all of them behave similarly to each other and return the modified slice:

    slices.Compact(s)       // modified slice in the return value is ignored
    s  = slices.Compact(s)  // s now points to the new changed slice
    s := slices.Compact(s)  // s already exists, this is not valid Go syntax.
    slices.Delete(s, …)     // modified slice in the return value is ignored
    s = slices.Delete(s, …) // s now points to the new changed slice

EDIT: Would prefer people not to downvote actual discussion. In this case there were was indeed good argument made on the reply that these also modify the underlying slice, but it's not like I was being rude in the comment.
Comment · 2 years ago
Comment · 2 years ago
At least based on my observations it's been common practice in ML papers for some years already. Usually releasing Github hosted project page and a repository with the same information, then releasing the code on that repo afterwards at some point.

I don't feel that's an issue. A lot more people are able to see what's happening on the bleeding edge than if they'd just release the paper without accompanying demo page, and faster than if they'd wait for the code to be ready for release? Of course one can argue that "they should just release whatever code they have instantly", but that's their choice if they want to clean it up, remove secrets etc.

Comment · 3 years ago
45it/s (0.1~s per image) on 7900XTX here, so it's still one magnitude faster on GPU with a lot higher power draw than the macs. Doing 10x slower with non-tethered is quite nice outcome.
Comment · 3 years ago
While I agree that it's much more effort to get things working on AMD cards than it is with Nvidia, I was a bit surprised to see this comment mention Whisper being an example of "5-10x as performant".

https://www.tomshardware.com/news/whisper-audio-transcriptio... is a good example of Nvidia having no excuses being double the price when it comes to Whisper inference, with 7900XTX being directly comparable with 4080, albeit with higher power draw. To be fair it's not using ROCm but Direct3D 11, but for performance/price arguments sake that detail is not relevant.

EDIT: Also using CTranslate2 as an example is not great as it's actually a good showcase why ROCm is so far behind CUDA: It's all about adapting the tech and getting the popular libraries to support it. Things usually get implemented in CUDA first and then would need additional effort to add ROCm support that projects with low amount of (possibly hobbyist) maintainers might not have available. There's even an issue in CTranslate2 where they clearly state no-one is working to get ROCm supported in the library. ( https://github.com/OpenNMT/CTranslate2/issues/1072#issuecomm... )

Comment · 3 years ago
Comment · 6 years ago
I was planning on mentioning Zoom as well. The Linux client especially is insanely bad, iirc it also drew itself on top of everything.

My suggestion on Linux at least is to use the web client. Just get the url, do a 's#/j/#/wc/join/#' to it and open it in browser of your choice. You'll need to copy the password manually, sometimes it might require captcha etc, but at least it's somewhat usable.

Comment · 6 years ago
Can't speak for everyone, but since pretty much everyone seems to have unlimited data and the speeds aren't that bad the consumer behavior probably doesn't change at all if you're on wifi or not.

That said, 35GB average still seems rather high. I'm interested how much I'm using, but I only have usage data from the past four months and those months aren't really that representative of what I would call normal use.

Comment · 6 years ago
By using only basic functionality that's easy enough to remember I guess I'd go with something like

`echo -e "foo bar baz" | tr -s ' ' | rev | cut -d ' ' -f 1-2 | rev | awk '{print $2 " " $1}`

Everything except the awk part is something that I use all the time and is easy to type & remember.

To be honest I'd use `choose` if it was available everywhere, but for string manipulation I can't justify using nonstandard tools since they aren't always available.

Every now and then there are some new ones I actually start to use. For example `ripgrep` mostly replaced `grep -R` for me some time ago, a lot of it has to do with the fact that if `rg` is not found I can fallback to normal grep and get the same result, just a bit slower.

I guess my point is that while I do appreciate innovation & making better tooling, the hard part always is getting the tool where it's most needed.

Comment · 6 years ago
Color me interested. I've been wanting to use IPFS for similar use case but there's always something that annoys me or documentation that's lacking.

While reading Hyperdrive/Hyperswarm docs I actually managed to find everything I wanted to know without much effort (most of all it seems like setting up this on private network should be doable)

Comment · 6 years ago
Oh, there are kindred spirits here. I've recommended this on other tab-related discussions but Tab Stats is one of the few Firefox addons that have been worth using as a tab hoarder. Allows me to see which pages are open in multiple tabs and then deduplicate them if needed, or just looking at (or closing) open tabs based on domain.

(I'm not affiliated with the creator and it's not without its own annoyances, but still easily recommendable to anyone with thousands of tabs open)

Comment · 6 years ago
Decided to try this out.

The instructions are mostly up-to-date, main thing that has changed seems to be that the multiple inboxes option is now under Settings->Inbox->Inbox type->Multiple Inboxes

Comment · 6 years ago
I think my tabs mostly belong to one of two categories:

* Research about a subject (that I didn't close when I continued to the next one)

* "Oh that's interesting, I'll read it later"

I do remember that 10+ years ago I used to have a nice collection of bookmarks, each with relevant tags. Then one day I had to switch browsers due to performance issues, the new browser didn't support tags from the previous one so lost everything. Ended up just keeping tabs open after that and every now and then I just go through them until 500 or so remain.

For the "read it later" scenario I'm aware that there are a lot of services that try to solve that problem, none that I've tried just seem to fit my workflow.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton