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