<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I don’t think so, this was just an embedded link to your hard drive:<div class=""><br class=""></div><div class=""><a href="file:///C:/tools/swigwin-3.0.7/Doc/Manual/Python.html#Python_builtin_types" class="">file:///C:/tools/swigwin-3.0.7/Doc/Manual/Python.html#Python_builtin_types</a></div><div class=""><br class=""></div><div class="">Sean</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 19, 2015, at 10:51 AM, Zachary Turner via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Nov 19, 2015 at 10:50 AM Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class="">Well some of the bugfixes are actually worth mentioning, because we actually have bugs on the C++ side that we can't fix because then SWIG won't be able to process the header files. For example, if SWIG sees this in a header file, it errors out and can't even proceed.<div class=""><br class=""></div><div class="">enum Foo : unsigned {</div><div class=""> <span class="Apple-converted-space"> </span>Bar = 0xFFFFFFFF</div><div class="">};</div><div class=""><br class=""></div><div class="">So instead we have to write this:</div><div class=""><br class=""></div><div class="">enum Foo {</div><div class=""> <span class="Apple-converted-space"> </span>Bar = 0xFFFFFFFF</div><div class="">};</div><div class=""><br class=""></div>According to the standard this produces an unsigned enum, but MSVC is non-comformant here, and we get a signed enum. So we have hundreds of warnings disabled as a result of this, and it's a legitimate bug on the C++ side that we would like to fix, irrespective of SWIG.<div class=""><br class=""></div><div class="">Feature-wise, here's a potentially incomplete list:</div><div class=""><br class=""></div><div class="">* Typemaps can re-use other typemaps, similar to how functions can call other functions</div><div class="">* A new -debug-tmsearch command line option which helps debugging typemap problems. For example, when you're looking at some generated code and trying to figure out which typemap generated it. I know I've had to do this many times during the Python 3 conversion, and this would have helped.</div><div class="">* Template classes are supported. We probably don't care about this, but it's an interesting thought.</div><div class="">* -builtin option supports generating higher performance wrapping code. Read the<span class="Apple-converted-space"> </span><a class="">SWIG documentation about -builtin</a></div></div></blockquote><div class="">Grr, do embedded links not work on the mailing list or something?</div><div class=""><br class=""></div><div class=""><a href="http://www.swig.org/Doc3.0/Python.html#Python_builtin_types" class="">http://www.swig.org/Doc3.0/Python.html#Python_builtin_types</a><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><div class=""><br class=""></div><div class="">JavaScript support has been mentioned as someone someone needs on more than one occasion. The name of the person interested escapes me, but this wasn't added until SWIG 3.x. Other languages like Go and Lua aren't in 1.x of SWIG either, I don't believe.</div><div class=""><br class=""></div><div class="">I'll try to think of some more.</div></div><div dir="ltr" class=""><div class=""><br class=""><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Nov 19, 2015 at 10:17 AM Todd Fiala <<a href="mailto:todd.fiala@gmail.com" target="_blank" class="">todd.fiala@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class="">I'm out next week, but I can help if needed after that.<div class=""><br class=""></div><div class="">Related to all this, you have mentioned a few times that there are newer swig features you want to use.</div><div class=""><br class=""></div><div class="">Can you enumerate the features not present in 1.x but present in 3.x that you want to take advantage of, and what benefits they will bring us? (I'm not referring to bug fixes in bindings, but actual features that bring something new that we didn't have before).</div><div class=""><br class=""></div><div class="">Thanks!</div><div class=""><br class=""></div><div class="">-Todd</div></div><div class="gmail_extra"></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Nov 19, 2015 at 10:14 AM, Zachary Turner<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:zturner@google.com" target="_blank" class="">zturner@google.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class="">I wasn't planning on working on this immediately, but given the outcome of the recent static bindings work, I can re-prioritize. I don't know how long it will take, because honestly writing this kind of thing in Python is new to me.. to make an understatement. But I'll get it done. Give me until mid next week and I'll post an update.</div><div class=""><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Nov 19, 2015 at 10:12 AM Todd Fiala <<a href="mailto:todd.fiala@gmail.com" target="_blank" class="">todd.fiala@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 19, 2015 at 9:44 AM, Zachary Turner<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:zturner@google.com" target="_blank" class="">zturner@google.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class="">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. <div class=""><br class=""></div><div class="">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.<div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">That seems fine.</div></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><div class=""><div class=""></div><div class="">And, as you said, the option can be provided to change the host that the service runs on, so someone could run one internally.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">That also seems fine. And yes, we can work it out on our end.</div><div class=""><br class=""></div><div class="">We'd need to make sure that developer flows would pick up the need to generate the bindings again if binding surface area changed, but that is no different than now.</div></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><div class=""><div class=""></div><div class="">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)</div></div></div><div class=""><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Yep, sounds right.</div></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class=""><div class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Nov 19, 2015 at 8:00 AM Todd Fiala <<a href="mailto:todd.fiala@gmail.com" target="_blank" class="">todd.fiala@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class="">For the benefit of continuity in conversation, here is what you had to say about it before:<div class=""><br class=""></div><div class=""><pre style="white-space: pre-wrap;" class="">> One possibility (which I mentioned to you offline, but I'll put it here for
others to see) is that we make a swig bot which is hosted in the cloud much
like our public build bots. We provide a Python script that can be run on
your machine, which sends requests over to the swig bot to run swig and
send back the results. Availability of the service would be governed by
the SLA of Google Compute Engine, viewable here:
<a href="https://cloud.google.com/compute/sla?hl=en" target="_blank" class="">https://cloud.google.com/compute/sla?hl=en</a>
> If we do something like this, it would allow us to raise the SWIG version
in the upstream, and at that point I can see some benefit in checking the
bindings in. Short of that, I still dont' see the value proposition in
checking bindings in to the repo. [bits deleted]
> If it means we can get off of SWIG 1.x in the upstream, I will do the work
to make remote swig generation service and get it up and running.</pre><pre style="white-space: pre-wrap;" class=""><br class=""></pre><pre style="white-space: pre-wrap;" class="">I'd like feedback from others on this. Is this something we want to consider doing?</pre><pre style="white-space: pre-wrap;" class="">From my perspective, this seems reasonable to look into doing if we:</pre><pre style="white-space: pre-wrap;" class="">(a) have the service code available, and</pre><pre style="white-space: pre-wrap;" class="">(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</pre><pre style="white-space: pre-wrap;" class="">(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</pre><pre style="white-space: pre-wrap;" class="">(c: option 2) <span style="font-family: arial, sans-serif;" class="">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></pre><pre style="white-space: pre-wrap;" class="">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."</pre><pre style="white-space: pre-wrap;" class=""><br class=""></pre><pre style="white-space: pre-wrap;" class="">Reasoning:</pre><pre style="white-space: pre-wrap;" class="">For (a): just so we all know what we're using.</pre><pre style="white-space: pre-wrap;" class="">For (b): I can envision production build flows that will not want to be hitting a third-party server. We shouldn't require that. </pre><pre style="white-space: pre-wrap;" class="">For (c): we don't want to prevent building in scenarios that can't hit a network during the build.</pre><pre style="white-space: pre-wrap;" class=""><br class=""></pre><pre style="white-space: pre-wrap;" class="">-Todd</pre></div></div><div class="gmail_extra"></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Nov 18, 2015 at 10:58 PM, Todd Fiala<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:todd.fiala@gmail.com" target="_blank" class="">todd.fiala@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote"><span class="">On Wed, Nov 18, 2015 at 10:06 PM, Todd Fiala<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:todd.fiala@gmail.com" target="_blank" class="">todd.fiala@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class="">Hey Zachary,<div class=""><br class=""></div><div class=""><div class="">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.</div><div class=""><br class=""></div><div class="">Regarding the bindings as service idea:</div></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div></span><div class="">Hey I got these, Zachary. They just didn't go in my inbox.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><div class=""></div><div class="">Thanks!</div><span class=""><font color="#888888" class=""><span class=""><font color="#888888" class=""><div class="">-- <br class=""></div><div class=""><div class=""><div dir="ltr" class="">-Todd</div></div></div></font></span></font></span></div><span class=""><font color="#888888" class=""></font></span></blockquote></div><span class=""><font color="#888888" class=""><br class=""><br clear="all" class=""><div class=""><br class=""></div>--<span class="Apple-converted-space"> </span><br class=""><div class=""><div dir="ltr" class="">-Todd</div></div></font></span></div></div></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div></div><div class="gmail_extra">--<span class="Apple-converted-space"> </span><br class=""><div class=""><div dir="ltr" class="">-Todd</div></div></div></blockquote></div></div></div></blockquote></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><br class=""><br clear="all" class=""><div class=""><br class=""></div>--<span class="Apple-converted-space"> </span><br class=""><div class=""><div dir="ltr" class="">-Todd</div></div></div></div></blockquote></div></div></div></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div></div><div class="gmail_extra">--<span class="Apple-converted-space"> </span><br class=""><div class=""><div dir="ltr" class="">-Todd</div></div></div></blockquote></div></div></div></div></blockquote></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">lldb-dev mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a></span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a></span></div></blockquote></div><br class=""></div></body></html>