Thread overview
Visual D DClosure mixin error?
Jun 21
Bart
Jun 22
Bart
June 21
I'm getting DClosure mixin not found when trying to go to a delegate on the stack.

DClosure.DClosure.d_closure_marshal!(bool delegate(gdk.Event.Event, gtk.Widget.Widget)).d_closure_marshal(gobject.c.types.GClosure * closure, gobject.c.types.GValue * return_value, unsigned int n_param_values, gobject.c.types.GValue * param_values, void * invocation_hint, void * marshal_data) Line 123	D

This is a file in GtkD.

It says it's like 123 but it's actually line 121.

Dclosure.d
	extern(C) static void d_closure_marshal(T)(GClosure* closure, GValue* return_value, uint n_param_values, /*const*/ GValue* param_values, void* invocation_hint, void* marshal_data)
	{
		DGClosure!(T)* cl = cast(DGClosure!(T)*)closure;

		if ( Parameters!(T).length > n_param_values )
			assert(false, "DClosure doesn't have enough parameters.");

		if ( closure.derivativeFlag )
		{
			GValue[] swapped = new GValue[n_param_values];
			swapped[0..n_param_values-1] = param_values[1..n_param_values];
			swapped[n_param_values-1] = param_values[0];
			param_values = swapped.ptr;
		}

		mixin(getCallbackCall!T()); // line 121 but stack trace says it's 123.
	}


Seems it can't find the line nor the mixin in file correctly.

The main mixin does not seem to have this code in it either but it has other code related to other mixins from gtkD so it

Do you have gtk installed or are you willing to install it? The closure is generated for most event handling in gtkD it seems such as simple button click handling. Probably any gtkD example will produce such a stack.
June 22

On 21/06/2019 15:55, Bart wrote:
> I'm getting DClosure mixin not found when trying to go to a delegate on the stack.
> 
> DClosure.DClosure.d_closure_marshal!(bool delegate(gdk.Event.Event, gtk.Widget.Widget)).d_closure_marshal(gobject.c.types.GClosure * closure, gobject.c.types.GValue * return_value, unsigned int n_param_values, gobject.c.types.GValue * param_values, void * invocation_hint, void * marshal_data) Line 123    D
> 
> This is a file in GtkD.
> 
> It says it's like 123 but it's actually line 121.
> 
> Dclosure.d
>     extern(C) static void d_closure_marshal(T)(GClosure* closure,
> GValue* return_value, uint n_param_values, /*const*/ GValue*
> param_values, void* invocation_hint, void* marshal_data)
>     {
>         DGClosure!(T)* cl = cast(DGClosure!(T)*)closure;
> 
>         if ( Parameters!(T).length > n_param_values )
>             assert(false, "DClosure doesn't have enough parameters.");
> 
>         if ( closure.derivativeFlag )
>         {
>             GValue[] swapped = new GValue[n_param_values];
>             swapped[0..n_param_values-1] = param_values[1..n_param_values];
>             swapped[n_param_values-1] = param_values[0];
>             param_values = swapped.ptr;
>         }
> 
>         mixin(getCallbackCall!T()); // line 121 but stack trace says
> it's 123.
>     }
> 
> 
> Seems it can't find the line nor the mixin in file correctly.
> 
> The main mixin does not seem to have this code in it either but it has other code related to other mixins from gtkD so it
> 
> Do you have gtk installed or are you willing to install it? The closure
> is generated for most event handling in gtkD it seems such as simple
> button click handling. Probably any gtkD example will produce such a stack.

I just tried it, and the rather new "Enable mixin debugging" feature on the Compiler->Debug page is what you are looking for. This will write the expanded mixins into the given file instead of the compiler just making up random filenames.

Unfortunately, with "Separate compile and link" the link step overwrites the file generated during compilation, so you should switch the compilation model to "Combined compile and link" for the gtk library.
June 22
On Saturday, 22 June 2019 at 07:09:42 UTC, Rainer Schuetze wrote:
>
>
> On 21/06/2019 15:55, Bart wrote:
>> I'm getting DClosure mixin not found when trying to go to a delegate on the stack.
>> 
>> DClosure.DClosure.d_closure_marshal!(bool delegate(gdk.Event.Event, gtk.Widget.Widget)).d_closure_marshal(gobject.c.types.GClosure * closure, gobject.c.types.GValue * return_value, unsigned int n_param_values, gobject.c.types.GValue * param_values, void * invocation_hint, void * marshal_data) Line 123    D
>> 
>> This is a file in GtkD.
>> 
>> It says it's like 123 but it's actually line 121.
>> 
>> Dclosure.d
>>     extern(C) static void d_closure_marshal(T)(GClosure* closure,
>> GValue* return_value, uint n_param_values, /*const*/ GValue*
>> param_values, void* invocation_hint, void* marshal_data)
>>     {
>>         DGClosure!(T)* cl = cast(DGClosure!(T)*)closure;
>> 
>>         if ( Parameters!(T).length > n_param_values )
>>             assert(false, "DClosure doesn't have enough parameters.");
>> 
>>         if ( closure.derivativeFlag )
>>         {
>>             GValue[] swapped = new GValue[n_param_values];
>>             swapped[0..n_param_values-1] = param_values[1..n_param_values];
>>             swapped[n_param_values-1] = param_values[0];
>>             param_values = swapped.ptr;
>>         }
>> 
>>         mixin(getCallbackCall!T()); // line 121 but stack trace says
>> it's 123.
>>     }
>> 
>> 
>> Seems it can't find the line nor the mixin in file correctly.
>> 
>> The main mixin does not seem to have this code in it either but it has other code related to other mixins from gtkD so it
>> 
>> Do you have gtk installed or are you willing to install it? The closure
>> is generated for most event handling in gtkD it seems such as simple
>> button click handling. Probably any gtkD example will produce such a stack.
>
> I just tried it, and the rather new "Enable mixin debugging" feature on the Compiler->Debug page is what you are looking for. This will write the expanded mixins into the given file instead of the compiler just making up random filenames.
>

I had this checked already. I could debug mixins sometimes and it wrote them all to
one large file.

So something must be buggy. I guess it's not finding the file name correctly. Remember, it's also reporting the line number wrong.

Maybe it is a problem with the compiler itself and not Visual D? I searched for the DClosure in the large mixin file and could not find it but other related mixins were inside.

> Unfortunately, with "Separate compile and link" the link step overwrites the file generated during compilation, so you should switch the compilation model to "Combined compile and link" for the gtk library.

I do have combined enable. Separate compile and link is far too slow to be usable.


June 23

On 22/06/2019 15:09, Bart wrote:
> On Saturday, 22 June 2019 at 07:09:42 UTC, Rainer Schuetze wrote:
>>
>>
>> On 21/06/2019 15:55, Bart wrote:
>>> I'm getting DClosure mixin not found when trying to go to a delegate on the stack.
>>>
>>> DClosure.DClosure.d_closure_marshal!(bool delegate(gdk.Event.Event, gtk.Widget.Widget)).d_closure_marshal(gobject.c.types.GClosure * closure, gobject.c.types.GValue * return_value, unsigned int n_param_values, gobject.c.types.GValue * param_values, void * invocation_hint, void * marshal_data) Line 123    D
>>>
>>> This is a file in GtkD.
>>>
>>> It says it's like 123 but it's actually line 121.
>>>
>>> Dclosure.d
>>>     extern(C) static void d_closure_marshal(T)(GClosure* closure,
>>> GValue* return_value, uint n_param_values, /*const*/ GValue*
>>> param_values, void* invocation_hint, void* marshal_data)
>>>     {
>>>         DGClosure!(T)* cl = cast(DGClosure!(T)*)closure;
>>>
>>>         if ( Parameters!(T).length > n_param_values )
>>>             assert(false, "DClosure doesn't have enough parameters.");
>>>
>>>         if ( closure.derivativeFlag )
>>>         {
>>>             GValue[] swapped = new GValue[n_param_values];
>>>             swapped[0..n_param_values-1] =
>>> param_values[1..n_param_values];
>>>             swapped[n_param_values-1] = param_values[0];
>>>             param_values = swapped.ptr;
>>>         }
>>>
>>>         mixin(getCallbackCall!T()); // line 121 but stack trace says
>>> it's 123.
>>>     }
>>>
>>>
>>> Seems it can't find the line nor the mixin in file correctly.
>>>
>>> The main mixin does not seem to have this code in it either but it has other code related to other mixins from gtkD so it
>>>
>>> Do you have gtk installed or are you willing to install it? The closure is generated for most event handling in gtkD it seems such as simple button click handling. Probably any gtkD example will produce such a stack.
>>
>> I just tried it, and the rather new "Enable mixin debugging" feature on the Compiler->Debug page is what you are looking for. This will write the expanded mixins into the given file instead of the compiler just making up random filenames.
>>
> 
> I had this checked already. I could debug mixins sometimes and it wrote
> them all to
> one large file.
> 
> So something must be buggy. I guess it's not finding the file name correctly. Remember, it's also reporting the line number wrong.

What is the file name it is not finding?

I suspect you have enabled mixin debugging for your project, but not gtkd.


> 
> Maybe it is a problem with the compiler itself and not Visual D? I searched for the DClosure in the large mixin file and could not find it but other related mixins were inside.
> 
>> Unfortunately, with "Separate compile and link" the link step
>> overwrites the file generated during compilation, so you should switch
>> the compilation model to "Combined compile and link" for the gtk library.
> 
> I do have combined enable. Separate compile and link is far too slow to be usable.
> 
> 

"Separate compile and link" and "Combined compile and link" shouldn't differ much, it's only about whether the linker is called directly or through dmd.

"Single file compilation" is usually way too slow, and useful only under special circumstances.