In the script you posted I noticed you called
$arg0.Len(). Does this mean the debugger can call member functions? That would be a great help when generalizing/porting scripts to multiple implementations (such as different standard libraries, or different versions of libraries with the same interface but different implementation), as long as variables of that type can be completely described by calls to member functions (which is true for a lot of types).
It looks like it gives a query to run and defines a function to parse the output. Would it not be simpler (and possibly more powerful) if the script could ask the debugger driver to run certain queries? That way you can run multiple queries and the script logic can even dynamically adjust which ones and/or how many times. It also allows for more abstraction from the actual queries, which might allow the same scripts to be used by both GDB and CDB.
(I 'm gonna use gdb examples here)
Before evaluating a variable, the driver runs a "whatis <var>" which gives the variable's type. This is then checked for matches by any script-registered type using the script-supplied regular expression.
If a script that matches is found, the previously defined "print_<typename>" gdb function is called. That would be "print_wxstring" in the above code case.
When we receive output from this command, the script's parse function (GDB_ParseWXString in the code above) is called.
Does this mean these things would have to be rewritten for each debugger? Is there maybe a way to abstract this a bit more, even if it's just the most basic functionality?
If the output needs to be in the same representation as a debugger output command, maybe the script should have access to some helper functions that produce the output in a more high-level way. This would not only be helpful in providing a more understandable way to create the output, but also allows for more uniform access to output formats for different debuggers.
This would basically entail some helper functions and/or classes. (Does AngelScript even have classes?)
The second argument will be filled with the result in a format similar to gdb's "output" command (the watches parsing works with this). So it will always be a string. I can elaborate on the format if you want it...
Hmm... I don't know much about gdb, but does this mean you could already write such a generic vector parsing script that would be parsed by C::B into a tree representation? (taking into account the scripts for the element type etc.)
The first argument that is passed to the script is more interesting though. It contains the driver's output of the previously run command (print_wxstring in this case).
Depending on print_wxstring's definition, this string might be multiline but it doesn't matter. The parser function (GDB_ParseWXString) should parse it correctly and put the parsing result in the second function argument we talked about earlier.
But some types may not be easy to print in one command, especially for people who've never used gdb directly (like me). I'm especially thinking about containers here.
Here a few parsing helper functions/classes would probably also be helpful. (Presumably, different debuggers write out different formats)
All the above mean that you can parse practically whatever. If you want, I can post an example for parsing a std::vector. It's perfectly possible with this setup.
I guess that already answers one of my questions. As often noted on these forums, you guys are
fast :lol:.
Seriously, that would probably be quite instructional, especially with extensive comments that explain everything.
Finally, I haven't settled with this design yet. I 'm still evaluating it...
Thanks for the feedback though 
I presumed you hadn't settled on it yet. Actually, that's
why I gave the feedback. I just wanted to make sure this would work for more complex structures that are best presented as multiple values. Best to do so before anything is settled on, right?
