D Language Foundation Monthly Meeting Summary for December 2022

[Hipreme]

On Monday, 23 January 2023 at 21:26:56 UTC, H. S. Teoh wrote:
> On Mon, Jan 23, 2023 at 08:43:03PM +0000, Adam D Ruppe via 
> Digitalmars-d-announce wrote:
>> On Monday, 23 January 2023 at 20:06:46 UTC, H. S. Teoh wrote:
>> > There should be a tool for auto-generating JS wrappers, 
>> > perhaps even HTML snippets, so that a user literally can 
>> > just write:
>> > 
>> > 	import std;	// OK, maybe import std.wasm or something
>> > 	void main() { writeln("Hello, world!");
>> > and get a webpage that prints that message in a browser 
>> > window
>> > without writing a single line of JS or HTML.
>> 
>> http://webassembly.arsdnet.net/
>> 
>> Paste in
>> import std.stdio;
>> void main() { writeln("hello world"); }
>> 
>> to the box on that page
>> 
>> and get
>> http://webassembly.arsdnet.net/usertemp
>
> Ahahahaha...  just like Adam to have already dunnit while I'm 
> still twiddling my fingers wondering how to go about doing it. 
> :-D  Now all we need is to package your little page up into a 
> dub package or something (personally I prefer just a tarball) 
> and we're good to go. :-D
>
>
>> Webassembly is a trash target but like been there done that.
>
> Yeah TBH after dabbling with it a little I realized just how 
> much it was still dependent on JS to do the heavy lifting.  You 
> can't even pass strings across the JS/WASM boundary without 
> truckloads of JS boilerplate.  The C-like API isn't officially 
> part of the WASM standard yet, and they're still trying to 
> figure out how GC might work. As far as I'm concerned, it's 
> still early adopter tech, not yet stable enough for me to 
> invest in.
>
>
>> Of course there are some caveats in what works, there have 
>> been come contributions coming in from hipreme recently to 
>> extend it a lil.
>
> Nice.  Can it handle WebGL yet?  I betcha that'd be the second 
> question a newbie to D would ask after asking about WASM. :-P
>
>
> T


I was going to wait a little bit on that announcement. But yes, 
Hipreme Engine has already been completely ported to WASM. File 
loading, rendering with my abstraction, audio playing, 
image/audio decoding, input system, I've got pretty much 
everything working. WASM only changed in my engine how the file 
loading is handled internally. An example, It sends D delegates 
to JS execute when things are complete, so, there isn't anymore a 
sync API for loading files.

I have used arsd.cgi for making it easy to any D programmer host 
it with dub. I have posted on Learn like yesterday how to 
integrate the custom runtime with any dub project too, which is 
how I'm using to build for my engine.

The list of features being supported are:

- new
- string switch
- classes (inheritance and abstract included)
- interfaces
- every array operation
- every associative array operation
- RAII
- delegates and function pointers
- assertion
- throw should work. Catching don't
- RTTI (typeid and other things that depends on it)
- All the compile time features seems to be working finely
- main() and it will run as expected.
- string utf decoding


Unsupported features:

- static this/~this (should be easy to implement though, my 
engine has no need to do that, specially since it uses a lot of 
DLL for Android and Xbox and static this is quite buggy for it 
anyway)
- try/catch
- fibers

The problem on try/catch/fiber are the same. They need stack 
unwinding and from what I've looked, this implementation needs 
compiler developers to write a little of assembly to get this 
working, as I have no idea on how that works, I can't implement 
that.

I believe this covers like 90% the usage of one using the 
druntime.

I honestly don't care about throw/catch. Specially for gamedev 
which is my aim, the code doesn't need to "protect" from itself.

That being said, if one is not using Hipreme Engine and is using 
a lot of standard library, this one would need to implement a lot 
of it. Hipreme Engine implements a minimal phobos (as I don't 
implement the entire libc) for being used. Needless to say, some 
modules from phobos didn't need to adapt to WASM, so, 
`std.algorithm` and `std.traits` are being used from upstream.

std.math was possible to copy/paste without too much work to do 
(A matter of 5 lines I think).

I'm also using arsd.ttf to runtime create text textures, a 
library which does not uses any of my modules, no bug was found 
on it, so, this is mostly a matter of giving a little of effort 
and everything can be done.