Hi all,
After a helpful conversation at the pike meet-up last month, I’ve been working on a proof-of-concept debugger for pike code. There is a lot of work left to do, and hopefully others will help me out, but I think that things are at a point where it can be used to do actual debugging.
I’ve put together a page[1] with my notes (and the code contains a lot of TODOs as well). Please take a look at both the page and the branch (bill/debugger-poc) and let me know if you think there are glaring faults in the approach. I am certain that there are a lot of small bugs as well. Please feel free to dig in and help out.
I suspect that a lot of the work to be done won’t really make a lot of sense until there’s a debugging client to use it with (beyond the hilfe I’ve been testing with).
There are a few items that I think I probably need guidance with:
1. Local names aren’t available. Previously, I attempted to parse these out of the source code, but I suspect that’s a losing battle. 2. I was chatting with Mateusz and we were thinking that something that gave us access to the parse tree might be helpful for clients. I wrote a Pike parser in java that is used by the eclipse plugin I wrote, and this allowed generating useful navigation and variable data. Would a native pike equivalent be useful for this and things such as a hypothetical Language Server Protocol? Maintaining duplicate code is probably not the best use of our time; but I suspect that the existing source isn’t really set up to allow this sort of piggy-back use.
As always, feedback and suggestions are welcome!
Bill
[1] http://wiki.gotpike.org/index.pike/PikeDevel/PikeDebugger
H. William Welliver III wrote:
After a helpful conversation at the pike meet-up last month, I???ve been working on a proof-of-concept debugger for pike code. There is a lot of work left to do, and hopefully others will help me out, but I think that things are at a point where it can be used to do actual debugging.
I presume you looked (and rejected?) integrating with gdb?
GDB or https://microsoft.github.io/debug-adapter-protocol/
Best Regards, Tomasz Jamroszczak
I had been wondering if there was a debugging equivilant to LSP… that might be worth looking into. I wonder if many clients beside microsoft’s have developed support for it? I know LSP has pretty broad support.
On Dec 7, 2018, at 6:08 AM, Tomasz Jamroszczak tjamroszczak@opera.com wrote:
GDB or https://microsoft.github.io/debug-adapter-protocol/ https://microsoft.github.io/debug-adapter-protocol/
Best Regards, Tomasz Jamroszczak
I can’t give any input on the debugger, but since I, for the past six months or so, primarily have been doing Typescript in VSCode, I must say it’s quite a challenge the days I have to go back to doing some Pike hacking (not because of the language itself, I love Pike, but from a tooling/developing perspective).
I’ve actually looked into LSP a bit and have had thoughts about implementing an LSP server for Pike (even the most simple stuff would help, you wouldn’t necessarily have to implement the whole shebang). But since Pike pretty much has zero introspection capabilities as of now, what you mentioned about the syntax tree is very interesting from a LSP perspective I think.
(And if using DAP would mean we’d also get an integrated debugger in VSCode, well then that would be awesome.)
Cheers # Pontus
Skickat i rörligt läge
7 dec. 2018 kl. 16:22 skrev H. William Welliver III william@welliver.org:
I had been wondering if there was a debugging equivilant to LSP… that might be worth looking into. I wonder if many clients beside microsoft’s have developed support for it? I know LSP has pretty broad support.
On Dec 7, 2018, at 6:08 AM, Tomasz Jamroszczak tjamroszczak@opera.com wrote:
GDB or https://microsoft.github.io/debug-adapter-protocol/
Best Regards, Tomasz Jamroszczak
I've thought about LSP on and off for a while now, and I think without getting access to the proceeds of the parsing process, it will be difficult to get some of the bigger features.
I think DAP is the way to go right now: it's straightforward, easy to build in Pike, and the hope that additional tools will build support makes a lot of sense to me. I do most of my non-Pike and non-Pike-C development using JetBrains' tools and I'm hopeful that DAP is on the way there.
So, amongst all of this, I've had a thought that makes me die a little inside, but one that could be an opportunity:
I wrote a Pike language plugin for Eclipse some time ago, and part of that involved a fairly accurate language parser. It allowed code navigation and folding and all sorts of basic syntax chacking. I also built a primitive "Language server" in Pike that provided more detailed syntax checking and such. The Java code's biggest problems (aside from being written in Java) were that it supported the current version of pike at the time, and that it was blissfully ignorant of the precompiler.
Would it make sense, as a first proof of concept step, to use the java based parser in combination with the Java module to kick-start an LSP implementation (and possibly help with some of the debugger related niceties? Obviously this has major limitations and is not ideal, but it would allow there to be a tangible result more quickly, and leave a desire to purify the code later on rather than having to wait.
As a side note, I've got a JSON-RPC implementation that I thought would be helpful, but I don't think either protocol is actually JSON-RPC. I can still dump it somewhere in case anyone wants it. Not sure if that's something that should sit next to XMLRPC or not.
Any thoughts?
Bill December 7, 2018 1:30 PM, "Pontus Östlund" <pontus@roxen.com (mailto:%22Pontus%20%C3%96stlund%22%20pontus@roxen.com)> wrote: I can’t give any input on the debugger, but since I, for the past six months or so, primarily have been doing Typescript in VSCode, I must say it’s quite a challenge the days I have to go back to doing some Pike hacking (not because of the language itself, I love Pike, but from a tooling/developing perspective).
I’ve actually looked into LSP a bit and have had thoughts about implementing an LSP server for Pike (even the most simple stuff would help, you wouldn’t necessarily have to implement the whole shebang). But since Pike pretty much has zero introspection capabilities as of now, what you mentioned about the syntax tree is very interesting from a LSP perspective I think.
(And if using DAP would mean we’d also get an integrated debugger in VSCode, well then that would be awesome.)
Cheers # Pontus Skickat i rörligt läge 7 dec. 2018 kl. 16:22 skrev H. William Welliver III <william@welliver.org (mailto:william@welliver.org)>: I had been wondering if there was a debugging equivilant to LSP… that might be worth looking into. I wonder if many clients beside microsoft’s have developed support for it? I know LSP has pretty broad support. On Dec 7, 2018, at 6:08 AM, Tomasz Jamroszczak <tjamroszczak@opera.com (mailto:tjamroszczak@opera.com)> wrote: GDB or https://microsoft.github.io/debug-adapter-protocol/ (https://microsoft.github.io/debug-adapter-protocol/) Best Regards, Tomasz Jamroszczak
The old “debugger” was written on top of GDB. It worked, but was slow and probably would not have been satisfactory for end users. It might be possible to use GDB as the user interface, but then I suspect the type of interface most users may want is not really what end users will want to employ. Plus, I’m not sure that GDB is designed to be a front end to a “foreign" language runtime.
On Dec 7, 2018, at 4:34 AM, Stephen R. van den Berg srb@cuci.nl wrote:
H. William Welliver III wrote:
After a helpful conversation at the pike meet-up last month, I???ve been working on a proof-of-concept debugger for pike code. There is a lot of work left to do, and hopefully others will help me out, but I think that things are at a point where it can be used to do actual debugging.
I presume you looked (and rejected?) integrating with gdb?
Stephen.
pike-devel@lists.lysator.liu.se
-
H. William Welliver III -
Pontus Östlund -
Stephen R. van den Berg -
Tomasz Jamroszczak