www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - toString

reply Michelle Long <HappyDance321 gmail.com> writes:
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.
Dec 31 2018
next sibling parent Basile B. <b2.temp gmx.com> writes:
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 ;)
Dec 31 2018
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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
Dec 31 2018
next sibling parent reply Michelle Long <HappyDance321 gmail.com> writes:
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?
Dec 31 2018
parent Rainer Schuetze <r.sagitario gmx.de> writes:
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).
Jan 01 2019
prev sibling parent reply Michelle Long <HappyDance321 gmail.com> writes:
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")
Jan 01 2019
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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.
Jan 03 2019
next sibling parent Michelle Long <HappyDance321 gmail.com> writes:
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)
Jan 03 2019
prev sibling parent reply Michelle Long <HappyDance321 gmail.com> writes:
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.
Jan 03 2019
parent Michelle Long <HappyDance321 gmail.com> writes:
 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).
Jan 04 2019