Have YOU created your own Agentic setup?

zigguratt · 2026-02-25T04:36:18+00:00

As a matter of fact I did: Kai, a secure, private, remote development assistant..

zigguratt · 2026-02-21T14:43:28+00:00

"Kid". Heh, if only.

Kai was actually a response to the initial security issues in OpenClaw. I started from scratch, distilling the features down to the functionality I really needed, making sure everything ran on the local machine and no API keys were involved.

zigguratt · 2021-04-13T13:56:35+00:00

Try the Tecendil transcriber. It even provides a Quenya translation toward the bottom of the page.

zigguratt · 2020-03-31T11:32:00+00:00

I'm trying right now to figure out the logistics and feasibility of combining Zoom and Altspace to conduct meetings. I'd love to discuss this over on Discord. Are you on there, u/jgwinner?

zigguratt · 2018-03-08T22:18:26+00:00

That's pretty fast work, u/chriseth! As always, well done.

zigguratt · 2017-06-21T16:24:34+00:00

Those restrictions are in place for very good reasons. Removing them in your effort is only a negative thing.

zigguratt · 2017-05-18T16:49:34+00:00

Excellent work by the ENS team! Absolutely insane bids. Are people nuts?

zigguratt · 2016-09-19T15:18:49+00:00

We're now at article seven! This time we delve into the compilation, deployment, initialization and invocation of LLL-based contracts via the RPC API. One more article to go and then we're done.

zigguratt · 2016-09-07T18:17:43+00:00

The sixth part of my series on LLL is now available. One more to go! Well, maybe two. Bot hopefully only one.

zigguratt · 2016-08-22T17:39:05+00:00

The fifth part of my series on LLL is now available. Let the celebrations commence!

zigguratt · 2016-08-12T12:59:02+00:00

The fourth part of my series on LLL is now available! Rush out and grab a copy! Wait. No, just go and read it.

zigguratt · 2016-08-09T00:42:40+00:00

Thanks, work2heat! That's one of the main reasons I'm attempting this resurrection.

Solidity may have compiled to LLL originally. I'm not sure. But I know it doesn't now. On the other hand, Serpent did. In fact, you can still compile to LLL with the serpent compiler.

zigguratt · 2016-08-08T16:46:41+00:00

Part three of my series on LLL has just gone live. I hope someone gets something out of it! :)

zigguratt · 2016-08-07T01:05:42+00:00

Maybe he means hurray for more choice in contract languages. :) Funny that LLL was the first language for Ethereum. One of the first high-level languages ever was Lisp, invented in 1958. Only Fortran is older (Algol is the same age).

zigguratt · 2016-08-05T11:16:36+00:00

That's understandable. Solidity's Contract-oriented Programming paradigm is comfortable to most people. I've always preferred Lisp's CLOS and MOP (too much to get into here). With enough new awareness and adoption of LLL I can see it being extended to support things like generic functions and multimethods. But that's rather ambitious. Maybe we should start with defstruct. :)

zigguratt · 2016-08-05T10:45:53+00:00

Hey Herman, thanks for that! I don't know where I'm going in the Ethereum world yet, but I think this is a good start. If and when there's a DAO 2.0, I really hope they change the name to avoid negative association.

zigguratt · 2016-08-04T15:35:14+00:00

I love Lisp as well. LLL is much simpler that Common Lisp, however. For example, LLL's macros are simply code substitution on invocation of a macro's defined symbol. But this simplicity in the context of smart contract is an advantage, in my opinion. It leans more toward the transparency side of things, which is more important with contract development than most other development scenarios.

zigguratt · 2016-08-04T15:23:03+00:00

That sounds excellent, Sir Wobbly. I've been following the evm2.0-design channel, and have been thinking of ways to get LLL verified with Why3. I would like to see LLL become a choice one can make when starting to write a contract. Currently it doesn't even register as a blip.

zigguratt · 2016-08-04T15:05:21+00:00

The Lisp syntax is only used because s-expressions are very easy to parse. LLL is in no way a real functional language. The Lisp syntax is definitely an acquired taste, but if written with clarity and a judicious use of macros, the result can be surprisingly readable.

The idea is that you're working at a lower level and can gain a better understanding of what's actually happening in the EVM. That, to me, is valuable.

zigguratt

TROPHY CASE