Re: Debugger status

Hi! Thanks for the update. I think it makes most sense to get the portions of the code that exist within existing files merged into the 8.1 codebase. Very little of the code is within an active path for most users, and I think the risk of running into unwanted behavior in the short term is

Re: Debugger status

Hey Bill, Sorry for the late response. I'm happy for your interest in continuing the debugger project. Most of the answers to your questions can be found in the 'debugger, status and suggestions sought' thread, in the last few letters. Archive link for convenience: [1]. For some wicked reason my

Re: debugger, status and suggestions sought

As discussed, I did the pre-merge cleanup, except: > * set_debugger() should probably not be an efun. Apparently it has to be, else it appears as an unknown identifier in master.pike. > * Move low_enable_breakpoint and low_disable_breakpoint to program.c I didn't really see any point in this,

Re: debugger, status and suggestions sought

Thanks for the feedback! Trying to limit time spent at the computer during summertime, but I'll certainly fix the issues before the next meetup. niedz., 4 sie 2019, 18:37 użytkownik Peter Bortas napisał: > Hi Mateusz, > > We had a long discussion about this, and the main reservation was if >

Re: debugger, status and suggestions sought

Hi Mateusz, We had a long discussion about this, and the main reservation was if having one global debug object in master is the correct final solution. But no one had plans on an alternative solution right now, and we absolutely do not want to stand in the way of something that finally provides

Re: debugger, status and suggestions sought

Previously, on Pike Debugger: we've ended up with a working proof-of-concept debugger with a set of cool features, including breakpoints, stepping, variable inspection, and an ability to debug a selected thread by firing SIGUSR1 at it (as a way ti debug multi-threaded programs). Unfortunately,

Re: debugger, status and suggestions sought

Update: with regard to multi-process debugging, some time ago I wrote a fun little feature that lets you open a debug server by sending a SIGUSR1 to a selected process/thread. A temporary substitute to multi-threaded debugging, also useful for debugging forked processes. I haven't pushed it to

Re: debugger, status and suggestions sought

I've verified my hypothesis and made breakpoints in classes work with commit [1]. The way I did it solves the problem, but I believe it should have been done on a lower level. I've also looked up the program cache and verified that there in fact already is such a structure. I'll work on avoiding

Re: debugger, status and suggestions sought

That's good news, looking forward to see the update! My branch is a little specific - I've completely disabled the Hilfe debugger, replacing it by the debug adapter. For this reason you need a DAP-compliant IDE to test on my branch. The examples I provided earlier should suffice, but if you have

Re: debugger, status and suggestions sought

That’s cool. I suspect that Parser.LR may require a bit of work to make it nicer to build a parser of this complexity, but I think it would be worth the effort, as it would allow a lot of interesting information to be extracted from pike classes… dependency graphs, data to allow refactoring,

Re: debugger, status and suggestions sought

CCing dozzie (aka Jarowit). He is proficient with parsers and is eager to put some effort to carry this step on. pon., 11 mar 2019 o 17:43 Mateusz Krawczuk napisał(a): > What exactly is this hypothetical parser needed for? Can you give more > detail on what is needed? > > I've been working on

Re: debugger, status and suggestions sought

What exactly is this hypothetical parser needed for? Can you give more detail on what is needed? I've been working on the debug adapter for a while now and made it possible to work with DAP-compliant IDEs, like VScode. You can check it out at the 'debugger' branch of my Pike fork [1].

Re: debugger, status and suggestions sought

Update: I took a little time this morning and merged grubba's local variable names branch with the debugger branch, and it looks pretty good. Seems to me that the next piece of infrastructure that's needed probably involves some sort of Pike parser. I've looked at the java parser a bit and I'm

Re: debugger, status and suggestions sought

I think there’s a sense that the parts of the debug infrastructure that run within the process under debug should be as lightweight as possible, and not be active unless the process is being debugged. In keeping with this line of thought, I think the in-process portion of the agent shouldn’t

Re: debugger, status and suggestions sought

Forget that pull request, I've got something way better! I gave up on hacking quicktype to make it spit out the protocol objects they way I wanted and started to rewriting it manually. I also came up with a proof-of-concept Debug Adapter written in Pike. If you would like to take a test ride,

Re: debugger, status and suggestions sought

I've issued a pull request [1] with quicktype-generated Debug Adapter Protocol pmod containing domain objects, along with serializing/deserializing subroutines. It leaves a lot to be desired, but it's something we can move the work on for now. One of the problems with this specification is the

Re: debugger, status and suggestions sought

Ah! Right, sorry, my bad, actually the specification is a JSON schema and can be found here: https://github.com/Microsoft/debug-adapter-protocol/blob/gh-pages/debugAdapterProtocol.json śr., 2 sty 2019, 20:23: H. William Welliver III napisał(a): > I started looking at the JSON-RPC code before

Re: debugger, status and suggestions sought

I started looking at the JSON-RPC code before the holidays, I will put what I have in a repository somewhere... it's not a lot of code, as the spec is pretty simple. Note that this won't be helpful for DAP, as it doesn't use JSON-RPC (though LSP does). I think (but am not 100% sure), that the

Re: debugger, status and suggestions sought

I've started a separate thread for QuickType support in Pike. But now I'm thinking perhaps it would be even better to have some kind of TypeScript -> Pike class transformer, since both DAP and LSP JSON-RPC message specifications are in TypeScript. Does anyone know any tools that might be able to

Re: debugger, status and suggestions sought

H. William Welliver III wrote: >By "at runtime" I meant when pike code is compiled, not when the interpreter > is compiled. Presumably this would be an option configurable at runtime. That is what I meant too. >I understand your sentiment in terms of aim, but it's important to remember > that

Re: debugger, status and suggestions sought

Yes, I think that DAP allows us to make the most of limited developer cycles. Also, I started writing domain objects and serialization code for the DAP protocol messages, but after a few hours, it seemed like generating code from the schema specification might be the more useful approach,

Re: debugger, status and suggestions sought

That's convincing. Having a debug adapter would allow to select from multiple debugger clients already available. I'll try and write one according to your suggestions. After your recent updates to the debugger-concept branch I'm no longer able to set a breakpoint. Can you please review the wiki

Re: debugger, status and suggestions sought

By "at runtime" I meant when pike code is compiled, not when the interpreter is compiled. Presumably this would be an option configurable at runtime. I understand your sentiment in terms of aim, but it's important to remember that just about any means of debugging (from printf to a debugger) is

Re: debugger, status and suggestions sought

H. William Welliver III wrote: >- Does optimization hurt the ability to debug? > Breakpoints on constant expressions or on a for loop, as examples, > won???t get hit how you might expect them to. > Is that okay, or should we explore ways to skip optimization at runtime? I personally prefer that

Re: debugger, status and suggestions sought

> On Dec 21, 2018, at 6:35 AM, Henrik Grubbström (Lysator) @ Pike (-) > developers forum <10...@lyskom.lysator.liu.se> wrote: > > Most of the code for handling local variables and their types and names is > located at the end of language.yacc. Of interest are probably the functions >

Re: debugger, status and suggestions sought

I agree that LSP may be a bit off-topic in this discussion, but I think DAP is very much relevant: implementing it, or the relevant portion of it, as the means of communicating with the in-process debug agent gets us a large bit of the way to having support in a range of debugger clients (VS

Re: debugger, status and suggestions sought

Hi. >I think having both LSP > and DAP > implementations for >Pike would be awsome, but I feel that this discussion is getting further >away from it's main point. We've been talking about

Re: debugger, status and suggestions sought

I think having both LSP and DAP implementations for Pike would be awsome, but I feel that this discussion is getting further away from it's main point. We've been talking about LSP for a

Re: debugger, status and suggestions sought

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

Re: debugger, status and suggestions sought

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

Re: debugger, status and suggestions sought

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 wrote: > > GDB or

Re: debugger, status and suggestions sought

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

Re: debugger, status and suggestions sought

GDB or https://microsoft.github.io/debug-adapter-protocol/ Best Regards, Tomasz Jamroszczak

Re: debugger, status and suggestions sought

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