Thread overview
surviving wasm
Dec 13
monkyyy
Dec 13
monkyyy
Dec 14
ryuukk_
Dec 14
ryuukk_
December 13

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

December 13

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

  1. 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.
December 13

On Wednesday, 13 December 2023 at 21:15:47 UTC, Julian Fondren wrote:

>
  1. 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.

December 14

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)

December 14

I forgot to link this nice website that got me started with WASM:

https://schellcode.github.io/webassembly-without-emscripten