Re: [lldb-dev] bindings as service idea

On Thu, Nov 19, 2015 at 1:38 PM Ted Woodward wrote: > 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. > Right, and this is actua

Re: [lldb-dev] bindings as service idea

Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary Turner via lldb-dev Sent: Thursday, November 19, 2015 11:45 AM To: Todd Fiala Cc: LLDB Subject: Re: [lldb-dev] bindings as service idea

Re: [lldb-dev] bindings as service idea

>> If so, does this mean everyone needs to generate a cert locally? Generally not - as long as the server is dishing out something over https, the server will be signed with a certificate that is going to be in the local OS's set of trusted root certificates (particularly if this is provided by Go

Re: [lldb-dev] bindings as service idea

The server is sending back code. I'd want to know I can trust whoever is sending me back code that I plan to build and run locally. Jim > On Nov 19, 2015, at 11:40 AM, Zachary Turner via lldb-dev > wrote: > > > > On Thu, Nov 19, 2015 at 10:28 AM Todd Fiala wrote: > Some other points we ne

Re: [lldb-dev] bindings as service idea

On Thu, Nov 19, 2015 at 10:28 AM Todd Fiala wrote: > Some other points we need to consider on the bindings-as-service idea: > > * The service should be exposed via secure connection (https/ssl/etc.) > This might already be guaranteed on the Google end by virtue of the > endpoint, but we'll want

Re: [lldb-dev] bindings as service idea

Derp, I forgot C++11 support. Some of it is not useful to us given the limited nature of the SB API, but certain things could be useful. Being able to transition to enum classes is nice, for example. Anyway, there's a lot here, so feel free to read through the document. http://www.swig.org/Doc3.

Re: [lldb-dev] bindings as service idea

Doh! lol On Thu, Nov 19, 2015 at 10:57 AM Sean Callanan wrote: > I don’t think so, this was just an embedded link to your hard drive: > > file:///C:/tools/swigwin-3.0.7/Doc/Manual/Python.html#Python_builtin_types > > Sean > > On Nov 19, 2015, at 10:51 AM, Zachary Turner via lldb-dev < > lldb-de

Re: [lldb-dev] bindings as service idea

I don’t think so, this was just an embedded link to your hard drive: file:///C:/tools/swigwin-3.0.7/Doc/Manual/Python.html#Python_builtin_types Sean > On Nov 19, 2015, at 10:51 AM, Zachary Turner via lldb-dev > wrote: > > > > On Thu, Nov 19, 2015 at 10:50 AM Zachary Turner

Re: [lldb-dev] bindings as service idea

On Thu, Nov 19, 2015 at 10:50 AM Zachary Turner wrote: > 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

Re: [lldb-dev] bindings as service idea

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. enum Foo : unsigned { Ba

Re: [lldb-dev] bindings as service idea

Some other points we need to consider on the bindings-as-service idea: * The service should be exposed via secure connection (https/ssl/etc.) This might already be guaranteed on the Google end by virtue of the endpoint, but we'll want to make sure we can have a secure connection. (This will be a

Re: [lldb-dev] bindings as service idea

I'm out next week, but I can help if needed after that. Related to all this, you have mentioned a few times that there are newer swig features you want to use. 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 brin

Re: [lldb-dev] bindings as service idea

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

Re: [lldb-dev] bindings as service idea

On Thu, Nov 19, 2015 at 9:44 AM, Zachary Turner wrote: > 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

Re: [lldb-dev] bindings as service idea

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

Re: [lldb-dev] bindings as service idea

For the benefit of continuity in conversation, here is what you had to say about it before: > 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 scr

Re: [lldb-dev] bindings as service idea

On Wed, Nov 18, 2015 at 10:06 PM, Todd Fiala wrote: > Hey Zachary, > > 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 c