-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
[WIP] Gdb console #278
[WIP] Gdb console #278
Conversation
1a59b3f
to
bba6d2d
Compare
Hey Antoine, looks really good so far. Also could you put the 'gdb' word into the module path to indicate that this is not a generic debugging facility but rather the gdb extension? Parsing the streams of running process and forwarding them to a terminal in the UI could be useful in other scenarios, too. Do you think it would be feasible to allow registering console parsers on the backend, that get activated on specific situations, for instance if gdb gets started? Maybe that way we could start processes on the backend, have their output parsed and still allow the user a full terminal to interact with the process. It would be nice if we don't need a new terminal for each such case. |
Yes I plan to have a generic debug API but maybe not the way it's been traditionally thought of. Things I'm considering right now:
So to answer this I'm thinking about using:
The main things is this last line, my current thinking is that there's no need for a middle ground API layer for debugging. In the end what Theia cares about is what is displayed in the UI. So if we can just map the UI to state queries and handle those we may have a generic api that will work with any UI. We just need some negotiation between the frontend and the backend to see what schema they can agree on and then display the UI that can be displayed based on the backend schema. This seems way nicer than with JSON-RPC. WIth that I would need to do like: Frontend <---------------------> Backend And this API would be quickly complicated, how to make it generic for any UI and any debugger ? It would need extentions etc... and I think that will be hard to manage. WIth GraphQL I think it can be: Frontend <---------------------------> Backend Note that since much of the UI are direct requests to State I expect the GraphQL Server part will contain mostly pure actions like adding a breakpoint. And all the rest will be a direct mapping UI to State. The complexity will reside in the actions implementation and only in this one place. Rather than at both ends of the backend /frontend + all the state data marshalling. This should make it easy to develop a UI too since the API will be basically just: request your data here's the schema for it. And it's BSD-3 licensed so we can use it :) Note that all this looks good on paper but I really need to make a proof of concept of it... WDYT ? Also about the module, it is generic and not GDB specific, the specific parts are in the MI directory and even that is not GDB specific (could work with lldb). The only gdb specific part is GdbDebugSession.ts and the tests... I needed something to test with... About the terminal, with the refactoring patch I pushed you can create a terminal with any endpoint so in a way you can already do that for any command that is started so long as you expose it from the backend. The missing parts are:
I think these will get worked on in conjunction with the build/launch modules and possibly #154 as we generalize the widget manager etc... I think it would make sense to generalize the backend services that are linked to some UI too. I'm not clear how to manage those mappings yet however. But yes indeed I'll work in that direction. |
Interesting, I guess I'll have to look into GraphQL to understand the advantages you listed.
Isn't vuex usually used in the UI process and not on the backend? |
Yep you may be interested about this podcast (changelog) about it. For vuex and the backend, yes it is usually in the frontend, a more appropriate diagram could have been UI <--> local state (vuex) <-----> GraphQL Server -> Server state (vuex?) -> Debugger Vuex might not be the best thing for this backend side... this link is interesting . There's still much to do to iron this out, but I think the general idea works. |
Is not it very bound to vue/vuex? With JSON-RPC other technologies can be used to implement backend, as Java. Is it possible with vuex? How one provides java-backend? What will be the technology-agnostic protocol specification? |
@akosyakov The tech agnostic protocol is GraphQL, vuex is just a state data store it could be replaced with any data store. Here's a more generic example: Frontend Backend |
Ok, looking forward to a prototype. It would be interesting to see something simple that shows extendibility of this approach compare to a JSON-RPC solution. If the debug extension will be one of core extensions at the end, it would be nice if it does not solve the same issues in a different way to other extensions. There should be a good a case to add new dependencies and have several ways to solve similar issues. |
Yes, like I said I think this approach could be used by other extensions too. Especially if they are data driven. The idea that you specify the types of what you query and then just request the data is very powerful imo compared to defining an API. Using a prototype should it should be more clear. I'll hopefully work on that soon but it will take some time... You may find this blog post from github (they're using graphql now) interesting too as they compare to REST: https://githubengineering.com/the-github-graphql-api/ |
@svenefftinge btw I think you're right about the gdb directory module I will make it so that debug: This module enables registration of the different debuggers and selecton of the right debugger for the project. gdb: Module for the actual debugger |
587c279
to
825da58
Compare
9a23e71
to
d75febe
Compare
Signed-off by: Antoine Tremblay <antoine.tremblay@ericsson.com> [debug] removed trailing space that trips linter [debug] mode backend code to the node folder
Signed-off-by: Antoine Tremblay <antoine.tremblay@ericsson.com>
Signed-off-by: Antoine Tremblay <antoine.tremblay@ericsson.com>
Signed-off-by: Antoine Tremblay <antoine.tremblay@ericsson.com>
FIXME use gdb preferences Signed-off-by: Antoine Tremblay <antoine.tremblay@ericsson.com>
Signed-off-by: Antoine Tremblay <antoine.tremblay@ericsson.com>
Signed-off-by: Antoine Tremblay <antoine.tremblay@ericsson.com>
This has been inactive for months. Can it be closed? |
yes, let's close it. |
You can now start a gdb console with this , you need gdb >= 7.12 in your path