<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 19, 2017 at 11:34 AM Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Sep 19, 2017, at 11:30 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
><br>
><br>
> On Tue, Sep 19, 2017 at 11:27 AM Jim Ingham <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br>
> 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.<br>
><br>
> 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.<br>
><br>
><br>
> Couldn't it just return eCommandFinishedNoResult?  Or a new value, eCommandFinishedPartialResult?<br>
<br>
I don't follow.  How would it know the user asked it to stop?<br><br></blockquote><div><br></div><div>The user already has a way to interrupt a command via DispatchInputInterrupt.  If the command is then interrupted and output is lost as a result, the private api returns the appropriate value, which the user can check for.</div></div></div>