Some thought about crashes when calling js from Nim

[clzls]

Similar to #5 , I went into some crashes when working with hello_world.nim using Nimble package.
In devel mode it crashes silently when clicked, in release mode it works but sometimes it still crashes.
I tried to change webui.nim:261 from

data = buffer.join().strip(leading = false, chars = {'\x00'})

to

data = $(cast[cstring](addr buffer[0]))

Then it seems to work smoothly, with thread:off. Not tested much and not using nightly build, but I want to note it here for others who is willing to make further investigations about it.

My env: Nim Compiler Version 1.6.12 [Windows: amd64]

[neroist]

Ah, thank you for this issue and the fix! I really haven't run into this issue, I wonder why that would cause an error 🤔

[neroist]

I've already opened a PR but I think it would be better if you opened one instead.

[clzls]

Ah, thank you for this issue and the fix! I really haven't run into this issue, I wonder why that would cause an error 🤔

I didn't know either since no exceptions or messages were shown (either Nim side or browser side) in my case, so I didn't open a PR at the first time...

As #17 has more details about the problem, I think we could close this one.

[clzls]

Some other thought: There are some calls returning webui-managed buffers, like encode. Would it be better if we copy the data to a Nim-managed string (by $) and destroy the returned buffers immediately? 😄

[AlbertShown]

I agree @clzl 👍
We should not forget to free the WebUI buffer using webui_free()

WebUI uses a custom memory management to allocate and free resources, so webui_free() will never cause a crash.

[neroist]

Some other thought: There are some calls returning webui-managed buffers, like encode. Would it be better if we copy the data to a Nim-managed string (by $) and destroy the returned buffers immediately? 😄

b26d95c 🎉