A biggie:

1. Visual D is not properly handling interfaces. If I declare an interface variable, it simply treats it as a pointer without casting it to it's class type. Since all interfaces are classes at run time, it should do this internally and treat all interfaces as the classes that they

idata	0x000002a47bcc8510 {}	moduleX.idata

But if I cast idata to it's class then it shows everything as as expected.

This is tedious because it requires me to cast all interfaces and, at least for debugging purposes, makes interfaces a real PITA.

The debugger should easily be able to figure out the class of the type(use typeinfo/typeid/reflection or whatever).

Then just internally cast them to the class as if I did it in code(but still show it as an interface variable in the debugger).

example:

interface X;
class Y : X;

X x = new Y;
Y y = cast(Y)x;

x then is treated as a dumb ptr in the debug windows but y is treated correctly. Clearly they are identical.


2. For some pointers for some reason when I drag them from the watch or locals to memory, it shows the memory where the pointer is declared rather than the data of the pointer.

This is happening in strange situations:


protected void[] data;
@property ref void[] Data() { return data; }

Later on I call a template function where I get the Data above from an object and pass it in:

auto data = cast(float[])obj.Data;
Mod!(float)(data, 10000);

A BP on data shows the correct data when dragged. (it lists the values in the memory window)

auto Mod(T)(T[] dat, size_t len)

Inside Mod the dat, when dragged, is not showing up as the values but as a fat pointer.

In inside mod, the value's for dat looks to be a fat pointer.

In the debugger it is registering dat as T[]* (a float[]*) rather than just T[]. I don't understand why it is doing this, everything in the code works but it seems to be treating dat as a pointer under the hood.



Thanks for any help!

Another issue is that things like bytes get exampled to size_t,

		x2	0xffffffffffffffff	byte

		x3	0x55	byte

Another suggestion! ;)

One of the major issues I tend to have is not seeing a variable in the debug window. Would it be possible to be able to click on a variable in the editor and tell it to watch the variable?

Hi,

On 13/05/2019 21:58, Alex wrote:
> 
> A biggie:
> 
> 1. Visual D is not properly handling interfaces. If I declare an
> interface variable, it simply treats it as a pointer without casting it
> to it's class type. Since all interfaces are classes at run time, it
> should do this internally and treat all interfaces as the classes that they
> 
> idata    0x000002a47bcc8510 {}    moduleX.idata
> 
> But if I cast idata to it's class then it shows everything as as expected.
> 
> This is tedious because it requires me to cast all interfaces and, at least for debugging purposes, makes interfaces a real PITA.
> 
> The debugger should easily be able to figure out the class of the type(use typeinfo/typeid/reflection or whatever).
> 
> Then just internally cast them to the class as if I did it in code(but still show it as an interface variable in the debugger).
> 
> example:
> 
> interface X;
> class Y : X;
> 
> X x = new Y;
> Y y = cast(Y)x;
> 
> x then is treated as a dumb ptr in the debug windows but y is treated correctly. Clearly they are identical.
> 

Will add to my TODO list. Evaluating the dynamic class already works for classes, but not interfaces. The explicit cast in the watch window (with fully qualified class name) works, too.

> 
> 2. For some pointers for some reason when I drag them from the watch or locals to memory, it shows the memory where the pointer is declared rather than the data of the pointer.
> 
> This is happening in strange situations:
> 
> 
> protected void[] data;
> @property ref void[] Data() { return data; }
> 
> Later on I call a template function where I get the Data above from an object and pass it in:
> 
> auto data = cast(float[])obj.Data;
> Mod!(float)(data, 10000);
> 
> A BP on data shows the correct data when dragged. (it lists the values
> in the memory window)
> 
> auto Mod(T)(T[] dat, size_t len)
> 
> Inside Mod the dat, when dragged, is not showing up as the values but as a fat pointer.
> 
> In inside mod, the value's for dat looks to be a fat pointer.
> 
> In the debugger it is registering dat as T[]* (a float[]*) rather than just T[]. I don't understand why it is doing this, everything in the code works but it seems to be treating dat as a pointer under the hood.

I guess this is caused by the x64 ABI: the slice is a struct too large to be passed in registers, so it is passed by reference. Dmd encodes this as a pointer in the debug information, while LDC actually uses references and it works better with it.

BTW: Please show complete (reduced) examples so it is easier to
reproduce without guessing.

On 15/05/2019 13:02, Alex wrote:> Another issue is that things like bytes get exampled to size_t,
>
>         x2    0xffffffffffffffff    byte
>
>         x3    0x55    byte

Will fix. Please note that byte is a signed type, ubyte is displayed correctly.

On 16/05/2019 06:34, Alex wrote:> Another suggestion! ;)
>
> One of the major issues I tend to have is not seeing a variable in the debug window. Would it be possible to be able to click on a variable in the editor and tell it to watch the variable?

You can either right click the data tool tip and select "Add watch", or drag the editor selection to the watch window.

On Thursday, 16 May 2019 at 05:55:23 UTC, Rainer Schuetze wrote:
> Hi,
>
> On 13/05/2019 21:58, Alex wrote:
>> 
>> A biggie:
>> 
>> 1. Visual D is not properly handling interfaces. If I declare an
>> interface variable, it simply treats it as a pointer without casting it
>> to it's class type. Since all interfaces are classes at run time, it
>> should do this internally and treat all interfaces as the classes that they
>> 
>> idata    0x000002a47bcc8510 {}    moduleX.idata
>> 
>> But if I cast idata to it's class then it shows everything as as expected.
>> 
>> This is tedious because it requires me to cast all interfaces and, at least for debugging purposes, makes interfaces a real PITA.
>> 
>> The debugger should easily be able to figure out the class of the type(use typeinfo/typeid/reflection or whatever).
>> 
>> Then just internally cast them to the class as if I did it in code(but still show it as an interface variable in the debugger).
>> 
>> example:
>> 
>> interface X;
>> class Y : X;
>> 
>> X x = new Y;
>> Y y = cast(Y)x;
>> 
>> x then is treated as a dumb ptr in the debug windows but y is treated correctly. Clearly they are identical.
>> 
>
> Will add to my TODO list. Evaluating the dynamic class already works for classes, but not interfaces. The explicit cast in the watch window (with fully qualified class name) works, too.

The problem is that there might be nested interfaces because of oop design. I strictly use interfaces so I'm always having to cast and create temp debug variables simply to get at the nested information.

So if a class contains another interface, it too should be casted and hence expandable.

Basically any interface listed in the debug should be treated as the class it expresses(most derived) even if it is part of another object.

That should add solve a lot of my problems in that area. I eagerly await the update! I just uninstalled vs2017 completely and installed 2019 + latest Visual D. So far everything has worked without a hitch.


> On 16/05/2019 06:34, Alex wrote:> Another suggestion! ;)
>>
>> One of the major issues I tend to have is not seeing a variable in the debug window. Would it be possible to be able to click on a variable in the editor and tell it to watch the variable?
>
> You can either right click the data tool tip and select "Add watch", or drag the editor selection to the watch window.

When I do that it says symbol not found for any symbol not declared in the local context[specially in my case it is a callback in gtkd].

Is there any way for Visual D to detect the error and use a FQN if that solves it(the FQN is added internally so it doesn't clutter up the debug window).


If I add the module to the variable then it does show it.

myModule.Mystaticvar

works

Could Visual D just not internally add this for me? We know it has the info because I can do go to definition and it takes me to the right module, so it seems it could first check if it gets

D0013: Error: Symbol not found

and if so then auto-resolve the name by fully qualifying it and then trying again...

Should be pretty simple and a just a few lines of code, assuming the FQN is easy to get.

Hypothetically if I were generating a module at runtime with a random name for some purpose, then it would be a pain to have to explicitly specify a variable in that module because it wouldn't be correct on the next run. Automatically resolving it would solve this problem though.

Also, if it fails with the FQN then it could try to use outer context, then this, then super, etc... (and the Type in the autos/watch would show the full info like super.SuperWorkedVar as to inform the programmer which qualification worked in case there was ambiguity so they could try an explicit case)

Thanks!

On 16/05/2019 11:19, Alex wrote:
> Could Visual D just not internally add this for me? We know it has the info because I can do go to definition and it takes me to the right module, so it seems it could first check if it gets
> 
> D0013: Error: Symbol not found
> 
> and if so then auto-resolve the name by fully qualifying it and then trying again...
> 
> Should be pretty simple and a just a few lines of code, assuming the FQN is easy to get.

Unfortunately, it is not. The semantic engine and the debugger extension are unaware of each other. Even if they are, symbol lookup might slow down the debugging experience quite a bit.

IIRC GDC emits symbol lookup information (e.g. imports) to the debug info. I think this should happen with DMD or LDC, too.

> 
> Hypothetically if I were generating a module at runtime with a random name for some purpose, then it would be a pain to have to explicitly specify a variable in that module because it wouldn't be correct on the next run. Automatically resolving it would solve this problem though.
> 
> Also, if it fails with the FQN then it could try to use outer context, then this, then super, etc... (and the Type in the autos/watch would show the full info like super.SuperWorkedVar as to inform the programmer which qualification worked in case there was ambiguity so they could try an explicit case)

Actually it already does this inside extern(D) unctions (but it might
not work for all symbols due to a change in the mangling). It doesn't
find symbols that are visible through imports.

On Friday, 17 May 2019 at 07:48:00 UTC, Rainer Schuetze wrote:
>
>
> On 16/05/2019 11:19, Alex wrote:
>> Could Visual D just not internally add this for me? We know it has the info because I can do go to definition and it takes me to the right module, so it seems it could first check if it gets
>> 
>> D0013: Error: Symbol not found
>> 
>> and if so then auto-resolve the name by fully qualifying it and then trying again...
>> 
>> Should be pretty simple and a just a few lines of code, assuming the FQN is easy to get.
>
> Unfortunately, it is not. The semantic engine and the debugger extension are unaware of each other. Even if they are, symbol lookup might slow down the debugging experience quite a bit.

;/


> IIRC GDC emits symbol lookup information (e.g. imports) to the debug info. I think this should happen with DMD or LDC, too.

Sure... whatever would be easiest to get things to work properly.

Surely the debugger can get the information. For this specific issue of adding a variable to the watch, it would only have to qualify it on adding the variable.

What I'd do, at least as a temporary work around is this:

When symbol cannot be resolved in the watch/autos/local:

Some how get the FQN. Either from the json files, or "ask" the semantic engine. [or ideally get dmd/ldc to give the info].

If speed is an issue, only do it when adding the name and cache it. This would be done once and so won't can't slow things down.

If multiple FQN's are found then require explicit casting.

It then seems the bulk of the work is getting the FQN. If that can be done relatively easy, even if a temporary hack, it might be worth it.


Remember, all one is trying to do is "cast(X)x;" and so it is just a matter of getting X for x... which is just something to "look up" somewhere.

If the semantic engine and debugger extension need to communicate with each other then maybe create some code to make a simple communications layer where information can be passed(could use json encoding).


Of course it might be much easier just to get the compilers to emit this information? Probably actually only a few lines of code?

> Remember, all one is trying to do is "cast(X)x;" and so it is just a matter of getting X for x... which is just something to "look up" somewhere.

I mean "name.x" rather than cast.

On Monday, 13 May 2019 at 19:58:58 UTC, Alex wrote:
>
> A biggie:
>
> 1. Visual D is not properly handling interfaces. If I declare an interface variable, it simply treats it as a pointer without casting it to it's class type. Since all interfaces are classes at run time, it should do this internally and treat all interfaces as the classes that they

Is there any ETA when this might be fixed? I feel I'll be more productive when it is so I'll put off working on some code until then... if it's not too far out. Not trying to rush you but if it's < a week I'll just re-order some things to be done.

Thanks.

On Friday, 17 May 2019 at 11:39:54 UTC, Alex wrote:
> On Monday, 13 May 2019 at 19:58:58 UTC, Alex wrote:
>>
>> A biggie:
>>
>> 1. Visual D is not properly handling interfaces. If I declare an interface variable, it simply treats it as a pointer without casting it to it's class type. Since all interfaces are classes at run time, it should do this internally and treat all interfaces as the classes that they
>
> Is there any ETA when this might be fixed? I feel I'll be more productive when it is so I'll put off working on some code until then... if it's not too far out. Not trying to rush you but if it's < a week I'll just re-order some things to be done.
>
> Thanks.

And just to be clear we are talking about the same thing ;)

interface X;

class Y : X { X x; }

Y q;
X y = q;
y.x = q;

Then in autos/local/watch on y one cannot see the fields of the object because it treats it as an interface and interfaces do not contain fields... even though obviously the object is actually a class.

This happens for nested fields too which is the main issue since one can't easily get at the fields programmatically without a lot of trouble.