On Thu, Feb 26, 2015 at 11:21 AM, Greg Clayton <gclay...@apple.com> wrote: > This actually sounds like a great command to add as a python command. > You could add it to the lldb/examples/python directory. I don't think it is > something > we want as a permanent command.
OK, I will go with it. It is infact present as a Python command in GDB as well. However, LLDB has more formalism and better IO handling that I pushed for it to be a builtin command. I am fine with it being a Python command. >> On Feb 26, 2015, at 11:16 AM, Siva Chandra <sivachan...@google.com> wrote: >> >> On Thu, Feb 26, 2015 at 11:06 AM, <jing...@apple.com> wrote: >>> I'd say it another way. Instead of spending the time on this explore >>> command, which requires you to re-do the labor every time you want >>> to inspect data of that type, produce a rough equivalent but whose >>> job is to interactively produce a synthetic child provider for a particular >>> data type. These aren't hard to write, but you have to know Python & >>> the SB API's so there a bit of a barrier to using them. If there was a >>> way to say: if A is 5, then view these three fields, if 6 view these other >>> three, etc, I think that would be pretty neat. >> >> While I personally disagree* with this, I will stop here. >> >> * There are many reasons. One of them is that, one could be dealing >> with moving targets. Hence, moving the data formatter along with the >> targets is double the work. Another reason is, if I were a library >> dev, an "explore" command is provided by my tool chain and can be used >> even before the data formatters are written for my data structures. >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
