podperson

I've been working with icons and icon systems for thirty years and there have always been tradeoffs and horribly manual processes. I think I've finally gotten a system which is al win. It lets you use SVG icons and icon elements, compose them on the fly, and use them as a design language leveraging CSS variables where needed.

The link is to a blog post that explains the evolution and architecture.

OP again:

The tjs compiler transpiles ts into itself: https://platform.tosijs.net/#example=Hello+TypeScript&sectio...

It's written in typescript and can transpile itself.

When it transpiles typescript, type declarations become contracts, and types are available at runtime.

It does all this with a 50-70% overhead (imperceptible in most cases), but there's an unsafe escape hatch (!) => {} functions bypass type checks.

Oh yeah, it does inline WASM and it handles the hard stuff other WASM implementations kind of leave as an exercise -- moving data across. And it support SIMD.

https://platform.tosijs.net/#view=tjs&example=Vector+Search+...

Error propagation is monadic, so functions passed bad arguments just don't execute. Also functions know from whence they came and you can execute code in debug mode and get a trace with your monadic error, so it's very agent friendly.

If you code in tjs natively you can do inline tests of unexported functions at transpile time.

If you transpile ts using tjs it gives you the same capability.

Single pass transpilation does inline tests and generates documentation at the same time.

tjs itself is a TRUE js superset with predicate functions to handle complex types (if your type system is going to be turing complete, own it), full introspection (so it's a true LISP, or what Dylan aspired to be), and safe Eval using a language subset that is deeply async. Again, universal endpoints.

Simple types are declared by example, so:

function greet(name: 'Alice') -> 'Hello, Alice' => `Hello, ${name}`

is not just a declaration of a function that takes a string and returns a string, but the string should look like 'Alice' and if it is 'Alice' the function will return 'Hello, Alice' and this is also an inline test that runs at transpile time.

It's evening when I posted. I was heading to dinner, not hovering over my computer.

Every execution atom in the save eval sandbox has a 'gas' cost that also time bounds it, so eval is safe both from the halting problem and type fuzzing, and the only things the code can do is execute capabilities you explicitly give it, and you can give those capabilities the same access tokens the request had. So you get universal endpoints.

OP here.

I wrote this because I was frustrated by the recent "16 AI Agents build a C compiler" narrative. Building a C compiler is an exercise in implementation; I wanted to see if one dev could use AI for invention.

The result is TJS. It's my attempt to fix what I dislike about TypeScript (erased types) and solve the eval() problem for AI agents. It treats JS like the Lisp it was meant to be: types are real values, autocomplete works by introspection, and execution is strictly gas-metered.

The playground is live here if you want to test the sandbox or the types: https://platform.tosijs.net

Happy to answer technical questions about the compiler architecture, the AJS sandbox, or how the gas metering works.

I am in Finland so apologies in advance if I am slow to reply.

While I was waiting for the night train to Oulu in Helsinki on Friday night, I pondered two problems I have been thinking about for years on the one hand, and for months on the other.

1. How can I build a simple *service-as-a-service* endpoint that pulls data, maybe does a little work on it (e.g. whittling it down, converting XML to JSON, etc.) caches it, and returns it? This seems to require *eval* to be really useful and then it's a whole deployment, code-review thing (for good reason). 2. How can I build an LLM-powered agent that… you get the idea. If service-as-a-service, why not *agent-as-a-service*? I'd already played with lang-chain and found it quite fiddly even for simple things, and this had led me to build a lighter, schema-first alternative to zod.

The epiphany I had was that these are the same question, and the problem was *eval*. So why not make *eval* completely safe?

The result is *agent-99* – a Turing-complete, cost-limited virtual machine that enables "Safe Eval" anywhere (Node, Bun, Deno, and the Browser). The runtime model is so simple it could easily be ported to any of your favorite languages: Python, Rust, Go, Java, Zig… Haskell. It's a perfect fit for Erlang.

Oh and because the underlying language is JSON schema, it's easy to hand it to an agent as a set of tools. So *agent-99* makes it easy to do that, too.

It's the infrastructure for *sky-net* but, you know, type-safe, deeply asynchronous, and without a halting problem.

- *agent-99 repo* https://www.google.com/search?q=https://github.com/tonioloew... - *agent-99-playground (Vibe Coded in ~2 hours):* https://github.com/brainsnorkel/agent99-playground

### The Core Idea

Most Agent frameworks (like LangChain) rely on heavy "Chain" classes or graph definitions that are hard to inspect, hard to serialize, and hard to run safely on the client.

`agent-99` takes a different approach: *Code is Data.*

1. You define logic using a *Fluent TypeScript Builder* (which feels like writing standard JS). 2. This compiles to a *JSON AST* (Abstract Syntax Tree). 3. The AST is executed by a *Sandboxed VM* (~7kB gzipped core).

Or to put it another way:

1. A program is a function 2. A function is data organized in a syntax tree 3. An agent is a function that takes data and code

`agent-99` provides a *builder* with a fluent-api for creating your language and creating programs, and a *virtual machine* for executing those programs with explicitly provided capabilities.

### Why use a VM? * *Safety:* It solves the halting problem pragmatically with a "Fuel" (Gas) counter. If the Agent loops forever, it runs out of gas and dies. * *Security:* It uses *Capability-Based Security*. The VM has zero access to fetch, disk, or DB unless you explicitly inject those capabilities at runtime. * *Portability:* Because the "code" is just JSON, you can generate an agent on the server, send it to the client, and run it instantly. No build steps, no deployment.

### Batteries Included (But Optional)

While the core is tiny, I wanted a "batteries included" experience for local dev. We built a standard library that lazy-loads:

* *Vectors:* Local embeddings via `@xenova/transformers`. * *Store:* In-memory Vector Search via `@orama/orama`. * *LLM:* A bridge to local models (like LM Studio).

### Proof of Concept

I sent the repo to a friend (https://github.com/brainsnorkel). He literally "vibe coded" a full *visual playground* in a couple of hours using the library. You can see the definitions generating the JSON AST in real-time.

### The Stack * *agent-99:* The runtime. * *tosijs-schema:* The underlying schema/type-inference engine https://github.com/tonioloewald/tosijs-schema

I’d love to hear your thoughts on this approach to code-as-data and agents-as-data.

It seems to be true to me. And aside from the API stuff (because I am far from an expert user of Zod) all of this has been carefully verified.

N is increasing. O(1) means constant (actually capped). We never check more than 100 items.

JSON schema is very human readable.

1. Zoe’s documentation, such as it is 2. Code examples

JSON Schema is a schema built on JSON and it’s already being used. Using XML would mean converting the XML into JSON schema to define the response from the LLM.

That said, JSON is “language neutral” but also super convenient for JavaScript developers and typically more convenient for most people than XML.

It generates schemas that are strict by default while Zod requires you to set everything manually.

This is actually discussed in the linked article (READ ME file).

I wrote this library this weekend after realizing that Zod was really not designed for the use-cases I want JSON schemas for: 1) defining response formats for LLMs and 2) as a single source of truth for data structures.

Unlike previous GUI platforms there's no reason we should need to cross-compile to XR devices given the capabilities of the VisioPro and Quest 3. This is literally the first demo of a multi-window dev environment building an XR scene in XR using the Quest 3 (because I don't have a Vision Pro to play with).

Well, the GP is talking about Apple's overall margins and the 70% figure is simply wrong. (Retail price - cost of goods is not margin.)

Apple does spend comparatively little on R&D (perhaps part of that is because they don't produce 400 different models of every darn device), but their margins on iPhones are still nowhere near 70%.

Clearly being an actual war criminal probably outweighs donating to prop 8, so there's that.

In any event, I think your problem is you took the wrong position on Eich -- first, there was no "lynch mob" -- being denied a high profile, well-paid job as head of a non-profit is not the same as being lynched. Second, no-one forced Eich to donate to prop 8, and the outcome was quite foreseeable. Isn't a bit of judgment an important job skill for the CEO of a non-profit?

What's odd to me is the choice of Condi Rice. Even assuming that she was relatively blameless compared to (say) Cheney, what the heck do they think they gain by appointing a polarizing political figure to their board?

Safari also -- not the home page but the articles. Showing up as phishing attack.

I agree. I should probably have put quotation marks around "effective".

It's hard to analyze data before it's available!

Aside from this announcement, Chinese have also (apparently) seen more stuff from planes and satellites than anyone else, despite -- for example -- lacking the P3 Orion and the P8 Poseidon, and not having much blue water navy experience, and it not being just off their coast.

We had big fanfare over the number of P3s the US and Australia were committing to the search, and the addition of the P8, and the deployment of a special US Naval vessel with dedicated sensor array. Since then the only nation to report positive sightings (more than once) has been China. Interesting no?

Odd to get downvoted for suggesting this is interesting.

1) If China feels it necessary to fabricate sightings in order to mollify its population (also note the way it has tried to manage the bereaved families and focus their anger on Malaysia including providing coordinated t-shirts etc.) then that's interesting.

2) If China, not usually noted as outstanding in air, naval, or orbital surveillance capability is able to outperform Australia (which is both very experienced with ocean searches and is operating on its doorstep) and the US then that's interesting.

3) If China is more willing to reveal its capabilities than the US or Australia that's also interesting. (E.g. I suspect the reason the Australians were so willing to commit to the current search area based on one satellite image is because they actually tracked the flight via Jindalee, but were unwilling to reveal that system's capabilities given there weren't going to be any survivors.)

Interesting how effective the Chinese have been (relative to the US and Australia) in the search thus far.

Good job.

The simple alert at the end for the score is a bit of a weakness.

I agree about the partial slide movement testing. Perhaps hit the arrow to test the move and double-tap it to actually make the move.

This suggests that its userbase is EXACTLY complementary for Facebook.

Do not underestimate this.

Absolutely. But don't overestimate it either! Most serious bugs compile perfectly well -- and so you're trading quick detection of simple errors for more difficulty dealing with the hard stuff.

I ended up writing one app (and making significant headway on a second) using node-webkit yesterday, so many thanks for bringing it to my attention.

In general, a web app has to get pretty ridiculously bloated for javascript minification and so forth to impact launch time on a local file system. I'd call this premature optimization. (In my day job we're working on a pretty huge web app and we don't use any build process except -- just recently -- precompiling our LESS files (mainly to handle IE and mobile devices)). For us, the downside of a build-process to the debug cycle is a far bigger hit than the benefit of minification. (Perhaps we were overreacting to another project which used maven and had 2-3 minute builds...)

Of course if you're using coffeescript or clojurescript or whatever there's no avoiding some kind of build process.

It strikes me that automating and simplifying the build process is exactly the kind of thing you could wrap up in a pretty nice node-webkit application!

The physical keyboard refers to claim 2, basically implying that the system for responding to suggestions (with gestures) applies whether the initial typing was done on the glass or virtual keyboard. So it's not making such a sweeping claim.

In any event, specific claims can be thrown out as appropriate.

The underlying runtime technology -- node-webkit -- seems pretty interesting.

This particular workflow would be more interesting to me if it was clearer that you could pick and choose your tools. I don't want to use Angular, Jade, or Coffeescript (for example). And (as per another thread) a workflow that included an out-of-box offline data storage option would be nice.

As I understand it, if I don't use tools that have a "compilation" phase, my workflow using node-webkit would be to save my files and restart node-webkit, right?

You can't program away edge cases, but the current standard behavior fails in the bog standard common case.