Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VSCode debug adapter protocol implementation #2447

Merged
merged 1 commit into from
Aug 21, 2018
Merged

Conversation

tolusha
Copy link
Contributor

@tolusha tolusha commented Jul 26, 2018

Reference issues

#1573
eclipse-che/che#8383

Description

This PR brings VSCode debug adapter protocol to the Theia IDE

Implemented features:

Establish Debug Sessions

  • Connect/Disconnect remote target
  • Start/Stop debug targets

Threads

  • Show threads of debug targets
  • Show Stack of Suspended Threads
  • Show Source for Suspended Threads

Suspend/Resume Actions

Stack Frame Variables

  • Display
  • Modify

Step actions

  • In/out/over

Breakpoints

  • Show list of Breakpoints
  • Remove Breakpoint

Line Breakpoint

  • DAP Create Line Breakpoint
  • display in editor

Demo vidoes

Demo 1
Demo 2

@tolusha tolusha added the dap debug adapter protocol label Jul 26, 2018
@tolusha tolusha self-assigned this Jul 26, 2018
@tolusha tolusha requested a review from akosyakov July 26, 2018 13:15
Copy link
Member

@paul-marechal paul-marechal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work !

Although here are the things that I picked up:

  • I am able to put breakpoints in launch.json (?)
  • The only breakpoints that show up in the debug panel are the ones placed in the json file, placing breakpoints in packages/filesystem/src/node/node-filesystem.ts doesn't show up in the panel.
  • Couldn't find a way to debug using Electron for Theia (maybe just a missing dep in the package.json)

Regarding the following coding pattern:

function shouldBeAsync(...args): Promise<void> {
    stuff();
    return Promise.resolve();
}

The issue here is that if an error is thrown, it will be done synchronously, and you will not be able to catch it using shouldBeAsync().catch(e => ...).

If this is intended, it's fine I guess.

I might have missed some things, but I'm sure Anton will have sharper eyes :)

@inject(ActiveLineDecorator) protected readonly lineDecorator: ActiveLineDecorator,
@inject(BreakpointDecorator) protected readonly breakpointDecorator: BreakpointDecorator,
@inject(BreakpointStorage) protected readonly storage: BreakpointStorage,
@inject(BreakpointsApplier) protected readonly breakpointApplier: BreakpointsApplier,
Copy link
Member

@paul-marechal paul-marechal Jul 27, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BreakpointDecorator, BreakpointStorage, so why BreakpointsApplier ?

Maybe it would be more consistent to call it BreakpointApplier too? (-s)

(even the variable is called breakpointApplier)

super.setMarkers(uri, BREAKPOINT_OWNER, newBreakpoints);
});

return Promise.resolve();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

async update(data: Ext...) { ... }

Then you don't need the return Promise.resolve().

existedBreakpoints.push(breakpoint);
super.setMarkers(uri, BREAKPOINT_OWNER, existedBreakpoints);

return Promise.resolve();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Convert function to async and you won't need the return.

const breakpoints = super.findMarkers({ uri, dataFilter: b => DebugUtils.makeBreakpointId(b) !== id }).map(m => m.data);

super.setMarkers(uri, BREAKPOINT_OWNER, breakpoints);
return Promise.resolve();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make async

* @returns true if breakpoint exists and false otherwise
*/
exists(id: string): Promise<boolean> {
return Promise.resolve(super.findMarkers().some(m => DebugUtils.makeBreakpointId(m.data) === id));
Copy link
Member

@paul-marechal paul-marechal Jul 27, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

function async exists(id: string): Promise<boolean> {
    return super.findMarkers().some(m => DebugUtils.makeBreakpointId(m.data) === id);
}

(added the function keyword here for github to color the code)

@thegecko
Copy link
Member

Really nice work @tolusha

I can confirm this works as expected when attaching to an existing node process and I think it's a really good base to build a debug experience matching vscode!

I took the testing further by implementing the vscode example mock debug extension and have this working as a launch request type debugger instead of the attach request type used in your node-debug package.

screen shot 2018-07-28 at 20 02 41

I'm happy to share this if anyone needs it, but I'm not sure how valuable it is to the Theia project.

In order to create a launch debugger, I needed to fill in a couple of very small bits in the debug code base. These can be seen here:

https://github.com/thegecko/theia/commits/vscode-debug-launch

Please let me know if you'd like to see this as a PR onto the vscode-debug-protocol branch before merging this PR or as a separate PR onto master later.

@tolusha
Copy link
Contributor Author

tolusha commented Jul 30, 2018

https://github.com/thegecko/theia/commits/vscode-debug-launch
@thegecko Let's create a PR into vscode-debug-protocol

@thegecko
Copy link
Member

@tolusha Done: #2463

@svenefftinge
Copy link
Contributor

@tolusha Great work!

Is there a specific reason you made the debug view horizontal? I think chrome devtools and vs code do it really well by laying it out vertically, because with the collapsable sections you can have all the important sections in one view without wasting screen estate if you are not interested (because you can collapse). Also it would be more familiar to devs because of the two tools mentioned above are widely used.

@tolusha
Copy link
Contributor Author

tolusha commented Jul 31, 2018

@marechal-p
PR is updated

@tolusha
Copy link
Contributor Author

tolusha commented Jul 31, 2018

@svenefftinge
In my opinion a horizontal panel is more useful than a vertical one.
It is a matter of restyling to make it vertical but I prefer to postpone it until the full design of the debug panel is ready.

@thegecko
Copy link
Member

IMO, if in doubt we should copy the layout used in vscode. People are used to it and debug adapters have been built with that layout in mind.

@svenefftinge
Copy link
Contributor

svenefftinge commented Aug 10, 2018

It is a matter of restyling to make it vertical but I prefer to postpone it until the full design of the debug panel is ready.

Agreed. Could you clean up / squash the history a bit? Also the DCO check fails.

@tolusha
Copy link
Contributor Author

tolusha commented Aug 14, 2018

screenshot from 2018-08-14 11-57-57

@tolusha
Copy link
Contributor Author

tolusha commented Aug 14, 2018

@svenefftinge
Commits are squashed and a new style is applied.

@svenefftinge
Copy link
Contributor

svenefftinge commented Aug 14, 2018

@tolusha the build fails. Looks like it is because you run theia test but don't have any ./src/**/*.*spec.ts.

https://travis-ci.org/theia-ide/theia/jobs/415824849#L4037

In other cases we have put a dummy file.

@akosyakov
Copy link
Member

Please add new packages to travis file for caching. I see there is a binary file, it is supposed to be checked in or downloaded each time?

@tolusha
Copy link
Contributor Author

tolusha commented Aug 14, 2018

@paul-marechal
Copy link
Member

paul-marechal commented Aug 14, 2018

@tolusha: it makes sense, although the file is currently checked in:
https://github.com/theia-ide/theia/pull/2447/files#diff-9253598657d98c7141891c1e62abaf23

git rm --cached packages/debug-nodejs/download/vscode-node-debug.tar.gz to remove it from the index, unless this is intended.

},
"devDependencies": {
"@theia/ext-scripts": "^0.3.13",
"gulp": "^3.9.1",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please, if there is nothing else used from gulp, could you convert it to plain nodejs like in @theia/java it's huge library to just download an archive in the end. Thanks!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In @tolusha 's defence, I'm surprised Theia doesn't use a task runner like gulp already. IMO, the npm scripts and theia-cli are alien and unwieldy. Perhaps a discussion for another time, however :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can bring the matter for next week's dev meeting?
I would be interested to hear about it :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not about Theia, but about downstream projects, they will have to install gulp just to download binaries.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using npm scripts as build tools is a common practice in JS world: https://www.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/
As well as abstracting common scripts via packages: https://blog.kentcdodds.com/automation-without-config-412ab5e47229

I don't really see a need to pull more dev dependencies and write additional js files for them.

@tolusha
Copy link
Contributor Author

tolusha commented Aug 15, 2018

@AlexTugarev @marechal-p
fixed

@tolusha tolusha force-pushed the vscode-debug-protocol branch 2 times, most recently from 5828aea to 4eafe9d Compare August 17, 2018 11:42
@tolusha
Copy link
Contributor Author

tolusha commented Aug 20, 2018

@svenefftinge
Any chance to merge?

@@ -58,6 +59,7 @@ export class MonacoEditor implements TextEditor, IEditorReference {
protected readonly onSelectionChangedEmitter = new Emitter<Range>();
protected readonly onFocusChangedEmitter = new Emitter<boolean>();
protected readonly onDocumentContentChangedEmitter = new Emitter<TextDocumentChangeEvent>();
protected readonly onMouseDownEmitter = new Emitter<EditorMouseEvent>();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please add it toDispose in the constructor

const { lineNumber, column } = e.target.position;
const event = {
target: {
...e.target,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why to copy other properties if they are not exposed? range and mosueColumn should not be copied but properly converted from 1-bazed to 0-based positions.

Copy link
Member

@akosyakov akosyakov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it looks safe, there almost no changes in other packages.

Please take care of comments in monaco package and merge.

Signed-off-by: Anatoliy Bazko <abazko@redhat.com>
@tolusha
Copy link
Contributor Author

tolusha commented Aug 21, 2018

@akosyakov
CI failed, but I don't see how it related to my PR

@paul-marechal
Copy link
Member

paul-marechal commented Aug 21, 2018

@tolusha if you are worried about appveyor: don't... The current error log is something rather common for some reason.

Maybe someone can restart the build, but travis linux + mac is green, so it should be good!

@akosyakov
Copy link
Member

@tolusha if travis is green it is enough, tests are flaky on windows all the time

@tolusha tolusha merged commit 18a37db into master Aug 21, 2018
l0rd added a commit to l0rd/debug-adapter-protocol that referenced this pull request Oct 22, 2018
@tolusha tolusha deleted the vscode-debug-protocol branch June 13, 2019 18:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dap debug adapter protocol
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants