Re: [lldb-dev] bindings as service idea

[Jim Ingham via lldb-dev]

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 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 
> non-issue for standing up a custom server, but the official one should have 
> this taken care of).
>  
> If the only thing we're sending from client -> server is packaged up source 
> code which is already available on the open source repository, and the server 
> doesn't require authentication, is this necessary?
> 
> If so, does this mean everyone needs to generate a cert locally?
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] bindings as service idea

[Todd Fiala via lldb-dev]

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 issue of production build flows not wanting to hit a third
> party server, etc.
>
> 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.
>
>
That seems fine.


> And, as you said, the option can be provided to change the host that the
> service runs on, so someone could run one internally.
>
> 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.
>
>
That also seems fine.  And yes, we can work it out on our end.

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.


> 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)
>
>
Yep, sounds right.


> On Thu, Nov 19, 2015 at 8:00 AM Todd Fiala  wrote:
>
>> 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 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:https://cloud.google.com/compute/sla?hl=en
>>
>> > 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.
>>
>>
>> I'd like feedback from others on this.  Is this something we want to 
>> consider doing?
>>
>> From my perspective, this seems reasonable to look into doing if we:
>>
>> (a) have the service code available, and
>>
>> (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
>>
>> (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
>>
>> (c: option 2) 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.
>>
>> 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."
>>
>>
>> Reasoning:
>>
>> For (a): just so we all know what we're using.
>>
>> For (b): I can envision production build flows that will not want to be 
>> hitting a third-party server.  We shouldn't require that.
>>
>> For (c): we don't want to prevent building in scenarios that can't hit a 
>> network during the build.
>>
>>
>> -Todd
>>
>>
>> On Wed, Nov 18, 2015 at 10:58 PM, Todd Fiala 
>> wrote:
>>
>>>
>>>
>>> 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

Re: [lldb-dev] bindings as service idea

[Todd Fiala via lldb-dev]

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 non-issue for standing up a custom server, but the
official one should have this taken care of).

* The method behind how/when the service is updated needs to be clear to
everyone.  This is both a transparency item and affects how changes to the
service code get to the online service.

We don't have to work those out immediately, but they are things we need to
consider.

-Todd


On Thu, Nov 19, 2015 at 10:17 AM, Todd Fiala  wrote:

> 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 bring us?  (I'm
> not referring to bug fixes in bindings, but actual features that bring
> something new that we didn't have before).
>
> Thanks!
>
> -Todd
>
> On Thu, Nov 19, 2015 at 10:14 AM, Zachary Turner 
> wrote:
>
>> 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.
>>
>> On Thu, Nov 19, 2015 at 10:12 AM Todd Fiala  wrote:
>>
>>> 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 issue of production build flows not wanting to hit a
 third party server, etc.

 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.


>>> That seems fine.
>>>
>>>
 And, as you said, the option can be provided to change the host that
 the service runs on, so someone could run one internally.

 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.


>>> That also seems fine.  And yes, we can work it out on our end.
>>>
>>> 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.
>>>
>>>
 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)


>>> Yep, sounds right.
>>>
>>>
 On Thu, Nov 19, 2015 at 8:00 AM Todd Fiala 
 wrote:

> 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 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:https://cloud.google.com/compute/sla?hl=en
>
> > If we do something like this, it would allow us to raise the SWIG 
> > version
> in the upstream, and at 

Re: [lldb-dev] bindings as service idea

[Zachary Turner via lldb-dev]

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 errors out and can't even proceed.
>
> enum Foo : unsigned {
> Bar = 0x
> };
>
> So instead we have to write this:
>
> enum Foo {
> Bar = 0x
> };
>
> 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.
>
> Feature-wise, here's a potentially incomplete list:
>
> * Typemaps can re-use other typemaps, similar to how functions can call
> other functions
> * 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.
> * Template classes are supported.  We probably don't care about this, but
> it's an interesting thought.
> * -builtin option supports generating higher performance wrapping code.
> Read the SWIG documentation about -builtin
>
Grr, do embedded links not work on the mailing list or something?

http://www.swig.org/Doc3.0/Python.html#Python_builtin_types


>
> 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.
>
> I'll try to think of some more.
>
>
> On Thu, Nov 19, 2015 at 10:17 AM Todd Fiala  wrote:
>
>> 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 bring us?  (I'm
>> not referring to bug fixes in bindings, but actual features that bring
>> something new that we didn't have before).
>>
>> Thanks!
>>
>> -Todd
>>
>> On Thu, Nov 19, 2015 at 10:14 AM, Zachary Turner 
>> wrote:
>>
>>> 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.
>>>
>>> On Thu, Nov 19, 2015 at 10:12 AM Todd Fiala 
>>> wrote:
>>>
 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 issue of production build flows not wanting to hit 
> a
> third party server, etc.
>
> 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.
>
>
 That seems fine.


> And, as you said, the option can be provided to change the host that
> the service runs on, so someone could run one internally.
>
> 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.
>
>
 That also seems fine.  And yes, we can work it out 

Re: [lldb-dev] bindings as service idea

[Sean Callanan via lldb-dev]

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  > 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 errors out and can't even proceed.
> 
> enum Foo : unsigned {
> Bar = 0x
> };
> 
> So instead we have to write this:
> 
> enum Foo {
> Bar = 0x
> };
> 
> 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.
> 
> Feature-wise, here's a potentially incomplete list:
> 
> * Typemaps can re-use other typemaps, similar to how functions can call other 
> functions
> * 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.
> * Template classes are supported.  We probably don't care about this, but 
> it's an interesting thought.
> * -builtin option supports generating higher performance wrapping code.  Read 
> the SWIG documentation about -builtin <>
> Grr, do embedded links not work on the mailing list or something?
> 
> http://www.swig.org/Doc3.0/Python.html#Python_builtin_types 
> 
>  
> 
> 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.
> 
> I'll try to think of some more.
> 
> 
> On Thu, Nov 19, 2015 at 10:17 AM Todd Fiala  > wrote:
> 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 bring us?  (I'm not 
> referring to bug fixes in bindings, but actual features that bring something 
> new that we didn't have before).
> 
> Thanks!
> 
> -Todd
> 
> On Thu, Nov 19, 2015 at 10:14 AM, Zachary Turner  > wrote:
> 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.
> 
> On Thu, Nov 19, 2015 at 10:12 AM Todd Fiala  > wrote:
> 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 issue of production build flows not wanting to hit a third party 
> server, etc.  
> 
> 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.
> 
> 
> That seems fine.
>  
> And, as you said, the option can be provided to change the host that the 
> service runs on, so someone could run one internally.
> 
> 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 

Re: [lldb-dev] bindings as service idea

[Zachary Turner via lldb-dev]

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 {
Bar = 0x
};

So instead we have to write this:

enum Foo {
Bar = 0x
};

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.

Feature-wise, here's a potentially incomplete list:

* Typemaps can re-use other typemaps, similar to how functions can call
other functions
* 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.
* Template classes are supported.  We probably don't care about this, but
it's an interesting thought.
* -builtin option supports generating higher performance wrapping code.
Read the SWIG documentation about -builtin


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.

I'll try to think of some more.

On Thu, Nov 19, 2015 at 10:17 AM Todd Fiala  wrote:

> 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 bring us?  (I'm
> not referring to bug fixes in bindings, but actual features that bring
> something new that we didn't have before).
>
> Thanks!
>
> -Todd
>
> On Thu, Nov 19, 2015 at 10:14 AM, Zachary Turner 
> wrote:
>
>> 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.
>>
>> On Thu, Nov 19, 2015 at 10:12 AM Todd Fiala  wrote:
>>
>>> 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 issue of production build flows not wanting to hit a
 third party server, etc.

 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.


>>> That seems fine.
>>>
>>>
 And, as you said, the option can be provided to change the host that
 the service runs on, so someone could run one internally.

 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.


>>> That also seems fine.  And yes, we can work it out on our end.
>>>
>>> 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.
>>>
>>>
 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 

Re: [lldb-dev] bindings as service idea

[Zachary Turner via lldb-dev]

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.

On Thu, Nov 19, 2015 at 10:12 AM Todd Fiala  wrote:

> 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 issue of production build flows not wanting to hit a third
>> party server, etc.
>>
>> 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.
>>
>>
> That seems fine.
>
>
>> And, as you said, the option can be provided to change the host that the
>> service runs on, so someone could run one internally.
>>
>> 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.
>>
>>
> That also seems fine.  And yes, we can work it out on our end.
>
> 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.
>
>
>> 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)
>>
>>
> Yep, sounds right.
>
>
>> On Thu, Nov 19, 2015 at 8:00 AM Todd Fiala  wrote:
>>
>>> 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 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:https://cloud.google.com/compute/sla?hl=en
>>>
>>> > 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.
>>>
>>>
>>> I'd like feedback from others on this.  Is this something we want to 
>>> consider doing?
>>>
>>> From my perspective, this seems reasonable to look into doing if we:
>>>
>>> (a) have the service code available, and
>>>
>>> (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
>>>
>>> (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
>>>
>>> (c: option 2) 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.
>>>
>>> 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."
>>>
>>>
>>> Reasoning:
>>>
>>> For (a): just so we all know what we're using.
>>>
>>> For (b): I can envision production build flows that will not want to be 
>>> hitting a third-party server.  We shouldn't require that.
>>>
>>> For (c): we don't want 

Re: [lldb-dev] bindings as service idea

[Zachary Turner via lldb-dev]

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-dev@lists.llvm.org> wrote:
>
>
>
> 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 errors out and can't even proceed.
>>
>> enum Foo : unsigned {
>> Bar = 0x
>> };
>>
>> So instead we have to write this:
>>
>> enum Foo {
>> Bar = 0x
>> };
>>
>> 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.
>>
>> Feature-wise, here's a potentially incomplete list:
>>
>> * Typemaps can re-use other typemaps, similar to how functions can call
>> other functions
>> * 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.
>> * Template classes are supported.  We probably don't care about this, but
>> it's an interesting thought.
>> * -builtin option supports generating higher performance wrapping code.
>> Read the SWIG documentation about -builtin
>>
> Grr, do embedded links not work on the mailing list or something?
>
> http://www.swig.org/Doc3.0/Python.html#Python_builtin_types
>
>
>>
>> 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.
>>
>> I'll try to think of some more.
>>
>>
>> On Thu, Nov 19, 2015 at 10:17 AM Todd Fiala  wrote:
>>
>>> 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 bring us?
>>>  (I'm not referring to bug fixes in bindings, but actual features that
>>> bring something new that we didn't have before).
>>>
>>> Thanks!
>>>
>>> -Todd
>>>
>>> On Thu, Nov 19, 2015 at 10:14 AM, Zachary Turner 
>>> wrote:
>>>
 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.

 On Thu, Nov 19, 2015 at 10:12 AM Todd Fiala 
 wrote:

> 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 issue of production build flows not wanting to 
>> hit a
>> third party server, etc.
>>
>> 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.
>>
>>
> That seems fine.
>
>
>> And, as you said, the option can be provided to change the host that
>> the service runs on, so someone could run one internally.
>>
>> But do note, that if the goal here is to get the SWIG version bumped
>> in 

Re: [lldb-dev] bindings as service idea

[Zachary Turner via lldb-dev]

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.0/CPlusPlus11.html


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 errors out and can't even proceed.
>
> enum Foo : unsigned {
> Bar = 0x
> };
>
> So instead we have to write this:
>
> enum Foo {
> Bar = 0x
> };
>
> 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.
>
> Feature-wise, here's a potentially incomplete list:
>
> * Typemaps can re-use other typemaps, similar to how functions can call
> other functions
> * 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.
> * Template classes are supported.  We probably don't care about this, but
> it's an interesting thought.
> * -builtin option supports generating higher performance wrapping code.
> Read the SWIG documentation about -builtin
>
> 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.
>
> I'll try to think of some more.
>
>
> On Thu, Nov 19, 2015 at 10:17 AM Todd Fiala  wrote:
>
>> 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 bring us?  (I'm
>> not referring to bug fixes in bindings, but actual features that bring
>> something new that we didn't have before).
>>
>> Thanks!
>>
>> -Todd
>>
>> On Thu, Nov 19, 2015 at 10:14 AM, Zachary Turner 
>> wrote:
>>
>>> 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.
>>>
>>> On Thu, Nov 19, 2015 at 10:12 AM Todd Fiala 
>>> wrote:
>>>
 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 issue of production build flows not wanting to hit 
> a
> third party server, etc.
>
> 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.
>
>
 That seems fine.


> And, as you said, the option can be provided to change the host that
> the service runs on, so someone could run one internally.
>
> 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 

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

[Zachary Turner via lldb-dev]

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 won't accept them, since 2.7 is "dead" except for maintenance and
security fixes.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Andre Alefeld via lldb-dev]

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 can be loaded:
test_app

otool -L DARWIN_X64/test_app
DARWIN_X64/test_app:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1225.1.1)
libmyapp.dylib (compatibility version 0.0.0, current version 0.0.0)



lldb -f DARWIN_X64/test_app
(lldb) target create "DARWIN_X64/test_app"
Current executable set to 'DARWIN_X64/test_app' (x86_64).
(lldb) r
Process 32234 launched: '/Users/xxx/yyy/zzz/source/DARWIN_X64/test_app'
(x86_64)
dyld: Library not loaded: libmyapp.dylib
  Referenced from: /Users/xxx/yyy/zzz/source/DARWIN_X64/test_app
  Reason: image not found
Process 32234 stopped
* thread #1: tid = 0x85c524, 0x7fff5fc01075 dyld`dyld_fatal_error +
1, stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
frame #0: 0x7fff5fc01075 dyld`dyld_fatal_error + 1
dyld`dyld_fatal_error:
->  0x7fff5fc01075 <+1>: nop   

dyld`dyldbootstrap::start:
0x7fff5fc01076 <+0>: pushq  %rbp
0x7fff5fc01077 <+1>: movq   %rsp, %rbp
0x7fff5fc0107a <+4>: pushq  %r15


how can I achieve that the shared lib is used in the debugger correctly,
do I have to set some additional environment variables. Is there a
special r (process launch) syntax that I need to use ?

in gdb it used to work like a charm...

thanks for any help you can deliver in advance,

Andre


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] bindings as service idea

[Todd Fiala via lldb-dev]

>> 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 Google).  It is true that a die-hard self OS builder can
totally build their own trusted set of roots, but that's going beyond.  (It
is possible to buy/procure very cheap certificates that come from
Certificate Authorities that are generally not popular or well known enough
to be in the stock set of Microsoft/OS X/Ubuntu trusted roots, but this is
totally avoidable.)



On Thu, Nov 19, 2015 at 11:48 AM, Jim Ingham  wrote:

> 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 <
> lldb-dev@lists.llvm.org> wrote:
> >
> >
> >
> > 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 to make sure we can have a secure connection.
> (This will be a non-issue for standing up a custom server, but the official
> one should have this taken care of).
> >
> > If the only thing we're sending from client -> server is packaged up
> source code which is already available on the open source repository, and
> the server doesn't require authentication, is this necessary?
> >
> > If so, does this mean everyone needs to generate a cert locally?
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>


-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] bindings as service idea

[Ted Woodward via lldb-dev]

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 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

 

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.  

 

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.

 

And, as you said, the option can be provided to change the host that the 
service runs on, so someone could run one internally.

 

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.

 

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)

 

On Thu, Nov 19, 2015 at 8:00 AM Todd Fiala  > wrote:

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 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:
https://cloud.google.com/compute/sla?hl=en
 
> 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.
 
I'd like feedback from others on this.  Is this something we want to consider 
doing?
>From my perspective, this seems reasonable to look into doing if we:
(a) have the service code available, and
(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
(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
(c: option 2) 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.
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."
 
Reasoning:
For (a): just so we all know what we're using.
For (b): I can envision production build flows that will not want to be hitting 
a third-party server.  We shouldn't require that. 
For (c): we don't want to prevent building in scenarios that can't hit a 
network during the build.
 
-Todd

 

On Wed, Nov 18, 2015 at 10:58 PM, Todd Fiala  > wrote:

 

 

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 

Re: [lldb-dev] bindings as service idea

[Zachary Turner via lldb-dev]

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 actually what I'm proposing.  You only hit the service
when you are editing a swig interface file and you need to generate updated
code.  Otherwise the latest version of the bindings is already checked out
in your repository.

And even then, you only *really* need to hit it when you physically cannot
(for whatever reason) or do not want to install swig on your machine.
There can still be a local path, that says "use the swig installed on my
machine".  Of course, if we're going to standardize on a version, it will
be the version of swig that the service runs.   So whatever version you
have on your machine -- if you intend to check in those bindings -- need to
be the same version used by the service.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] FW: LLDB Windows Python Bindings

[Ted Woodward via lldb-dev]

 

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 lldb-dev
Sent: Thursday, November 19, 2015 12:01 PM
To: Aidan Dodds; LLDB
Subject: Re: [lldb-dev] LLDB Windows Python Bindings

 

+lldb-dev since this could be useful to other people.

 

I'm actively working on getting Python 3.5 support working.  If you want to go 
this route, it will make your life much easier.  But I don't have a fully 
passing test suite yet, there are still about 30 failing tests.  So consider 
Python 3.5 experimental, and at your own risk.  (Patches welcome!)

 

If you want to go with Python 2.7 then the test suite should pass fully, but 
there are 1-2 flaky timeouts that happen occasionally.  But it is a lot more 
work to set up and nobody ever gets it right because it's so complicated.

 

So, for Python 3.5:

1) You must use Visual Studio 2015.  2013 or earlier will not work.

2) Install Python 3.5 from python.org  

3) Run CMake with -DPYTHON_HOME=C:\Python35

4) That's it.  You're done.

 

You don't need to build your own Python 3.5, which it sounds like what you're 
doing.  If you're not trying to build your own Python 3.5, then check to make 
sure your PYTHONPATH is not set to anything.  Mixed environments could be a 
problem.  If that doesn't fix it, then debugging into it a little bit could 
help.  For example, try running C:\Python35\python_d.exe and then typing 
"import _ctypes".  It should work.  If you're doing a release build then try 
making sure that finish_swig is running python.exe, and if you're doing a debug 
build then try making sure that finish_swig is running python_d.exe.  

 

For Python 2.7

1) You must not be using Visual Studio 2015.  Only 2013 will work

2) Can you tell me what command line you're invoking CMake with? 

3) Can you open up build.ninja and search for this line:

 

Custom command for tools\lldb\CMakeFiles\finish_swig

 

And then paste the line under it back into this email?

 

On Thu, Nov 19, 2015 at 8:55 AM Aidan Dodds  > wrote:

Hi Zachary,

I am currently trying to produce a windows build of LLDB that has python
bindings.
There seems to be a lot of discussion on the mailing list regarding
python at the moment.

I couldn't see any documentation or instructions anywhere about how to
produce them.

I have tried with python2.7 and 3.5 varying degrees of success.
While I was able to produce a debug version of the 2.7 interpreter,
CMake seems to be looking for
python27_d+.lib, and I am not sure why the + has been appended.
My build using python 3.5 fails on finish_swig, with: ImportError: No
module named '_ctypes'.

It would be very much appreciated if you could point me to a reference
for building the bindings
on windows or even just give me some direction to the simplest way to
produce them.

Also out of interest what is that state of the lldb test suite on windows?

Thanks,
Aidan

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Greg Clayton via lldb-dev]

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 
>  wrote:
> 
> Hello,
>  Pavel- my question is how do we solve it ? should Mikhail log a bug ? 
> for this issue 
> 
> BR,
> A Ravi Theja
> 
> On Tue, Nov 17, 2015 at 10:42 AM, Ravitheja Addepally 
>  wrote:
> Hello,
> 
> Yeah you are right Mikhail, thanks for pointing it out, I 
> must ask, is there any bug already logged for this issue ?
> 
> Ravi
> 
> 
> On Mon, Nov 16, 2015 at 5:24 PM, Mikhail Filimonov via lldb-dev 
>  wrote:
> Hi guys and thank you for the excellent community project!
> 
>  
> 
> Recently I’ve stumbled on a pesky, but trivial Invalid iterator dereference 
> bug in SymbolContext and TypeMap implementations at revisions
> 
> https://github.com/llvm-mirror/lldb/blob/e528da256d14ecac7df858462b44dca931879509/source/Symbol/SymbolContext.cpp#L823
> 
> and
> 
> https://github.com/llvm-mirror/lldb/blob/5ac1fc5bc961688505334395598a2bb174eabd3b/source/Symbol/TypeMap.cpp#L172
> 
>  
> 
> From the code below it is obvious that TypeMap::ForEach calls the 
> pre-increment operator on m_types iterator right after it has been 
> invalidated by m_types.erase
> 
>  
> 
> SymbolContext::SortTypeList(TypeMap _map, TypeList _list ) const
> 
> {
> 
> TypeMaptoList callbackM2L (type_map, type_list);
> 
> type_map.ForEach(callbackM2L);
> 
> return ;
> 
> }
> 
>  
> 
> void
> 
> TypeMap::ForEach (std::function  const )
> 
> {
> 
> for (auto pos = m_types.begin(), end = m_types.end(); pos != end; ++pos)
> 
> {
> 
> if (!callback(pos->second))
> 
> break;
> 
> }
> 
> }
> 
>  
> 
> bool
> 
> TypeMap::RemoveTypeWithUID (user_id_t uid)
> 
> {
> 
> iterator pos = m_types.find(uid);
> 
>
> 
> if (pos != m_types.end())
> 
> {
> 
> m_types.erase(pos);
> 
> return true;
> 
> }
> 
> return false;
> 
> }
> 
>  
> 
> class TypeMaptoList
> 
> {
> 
> public:
> 
> TypeMaptoList(TypeMap , TypeList ) :
> 
> type_map(typem),type_list(typel)
> 
> {
> 
> }
> 
>  
> 
> bool
> 
> operator() (const lldb::TypeSP& type)
> 
> {
> 
> if(type)
> 
> {
> 
> type_list.Insert(type);
> 
> type_map.RemoveTypeWithUID(type->GetID());
> 
> if (type_map.Empty())
> 
> return false;
> 
> }
> 
> return true;
> 
> }
> 
>  
> 
> private:
> 
> TypeMap _map;
> 
> TypeList _list;
> 
> };
> 
>  
> 
> Regards,
> 
> Mikhail Filimonov
> 
>  
> 
>  
> 
>  
> 
> This email message is for the sole use of the intended recipient(s) and may 
> contain confidential information.  Any unauthorized review, use, disclosure 
> or distribution is prohibited.  If you are not the intended recipient, please 
> contact the sender by reply email and destroy all copies of the original 
> message.
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Todd Fiala via lldb-dev]

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 like to do a complete audit of dotest's command line options, find
> out who's using what, and then potentially delete anything that isn't being
> used.  There's a mess of command line options in use, to the point that
> it's often hard to find free letters to use for new options.
>
> I created this spreadsheet with a complete list of command line options,
> their descriptions, and a place for people to enter what options they're
> using or do not want to be deleted.
>
>
> https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing
>
> If someone has already written YES in the box that indicates they need the
> option, please don't overwrite it.  If you write YES in a box, please
> provide at least a small rationale for why this option is useful to you.
> Feel free to add additional rationale if someone has already added some
> rationale.
>
> I'm going to have a couple days in mid-December and do this cleanup, so
> I'd like to get a solid picture of what options are not needed before
> then.  After people have had some time to look over this, I'll go through
> the results and decide what to do with each one, and then send out another
> email with a proposed action column for each command line option.
>
> Please do take the time to have a look at this, because any option that
> doesn't have a YES in it after a couple of weeks I'm going to assume is a
> candidate for deletion.
>
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>


-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] bindings as service idea

[Zachary Turner via lldb-dev]

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.

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.

And, as you said, the option can be provided to change the host that the
service runs on, so someone could run one internally.

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.

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)

On Thu, Nov 19, 2015 at 8:00 AM Todd Fiala  wrote:

> 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 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:https://cloud.google.com/compute/sla?hl=en
>
> > 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.
>
>
> I'd like feedback from others on this.  Is this something we want to consider 
> doing?
>
> From my perspective, this seems reasonable to look into doing if we:
>
> (a) have the service code available, and
>
> (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
>
> (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
>
> (c: option 2) 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.
>
> 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."
>
>
> Reasoning:
>
> For (a): just so we all know what we're using.
>
> For (b): I can envision production build flows that will not want to be 
> hitting a third-party server.  We shouldn't require that.
>
> For (c): we don't want to prevent building in scenarios that can't hit a 
> network during the build.
>
>
> -Todd
>
>
> On Wed, Nov 18, 2015 at 10:58 PM, Todd Fiala  wrote:
>
>>
>>
>> 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 certainly wait for a solution (using an alternate approach in our
>>> branch) until we arrive at something more palatable to everyone.
>>>
>>> Regarding the bindings as service idea:
>>>
>>> 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