Re: BREAKing into Euphoria
- Posted by ghaberek (admin) Feb 28, 2022
- 1252 views
- 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 trace screen is pretty dumb in what it knows about types. It might be possible to store some additional information in the symbol table that it could use. I've been thinking about this as part of my ideas for expanding the type system that I mentioned above. But this next feature might be what helps the most:
- 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.
Building on that, I just had an idea: just bake this into the interpreter with something like a "string_routine()" similar to Python's object.__str__() or .NET's Object.ToString(). Basically, any "true" object (atom or sequence) could have a routine attached just like how we're doing delete_routine() today (a pointer/routine_id to a "cleanup" function). The default implementation could just print atoms as "%d" and sequences as {65'A',66'B',...} like it does today. But, and this is where it gets clever: sequences declared with quotes could have a different routine assigned that tries to print the string directly, and it could still fallback to the default function if it encounters non-string data. And, by exposing this to the frontend like delete_routine(), users can implement their own custom handlers. That would be helpful for stuff like memory addresses returned from allocate(), which would be better printed as "0x%08x". I will look into implementing this but it won't be for a while.
- Just to save keystrokes, and do as gdb does, dont use ? but 'p' to print a var.
I think '?' was used originally because it's the built-in "quick print" operator. It's also a query like, "what is this variable?" It's possible to use almost any key for this purpose so we could use both and display "?/p" in the help area instead.
- 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.
I think this part might be best handled by adding the string_routine() I mentioned above.
- 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 .
Allowing to query sequence subscripts would be a nice feature. I'll look into that as well.
Any better ideas?
That's quite a few! This kind of feedback is very good though and I'm happy to try accommodating whatever we can make fit.
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.
I think good debugging tools are essential to a good language and to writing good software. As Brian Kernighan once said:
-Greg
