Re: scone v2.1 - CLI text, colors, input library
On Monday, 19 November 2018 at 16:44:52 UTC, Martin Tschierschke wrote: On Monday, 19 November 2018 at 12:14:26 UTC, Vladimirs Nordholm wrote: https://github.com/vladdeSV/scone [...] Looks interesting! Hint - there is a broken link to: simple examples https://github.com/vladdeSV/scone/tree/master/examples Good catch! Fixed ;)
Re: scone v2.1 - CLI text, colors, input library
On Monday, 19 November 2018 at 12:14:26 UTC, Vladimirs Nordholm wrote: https://github.com/vladdeSV/scone [...] Looks interesting! Hint - there is a broken link to: simple examples https://github.com/vladdeSV/scone/tree/master/examples
Re: Ported js13k game underrun to D targeting webassembly
On Monday, 19 November 2018 at 11:13:52 UTC, Dukc wrote: I had a look at your code, and just now I realized that spasm can really call JavaScript without any glue from JavaScript side. I am not sure where you got that impression from, but I am afraid you'll still need js glue code. This is huge! Now I can start to think about expanding my usage of D at the web page I'm developing, potentially replacing parts of my application made with Bridge.NET. The only thing I did with spasm was to use a subset of the D language to define a declarative language for creating html components, and I used lots of introspection to optimise the rendering of them. Everything else comes from the wasm backend from llvm and it's support in ldc. I really appreciate you getting excited about it but look, Spasm is still in an early stage. The code is rough, the documentation poor. And it has plenty missing that needs to be fixed before you should consider writing anything serious with it. The two most important being bindings to all web apis and memory deallocation. Having said that, of course I want you to use it :) I know you did announce about Spasm earlier and I should have thanked you already. My fault: I realized that you made something that enables one to generate WebAsm, but didn't realize it enabled calling JS classes directly. Should have looked closer. The way calling js classes from D (or any language out there) works, is to insert the js object in a big associative array at the js side with an int as the key. The int (handle) is passed to D. Anytime D wants to call a function or retrieve a property of that class it calls some glue code with the handle as first parameter. In the javascript glue code the handle is used to lookup the object and the corresponding function is called. Since javascript allows you to call by string (e.g. `object["foobar"]()`), you can minimize glue code at the expense of decoding utf-8 strings. 1. Manually compile your code and parts of Druntime/Phobos targetting 32-bit X86, link them manually with llvm-link using --only-needed and only then compile to JavaScript (Haven't tried with WebAsm, but theoretically should compile the same way). This way you don't need to manually stub what you don't use -well, when the linkers have same ideas about what you're calling, which's not always the case. That might work, but for the end-user it really needs to be as simple as `dub build`. 2: Use Vladimir's DScripten. I haven't tried, as I was limited by not being aware of anything like spasm to call Web API, but probably easier than my method above and brings larger portions of Phobos into user's reach. Also IIRC Vladimir managed to get allocators working. Yep. The prototype version of spasm ran on top of dscripten-tools. I decided to move to native llvm wasm compilation instead, since I don't particularly like the emscripten toolchain. Even with my relatively meager method, pipeline-style programming with std.algorithm and std.range over (often static) arrays is doable and practical in my experience. As long as std.algorithms/ranges don't allocate, they work.
scone v2.1 - CLI text, colors, input library
https://github.com/vladdeSV/scone
Finally, after a year in pre-release hell, version v2.1.0 is
finally released.
Quickie about scone:
scone lets you use the CLI to make applications/games,
cross-platform. Text, colors, and inputs.
window.title = "Example 3";
window.resize(40, 10);
while (loop) {
window.clear();
window.write(
10, 5, // x, y
Color.yellow.foreground,
Color.white.background,
"scone"
);
foreach(input; window.getInputs()) {
if(!input.pressed) continue;
if(input.key == SK.right) loop = false;
}
window.print();
}
Finally, POSIX support isn's 100% perfect. Because ANSI and key
codes for inputs vary from system to system I can only do so much
on my OSX machine. Inputs specifically, where not all keys
register, multiple simultaneous keys don't always register, and
only key _presses_ are registered. If any of you find other bugs,
please report them on the Github page.
If you use this library, please tell me about it! Love seeing it
in use
Best regards,
Vladimirs Nordholm
Re: Ported js13k game underrun to D targeting webassembly
On Saturday, 17 November 2018 at 21:35:59 UTC, Sebastiaan Koppe wrote: [snip] I had a look at your code, and just now I realized that spasm can really call JavaScript without any glue from JavaScript side. This is huge! Now I can start to think about expanding my usage of D at the web page I'm developing, potentially replacing parts of my application made with Bridge.NET. I know you did announce about Spasm earlier and I should have thanked you already. My fault: I realized that you made something that enables one to generate WebAsm, but didn't realize it enabled calling JS classes directly. Should have looked closer. Things like: - almost no use of phobos (even at CTFE) D could definitely use some love in that area. I was specifically stumped that stdx.allocator doesn't work in betterC; if somewhere is a good place to use stdx.allocator you would expect it to be betterC, but alas. I agree. I, neither, have managed to link allocators in. But I quess you can use Phobos more than you think. Seeing how great stuff you have done, It may be that what I'm stating here may already be plain obvious to you, but I say it just in case anyway. You need a way to link in non-templated code. Two way's I'm aware of: 1. Manually compile your code and parts of Druntime/Phobos targetting 32-bit X86, link them manually with llvm-link using --only-needed and only then compile to JavaScript (Haven't tried with WebAsm, but theoretically should compile the same way). This way you don't need to manually stub what you don't use -well, when the linkers have same ideas about what you're calling, which's not always the case. 2: Use Vladimir's DScripten. I haven't tried, as I was limited by not being aware of anything like spasm to call Web API, but probably easier than my method above and brings larger portions of Phobos into user's reach. Also IIRC Vladimir managed to get allocators working. Even with my relatively meager method, pipeline-style programming with std.algorithm and std.range over (often static) arrays is doable and practical in my experience.
