Skip to content
This repository has been archived by the owner on Jul 15, 2023. It is now read-only.

Test Plan for early Feb (2019) release #2288

Closed
ramya-rao-a opened this issue Jan 29, 2019 · 25 comments
Closed

Test Plan for early Feb (2019) release #2288

ramya-rao-a opened this issue Jan 29, 2019 · 25 comments

Comments

@ramya-rao-a
Copy link
Contributor

ramya-rao-a commented Jan 29, 2019 •
edited
Loading

If you got a notification from this issue, then you are part of the next update to the Go extension.
Thanks and Welcome!

Here, I am listing some of the features and the bug fixes that will go in the next update and for which I need some help in testing. Since I dont work with Go in my day job, I always feel that someone who does Go more than me can help in testing tremendously.

Also mentioned are the folks who logged the bugs/feature requests, those who upvoted it, and those who fixed it by sending PRs as these are the people with the most context on what the issue is.

And when I say "test", you can do a minimum pass of just installing the update and then do nothing special other than going about using VS Code like you do everyday. Or you can test the feature you requested/implemented or the bug you logged/fixed. Or you can test all of the below. Every bit helps.

Drop in a comment in this issue after 2 or 3 days of installing the update i.e the beta version with your findings.

Debugging improvements

Others
@ramya-rao-a
Copy link
Contributor Author

Including other contributors here whose work will be going into the next update, but their work is already tested

@brycekahle, @hellozee, @shreyu86, @oneslash

@kidlj
Copy link

kidlj commented Jan 30, 2019 •
edited
Loading

On #2180

No, the latest beta10 extension still doesn't work well for mod in mod.

How to reproduce:

$ git clone git@github.com:kidlj/demo.git   // outside GOPATH
$ cd demo/gin
$ go build .

vscode_mod_in_mod_issue

By the way, the navigation speed in go mod mode seems to be much faster than 0.8.0 when Docs Tool set to 'godoc'. Thanks.

@primalmotion
Copy link
Contributor

I've quickly checked the debugger, it's the first time it works as expected for me :)

@ramya-rao-a ramya-rao-a mentioned this issue Jan 30, 2019
Closed
@OneOfOne
Copy link
Contributor

The debugger seems to work as intended, yay!

@ramya-rao-a
Copy link
Contributor Author

@kidlj Can you ensure you have updated the dependent tools? Run Go: Install/Update tools and update either godef or gogetdoc (which ever it is that you are using). Also, turn off language server when using this.

@kidlj
Copy link

kidlj commented Jan 31, 2019

@ramya-rao-a Hi. I updated all the dependent tools and have a fresh Code insider version installed with no custom settings. But the beta10 extension still doesn't work for mod in mod.

Here is the output screenshot:

vscode_mod_in_mod_issue

Can you reproduce this with the testing project? https://github.com/kidlj/demo

@krasoffski
Copy link

I was not able to reproduce #2197 on my pet projects. With big code base will try a little bit later.

@ramya-rao-a
Copy link
Contributor Author

@kidlj #2180 was tracking the bug that Go to definition doesnt work in the files that are part of the sub module. This is fixed.

The case you are trying in your screenshots is the below

I have created #2296 to track this.

@bihe
Copy link

bihe commented Jan 31, 2019

Regarding #2002

Wow, that's a great debug experience!

I was first 😕 because of

The issue of breakpoints getting added successfully only before a debug session or when another
breakpoint is hit is a limitation on delve's side which doesn't allow interacting with the target process when it is running.

I can now happily add/remove/.. breakpoints even if there is no active breakpoint currently hit.
So the stop-breakpoint-start approach works perfectly!

If the debug process is stopped, also the 'dlv' and 'debug' processes are terminated.

I summary overachieved - because I did not expect the freedom to change breakpoints not matter when 👍

Environment:

  • Ubuntu 18.10 x86_64
  • vscode 1.30.2
  • vscode-go 0.8.1-beta.10
  • go version ggo1.11.4 linux/amd64

@ramya-rao-a
Copy link
Contributor Author

ramya-rao-a commented Feb 4, 2019 •
edited
Loading

cc @lggomez to take a look at the debugging features and bug fixes, as he has added quite a few features/bug fixes in this area in the past himself.

@karim
Copy link

karim commented Feb 4, 2019

@ramya-rao-a I don't know if I should reply here to say everything is working as expected or reply only if there is a problem with the latest beta.

Your fix in #2246 is working great and I tested it using the latest beta. Thanks again. 😃

@ramya-rao-a
Copy link
Contributor Author

I don't know if I should reply here to say everything is working as expected or reply only if there is a problem with the latest beta.

Even feedback that everything is working as expected is very useful. Thanks @karim!

@lggomez
Copy link
Contributor

lggomez commented Feb 5, 2019

I did a quick rundown test of the debug changes and so far It is good, at least on a minimalist test package. I am on leave until thursday so I wont be able to debug complex and productive tests until then

This release is going to be really great

@tcagan
Copy link

tcagan commented Feb 5, 2019

Hi,
To chime in :

Over all - this version is great and debugging experience is much improved - thanks for everyone (@ramya-rao-a specifically) for this!

@lggomez
Copy link
Contributor

lggomez commented Feb 5, 2019

@tcagan just so you know, recursion depth can be configured in the debugger via settings:

"go.delveConfig": {
        "useApiV1": false,
        "dlvLoadConfig": {
            "followPointers": true,
            "maxVariableRecurse": 3,
            "maxStringLen": 100,
            "maxArrayValues": 100,
            "maxStructFields": -1
        }
    }

Be careful with the values because the traversal time might grow exponentially, I would not recommend a maxVariableRecurse value higher than 5, but you're welcome to try

@jhendrixMSFT
Copy link
Member

@tcagan do you have an example where deeply nested structures stops working so I can investigate? My change should work for structs of arbitrary depth (was the intent anyways).

@tcagan
Copy link

tcagan commented Feb 6, 2019

@jhendrixMSFT - please see attached image.

I am using go-jira and looking at an instance of Issue struct.

My variable name is issue.

At the top of the watch pane, you can see it expanded - it shows issue.ChangeLog.Histories but does not expand the items within that slice.

Following, I am showing specific item in the Histories slice - here it does not expand items in Items slice.

Following you can see a specific item in the Items slice (just for reference that the items are not empty).

Is this the expected behavior?
Could it possibly be related to slice/array expansion?
Maybe I Should change something in the settings?

screen shot 2019-02-06 at 8 41 23 am

@tcagan
Copy link

tcagan commented Feb 6, 2019

@ramya-rao-a btw, this version also fixed an issue I've had that the debugged process wasn't terminated (for a web api project, I had to kill it manually each time as it was blocking my port and I couldn't re-run)

@segevfiner
Copy link
Contributor

#2215 seems working. I wish we could also get the godef part working too, but they don't seem responsive to the PR...

@jhendrixMSFT
Copy link
Member

@tcagan thanks this is helpful. The problem here is the eval expression fails, see the output in the debug console.

Failed to evaluate expression - 1:28: expected operand, found 'go'

The type name returned by delve, github.com/andygrunwald/go-jira.ChangelogHistory, appears to be the problem. I'll investigate further.

@ramya-rao-a
Copy link
Contributor Author

@jhendrixMSFT Thats a good find, but I believe we should continue investigating that, but dont need to block the build for it. Can you log a separate issue for this and copy over @tcagan's feedback in #2288 (comment)

@tcagan For #2288 (comment), is there a github issue for it?

@ramya-rao-a
Copy link
Contributor Author

The 0.9.0 update is now released, thanks everyone for all the help :)

Happy Coding!

@dhowden
Copy link
Contributor

dhowden commented Feb 7, 2019 •
edited
Loading

Did this break "run benchmark"? It seems to be passing the name of benchmark X to go test -run ^X$ instead of doing the old go test -run ^$ -bench ^X$

@ramya-rao-a
Copy link
Contributor Author

@dhowden That's right, thanks! Released 0.9.1 with the fix.

@tcagan
Copy link

tcagan commented Feb 7, 2019

@ramya-rao-a I believe its related to #1010 (and fix #2198 does improved it).
Depending on what @jhendrixMSFT finds - it could be related or something new.

@jhendrixMSFT jhendrixMSFT mentioned this issue Feb 11, 2019
Merged
@lggomez lggomez mentioned this issue Feb 13, 2019
Merged
@jhendrixMSFT jhendrixMSFT mentioned this issue Feb 14, 2019
Closed
@vscodebot vscodebot bot locked and limited conversation to collaborators Mar 24, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests