Thread overview
December 31
Display variables in the watch shows the variables in a flat list. Can we just get an override for toString or some other method to change what is displayed?

Surely this can be accomplished?

Even if it means creating an external DLL that Visual D can read and choose the right function and use it to take the object and return a string and simply display that string instead of whatever Visual D is generating internally?

struct S
{
   int x;
}


Somewhere

   auto S_toString(S s)
   {
      return "S: "~s.x;
   }

Should be very simple to do. Visual D just uses that function.


December 31
On Monday, 31 December 2018 at 10:13:17 UTC, Michelle Long wrote:
> Display variables in the watch shows the variables in a flat list. Can we just get an override for toString or some other method to change what is displayed?
>
> Surely this can be accomplished?
>
> Even if it means creating an external DLL that Visual D can read and choose the right function and use it to take the object and return a string and simply display that string instead of whatever Visual D is generating internally?
>
> struct S
> {
>    int x;
> }
>
>
> Somewhere
>
>    auto S_toString(S s)
>    {
>       return "S: "~s.x;
>    }
>
> Should be very simple to do. Visual D just uses that function.

when it's easy enough do it yourself ;)
December 31

On 31/12/2018 11:13, Michelle Long wrote:
> Display variables in the watch shows the variables in a flat list. Can we just get an override for toString or some other method to change what is displayed?
> 
> Surely this can be accomplished?
> 
> Even if it means creating an external DLL that Visual D can read and choose the right function and use it to take the object and return a string and simply display that string instead of whatever Visual D is generating internally?
> 
> struct S
> {
>    int x;
> }
> 
> 
> Somewhere
> 
>    auto S_toString(S s)
>    {
>       return "S: "~s.x;
>    }
> 
> Should be very simple to do. Visual D just uses that function.
> 
> 

What you can do now when using the VS debugger with the mago extension (and not mago selected as debug engine):

struct Size
{
	int w;
	int h;

	const char* toDebug()
	{
		import std.conv;
		import std.utf;

		return toUTFz!(char*)(to!string(w) ~ "x" ~ to!string(h));
	}
}

int test()
{
	Size sz = Size(10, 20);
	return sz.w * sz.h; // Breakpoint here
}

Run to the breakpoint and then add watch "sz.toDebug()" to execute the function and display the result.

Some limitations apply:
- no arguments but the implicit this or context pointer (i.e. delegates
work, too)
- doesn't work with slice return values for x64 due to incompatible ABI
- you have to manually reevaluate in the watch window due to possible
side-effects
- the example above currently seems broken for x86, not sure why
December 31
On Monday, 31 December 2018 at 15:39:05 UTC, Rainer Schuetze wrote:
>
>
> On 31/12/2018 11:13, Michelle Long wrote:
>> Display variables in the watch shows the variables in a flat list. Can we just get an override for toString or some other method to change what is displayed?
>> 
>> Surely this can be accomplished?
>> 
>> Even if it means creating an external DLL that Visual D can read and choose the right function and use it to take the object and return a string and simply display that string instead of whatever Visual D is generating internally?
>> 
>> struct S
>> {
>>    int x;
>> }
>> 
>> 
>> Somewhere
>> 
>>    auto S_toString(S s)
>>    {
>>       return "S: "~s.x;
>>    }
>> 
>> Should be very simple to do. Visual D just uses that function.
>> 
>> 
>
> What you can do now when using the VS debugger with the mago extension (and not mago selected as debug engine):
>

Where do I get the mago extension? https://github.com/rainers/mago

Or is it build in to Visual D and there is another setting?





January 01

On 31/12/2018 19:37, Michelle Long wrote:
> On Monday, 31 December 2018 at 15:39:05 UTC, Rainer Schuetze wrote:
>>
>> What you can do now when using the VS debugger with the mago extension (and not mago selected as debug engine):
>>
> 
> Where do I get the mago extension? https://github.com/rainers/mago
> 
> Or is it build in to Visual D and there is another setting?
> 

It is installed with Visual D and is automatically used if a .vcxproj project is used, or if debuggger "Visual Studio" is selected for a .visualdproj project.

One way to note that it is in use is checking the language column of the stack: it usually shows a mixture of D, C/C++ and Unknown (see http://rainers.github.io/visuald/visuald/Debugging.html#concord).
January 01
On Monday, 31 December 2018 at 15:39:05 UTC, Rainer Schuetze wrote:
>
>
> On 31/12/2018 11:13, Michelle Long wrote:
>> Display variables in the watch shows the variables in a flat list. Can we just get an override for toString or some other method to change what is displayed?
>> 
>> Surely this can be accomplished?
>> 
>> Even if it means creating an external DLL that Visual D can read and choose the right function and use it to take the object and return a string and simply display that string instead of whatever Visual D is generating internally?
>> 
>> struct S
>> {
>>    int x;
>> }
>> 
>> 
>> Somewhere
>> 
>>    auto S_toString(S s)
>>    {
>>       return "S: "~s.x;
>>    }
>> 
>> Should be very simple to do. Visual D just uses that function.
>> 
>> 
>
> What you can do now when using the VS debugger with the mago extension (and not mago selected as debug engine):
>
> struct Size
> {
> 	int w;
> 	int h;
>
> 	const char* toDebug()
> 	{
> 		import std.conv;
> 		import std.utf;
>
> 		return toUTFz!(char*)(to!string(w) ~ "x" ~ to!string(h));
> 	}
> }
>
> int test()
> {
> 	Size sz = Size(10, 20);
> 	return sz.w * sz.h; // Breakpoint here
> }
>
> Run to the breakpoint and then add watch "sz.toDebug()" to execute the function and display the result.
>
> Some limitations apply:
> - no arguments but the implicit this or context pointer (i.e. delegates
> work, too)
> - doesn't work with slice return values for x64 due to incompatible ABI
> - you have to manually reevaluate in the watch window due to possible
> side-effects
> - the example above currently seems broken for x86, not sure why

Ok, I switched to visual studio debugger added a watch then ran it.

When I initially run the program I get:

sz.toDebug()	D0022: Error: Function call may have side effects	

and when I refresh I get

sz.toDebug()    D0017: Error: Calling functions not implemented


Also, this wasn't really the solution I was looking for because the point as to optimize the visual data flow of the objects in the locals and auto's window.

It would be better if such a function was called automatically. I realize that side effects are a problem but that is on the programmer IMO.   Maybe just require it to be pure? In fact though, maybe side effects could be useful in some cases.

Basically I use the locals mostly so I can quickly see values of data... sometimes too much information is shown that is not relevant since the members are all listed. Usually this obscures some piece of information that is actually relevant because their is not enough visual room. Hence, being able to control what is shown is pretty important to make debugging quicker. Having to go add a watch and revaluate every time significantly slows things down.

If this basically works with the watch window then surely it would not be too much trouble to get it to work with the locals? (assuming you have control over the side effects issue)

It could be an optional "feature": ("Enable Locals toDebug")

January 03

On 01/01/2019 17:57, Michelle Long wrote:
> On Monday, 31 December 2018 at 15:39:05 UTC, Rainer Schuetze wrote:
> 
> Ok, I switched to visual studio debugger added a watch then ran it.
> 
> When I initially run the program I get:
> 
> sz.toDebug()    D0022: Error: Function call may have side effects
> 
> and when I refresh I get
> 
> sz.toDebug()    D0017: Error: Calling functions not implemented

This error is shown only by the mago debug engine, not the extension to VS. (You might have changed the wrong configuration, happens to me quite often.)

> 
> 
> Also, this wasn't really the solution I was looking for because the point as to optimize the visual data flow of the objects in the locals and auto's window.
> 
> It would be better if such a function was called automatically. I realize that side effects are a problem but that is on the programmer IMO.   Maybe just require it to be pure? In fact though, maybe side effects could be useful in some cases.
> 
> Basically I use the locals mostly so I can quickly see values of data... sometimes too much information is shown that is not relevant since the members are all listed. Usually this obscures some piece of information that is actually relevant because their is not enough visual room. Hence, being able to control what is shown is pretty important to make debugging quicker. Having to go add a watch and revaluate every time significantly slows things down.
> 
> If this basically works with the watch window then surely it would not be too much trouble to get it to work with the locals? (assuming you have control over the side effects issue)
> 
> It could be an optional "feature": ("Enable Locals toDebug")
> 

Yes, we could single out some class/struct member function that can be called by the debugger automatically if it exists. It might have bad side effects, though, especially if called on uninitialized pointers.
January 03
On Thursday, 3 January 2019 at 11:44:11 UTC, Rainer Schuetze wrote:
>
>
> On 01/01/2019 17:57, Michelle Long wrote:
>> On Monday, 31 December 2018 at 15:39:05 UTC, Rainer Schuetze wrote:
>> 
>> Ok, I switched to visual studio debugger added a watch then ran it.
>> 
>> When I initially run the program I get:
>> 
>> sz.toDebug()    D0022: Error: Function call may have side effects
>> 
>> and when I refresh I get
>> 
>> sz.toDebug()    D0017: Error: Calling functions not implemented
>
> This error is shown only by the mago debug engine, not the extension to VS. (You might have changed the wrong configuration, happens to me quite often.)
>

So there are two debug settings I see in the project propertiers:

1. Under Configuration Properties/Debugging/Debugger which I selected Visual Studio.

2. Under Configuration Properties/Compiler/Debug/Debug Info which I had set to none for some reason and I changed to "selected debugger" which I take to be what is set in 1.

in which the results are still the same.

So either there is a different setting or it is still using the mago debugger regardless of the setting.


> Yes, we could single out some class/struct member function that can be called by the debugger automatically if it exists. It might have bad side effects, though, especially if called on uninitialized pointers.

Simply not passing a null should work for 99% of cases. Surely one can catch any  errors and ignore them and such. I have no problem with potential side effects as long as I am in control of creating them. After all, if I unintentionally create a side effect then I can fix it and then it shouldn't be a problem. I'm more interested in creating an optimized debug experience that is tailored to my work flow than saving me from dropping an egg. (I understand in some cases it could cause loss of data, but as long as I'm in control of that I have no problem with it, it should be extremely unlikely so not worth the worry)



January 03
On Thursday, 3 January 2019 at 11:44:11 UTC, Rainer Schuetze wrote:
>
>
> On 01/01/2019 17:57, Michelle Long wrote:
>> On Monday, 31 December 2018 at 15:39:05 UTC, Rainer Schuetze wrote:
>> 
>> Ok, I switched to visual studio debugger added a watch then ran it.
>> 
>> When I initially run the program I get:
>> 
>> sz.toDebug()    D0022: Error: Function call may have side effects
>> 
>> and when I refresh I get
>> 
>> sz.toDebug()    D0017: Error: Calling functions not implemented
>
> This error is shown only by the mago debug engine, not the extension to VS. (You might have changed the wrong configuration, happens to me quite often.)
>
>> 
>> 
>> Also, this wasn't really the solution I was looking for because the point as to optimize the visual data flow of the objects in the locals and auto's window.
>> 
>> It would be better if such a function was called automatically. I realize that side effects are a problem but that is on the programmer IMO.   Maybe just require it to be pure? In fact though, maybe side effects could be useful in some cases.
>> 
>> Basically I use the locals mostly so I can quickly see values of data... sometimes too much information is shown that is not relevant since the members are all listed. Usually this obscures some piece of information that is actually relevant because their is not enough visual room. Hence, being able to control what is shown is pretty important to make debugging quicker. Having to go add a watch and revaluate every time significantly slows things down.
>> 
>> If this basically works with the watch window then surely it would not be too much trouble to get it to work with the locals? (assuming you have control over the side effects issue)
>> 
>> It could be an optional "feature": ("Enable Locals toDebug")
>> 
>
> Yes, we could single out some class/struct member function that can be called by the debugger automatically if it exists. It might have bad side effects, though, especially if called on uninitialized pointers.

Another idea long these lines is to automatically evaluate functions of types that take no inputs.

struct X
{
   int x;
   int foo(bool test) { return x; }
}

Here foo can be evaluated. In the watch window it shows up as a function but it then this require evaluation manually which requires editing code. Having the debugger automatically evaluate it makes it much easier.

I realize that side effects could pose a big problem here... ideally they would just be caught and ignored...

Not sure if VD can add some button to the watch window list that one could simply click on to evaluate on this(if not null)?

The idea is having to add code simply to see the value of the method only to have to remove that code later.

X a;
int val = a.foo(); // < this line can be avoided if the debugger would just show us the value it gets. It already shows us the address and other info but not the value which is the most important. It could show the value as a child element and require evaluation.

This might be less feasible but still a useful feature.


January 04
> struct X
> {
>    int x;
>    int foo(bool test) { return x; }
> }


I really mean using a delegate function pointer

+		foo	0x00f61000 {X.foo} int function(X, bool)*


struct X
{
   int x;
   int function(X x, bool test = false) foo;
}

When one expands a variable that contains the function, it can be evaluated on that variable...

so instead of just showing the function pointer info and having to evaluate it manually I was thinking it might be interesting if the function could be evaluated by the debugger since it would be much faster...

I realize this has some problem, specially for function pointers(since we don't know if they are to operate on this or not)...

but if something could be done to easy the strain of having to manually make it work then it would be very useful.

I really wish VD could have it's window like a watch that one could setup to do stuff like this because VS's concept of debugging can be very limiting(although it is getting better, it is still is based on the punch-card method).

Imagine if any debugging info could be gotten with the click of a mouse rather than having to mess around with stuff constantly. The problem with debugging is lack of information and having to find it(to find bugs we have to find out what information is wrong and hence the presentation of information is key to speed up this process).