Ported js13k game underrun to D targeting webassembly

[Dukc]

On Monday, 19 November 2018 at 13:52:28 UTC, Sebastiaan Koppe 
wrote:

> I am not sure where you got that impression from, but I am 
> afraid you'll still need js glue code.

I met the type JsHandle, found it's definiton and saw that it's 
only an alias for an int. I did remember seeing something similar 
in val.h (the emscripten header that's for using cpp to interface 
with JS classes) so I thought that you're calling the javascript 
interface directly with some knowledge how the function ABI looks 
like internally


> I really appreciate you getting excited about it but look, 
> Spasm is still in an early stage. The code is rough, the 
> documentation poor.

So is my code that translates to JavaScript. Pretty much anything 
is an improvement over having to write a wrapper functions in JS 
that can only use ints. So it's not poor for me!

>
> Having said that, of course I want you to use it :)
>

:). With good likelihood I will. I just need to find a good time 
and target for first translation attempt.


>> I know you did announce about Spasm earlier and I should have 
>> thanked you already. My fault: I realized that you made 
>> something that enables one to generate WebAsm, but didn't 
>> realize it enabled calling JS classes directly. Should have 
>> looked closer.
> The way calling js classes from D (or any language out there) 
> works, is to insert the js object in a big associative array at 
> the js side with an int as the key. The int (handle) is passed 
> to D. Anytime D wants to call a function or retrieve a property 
> of that class it calls some glue code with the handle as first 
> parameter. In the javascript glue code the handle is used to 
> lookup the object and the corresponding function is called.
>
> Since javascript allows you to call by string (e.g. 
> `object["foobar"]()`), you can minimize glue code at the 
> expense of decoding utf-8 strings.

Not quite as impressive I thought but still a clear improvement 
over what I do. It still sounds like one can do some light 
interfacing reasonably with your method. After all, it's always 
possible to hide those decoding things behind some interface that 
prematurely decodes the used function names.

>
>> 1. Manually compile your code and parts of Druntime/Phobos 
>> targetting 32-bit X86, link them manually with llvm-link using 
>> --only-needed and only then compile to JavaScript (Haven't 
>> tried with WebAsm, but theoretically should compile the same 
>> way). This way you don't need to manually stub what you don't 
>> use -well, when the linkers have same ideas about what you're 
>> calling, which's not always the case.
> That might work, but for the end-user it really needs to be as 
> simple as `dub build`.

Definitely a big downside if making a library, for sure.

> I decided to move to native llvm wasm compilation instead, 
> since I don't particularly like the emscripten toolchain.

It feels buggy, true.