These are chat archives for derekparker/delve

20th
Sep 2015
Florin Pățan
@dlsniper
Sep 20 2015 13:25
Hi @derekparker. Congrats for the new job @ CoreOS. Have fun!
I'd like to ask you about the values representation, for now for structs (but I'll do some research about maps / slices as well)

In the following program: https://play.golang.org/p/7iLhA1u9Xj if you do a breakpoint on line 19 and then execute locals it will display:

a = struct { A string; B int } {A: demo, B: 10}
i = 139719581106177

which is almost correct. a.A value should be represented as a string, quoted, but seems it isn't. That in itself wouldn't be that much of a problem for now lets say, however, there's no way to access the individual members of the struct, which is the issue.

Florin Pățan
@dlsniper
Sep 20 2015 13:33
Right now, IDEA displays a struct like this: http://i.imgur.com/TlJDU3R.png but I'd like to have something along the lines of how node is displayed in this image: http://i.imgur.com/LsP4MaK.png (with each property of the object forming a different entry)
However that's not easily doable since there's no information on where a field starts and where one ends
Is that something that would be doable? I'm thinking the first step would be to have Variable.Type changed from string to interface{} to begin with, but I don't know what other changes would need to be done, by looking at: https://github.com/derekparker/delve/blob/master/service/api/types.go#L105
Florin Pățan
@dlsniper
Sep 20 2015 13:46
On a closer examination, it seems that all the compound types such as maps, slices and channels as well, are represented with their internal properties as well as external ones. I've updated the example I'm using: https://play.golang.org/p/i4KcVTVjAz
Alessandro Arzilli
@aarzilli
Sep 20 2015 14:21
@dlsniper in http://i.imgur.com/LsP4MaK.png node is a variable of type XValueNodeImpl and all the stuff called my* below it are member fields, correct?
Florin Pățan
@dlsniper
Sep 20 2015 14:22
@aarzilli that's correct, yes
Alessandro Arzilli
@aarzilli
Sep 20 2015 14:24
basically Variable would need to get a new member field: fields []Variable
Florin Pățan
@dlsniper
Sep 20 2015 14:24
in Go this would be something like:
type XValueNodeImpl struct {
    myName string,
    myRawValue: *pointer*
...
}
node := XValueNodeImpl{
    myName: "a",
    myRawValue: nil
...
}

basically Variable would need to get a new member field: fields []Variable

Yes, that could be a way to represent it.

Alessandro Arzilli
@aarzilli
Sep 20 2015 14:27
however I think we should decide on a definition of type Variable that has everything we need, including slices and maps
and all the corner cases were we partially retrieve stuff because of our limits on array size and recursion depth
Florin Pățan
@dlsniper
Sep 20 2015 14:32
Agreed. For example a map[string]int looks like this: http://i.imgur.com/BXVNQ8T.png while a chan int, 10 looks like this: http://i.imgur.com/LyfvgRy.png
and I'd say that the internal properties from Go are useful, if not important, to have as well (for example on a channel you can see the closed flag / status from the debugger which is helpful)
Alessandro Arzilli
@aarzilli
Sep 20 2015 14:34
maps are not currently supported
and neither are chans
Florin Pățan
@dlsniper
Sep 20 2015 14:36
I meant to use them as examples of possible properties, thanks for the heads-up
Alessandro Arzilli
@aarzilli
Sep 20 2015 14:36
go implements both types internally as structs so we are able to read them partially, but they aren't really supported
for maps we only read the stuff that happens to fall inside the first bucket of the map
Florin Pățan
@dlsniper
Sep 20 2015 15:13
aaand I've just found the mailing list, I'll continue there, seems @ignatov already tackled some of the things I've mentioned earlier...
Derek Parker
@derekparker
Sep 20 2015 16:41
@dlsniper @aarzilli this is a good discussion, and actually opens up for something I was already going to mention. I think it would be great to have a proper breakdown of all members of a struct, included in the Variable representation. That would be a huge improvement. Additionally, I think we should think about Variable having short and long (for example) members which would allow us to have both the shortened version of arrays/strings/etc, but also the full value of those variables for display by IDEs, etc.
derekparker/delve#244 and derekparker/delve#243
Alessandro Arzilli
@aarzilli
Sep 20 2015 16:54
I don't think it's feasible to always retrieve whole arrays, it could potentially be gigabytes of data
Florin Pățan
@dlsniper
Sep 20 2015 16:58
Agreed. I'd rather see this as being able to display reasonable sized arrays, say 50 elements (?) and have the ability to get any parts of the array as long as they are still within reason (50 elems) or search for a specific key / value within the array
userland go structs, not the internal ones, should always be retrieved with all their members as for values, the above restrictions / features should be applied to the them
Derek Parker
@derekparker
Sep 20 2015 18:20
Agreed
So then we keep maintaining only our truncated version of arrays/strings/etc... up to some max limit, and then add a Members []Variable field for structs
@dlsniper would it still be nice to have a full/short version of potentially large variables (slices/strings/etc...) for like an "expanded" view in the IDE UI, or is that generally a non-issue?
And to clarify, the full would still have an upper bound
As @aarzilli mentioned the actual data could be more than we would actually like to read in.
Florin Pățan
@dlsniper
Sep 20 2015 18:27
for an IDE I think having the full data would be good, the representation could be handled by the client (so either full, short or otherwise could be displayed)
Alessandro Arzilli
@aarzilli
Sep 20 2015 18:42
If 'full' still has an upper bound what's the difference between 'full' and 'reduced'?
Derek Parker
@derekparker
Sep 20 2015 18:47
Yeah 'full' is a misnomer. Basically I think it could be useful to have a really short, 'preview' representation, and a longer, yet still bounded representation. I think that could be useful in both the terminal and to IDEs, because for example, 'bt -full' can be hard to read with large structs and arrays and so on.
Alessandro Arzilli
@aarzilli
Sep 20 2015 18:53
if it's just visualization then it should be something the client should be able to do once it gets a data structure instead of a preformatted string
Derek Parker
@derekparker
Sep 20 2015 18:57
Yeah I agree with that.
Alessandro Arzilli
@aarzilli
Sep 20 2015 18:57
ok