Clojurians Log v2

FYI @clojurians115 aider is crazy good. Super token hungry though

@bbloom That's good feedback. I was happy to find the web components model because in other standards, especially GC, it is explicitly stated that language interop is not within scope. That leaves a lot of space for different data structure layouts and calling conventions. The high level docs on web components seemed like a reasonable attempt to add metadata/glue to be able to cross those boundaries. I probably stopped reading before getting into the weeds.

@john Yep. aider is definitely impressive. I'm glad I tried aider a couple of days ago because today I see that Anthropic has release https://www.anthropic.com/news/model-context-protocol I probably wouldn't have gone through setting up a API account (why are they completely separate?) because MCP can be used directly with Claude.

Yeah, aider ought'a benefit from MCP. And having a lot of training data on a single protocol will likely benefit all open source models too. Especially smaller models that can't necessarily hack in a shell that well. But for more powerful models, I'd imagine there's nothing MCP can provide that the model couldn't just get done in bash. The human interface is the protocol for them IMO. If it makes super small LLMs a lot more useful though that'd be a big win. There's a valid sandboxing / security argument in favor of MCP too, for some use cases

One of the main benefits I see of things like MCP is more fine grained security, privacy, multi-tenancy control. You give it bash and it can do, well, anything you can do in bash.

Right, it can be more secure in some ways

Having a local llm, that is 100% private, mitigates some risk, by some risk models, if you don't trust the inf provider. qwen2.5-coder:0.5B is super fast and can almost operate aider efficiently. But if you don't trust open source models that's a different risk model. Yeah, hmm, so many different usecases with different tradeoffs

With standardization on MCP and tools like aider, future small models trained up on them will be way more productive, I bet

marco-o1 is also an interesting new open model that tries to do longer test-time inf like the new openai o1 models

IIRC some folks were very mad about the component proposal

From the web folks https://www.assemblyscript.org/standards-objections.html

@john thanks. Interesting reading. I wasn't previously aware of that disagreement.

Yeah, pretty wild. Looks like the wasmgc proposal didn't have as much disagreement and controversy, fortunately

@john true, wasmgc seems pretty solid (although definitely MVP in terms of ergonomics and efficiency from my reading and playing with it).

@clojurians115 Q about what you said here: Create babashka program to extract ENBF from wasm spec Is the EBNF stuff just for conformance testing the wam impl?

Or is that somehow part of implementing it? I remember you had that auto-gen-code-based-on-ebnf thing

@john Heh, good questions (and apparently you're watching my github pushes 😄 since I haven't actually posted that here). I want to convert my wam tool from JS to Clojure/babashka. And instead of a half-baked hand-coded parser, I want it to actually be based on the spec. wam is intended to be a superset of wat with some conveniences/macros/sugar to make writing "wat" by hand less annoying. I don't necessarily want wam to be in the the final Clojure wasm toolchain/pipeline, but I think it will be a useful interim tool (at least for my own learning process if nothing else). But once I have an parser grammar for wat, then, yes, I can feed it into instacheck and generate bogus but well formed wat tests where that's useful. It probably won't be that useful for testing wam itself because I intend to use the same grammar/parser in wam itself. But could definitely be used for generatively testing other wat tools.

@john and, TBH, extracting usable EBNF from the spec seemed like a good task to get my feet wet with aider.chat. 😁

ah geez lol there goes my evening 🙂 Didn't realize aider was open source. Okay cool that makes sense

@clojurians115 I'm assuming you saw @adam678 https://github.com/helins/wasm.cljc. There's also @roman01la https://github.com/roman01la/clj-wasm and @bbloom’s https://github.com/brandonbloom/waet.

https://github.com/brandonbloom/waet/blob/main/resources/waet/wat.ebnf?

@john I was aware of @adam678 work. I didn't know about clj-wasm or waet. Those are good references. I need to add these all to my links list. I'm partly trying to avoid hard coding all this: https://github.com/brandonbloom/waet/blob/main/src/waet/inst.clj#L71 That information is all in the spec if it can be reliably parsed out of it.

The MAL/wasm implementation was on top of wam, right?

Wish I would have caught your talk. I was at the conj for a bit but couldn't stay the whole time

@clojurians115 most of that was copy/paste from the spec + vim macros

Implementing EBNFs is catharsis for @clojurians115 lol

@john Yes, current wasm mal implementation uses wam. It's actually sort of a port of the mal BASIC implementation weirdly enough (because I had implemented manual reference counting/GC which the wasm one also needed). I want to do a new wasm implementation but using GC and other recent standards (bulk mem, exceptions, etc). Partly for fun, but mostly so I can explore and learn the new wasm features. My Clojure conj talk was totally unrelated to any of this (https://www.youtube.com/watch?v=rZaouaZq7t8). Unless you're referring to the Unsession. That was basically a spur of the moment thing and I didn't have a presentation (room didn't have the capability anyways). It was mostly a group discussion among interested people. And yes, now that I'm 5 years removed from my PhD defense, I think I can do EBNF for fun again 🤣

@bbloom It's very pretty copy/paste though! I'm going to take a stab at automatically extracting a grammar from the spec to see how far I can get. I think the full grammar is in there hidden in the latex markup.

In the topic of the standards models: I don’t really have a horse in the race, but I did find the component model to be somewhat overwhelming. It’s dramatically more complex than wasi “1” or whatever it’s called now. And it isn’t obvious to me what’s the goals actually are or if it’s able to achieve them. Wasi1 was basically C/Unix interop, which is pretty useful. The component model is a new thing entirely, which is a much bigger gamble. It feels like an entirely new VM/ecosystem & it’s not clear to me that this is a successful way to build such a thing, but time will tell.

Also when I last played with it, I literally couldn’t get any runtime to work for more than one example, and no one example worked in more than one runtime. So clearly immature.

May be better now. No idea honestly

That's the one I mentioned at the Conj but without knowing what it really was. Do you have more insights, notably about adding language support?

Still reading. WIT is definitely interesting reading and should probably influence how we do our implementation/port: https://component-model.bytecodealliance.org/design/wit.html. I'm happy to see that it's going in an interface approach direction, Also I think components is one area that we would want to influence and give feedback on. I suspect that as languages adopt the component model, it will also result in optimizations and changes pushed down into the lower-level standards and implementations.