<div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 14, 2018 at 6:58 PM Jason Molenda <<a href="mailto:jmolenda@apple.com">jmolenda@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>
<br>
> On Aug 14, 2018, at 6:39 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> <br>
> Having bugs also makes the debugger harder to innovate in the future because it’s, not having tests leads to having bugs, and sb api tests leads to not having te<br>
<br>
Yes, lldb does not have these problems -- because we learned from our decades working on gdb, and did not repeat that mistake.  To be honest, lldb is such a young debugger - barely a decade old, depending on how you count it, that ANY testsuite approach would be fine at this point.  Add a couple more decades and we'd be back into the hole that gdb was in.  {I have not worked on gdb in over a decade, so I don't know how their testing methodology may be today}</blockquote><div dir="auto">That doesn’t mean that the current approach is the final word.  As new people come onto the project, new ideas come forth and we should entertain them rather than deciding that all decisions are set in stone forever.</div><div dir="auto"><br></div><div dir="auto">For example, the object model based approach I mentioned earlier would not have any of the problems that you’ve described from gdb.  Just because one set of problems has been solved doesn’t mean we should declare victory and say there’s no point in trying to solve the remaining problems too.  And right now, the problem is that we need to be coming up with a way to make tests easier to write so that people will actually write them</div></div></div>