On Tuesday, 8 May 2018 at 09:51:11 UTC, Mike Franklin wrote:
I've been recently assigned the task of building a web-based Ladder Logic editor/compiler (https://en.wikipedia.org/wiki/Ladder_logic). This would not be a short-lived application, however.
Hmm, sounds like this would be an interactive application that would need access to the HTML DOM. Currently, this isn't directly possible - when running in an asm.js VM, there is no D type to represent a JavaScript object. It is possible to call out to / eval JavaScript, though, so perhaps it could be possible using a shim, where a JavaScript array holds JavaScript/DOM objects, and D refers to them by index.
I'm not sure if I would be much help with this, but know that there is demand for it. I think the difficult part would be porting the D runtime to "browser" environment, and I'm not sure what's involved with that, especially given all platform dependencies that the runtime is currently bound to.
Here are some of the challenges with getting D to run on emscripten:
- Emscripten is neither Windows nor Posix, which causes most version(platform){...}else... blocks to fail. Emscripten does provide a libc (based on glibc, I think) which even abstracts some things like I/O and the filesystem, but the feature set is definitely less complete than the platforms we currently support, so there's lots of stubbing involved.
- As a result of this, some parts of Phobos simply have no way of working correctly. For example, a good part of std.math concerns itself with the floating-point environment and flags, but in our case these all come down to "whatever the browser gives you" - which is probably standardized, but not under your control. So, these definitions would need a version(dscripten){}else wrapper.
- In theory, garbage collection might be made to work, with extensive help from the compiler. The problem is that we are still using JavaScript's stack, which means we can't scan it for pointers. It could be worked around by getting the compiler to also place references to heap objects somewhere else, like a second stack. For the short term, a practical approach would be to use @nogc memory allocation / container libraries (std.allocator etc.) and minimize GC allocations (e.g. closures are still nice to have).
- Exceptions do not work - throwing simply aborts. C++ exceptions do work in emscripten, so I think this could be made to work if a compiler guru spends some time on it.
- Threads look like they could be made to work - emscripten seems to have some wrappers to create/control Web Workers through a libpthreads-like API.
