IIRC Enrico put in something where we would tell Python to interrupt at points where Python checks for interruptibility, but that is pretty herky-jerky. It would be much better to have the commands control this.
Jim > On Sep 19, 2017, at 11:34 AM, Jim Ingham <jing...@apple.com> wrote: > > >> On Sep 19, 2017, at 11:30 AM, Zachary Turner <ztur...@google.com> wrote: >> >> >> >> On Tue, Sep 19, 2017 at 11:27 AM Jim Ingham <jing...@apple.com> wrote: >> We agreed to forwards compatibility because people write big scripts that >> use the SB API, implement GUI's on top of them (more than just Xcode) etc. >> So we try not to jerk those folks around. That adds a little more >> responsibility on our part to think carefully about what we add, but the >> notion that we should refrain from making useful functionality available >> because we'd rather not be beholden to our decisions seems really >> wrong-headed to me. >> >> And in this case there's a clear use for this. For instance the xnu macros >> have a bunch of Python based commands that spew out pages and pages of >> output. Those guys would love to make their commands interruptible. To do >> that they would need to call WasInterrupted. So this is 100% something that >> should be available at the SB API layer. >> >> >> Couldn't it just return eCommandFinishedNoResult? Or a new value, >> eCommandFinishedPartialResult? > > I don't follow. How would it know the user asked it to stop? > > Jim > > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
