What is the recommended way to roll a D app running in a web browser at the moment? Spasm or something else? Last time I remember Spasm could only allocate memory but couldn't deallocate it, has it changed since then?

On Friday, 31 July 2020 at 16:23:16 UTC, JN wrote:
> What is the recommended way to roll a D app running in a web browser at the moment? Spasm or something else? Last time I remember Spasm could only allocate memory but couldn't deallocate it, has it changed since then?

There is no reason why you can't deallocate, since it is just plain old manual memory management. The wasm allocator follows the stdx allocator so you can build on that.

I did experiment with a GC last year but I abandoned that in favor of porting druntime to wasm. The problems I ran into were mostly because 'new' isn't templated, so no amount of work I did would allow people to simply 'new' things, and instead they would always be stuck with custom allocators. Which is fine for some, but it is really barebones.

Since corona I have become a bit focussed on work, to the expense of literally everything else. I do hope that during the summer I can find time to finish it. It really is almost there.

Regardless, I think you best bet is to use the web api bindings in spasm and take it from there.

On Friday, 31 July 2020 at 21:18:25 UTC, Sebastiaan Koppe wrote:
> On Friday, 31 July 2020 at 16:23:16 UTC, JN wrote:
>> What is the recommended way to roll a D app running in a web browser at the moment? Spasm or something else? Last time I remember Spasm could only allocate memory but couldn't deallocate it, has it changed since then?
>
> There is no reason why you can't deallocate, since it is just plain old manual memory management. The wasm allocator follows the stdx allocator so you can build on that.
>
> I did experiment with a GC last year but I abandoned that in favor of porting druntime to wasm. The problems I ran into were mostly because 'new' isn't templated, so no amount of work I did would allow people to simply 'new' things, and instead they would always be stuck with custom allocators. Which is fine for some, but it is really barebones.

I've been wondering, is it possible to make gc take an allocator for memory allocation, instead of manually querying OS for that?

If it is possible, then it would make possible to use new in wasm, by just passing wasm allocator to it.

On Saturday, 1 August 2020 at 08:42:49 UTC, Alexandru Ermicioi wrote:
> On Friday, 31 July 2020 at 21:18:25 UTC, Sebastiaan Koppe wrote:
>> I did experiment with a GC last year but I abandoned that in favor of porting druntime to wasm. The problems I ran into were mostly because 'new' isn't templated, so no amount of work I did would allow people to simply 'new' things, and instead they would always be stuck with custom allocators. Which is fine for some, but it is really barebones.
>
> I've been wondering, is it possible to make gc take an allocator for memory allocation, instead of manually querying OS for that?

Yep, that is what I am doing in the wasm port of druntime. Instead of querying memory from the OS it calls the appropriate wasm functions to increase memory (which function a lot like sbrk.)

The GC uses memory mapping to fetch and return memory. Wasm doesn't support it so I wrote a simple freelist on top of the wasm memory functions https://github.com/skoppe/druntime/blob/wasm/src/gc/os.d#L180 so that I could connect it to the GC (I can't use stdx allocator in druntime).

> If it is possible, then it would make possible to use new in wasm, by just passing wasm allocator to it.

There is another problem with using 'new'. It isn't available in betterC, which means you need most of druntime first, before you can use it.

On Saturday, 1 August 2020 at 11:19:46 UTC, Sebastiaan Koppe wrote:
> The GC uses memory mapping to fetch and return memory. Wasm doesn't support it so I wrote a simple freelist on top of the wasm memory functions https://github.com/skoppe/druntime/blob/wasm/src/gc/os.d#L180 so that I could connect it to the GC (I can't use stdx allocator in druntime).

I see, can you explain reason why you can't use stdx allocator in druntime?

Ofc, we can't make direct dependency between druntime and external lib, so I was thinking is it possible to abstract raw memory allocation in gc into some kind of interface, and then just write adaptor to wasm stdx for that interface, or any other stdx compliant allocator or std.experimental allocator?

On Saturday, 1 August 2020 at 16:32:16 UTC, Alexandru Ermicioi wrote:
> On Saturday, 1 August 2020 at 11:19:46 UTC, Sebastiaan Koppe wrote:
>> The GC uses memory mapping to fetch and return memory. Wasm doesn't support it so I wrote a simple freelist on top of the wasm memory functions https://github.com/skoppe/druntime/blob/wasm/src/gc/os.d#L180 so that I could connect it to the GC (I can't use stdx allocator in druntime).
>
> I see, can you explain reason why you can't use stdx allocator in druntime?
>
> Ofc, we can't make direct dependency between druntime and external lib, so I was thinking is it possible to abstract raw memory allocation in gc into some kind of interface, and then just write adaptor to wasm stdx for that interface, or any other stdx compliant allocator or std.experimental allocator?

If you look in the os.d file I linked to earlier you will notice that it contains many versions of os_mem_map/os_mem_unmap for all kinds of targets. It is the interface you speak of.

On Saturday, 1 August 2020 at 11:19:46 UTC, Sebastiaan Koppe wrote:
>> If it is possible, then it would make possible to use new in wasm, by just passing wasm allocator to it.
>
> There is another problem with using 'new'. It isn't available in betterC, which means you need most of druntime first, before you can use it.

I'm really looking forward to this working, I have a video game code base that I can't realistically rewrite to not use 'new'. My goal was to port it to WASM+WebGL.