Runtime introspection, or how to get class members at runtime Fin D
Hi, What is the state of runtime introspection in D, specifically for classes? Is there any way to get *at runtime* the (public or otherwise accessible) members of a class? I have had a look as TypeInfo_Class [1], but apparently I can only get a list of types and offsets... which would be almost good enough, if not because the names of the members are missing, or at least I haven't been able to find them. In this case, what I'm trying to do is to serialize / dump / print the contents of an object (class instance) without knowing its actual runtime type. Before somebody suggests compile time introspection, the "main" code where this routine lives only provides a base class, and it's up to dlopen'ed plugins to provide the actual implementation... so I'm sorry but no compile-time solution can possibly work. Also, having each derivative class provide their own dumping information is not practical, I'd rather have it automated. I know it might not be the most idiomatic D, but as somebody with mostly a Java background (with some C and just a bit of C++) it seems something really straightforward to me: myObject.getClass().getFields() [2]. Also, I know I could add some UDA or even crawl the modules and have this information generated automatically at compilation time and added to the type itself in a member, and I might even end up doing it, but honestly, I think it's something that the language should provide in a kind of easy / accessible way. Powerful as compile-time introspection is, I think runtime shouldn't be forgotten either :-) Thanks, A. [1]: https://dlang.org/library/object/type_info__class.html [2]: https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getFields--
Re: Runtime introspection, or how to get class members at runtime Fin D
On 07/06/2018 1:28 AM, Arafel wrote: Hi, What is the state of runtime introspection in D, specifically for classes? Is there any way to get *at runtime* the (public or otherwise accessible) members of a class? No. I have had a look as TypeInfo_Class [1], but apparently I can only get a list of types and offsets... which would be almost good enough, if not because the names of the members are missing, or at least I haven't been able to find them. You don't want TypeInfo. In this case, what I'm trying to do is to serialize / dump / print the contents of an object (class instance) without knowing its actual runtime type. Before somebody suggests compile time introspection, the "main" code where this routine lives only provides a base class, and it's up to dlopen'ed plugins to provide the actual implementation... so I'm sorry but no compile-time solution can possibly work. Also, having each derivative class provide their own dumping information is not practical, I'd rather have it automated. I know it might not be the most idiomatic D, but as somebody with mostly a Java background (with some C and just a bit of C++) it seems something really straightforward to me: myObject.getClass().getFields() [2]. Doesn't exist.
how to sort the container Array from std.container
I know that sort accepts Range( I am correct right ? ), so, Array!uint arr; //inserts element to arr sort( arr.Range ); don't work, it says cannot pass RangeT!(Array!uint) as function argument
Re: Runtime introspection, or how to get class members at runtime Fin D
On 06/06/2018 03:30 PM, rikki cattermole wrote: You don't want TypeInfo. Why not (genuine question)? There's even myObject.classinfo, and I can only assume that there's some reason why it's there... In this case, what I'm trying to do is to serialize / dump / print the contents of an object (class instance) without knowing its actual runtime type. Before somebody suggests compile time introspection, the "main" code where this routine lives only provides a base class, and it's up to dlopen'ed plugins to provide the actual implementation... so I'm sorry but no compile-time solution can possibly work. Also, having each derivative class provide their own dumping information is not practical, I'd rather have it automated. I know it might not be the most idiomatic D, but as somebody with mostly a Java background (with some C and just a bit of C++) it seems something really straightforward to me: myObject.getClass().getFields() [2]. Doesn't exist. Well, thanks for the quick and succinct answer... I guess the question now would be how realistic it would be to propose such an addition to the language... Has it already been discussed? (I tried searching the forum, but didn't find anything relevant) I know it's got a runtime penalty, but realistically speaking, spending some bytes for the field names in the TypeInfo of a class shouldn't be that much of a problem?
Re: how to sort the container Array from std.container
On Wednesday, 6 June 2018 at 13:44:09 UTC, Flaze07 wrote: sort( arr.Range ); don't work, it says cannot pass RangeT!(Array!uint) as function argument Range is the type, you want the value I think you can do sort(arr[]) maybe
Re: Runtime introspection, or how to get class members at runtime Fin D
On 07/06/2018 1:44 AM, Arafel wrote: On 06/06/2018 03:30 PM, rikki cattermole wrote: You don't want TypeInfo. Why not (genuine question)? There's even myObject.classinfo, and I can only assume that there's some reason why it's there... In this case, what I'm trying to do is to serialize / dump / print the contents of an object (class instance) without knowing its actual runtime type. Before somebody suggests compile time introspection, the "main" code where this routine lives only provides a base class, and it's up to dlopen'ed plugins to provide the actual implementation... so I'm sorry but no compile-time solution can possibly work. Also, having each derivative class provide their own dumping information is not practical, I'd rather have it automated. I know it might not be the most idiomatic D, but as somebody with mostly a Java background (with some C and just a bit of C++) it seems something really straightforward to me: myObject.getClass().getFields() [2]. Doesn't exist. Well, thanks for the quick and succinct answer... I guess the question now would be how realistic it would be to propose such an addition to the language... Has it already been discussed? (I tried searching the forum, but didn't find anything relevant) I know it's got a runtime penalty, but realistically speaking, spending some bytes for the field names in the TypeInfo of a class shouldn't be that much of a problem? It is not an easy task building a reflection API from scratch. I'm one of the many that have tried. There is also push back from those who consider it "bloat" and don't need it. You can't just extend TypeInfo, it was never designed for it.
Re: Runtime introspection, or how to get class members at runtime Fin D
On Wednesday, 6 June 2018 at 13:44:39 UTC, Arafel wrote: Why not (genuine question)? There's even myObject.classinfo, and I can only assume that there's some reason why it's there... It holds just barely enough info for dynamic casting, GC, and other language implementation stuff. (and then Object.factory for some weird reason, which actually causes bloat for so little benefit) Well, thanks for the quick and succinct answer... I guess the question now would be how realistic it would be to propose such an addition to the language... Has it already been discussed? It is possible to add it to the runtime library right now (there's a thing called rtInfo in there made to hold it, it is just null right now), just people fight over even a few bytes of added metadata. So if it is added, it would surely be some opt-in thing that will require your thing be recompiled anyway. If you can recompile the library, you can add a parallel extended info thing (MyReflectionInfo[TypeInfo] array perhaps, populated by a static this() ctor created via compile time reflection) that gives what you need. But if you can't recompile the library, the field names are simply not there
Re: how to sort the container Array from std.container
On Wednesday, 6 June 2018 at 13:46:41 UTC, Adam D. Ruppe wrote: On Wednesday, 6 June 2018 at 13:44:09 UTC, Flaze07 wrote: sort( arr.Range ); don't work, it says cannot pass RangeT!(Array!uint) as function argument Range is the type, you want the value I think you can do sort(arr[]) maybe I see why it works, so, [] is called slice operator right ? and in https://dlang.org/phobos/std_container_array.html#.Array.opSlice it returns range, so that's why it worked
Re: how to sort the container Array from std.container
On 07/06/2018 1:58 AM, Flaze07 wrote: On Wednesday, 6 June 2018 at 13:46:41 UTC, Adam D. Ruppe wrote: On Wednesday, 6 June 2018 at 13:44:09 UTC, Flaze07 wrote: sort( arr.Range ); don't work, it says cannot pass RangeT!(Array!uint) as function argument Range is the type, you want the value I think you can do sort(arr[]) maybe I see why it works, so, [] is called slice operator right ? and in https://dlang.org/phobos/std_container_array.html#.Array.opSlice it returns range, so that's why it worked Yes.
Re: Runtime introspection, or how to get class members at runtime Fin D
On 06/06/2018 03:52 PM, Adam D. Ruppe wrote:
It is possible to add it to the runtime library right now (there's a
thing called rtInfo in there made to hold it, it is just null right
now), just people fight over even a few bytes of added metadata. So if
it is added, it would surely be some opt-in thing that will require your
thing be recompiled anyway.
If I wanted to add it myself, would I need to create a personalised D
compiler and/or D Runtime? That would be probably way too much for me :)
Also, it would have to be distributed and used to create the plugins...
If you can recompile the library, you can add a parallel extended info
thing (MyReflectionInfo[TypeInfo] array perhaps, populated by a static
this() ctor created via compile time reflection) that gives what you need.
Yeah, I had some ideas in this regard, still I would like it to be
transparent from the plugin creator point of view, but I don't know if
it would be possible to contain everything in the base class... so far I
had though about a base class like this:
```
import std.traits;
import std.meta;
TypeInfo[string][TypeInfo_Class] RTInfo;
class Base {
this(this C)() {
if (typeid(C) in RTInfo)
return;
RTInfo[typeid(C)] = (TypeInfo[string]).init;
static foreach_reverse(Type; AliasSeq!(C, BaseClassesTuple!C)) {
static foreach(string field; FieldNameTuple!Type) {
RTInfo[typeid(Type)][field] =
typeid(typeof(__traits(getMember, Type, field)));
}
}
}
}
```
But I think children classes can bypass this constructor, so I guess
it's not so easy, will have to keep trying :-)
A templated static this would be cool, though:
class Base {
static this(this C)() {
// ...
}
}
Apparently it's not possible :-(
Re: how to sort the container Array from std.container
On Wednesday, 6 June 2018 at 14:06:54 UTC, rikki cattermole wrote: On 07/06/2018 1:58 AM, Flaze07 wrote: On Wednesday, 6 June 2018 at 13:46:41 UTC, Adam D. Ruppe wrote: On Wednesday, 6 June 2018 at 13:44:09 UTC, Flaze07 wrote: sort( arr.Range ); don't work, it says cannot pass RangeT!(Array!uint) as function argument Range is the type, you want the value I think you can do sort(arr[]) maybe I see why it works, so, [] is called slice operator right ? and in https://dlang.org/phobos/std_container_array.html#.Array.opSlice it returns range, so that's why it worked Yes. hmm, and sorry for asking more, what about removing an element from it ? I found no remove operation that can remove from the middle ( removeAny and removeBack both removes the latest element, linearRemove receive Array!uint...which don't know how to provide )
Re: how to sort the container Array from std.container
On 07/06/2018 2:20 AM, Flaze07 wrote: On Wednesday, 6 June 2018 at 14:06:54 UTC, rikki cattermole wrote: On 07/06/2018 1:58 AM, Flaze07 wrote: On Wednesday, 6 June 2018 at 13:46:41 UTC, Adam D. Ruppe wrote: On Wednesday, 6 June 2018 at 13:44:09 UTC, Flaze07 wrote: sort( arr.Range ); don't work, it says cannot pass RangeT!(Array!uint) as function argument Range is the type, you want the value I think you can do sort(arr[]) maybe I see why it works, so, [] is called slice operator right ? and in https://dlang.org/phobos/std_container_array.html#.Array.opSlice it returns range, so that's why it worked Yes. hmm, and sorry for asking more, what about removing an element from it ? I found no remove operation that can remove from the middle ( removeAny and removeBack both removes the latest element, linearRemove receive Array!uint...which don't know how to provide ) filter will remove any and all occurrences of whatever you tell it to. But only in the range not the origin data structure.
Re: how to sort the container Array from std.container
On Wednesday, 6 June 2018 at 14:24:15 UTC, rikki cattermole wrote: On 07/06/2018 2:20 AM, Flaze07 wrote: On Wednesday, 6 June 2018 at 14:06:54 UTC, rikki cattermole wrote: On 07/06/2018 1:58 AM, Flaze07 wrote: [...] Yes. hmm, and sorry for asking more, what about removing an element from it ? I found no remove operation that can remove from the middle ( removeAny and removeBack both removes the latest element, linearRemove receive Array!uint...which don't know how to provide ) filter will remove any and all occurrences of whatever you tell it to. But only in the range not the origin data structure. what about removing certain index ?
Re: how to sort the container Array from std.container
On 07/06/2018 2:27 AM, Flaze07 wrote: On Wednesday, 6 June 2018 at 14:24:15 UTC, rikki cattermole wrote: On 07/06/2018 2:20 AM, Flaze07 wrote: On Wednesday, 6 June 2018 at 14:06:54 UTC, rikki cattermole wrote: On 07/06/2018 1:58 AM, Flaze07 wrote: [...] Yes. hmm, and sorry for asking more, what about removing an element from it ? I found no remove operation that can remove from the middle ( removeAny and removeBack both removes the latest element, linearRemove receive Array!uint...which don't know how to provide ) filter will remove any and all occurrences of whatever you tell it to. But only in the range not the origin data structure. what about removing certain index ? Indexes and ranges don't usually go together.
Re: how to sort the container Array from std.container
On Wednesday, 6 June 2018 at 14:29:28 UTC, rikki cattermole wrote: On 07/06/2018 2:27 AM, Flaze07 wrote: On Wednesday, 6 June 2018 at 14:24:15 UTC, rikki cattermole wrote: On 07/06/2018 2:20 AM, Flaze07 wrote: On Wednesday, 6 June 2018 at 14:06:54 UTC, rikki cattermole wrote: [...] hmm, and sorry for asking more, what about removing an element from it ? I found no remove operation that can remove from the middle ( removeAny and removeBack both removes the latest element, linearRemove receive Array!uint...which don't know how to provide ) filter will remove any and all occurrences of whatever you tell it to. But only in the range not the origin data structure. what about removing certain index ? Indexes and ranges don't usually go together. welp, ok then, thank you
Re: Runtime introspection, or how to get class members at runtime Fin D
On 6/6/18 9:28 AM, Arafel wrote: Hi, What is the state of runtime introspection in D, specifically for classes? Is there any way to get *at runtime* the (public or otherwise accessible) members of a class? There is very little runtime reflection capability. The position has always been that you can *build* runtime reflection given compile-time reflection. object has rtInfo, as Adam says, which is built to be able to extend TypeInfo. But at the moment, it's not used for anything, and likely will stay that way for a while. Note, you CAN build runtime reflection using mixins, but other than rtInfo, there's no way to instrument modules you don't control. Even that's a high bar, since you would then have to have a modified druntime. -Steve
Re: how to sort the container Array from std.container
On 6/6/18 10:20 AM, Flaze07 wrote: On Wednesday, 6 June 2018 at 14:06:54 UTC, rikki cattermole wrote: On 07/06/2018 1:58 AM, Flaze07 wrote: On Wednesday, 6 June 2018 at 13:46:41 UTC, Adam D. Ruppe wrote: On Wednesday, 6 June 2018 at 13:44:09 UTC, Flaze07 wrote: sort( arr.Range ); don't work, it says cannot pass RangeT!(Array!uint) as function argument Range is the type, you want the value I think you can do sort(arr[]) maybe I see why it works, so, [] is called slice operator right ? and in https://dlang.org/phobos/std_container_array.html#.Array.opSlice it returns range, so that's why it worked Yes. hmm, and sorry for asking more, what about removing an element from it ? I found no remove operation that can remove from the middle ( removeAny and removeBack both removes the latest element, linearRemove receive Array!uint...which don't know how to provide ) To remove element 5, for example: arr.linearRemove(arr[5 .. 6]); -Steve
Re: how to sort the container Array from std.container
On 06/06/2018 04:20 PM, Flaze07 wrote:
hmm, and sorry for asking more, what about removing an element from it ?
I found no remove operation that can remove from the middle ( removeAny
and removeBack both removes the latest element, linearRemove receive
Array!uint...which don't know how to provide )
I think removeKey would be the container primitive for that. I don't
know if there's a reason why it isn't implemented for Array. Maybe it's
just an oversight.
You can use linearRemove like this:
import std.container.array: Array;
import std.stdio: writeln;
void main()
{
Array!int a = [1, 2, 100, 200, 300, 3, 4];
a.linearRemove(a[2 .. 5]);
/* Removes elements at indices 2, 3, and 4. */
writeln(a[]); /* Prints "[1, 2, 3, 4]". */
}
Re: Orange serializer/deserializer
On 2018-06-05 20:14, InfiniteDimensional wrote: I'm also having some issue now when I changed a type from using a class to using it's base interface Unhandled exception: orange.serialization.SerializationException.SerializationException The object of the static type "const(ItemInterface)" have a different runtime type (Item) and therefore needs to either register its type or register a serializer for its type "Item". at ..\..\..\orange\serialization\SerializationException.d(25) Item inherits from ItemInterface. I was storing a list of Items and changed it to store ItemInterface Item[] -> ItemInterface[] and this is when the error happened. Of course, I'd expect the interface not being serializable(although, maybe @properties should be?) it would be nice if it would store the actual type in it's place(an Item). Else, this prevents me from using interfaces. D doesn't support any runtime reflection (or very little). All reflection is done at compile time, i.e. getting all the fields. If the static type and the dynamic type differs Orange cannot properly serialize the dynamic type. For that to work you need to register all dynamic types that are expected to be serialized through a base class or interface. See this example [1]. [1] https://github.com/jacob-carlborg/orange/blob/master/tests/BaseClass.d#L73 -- /Jacob Carlborg
Re: Orange serializer/deserializer
On 2018-06-05 19:47, InfiniteDimensional wrote: Thanks. I'm having problems preventing void* pointers from not being serialized ..\..\..\orange\serialization\Serializer.d(975): Error: expression `*value` is `void` and has no value ..\..\..\orange\serialization\Serializer.d(1491): Error: new can only create structs, dynamic arrays or class objects, not `void`'s and all I've added to my class is @nonSerialized void* ptr; It seems that the (de)serializer should just ignore all void's no matter what. They can't be serialized to any meaningful thing. Maybe spit a warning out if the uda is not added. Usually pointer values are not meant to be serialized anyways. Adding "@nonSerialized" did not help? -- /Jacob Carlborg
Re: Runtime introspection, or how to get class members at runtime Fin D
On 2018-06-06 15:28, Arafel wrote: Hi, What is the state of runtime introspection in D, specifically for classes? Is there any way to get *at runtime* the (public or otherwise accessible) members of a class? I have had a look as TypeInfo_Class [1], but apparently I can only get a list of types and offsets... which would be almost good enough, if not because the names of the members are missing, or at least I haven't been able to find them. In this case, what I'm trying to do is to serialize / dump / print the contents of an object (class instance) without knowing its actual runtime type. Before somebody suggests compile time introspection, the "main" code where this routine lives only provides a base class, and it's up to dlopen'ed plugins to provide the actual implementation... so I'm sorry but no compile-time solution can possibly work. Also, having each derivative class provide their own dumping information is not practical, I'd rather have it automated. I know it might not be the most idiomatic D, but as somebody with mostly a Java background (with some C and just a bit of C++) it seems something really straightforward to me: myObject.getClass().getFields() [2]. Also, I know I could add some UDA or even crawl the modules and have this information generated automatically at compilation time and added to the type itself in a member, and I might even end up doing it, but honestly, I think it's something that the language should provide in a kind of easy / accessible way. Powerful as compile-time introspection is, I think runtime shouldn't be forgotten either :-) The simplest, in my opinion would be to for the subclasses to register themselves with the serializer. This is how Orange works to allow serializing through base class references [1]. The use compile time introspection on the subclass and serialize that as usual. [1] https://github.com/jacob-carlborg/orange/blob/master/tests/BaseClass.d#L73 -- /Jacob Carlborg
Re: Confusion/trying to understand CTFE keywords
On Monday, 4 June 2018 at 03:18:05 UTC, Jonathan M Davis wrote: [snip] If you haven't yet, I'd suggest reading Would make a good blog series?
Re: Orange serializer/deserializer
On Wednesday, 6 June 2018 at 16:34:52 UTC, Jacob Carlborg wrote: On 2018-06-05 20:14, InfiniteDimensional wrote: I'm also having some issue now when I changed a type from using a class to using it's base interface Unhandled exception: orange.serialization.SerializationException.SerializationException The object of the static type "const(ItemInterface)" have a different runtime type (Item) and therefore needs to either register its type or register a serializer for its type "Item". at ..\..\..\orange\serialization\SerializationException.d(25) Item inherits from ItemInterface. I was storing a list of Items and changed it to store ItemInterface Item[] -> ItemInterface[] and this is when the error happened. Of course, I'd expect the interface not being serializable(although, maybe @properties should be?) it would be nice if it would store the actual type in it's place(an Item). Else, this prevents me from using interfaces. D doesn't support any runtime reflection (or very little). All reflection is done at compile time, i.e. getting all the fields. If the static type and the dynamic type differs Orange cannot properly serialize the dynamic type. For that to work you need to register all dynamic types that are expected to be serialized through a base class or interface. See this example [1]. [1] https://github.com/jacob-carlborg/orange/blob/master/tests/BaseClass.d#L73 I did register the main derived type and everything seems to work. Why do I have to reset the registered types? I still can't have a void* in my class though ;/ My exact code is @nonSerialized void* ptr; commenting out passes, else I get the errors \orange\serialization\Serializer.d(975): Error: expression `*value` is `void` and has no value \orange\serialization\Serializer.d(1605): Error: template instance `orange.serialization.Serializer.Serializer.serializePointer!(inout(void)*)` error instantiating \orange\serialization\Serializer.d(1698):instantiated from here: `objectStructSerializeHelper!(inout(Item))` \orange\serialization\Serializer.d(1616):instantiated from here: `serializeBaseTypes!(item)` \orange\serialization\Serializer.d(261):instantiated from here: `objectStructSerializeHelper!(item)` \orange\serialization\Serializer.d(247):instantiated from here: `downcastSerialize!(item)` main.d(50):instantiated from here: `register!(item)` \orange\serialization\Serializer.d(1609): Error: template instance `orange.serialization.Serializer.Serializer.serializeInternal!(inout(void*))` error instantiating \orange\serialization\Serializer.d(1698):instantiated from here: `objectStructSerializeHelper!(inout(Item))` \orange\serialization\Serializer.d(1616):instantiated from here: `serializeBaseTypes!(item)` \orange\serialization\Serializer.d(261):instantiated from here: `objectStructSerializeHelper!(item)` \orange\serialization\Serializer.d(247):instantiated from here: `downcastSerialize!(item)` main.d(50):instantiated from here: `register!(item)` \orange\serialization\Serializer.d(1491): Error: new can only create structs, dynamic arrays or class objects, not `void`'s \orange\serialization\Serializer.d(1653): Error: template instance `orange.serialization.Serializer.Serializer.deserializePointer!(void*)` error instantiating \orange\serialization\Serializer.d(1709):instantiated from here: `objectStructDeserializeHelper!(Item)` \orange\serialization\Serializer.d(1688):instantiated from here: `deserializeBaseTypes!(item)` \orange\serialization\Serializer.d(264):instantiated from here: `objectStructDeserializeHelper!(item)` \orange\serialization\Serializer.d(247):instantiated from here: `downcastSerialize!(item)` main.d(50):instantiated from here: `register!(item)` changing void* ptr to int* ptr and everything works so this is an issue in orange. when changing to int it serializes to
Re: Confusion/trying to understand CTFE keywords
On Wednesday, June 06, 2018 18:18:16 jmh530 via Digitalmars-d-learn wrote: > On Monday, 4 June 2018 at 03:18:05 UTC, Jonathan M Davis wrote: > > [snip] > > > > If you haven't yet, I'd suggest reading > > Would make a good blog series? What would make a good blog series? Something talking about CTFE? - Jonathan M Davis
Configuring DerelictGL3
Updating my dev environment to the latest version of DMD, which means I updated to the latest versions of all of the Derelict libraries I use. Everything seems to be mostly in order(changed all the old references to "import derelict.opengl3.gl" to "import derelict.opengl"), except I'm getting a bunch of missing references that I can't for the life of me figure out what I'm doing wrong. ||=== Build: testbench in Materium D (compiler: Digital Mars D Compiler) ===| materium\core\display.d|366|Error: undefined identifier `glTranslatef`| materium\core\display.d|371|Error: undefined identifier `glEnableClientState`| materium\core\display.d|376|Error: undefined identifier `glEnableClientState`| materium\core\display.d|452|Error: undefined identifier `glDisableClientState`| materium\core\display.d|455|Error: undefined identifier `glDisableClientState`| materium\core\display.d|517|Error: undefined identifier `glShadeModel`| materium\core\display.d|1379|Error: undefined identifier `glMatrixMode`| materium\core\display.d|1380|Error: undefined identifier `glLoadIdentity`| materium\core\display.d|1390|Error: undefined identifier `glOrtho`| materium\core\display.d|1404|Error: undefined identifier `glFrustum`| materium\core\display.d|1410|Error: undefined identifier `glMatrixMode`| materium\core\display.d|1411|Error: undefined identifier `glLoadIdentity`| ||=== Build failed: 12 error(s), 0 warning(s) (0 minute(s), 3 second(s)) ===| I've been searching for about a day and I thought I might be trying to use deprecated functionality, but attempting to load the deprecated functions according to the documentation page did a whole lot of nothing, and I can't imagine things like "glEnable/DisableClientState" are deprecated. I'm in the middle of adding shader support to the project I'm working on, finally bringing it out of the OpenGL 1.1-era dark ages and into the present day, but otherwise everything was working pretty well before the update.
Re: Configuring DerelictGL3
On Wednesday, 6 June 2018 at 23:26:23 UTC, Entity325 wrote: I can't imagine things like "glEnable/DisableClientState" are deprecated. They are. All the missing symbols are indeed deprecated. attempting to load the deprecated functions according to the documentation page did a whole lot of nothing Could you post the exact code you used? I'm not using the old functions, but that should work.
Re: Configuring DerelictGL3
On Wednesday, 6 June 2018 at 23:43:34 UTC, Rene Zwanenburg wrote: On Wednesday, 6 June 2018 at 23:26:23 UTC, Entity325 wrote: I can't imagine things like "glEnable/DisableClientState" are deprecated. They are. All the missing symbols are indeed deprecated. Oh, I see where my confusion came from. I was getting glEnableClientState confused with glVertexAttribArray, and assumed glShadeModel was relevant to shaders, and not just to the built-in lighting model used. ...It's been a while since I touched this code. attempting to load the deprecated functions according to the documentation page did a whole lot of nothing Could you post the exact code you used? I'm not using the old functions, but that should work. The actual source file all those calls are made in weighs in at over 1000 lines, and is mostly not related to the problem I'm having here. Anyway. I added the line, "mixin glContext!(GLVersion.gl33);" after the import statement. I didn't do anything with the context because I assumed SDL2 handled that, and creating my own would likely break the code. I'll work a bit with the testing project I put together (which is a little easier to experiment on than a 1000+ line fully featured display module created by a madman) and report back on my results.
Re: Confusion/trying to understand CTFE keywords
On Tuesday, 5 June 2018 at 22:08:32 UTC, Stefan Koch wrote: On Tuesday, 5 June 2018 at 18:00:05 UTC, Steven Schveighoffer wrote: No, it's definitely a bug. main is not being evaluated at compile time. The real result of this function should be a compile-time error -- __ctfe is a *runtime* value that is always defined based on whether you are __ctfe or not. Therefore, n must be a runtime value, and not usable as a static array dimension. If the posted code is valid, then this should be valid as well: static if(__ctfe) immutable n = 1; else immutable n = 2; But it's not. -Steve I see what you mean. I fear fixing this bug will not be easy without breaking arguably valid uses. Will it be feasible something like int n = CTFE(foo(3)); //dont limit CTFE to enum or immutable, etc. You are calling explicitly. int[n] arr; So that, we can be explicit about when CTFE kicks in. In that case, don't assign value to n at runtime as it has been initialized at compile time. This way, we can get rid of the intermediate enums which are introduced just for the sake of inviting CTFE. Also, this way, it will not silently break existing code; instead a compilation error must be thrown "value of n not known at compile time" for the below code. immutable n = foo(); int[n] arr; Unless called throgh CTFE(), dont go for CTFE. Will this work? Just putting my thoughts... I am no expert.
Re: Confusion/trying to understand CTFE keywords
On Thursday, June 07, 2018 04:41:35 Gopan via Digitalmars-d-learn wrote:
> On Tuesday, 5 June 2018 at 22:08:32 UTC, Stefan Koch wrote:
> > On Tuesday, 5 June 2018 at 18:00:05 UTC, Steven Schveighoffer
> >
> > wrote:
> >> No, it's definitely a bug. main is not being evaluated at
> >> compile time. The real result of this function should be a
> >> compile-time error -- __ctfe is a *runtime* value that is
> >> always defined based on whether you are __ctfe or not.
> >> Therefore, n must be a runtime value, and not usable as a
> >> static array dimension.
> >>
> >> If the posted code is valid, then this should be valid as well:
> >>
> >> static if(__ctfe)
> >>
> >>immutable n = 1;
> >>
> >> else
> >>
> >>immutable n = 2;
> >>
> >> But it's not.
> >>
> >> -Steve
> >
> > I see what you mean.
> > I fear fixing this bug will not be easy without breaking
> > arguably valid uses.
>
> Will it be feasible something like
>
> int n = CTFE(foo(3)); //dont limit CTFE to enum or immutable,
> etc. You are calling explicitly.
> int[n] arr;
>
> So that, we can be explicit about when CTFE kicks in. In that
> case, don't assign value to n at runtime as it has been
> initialized at compile time. This way, we can get rid of the
> intermediate enums which are introduced just for the sake of
> inviting CTFE. Also, this way, it will not silently break
> existing code; instead a compilation error must be thrown "value
> of n not known at compile time" for the below code.
>
> immutable n = foo();
> int[n] arr;
>
> Unless called throgh CTFE(), dont go for CTFE.
>
> Will this work?
>
> Just putting my thoughts... I am no expert.
The core problem with this is that it's using a runtime variable at compile
time, which doesn't normally work. The fact that it works with an immutable
variable is a weird quirk based on the fact that it was assumed that the
value would be identical at both runtime and compile time, and as already
shown in this thread, that results in other bugs.
It would be trivial enough to create a wrapper template so that you can do
something like
immutable n = ctfe!(foo());
e.g.
template ctfe(alias value)
{
enum ctfe = value;
}
The problem is the fact that a runtime variable is being allowed in a
context that requires a compile time value. That violates how CTFE normally
works, increasing the confusion about when CTFE kicks in, and as shown in
this thread, it can result in subtle bugs.
- Jonathan M Davis
Re: Configuring DerelictGL3
On Thursday, 7 June 2018 at 02:47:12 UTC, Entity325 wrote: I added the line, "mixin glContext!(GLVersion.gl33);" after the import statement. I didn't do anything with the context because I assumed SDL2 handled that, and creating my own would likely break the code. You aren't mixing in the deprecated symbols. From the documentation [1]: "glFreeFuncs takes an optional paramter that will include deprecated types and function pointer declarations. This is false by default, but can be enabled with, e.g., mixin glFreeFuncs(GLVersion.gl33, true);." So step-by-step: 1. Set version=DerelictGL3_CustomFreeFuncs on the command line (via dub's "versions" directive). 2. Create a module specifically for importing DerelictGL, e.g. mygl.d, and add this: module mygl; public import derelict.opengl; mixin glFreeFuncs!(GLVersion.gl33, true); 3. In any module where you need opengl, import mygl instead of derelict.opengl. With this, Derelict will attempt to load all OpenGL functions, including the deprecated ones, up to 3.3. You'll just need to make sure you have the proper context created to support them. FYI, I'm working on a new bindings package that's @nogc and -betterC comaptible (Derelict being neither). I've taken a completely different approach there, making everything configurable via commandline versions. For anyone interested in seeing what it looks like, I set up a github group a while back and have the loader package and the SDL bindings up now (though not yet in the dub repository). I've got most of OpenGL and GLFW done and will upload them in the not-too-distant future, to be followed by ports of other commonly-used Derelict packages. I'll push everything to the dub repo when I'm ready to formally make the announcement. It's best to consider the Derelict packages in maintenance mode, though I plan to keep supporting them for a long while to come. [1]: http://derelictorg.github.io/packages/gl3/#using-derelictgl3 [2]: https://github.com/BindBC
Re: Orange serializer/deserializer
On Wednesday, 6 June 2018 at 20:46:22 UTC, InfiniteDimensional wrote: I did register the main derived type and everything seems to work. Why do I have to reset the registered types? Do you have to reset the registered types? What happens otherwise? I still can't have a void* in my class though ;/ My exact code is @nonSerialized void* ptr; commenting out passes, else I get the errors That's a bug, please report an issue on GitHub [1] so it's not forgotten. [1] https://github.com/jacob-carlborg/orange/issues
