Jump to page: 1 24  
Page
Thread overview
How to get to a class initializer through introspection?
Aug 02, 2020
Stefan Koch
Aug 03, 2020
Adam D. Ruppe
Aug 03, 2020
Stefan Koch
Aug 03, 2020
Adam D. Ruppe
Aug 04, 2020
Timon Gehr
Aug 02, 2020
Adam D. Ruppe
Aug 03, 2020
Adam D. Ruppe
Aug 03, 2020
Adam D. Ruppe
Aug 03, 2020
Adam D. Ruppe
Aug 03, 2020
Johan
Aug 03, 2020
Johan
Aug 03, 2020
Adam D. Ruppe
Aug 04, 2020
Adam D. Ruppe
Aug 04, 2020
Simen Kjærås
Aug 04, 2020
Johan
Aug 04, 2020
Johannes Pfau
Aug 05, 2020
Johannes Pfau
Aug 05, 2020
Johan
Aug 05, 2020
Johannes Pfau
Aug 05, 2020
Johan
Aug 06, 2020
Johannes Pfau
Aug 06, 2020
Johan
Aug 06, 2020
Johannes Pfau
Aug 05, 2020
Johan
Aug 03, 2020
Adam D. Ruppe
Aug 03, 2020
Johan
August 02, 2020
I'm working on redoing typeid for classes without compiler magic, and stumbled upon the class initializer - the bytes blitted over the class before the constructor is called.

Any ideas on how to do that via introspection? The fields are accessible, but not their default values.

It seems like __traits(type, getInitializer) might be necessary.
August 02, 2020
On Sunday, 2 August 2020 at 22:25:19 UTC, Andrei Alexandrescu wrote:
> I'm working on redoing typeid for classes without compiler magic, and stumbled upon the class initializer - the bytes blitted over the class before the constructor is called.
>
> Any ideas on how to do that via introspection? The fields are accessible, but not their default values.
>
> It seems like __traits(type, getInitializer) might be necessary.

So you are introducing new compiler magic in the form of __traits,
To replace the old compiler magic in the form of type-info?

What exactly is the goal of this?
August 02, 2020
On Sunday, 2 August 2020 at 22:25:19 UTC, Andrei Alexandrescu wrote:
> Any ideas on how to do that via introspection? The fields are accessible, but not their default values.

It is ugly but possible right now to pull in the symbol via extern(C).

See line 20 in my latest blog's example:

http://dpldocs.info/this-week-in-d/Blog.Posted_2020_07_27.html#zero-runtime-classes

ldc complains but it is a type mismatch not a fundamental barrier, I just didn't figure out the right thing to silence it yet.

> It seems like __traits(type, getInitializer) might be necessary.

but yes this would be generally nicer anyway imo.
August 03, 2020
On Sunday, 2 August 2020 at 22:48:51 UTC, Stefan Koch wrote:
> What exactly is the goal of this?

It makes pay-as-you-go runtime easier for specialized use cases at least.
August 03, 2020
On Monday, 3 August 2020 at 00:06:13 UTC, Adam D. Ruppe wrote:
> On Sunday, 2 August 2020 at 22:48:51 UTC, Stefan Koch wrote:
>> What exactly is the goal of this?
>
> It makes pay-as-you-go runtime easier for specialized use cases at least.

Isn't betterC supposed to do that?
August 03, 2020
On Monday, 3 August 2020 at 00:07:40 UTC, Stefan Koch wrote:
> Isn't betterC supposed to do that?

betterC is about just using the C runtime and doesn't allow you to use any of the D runtime, even if you want to.
August 02, 2020
On 8/2/20 6:48 PM, Stefan Koch wrote:
> On Sunday, 2 August 2020 at 22:25:19 UTC, Andrei Alexandrescu wrote:
>> I'm working on redoing typeid for classes without compiler magic, and stumbled upon the class initializer - the bytes blitted over the class before the constructor is called.
>>
>> Any ideas on how to do that via introspection? The fields are accessible, but not their default values.
>>
>> It seems like __traits(type, getInitializer) might be necessary.
> 
> So you are introducing new compiler magic in the form of __traits,
> To replace the old compiler magic in the form of type-info?
> 
> What exactly is the goal of this?

The idea is to minimize the compiler magic and shift most of the work to the library in an on-demand manner. Most of the typeid stuff is (somewhat surprisingly) moveable to library code. Moving the classinfo part will expose the holes in the __traits offering. Once the typeid stuff is in druntime, there are numerous opportunities for improving and extending it.
August 02, 2020
On 8/2/20 7:59 PM, Adam D. Ruppe wrote:
> On Sunday, 2 August 2020 at 22:25:19 UTC, Andrei Alexandrescu wrote:
>> Any ideas on how to do that via introspection? The fields are accessible, but not their default values.
> 
> It is ugly but possible right now to pull in the symbol via extern(C).
> 
> See line 20 in my latest blog's example:
> 
> http://dpldocs.info/this-week-in-d/Blog.Posted_2020_07_27.html#zero-runtime-classes 
> 
> 
> ldc complains but it is a type mismatch not a fundamental barrier, I just didn't figure out the right thing to silence it yet.
> 
>> It seems like __traits(type, getInitializer) might be necessary.
> 
> but yes this would be generally nicer anyway imo.

Holy Molly this works. FWIW here's what I plan to use: https://run.dlang.io/is/A6cbal. No need for __gshared because immutable stuff is already shared.

The only bummer is it can't be read during compilation, but I assume there'd be a chicken and egg problem if it were.

Thanks, Adam! Walter and I had absolutely no idea this can be done but we thought to post here on the off chance. Thanks again!
August 03, 2020
On Monday, 3 August 2020 at 00:37:48 UTC, Andrei Alexandrescu wrote:
> Holy Molly this works. FWIW here's what I plan to use: https://run.dlang.io/is/A6cbal. No need for __gshared because immutable stuff is already shared.

Yes, indeed.

> The only bummer is it can't be read during compilation, but I assume there'd be a chicken and egg problem if it were.

Eh, what if you did

class A {
    ubyte[__traits(classInstanceSize, A)] recursive;
}

it gives a forward reference error, but it works elsewhere and I think that's fair. We could probably do something similar with a hypothetical __traits(initializer).

So I think it is potentially possible and worth at least looking more into. My pragma(mangle) thing there was just a hack to make it work with today's dmd, but tomorrow's dmd could do a better job.

(what set me on this path btw was just a hunch I could put opCast in Object itself and hack up my own dynamic cast without druntime. Obviously, I didn't finish that for the blog, but it *is* possible, at least if you explicitly mixin something. That is what led me to posting this thread to muse how to change that: https://forum.dlang.org/thread/huheqhyjkgoroeulmotj@forum.dlang.org but it is still awkward to deal with interface offsets without help from the compiler regardless. But still prolly doable with some more time.)

> Thanks, Adam! Walter and I had absolutely no idea this can be done but we thought to post here on the off chance. Thanks again!

Y'all should read my blog :P

There's times when I go a full month with nothing to say since I get busy with day job work or around the house with family stuff etc. But I still try to slap something down at least once a month and I have a lot of magic tricks and just cool library stuff in there.

Next week I'll probably post my little Tetris game I slapped together on an airplane a couple weeks ago. So not much to learn about D magic tricks but sometimes it is nice to just show how easy fun things are to do too!
August 02, 2020
On 8/2/20 9:06 PM, Adam D. Ruppe wrote:
> Y'all should read my blog :P

Well said.

> There's times when I go a full month with nothing to say since I get busy with day job work or around the house with family stuff etc. But I still try to slap something down at least once a month and I have a lot of magic tricks and just cool library stuff in there.
> 
> Next week I'll probably post my little Tetris game I slapped together on an airplane a couple weeks ago. So not much to learn about D magic tricks but sometimes it is nice to just show how easy fun things are to do too!

Before you mentally get into that... maybe you can also say what the whole deal with OffsetTypeInfo and offTi is. I reckon it's a sort of information on members of a class, but my attempts have been fruitless:

https://run.dlang.io/is/68M1qn

« First   ‹ Prev
1 2 3 4