www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - surviving wasm

reply monkyyy <crazymonkyyy gmail.com> writes:
so long term planning on wasm raylib; I want compatibility with 
the good parts of the std, the std is causal about using libc 
while ldc-wasm half-baked implication is missing a bunch of 
basically worthless symbols but given the std is 1 million lines 
of code it will be a perennial problem that I make something work 
natively, I try it in wasm, it breaks citing a random core lib at 
a random line; the options I know about are:

1. use a "team betterc" personal std that doesn't have the apis I 
want, apis I know and probably limited
2. merge "use libc less" upstream to a std that has been slow to 
merge changes and probably doesnt care about wasm
3. fork the std
4. maintain patches to the std that go in and rewrite them live 
with root :D what could go wrong
5. make my own personal std that matches the std api of the parts 
I use

I hate all these options
Dec 13 2023
next sibling parent reply Julian Fondren <julian.fondren gmail.com> writes:
On Wednesday, 13 December 2023 at 20:40:20 UTC, monkyyy wrote:

 so long term planning on wasm raylib; I want compatibility with 
 the good parts of the std, the std is causal about using libc 
 while ldc-wasm half-baked implication is missing a bunch of 
 basically worthless symbols but given the std is 1 million 
 lines of code it will be a perennial problem that I make 
 something work natively, I try it in wasm, it breaks citing a 
 random core lib at a random line; the options I know about are:

 1. use a "team betterc" personal std that doesn't have the apis 
 I want, apis I know and probably limited
 2. merge "use libc less" upstream to a std that has been slow 
 to merge changes and probably doesnt care about wasm
 3. fork the std
 4. maintain patches to the std that go in and rewrite them live 
 with root :D what could go wrong
 5. make my own personal std that matches the std api of the 
 parts I use

 I hate all these options


6. statically build against musl and include it in the wasm 
binary. Since phobos is slow to change, its libc dependencies 
will also be slow to change, and you can work on reducing how 
much musl goes into the binary. Musl's MIT-licensed and D has 
ImportC; maybe this can be upstreamed as a pseudo-libc-less build 
option. People who don't care about wasm may still care about 
dodging glibc due to binary portability hassles with deployment 
to older servers. ldc already uses musl on Alpine Linux, popular 
with containers.
Dec 13 2023
parent monkyyy <crazymonkyyy gmail.com> writes:
On Wednesday, 13 December 2023 at 21:15:47 UTC, Julian Fondren 
wrote:

 6. statically build against musl and include it in the wasm 
 binary. Since phobos is slow to change, its libc dependencies 
 will also be slow to change, and you can work on reducing how 
 much musl goes into the binary. Musl's MIT-licensed and D has 
 ImportC; maybe this can be upstreamed as a pseudo-libc-less 
 build option. People who don't care about wasm may still care 
 about dodging glibc due to binary portability hassles with 
 deployment to older servers. ldc already uses musl on Alpine 
 Linux, popular with containers.


I have alpine linux running in distro box and im getting more 
"not my problem" errors
-mtriple=wasm32-unknown-unknown-musl : /stdc/time.d(34): Error: 
undefined identifier `time_t`,
-mtriple=wasm32-linux-musl-webassembly : posix/signal.d(394): 
Error: static assert:  "unimplemented"
--mtriple=i686-linux-musl: /usr/include/d/std/array.d(3418): 
Error: `TypeInfo` cannot be used with -betterC

etc. whats the correct triple even, who knows!!!!!

I just can't fix posix signaling or libc.time or clib.math or 
array using typeinfo because I called `float.to!string`

https://github.com/crazymonkyyy/raylib-2024/blob/bf23aede90ea75bfffd074a4bcae04281f21ce27/examples/001-helloworld.d#L11

I have no patience with this direction either, d's std depends on 
libc any claim that "d's std is pay-as-you-go with betterc" is 
delusional, wasm support is half-baked and undocumented Im 
trail-bazing as is.
Dec 13 2023
prev sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Wednesday, 13 December 2023 at 20:40:20 UTC, monkyyy wrote:

 so long term planning on wasm raylib; I want compatibility with 
 the good parts of the std, the std is causal about using libc 
 while ldc-wasm half-baked implication is missing a bunch of 
 basically worthless symbols but given the std is 1 million 
 lines of code it will be a perennial problem that I make 
 something work natively, I try it in wasm, it breaks citing a 
 random core lib at a random line; the options I know about are:

 1. use a "team betterc" personal std that doesn't have the apis 
 I want, apis I know and probably limited
 2. merge "use libc less" upstream to a std that has been slow 
 to merge changes and probably doesnt care about wasm
 3. fork the std
 4. maintain patches to the std that go in and rewrite them live 
 with root :D what could go wrong
 5. make my own personal std that matches the std api of the 
 parts I use

 I hate all these options


there is no libc on WASM, you'll either have to use WASI or 
emscripten

emscripten was made for this specific case, so you don't have to 
worry about anything

https://theartofmachinery.com/2018/12/20/emscripten_d.html


I personally started from scratch, so i only pay for what i use, 
and carefully craft my own std/runtime, and it's the way to go 
imo, just like i'd do in C, but with the advantage of using a 
better language (D)
Dec 14 2023
parent ryuukk_ <ryuukk.dev gmail.com> writes:
I forgot to link this nice website that got me started with WASM:

https://schellcode.github.io/webassembly-without-emscripten
Dec 14 2023