On Tuesday, 9 July 2024 at 14:42:01 UTC, monkyyy wrote:
> On Tuesday, 9 July 2024 at 07:54:12 UTC, kiboshimo wrote:
>> - betterC can be compiled to WASM, but some of phobos can't, so basically same worries as above. I'm afraid to lose some essential systems stuff that I could not replace.
>
> yes, and your not afraid enough
>
>> Really liked the idea of doing it with betterC to start my systems programming journey
>
> Theres nothing even slightly pleasant or easy about d's wasm "support"; I wrote my own cos, sqrt functions, you get *nothing* from phoboes

Writing my own math functions is outside of my range, I still have hopes of this not being so hard. So you get another opportunity to crush it.

You could have used a C library for those things you implemented yourself, right? I suppose you didn't because doing things is cool, or because C is "not ergonomic" to use as foreign code. Because of the quirks. Which would make for a not so pleasant experience when writing a small game.

What do you think about using C libraries like that?

On Tue, Jul 09, 2024 at 08:03:15PM +0000, kiboshimo via Digitalmars-d-learn wrote:
> On Tuesday, 9 July 2024 at 14:42:01 UTC, monkyyy wrote:
> > On Tuesday, 9 July 2024 at 07:54:12 UTC, kiboshimo wrote:
[...]
> > > Really liked the idea of doing it with betterC to start my systems programming journey
> > 
> > Theres nothing even slightly pleasant or easy about d's wasm "support"; I wrote my own cos, sqrt functions, you get *nothing* from phoboes
> 
> Writing my own math functions is outside of my range, I still have hopes of this not being so hard. So you get another opportunity to crush it.
[...]

What are you planning to run your wasm on?  If in the browser, you could just use the browser's JS math functions.  The performance won't be stellar (the wasm-JS boundary is SLOW), but it'd work and you wouldn't have to write your own math functions.  This is what I use in my own D/wasm project.  (It'd probably still beat any hand-written WASM reimplementation of math functions that you write.  Remember, wasm is interpreted, so it won't beat the browser's built-in native math functions, which in all likelihood use the CPU's hardware math instructions.)

If you're planning to run your wasm in a native environment, you could probably just use the C API to interface with the host system's C library functions.

Don't reinvent the square wheel unless you're planning to ride it on an inverted catenary road. :-P

//

On a larger note, if you're planning to write something small that runs in a browser, you might be interested to check out:

	https://github.com/Ace17/dscripten

This is the D equivalent of emscripten. While it's nowhere near the maturity of emscripten itself, it may be Good Enough(tm) for your use. Rather than wrangling with the WASM/JS API (it's still early stage, there are a LOT of bumps currently still in the road), just let LLVM convert your D code straight into JS and run it as JS in the browser. Then you can leverage all the existing JS APIs your browser already supports, instead of having to reinvent yet another square wheel.


T

-- 
Some days you win; most days you lose.

On Tuesday, 9 July 2024 at 20:03:15 UTC, kiboshimo wrote:
> On Tuesday, 9 July 2024 at 14:42:01 UTC, monkyyy wrote:
>> On Tuesday, 9 July 2024 at 07:54:12 UTC, kiboshimo wrote:
>>> - betterC can be compiled to WASM, but some of phobos can't, so basically same worries as above. I'm afraid to lose some essential systems stuff that I could not replace.
>>
>> yes, and your not afraid enough
>>
>>> Really liked the idea of doing it with betterC to start my systems programming journey
>>
>> Theres nothing even slightly pleasant or easy about d's wasm "support"; I wrote my own cos, sqrt functions, you get *nothing* from phoboes
>
> Writing my own math functions is outside of my range, I still have hopes of this not being so hard. So you get another opportunity to crush it.

Honestly porting isqrt is easier then trying to get a half baked file io to work

but it is *everything* is gone and thats probaly overwhelming unless your prepared for it.

>
> You could have used a C library for those things you implemented yourself, right? I suppose you didn't because doing things is cool, or because C is "not ergonomic" to use as foreign code. Because of the quirks. Which would make for a not so pleasant experience when writing a small game.
>
> What do you think about using C libraries like that?

wasm *in general* breaks libc's fileio "for safety" (arguably the most important part of libc, morons), d's wasm libc in even more broken due to it coming out of no where and there being like 3 guys doing 20 ours of work on the "runtime" or something(ignore ppl who say d supports 7 platforms, it supports 2).

While it can be a trivial port, I think you better off sticking to the raylib api as your ground layer as whatever work there seems to carry over.

On 09/07/2024 9:58 PM, kiboshimo wrote:
> On Tuesday, 9 July 2024 at 09:30:18 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> Threads are indeed gone.
> 
> Oh no.
> 
>> If you want them, you'll have to call out to the system API and do your own thing.
> 
> I hope "doing my own thing here" could be linking to a C library that interacts with the OS on my behalf.

If you don't need to interact with an existing thread abstraction such as druntime, working with pthreads or Windows threading abstraction isn't an issue.

These API's are pretty easy to interact with, I've got my own -betterC threading abstraction (I have good reasons not to recommend it here).

>> I cannot comment about web assembly since I haven't done
>> anything there, but some people have so hopefully they'll
>> comment about where to go from here.
> 
> Some of them might know. And if they know, them I will know. And if I know, then, you know...

Oh I've seen them do stuff with it, its just not something I've wanted to learn, I have a lot of other stuff before it.

On Tuesday, 9 July 2024 at 20:24:14 UTC, H. S. Teoh wrote:
> What are you planning to run your wasm on?  If in the browser, you could just use the browser's JS math functions.  The performance won't be stellar (the wasm-JS boundary is SLOW), but it'd work and you wouldn't have to write your own math functions.  This is what I use in my own D/wasm project.  (It'd probably still beat any hand-written WASM reimplementation of math functions that you write.  Remember, wasm is interpreted, so it won't beat the browser's built-in native math functions, which in all likelihood use the CPU's hardware math instructions.)

This cleared up some fundamental misunderstandings I had, thank you. I want to use raylib and betterC to build a small game that runs on the browser. For motivation I though Wasm had many advantages over Js, but now I don't know if that is necessarily the case.

> If you're planning to run your wasm in a native environment, you could probably just use the C API to interface with the host system's C library functions.

That covers native use-case. In the browser I can compile my programs to .js using emscripten/dscripten or I can just use JS API from WASM (but that is slow).

I though emscripten could target WASM directly, without conversion to .js first. And, since it supports C, I'm assuming they re-implemented C API to the OS on WASM, without the need for calling JS API or WASI. (that might not serve me still, see bellow)

I feel some fundamental misunderstanding remain, but now I have more material to research on my own, so feel free to ignore this if it is "too wrong".

- I though one could write an application with -betterC for WASM, because LDC can target it, then could build it linking to C libraries that already work on WASM and run the resulting build on the browser. That would avoid the JS-WASM bondary since everything would be WASM and I would not need to write my own abstractions.
// I'm guessing one can't simply do that, and the toolchain that compiles to WASM is not so flexible/similar to compiling a normal binary. Maybe WASM does not have support for dynamic linking, for example.

- Is WASI relevant to the browser context? Or just to native apps? I though WASI API could be used on the browser, but comments and blogs about it often bring up the native context only.

I tried to reply everyone here, since I think most answers converge. Thank you all for your help :)

On Wednesday, 10 July 2024 at 01:48:54 UTC, kiboshimo wrote:
> - I though one could write an application with -betterC for WASM, because LDC can target it, then could build it linking to C libraries that already work on WASM and run the resulting build on the browser. That would avoid the JS-WASM bondary since everything would be WASM and I would not need to write my own abstractions.
> // I'm guessing one can't simply do that, and the toolchain that compiles to WASM is not so flexible/similar to compiling a normal binary. Maybe WASM does not have support for dynamic linking, for example.

I was able to generate a .wasm file from hello_world.d (main) and hello_lib.c using LDC for compilation to bytecode, then to webassembly with emscripten. So, in theory it works, just couldn't test it yet since I'm learning Web APIs and nodejs.

It would take sometime for me to figure how to print to javascript console from a generated .html file from emscripten, this is a small update so nobody gets too caught up that quote.

On Wednesday, 10 July 2024 at 08:26:56 UTC, kiboshimo wrote:
> It would take sometime for me to figure how to print to javascript console from a generated .html file from emscripten, this is a small update so nobody gets too caught up that quote.

Got it printing quicker than I thought (node and browser with localhost). So stdio works. Any reason why other libraries wouldn't?

Just archiving this progress here for anyone reading, but won't pollute the forum further if this thread dies out. I'm very grateful for the help, would have lost a lot of time without the reference frame you guys gave me :)