Two visual D suggestions:

[Rainer Schuetze]

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.