go method naming convention used by capslock is inconsistent with other popular tools #115
Description
The naming convention that capslock uses for Go methods seems to be inconsistent with the conventions used by other tools (for example, debuggers, profilers, and so on).
Here is a toy program to demonstrate: playground link.
This program makes a series of calls into the text/template program from Go's standard library, at runtime most of the time is spent in that package. If I run this program through capslock, the convention used for reporting pointer Go methods is
(*<packagepath>.<type>).<methodname>
instead of the more commonly used
<packagepath>.(*<type>).<methodname>
Here is what I see from capslock:
$ capslock -output=graph > p.dot
$ fgrep '.walk"' *.dot | head -3
"(*text/template.Template).execute" -> "(*text/template.state).walk"
"(*text/template.state).walk" -> "(*text/template.state).errorf"
"(*text/template.state).walk" -> "(*text/template.state).evalPipeline"
$
Examples of other tools that use the latter convention: pprof (profiler), delve (debugger). Specifics:
Profiler:
$ go run hotmeth.go
$ ls *.p
prof.p
$ pprof prof.p
File: hotmeth
Type: cpu
Time: May 6, 2024 at 1:50pm (UTC)
Duration: 1.41s, Total samples = 1.40s (99.57%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top10
Showing nodes accounting for 520ms, 37.14% of 1400ms total
Showing top 10 nodes out of 210
flat flat% sum% cum cum%
120ms 8.57% 8.57% 340ms 24.29% runtime.mallocgc
80ms 5.71% 14.29% 280ms 20.00% text/template/parse.(*lexer).nextItem
50ms 3.57% 17.86% 560ms 40.00% text/template/parse.(*Tree).textOrAction
40ms 2.86% 20.71% 60ms 4.29% reflect.(*structType).FieldByName
40ms 2.86% 23.57% 120ms 8.57% text/template.(*state).evalField
40ms 2.86% 26.43% 300ms 21.43% text/template.(*state).walk
40ms 2.86% 29.29% 250ms 17.86% text/template/parse.(*Tree).nextNonSpace
40ms 2.86% 32.14% 740ms 52.86% text/template/parse.(*Tree).parse
40ms 2.86% 35.00% 130ms 9.29% text/template/parse.(*Tree).peek
30ms 2.14% 37.14% 50ms 3.57% runtime.deductAssistCredit
(pprof)
Debugger:
$ go build hotmeth.go
$ dlv debug .
Type 'help' for list of commands.
(dlv) b text/template.(*state).walk
Breakpoint 1 set at 0x586336 for text/template.(*state).walk() /w/ygo/src/text/template/exec.go:261
(dlv) c
> text/template.(*state).walk() /w/ygo/src/text/template/exec.go:261 (hits goroutine(1):1 total:1) (PC: 0x586336)
256: walkContinue = errors.New("continue")
257: )
258:
259: // Walk functions step through the major pieces of the template structure,
260: // generating output as they go.
=> 261: func (s *state) walk(dot reflect.Value, node parse.Node) {
262: s.at(node)
263: switch node := node.(type) {
264: case *parse.ActionNode:
265: // Do not pop variables so they persist until next end.
266: // Also, if the action declares variables, don't print the result.
(dlv) b (*text/template.state).walk
Command failed: location "(*text/template.state).walk" not found
(dlv)
It would be nice if capslock could work the same way. Thanks.