Re: Good News: Almost all druntime supported on arsd webassembly
On Friday, 6 January 2023 at 22:14:23 UTC, Ferhat Kurtulmuş wrote: One question. Does GC work with Adam's druntime for wasm? I haven't actually written one yet, so it leaks if you don't pay attention yourself. But I have a plan that should work: you do the setTimeout(collect, 0) so it runs when the event loop is idle. Then the wasm stack is empty so you can scan pure memory. IMHO, D's GC need a second thread This isn't true, it never needs a second thread, even on normal desktop. The problem with GC on wasm is the webasm stack is opaque. You can have the compiler output a shadow stack or my plan of scanning when it is empty. Either should work but I haven't had time to implement anything.
Re: Good News: Almost all druntime supported on arsd webassembly
On Friday, 6 January 2023 at 22:13:15 UTC, H. S. Teoh wrote: The big question I have right now is, what's the status of interfacing with web APIs such as WebGL? This part is really easy, you can call it from D with the opDispatch or pass it through as eval strings.
Re: Good News: Almost all druntime supported on arsd webassembly
On Friday, 6 January 2023 at 12:52:43 UTC, Hipreme wrote: Hello people. I have tried working again with adam's wasm minimal runtime, and yesterday I was able to make a great progress on it. [...] This sounds great. Thank you for your efforts. I will play around with it someday. I have not touched my pet game a while [1]. I used emscripten for sdl, and skoppe's druntime fork. One question. Does GC work with Adam's druntime for wasm? If yes, how? IMHO, D's GC need a second thread, which is a problem with wasm. 1: https://github.com/aferust/drawee
Re: Good News: Almost all druntime supported on arsd webassembly
On Fri, Jan 06, 2023 at 12:52:43PM +, Hipreme via Digitalmars-d-announce wrote: > Hello people. I have tried working again with adam's wasm minimal > runtime, and yesterday I was able to make a great progress on it. [...] > All those tests are currently passing. That means we almost got all > the common features from the D Runtime into Arsd custom runtime. > Meaning that the only thing that would be missing right now being the > WASI libc. But my engine is not going to use it entirely, only a > subset of it. So, I would like to say that whoever wants to play with > it now is able to do it so. > > > That being said, I would carefully advice that while I bring those > implementations, I didn't care about memory leaks, so, it is a runtime > without GC: careless allocations. But! It is possible to port some > programs specially if you're already doing house clearing yourself. As > my engine does not leak memory in loop (as that would make it trigger > the GC and thus make it slow), it is totally possible to use it. [...] This is awesome stuff, thanks for pushing ahead with it!! Keep this up, and I might actually decide to use your game engine for my projects. ;-) The big question I have right now is, what's the status of interfacing with web APIs such as WebGL? How much JS glue is needed for that to work? My dream is for all of the JS boilerplate to be automated away, so that I don't have to write a single line of JS for my D project to work in WASM. T -- Those who don't understand Unix are condemned to reinvent it, poorly.
Update on my D game
Hello, Yesterday I released a major update to my D-based game that I've been working on for about a year now, you can read about it here: https://kenny-shields.itch.io/imperium-scenario-system/devlog/472621/2023-01-05-physics-rework The game is a work in progress, so any feedback on bugs/instability/gameplay is appreciated. Thanks!
Re: Safer Linux Kernel Modules Using the D Programming Language
On Friday, 6 January 2023 at 04:07:12 UTC, areYouSureAboutThat wrote: btw. Linus one said, more or less, that one reason he likes C so much, is because when he is typing it, he can visualise what assembly will be produced (i.e. his mind is always intune with the code the machine will actually run). I wonder if he could every say the same about D code though (that's a question). btw. Just in case I misquoted him, I found the link: https://www.youtube.com/watch?v=CYvJPra7Ebk
Re: Builder: Tiny Utility Library to Add a Builder API to Classes
On Friday, 6 January 2023 at 12:54:07 UTC, Vijay Nayar wrote:
On Friday, 6 January 2023 at 09:26:51 UTC, thebluepandabear
wrote:
.isActive(true)
.build();
```
Good
how would I extend the builder methods?
The builder methods are automatically generated and go up the
inheritance chain to capture all the fields in your class. (I
assume that you are referring to inheritance when you say
"extend"?)
Here is one of the unit-tests demonstrating this:
```
class A2 {
int a;
string b;
}
class B2 : A2 {
int c;
mixin AddBuilder!(typeof(this));
}
/// All inherited fields should be available from the builder.
unittest {
B2 b2 = B2.builder()
.a(3)
.b("ham")
.c(4)
.build();
assert(b2.a == 3);
assert(b2.b == "ham");
assert(b2.c == 4);
}
```
I meant what if I want some extra behavior for the setter method
other than just assigning a value to the field. E.g. if I set a
password field, I might want to validate that it's valid.
Re: Builder: Tiny Utility Library to Add a Builder API to Classes
On Friday, 6 January 2023 at 09:26:51 UTC, thebluepandabear wrote:
.isActive(true)
.build();
```
Good
how would I extend the builder methods?
The builder methods are automatically generated and go up the
inheritance chain to capture all the fields in your class. (I
assume that you are referring to inheritance when you say
"extend"?)
Here is one of the unit-tests demonstrating this:
```
class A2 {
int a;
string b;
}
class B2 : A2 {
int c;
mixin AddBuilder!(typeof(this));
}
/// All inherited fields should be available from the builder.
unittest {
B2 b2 = B2.builder()
.a(3)
.b("ham")
.c(4)
.build();
assert(b2.a == 3);
assert(b2.b == "ham");
assert(b2.c == 4);
}
```
Good News: Almost all druntime supported on arsd webassembly
Hello people. I have tried working again with adam's wasm minimal
runtime, and yesterday I was able to make a great progress on it.
Currently, the only feature that I did not bother to implement
support for was the try/catch/finally/throw friends. Pretty much
only because I don't use in my engine. I would like to ask you
guys some feedback on its current usage, I have written a file
with only tests to the wasm runtime:
```d
// ldc2 -i=. --d-version=CarelessAlocation -i=std
-Iarsd-webassembly/ -L-allow-undefined -ofserver/omg.wasm
-mtriple=wasm32-unknown-unknown-wasm
arsd-webassembly/core/arsd/aa
arsd-webassembly/core/arsd/objectutils
arsd-webassembly/core/internal/utf
arsd-webassembly/core/arsd/utf_decoding hello
arsd-webassembly/object.d
import arsd.webassembly;
import std.stdio;
class A {
int _b = 200;
int a() { return 123; }
}
interface C {
void test();
}
interface D {
void check();
}
class B : A, C
{
int val;
override int a() { return 455 + val; }
void test()
{
rawlog(a());
int[] a;
a~= 1;
}
}
void rawlog(Args...)(Args a, string file = __FILE__, size_t line
= __LINE__)
{
writeln(a, " at "~ file~ ":", line);
}
struct Tester
{
int b = 50;
string a = "hello";
}
void main()
{
float[] f = new float[4];
assert(f[0] is float.init);
f~= 5.5; //Append
f~= [3, 4];
int[] inlineConcatTest = [1, 2] ~ [3, 4];
auto dg = delegate()
{
writeln(inlineConcatTest[0], f[1]);
};
dg();
B b = new B;
b.val = 5;
A a = b;
a.a();
C c = b;
c.test();
assert(cast(D)c is null);
Tester[] t = new Tester[10];
assert(t[0] == Tester.init);
assert(t.length == 10);
switch("hello")
{
case "test":
writeln("broken");
break;
case "hello":
writeln("Working switch string");
break;
default: writeln("What happenned here?");
}
string strTest = "test"[0..$];
assert(strTest == "test");
Tester* structObj = new Tester(50_000, "Inline Allocation");
writeln(structObj is null, structObj.a, structObj.b);
int[string] hello = ["hello": 500];
assert(("hello" in hello) !is null, "No key hello yet...");
assert(hello["hello"] == 500, "Not 500");
hello["hello"] = 1200;
assert(hello["hello"] == 1200, "Reassign didn't work");
hello["h2o"] = 250;
assert(hello["h2o"] == 250, "New member");
int[] appendTest;
appendTest~= 50;
appendTest~= 500;
appendTest~= 5000;
foreach(v; appendTest)
writeln(v);
string strConcatTest;
strConcatTest~= "Hello";
strConcatTest~= "World";
writeln(strConcatTest);
int[] intConcatTest = cast(int[2])[1, 2];
intConcatTest~= 50;
string decInput = "a";
decInput~= "こんいちは";
foreach(dchar ch; "こんいちは")
{
decInput~= ch;
writeln(ch);
}
writeln(decInput);
int[] arrCastTest = [int.max];
foreach(v; cast(ubyte[])arrCastTest)
writeln(v);
}
```
All those tests are currently passing. That means we almost got
all the common features from the D Runtime into Arsd custom
runtime. Meaning that the only thing that would be missing right
now being the WASI libc. But my engine is not going to use it
entirely, only a subset of it. So, I would like to say that
whoever wants to play with it now is able to do it so.
That being said, I would carefully advice that while I bring
those implementations, I didn't care about memory leaks, so, it
is a runtime without GC: careless allocations. But! It is
possible to port some programs specially if you're already doing
house clearing yourself. As my engine does not leak memory in
loop (as that would make it trigger the GC and thus make it
slow), it is totally possible to use it.
"But why didn't you continued Skoppe's WASM work?", I literally
am not able to build LDC runtime no matter how hard I tried.
Doing that work on a minimal runtime was a lot easier.
If you do find any use in the work I've done, please do test it
as I'll benefit from both you guys test. If you find any
performance improvement on it, it'll be gladly be accepted.
I do not intend to replace the druntime with that. I've done the
minimal subset of features that makes my engine work for the web.
A real druntime is still expected and awaited by me.
The link to the PR to be tested can be found there:
https://github.com/adamdruppe/webassembly/pull/9
Re: Safer Linux Kernel Modules Using the D Programming Language
On Friday, 6 January 2023 at 10:29:30 UTC, H. S. Teoh wrote: On Fri, Jan 06, 2023 at 04:07:12AM +, areYouSureAboutThat via Digitalmars-d-announce wrote: [...] btw. Linus one said, more or less, that one reason he likes C so much, is because when he is typing it, he can visualise what assembly will be produced (i.e. his mind is always intune with the code the machine will actually run). That has stopped being true for at least a decade or more. C was designed to map well to the PDP-11's instruction set; modern CPU's are completely different beasts with out-of-order execution, cache hierarchy, multi-core, multi-thread per core, expanded instruction sets, and microcode. Why do you think, for example, that in the kernel functions and intrinsics are used for certain CPU-specific instructions? Because nothing in C itself corresponds to them. The closeness of C to the CPU is only an illusion. T Those statements, even if spoken recently, are just a way of maintaining PR. Elon also similarly calls C++ a bloated mess and that all high performance code at Tesla is in C, as if that's something to be proud of... their ultra safety critical software project being built using a very much unsafe-by-defualt-for-everything language... Nvidia made a good decision to use ADA/SPARK, IMO
Re: Safer Linux Kernel Modules Using the D Programming Language
On Fri, Jan 06, 2023 at 04:07:12AM +, areYouSureAboutThat via Digitalmars-d-announce wrote: [...] > btw. Linus one said, more or less, that one reason he likes C so much, is > because when he is typing it, he can visualise what assembly will be > produced (i.e. his mind is always intune with the code the machine will > actually run). That has stopped being true for at least a decade or more. C was designed to map well to the PDP-11's instruction set; modern CPU's are completely different beasts with out-of-order execution, cache hierarchy, multi-core, multi-thread per core, expanded instruction sets, and microcode. Why do you think, for example, that in the kernel functions and intrinsics are used for certain CPU-specific instructions? Because nothing in C itself corresponds to them. The closeness of C to the CPU is only an illusion. T -- Don't get stuck in a closet---wear yourself out.
Re: Builder: Tiny Utility Library to Add a Builder API to Classes
.isActive(true) .build(); ``` Good how would I extend the builder methods?
Re: Builder: Tiny Utility Library to Add a Builder API to Classes
On Thursday, 5 January 2023 at 23:31:36 UTC, Vladimir Marchevsky
wrote:
On Thursday, 5 January 2023 at 21:48:40 UTC, Vijay Nayar wrote:
2. Using a constructor with many arguments.
```
A a = new A("Bob", 20, false, true);
```
This approach can construct arguments inline, such as during a
function call, however, the arguments are not labeled, making
it easy to get the order wrong or for the meaning to be
unclear.
Hopefully we'll finally have named arguments. Considering they
were accepted to language more than two years ago - maybe in
the next century...
Named arguments would definitely obviate this tool, but in the
meanwhile, this tool basically lets you achieve the same
objectives in terms of single-expression construction and clearly
labeled arguments. I guess one extra advantage of the `builder`
library is that you also don't have to bother writing a
constructor at all and can just use the default one.
