3 ms·

I have a very minimal v86 experiment here: https://tools.simonwillison.net/v86 https://tools.simonwillison.net/v86 My eventual goal with that is to expand it s

by simonw 10mo ago

I have a very minimal v86 experiment here: https://tools.simonwillison.net/v86 https://tools.simonwillison.net/v86 My eventual goal with that is to expand it so an LLM can treat it like a filesystem and execution environment and do Claude Code style tricks with it, but it's not particularly easy to programmatically run shell commands via v86 - it seems to be designed more for presenting a Linux environment in an interactive UI in a browser. It's likely I've not found the right way to run it yet though.

anilgulecha 10mo ago
On the second tab (which is a text/browser interface to the VM) here: https://copy.sh/v86/?profile=buildroot https://copy.sh/v86/?profile=buildroot , you can start sh shell, and run arbitrary commands, and see output. making a programmatic i/o stream is left as an exercise (to claude perhaps :).
Lerc 10mo ago
One of the very first experiments I did with AI was trying to build a browser based filesystem interface and general API provider. I think the first attempts were with ChatGPT 3.5 . I pretty quickly hit a wall, but Gpt4 got me quite a lot further. I see the datestamp on this early test https://fingswotidun.com/tests/messageAPI/ https://fingswotidun.com/tests/messageAPI/ is 2023-03-22 Thinking about the progress since then I'm amazed I got as far as I did. (To get the second window to run its test you need to enter aWorker.postMessage("go") in the console) The design was using IndexedDB to make a very simple filesystem, and a transmittable API The source of the worker shows the simplicity of it once set up. https://fingswotidun.com/tests/messageAPI/testWorker.js https://fingswotidun.com/tests/messageAPI/testWorker.js in total is just importScripts("MessageTunnel.js"); // the only dependency of the worker onmessage = function(e) { console.log(`Worker: Message received from main script`,e.data); if (e.data.apiDefinition) { installRemoteAPI(e.data.apiDefinition,e.ports[0]) } if (e.data=="go") { go(); return; } } async function go() { const thing = await testAPI.echo("hello world") console.log("got a thing back ",thing) //fs is provided by installRemoteAPI const rootInfo = await fs.stat("/"); console.log(`stat("/") returned `,rootInfo) // fs.readDir returns an async iterator that awaits on an iterator on the host side const dir = await fs.readDir("/") for await (const f of dir) { const stats = await fs.stat("/"+f.name); console.log("file " +f,stats) } } I distinctly remember adding a Serviceworker so you could fetch URLs from inside the filesystem, so I must have a more recent version sitting around somewhere. It wouldn't take too much to have a $PATH analog and a command executor that launched a worker from a file on the system if it found a match existed on the $PATH. Then a LLM would be able to make its own scripts from there. It might be time to revisit this. Polishing everything up would probably be a piece of cake for Claude.

by simonw 10mo ago

anilgulecha 10mo ago

On the second tab (which is a text/browser interface to the VM) here: https://copy.sh/v86/?profile=buildroot https://copy.sh/v86/?profile=buildroot , you can start sh shell, and run arbitrary commands, and see output. making a programmatic i/o stream is left as an exercise (to claude perhaps :).

Lerc 10mo ago

One of the very first experiments I did with AI was trying to build a browser based filesystem interface and general API provider. I think the first attempts were with ChatGPT 3.5 . I pretty quickly hit a wall, but Gpt4 got me quite a lot further. I see the datestamp on this early test https://fingswotidun.com/tests/messageAPI/ https://fingswotidun.com/tests/messageAPI/ is 2023-03-22 Thinking about the progress since then I'm amazed I got as far as I did. (To get the second window to run its test you need to enter aWorker.postMessage("go") in the console) The design was using IndexedDB to make a very simple filesystem, and a transmittable API The source of the worker shows the simplicity of it once set up. https://fingswotidun.com/tests/messageAPI/testWorker.js https://fingswotidun.com/tests/messageAPI/testWorker.js in total is just importScripts("MessageTunnel.js"); // the only dependency of the worker onmessage = function(e) { console.log(`Worker: Message received from main script`,e.data); if (e.data.apiDefinition) { installRemoteAPI(e.data.apiDefinition,e.ports[0]) } if (e.data=="go") { go(); return; } } async function go() { const thing = await testAPI.echo("hello world") console.log("got a thing back ",thing) //fs is provided by installRemoteAPI const rootInfo = await fs.stat("/"); console.log(`stat("/") returned `,rootInfo) // fs.readDir returns an async iterator that awaits on an iterator on the host side const dir = await fs.readDir("/") for await (const f of dir) { const stats = await fs.stat("/"+f.name); console.log("file " +f,stats) } } I distinctly remember adding a Serviceworker so you could fetch URLs from inside the filesystem, so I must have a more recent version sitting around somewhere. It wouldn't take too much to have a $PATH analog and a command executor that launched a worker from a file on the system if it found a match existed on the $PATH. Then a LLM would be able to make its own scripts from there. It might be time to revisit this. Polishing everything up would probably be a piece of cake for Claude.