Comments (13)
@derekparker, I think more general functionality to display a variable as fmt.Sprintf("%s", x)
or fmt.Sprintf("%v", x)
would be quite useful in cases when x
is a big.Int
or a big.Rat
or any other user type with nice String() implementation.
May be a new command can be introduced for this: pf "format spec like %s, %d" s d
Dealing with breakpoints inside String()
or Error()
methods might be a bit tricky though.
from delve.
@binary132 Ah, I understand what you're saying. Makes sense.
from delve.
I explored code a little for this. If nobody is working on variable printing then I'd like to take this up next.
It will require thinking a bit since there are more of similar type in line [ #61 #116 #117 #122 ]
Have you thought about how to go about this?
Should use a pretty printer package?
http://godoc.org/github.com/kr/pretty
https://github.com/davecgh/go-spew
It can get really messy if we think of all of these together.
package.ExportedSliceOfMap[index][key].MemberStruct.MemberSlice[index]
is kind of scary.
Should this be thought of?
from delve.
I've thought a bit about this and IMHO the optimal way to do this is in three steps
- split the code in variables to separate calculation of addresses with reading values, this will help with step 3 and also make implementing a set command possible
- change the code that reads values to read them into some data structure instead of producing a string directly, then implement a pretty printer on top of that
- once 1 and 2 are in place use go/parser.ParseExpr to parse expressions and write an interpreter for (a subset of) the go expression sublanguage.
Printing the value of an expression like that would then be automatic. AFAIK you won't be able to use a pretty printer because those use reflect that's not going to work across processes.
I have step 1 almost done but I've been holding off publishing it because it depends on my other two PRs.
from delve.
@aarzilli you're correct and that sounds like a reasonable plan for the other issues mentioned by @Omie. This issue does not deal with evaluation based off of an expression, it involves adding functionality to call a Go function and store the return value(s) and then essentially print the string
that is returned by .Error
to the screen.
from delve.
@kostya-sh are you thinking of trying to use the format string and have Delve eval the variables used and then create the formatted string itself? That's kind of interesting, and could lead to the type of command you've suggested. Either way, we're still going to need to land #119 eventually before 1.0 and it would be nice to just be able to use that to "call" the Error
method and read the string that it returns.
from delve.
@derekparker, no, my example of a new command wasn't very clear. s
and d
are names of local variables there, they could have been foo
and bar
. I wasn't aware of #119. With function calls one can just write:
fmt.Sprintf("format spec like %s, %d", foo, bar)
making a new command unnecessary.
from delve.
it's been a while here. Is this issue still open? I'm not an expert, I only recently started using go.
I would love to take this up, could someone just give me a few pointers about where to start digging at the source?
from delve.
@gideondsouza you would have to first implement function calls, the problem there is interacting with the go runtime in a way that isn't fragile and doesn't upset the runtime: figure out how if there is enough stack space, extend the stack if there isn't enough for the call, deal with panics caused by the injected call, figure out how to make the garbage collector happy about a stack frame that would normally be impossible.
from delve.
As a user, I'd really prefer to see the value of the error if I'm step-through debugging / tracing. Maybe this should be some kind of "alternate" print command, like "render" or "format"? (That could also be useful for rendering things like byte buffers, maybe using spew.Dump
?)
from delve.
@binary132 I'm not sure I completely understand what you mean. The string returned from .Error()
should be the formatted value of that error.
from delve.
Yes, print err.Error()
should print that string, but print err
should show the value of the interface.
If I had my pick, I'd take what @kostya-sh suggested. If forced to choose between print
displaying an interface's value or its String()
result, I would definitely rather see the real value (plus calling a method could cause side effects, allocations, etc. which print
should be expected not to trigger implicitly.)
from delve.
Going to close this out as technically this is possible now. You can execute call err.Error()
and get the string back.
from delve.
Related Issues (20)
- panic when delve process is stopped HOT 1
- support for Termux debugger with the Android
- How build arm version HOT 1
- Support `dlv types` from DAP (the same way `types` is supported in the command line `dlv` REPL)
- polish go1.23 range-over-func UX HOT 1
- Does delve ignore // line instructions during debug HOT 1
- Breakpoints do not work in packages with a TestMain(*testing.M) function HOT 1
- Unable to print a package string const value during a breakpoint HOT 1
- Error clearing stack watchpoint HOT 2
- Add defer functions to follow-calls tracing option
- Breakpoint line numbers not matching HOT 1
- Hitting compile error when launching delve in devbox HOT 4
- `undefined behavior - version of Delve is too old for Go version 1.22.3 (maximum supported version 1.20)` HOT 2
- trace: allow tracing from (or skip tracing on) G-less threads
- panic when data length is greater than memCache size
- Unable to find escape variables when using Delve HOT 7
- Fail to set watchpoint after clearing one of four HOT 3
- Dwarf parsing infinite loop causes OOM HOT 1
- Feature request: restart the current function HOT 6
- Seeing a warning that delve is too old for the latest Go version 1.22.5 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from delve.