_d_allocmemory

[WebFreak001]

extern (C) export void _start()
{
    auto elem = document.createElement("div").as!HTMLElement;
    elem.style.backgroundColor = "green";
    elem.innerHTML = "BLA BLA!";
    elem.addEventListener("mouseover", (Event event) {
        elem.style.backgroundColor = "red";
        console.log("onmouseover");
        console.log(event);
        console.log(event.as!MouseEvent.clientX);
    });

    auto root = document.querySelector("body").front;
    root.appendChild(elem);
}

simply adding that elem.style.backgroundColor = "red"; makes it seem to allocate (probably delegate context so it can access the outer stack?)

Disregard that this code doesn't even work because the elem goes out of scope, I can't seem to read/write global variables as LLVM seems to fail then.

Anything going against just providing

extern (C) export void* _d_allocmemory(size_t sz)
{
    import spasm.rt.memory : allocator;

    return allocator.allocate(sz).ptr;
}

?

It seems to run without error then (though I don't know how correct it is because well the stack is invalid there anyway lol)

[skoppe]

simply adding that elem.style.backgroundColor = "red"; makes it seem to allocate (probably delegate context so it can access the outer stack?)

The allocation happens (as far as I can see) because it needs to put elem on the heap to allow the delegate to access it.

Disregard that this code doesn't even work because the elem goes out of scope, I can't seem to read/write global variables as LLVM seems to fail then

Probably a tls issue. Put a __gshared before the declaration.

Anything going against just providing

Not much, except, who is going to free it? I think it is a better idea that I focus on the mem issues I already have :)

Thanks for trying this stuff out! I use the bindings sparingly, as I am focused on the SPA framework part of spasm.

[skoppe]

I have implemented _d_allocmemory in 0.2.0-beta.1, so now you can take closures. There is still nothing that frees it though. That will require some changes in druntime and the dmd frontend.

Even though they still leak, if you keep the amount of closures limited there is no real danger.