I know you answered this briefly on IRC, but i had to run so I didn't have time to ask for clarification.  What is the benefit of this approach over a stateful command similar to git bisect?  I know you said something about exploring very large types, but I didn't quite follow why this approach lends itself better.<br><br>There are a number of advantages of the stateful approach.  One is that you can run arbitrary commands between stages of the traversal.  Maybe you see a pointer whose value is a module load address , and you want to dump info about the module loaded at that address.  <br><br>It also provides more flexibility even in the exploration process.  If a field is a void* for example, an interactive command might be forced to give up, whereas a stateful non interactive command may be able to be forced into treating it as a specific type through a cast expression.  It seems like the number of times you would know more than the type information lets on might warrant the additional flexibility.<br><br>It might also be difficult to test an interactive command.  Would the command callback into python?  Seems difficult.<br><br>Anyways, these are just ideas.  I do like the general idea of a command that explores type hierarchies this way<br><div class="gmail_quote">On Wed, Feb 25, 2015 at 6:11 PM Siva Chandra <<a href="mailto:sivachandra@google.com">sivachandra@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
This is more like a question through a proposal on how to add<br>
interactive commands to LLDB.<br>
<br>
By an interactive command, I mean that when one runs the command, it<br>
asks for more input from the user. AFAICT, there is no way currently<br>
to do that in LLDB. There is an IOHandlerConfirm which can be used to<br>
get a yes/no response from the user, but what I am looking for is<br>
something which can read in "richer" inputs. Could we extend<br>
IOHandlerConfirm as follows:<br>
<br>
1. Rename IOHandlerConfirm to IOHandlerUserResponse<br>
2. To support the existing use case of "confirm", add two methods,<br>
UserResponseIsYes and UserResponseIsNo to it.<br>
3. Make its GetResponse method return the raw user input.<br>
4. Add few convenience methods to it like GetResponseAsUint8,<br>
GetResponseAsString etc.<br>
<br>
The above is a big picture idea; there could be a few details to<br>
resolve when getting down to implementation. My motivation to require<br>
a facility like this is to implement something like the "explore"<br>
command of GDB:<br>
<a href="https://sourceware.org/gdb/current/onlinedocs/gdb/Data.html" target="_blank">https://sourceware.org/gdb/<u></u>current/onlinedocs/gdb/Data.<u></u>html</a>.<br>
<br>
Thanks,<br>
Siva Chandra<br>
______________________________<u></u>_________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/lldb-dev</a><br>
</blockquote></div>