Some Python ideas, looking for feedback

Some Python ideas, looking for feedback

[Paul_Koning]

In trying out the Python scripting, I've run into some things that seem either inconsistent, or omissions of standard Python facilities, and I could do something about this if there is interest.

One inconsistency: Value objects can have their fields looked up by collection syntax, but Type objects cannot.  

Omission: while Value objects can have collection references to individual components, they don't support iteration as is normal for Python collections.

And a question: is there a way to get the value corresponding to an enum type's value name?  The name comes back in the fields() output but I don't see how I would get the value.  Could that be made a value attribute of the field object?

I can propose patches for each of these things, if there is interest.

               paul

Re: Some Python ideas, looking for feedback

[André Pönitz]

On Tuesday 16 August 2011 13:03:42 ext Paul_Koning@Dell.com wrote:
> [...]
> And a question: is there a way to get the value corresponding to an enum type's value name?  
> The name comes back in the fields() output but I don't see how I would get the value.  Could that be made a value attribute of the field object?

int(...) works, or "%d" % ...

Andre'

RE: Some Python ideas, looking for feedback

[Paul_Koning]

>On Tuesday 16 August 2011 13:03:42 ext Paul_Koning@Dell.com wrote:
>> [...]
>> And a question: is there a way to get the value corresponding to an enum type's value name?  
>> The name comes back in the fields() output but I don't see how I would get the value.  Could that be made a value attribute of the field object?
>
>int(...) works, or "%d" % ...

That works for Value objects, but not for fields of Type.  But it looks like an obvious way to make it work for Type (rather than a "value" attribute as I suggested earlier).

	paul

Re: Some Python ideas, looking for feedback

[Andrew Oakley]

On Tue, 16 Aug 2011 09:45:35 -0500
<Paul_Koning@Dell.com> wrote:

> >On Tuesday 16 August 2011 13:03:42 ext Paul_Koning@Dell.com wrote:
> >> [...]
> >> And a question: is there a way to get the value corresponding to
> >> an enum type's value name? The name comes back in the fields()
> >> output but I don't see how I would get the value.  Could that be
> >> made a value attribute of the field object?
> >
> >int(...) works, or "%d" % ...
> 
> That works for Value objects, but not for fields of Type.  But it
> looks like an obvious way to make it work for Type (rather than a
> "value" attribute as I suggested earlier).

What you are looking for is (for some reason) stored in bitpos.  I
can't actually find any documentation for this :(.

You could use the function that is included with current gdb trunk
(not sure if it is any releases) in the module gdb.types.  It looks
like this:

> def make_enum_dict(enum_type):
>     """Return a dictionary from a program's enum type.
> 
>     Arguments:
>         enum_type: The enum to compute the dictionary for.
> 
>     Returns:
>         The dictionary of the enum.
> 
>     Raises:
>         TypeError: The type is not an enum.
>     """
> 
>     if enum_type.code != gdb.TYPE_CODE_ENUM:
>         raise TypeError("not an enum type")
>     enum_dict = {}
>     for field in enum_type.fields():
>         # The enum's value is stored in "bitpos".
>         enum_dict[field.name] = field.bitpos
>     return enum_dict

-- 
Andrew Oakley

Re: Some Python ideas, looking for feedback

[Andrew Oakley]

On Wed, 17 Aug 2011 19:37:10 +0100
Andrew Oakley <andrew@ado.is-a-geek.net> wrote:
> What you are looking for is (for some reason) stored in bitpos.  I
> can't actually find any documentation for this :(.

Perhaps we should fix that:

Document gdb.Value field attribute "bitpos" for enums.

---

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 6e7bf52..c82173b 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -21575,7 +21575,8 @@ Each field is an object, with some pre-defined
attributes: @item bitpos
 This attribute is not available for @code{static} fields (as in
 C@t{++} or Java).  For non-@code{static} fields, the value is the bit
-position of the field.
+position of the field.  For @code{enum} fields, the value is the
enumeration +member's integer representation.

 @item name
 The name of the field, or @code{None} for anonymous fields.



-- 
Andrew Oakley

Re: Some Python ideas, looking for feedback

[Eli Zaretskii]

> Date: Wed, 17 Aug 2011 20:13:16 +0100
> From: Andrew Oakley <andrew@ado.is-a-geek.net>
> Cc: <gdb@sourceware.org>
> 
> -position of the field.
> +position of the field.  For @code{enum} fields, the value is the
> enumeration +member's integer representation.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I don't understand this part.  Can you elaborate, please?  In
particular, what does that `+' stand for?

Re: Some Python ideas, looking for feedback

[Andrew Oakley]

On Wed, 17 Aug 2011 22:29:40 +0300
Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Wed, 17 Aug 2011 20:13:16 +0100
> > From: Andrew Oakley <andrew@ado.is-a-geek.net>
> > Cc: <gdb@sourceware.org>
> > 
> > -position of the field.
> > +position of the field.  For @code{enum} fields, the value is the
> > enumeration +member's integer representation.
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> I don't understand this part.  Can you elaborate, please?  In
> particular, what does that `+' stand for?

Oops.  That's a broken copy + paste into a email compose window.  I
should have used git send-email so that didn't happen :(. 

"Fixed" version:

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 6e7bf52..c82173b 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -21575,7 +21575,8 @@ Each field is an object, with some pre-defined
attributes: @item bitpos
 This attribute is not available for @code{static} fields (as in
 C@t{++} or Java).  For non-@code{static} fields, the value is the bit
-position of the field.
+position of the field.  For @code{enum} fields, the value is the
+enumeration member's integer representation.

 @item name
 The name of the field, or @code{None} for anonymous fields.


-- 
Andrew Oakley

Re: Some Python ideas, looking for feedback

[Eli Zaretskii]

> Date: Wed, 17 Aug 2011 20:35:25 +0100
> From: Andrew Oakley <andrew@ado.is-a-geek.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sourceware.org
> 
> "Fixed" version:
> 
> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
> index 6e7bf52..c82173b 100644
> --- a/gdb/doc/gdb.texinfo
> +++ b/gdb/doc/gdb.texinfo
> @@ -21575,7 +21575,8 @@ Each field is an object, with some pre-defined
> attributes: @item bitpos
>  This attribute is not available for @code{static} fields (as in
>  C@t{++} or Java).  For non-@code{static} fields, the value is the bit
> -position of the field.
> +position of the field.  For @code{enum} fields, the value is the
> +enumeration member's integer representation.

This version is fine, thanks.

Re: Some Python ideas, looking for feedback

[Daniel Jacobowitz]

On Wed, Aug 17, 2011 at 3:13 PM, Andrew Oakley <andrew@ado.is-a-geek.net> wrote:
> On Wed, 17 Aug 2011 19:37:10 +0100
> Andrew Oakley <andrew@ado.is-a-geek.net> wrote:
>> What you are looking for is (for some reason) stored in bitpos.  I
>> can't actually find any documentation for this :(.
>
> Perhaps we should fix that:
>
> Document gdb.Value field attribute "bitpos" for enums.

I don't suppose we can avoid exposing this internal C wart to Python,
and expose it some other way... ?

-- 
Thanks,
Daniel

RE: Some Python ideas, looking for feedback

[Paul_Koning]

>> On Wed, 17 Aug 2011 19:37:10 +0100
>> Andrew Oakley <andrew@ado.is-a-geek.net> wrote:
>>> What you are looking for is (for some reason) stored in bitpos.  I 
>>> can't actually find any documentation for this :(.
>>
>> Perhaps we should fix that:
>>
>> Document gdb.Value field attribute "bitpos" for enums.
>
>I don't suppose we can avoid exposing this internal C wart to Python, and expose it some other way... ?

Clearly we could.  For example, André suggested using the int() function on the field object, by analogy to what int() does to an enum-valued Value object.  That certainly would make sense and it would be a pretty natural Pythonic thing to do.

	paul

Re: Some Python ideas, looking for feedback

[Tom Tromey]

>>>>> "Paul" ==   <Paul_Koning@Dell.com> writes:

Paul> Clearly we could.  For example, André suggested using the int()
Paul> function on the field object, by analogy to what int() does to an
Paul> enum-valued Value object.  That certainly would make sense and it
Paul> would be a pretty natural Pythonic thing to do.

Sounds good to me.

Tom

Re: Some Python ideas, looking for feedback

[Tom Tromey]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

Daniel> I don't suppose we can avoid exposing this internal C wart to Python,
Daniel> and expose it some other way... ?

I think it depends on whether we have shipped it or not.
If we have, then perhaps someone is using it; in that case I would
rather not break it.

However, even in that case, we can still add a new attribute with a
better name and recommend that people use it.

Tom

Re: Some Python ideas, looking for feedback

[Andrew Oakley]

On 19/08/11 15:13, Tom Tromey wrote:
>>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:
> 
> Daniel> I don't suppose we can avoid exposing this internal C wart to Python,
> Daniel> and expose it some other way... ?
> 
> I think it depends on whether we have shipped it or not.
> If we have, then perhaps someone is using it; in that case I would
> rather not break it.

Yes, you've shipped it.  At least one person is using it (me).  I'd
prefer it if this didn't go away.

> However, even in that case, we can still add a new attribute with a
> better name and recommend that people use it.

Thats fair enough, but for now can we please get the documentation updated?

-- 
Andrew Oakley

Re: Some Python ideas, looking for feedback

[Phil Muldoon]

Andrew Oakley <andrew@ado.is-a-geek.net> writes:

> On 19/08/11 15:13, Tom Tromey wrote:
>>>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:
>> 
>> Daniel> I don't suppose we can avoid exposing this internal C wart to Python,
>> Daniel> and expose it some other way... ?
>> 
>> I think it depends on whether we have shipped it or not.
>> If we have, then perhaps someone is using it; in that case I would
>> rather not break it.
>
> Yes, you've shipped it.  At least one person is using it (me).  I'd
> prefer it if this didn't go away.
>
>> However, even in that case, we can still add a new attribute with a
>> better name and recommend that people use it.
>
> Thats fair enough, but for now can we please get the documentation updated?

Didn't Eli already approve it?  

If so, do you have FSF paperwork filed (I'm not a maintainer, so I won't
hazard a guess if this is ok to be posted by another committer).

OTOH, if you see yourself doing more GDB hacking, and do not have
paperwork, best to get that underway.  Sometimes there can be long
delays in that process.

Cheers

Phil

Re: Some Python ideas, looking for feedback

[Andrew Oakley]

On 24/08/11 12:42, Phil Muldoon wrote:
> Andrew Oakley <andrew@ado.is-a-geek.net> writes:
> 
>> On 19/08/11 15:13, Tom Tromey wrote:
>>>>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:
>>>
>>> Daniel> I don't suppose we can avoid exposing this internal C wart to Python,
>>> Daniel> and expose it some other way... ?
>>>
>>> I think it depends on whether we have shipped it or not.
>>> If we have, then perhaps someone is using it; in that case I would
>>> rather not break it.
>>
>> Yes, you've shipped it.  At least one person is using it (me).  I'd
>> prefer it if this didn't go away.
>>
>>> However, even in that case, we can still add a new attribute with a
>>> better name and recommend that people use it.
>>
>> Thats fair enough, but for now can we please get the documentation updated?
> 
> Didn't Eli already approve it?

Oops, it looks like he did but it just hasn't been committed yet.

> If so, do you have FSF paperwork filed (I'm not a maintainer, so I won't
> hazard a guess if this is ok to be posted by another committer).

The paperwork has already been done (I'm not sure it's really necessary
here anyway).

Thanks

-- 
Andrew Oakley

Re: Some Python ideas, looking for feedback

[Phil Muldoon]

Andrew Oakley <andrew@ado.is-a-geek.net> writes:

>> Didn't Eli already approve it?
>
> Oops, it looks like he did but it just hasn't been committed yet.
>
>> If so, do you have FSF paperwork filed (I'm not a maintainer, so I won't
>> hazard a guess if this is ok to be posted by another committer).
>
> The paperwork has already been done (I'm not sure it's really necessary
> here anyway).

If you have maintainer approval, FSF paperwork approved and filed, and
write-after-approval status, you should check it in.

Cheers

Phil

Re: Some Python ideas, looking for feedback

[Tom Tromey]

>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:

Phil> Didn't Eli already approve it?  

Yes.  I'm checking it in.

Andrew, please write a ChangeLog entry next time.  Here is what I am
using:

2011-08-25  Andrew Oakley  <andrew@ado.is-a-geek.net>

	* gdb.texinfo (Types In Python): Document 'bitpos' for enums.

Phil> If so, do you have FSF paperwork filed (I'm not a maintainer, so I won't
Phil> hazard a guess if this is ok to be posted by another committer).

Phil> OTOH, if you see yourself doing more GDB hacking, and do not have
Phil> paperwork, best to get that underway.  Sometimes there can be long
Phil> delays in that process.

If you already have paperwork, you can get write-after-approval access;
contact me off-list.

Tom

Re: Some Python ideas, looking for feedback

[Phil Muldoon]

<Paul_Koning@Dell.com> writes:

> In trying out the Python scripting, I've run into some things that seem either inconsistent, or omissions of standard Python facilities, and I could do something about this if there is interest.

Apologies for not replying sooner, but:

> One inconsistency: Value objects can have their fields looked up by collection syntax, but Type objects cannot.  
>
> Omission: while Value objects can have collection references to individual components, they don't support iteration as is normal for Python collections.

Can you file bugs for these?  That way they have the best way of being
fixed and not forgotten in mailing list traffic.  I check
sourceware.org bugzilla daily.  No promises when I (or somebody else)
will implement them, but I will try for 7.4

Cheers

Phil

Re: Some Python ideas, looking for feedback

[Tom Tromey]

>>>>> "Paul" ==   <Paul_Koning@Dell.com> writes:

Paul> Omission: while Value objects can have collection references to
Paul> individual components, they don't support iteration as is normal for
Paul> Python collections.

I think this would be a good addition.

Tom