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