158 karma · joined June 30, 2017
Seeing it now the show also has some pretty fun foreshadowing of llm technology like an episode where they anticipate the idea of "ssd streaming" (running a model slower when you don't have enough memory to fit it all at once), at least this is how I interpreted it to make the connection.
And there are many others connections that now can be made thinking about llms vs the machine
Oh and they also anticipated the openai incident where models started using random stuff as external persistent memory across "sessions"
But still this is an awesome project!
I just had to do a little patch to support my iGPU device that is a bit newer than Intel Xe-LP, maybe I'll do a PR.
On a side note the other day I was experimenting with Sonnet 5.5. I gave it the llama cpp repo and told it to extract in a single file inference for a single model + backend (qwen3.5 4b mtp + sycl) and (after a long time) it actually worked! It produced a ~1400 lines file with no deps. I need to check the quality of inference yet but I think this is still a great achievement.
I'm pretty sure 2027 will be a very interesting year for local models and inference.
Instead of coding agents like tool for local models I would like to see more "docker ps" like tools where you can queue up tasks that get processes incrementally (maybe when the pc i idle) and are specialized for doing retries and caching as much work as possible to work decently with slow local models.
https://paper-explorer.aziis98.com/ (also on github https://github.com/aziis98/paper-explorer)
This uses OpenAlex as a source of articles and to let you explore the citation graph of papers. This is still a prototype mostly made to test out how far I could go with vibecoding (well I still checked the code now and then) something without a js framework. Someday I think I will add more features to it, but now there is already a somewhat working version of import/export so I'm fine with it.
This way on the frontend you can lazily load this. Maybe you could even store the HNSW in chunks and just load the pieces you need for your specific search query.
i.e. like https://pagefind.app/ but to get fully static vector search.
I also did some experiments some time ago. The thing this is missing for me is the ability to also run arbitrary commands other that just using a few premade apps. In fact I think this stuff becomes really interesting when you put a real "shell" on top of this.
And I don't mean a classical posix shell, something that can be used to leverage the full power of the custom ui and frontend. Also a must have is "nestable connections".
The experiment I was doing was with a web interface and a statically compiled Go backend (for easy deployment via ssh). Maybe some day I will finish it xD
Still, I would really like to know how you approached this from an architecture perspective. I'm also curious to how much coding agents structured the code like so by themselves or if you had to steer them heavily (I've just tried a bit gemini flash from antigravity cli so I'm a bit behind on this).
Also how did you approach the rendering correspondence with actual tikz code? Do you have some tests that like render the tikz using latex and your js pipeline and compare the result for differences?
What are you using for inference? I have a recent intel laptop with 32GB of DDR5 and I am getting at most 25tps with the llama cpp vulkan backend (that is the fastest, I also tried sycl but it is a bit slower)
The only thing I'm not sure about is if this model supports thinking or not.
https://github.com/aziis98/preact-css-extract
I made this as I couldn't stand writing another 2K lines css file and wanted to try the atomic css wagon without having to switch from preact or having to learn tailwind
But there are benchmark numbers at least, so maybe they only used it for the prose
When dealing with lists there are so many possible ways of updating them (full updates, insertion/removal at an index, update at an index, ...) that manually mounting and unmounting single items by hand gets unbearable. You must then do some kind of diffing at the framework level to get good performance and readable code.
I would like to see "VanillaJS" articles talk both more and more in depth about this problem.
And I'm pretty sure using a GC in some cases it's the only option to not go crazy.
Another thing is that this looks like any other framework out there. I think you can map every one of it's features mostly 1-1 to SolidJS. What is the novelty here? The slightly changed js syntax with "component", "@" and "#"?
I would like to see more radical and new ideas in the js space, expecially in this period. Maybe a new take on Elm to get stronger UI stability guarantees. Or even just some very good tooling to reason about very large reactivity graphs at runtime and (maybe also at) compile time.
That said I still appreciate the work and in particular all the effort spent making the new syntax work in all common editors, I see they support vscode, intellij, sublime, ...
Edit: In the actual documentation they provide an llm.txt https://www.ripplejs.com/llms.txt
Edit: Found it here https://github.com/plby/lean-proofs/blob/main/src/v4.24.0/Er...
Or maybe just make it all a single lispy language
[1]: https://chatgpt.com/share/6941c96c-c160-8005-bea6-c809e58591...
Does somebody know how to correctly prompt the model for these tasks or even better provide some docs? The pictures with the pretty markers are appreciated but that section is a bit vague and without references