This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-25
Channels
- # announcements (1)
- # beginners (70)
- # boot (2)
- # cider (12)
- # cljdoc (19)
- # clojure (25)
- # clojure-austin (1)
- # clojure-nl (2)
- # clojure-uk (9)
- # clojurescript (24)
- # cursive (7)
- # datomic (8)
- # figwheel-main (22)
- # flambo (1)
- # fulcro (16)
- # funcool (3)
- # jobs (1)
- # juxt (3)
- # off-topic (39)
- # reagent (4)
- # reitit (4)
- # ring (2)
- # shadow-cljs (90)
- # specter (11)
- # sql (2)
- # testing (2)
Been thinking about creating a wast-to-wasm assembler in clojure(script), from which I can then write an intermediate language for writing a subset of clojure
I think the assembler has straightforward guidelines, but I feel like getting clojure's persistent data collections into webassembly is next to impossible without some more radical design decisions
I could try stealing some ideas from the rust crew, since they designed a new allocator specifically for wasm, but then it would be a matter of developing a good gc. I'd probably focus on just getting it functionality correct before attempting to optimize it
But the big question is... what do I name my project? I've had a bad track record, so i'd be open to some suggestions
Maybe since i'll be making an intermediate to build up to clojure, i could step the letter down to blojure
But I don't understand why you need a wast to wasm compiler. Hasn't somebody already built that?
looks like a thing called wabt will do it. Looking at the source code for this demo: https://cdn.rawgit.com/WebAssembly/wabt/aae5a4b7/demo/wat2wasm/
function compile() {
outputEl.textContent = '';
var binaryOutput;
try {
var module = wabt.parseWat('test.wast', watEditor.getValue());
module.resolveNames();
module.validate();
var binaryOutput = module.toBinary({log: true, write_debug_names:true});
outputEl.textContent = binaryOutput.log;
binaryBuffer = binaryOutput.buffer;
var blob = new Blob([binaryOutput.buffer]);
if (binaryBlobUrl) {
URL.revokeObjectURL(binaryBlobUrl);
}
binaryBlobUrl = URL.createObjectURL(blob);
downloadLink.setAttribute('href', binaryBlobUrl);
downloadEl.classList.remove('disabled');
} catch (e) {
outputEl.textContent += e.toString();
downloadEl.classList.add('disabled');
} finally {
if (module) module.destroy();
}
}
function run() {
jsLogEl.textContent = '';
if (binaryBuffer === null) return;
try {
let wasm = new WebAssembly.Module(binaryBuffer);
let js = jsEditor.getValue();
let fn = new Function('wasmModule', 'console', js + '//# sourceURL=demo.js');
fn(wasm, wrappedConsole);
} catch (e) {
jsLogEl.textContent += String(e);
}
}
This might be inspirational https://github.com/perlin-network/life
apparently this hullabaloo about liftoff is all about this streaming compilation stuff https://jaxenter.com/v8-javascript-liftoff-148475.html
I guess it was one of the original wasm design goals - to allow this streaming compilation model, so things can start happening before later bits are available
Yeah, I've been wondering about an allocation/free scheme for both cljs and wasm wast on SharedArrayBuffers
If the allocation/free scheme is lockfree, I'm thinking different environments can operate on the same buffer if they all implement the same lockfree protocol
I'm working on an algorithm right now. I'm going to try to rewrite it with comments on https://www.maria.cloud and then people can just play with it or fork it off maria.cloud.