<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>For our builds at QUIC, we're not interested in hitting an external server to get code. So we'd either hit the server when needed and check in the resultant bindings, or (preferably) use bindings from upstream.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>--<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Qualcomm Innovation Center, Inc.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> lldb-dev [mailto:lldb-dev-bounces@lists.llvm.org] <b>On Behalf Of </b>Zachary Turner via lldb-dev<br><b>Sent:</b> Thursday, November 19, 2015 11:45 AM<br><b>To:</b> Todd Fiala<br><b>Cc:</b> LLDB<br><b>Subject:</b> Re: [lldb-dev] bindings as service idea<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Just to re-iterate, if we use the bindings as a service, then I envision checking the bindings in. This addresses a lot of the potential pitfalls you point out, such as the "oops, you can't hit the network, no build for you" and the issue of production build flows not wanting to hit a third party server, etc. <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>So if we do that, then I don't think falling back to local generation will be an issue (or important) in practice. i.e. it won't matter if you can't hit the network. The reason I say this is that if you can't hit the network you can't check in code either. So, sure, there might be a short window where you can't do a local build , but that would only affect you if you were actively modifying a swig interface file AND you were actively without a network connection. The service claims 99.95% uptime, and it's safe to say we are looking at significantly less than 100% usage of the server (given checked in bindings), so I think we're looking at once a year -- if that -- that anyone anywhere has an issue with being able to access the service.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>And, as you said, the option can be provided to change the host that the service runs on, so someone could run one internally.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>But do note, that if the goal here is to get the SWIG version bumped in the upstream, then we will probably take advantage of some of these new SWIG features, which may not work in earlier versions of SWIG. So you should consider how useful it will be to be able to run this server internally, because if you can't run a new version of swig locally, then can you run it internally anywhere? I don't know, I'll leave that for you to figure out.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Either way, it will definitely have the ability to use a different host, because that's the easiest way to debug theclient and server (i.e. run them on the same machine with 127.0.0.1)<o:p></o:p></p></div></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Thu, Nov 19, 2015 at 8:00 AM Todd Fiala <<a href="mailto:todd.fiala@gmail.com">todd.fiala@gmail.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal>For the benefit of continuity in conversation, here is what you had to say about it before:<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><pre style='white-space:pre-wrap'><span style='color:black'>> One possibility (which I mentioned to you offline, but I'll put it here for<o:p></o:p></span></pre><pre><span style='color:black'>others to see) is that we make a swig bot which is hosted in the cloud much<o:p></o:p></span></pre><pre><span style='color:black'>like our public build bots. We provide a Python script that can be run on<o:p></o:p></span></pre><pre><span style='color:black'>your machine, which sends requests over to the swig bot to run swig and<o:p></o:p></span></pre><pre><span style='color:black'>send back the results. Availability of the service would be governed by<o:p></o:p></span></pre><pre><span style='color:black'>the SLA of Google Compute Engine, viewable here:<o:p></o:p></span></pre><pre><span style='color:black'><a href="https://cloud.google.com/compute/sla?hl=en" target="_blank">https://cloud.google.com/compute/sla?hl=en</a><o:p></o:p></span></pre><pre><span style='color:black'><o:p> </o:p></span></pre><pre><span style='color:black'>> If we do something like this, it would allow us to raise the SWIG version<o:p></o:p></span></pre><pre><span style='color:black'>in the upstream, and at that point I can see some benefit in checking the<o:p></o:p></span></pre><pre><span style='color:black'>bindings in. Short of that, I still dont' see the value proposition in<o:p></o:p></span></pre><pre><span style='color:black'>checking bindings in to the repo. [bits deleted]<o:p></o:p></span></pre><pre><span style='color:black'><o:p> </o:p></span></pre><pre><span style='color:black'>> If it means we can get off of SWIG 1.x in the upstream, I will do the work<o:p></o:p></span></pre><pre><span style='color:black'>to make remote swig generation service and get it up and running.<o:p></o:p></span></pre><pre style='white-space:pre-wrap'><span style='color:black'><o:p> </o:p></span></pre><pre style='white-space:pre-wrap'><span style='color:black'>I'd like feedback from others on this. Is this something we want to consider doing?<o:p></o:p></span></pre><pre style='white-space:pre-wrap'><span style='color:black'>From my perspective, this seems reasonable to look into doing if we:<o:p></o:p></span></pre><pre style='white-space:pre-wrap'><span style='color:black'>(a) have the service code available, and<o:p></o:p></span></pre><pre style='white-space:pre-wrap'><span style='color:black'>(b) if we so choose, we can readily have the script hit another server (so that a consumer can have the entire setup on an internal network), and<o:p></o:p></span></pre><pre style='white-space:pre-wrap'><span style='color:black'>(c: option 1) be able to fall back to generate with swig locally as we do now in the event that we can't hit the server<o:p></o:p></span></pre><pre style='white-space:pre-wrap'><span style='color:black'>(c: option 2) </span><span style='font-family:"Arial",sans-serif;color:black'>rather than fall back to swig generation, use swig generation as primary (as it is now) but, if a swig is not found, then do the get-bindings-as-a-service flow.</span><span style='color:black'><o:p></o:p></span></pre><pre style='white-space:pre-wrap'><span style='color:black'>This does open up multiple ways to do something, but I think we need to avoid a failure mode that says "Oops, you can't hit the network. Sorry, no lldb build for you."<o:p></o:p></span></pre><pre style='white-space:pre-wrap'><span style='color:black'><o:p> </o:p></span></pre><pre style='white-space:pre-wrap'><span style='color:black'>Reasoning:<o:p></o:p></span></pre><pre style='white-space:pre-wrap'><span style='color:black'>For (a): just so we all know what we're using.<o:p></o:p></span></pre><pre style='white-space:pre-wrap'><span style='color:black'>For (b): I can envision production build flows that will not want to be hitting a third-party server. We shouldn't require that. <o:p></o:p></span></pre><pre style='white-space:pre-wrap'><span style='color:black'>For (c): we don't want to prevent building in scenarios that can't hit a network during the build.<o:p></o:p></span></pre><pre style='white-space:pre-wrap'><span style='color:black'><o:p> </o:p></span></pre><pre style='white-space:pre-wrap'><span style='color:black'>-Todd<o:p></o:p></span></pre></div></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Wed, Nov 18, 2015 at 10:58 PM, Todd Fiala <<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Wed, Nov 18, 2015 at 10:06 PM, Todd Fiala <<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal>Hey Zachary,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal>I think the time pressure has gotten the better of me, so I want to apologize for getting snippy about the static bindings of late. I am confident we will get to a good solution for removing that dependency, but I can certainly wait for a solution (using an alternate approach in our branch) until we arrive at something more palatable to everyone.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Regarding the bindings as service idea:<o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>How quickly do you think you could flesh out the bindings as a service idea? With a relatively strong dislike for the static approach I'm taking, I can back off that and just use my current code here in a downstream branch for now. Ultimately I want to remove the requirement for swig, but I can probably achieve that without doing it in upstream if we're going to have some solution there at some point ideally sooner than later.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Also - I think you were going to send me a swig 3.x binding to try out (I'd need the LLDBWrapPythoh.cpp and the lldb.py, and you'd just need to let me know if it still needs to be post-processed or it would need to be done). Can we shoot for trying that out maybe tomorrow?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Hey I got these, Zachary. They just didn't go in my inbox.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal>Thanks!<o:p></o:p></p></div><div><p class=MsoNormal><span style='color:#888888'>-- <o:p></o:p></span></p></div><div><div><div><p class=MsoNormal><span style='color:#888888'>-Todd<o:p></o:p></span></p></div></div></div></div></blockquote></div><p class=MsoNormal><span style='color:#888888'><br><br clear=all><o:p></o:p></span></p><div><p class=MsoNormal><span style='color:#888888'><o:p> </o:p></span></p></div><p class=MsoNormal><span style='color:#888888'>-- <o:p></o:p></span></p><div><div><p class=MsoNormal><span style='color:#888888'>-Todd<o:p></o:p></span></p></div></div></div></div></blockquote></div><p class=MsoNormal><br><br clear=all><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal>-- <o:p></o:p></p><div><div><p class=MsoNormal>-Todd<o:p></o:p></p></div></div></div></blockquote></div></div></body></html>