Funny to see this show up today since coincidentally I've had Claude code running for the past ~15 hours attempting to port MicroQuickJS to pure dependency-free Python, mainly as an experiment in how far a porting project can go but also because a sandboxed (memory constrained, to us time limits) JavaScript interpreter that runs in Python is something I really want to exist.
I'm currently torn on whether to actually release it - it's in a private GitHub repository at the moment. It's super-interesting and I think complies just fine with the MIT licenses on MicroQuickJS so I'm leaning towards yes.
> I think you halucinated this up. (Quote from original comment, pre malicious-edit)
No point in responding to a troll, but for the other people who may be reading this comment chain, he's used LLMs for various tasks. Not to mention that he founded TextSynth, an entire service that revolves around them.
> TextSynth provides access to large language, text-to-image, text-to-speech or speech-to-text models such as Mistral, Llama, Stable Diffusion, Whisper thru a REST API and a playground. They can be used for example for text completion, question answering, classification, chat, translation, image generation, speech generation, speech to text transcription, ...
TI had similar idea with TI-99/4 - running interpreted BASIC programs using BASIC written in special interpreted language (GPL) running in its own virtual machine, with actual CPU machine code executing from ram accessible thru single byte window of Video processor. Really brilliant system, turtles all the way down.
I wouldn't trust it without a deeper inspection. I've had Claude do a workaround (ie: use a javascript interpreter and wrap it in Python) and then claim that it completed the task! The CoT was an interesting read on how his mind think about my mind (the user want ... but this should also achieve this ... the user however asked it to be this ... but this can get what the user want ...; that kind of salad)
I see that you're no longer copying and pasting from the terminal, I remember those two gnarly code sessions to get a previous transcript. How are you generating that transcript now? I'd certainly like to use that for my own record keeping.
It's a new tool I built yesterday (because for this particular JavaScript interpreter project publishing the full transcript was essential): https://github.com/simonw/claude-code-publish
It only works with Claude Code for the web sessions at the moment but I expect I'll get it working for local sessions too.
How many tests do other JS runtimes like V8 have? ~400 tests sounds reasonable for a single data structure, but orders of magnitude off for a language runtime.
Yes, effectively my entire project was generated by AI.
It's a very weird and uncomfortable way of working - I've said in the past that I don't like a single line of unreviewed AI-generated code in anything beyond a prototype, and now here I am with 13,000+ lines of mostly unreviewed Python written by Claude Opus 4.5.
I'm leaving the alpha label on it until I'm a whole lot more comfortable with the codebase!
I do however know that the tests are pretty comprehensive because I had the model use TDD from the very start - write a test, watch it fail, then implement code to make it pass.
I was able to keep an eye on what it was doing on my phone while it worked and the TDD process seemed to be staying honest.
I'm now having Claude Code build the tests for my voicenotes organization application. For the most basic implementation - just a single text field - I wrote in English which tests I know I need, there were about two dozen. Approaching size limits, unicode, normalization, nonprinting characters, Hebrew vowel points, empty strings vs NULL strings, Exceeded byte length without exceeded character length, etc etc. I then threw Claude Code at it.
Claude Code found more edge cases to write tests for than I ever would have thought of. And I've been doing this for 20 years.
I build and distribute software in Python. My ideal solution is something that installs cleanly via pip so I can include it as a regular dependency of my other projects.
It's analogous to asm.js, the precursor to WebAssembly, which was written in js, in that it ran virtual machines in pure js, which is a huge win in portability. The mquickjs readme explains it in a much lower level way than the quickjs readme. There's also more emphasis on the bytecode. In a way it's like a tiny WebAssembly plus garbage collection extension vm that can run compile to js languages, going beyond that and compiling them to bytecode. The overhead of porting it to a dynamic language wouldn't always be that bad depending on the use case. Its memory savings could be maintained.
I'm currently torn on whether to actually release it - it's in a private GitHub repository at the moment. It's super-interesting and I think complies just fine with the MIT licenses on MicroQuickJS so I'm leaning towards yes.
Its got to 402 tests with 2 failing - the big unlock was the test suite from MicroQuickJS: https://github.com/bellard/mquickjs/tree/main/tests
Its been spitting out lines like this as it works: