leeoniya

6 ms·

1.
by leeoniya 25d ago
i also tapped out quickly. how many times can you describe the same thing? Claude: "Hold my beer."
2.
by leeoniya 1mo ago
> The one shown in Wikipedia is mine. neat! https://upload.wikimedia.org/wikipedia/commons/e/e3/Pen_Regi... assuming you still have it, it wouldn't be the worst idea to update the pic to somethin
3.
by leeoniya 1mo ago
It's possible to do a large amount of AI-assisted work, then do a second/third/fourth pass to break it up into a reviewable stack of self-contained PRs. But it takes time, and there's no such thing as one-shotting it. An
4.
by leeoniya 1mo ago
i've always been impressed by NBA*: https://github.com/anvaka/ngraph.path demo: https://anvaka.github.io/ngraph.path.demo/
5.
Show HN: easy-tz – A fast, 10KB, dependency-free getTimeZonesAt(timestamp)(github.com)
2 points by leeoniya 2mo ago|0 comments
6.
by leeoniya 3mo ago
so, Your Attention is All They Need?
7.
by leeoniya 4mo ago
or was it Windows hiding file extensions by default and you downloaded a .mp3.exe file?
8.
by leeoniya 4mo ago
surprised not to see http://phpsadness.com/ here
9.
by leeoniya 4mo ago
the term "Americans" always bothered me, though it's commonly used to refer to US
10.
by leeoniya 4mo ago
> "no no, it has full test coverage" i don't have enough fingers (and toes) to count how many times i've demonstrated that "100% coverage" is almost universally bullshit.
11.
by leeoniya 4mo ago
if you want to do image diffing, use https://github.com/dmtrKovalenko/odiff however, if you have SVGs already, compare those without rasterizing them first, then if that fails rasterize & odiff the baseline and new
12.
by leeoniya 5mo ago
Levenshtein distance is often a poor way to fuzzy match or rank. i suspect that in js, even the trie approach would incur significant GC/alloc thrashing or cost of building a huge trie index. i tried fuzzy matching using a cleverly-ass
13.
by leeoniya 5mo ago
> Sen. Sheldon Whitehouse ok, i was confused for a minute. > And, given that the gas breaks down relatively quickly, this would have been one of the fastest ways to reduce global warming. s/quickly/slowly?
14.
by leeoniya 6mo ago
> for a 2–3% performance gain this is highly workload-dependent. there are plenty of APIs that are multiple-factor faster and 10x more memory efficient due to native implementation.
15.
by leeoniya 6mo ago
ack, see my reply to sibling comment: https://news.ycombinator.com/item?id=47572206
16.
by leeoniya 6mo ago
no disagreement. i never claimed uWrap did anything more than it does. it was not meant for typography/text-layout but for line count estimation. it never needed to be perfect, and i did not claim equivalence to pretext. however, for t
17.
by leeoniya 6mo ago
i don't have a mac to test this with currently, so hopefully it's not the price but a matter of adding a Safari-specific adjustement :) internally it still uses the Canvas measureText() API, so there's nothing fundamentally t
18.
by leeoniya 6mo ago
tried just doing a concat of the 100k sentences with line breaks, it wasnt much faster, ~1880ms.
19.
by leeoniya 6mo ago
it is not clear from the API/docs how i would use prepare() once on one text and then use layout() for completely different text. i think the intended purpose is that your text is maybe large but static and your layout just changes qui
20.
by leeoniya 6mo ago
correct, it was meant for estimating row height for virtualizing a 100k row table with a latin-ish LTR charset (no emoji handling, etc). its scope is much narrower. still, the difference in perf is significant, which i have found to be true
21.
by leeoniya 6mo ago
i wrote something similar for this purpose, but much simpler and in 2kb, without AI, about a year ago. uWrap.js: https://news.ycombinator.com/item?id=43583478 . it did not reach 11k stars overnight, tho :D for ASCII text,
22.
by leeoniya 6mo ago
just throw another few on the pile: https://mastodon.social/@azureshit
23.
by leeoniya 7mo ago
the good ones would usually follow up with, "how much detail do you _really_ want ;D"
24.
by leeoniya 7mo ago
i used something like this in unstructured technical interviews all the time. "you type a phrase into google search, you press enter, get some results. tell me, in technical detail, what happened in that chain of actions" the dive
25.
by leeoniya 8mo ago
hey! > But regarding sampling, if it's a line chart, you can sample adaptively by checking whether the next point makes a meaningfully visible difference measured in pixels compared to its neighbours. uPlot basically does this (see
26.
by leeoniya 8mo ago
> In Ardour (a cross-platform, libre, open source DAW), we actually compute and store min/max-per-N-samples and use that for plotting (and as the basis for further downsampling. this is, effectively, what uPlot does, too: https:&#x
27.
by leeoniya 8mo ago
yw!
28.
by leeoniya 8mo ago
agreed, heatmaps with logarithmic cell intensity are the way to go for massive datasets in things like 10,000-series line charts and scatter plots. you can generally drill downward from these, as needed.
29.
by leeoniya 8mo ago
uPlot maintainer here. this looks interesting, i'll do a deeper dive soon :) some notes from a very brief look at the 1M demo: - sampling has a risk of eliminating important peaks, uPlot does not do it, so for apples-to-apples perf com
30.
by leeoniya 8mo ago
related: i had to jump through the Date hoops recently (again) when rewriting uPlot's DST and timezone handling, but i'm pretty happy with the result that avoided much complexity, performance loss, and adding a dependency: https:

More ›