Re: A bit more Emscripten
On Thursday, 10 May 2018 at 08:32:07 UTC, Vladimir Panteleev wrote: On Tuesday, 8 May 2018 at 08:53:36 UTC, Vladimir Panteleev wrote: https://github.com/CyberShadow/dscripten-tools Progress update: - std.stdio.writeln() works - Using a D main() works (though unittests and static constructors still don't) - WebAssembly output works! - std.allocator works (at least, Mallocator + building-blocks do) Very cool, Vladimir. When I get time we will try to see if it's useful for some internal prototype tools.
Re: A bit more Emscripten
On Tuesday, 8 May 2018 at 08:53:36 UTC, Vladimir Panteleev wrote: https://github.com/CyberShadow/dscripten-tools Progress update: - std.stdio.writeln() works - Using a D main() works (though unittests and static constructors still don't) - WebAssembly output works! - std.allocator works (at least, Mallocator + building-blocks do)
Re: A bit more Emscripten
On Tuesday, 8 May 2018 at 08:53:36 UTC, Vladimir Panteleev wrote: I heard there was a bit of general interest on the subject, so would be interesting to hear about more potential use cases. Like Franklin, I am programming a web page. It works fully with script, even the html elements are described in the script, not at the html document. Since JavaScript sucks as a source language, I use Bridge.NET to compile C# to it. From day one I decided that if my web page needs custom server code someday, Vibe.d is the first thing I will look at. With so much logic on client-side, it is a tempting thought to use D there too. I have made a few test runs with LDC/Emscripten, but the biggest problem is unability to call most HTML element logic directly. Emsrcipten does have a c++ module to call custom JS classes, I am going to try it with Calypso someday. This work is not exactly what I was looking for, as if I can call JavaScript I'll be able to call it's functions which should remove most of the need for a runtime, memory management excluded. Definitely I can see it useful and worth following nonetheless: It will make porting a desktop application to a web page easier, or vice-versa. It's a tantalizing thought that one could start developing an application and only later decide whether a browser will host it or no. Of course, this would for most cases require a GUI that works in both enviroments.
Re: A bit more Emscripten
On Tuesday, 8 May 2018 at 18:44:06 UTC, Vladimir Panteleev wrote: 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. Maybe we could port something like this to D. Or wait till someday dpp can #include the STL. https://github.com/mbasso/asm-dom/blob/master/README.md
Re: A bit more Emscripten
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.
Re: A bit more Emscripten
On Tuesday, 8 May 2018 at 08:53:36 UTC, Vladimir Panteleev wrote: I heard there was a bit of general interest on the subject, so would be interesting to hear about more potential use cases. 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. I'd like to use D so I can take advantage of its fantastic modeling features to help manage the complexity of building such tool. It would also be more familiar, and therefore more productive, for me to use a language like D, so I don't have to do so much study and figuring to implement my ideas in Javascript, or learn some new API/framework/library/tool/whatever. One of my primary motivations for learning D is to avoid having to learn a different programming language for every different platform or problem domain: modeling power, modern convenience, and native efficiency are the trifecta for me (we should have kept that motto, IMO). Add some platform independence, and I'm extremely happy. For now, unfortunately, it looks like I'll probably be using primarily Javascript and C#. 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. Mike
A bit more Emscripten
https://github.com/CyberShadow/dscripten-tools This builds a little upon Sebastien Alaiwan (Ace17)'s excellent prior work of putting together a toolchain for compiling D to JavaScript / asm.js. Improvements include a DMD-like driver and rdmd wrapper, meaning that most tools that know how to use dmd/rdmd will be able to also use this toolchain. Dub is an example. Currently the focus is on headless scripts - Web Workers and Node. Also included are some hacked up parts of Phobos/Druntime. Generally such environments are restricted to @nogc stuff, but I wanted to see how far we can get without prior restrictions. As a result, things like Appender and format(...) (i.e. formatting to the heap) work. Of course, garbage collection is unavailable - it's using the "manual" GC implementation (allocates only), though considering most webpages are short-lived, it might not be a problem for many use cases. I heard there was a bit of general interest on the subject, so would be interesting to hear about more potential use cases.
