• Jethro (6/6) Apr 16 2017 Debugging tuples is pretty hard to decypher. Instead of using
• Jethro (9/15) Apr 16 2017 Also, when displaying the value in watches, it would be nice to
• Jethro (4/4) Apr 16 2017 On other require: Please don't allow expanding strings that do
• Jethro (13/13) Apr 17 2017 Also, use the named tuple elements, if they exist, to replace the
• Rainer Schuetze (7/23) Apr 18 2017 Yeah, having an option to hide the field names makes sense. It can help
• Jethro (4/4) Apr 17 2017 Another idea:

Jethro <qyzz gr.ff> writes:

Debugging tuples is pretty hard to decypher. Instead of using 
_expand_field, could it be possible to display the names of the 
fields of they exist?

After all, the type is listed with the names so it should be easy 
to get them from the type string and just replace the displayed 
_expand_field with them.

Jethro <qyzz gr.ff> writes:

On Sunday, 16 April 2017 at 21:00:59 UTC, Jethro wrote:
 Debugging tuples is pretty hard to decypher. Instead of using 
 _expand_field, could it be possible to display the names of the 
 fields of they exist?

 After all, the type is listed with the names so it should be 
 easy to get them from the type string and just replace the 
 displayed _expand_field with them.

Also, when displaying the value in watches, it would be nice to 
not show the field name, they take up so much room that one can't 
really see much of the tuple, specially with nested values.

{__expand_field_0="A", __expand_field_1={__expand_field_0="B", 
__expand_field_1=0}, ...}

Instead

{"A", {"B", 0}, ...}

It's much more concise and is not confusing at all.

Jethro <qyzz gr.ff> writes:

On other require: Please don't allow expanding strings that do 
not really need it. e.g., short strings that fit in the value 
textbox easily. The extra "expand glyph" can be confusing as it 
doesn't help distinguish between strings and actual arrays.

Jethro <qyzz gr.ff> writes:

Also, use the named tuple elements, if they exist, to replace the 
_expand_field text.

So, instead of

_expand_field_0
_expand_field_1
_expand_field_2
_expand_field_3

when expanding a tuple in the watch, one would get something like

Name
Address
Zip
Other

which is much more informative.

Rainer Schuetze <r.sagitario gmx.de> writes:

On 17.04.2017 01:43, Jethro wrote:
 On Sunday, 16 April 2017 at 21:00:59 UTC, Jethro wrote:
 Debugging tuples is pretty hard to decypher. Instead of using
 _expand_field, could it be possible to display the names of the fields
 of they exist?

 After all, the type is listed with the names so it should be easy to
 get them from the type string and just replace the displayed
 _expand_field with them.

 Also, when displaying the value in watches, it would be nice to not show
 the field name, they take up so much room that one can't really see much
 of the tuple, specially with nested values.

 {__expand_field_0="A", __expand_field_1={__expand_field_0="B",
 __expand_field_1=0}, ...}

 Instead

 {"A", {"B", 0}, ...}

 It's much more concise and is not confusing at all.

Yeah, having an option to hide the field names makes sense. It can help 
with any struct, not only tuples.

Extracting the names of the fields from the template type string is a 
bit more involved and very much specialized to the implementation of 
Tuple. Maybe a VS visualizer works, but I suspect it needs some 
visualizer macro system in mago.

Jethro <qyzz gr.ff> writes:

Another idea:

With tuples, and possibly other types that use enum, instead of 
giving the integer value, give the enum string name. This way it 
is more informative.