> On Feb 26, 2015, at 6:57 AM, Siva Chandra <sivachan...@google.com> wrote: > > On Wed, Feb 25, 2015 at 6:36 PM, <jing...@apple.com> wrote: >> I haven't used the gdb "explore". It does seem a little odd to me, >> like something that is well modeled by a turn-down GUI variable >> display but not so much by this kind of question & answer session. >> But I haven't used it so I can't say. > > My own point of view: I have hardly ever used an IDE or GUI for dev > work or debugging. Having a CLI for this would likely be of value to > people like me. However, I do agree that if one is using a GUI, this > should not be required. But would that GUI require to understand the > current source language? For example, it should be able to do produce > syntax for field access like a.b->c.d. May be its not an issue.
It is driven by the SBValue system, it's up to that system to produce the notion of "child objects", then the GUI just reflects that. The SBValue system clearly has to understand the source language. You can even ask it "give me the expression that produced this child in the current source language, for instance if you then want to pass that value to an expression for some purpose. But for basic data display the SBValue layout works fine. > >> OTOH, I do have other uses for a slightly more advanced interactive >> IO handler. For instance, it you do "process attach -n" and there are >> multiple processes with the same name, we show you a nice little >> listing of the processes and their arguments so you can figure out >> which PID you actually want to attach to. But it would be nicer to say >> "here are these five processes, type the index of the one you want to >> attach to." > > One could argue that this case can also be handled by a GUI more > effectively? :-) I wouldn't. > >> Maybe you could also have "show me more about process 3" which >> could dump a more verbose output, and then you would decide to >> attach to 3... > > So, do you envision this to happen in a single command "session", or > do you envision something like what Zach talked about: a command > retaining state across sessions. I am not a fan of keeping state > across sessions as managing state between two sessions could get > tricky and IMO not worth it for the command I have in mind. Again, I haven't thought about the best way to implement something like the "explore" command. So I don't have an opinion about how to implement it. In the simple "pick from a list" version of selecting a process, it would also be a one-shot thing so statefulness isn't really relevant. But if you imagine doing something like: (lldb) process attach -n Foo INDEX PID ARGUMENTS 1 111 foo bar 2 222 foo bar bar Select a index to attach to (?<N> for more info) > ?1 <More info on process 1> Select a index to attach to (?<N> for more info) > ?2 <More info on process 2> Select a index to attach to (?<N> for more info) > 2 Attaching to PID 222 (lldb) Then making it a complete session is much more natural than having to come in & out of "process attach". Jim _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
