Re: BREAKing into Euphoria
- Posted by ghaberek (admin) Feb 28, 2022
- 1256 views
"I've (you've) implemented"???
LOL well I meant, you designed it and I implemented it. If we release with this feature you'll surely be credited for the contribution.
Did you already implement this, and has it made it to github since that would save me time?
No not yet, but it's a relatively small change so if I can determine it's safe to use then I can push the change to the repo soon.
If you implement it in the backend, then there's no need to add a debug API for it.
For this? No. You're right that there's no need to have an external debugger trigger the internal trace screen; it should implement its own trace-like interface.
I find this backend method useful for libraries; often you don't want to pop out to the debugger in the library (which has been tested to work) - the problem is with the userapp (same for type checks). What you want is to pop up the debugger in the user's code ("with trace" section), and keep the library / type check "without trace". This reflects an elegance of euphoria; that the user has control of the scope of debuggability, only now it can be queued in "without trace" sections.
Right, and that got me thinking about complex with/without trace scenarios. I made a small addition to the changes I listed above in parser.e to help with this.
I've been having some thoughts about the debugger API;
FYI Matt wrote the external debugger API for Euphoria 4.1 several years ago. I think I've got a pretty good handle on how it works and I'd very much like to improve on it.
- Does it extend euphoria's internal debugger functionality or does the API replace that functionality? Obviously very unattractive and wasteful to recreate the existing debugger's functionality.
I think the best answer is "both?" What the external debugger API does is allow you to add hooks into some existing functions that already exist in the backend. For example, when the backend encounters a trace op, it calls DebugScreen() to flip over to the trace screen you see now. You can implement your own DebugScreen() to be called instead, and that can be whatever you want. From there, you can query the symbol table and the call stack, etc. You can also inject trace statements to act as break points. I'm hoping to use this to implement full-on external debugging in my vscode-extension extension.
- My pet annoyance is the debugger's ignorance of string sequences and thumping them out as interspersed numbers. Naturally we don't want to explicity run-time mark sequences as 'strings'. But we could modify the interpreter to assign some pointer part of the string to a string memory address range, and have an API to query the string-edness of a sequence.
Well, this is its own problem altogether and not specific to the trace screen. Your ex.err dumps are going to be full of non-string sequences as well. I know in Phix, Pete has implemented strings as their own dedicated type. I think that would be more complicated with Euphoria but I'm exploring options of expanding the type system to be a little "smarter" than it is today. In the meantime, I'm hoping to at least improve the "pretty print" functionality that's used in trace and ex.err to prefer string-like output, and possibly have a way to disable this. (Something like without pretty_errors)
- Irrespective of above implicit string marking, a 's' command to print out a sequence as a string ???
That's a good idea. I'll look into that along with your 'p' suggestion below.
(Long thread; replies continued below.)
-Greg
