sivachandra updated this revision to Diff 37630.
sivachandra added a comment.
Address comments.
http://reviews.llvm.org/D13778
Files:
include/lldb/API/SBValue.h
include/lldb/Core/ValueObject.h
include/lldb/Core/ValueObjectCast.h
include/lldb/Core/ValueObjectChild.h
include/lldb/Core/V
sivachandra added a comment.
When such an error occurs, it is unlikely to be an lldb bug, or data-formatter
bug. One can come up with a data structure for which reading a child element
would require complete debug info, but reading the # of child elements need not
require complete debug info (t
labath added a comment.
How big of an error does it have to be for that to happen? Is that something we
would consider an "lldb bug"/"data formatter bug" or it can be caused by
something out of our control, like missing debug info on one of the children?
http://reviews.llvm.org/D13778
_
sivachandra added a comment.
There could be an error reading the k-th element for k < n.In which case, we
will wrongly conclude that there are only k-1 elements.
http://reviews.llvm.org/D13778
___
lldb-commits mailing list
lldb-commits@lists.llvm.o
labath added a subscriber: labath.
labath added a comment.
Not really my area, but couldn't the needed functionality be implemented on top
of GetChildAtIndex(). I mean, if GetChildAtIndex(50) returns a valid SBValue,
then the container has at least 50 elements, right?
Then `HasAtLeastNChildren(n
clayborg added a comment.
For the public API you will need both and not have a default arg.
http://reviews.llvm.org/D13778
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
sivachandra added a comment.
I did this experiment before setting off:
class A
{
public:
int method();
int method(int a = 10);
};
int
A::method()
{
return 10;
}
int
A::method(int a)
{
return a + 10;
}
int
main()
{
A a;
return a.method
sivachandra added a comment.
Ah, I did not notice PyCallable::GetNumArguments before you drew my attention
to it. It seems to be using internals of PyCodeObject. When I said "no
easy/clean way", I was talking about avoiding such a usage. If that is
acceptable, I am fine with it. I will modify t
granata.enrico added a comment.
One alternative would be to have the num_children method on the synthetic
provider itself be able to take an optional argument that is the max_count.
That is, instead of defining
def num_children(self):
..
You would instead define
def num_children(self,
sivachandra added a comment.
I did consider the option of adding a new method GetNumChildren (uint32_t max =
UINT32_MAX). This if fine from SBValue point of view. But from a the scripted
synthetic provider point of view, I am not sure there is an easy/clean way of
checking whether the num_child
clayborg added a comment.
I would almost rather change the GetNumChildren() to take a "max" param:
class SBValue
{
uint32_t
GetNumChildren ();
uint32_t
GetNumChildren (uint32_t max = UINT32_MAX);
};
We need to keep the other one so that our public API still has
On Thu, Oct 15, 2015 at 11:59 AM, Enrico Granata
wrote:
> granata.enrico added a comment.
>
> So, if I understand this correctly, this HasChildAtIndex() API returns a
> three-state int:
>
> 1 == yes I do
> 0 == no I do not
> -1 == maybe, can't tell
>
> When would you ever run into the -1 case? It
granata.enrico added a comment.
So, if I understand this correctly, this HasChildAtIndex() API returns a
three-state int:
1 == yes I do
0 == no I do not
-1 == maybe, can't tell
When would you ever run into the -1 case? It seems you're mostly using it as an
invalid marker. Would 0 not be a bett
sivachandra added a comment.
Ah, we want this exposed in the SBValue API. What I mean't in the earlier
message was that no other part of LLDB will functionally depend/lookup/expect
this "feature".
http://reviews.llvm.org/D13778
___
lldb-commits ma
granata.enrico requested changes to this revision.
granata.enrico added a comment.
This revision now requires changes to proceed.
If so, why do you need this to be exposed as a call that LLDB knows about?
You are free to provide any methods you want in your synthetic child providers.
Adding them
sivachandra added a comment.
Yes, we would like to use this is specific synthetic providers. It will not be
used by any part of LLDB internally.
http://reviews.llvm.org/D13778
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.l
granata.enrico added a comment.
Is it possible to ask for concrete examples?
As in, for example, do you plan to change ValueObjectPrinter to use this API in
some way?
Or do you have any specific synthetic providers that you would like to use this
API in?
http://reviews.llvm.org/D13778
sivachandra added a comment.
As I mentioned in the first post, this is the use case:
Synthetic child providers currently have a method "has_children" and
"get_num_children". While the former is good enough to know if there are
children, it does not give any insight into how many children there ar
granata.enrico added a comment.
What do you plan to use this has_child_at_index call for?
My concern is that it adds complication to the synthetic child provider
interface. Yes, I understand it is optional, but it seems like yet another
thing in the "any children?" realm that I would rather muc
sivachandra added a comment.
If the general idea in this patch is OK, I will update it with tests.
http://reviews.llvm.org/D13778
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
sivachandra created this revision.
sivachandra added reviewers: clayborg, granata.enrico.
sivachandra added a subscriber: lldb-commits.
Along with this, support for an optional Python synthetic child provider
method "has_child_at_index" has also been added. These have been added
with the following
21 matches
Mail list logo
