<div dir="ltr">Thanks. I wasn't sure how well C++ overloading works with SWIG, that's definitely a more ergonomic solution.<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 8, 2018 at 1:16 PM, Greg Clayton <span dir="ltr"><<a href="mailto:clayborg@gmail.com" target="_blank">clayborg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><div><div class="h5"><br><blockquote type="cite"><div>On Jun 8, 2018, at 12:54 PM, Leonard Mosescu via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="m_-565193510736933763Apple-interchange-newline"><div><div dir="ltr"><div style="line-height:18px"><div><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><font face="Droid Sans Mono, monospace, monospace, Droid Sans Fallback"><span style="white-space:pre-wrap">What is the governing</span> <span style="white-space:pre-wrap">philosophy around making changes to the SB API? The "</span></font></span><font face="Droid Sans Mono, monospace, monospace, Droid Sans Fallback"><a href="http://lldb.llvm.org/SB-api-coding-rules.html" style="white-space:pre-wrap" target="_blank">SB API Coding Rules</a><span style="white-space:pre-wrap">"</span></font></div><div><font face="Droid Sans Mono, monospace, monospace, Droid Sans Fallback"><span style="white-space:pre-wrap">page establishes the practices on how to avoid introducing accidental incompatibility, but what </span></font></div><div><font face="Droid Sans Mono, monospace, monospace, Droid Sans Fallback"><span style="white-space:pre-wrap">about the cases where there's a case for intentionally making changes?</span></font></div><div><font face="Droid Sans Mono, monospace, monospace, Droid Sans Fallback"><span style="white-space:pre-wrap"><br></span></font></div><div><font face="Droid Sans Mono, monospace, monospace, Droid Sans Fallback"><span style="white-space:pre-wrap">For example, </span></font><span style="font-family:"Droid Sans Mono",monospace,monospace,"Droid Sans Fallback";white-space:pre-wrap">I'd like to make a small change to SBTarget to allow surfacing errors during LoadCore():</span></div><div style="font-family:"Droid Sans Mono",monospace,monospace,"Droid Sans Fallback";white-space:pre-wrap"><span style="font-weight:normal"><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></span></span></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div style="line-height:18px"><div style="font-family:"Droid Sans Mono",monospace,monospace,"Droid Sans Fallback";white-space:pre-wrap"><span style="font-weight:normal"><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">SBProcess </span><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;color:rgb(121,94,38)">SBTarget::LoadCore</span><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">(</span><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;color:rgb(0,0,255)">const</span><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"> </span><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;color:rgb(0,0,255)">char</span><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"> </span><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">*</span><span style="font-size:small;font-weight:400;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">core_file</span><span style="font-size:small;font-weight:400;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">)</span></span></div></div></blockquote><div style="line-height:18px"><div style="font-family:"Droid Sans Mono",monospace,monospace,"Droid Sans Fallback";white-space:pre-wrap"><span style="font-weight:normal"><br></span></div><div style="font-family:"Droid Sans Mono",monospace,monospace,"Droid Sans Fallback";white-space:pre-wrap"><span style="font-weight:normal">And add an explicit out error parameter (in line with SBTarget::Attach(), Launch(), ...):</span></div><div style="font-family:"Droid Sans Mono",monospace,monospace,"Droid Sans Fallback";white-space:pre-wrap"><span style="font-weight:normal"><br class="m_-565193510736933763gmail-Apple-interchange-newline"></span></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div style="line-height:18px"><div style="font-family:"Droid Sans Mono",monospace,monospace,"Droid Sans Fallback";white-space:pre-wrap"><span style="font-weight:normal">SBProcess </span><span style="font-weight:normal;color:rgb(121,94,38)">SBTarget::LoadCore</span><span style="font-weight:normal">(</span><span style="font-weight:normal;color:rgb(0,0,255)">const</span><span style="font-weight:normal"> </span><span style="font-weight:normal;color:rgb(0,0,255)">char</span><span style="font-weight:normal"> </span><span style="font-weight:normal">*</span><span>core_file<b>, SBError </b></span><span><b>&</b></span><span><b>error</b>)</span></div><div style="font-family:"Droid Sans Mono",monospace,monospace,"Droid Sans Fallback";white-space:pre-wrap"><span><br></span></div></div></blockquote><font face="Droid Sans Mono, monospace, monospace, Droid Sans Fallback"><span style="white-space:pre-wrap">If the rule is to strictly avoid any kind of changes then I'd have to resort to</span></font><div><font face="Droid Sans Mono, monospace, monospace, Droid Sans Fallback"><span style="white-space:pre-wrap">a COM-like versioning and introduce a new SBTarget::LoadCore2 (or LoadCoreEx, ... pick</span></font></div><div><font face="Droid Sans Mono, monospace, monospace, Droid Sans Fallback"><span style="white-space:pre-wrap">your poison, I'm not set on any name) while also keeping the existing LoadCore().</span></font></div><div><font face="Droid Sans Mono, monospace, monospace, Droid Sans Fallback"><span style="white-space:pre-wrap"><br></span></font></div><div><font face="Droid Sans Mono, monospace, monospace, Droid Sans Fallback"><span style="white-space:pre-wrap">Any guidance on this? Thanks!</span></font><br><div><font face="Droid Sans Mono, monospace, monospace, Droid Sans Fallback"><span style="white-space:pre-wrap"><br></span></font></div></div></div></div></blockquote><div><br></div></div></div>Just add an extra overloaded version of LoadCore. We don't want people's code to not link and since Apple uses a LLDBRPC.framework that sub-launches a lldb-rpc-server which can connect to older LLDB.framework binaries, we can't remove functions.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Greg</div></font></span><span class=""><div><br><blockquote type="cite"><div><div dir="ltr"><div><div><br></div></div></div>
______________________________<wbr>_________________<br>lldb-dev mailing list<br><a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/lldb-dev</a><br></div></blockquote></div><br></span></div></blockquote></div><br></div>