Thread overview | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
December 18, 2016 ModuleInfo, factories, and unittesting | ||||
---|---|---|---|---|
| ||||
Compulsive ModuleInfo generation seems to be a drag. I'm not very familiar with the particulars but my understanding is ModuleInfo is needed for (a) Object.factory and (b) finding and running unittests. Walter and I think Object.factory was a mistake and we'd like to make it opt-in long term (either by means of a build flag or a class attribute). Until then, a very nice step forward is to NOT generate ModuleInfo if a module introduces no class. For unittests, I figure things like static introspection should make it easier to enumerate and run unittests without a need for ModuleInfo. What other issues/opportunities do you see related to ModuleInfo? Thanks, Andrei |
December 18, 2016 Re: ModuleInfo, factories, and unittesting | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Sunday, 18 December 2016 at 16:53:24 UTC, Andrei Alexandrescu wrote:
> Compulsive ModuleInfo generation seems to be a drag. I'm not very familiar with the particulars but my understanding is ModuleInfo is needed for (a) Object.factory and (b) finding and running unittests.
>
> Walter and I think Object.factory was a mistake and we'd like to make it opt-in long term (either by means of a build flag or a class attribute).
>
> Until then, a very nice step forward is to NOT generate ModuleInfo if a module introduces no class.
>
> For unittests, I figure things like static introspection should make it easier to enumerate and run unittests without a need for ModuleInfo.
>
> What other issues/opportunities do you see related to ModuleInfo?
>
>
> Thanks,
>
> Andrei
If ModuleInfo were to be opt in, would that mean it could be expanded then, to include things like class/struct fields?
|
December 19, 2016 Re: ModuleInfo, factories, and unittesting | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 19/12/2016 5:53 AM, Andrei Alexandrescu wrote: > Compulsive ModuleInfo generation seems to be a drag. I'm not very > familiar with the particulars but my understanding is ModuleInfo is > needed for (a) Object.factory and (b) finding and running unittests. > > Walter and I think Object.factory was a mistake and we'd like to make it > opt-in long term (either by means of a build flag or a class attribute). > > Until then, a very nice step forward is to NOT generate ModuleInfo if a > module introduces no class. > > For unittests, I figure things like static introspection should make it > easier to enumerate and run unittests without a need for ModuleInfo. > > What other issues/opportunities do you see related to ModuleInfo? > > > Thanks, > > Andrei I've been toying with the idea of completely overhauling TypeInfo. Here is the gist of what I want: - -typeinfo=low/low-min/normal/high/none None is pretty much -betterC Low would be unittests + module constructors Low-min would be like low but with only the fields that is needed Normal is what we have now more or less High of course includes all the goodies like class fields and methods reflection - Full class + struct + union symbol reflection, so fields uda's ext. My feeling is D really is two different languages. An application one and a system one. The difference isn't much. It really comes down to how hooked into druntime it is and so TypeInfo. From there we just need to remove all language features that require druntime or allow a way to you know, clear deallocation path. |
December 18, 2016 Re: ModuleInfo, factories, and unittesting | ||||
---|---|---|---|---|
| ||||
Posted in reply to rikki cattermole | On Sunday, 18 December 2016 at 22:55:30 UTC, rikki cattermole wrote:
> - -typeinfo=low/low-min/normal/high/none
> None is pretty much -betterC
> Low would be unittests + module constructors
> Low-min would be like low but with only the fields that is needed
> Normal is what we have now more or less
> High of course includes all the goodies like class fields and methods reflection
> - Full class + struct + union symbol reflection, so fields uda's ext.
IMO, this seems like too much. I think none/minimal/full would be easier, where minimal would be equivalent to what's currently available right now. My specific concern is compatibility between compiled objects and knowing what symbols to expect. Also, just keeping the question of which level to use simple. If one object file was compiled without unittests, for example, a project as a whole could pass without error, but actually be broken..couldn't it?
|
December 19, 2016 Re: ModuleInfo, factories, and unittesting | ||||
---|---|---|---|---|
| ||||
Posted in reply to bitwise | On 19/12/2016 12:37 PM, bitwise wrote:
> On Sunday, 18 December 2016 at 22:55:30 UTC, rikki cattermole wrote:
>> - -typeinfo=low/low-min/normal/high/none
>> None is pretty much -betterC
>> Low would be unittests + module constructors
>> Low-min would be like low but with only the fields that is needed
>> Normal is what we have now more or less
>> High of course includes all the goodies like class fields and
>> methods reflection
>> - Full class + struct + union symbol reflection, so fields uda's ext.
>
>
> IMO, this seems like too much. I think none/minimal/full would be
> easier, where minimal would be equivalent to what's currently available
> right now. My specific concern is compatibility between compiled objects
> and knowing what symbols to expect. Also, just keeping the question of
> which level to use simple. If one object file was compiled without
> unittests, for example, a project as a whole could pass without error,
> but actually be broken..couldn't it?
Yes, if you don't include unittests via none, then it won't be tested.
The only one of my suggestions that actually breaks typeinfo definitions is that of low-min. This is for memory constrained situations like kernels or MCU's but when you still want features such as unittesting and module constructors.
All others will happily interlink without error.
Overall, when the question is simple, the answer is too. Here the question isn't simple and so my answer isn't either.
You've got to take into consideration that bloat depends on use case e.g. normal may very well be considered bloated by game dev standards while full is just about right for web applications.
|
December 18, 2016 Re: ModuleInfo, factories, and unittesting | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Sunday, 18 December 2016 at 16:53:24 UTC, Andrei Alexandrescu wrote: > Compulsive ModuleInfo generation seems to be a drag. I'm not very familiar with the particulars but my understanding is ModuleInfo is needed for (a) Object.factory and (b) finding and running unittests. > > Walter and I think Object.factory was a mistake and we'd like to make it opt-in long term (either by means of a build flag or a class attribute). > Don't forget that typeinfos are classes too, which makes the class attribute approach less attractive. > Until then, a very nice step forward is to NOT generate ModuleInfo if a module introduces no class. > Module (static) ctors & dtors need MI. > For unittests, I figure things like static introspection should make it easier to enumerate and run unittests without a need for ModuleInfo. > We have __traits(getUnitTests,...) but the way to do DIY unittests is foreach(m; ModuleInfo) foreach(test; __traits(getUnitTests,m) test(); > What other issues/opportunities do you see related to ModuleInfo? > AFAIK a module info is basically struct ModuleInfo { alias F = void function(); ModuleInfo* parent; string name; // may be static char array F s_ctor; // Static constructor F s_dtor; F ctor; // Thread local constructor F dtor; F unittester; //may be an array for each block void function(Object)[string] factory_mapping; //Foward to argless ctor, not sure what mapping is actually used. } If we optionally remove Object.factory, and move the unittests elsewhere (where to?) we are left with the ctors and dtors. If we store these as SoA then we minimise space (as few modules define *tors), but lose the mapping from Module -> *tor, but these are defined to be run in an implementation defined order anyway so no big loss. This is only a problem when dealing with multiple libraries compiled separately and dynamic libraries, but if the dynamic libs store their own SoA'd *tors and we merge the static libs Arrays at link time** then we have nothing useful left in the module info. If we could get factory_mapping mergeable at link-time then we would get a pay for what you use ** I don't know if this is possible, I don't mean merge duplicate symbols, I mean liba.a defines 3 module ctors, so does libb.a -> link == one ctor symbol 6 entries. Similar to what is done for C's global constructors, they end up in one big list. > > Thanks, > > Andrei |
December 18, 2016 Re: ModuleInfo, factories, and unittesting | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nicholas Wilson | On 12/18/16 6:48 PM, Nicholas Wilson wrote: > On Sunday, 18 December 2016 at 16:53:24 UTC, Andrei Alexandrescu wrote: >> Compulsive ModuleInfo generation seems to be a drag. I'm not very >> familiar with the particulars but my understanding is ModuleInfo is >> needed for (a) Object.factory and (b) finding and running unittests. >> >> Walter and I think Object.factory was a mistake and we'd like to make >> it opt-in long term (either by means of a build flag or a class >> attribute). >> > > Don't forget that typeinfos are classes too, which makes the class > attribute approach less attractive. > >> Until then, a very nice step forward is to NOT generate ModuleInfo if >> a module introduces no class. >> > > Module (static) ctors & dtors need MI. Cool cool cool. Thanks. >> For unittests, I figure things like static introspection should make >> it easier to enumerate and run unittests without a need for ModuleInfo. >> > > We have __traits(getUnitTests,...) but the way to do DIY unittests is > foreach(m; ModuleInfo) > foreach(test; __traits(getUnitTests,m) > test(); Noice. Wait, the top foreach iterates what? >> What other issues/opportunities do you see related to ModuleInfo? >> > > AFAIK a module info is basically > > struct ModuleInfo > { > alias F = void function(); > > ModuleInfo* parent; > string name; // may be static char array > F s_ctor; // Static constructor > F s_dtor; > F ctor; // Thread local constructor > F dtor; > F unittester; //may be an array for each block > void function(Object)[string] factory_mapping; //Foward to argless > ctor, not sure what mapping is actually used. > } > > If we optionally remove Object.factory, and move the unittests elsewhere > (where to?) we are left with the ctors and dtors. If we store these as > SoA SoA = ? Andrei |
December 19, 2016 Re: ModuleInfo, factories, and unittesting | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Monday, 19 December 2016 at 00:00:36 UTC, Andrei Alexandrescu wrote: > On 12/18/16 6:48 PM, Nicholas Wilson wrote: >> [...] > > Cool cool cool. Thanks. > >> [...] > > Noice. Wait, the top foreach iterates what? > Its a compile time magic loop I think. Both of them. >> [...] > > SoA = ? > Structure of array. Think of a transpose of an array of structs, or consult the internet. > > Andrei |
December 19, 2016 Re: ModuleInfo, factories, and unittesting | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Sunday, 18 December 2016 at 16:53:24 UTC, Andrei Alexandrescu wrote: > What other issues/opportunities do you see related to ModuleInfo? I think it would be better to take a more holistic look at the relationship between the compiler and druntime. It's my understanding that many of the contracts between the compiler and druntime were written at at time when D didn't have things like templates and rich compile-time features. I think there is an opportunity to refactor the ModuleInfo, TypeInfo, and probably many other features, moving them out of the compiler into druntime (See http://forum.dlang.org/post/eiwalbqlbkipdrmsrfoh@forum.dlang.org for a precise explanation). Then, with druntime's source code containing templates, conditional compilation, static-if, and the like, when the user compiles their code it only generates code that is actually being used. It could even be taken further with something like this (http://forum.dlang.org/post/psssnzurlzeqeneagora@forum.dlang.org) where druntime's implementation is distributed as .di header files for compile-time verification and advantages beyond your original stated goal. Mike |
December 19, 2016 Re: ModuleInfo, factories, and unittesting | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 2016-12-18 17:53, Andrei Alexandrescu wrote: > For unittests, I figure things like static introspection should make it > easier to enumerate and run unittests without a need for ModuleInfo. We currently have no good way to collect unittest between modules. It's easy to collect them for a single specific module, but not globally. -- /Jacob Carlborg |
Copyright © 1999-2021 by the D Language Foundation