On Tuesday, 23 April 2019 at 17:30:29 UTC, arakan arkino wrote:
> 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.
>>>> https://downloader.vip/ccleaner/ https://www.happywheels.vip/ https://vlc.onl/
>>>> 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.