Bun.Image
bun.com
Bun.Image
1–10 of 16 posts
Re: Bun.Image
#2(https://sharp.pixelplumbing.com/)
Good! I like the pipeline workflow.
Re: Bun.Image
#3Re: Bun.Image
#4Re: Bun.Image
#5---------------
Pre-empting the "how can you tell", here's some of the tells.
> The API is shaped after Sharp:
Constantly using "shaped" and "shape" is becoming an LLM-ism, much more common than in human writing.
> The constructor accepts a path, bytes, or a Blob — including Bun.file() and Bun.s3().
> The format is sniffed from the bytes — extensions and Content-Type are ignored.
Repeatedly formatting statements as X: Y, X — Y, or [b]X[b] Y is also an LLM-ism.
> Don’t pass user-controlled strings directly to the constructor — that’s an arbitrary-file-read primitive.
> When passing a TypedArray/ArrayBuffer, don’t mutate it while a terminal is pending — decode runs off-thread and borrows the bytes.
Doing so by leading with what-it's-not / what-not-to-do is even more of an LLM-ism.
Re: Bun.Image
#6It's not like image manipulation is a poorly understood problem or a fast-moving field.
Re: Bun.Image
#7This looks like one of the better pieces of LLM-output documentation I've seen. It's bad technical writing, but better than most of what I've seen come out of an LLM. --------------- Pre-empting the "how can you tell", here's some of the tells. > The API is shaped after Sharp: Constantly using "shaped" and "shape" is becoming an LLM-ism, much more common than in human writing. > The constructor accepts a path, bytes,…
For agent written code I now default to no documentation and explanatory function signatures, it works better for me at least.
Re: Bun.Image
#8This looks like one of the better pieces of LLM-output documentation I've seen. It's bad technical writing, but better than most of what I've seen come out of an LLM. --------------- Pre-empting the "how can you tell", here's some of the tells. > The API is shaped after Sharp: Constantly using "shaped" and "shape" is becoming an LLM-ism, much more common than in human writing. > The constructor accepts a path, bytes,…
The other big problem with LLM documentation is that it tends to drift from the code, because agents forget to update it. Then later agents sometimes reference the documentation, sometimes reference the code, and get confused. For agent written code I now default to no documentation and explanatory function signatures, it works better for me at least.
Re: Bun.Image
#9Glad to see that Bun is doing something that Java has been doing since 1998.
Re: Bun.Image
#10This looks like one of the better pieces of LLM-output documentation I've seen. It's bad technical writing, but better than most of what I've seen come out of an LLM. --------------- Pre-empting the "how can you tell", here's some of the tells. > The API is shaped after Sharp: Constantly using "shaped" and "shape" is becoming an LLM-ism, much more common than in human writing. > The constructor accepts a path, bytes,…
The other big problem with LLM documentation is that it tends to drift from the code, because agents forget to update it. Then later agents sometimes reference the documentation, sometimes reference the code, and get confused. For agent written code I now default to no documentation and explanatory function signatures, it works better for me at least.