HN user
http://eastfarthing.com/blog/
andrew at $DOMAIN
I've seen that sort of thing before - I told it I was going to go take lunch or dinner, and it told itself this would be a great opportunity to try to keep plugging along while I was AFK.
Once on a late-night session, I had Cline!Claude spontaneously point out the time to me and suggest that I get to bed and come back fresh the next day.
I don't think it's in the system prompt, but that the harnesses time-stamp each turn in the context.
And from what I've seen, they also include the current and max context, so that the model can decide whether to continue work, suggest compaction, or prefer actions that might reduce the growth of its context.
I became a fan of Kaitai Struct [0] when doing some amateur sleuthing last year. It has a web-based IDE [1] for writing and testing structure definitions against hex dumps, and can generate binary parsers in Python (and many other languages) right from the Web IDE.
Off topic, but that photo is amazing, and got a good laugh out of me. It definitely falls in the "pets and owners who look alike" category.
I do like that general idea. I bet it would be possible wrap in a handy elisp macro.
Yep. `C-h k` to look up what a key does, `C-h f` to look up a function, and `C-h v` to look up a variable/setting will get you pretty far.
I'd also add `C-h b` to show you the key bindings. (And `C-h` after a prefix key will usually show you the bindings that start with that prefix.) `C-h a` for apropos to search commands by substring can also be useful.
The thing that makes it really "self documenting" is that these help commands reflect the live environment at the moment you use it. If you've added a new binding in your init.el, `C-h b` and `C-h k` will show it. If you've added a new function in your init.el, or loaded a custom package, all those functions can now be found via `C-h f`. The help system will show you the doc strings for them and provide hyperlinks right to the source.
Moreover, this works for anything that you define on the fly. Open an Emacs lisp buffer, type some elisp code to define a function or variable, execute the definition, and now it'll appear under the above in the help system the next time you invoke help.
The only problem is that, in the name of not breaking backwards-compatibility (or something like that), the archaic defaults have remained.
As a user since '97, I've often felt that this philosophy is entirely, well, backwards. I know how to read the release notes to learn of such changes and how to edit my personal init.el file to revert a setting if I don't like the new default. As long as no one takes away the option, the default doesn't really matter too much to me. But newcomers who might not yet be comfortable with editing their init.el files could really benefit from a more optimal out-of-box experience.
(And besides that, often the newer option is something that I've already moved on to, so making it the new default means I can now remove it from my init.el. I always enjoy when I discover that I can cut something from my init.el because it's now in base Emacs.)
On the other hand, crafts like knitting and other fiber arts can be very repetitive and people still enjoy them.
(Personally, I've also enjoyed unit origami, which involves folding the same module many times over and assembling them.)
I loved the keyboard on my HP-48G. It had such a nice crisp tactile feel to the key presses - a bit of snap - that I got to where it could usually operate it by touch without looking.
(These days it's stored safely away with batteries removed, so I don't use it that much anymore. For convenience, I usually just use either Droid48 on my phone, or Emacs Calc at my computers.)
I had that experience with the last house we rented before we bought.
We were quiet, predictable, don't-rock-the-boat tenants, and the rando owner mentioned that they valued that enough that raising rents wasn't worth the potential risk of new tenants who might cause them more hassle.
Yes, I get that and meant to imply it with "frontier". But my question was more about how my biggest uses by far of data center-provided AI in terms of tokens have been in things like experimenting with agentic coding on my desktops. If I'm just tapping away at my phone with some questions in a chat window, my AI needs are much lower. Compete with me for the HW resources that I need to make full use of your data center-provided AI supply, and I'll just drop my demand accordingly.
(I know, I know... the answer is probably that they expect me to just move my software development to the cloud, too. Joy!)
Analogous to that, this is something that I'd been wondering about with respect to hardware prices as silicon is reallocated from consumers to data centers: how am I to make heavy use of frontier (edit: i.e., cloud/data center-provided) AI models if I can't easily buy a machine worth using it on?
I'm reminded of The Hobbit with the phrase "Good morning" in the first chapter:
"Good Morning!" said Bilbo, and he meant it. The sun was shining, and the grass was very green. But Gandalf looked at him from under long bushy eyebrows that stuck out further than the brim of his shady hat.
"What do you mean?" he said. "Do you wish me a good morning, or mean that it is a good morning whether I want it or not; or that you feel good this morning; or that it is a morning to be good on?"
"All of them at once," said Bilbo. "And a very fine morning for a pipe of tobacco out of doors, into the bargain.
From the linked post, it didn't read like a separate KV cache was needed:
The draft models seamlessly utilize the target model's activations and share its KV cache, meaning they don't have to waste time recalculating context the larger model has already figured out.
Ah. We're back to the days of Emacs' old `M-x psychoanalyze-pinhead`, then. (Psychoanalyze-pinhead ran the Eliza chat-bot and fed it bizarre quotations collected from the Zippy the Pinhead comics.)
Or better yet, pitting Eliza vs. Parry (https://logic.stanford.edu/complaw/readings/elizaandparry.pd...), where Parry was meant to simulate a paranoid schizophrenic. That was 1973, more than 50 years ago.
Everything old is new again.
At least for the CPU/GPU split, llama.cpp recently added a `--fit` parameter (might default to on now?) that pairs with a `--fitc CONTEXTSIZE` parameter. That new feature will automatically look at your available VRAM and try to figure out a good CPU/GPU split for large models that leaves enough room for the context size that you request.
From my recollection of doing fun palette stuff back in the DOS VGA days, I'm betting it was more like:
pal.r = pal.g = pal.b = (77 * pal.r + 150 * pal.g + 29 * pal.b) >> 8;
I think the point the GP was trying to make is that the GitHub UI ought to be able to allow you to submit a branch with multiple well-organized commits and review each commit separately with its own PR. The curation of the commits that you'd do for stacked PRs could just as easily be done with commits on a single branch; some of us don't just toss random WIP and fixup commits on a branch and leave it to GitHub to squash at the end. I.e., it's the GitHub UI rather than Git that has been lacking.
(FWIW, I'm dealing with this sort of thing at work right now - working on a complex branch, rewriting history to keep it as a sequence of clean testable and reviewable commits, with a plan to split them out to individual PRs when I finish.)
Cave Johnson here. I'll be honest, we're throwing science at the wall here to see what sticks. No idea what it'll do. Probably nothing. Best-case scenario, you might get some superpowers.
I've been using the 1M window at work through our enterprise plan as I'm beginning to adopt AI in my development workflow (via Cline). It seems to have been holding up pretty well until about 700k+. Sometimes it would continue to do okay past that, sometimes it started getting a bit dumb around there.
(Note that I'm using it in more of a hands-on pair-programming mode, and not in a fully-automated vibecoding mode.)
My take as a graphics programmer is that angles are perfectly fine as inputs. Bring 'em! And we'll use the trig to turn those into matrices/quaternions/whatever to do the linear algebra. Not a problem.
I'm a trig-avoider too, but see it more as about not wiggling back and forth. You don't want to be computing angle -> linear algebra -> angle -> linear algebra... (I.e., once you've computed derived values from angles, you can usually stay in the derived values realm.)
Pro-tip I once learned from Eric Haines (https://erich.realtimerendering.com/) at a conference: angles should be represented in degrees until you have to convert them to radians to do the trig. That way, user-friendly angles like 90, 45, 30, 60, 180 are all exact and you can add and subtract and multiply them without floating-point drift. I.e., 90.0f is exactly representable in FP32, pi/2 is not. 1000 full revolutions of 360.0f degrees is exact, 1000 full revolutions of float(2*pi) is not.
Author here. I have a JavaScript port of my automated test suite (https://github.com/a-e-k/canvas_ity/blob/main/test/test.html) that I used to compare my library against browser <canvas> implementations. I was surprised by all of the browser quirks that I found!
But compiling to WASM and running side-by-side on that page is definitely something that I've thought about to make the comparison easier. (For now, I just have my test suite write out PNGs and compare them in an image viewer split-screen with the browser.)
Author here. There's no AI-generated code in this. But yes, security hardening this has not been a priority of mine (though I do have some ideas about fuzz testing it), so for now - like with many small libraries of this nature - it's convenient but best used only with trusted inputs if that's a concern.
Author here. No vibe-coding, all human-written. Are you thinking of my use of GitHub emoji on the section headings in the README? I just found they helped my eye pick out the headings a little more easily and I'd seen some other nice READMEs at the time do that sort of thing when I went looking for examples to pattern it off of. I swear I'd had no idea it would become an LLM thing!
Author here. What a pleasant surprise to see this trending on the front page!
(I did post a Show HN at the time of the original release, https://news.ycombinator.com/item?id=33148540, but it never gained traction.)
Just to answer some comments that I see:
1. This was absolutely not vibecoded!
I'd originally started with a different version control system and was still getting used to Git and GitHub at the time that I'd released this. (I was a latecomer to Git just because I hated the CLI so much.) It was easiest for me just to drop the whole thing as a snapshot in a single commit.
But my private repo for it actually started in May 2017, and it had 320 commits leading up to its release, all human-written.
For the v2.0 that I have in mind, I'm thinking of force-pushing to migrate the full development history to the public repo.
And finally I'll add that I'm a graphics engineer by education and career. Where would the fun be in vibe-coding this? :-) Oh, and this compiles down to just ~36KiB of object code on x86-64 last I checked. Good luck vibe-coding that constraint.
2. Why a single header with `#define CANVAS_ITY_IMPLEMENTATION`?
I was inspired by the STB header ibraries (https://github.com/nothings/stb) and by libraries inspired by those, all of which I've found very convenient. In particular, I like their convenience for small utilities written in a single .cpp file where I can just `g++ -O3 -o prog prog.cpp` or such to compile without even bothering with a makefile or CMake.
Since the implementation here is all within a single #ifdef block, I had figured that anyone who truly preferred separate .cpp and .h files could easily split it themselves in just a few minutes.
But anyway, I thought this would be a fun way of "giving back" to the STB header ecosystem and filling what looked to me like an obvious gap among the available header libraries. It started as something that I'd wished I'd had before, for doing some lightweight drawing on top of images, and it just kind of grew from there. (Yes, there was Skia and Cairo, but both seemed way heavier weight than they ought to be, and even just building Skia was an annoying chore.)
----
Since I mentioned a v2.0, I do have a roadmap in mind with a few things for it: beside the small upgrades mentioned in the GitHub issues to support parts of newer <canvas> API specs (alternate fill rules, conic gradients, elliptical arcs, round rectangles) and text kerning, I'm thinking about porting it to a newer C++ standard such as C++20 (I intentionally limited v1.0 to C++03 so that it could be used in as many places as possible), possibly including a small optional library on top of it to parse and rasterize a subset of SVG, and an optional Python binding.
Not to mention if that if somebody needs to come over, the proper thing to do is signal first. Then I'm happy to politely ease off a bit and open more space for them to come over safely.
It's the people who aggressively slide right over just a few feet in front of me (cutting off nearly all of my safety buffer) without so much as a signal that really drive me nuts.
I spent over a decade developing rendering software used in VFX, and ran CentOS Linux as my development platform at work.
We tried to follow the VFX reference platform once that became a thing back in 2014.
When the Unsloth quant of the flash model does appear, it should show up as unsloth/... on this page:
https://huggingface.co/models?other=base_model:quantized:zai...
Probably as:
In the words of Mr. Plinkett, regarding certain movie details: "Some so subtle you might not have noticed. But your brain did." (https://www.youtube.com/watch?v=RqYx0cqy0WA&t=1266s)
I'd also argue that it's much like movie editing: you tend to only notice it when it's crappy.
I've never been to EGSR. Possibly SIGGRAPH?