www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - Two visual D suggestions:

reply Alex <AJ gmail.com> writes:
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!
May 13 2019
next sibling parent reply Alex <AJ gmail.com> writes:
Another issue is that things like bytes get exampled to size_t,

		x2	0xffffffffffffffff	byte

		x3	0x55	byte
May 15 2019
parent Alex <AJ gmail.com> writes:
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?
May 15 2019
prev sibling next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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.
May 15 2019
parent reply Alex <AJ gmail.com> writes:
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!
May 16 2019
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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.
May 17 2019
parent reply Alex <AJ gmail.com> writes:
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?
May 17 2019
parent Alex <AJ gmail.com> writes:
 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.
May 17 2019
prev sibling parent reply Alex <AJ gmail.com> writes:
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.
May 17 2019
next sibling parent Alex <AJ gmail.com> writes:
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.
May 17 2019
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 17/05/2019 13:39, 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.
 


Should be fixed in the next version. The machinery was mostly already
there, but classes and interfaces that don't have any fields would not
show the dynamic type. It is now also shown with braces in the type


I also added some support for extern(C++) classes getting the derived
type from the symbol name of the vtbl. No support for multiple
inheritence in C++, though.
May 19 2019
parent Alex <AJ gmail.com> writes:
On Monday, 20 May 2019 at 06:44:38 UTC, Rainer Schuetze wrote:

 On 17/05/2019 13:39, 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.
 


 Should be fixed in the next version. The machinery was mostly 
 already there, but classes and interfaces that don't have any 
 fields would not show the dynamic type. It is now also shown 

 C++).

 I also added some support for extern(C++) classes getting the 
 derived type from the symbol name of the vtbl. No support for 
 multiple inheritence in C++, though.



Thanks.
May 20 2019