Re: [Lldb-commits] [PATCH] D31371: Stop calling ValueObject::SetName from synthetic child providers

[Jim Ingham via lldb-commits]

Thanks.

Jim
> On Mar 30, 2017, at 1:16 PM, Tamas Berghammer  wrote:
> 
> Created bug for exposing ValueObject::Clone as SB API: 
> http://bugs.llvm.org/show_bug.cgi?id=32477
> 
> On Thu, Mar 30, 2017 at 1:04 PM Jim Ingham via Phabricator 
>  wrote:
> jingham accepted this revision.
> jingham added a comment.
> This revision is now accepted and ready to land.
> 
> Good.
> 
> 
> https://reviews.llvm.org/D31371
> 
> 
> 

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

Re: [Lldb-commits] [PATCH] D31371: Stop calling ValueObject::SetName from synthetic child providers

[Tamas Berghammer via lldb-commits]

Created bug for exposing ValueObject::Clone as SB API:
http://bugs.llvm.org/show_bug.cgi?id=32477

On Thu, Mar 30, 2017 at 1:04 PM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:

> jingham accepted this revision.
> jingham added a comment.
> This revision is now accepted and ready to land.
>
> Good.
>
>
> https://reviews.llvm.org/D31371
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D31371: Stop calling ValueObject::SetName from synthetic child providers

[Jim Ingham via lldb-commits]

I see.  Might be worth filing an enhancement request to expose Clone so you can 
do this in a Python synthetic child provider.  But there's no reason that lack 
should block this change.

Jim

> On Mar 30, 2017, at 12:51 PM, Tamas Berghammer  wrote:
> 
> It is possible to vend one of the actual backing object as a synthetic child 
> using the SB API. What is not possible from the SB API at the moment (we 
> might want to fix it) is to vend one of the actual backing object with a 
> different name then the underlying object itself. You can still say that 
> object X has a child named "foobar" (so X.foobar will work) but the name of 
> the actual child will be something like "_M_baz" when displayed.
> 
> On Wed, Mar 29, 2017 at 10:16 AM Jim Ingham  wrote:
> 
> > On Mar 29, 2017, at 2:06 AM, Tamas Berghammer via Phabricator 
> >  wrote:
> >
> > tberghammer added a comment.
> >
> > SBValue::SetName is not part of the SB API (what is the right decision IMO 
> > as an SBValue should be mostly immutable) so this issue doesn't effect it. 
> > I looked through the code in examples/synthetic/gnu_libstdcpp.py and it is 
> > always using one of the SBValue::Create* method to produce new SBValue what 
> > will create a new value object one way or the other. Considering that 
> > nobody complained about the missing SetName method at the SB API level I 
> > don't see a big need for exposing the Clone method there. At the same line 
> > if SetName/Clone isn't part of the SB API then I think we shouldn't 
> > document it at the webpage.
> 
> Seems like vending one of the actual backing objects as a synthetic object is 
> a reasonable thing to do (it's what you are doing internally).  But if we 
> don't allow a way to do that currently, then there's no reason to add one.
> 
> Jim
> 
> 
> >
> > (I will upload a fix for the spelling errors later)
> >
> >
> > https://reviews.llvm.org/D31371
> >
> >
> >
> 

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

Re: [Lldb-commits] [PATCH] D31371: Stop calling ValueObject::SetName from synthetic child providers

[Tamas Berghammer via lldb-commits]

It is possible to vend one of the actual backing object as a synthetic
child using the SB API. What is not possible from the SB API at the moment
(we might want to fix it) is to vend one of the actual backing object with
a different name then the underlying object itself. You can still say that
object X has a child named "foobar" (so X.foobar will work) but the name of
the actual child will be something like "_M_baz" when displayed.

On Wed, Mar 29, 2017 at 10:16 AM Jim Ingham  wrote:

>
> > On Mar 29, 2017, at 2:06 AM, Tamas Berghammer via Phabricator <
> revi...@reviews.llvm.org> wrote:
> >
> > tberghammer added a comment.
> >
> > SBValue::SetName is not part of the SB API (what is the right decision
> IMO as an SBValue should be mostly immutable) so this issue doesn't effect
> it. I looked through the code in examples/synthetic/gnu_libstdcpp.py and it
> is always using one of the SBValue::Create* method to produce new SBValue
> what will create a new value object one way or the other. Considering that
> nobody complained about the missing SetName method at the SB API level I
> don't see a big need for exposing the Clone method there. At the same line
> if SetName/Clone isn't part of the SB API then I think we shouldn't
> document it at the webpage.
>
> Seems like vending one of the actual backing objects as a synthetic object
> is a reasonable thing to do (it's what you are doing internally).  But if
> we don't allow a way to do that currently, then there's no reason to add
> one.
>
> Jim
>
>
> >
> > (I will upload a fix for the spelling errors later)
> >
> >
> > https://reviews.llvm.org/D31371
> >
> >
> >
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D31371: Stop calling ValueObject::SetName from synthetic child providers

[Jim Ingham via lldb-commits]

> On Mar 29, 2017, at 2:06 AM, Tamas Berghammer via Phabricator 
>  wrote:
> 
> tberghammer added a comment.
> 
> SBValue::SetName is not part of the SB API (what is the right decision IMO as 
> an SBValue should be mostly immutable) so this issue doesn't effect it. I 
> looked through the code in examples/synthetic/gnu_libstdcpp.py and it is 
> always using one of the SBValue::Create* method to produce new SBValue what 
> will create a new value object one way or the other. Considering that nobody 
> complained about the missing SetName method at the SB API level I don't see a 
> big need for exposing the Clone method there. At the same line if 
> SetName/Clone isn't part of the SB API then I think we shouldn't document it 
> at the webpage.

Seems like vending one of the actual backing objects as a synthetic object is a 
reasonable thing to do (it's what you are doing internally).  But if we don't 
allow a way to do that currently, then there's no reason to add one.

Jim


> 
> (I will upload a fix for the spelling errors later)
> 
> 
> https://reviews.llvm.org/D31371
> 
> 
> 

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