JDevlieghere added a comment.

In D58564#1410213 <https://reviews.llvm.org/D58564#1410213>, @labath wrote:

> I am sorry that I won't have much time to review this in the next couple of 
> weeks, but I don't think this is a good direction here. I don't see how this 
> will interact with the SB API recorder, specifically with things like 
> SBCommandInterpreter::HandleCommand, and ::HandleCommandsFromFile. The thing 
> I would expect to see is that SB recorder captures the input of those 
> commands (for a somewhat broad interpretation of "capture") during recording, 
> and then substitute this during replay. That way the CommandInterpreter class 
> would not need (almost?) any modifications.


It’s been a while but wasn’t this exactly what you proposed in the other 
differential? How would you capture commands that are entered interactively 
(through RunCommqndInterpreter)?

Anyway, I don’t believe this is a concern. The provider here only capture 
what’s entered interactively, hence the flag. Replaying the API call should 
work exactly as expected. I’ll double check later today.

> With this approach (shoving all commands into a single stream in the 
> CommandInterpreter) it becomes impossible to replay the API calls above. If 
> you want to proceed with this, then go ahead (it's your feature), but I 
> believe you'll run into some problems down the line.




CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58564/new/

https://reviews.llvm.org/D58564



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to