Debugging: Map keys/values are shown in array syntax as alternating elements

[willfaught]

Example:

For something like a large map[interface{}]interface{}, it can be difficult to see at a glance which elements are keys and which are values. Perhaps there's a way to number the key/value pairs, and display the key and value for each pair on their own adjacent lines?

---

• VSCode Version: Code 1.18.1 (929bacba01ef658b873545e26034d1a8067445e9, 2017-11-16T18:23:26.125Z)
• OS Version: Darwin x64 17.2.0
• Extensions:

Extension	Author (truncated)	Version
vscode-docker	Pet	0.0.22
sort-lines	Tyr	1.3.0
githistory	don	0.2.3
markdown-table-formatter	jos	0.2.3
Go	luk	0.6.69
prettify-json	moh	0.0.3
azure-account	ms-	0.2.2
rewrap	stk	1.5.3
gitblame	wad	2.2.0
vscode-proto3	zxh	0.1.2

[ramya-rao-a]

Can you share a sample code that I can use to see what's going on?

[willfaught]

Not at the moment, it's proprietary code. I'll keep my eyes open for a repro I can post here.

[vanhumbeecka]

As asked, below is a sample code where this problem occurs.
It is the same as referenced in https://github.com/derekparker/delve/issues/1039#issuecomment-350533067
In that issue, you can see the output in a screenshot.

package main

import (
	"bufio"
	"fmt"
	"log"
	"os"
	"strconv"
)

type Pair struct {
	num      int
	subTotal int
}

func check(e error, msg ...string) {

	if e != nil {
		panic(e)
	}
}

func main() {
	arg := os.Args[1:]
	fmt.Println(arg)
	fmt.Println(len(arg))

	f, err := os.Open("./input")
	check(err)
	defer f.Close()

	scanner := bufio.NewScanner(f)
	for scanner.Scan() {
		m := make(map[int]Pair)
		if len(arg) > 0 {
			fmt.Println("puzzle B")
			m = toMap2(scanner.Text())
		} else {
			fmt.Println("puzzle A")
			m = toMap(scanner.Text())
		}

		fmt.Println(countMap(m))
	}

	if err := scanner.Err(); err != nil {
		log.Fatal(err)
	}

}

func toMap(line string) map[int]Pair {
	// map[index][subtotal]
	res := make(map[int]Pair)

	for i, c := range line {
		number, _ := strconv.Atoi(string(c))
		res[i] = Pair{number, 0}
		if i > 0 {
			if res[i-1].num == res[i].num {
				res[i] = Pair{res[i].num, res[i].num}
			}
		}
		// fmt.Printf("%d -- %d -- %d\n", i, res[i].num, res[i].subTotal)
	}
	// count 1st number
	if res[len(res)-1].num == res[0].num {
		res[0] = Pair{res[0].num, res[0].num}
	}

	return res
}

func toMap2(line string) map[int]Pair {
	res := make(map[int]Pair)
	jump := len(line) / 2
	for i, c := range line {
		number, _ := strconv.Atoi(string(c))
		res[i] = Pair{number, 0}
	}

	for k := range res {
		// if i > jump {
		// 	if res[i-jump].num == res[i].num {
		// 		res[i] = Pair{res[i].num, res[i].num}
		// 	}
		// }
		if res[k%len(line)].num == res[(k+jump)%len(line)].num {
			res[k] = Pair{res[k].num, res[k].num}
		}
	}

	return res
}

func countMap(m map[int]Pair) int {
	count := 0
	for _, v := range m {
		count = count + v.subTotal
	}
	return count
}

[ramya-rao-a]

@vanhumbeecka This program seems to be expecting some input. Can you share the debug config that you are using?

[Rakhmanov]

@ramya-rao-a, I think that's what is main concern. This is map of strings, the OP has map of slices, but the effect is the same, in debug window they are displayed as an array of strings.

[ramya-rao-a]

Thanks for the sample code @Rakhmanov

This seems to be an issue with how delve sends data to the debug adapter in the Go extension. If you add "trace": "verbose" to your debug configuration, you can see logs in the debug console for every request sent to and response received from delve

The request for ListLocalVars returns an object a with 2 children one and abc instead of a single child.

[ramya-rao-a]

I have logged upstream issue https://github.com/derekparker/delve/issues/1115

[Rakhmanov]

@ramya-rao-a
Thanks for acting on it, It seems on the delve side its intentional. Makes sense as they said structs can be used as keys. However it is very confusing when seen in debugger. May be there is some front end implementation that can display it nicely is due.

[lggomezml]

I agree with @Rakhmanov, as long as we have the type info all maps could be handled in a different way rather than the same way in which arrays/slices are transformed

Extracting the GoReflectKind.Map case and chaging the variable traversal accordingly should do the trick right?

https://github.com/Microsoft/vscode-go/blob/31e9cc2bc1a337b4a62c0adf5d029536d7095960/src/debugAdapter/goDebug.ts#L718-L727

[lggomez]

@ramya-rao-a I was about to give this issue a try locally and I see you already implemented the fix

Thanks for the celerity

[ramya-rao-a]

Thanks to your pointer in #1384 (comment) I realized this was an easy fix :)

Others,
The fix for this issue is now out in the latest update to the Go extension (0.6.77)

[willfaught]

Thanks!

…

On Tue, Feb 20, 2018 at 2:18 PM Ramya Rao ***@***.***> wrote: Closed #1384 <#1384>. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1384 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD5VjINiyIeFAzkxhmsA-r_nWgffGpnks5tW0TQgaJpZM4Qv8Sj> .