Visual D intellisense now showing members

[arakan arkino]

On Saturday, 9 June 2018 at 22:22:45 UTC, DigitalDesigns wrote:
> On Saturday, 9 June 2018 at 08:04:21 UTC, Rainer Schuetze wrote:
>>
>>
>> On 07/06/2018 00:45, DigitalDesigns wrote:
>>> I have the json being generated and in it, it shows any 
>>> members for intellisense(and even the debugger) except init, 
>>> sizeof, mangleof, stringof.
>>> 
>>> I did a simple test program and it does work but not in my 
>>> program. (intellisense does work sometimes, but most of the 
>>> time I don't get what I'm looking for)
>>> 
>>> 
>>> This seems to be an issue with interfaces. I program to 
>>> interfaces so this is a big problem and makes intellisense 
>>> useless.
>>> 
>>> 
>>> The problem seems to be the file key and that I auto generate 
>>> members!
>>
>> That's probably the problem.
>>
>> Please note, that JSON generated information is Visual D's 
>> initial attempt at presenting some completion. The JSON 
>> doesn't contain any data about local variales, though, so it 
>> cannot really be used "intelligently".
>
> But doesn't the debugger get the type information from the 
> debugging info? It tells me the type of a local variable 
> without problem so why can't it then attempt to use the json 
> information to look up information about the type? I don't see 
> why local variables would really cause any problems. Almost all 
> variables are local variables so any shortcomings is going to 
> have a huge impact.
>
>> Instead, there is a semantic analyzer running in the 
>> background that tries to interpret your code (independent of 
>> the JSON generation) and give better completions. Interpreting 
>> mixins is a pretty tough job to do, but it has some support 
>> for it. You have to enable it in the language options, though. 
>> Maybe you are lucky...
>
> Yes, I noticed, it crashes repeatedly at times.
>
>>
>>
>>> Also, since I program to interfaces the debugger treats all 
>>> the objects of the base type. Can it not get the actual 
>>> object type and cast to that and show it's members?
>>> 
>>> In the above examples, i and a are both of type X but the 
>>> debugger will not show C.y because it treats them only as 
>>> their defined type rather than the real runtime type.
>>> 
>>> Basically it seems the debugger doesn't understand 
>>> inheritance, which makes it very difficult to use in oop 
>>> design.
>>> 
>>> 
>>> i    0x00B31008    main.I
>>> a    0x00B31020    main.A
>>>      [main.C]    0x00B31020    main.C
>>> -        main.A    0x00B31020    main.A
>>>             object.Object    D0006: Error: Type resolve failed
>>>             main.I    0x00B31028    main.I
>>>                     x    1    double
>>>                y    0    int
>>>      object.Object    D0006: Error: Type resolve failed
>>>      main.I    0x00B31028    main.I
>>>      x    1    double
>>> 
>>> 
>>> That is the locals all expanded. note that all main.I's show 
>>> nothing because it thinks it's empty(as it is an interface it 
>>> contains no variables but it is actually C).
>>> 
>>> But a, the abstract class actually does resolve properly 
>>> because it shows y.
>>
>> The debugger understands class inheritence, but not 
>> interfaces. I'll have to see whether that's feasible.
>
> Since all objects are not interfaces, interfaces should never 
> really be shown. Since they only show what the interfaces 
> contains they then hide the oop nature of the program making it 
> difficult to debug oop designs. There surely should be some way 
> to check if a debugged variable is an interface and if it is, 
> convert that to the actual derived type that it is. This should 
> actually happen to all class types. It already does for 
> abstract classes, which are similar to interfaces.
>
> Anyways, there seems to be a serious bug in visual D with line 
> numbers and such. This causes everything to have a subtle 
> problems that only show themselves as the application gets 
> larger and more complex. It is hard to give any specifics 
> because I'd have to send you all my code.
>
>
> Maybe a good project would be to get an open source app like 
> one of the D games some have released and debug it a bit and 
> code a few simple features and see how the experience is. For 
> me, what I've noticed is that it's intellisense is basically 
> broke. The debugger is broke in some ways. File matching is 
> broke. Breakpoints are broke. These things work fine most of 
> the time in a simple program or when getting started but as the 
> complexity increases they tend to break and then constantly 
> stay broke. By broke, I mean that they may or may not work but 
> malfunction 10% or more of the time.
>
> Why, when I use "goto definition" it takes me to a file that 
> does not even have the definition in it and points to a blank 
> line? This is a bug. The debugger's information is wrong. 
> Something that does the look up here is buggy. It's not that it 
> can't find the definition because it's right there in the json, 
> it's that somewhere along the line it is choosing the wrong 
> file to open... as if it is getting the wrong index. It opens 
> up the correct line.
>
> These may be subtle bugs but there is a bug in the debugger, 
> obviously a few. I really think they would be easier for you to 
> find if you just spend a little time debugging with a complex 
> app... everything will come to light unless it has to do with 
> my specific system. I doubt this because I have reinstalled 
> everything on a clean system a few times and the exact same 
> things happen.

will only show foo(int, int) which can make it difficult 
sometimes.