luwa

I gave up on a side-project Nearly a decade ago when WASM was new I started trying to implement a pure WASM lua implementation. With eventual goal to JIT, so I was writing it all in Lua to bootstrap I wrote a macro assembler in lua, & implemented objects, tables, garbage collector, lexer/parser. But when I got to the bytecode VM I got tangled trying to implement opcodes while dealing with "every allocation invalidates references because it's a moving GC" I was keeping a devlog on patreon (mostly stream of consciousness posts) & had a couple people supporting for a total ~10$/mo. Shortly after development stalled I paused payments Despite having a successful open source card game (openEtG), Luwa remains my most starred project on github: https://github.com/serprex/luwa I regretted stalling on this project for a long time, since it was a bi

Pure wasm has benefits since it gives you full control of heap layout The last bit about not changing areas of the board sounds like the initial step down the madness of implementing hashlife algorithm in pure webassembly https://en.m.wikipedia.org/wiki/Hashlife Few years ago I was tinkering with raw wasm lua (never got bytecode eval working, so no result) & wrote table's code in wasm (which was then used by lexer) https://github.com/serprex/luwa/blob/master/rt/_table.lua

Every story is unique. I was responding to a comment that was making sweeping claims My story likely isn't replicable, but everyone has to find their way I interviewed for Citus a couple weeks before they announced being acquired. I found out about the acquisition on Hacker News before having received an offer. They were able to get me in without going through the hiring process again Initially I'd be moving to San Francisco but I wasn't eligible for any visas as I don't have a post secondary education. Staying in Canada's worked out Some examples of things working out here: I was asked to implement some parsing, & well that's not so hard when you've written a Lua parser a year beforehand: https://github.com/serprex/luwa/blob/master/rt/astgen.lua (an astute reader will notice I don't handle precedence here, which is pretty important for a

Your complaints are mostly addressed in Lua 5.3 (64 bit integers, utf8 in stdlib, bitwise ops) & many would suggest you use LPeg if you're itching for non trivial string manipulation Also the documentation provided by lua.org is quite accessible: https://www.lua.org/manual/5.3 What I'd really like is stdlib to provide a Buffer type, as opposed to having to use a table of integers which then gets pushed into a string with chunked calls to string.char(table.unpack(buf, n, n+4096)) Example of what I'm complaining about: https://github.com/serprex/luwa/blob/master/rt/make.lua#L758 So all said I don't disagree with you: Lua can fall short, it doesn't have the community other languages have built up, & the community it has is rather fractured. Like LuaJIT making 5.2 what most call Lua, but also that being an extension language it's hard to upgr

> Resulting code for a gc looks like this: https://github.com/serprex/luwa/blob/master/rt/gc.lua Nice! That's a compact gc, perfect for browsers.

It's not a JavaScript imitation. This is a JavaScript-like syntax for writing WebAssembly. Other than that, (excepting the closure helper) it's 1-to-1 WebAssembly. Not everyone enjoys writing verbose S-Expressions [1], even if it makes for a good canonical format. If you despise JavaScript so much that you can't bear the thought of something that vaguely looks like JavaScript, then don't worry there are other "skins" for writing WebAssembly [2-4] and it should not be too hard to write your own. Finally, nobody owns WebAssembly. It's for clever people like yourself just as much as it is for dirty JavaScript programmers like me. [1] https://developer.mozilla.org/en-US/docs/WebAssembly/Text_fo... [2] https://github.com/tmcw/wah [3] https://github.com/serprex/luwa [4] https://medium.com/cirru-project/webassembly-s-expression-an...

I've been going with Lua for writing raw webassembly Assembler setup: https://github.com/serprex/luwa/blob/master/rt/make.lua Resulting code for a gc looks like this: https://github.com/serprex/luwa/blob/master/rt/gc.lua & it leaves the full Lua language at my disposal for metaproramming. At the end of a day a human usable assembler needs to be a macro assembler It'd be neat to have a JS macroassembler, could then have the host browser runtime compile wasm modules dynamically

It's not a binary encoded AST anymore, it's pretty much a stack machine (with constraints like .NET which allow for easy conversion to SSA) Example: A Lua lexer, https://github.com/serprex/luwa/blob/f048aa2f67dfae00740d556...

Copying GC can be straight forward to implement: https://github.com/serprex/luwa/blob/d96ba8fc478813a0a65a65c... Get to punt the allocator as a bump allocator

I've been working on a hand written Lua interpreter in WASM (using Lua as a macro assembler, ofc). Long term I'd like to have it jit wasm code: https://github.com/serprex/luwa Currently in the process of porting the parser & codegen that's implemented in Javascript to Lua so that I can have the implementation bootstrap itself. Plus the codegen was for a bytecode I came up with in JS but which has evolved quite a bit since getting everything in place to happen in WASM

Weird there isn't a src directory collecting everything together Hashtables are one of those data structures one can easily get away with never having to write on their own, yet still use every day. In scripting languages it's impractical to roll your own, & in the more abstracted low level languages there'll usually be a pretty good generic version. Yet there's much room for variation I had the joy to be out of reach of off-the-shelf hashtables for luwa, init: https://github.com/serprex/luwa/blob/436c7271120fcd116af30e9... get/set: https://github.com/serprex/luwa/blob/436c7271120fcd116af30e9... hash: https://github.com/serprex/luwa/blob/436c7271120fcd116af30e9... Still need to implement Lua's sequential-portion-as-array logic. I do like the API not having a 'remove' method, opting intead for nil by default. nil value entries get vacuumed

> who the hell keeps a single source-code file that big Me. SQLlite. .NET's garbage collector. CPython's eval. Lua's lexer. xinit. dwm. These are off the top of my head that I've seen https://raw.githubusercontent.com/dotnet/coreclr/master/src/... https://github.com/catseye/Befunge-93/blob/master/src/bef.c https://github.com/rust-lang/rust/blob/master/src/liballoc/v... https://github.com/oxyc/luaparse/blob/master/luaparse.js Yep. Pretty troll comment. Felt like taking the bite today. I'm going to get back to getting my lexer past 1000 lines today: https://github.com/serprex/luwa/blob/master/rt/lex.wawa

I've been wanting to do something like this but for WebAssembly & with Guile. Feels like it be useful compared to the hand writing I've been doing, here's an in-progress lexer: https://github.com/serprex/luwa/blob/master/rt/lex.wawa with the janky wawa assembler being https://github.com/serprex/luwa/blob/master/scripts/wawa.js

https://github.com/serprex/luwa Have a basic interpreter worked out, currently implementing tracing, no WASM currently being output. I have some previous experience generating wasm tho: https://github.com/serprex/Befunge https://github.com/serprex/brainwebfuckassembly I don't really care about interacting with DOM. I feel that something like vDOM & working out a method to play nice with emscripten's ABI will have more use for projects which want to run a wasm jit with the code being mostly in WASM lua.js seems promising on the not-wasm front. Possibility to allow coroutines by implementing those on top of generators like I've done in my own implementation

Chrome's generators are still quite fast compared to Firefox. I've currently got a generator stress test in using generators to implement a lua parser: https://github.com/serprex/luwa/blob/2c1ef6be42b804144340a2e... Currently trying to rewrite the Exp rule from using combinators to using something that'll properly handle operator precedence (Not keen on having 11 levels of operator precedence encoded in the grammar)