Thread overview
Can we ease WASM in D ?
5 days ago
Jesse Phillips
4 days ago
Hipreme
November 16

Dear community,

I look some day ago to the D wasm page:
-> https://wiki.dlang.org/Generating_WebAssembly_with_LDC

And since then I ask myself can we at compile time convert a D code to an extern C code for wasm ?

Indeed, if a library/framework would wrap this to let end user write his code in plain D that would be awesome.

So did you think it is possible to do it by using metaprogramming, mixin, mixin template, mixin string … ?

Thanks for your ideas

November 16

On Wednesday, 16 November 2022 at 22:51:31 UTC, bioinfornatics wrote:

>

And since then I ask myself can we at compile time convert a D code to an extern C code for wasm ?

It would be pretty cool if you could just mark @wasm on a function and have it magically convert... the dcompute thing i think does something like this. but im not sure.

>

Indeed, if a library/framework would wrap this to let end user write his code in plain D that would be awesome.

So did you think it is possible to do it by using metaprogramming, mixin, mixin template, mixin string … ?

What I've done before (including the webassembly.arsdnet.net website) is have the server call the compiler as-needed when requesting the file, which makes it feel pretty transparent. You might want to do that too, it'd be on the file level instead of on the function level but it works.

November 16

On Wednesday, 16 November 2022 at 23:00:40 UTC, Adam D Ruppe wrote:

>

On Wednesday, 16 November 2022 at 22:51:31 UTC, bioinfornatics wrote:

>

[...]

It would be pretty cool if you could just mark @wasm on a function and have it magically convert... the dcompute thing i think does something like this. but im not sure.

>

[...]

What I've done before (including the webassembly.arsdnet.net website) is have the server call the compiler as-needed when requesting the file, which makes it feel pretty transparent. You might want to do that too, it'd be on the file level instead of on the function level but it works.

This is what it does, albeit with a pretty wacky pipeline because GPUs be crazy.

November 16
On Wed, Nov 16, 2022 at 10:51:31PM +0000, bioinfornatics via Digitalmars-d-learn wrote:
> Dear community,
> 
> I look some day ago to the D wasm page:
> -> https://wiki.dlang.org/Generating_WebAssembly_with_LDC
> 
> And since then I ask myself can we at  compile time convert a D code to an extern C code for wasm ?
> 
> Indeed, if a library/framework  would wrap this to let end user write his code in plain D that would be awesome.

You mean with Phobos and everything included?  I think there may be issues with that... because the current WASM does not define a memory management mechanism, so you'd have to convert the GC implementation to work with WASM.  Which would have issues with deployment because AIUI currently WASM still requires Javascript to initiate running it; if druntime needs special handling, for example, then you'd have to worry about coordinating with any JS code that the user may also wish to deploy, for example.  There are also language constructs that may not be supportable, like exceptions that propagate beyond the JS/WASM boundary (although if we add a layer of indirection to D functions called from JS, this might be possible to shoehorn into a semblance of working).

I did actually play with this a week or two ago; and found that it was actually quite difficult to get meaningful native code (D or otherwise) off the ground, because of the currrently mandatory Javascript component that need not only to load and initialize the WASM module, but also to interface with various browser APIs --- since WASM cannot call any of them directly, but has to go through a JS export/import API. String support also needs a lot of boilerplate.

Which actually gave me the idea of a D-based framework that uses compile-time introspection, etc., to auto-generate the necessary JS glue code (e.g., as a pre-compile step[1]) so that the user does not actually have to write any JS manually for things to work.

[1] I.e., there'd be a special D helper tool that imports your user D code and performs introspection on it, and spits out JS glue code at runtime. So you'd run this as part of your build, and it creates the necessary JS file(s) that you need to insert into your HTML; in the meantime, you run a separate build command to compile the user D code into WASM.  (This is why dub seriously needs to break out of its single executable modus operandi -- I don't think this can be easily bundled with dub right now.)

Having this tool is essential to making D's WASM experience tolerable; currently the insane amounts of JS boilerplate you have to write in order to get non-trivial D code off the ground is ridiculous.  Trying to write a WASM function that does string processing, for example, requires a ton of hacks to work around the lack of a built-in string type.  D could totally automate this crap away by having a wrapper tool that introspects your D code at compile-time and spits out the necessary JS boilerplate and any other needed shims in order to get this to work with a minimum of fuss.  Also, interfacing with browser APIs like WebGL also needs to be doable with a minimum of fuss, which currently isn't possible because of the unavoidable JS component with its associated boilerplate.


T

-- 
Hey, anyone can ignore me and go ahead and do it that way. I wish you the best of luck -- sometimes us old coots are dead wrong -- but forgive me if I'm not going to be terribly sympathetic if you ignore my advice and things go badly! -- Walter Bright
November 16
On Wednesday, 16 November 2022 at 23:16:26 UTC, H. S. Teoh wrote:
> You mean with Phobos and everything included?  I think there may be issues with that...

Yes, this is a problem, but I think I have a solution: defer GC runs until javascript is running. There's also some llvm features that might fix it.

If I had a spare day I think I could play with it.


> Which actually gave me the idea of a D-based framework that uses compile-time introspection, etc., to auto-generate the necessary JS glue code (e.g., as a pre-compile step[1]) so that the user does not actually have to write any JS manually for things to work.

Sebastiaan Koppe generates the D/JS glue code from web standards. I've done it more dynamically inside D itself (exposing an `eval` hook on the JS side).

Sebastiaans: https://github.com/skoppe/spasm

mine: http://dpldocs.info/this-week-in-d/Blog.Posted_2020_08_10.html

Actually pretty easy to solve.

November 16
Thanks Adam, H. S., max for your point of view

On Wednesday, 16 November 2022 at 23:23:48 UTC, Adam D Ruppe wrote:
> On Wednesday, 16 November 2022 at 23:16:26 UTC, H. S. Teoh wrote:
>> You mean with Phobos and everything included?  I think there may be issues with that...


Yes that would be really fantastic to get those enhancement. As example I see this wasm framework wrote in rust: https://github.com/yewstack/yew

Get a such framework in D wold be helpful
5 days ago

On Wednesday, 16 November 2022 at 22:51:31 UTC, bioinfornatics wrote:

>

Dear community,

I look some day ago to the D wasm page:
-> https://wiki.dlang.org/Generating_WebAssembly_with_LDC

And since then I ask myself can we at compile time convert a D code to an extern C code for wasm ?

Thanks for your ideas

Not exactly related, but this effort seemed to have gotten pretty far. But is old now https://code.dlang.org/packages/spasm

4 days ago

On Wednesday, 16 November 2022 at 22:51:31 UTC, bioinfornatics wrote:

>

Dear community,

I look some day ago to the D wasm page:
-> https://wiki.dlang.org/Generating_WebAssembly_with_LDC

And since then I ask myself can we at compile time convert a D code to an extern C code for wasm ?

Indeed, if a library/framework would wrap this to let end user write his code in plain D that would be awesome.

So did you think it is possible to do it by using metaprogramming, mixin, mixin template, mixin string … ?

Thanks for your ideas

It should not be too hard to do that using mixin templates. The concept is the same from my @ExportD that I'm using on my engine.

What @ExportD does is to create a new function based on the function target function [or even classes] which all it does is call that (or even attach a GC.root as needed ), and generates factory functions for classes or create some extern(C) export the function.

I have done the same thing also for Lua and Java, don't seem that hard to do it with WASM. The only difference is that you will need to mixin template yourself (I do it at the end of file), then I iterate through the module members containing your @wasm UDAs, and generate the functions needed.

Remember that you could also use things such as @wasm("myNewFunctionName") and handle such cases.

But for me, working with D without a D runtime is simply not worth. That being said, if we had a working D runtime for WASM I would be adapting my engine to support it too.