January 24, 2023
On Monday, 23 January 2023 at 21:26:56 UTC, H. S. Teoh wrote:
> On Mon, Jan 23, 2023 at 08:43:03PM +0000, Adam D Ruppe via Digitalmars-d-announce wrote:
>> On Monday, 23 January 2023 at 20:06:46 UTC, H. S. Teoh wrote:
>> > There should be a tool for auto-generating JS wrappers, perhaps even HTML snippets, so that a user literally can just write:
>> > 
>> > 	import std;	// OK, maybe import std.wasm or something
>> > 	void main() { writeln("Hello, world!");
>> > and get a webpage that prints that message in a browser window
>> > without writing a single line of JS or HTML.
>> 
>> http://webassembly.arsdnet.net/
>> 
>> Paste in
>> import std.stdio;
>> void main() { writeln("hello world"); }
>> 
>> to the box on that page
>> 
>> and get
>> http://webassembly.arsdnet.net/usertemp
>
> Ahahahaha...  just like Adam to have already dunnit while I'm still twiddling my fingers wondering how to go about doing it. :-D  Now all we need is to package your little page up into a dub package or something (personally I prefer just a tarball) and we're good to go. :-D
>
>
>> Webassembly is a trash target but like been there done that.
>
> Yeah TBH after dabbling with it a little I realized just how much it was still dependent on JS to do the heavy lifting.  You can't even pass strings across the JS/WASM boundary without truckloads of JS boilerplate.  The C-like API isn't officially part of the WASM standard yet, and they're still trying to figure out how GC might work. As far as I'm concerned, it's still early adopter tech, not yet stable enough for me to invest in.
>
>
>> Of course there are some caveats in what works, there have been come contributions coming in from hipreme recently to extend it a lil.
>
> Nice.  Can it handle WebGL yet?  I betcha that'd be the second question a newbie to D would ask after asking about WASM. :-P
>
>
> T


I was going to wait a little bit on that announcement. But yes, Hipreme Engine has already been completely ported to WASM. File loading, rendering with my abstraction, audio playing, image/audio decoding, input system, I've got pretty much everything working. WASM only changed in my engine how the file loading is handled internally. An example, It sends D delegates to JS execute when things are complete, so, there isn't anymore a sync API for loading files.

I have used arsd.cgi for making it easy to any D programmer host it with dub. I have posted on Learn like yesterday how to integrate the custom runtime with any dub project too, which is how I'm using to build for my engine.

The list of features being supported are:

- new
- string switch
- classes (inheritance and abstract included)
- interfaces
- every array operation
- every associative array operation
- RAII
- delegates and function pointers
- assertion
- throw should work. Catching don't
- RTTI (typeid and other things that depends on it)
- All the compile time features seems to be working finely
- main() and it will run as expected.
- string utf decoding


Unsupported features:

- static this/~this (should be easy to implement though, my engine has no need to do that, specially since it uses a lot of DLL for Android and Xbox and static this is quite buggy for it anyway)
- try/catch
- fibers

The problem on try/catch/fiber are the same. They need stack unwinding and from what I've looked, this implementation needs compiler developers to write a little of assembly to get this working, as I have no idea on how that works, I can't implement that.

I believe this covers like 90% the usage of one using the druntime.

I honestly don't care about throw/catch. Specially for gamedev which is my aim, the code doesn't need to "protect" from itself.

That being said, if one is not using Hipreme Engine and is using a lot of standard library, this one would need to implement a lot of it. Hipreme Engine implements a minimal phobos (as I don't implement the entire libc) for being used. Needless to say, some modules from phobos didn't need to adapt to WASM, so, `std.algorithm` and `std.traits` are being used from upstream.

std.math was possible to copy/paste without too much work to do (A matter of 5 lines I think).

I'm also using arsd.ttf to runtime create text textures, a library which does not uses any of my modules, no bug was found on it, so, this is mostly a matter of giving a little of effort and everything can be done.
January 24, 2023

On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote:

>

Robert thinks Rust has won that game. We're the second person to the moon.

Do you mean second to last? The safety offered by D language currently only looks good when compared to C/C++, but is worse than pretty much any of the other popular/mainstream languages. D language even did not invent memory safety, because the other safe languages existed long before it (such as Python, etc.).

The strong point of D language is a convenient syntax combined with full native speed of compiled binaries. And also compilation speed for those who care about it. But the safety is not exactly great. And compatibility breaking habits are also bad. D can't realistically compete with Rust on the safety front and with C/C++ on the compatibility front.

>

Put @safe on top, disallow taking addresses of the stack, don't allow returning ref, and don't allow pointer arithmetic. That's as safe as we need to be.

I like this proposal. Will it actually happen?

January 24, 2023
On 1/23/2023 11:21 PM, Siarhei Siamashka wrote:
> But the safety is not exactly great.

It does (and always has) resolved the #1 memory safety problem - buffer overflows.

If you use @safe, and the GC for allocations, it is just as memory safe as Python.

January 28, 2023

On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote:

>

The December meeting took place on the 3rd of the month at 15:00 UTC. The following people were present:

Razvan noted that simplifying the language is part of our vision, and this seems like a good candidate. Walter agreed. Dennis suggested going through DRuntime and Phobos to look at all instances of @property and seeing if they could be removed. Walter agreed.

Is there a document describing cases where removal of @property does not lead to an error but does lead to a change in behavior of code?

We are considering a blanket removal of 3000+ instances of @property. The resulting compile errors I can fix (unless they happen in speculative instantiations, they may be harder to track down), but I am especially worried about changes in behavior that do not lead to compile warnings/errors.

Thanks a lot,
Johan

January 28, 2023

On Saturday, 28 January 2023 at 13:04:33 UTC, Johan wrote:

>

Is there a document describing cases where removal of @property does not lead to an error but does lead to a change in behavior of code?

We are considering a blanket removal of 3000+ instances of @property. The resulting compile errors I can fix (unless they happen in speculative instantiations, they may be harder to track down), but I am especially worried about changes in behavior that do not lead to compile warnings/errors.

Given that the only thing @property actually does is change the result of typeof in certain situations, the behavior changes will probably be things like the following:

static if (typeof(foo.bar) == T) {
    // foo has a `T bar` property
} else {
    // doesn't have it
}

Currently, if foo has a @property T bar();, this code will take the first branch. If @property is removed, it will take the second.

January 28, 2023
On 1/28/2023 5:04 AM, Johan wrote:
> Is there a document describing cases where removal of `@property` does not lead to an error but does lead to a change in behavior of code?

No.

> We are considering a blanket removal of 3000+ instances of `@property`. The resulting compile errors I can fix (unless they happen in speculative instantiations, they may be harder to track down), but I am especially worried about changes in behavior that do not lead to compile warnings/errors.

It's been a while, but I think the only difference is if you're taking the address of a property. Without the @property, the address of the function will be taken. With @property, the address of the return value will be taken.

This will affect inference, such as `auto x = &s.foo;`

That will likely lead to type mismatch errors further down the line, but I can't guarantee it.

The best approach I can recommend is to remove the @propertys a handful at a time, checking them into git, and running your test suite to check for any failures. This will make `git bisect` invaluable in tracking down the cause of any errors that are missed by the test suite.

1 2
Next ›   Last »