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

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

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

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 >

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

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 {

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

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

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.

Re: [lldb-dev] FW: LLDB Windows Python Bindings

On Thu, Nov 19, 2015 at 1:39 PM Ted Woodward via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Why can’t we use VS 2015 with Python 2.7? > Python 2.7 literally does not even compile with VS 2015, you would have to fork it and fix the compilation errors. I've tried to upstream fixes and they

[lldb-dev] lldb with app using shared lib not working

Hi, if I try to debug an application from the terminal that is using a shared lib lldb complains always about not finding the library even though everything is loading correctly when starting the app directly from the same terminal: echo $DYLD_LIBRARY_PATH/ running with debugger, shared lib

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

Re: [lldb-dev] bindings as service idea

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. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a

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

[lldb-dev] FW: LLDB Windows Python Bindings

Why can’t we use VS 2015 with Python 2.7? -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, 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

Re: [lldb-dev] Invalid iterator dereference in TypeMap::ForEach when it's invoked with TypeMaptoList callback

I fixed this: % svn commit Sendinginclude/lldb/Symbol/TypeMap.h Sendingsource/Symbol/SymbolContext.cpp Sendingsource/Symbol/TypeMap.cpp Transmitting file data ... Committed revision 253618. > On Nov 18, 2015, at 12:54 AM, Ravitheja Addepally via lldb-dev >

Re: [lldb-dev] Auditing dotest's command line options

We're reviewing these. I've added the ones that I use or need for infrastructure. I've pinged everyone else internally and we'll be sure to update any others over today and tomorrow. -Todd On Wed, Nov 18, 2015 at 2:32 PM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > I would

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