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

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 < ravithejaw...@gmail.com> wrote: > Hello, > > Yeah you are right Mikhail, thanks for pointing it out, I > must

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

Usage of static bindings for the prepare_bindings.py script went in here: r253448. Only Xcode provides the flag to use it. The commit description indicates how it works in this incarnation. Essentially it only uses the static Python binding if and only if a swig isn't specified or cannot be foun

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

On Tue, Nov 17, 2015 at 8:03 PM Todd Fiala wrote: > Nothing concrete at the moment; however, it could be interesting to look > at the clang community and see what could be done for llvm-based language > implementations. The angle that I think would be interesting would be if > we can generate bi

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

On 18 November 2015 at 09:02, Zachary Turner via lldb-dev wrote: > On Tue, Nov 17, 2015 at 8:03 PM Todd Fiala wrote: >> >> Nothing concrete at the moment; however, it could be interesting to look >> at the clang community and see what could be done for llvm-based language >> implementations. The

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

Checking in the static bindings is no different than projects checking in autoconf config baked scripts so that the vast majority of people don't need to run autoconf just to get a setup that rarely changes. There is precedent for this going back a long way on open source projects. I'm backing of

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

> On OS X, it is a pain to get unless you install homebrew/macports/fink. On Linux, you'll need to do an apt-get or yum install. And I should add that installing home-brew (the most common way of picking up extra goodies, as I know I do it on home machines) is also one of the most common ways to p

[lldb-dev] keep an eye out for broken lldb bindings

Hi all, I've cleaned up our swig generation scripts as used by cmake and Xcode builds. They're working fine on Xcode, but I've only checked them on Ubuntu 14.04 as far as cmake builds go. The change to switch over to the cleaned-up script happened here: r253478 Probably the biggest place somet

Re: [lldb-dev] keep an eye out for broken lldb bindings

FYI - This switchover change looks like it made it through the Ubuntu and Windows builders. On Wed, Nov 18, 2015 at 10:21 AM, Todd Fiala wrote: > Hi all, > > I've cleaned up our swig generation scripts as used by cmake and Xcode > builds. They're working fine on Xcode, but I've only checked the

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

On Wed, Nov 18, 2015 at 10:00 AM Todd Fiala wrote: > Checking in the static bindings is no different than projects checking in > autoconf config baked scripts so that the vast majority of people don't > need to run autoconf just to get a setup that rarely changes. There is > precedent for this g

Re: [lldb-dev] keep an eye out for broken lldb bindings

BTW this change only affected the swig wrapper generation. There's a separate "finish" script that I have not yet touched nor have I adopted on Xcode. I'll look at that as some near-term clean-up, I'd like to get Xcode using what everyone else is using there. -Todd On Wed, Nov 18, 2015 at 10:32

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

On Wed, Nov 18, 2015 at 10:34 AM, Zachary Turner wrote: > > > On Wed, Nov 18, 2015 at 10:00 AM Todd Fiala wrote: > >> Checking in the static bindings is no different than projects checking in >> autoconf config baked scripts so that the vast majority of people don't >> need to run autoconf just

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

> On Nov 18, 2015, at 10:34 AM, Zachary Turner via lldb-dev > wrote: > > > > On Wed, Nov 18, 2015 at 10:00 AM Todd Fiala > wrote: > Checking in the static bindings is no different than projects checking in > autoconf config baked scripts so that the vast majorit

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

On Wed, Nov 18, 2015 at 11:15 AM Todd Fiala wrote: > > My intent here is to only provide the --allow-static-binding option on > cmake if it is explicitly turned on. And it will be off by default. > I know, but I don't really like adding options that nobody is going to use, because it makes maint

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

On Wed, Nov 18, 2015 at 11:15 AM Todd Fiala wrote: > On Wed, Nov 18, 2015 at 10:34 AM, Zachary Turner > wrote: > >> Because even if it isn't perfect for everyone, it works for everyone. >> > > Unless you can't get swig on your system in a way that doesn't break other > items. And then it does

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

(This is originally from a thread on lldb-commits, but it seems more appropriate here, so I'm responding here. On Wed, Nov 18, 2015 at 12:47 PM Todd Fiala wrote: > BTW if you cook up something on the swig-as-a-service end that ends up > working to eliminate the need for swig, I'll be happy to re

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

On Wed, Nov 18, 2015 at 12:45 PM, Zachary Turner wrote: > > > On Wed, Nov 18, 2015 at 11:15 AM Todd Fiala wrote: > >> On Wed, Nov 18, 2015 at 10:34 AM, Zachary Turner >> wrote: >> >>> Because even if it isn't perfect for everyone, it works for everyone. >>> >> >> Unless you can't get swig on

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

On Wed, Nov 18, 2015 at 12:53 PM, Todd Fiala wrote: > > > On Wed, Nov 18, 2015 at 12:45 PM, Zachary Turner > wrote: > >> >> >> On Wed, Nov 18, 2015 at 11:15 AM Todd Fiala wrote: >> >>> On Wed, Nov 18, 2015 at 10:34 AM, Zachary Turner >>> wrote: >>> Because even if it isn't perfect for e

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

On Wed, Nov 18, 2015 at 12:51 PM, Zachary Turner wrote: > (This is originally from a thread on lldb-commits, but it seems more > appropriate here, so I'm responding here. > > On Wed, Nov 18, 2015 at 12:47 PM Todd Fiala wrote: > >> BTW if you cook up something on the swig-as-a-service end that en

[lldb-dev] if you look at binding-generation-as-service element...

Hey Zachary, Please make sure to ping Greg Clayton, particularly if it does anything that would make the binding no longer be C-linkage-compatible. He can tell you all the bits we are counting on. I think the keys are: * we don't ever have there be vtables. * we never remove API surface area. *

Re: [lldb-dev] if you look at binding-generation-as-service element...

Can I send you a sample set of bindings generated by 3.x as a fail-fast test? Try them out, see if anything breaks, etc? On Wed, Nov 18, 2015 at 1:07 PM Todd Fiala wrote: > Hey Zachary, > > Please make sure to ping Greg Clayton, particularly if it does anything > that would make the binding no

Re: [lldb-dev] if you look at binding-generation-as-service element...

Sure. On Wed, Nov 18, 2015 at 1:09 PM, Zachary Turner wrote: > Can I send you a sample set of bindings generated by 3.x as a fail-fast > test? Try them out, see if anything breaks, etc? > > On Wed, Nov 18, 2015 at 1:07 PM Todd Fiala wrote: > >> Hey Zachary, >> >> Please make sure to ping Greg

Re: [lldb-dev] if you look at binding-generation-as-service element...

LLDBWrapPython.cpp https://drive.google.com/file/d/0Bzpf8QJC6OGOc0RZNGY1dEhBZzQ/view?usp=sharing> lldb.py https://drive.google.com/file/d/0Bzpf8QJC6OGOaEVaNF9GY0tPXzg/view?usp=sharing> Double check the top of lldb.py to make sure swig_version = (3,0,x) On Wed, Nov 18, 2015 at 1:14 PM Todd Fiala

Re: [lldb-dev] if you look at binding-generation-as-service element...

Err, links aren't showing up for me. Gonna try this again. lldb.py - https://drive.google.com/file/d/0Bzpf8QJC6OGOaEVaNF9GY0tPXzg/view?usp=sharing LLDBWrapPython.cpp- https://drive.google.com/file/d/0Bzpf8QJC6OGOaEVaNF9GY0tPXzg/view?usp=sharing On Wed, Nov 18, 2015 at 1:19 PM Zachary Turn

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

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

[lldb-dev] bindings as service idea

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

Re: [lldb-dev] if you look at binding-generation-as-service element...

Ah good got it. Thanks, somehow didn't see this earlier. Thanks! On Wed, Nov 18, 2015 at 1:27 PM, Zachary Turner wrote: > Google Drive is being bad right now. Hopefully this works better :-/ > > > > On Wed, Nov 18, 2015 at 1:20 PM Zachary Turner wrote: > >> Err, links aren't showing up for m

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