leeoniya

i also tapped out quickly. how many times can you describe the same thing?

Claude: "Hold my beer."

> 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 something without chromatic aberration and motion blur. the wiki pic is probably the worst of the bunch compared to others on google image search :)

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. And it's basically impossible to continuously rebase manually without burning tokens. The way to merge the stack is more-or-less "stop the world".

However, I have yet to see how this will play out with upstream contribs:

https://github.com/moment/luxon/discussions/1796

https://github.com/leeoniya/luxon/tree/leeoniya/perf-patches...

i've always been impressed by NBA*: https://github.com/anvaka/ngraph.path

demo: https://anvaka.github.io/ngraph.path.demo/

so, Your Attention is All They Need?

or was it Windows hiding file extensions by default and you downloaded a .mp3.exe file?

surprised not to see http://phpsadness.com/ here

the term "Americans" always bothered me, though it's commonly used to refer to US

> "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.

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 on-demand. this way you dont waste a ton of space storing a bunch of binary [possibly evolving] pngs in git.

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-assembled regexp approach which works surprisingly well: https://github.com/leeoniya/uFuzzy

> 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?

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

ack, see my reply to sibling comment: https://news.ycombinator.com/item?id=47572206

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 the use case of virtualization of data tables -- a use case pretext is also targeted at -- and in the common case of latin alphabets, right now pretext is significantly slower. i hope that it can become faster despite its much more thorough support for "rest of the owl".

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 that should differ unless Safari has broken measureText, which tbh, would not be out of character for that browser.

tried just doing a concat of the 100k sentences with line breaks, it wasnt much faster, ~1880ms.

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 quickly. this is not the case for figuring out the height of 100k rows of different texts in a table, for example.

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 in general of AI-generated geenfield code.

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, mine finishes in 80ms, and pretext takes 2200ms. i haven't yet checked pretext for accuracy (how closely it matches the browser), but will test tonight.

let's see how close pretext can get to 80ms (or better) without adopting my algorithm / caching strategy.

https://github.com/chenglou/pretext/issues/18

there are already significant performance improvement PRs open right now, including one done using autoresearch.

just throw another few on the pile:

https://mastodon.social/@azureshit

the good ones would usually follow up with, "how much detail do you _really_ want ;D"

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 diversity of replies is fascinating, you learn a lot about a "full stack" candidate this way.

Feynman's classic "Why?" chain: https://www.youtube.com/watch?v=36GT2zI8lVA

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 sibling comment), so hopefully that's some validation for you :)

> 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://github.com/leeoniya/uPlot/issues/1119

yw!

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.

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 comparison you have to turn that off. see https://github.com/leeoniya/uPlot/pull/1025 for more details on the drawbacks of LTTB

- when doing nothing / idle, there is significant cpu being used, while canvas-based solutions will use zero cpu when the chart is not actively being updated (with new data or scale limits). i think this can probably be resolved in the WebGPU case with some additional code that pauses the updates.

- creating multiple charts on the same page with GL (e.g. dashboard) has historically been limited by the fact that Chrome is capped at 16 active GL contexts that can be acquired simultaneously. Plotly finally worked around this by using https://github.com/greggman/virtual-webgl

> data: [[0, 1], [1, 3], [2, 2]]

this data format, unfortunately, necessitates the allocation of millions of tiny arrays. i would suggest switching to a columnar data layout.

uPlot has a 2M datapoint demo here, if interested: https://leeoniya.github.io/uPlot/bench/uPlot-10M.html

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://github.com/leeoniya/uPlot/pull/1072

fun demos: https://leeoniya.github.io/uPlot/demos/timezones-dst.html