OpenEuphoria

Re: BREAKing into Euphoria

• Posted by abuaf Feb 27, 2022
• 1291 views

"I've (you've) implemented"??? Did you already implement this, and has it made it to github since that would save me time? If you implement it in the backend, then there's no need to add a debug API for it. 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 user app (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.

I've been having some thoughts about the debugger API;

• 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.
• 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.
• Irrespective of above implicit string marking, a 's' command to print out a sequence as a string ???
• Quick hack; a 'string' type check, that not only checks that all sequence elements are integers [0..255] , but makes a simplified CRC of the sequence and stores that for later so the debugger can match against it and print appropriately. The aim here is to fingerprint strings on assignment. Maybe there's a faster backend method to finger print sequences based on their internal pointers.
• The string printing issue is part of a bigger issue on sequence printing in general. In the end only the eu app can pretty print a complex sequence according to appropriate user preference. Ie you dont want a detailed page long full dump of a complex sequence. So i would suggest a eu callback (in "without trace" code to prevent recursion) that would take a sequence as input, and return a string for the debugger to print. This would apply to the new debugger 's' command, so if the user really wants a full dump, use the usual '?' command.
• Just to save keystrokes, and do as gdb does, dont use ? but 'p' to print a var.
• Finally as an alternative to slow type check fingerprinting on var write, instead a debugger output reprint callback. Eg on app init, a table of special var names is created. Debugger adds variables to debug display. Then it makes the 'reprint' callback, which takes as arg a string of the debug display area. Then the callback can consult the special var name list and rewrite values of matching variables, and return that. Finally the debugger displays what is returned. I think this is the least obtrusive, easiest way, without adding any significant runtime changes, and without resorting to a new debugger. How to support debug printing of seq[4] ? We first let the debugger accept the array subscript as part of the variable name to print. No value is printed because the debugger is too dumb to do that. Instead the reprint callback handle this complexity, even accepting a variable as a sequence subscript rather than going full parser. All this is in the name of keeping the runtime lean (small) and mean (fast). Even the few KB of this reprint euphoria can can be cancelled with a ifdef .

Any better ideas? In the end i believe the debugger should get relatively small attention since its not the main operation of euphoria (an interpreter/translater). Like most users (maintainers?) my objective is not to spend years supporting a hobby horse, i just want to get some well defined programs done. I'm willing to spend a bit of time to make that done more comfortably. Too utilitarian? Each to his own.