public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] Add some const-ness to py-cmd.c
@ 2013-12-08  8:05 Doug Evans
  2013-12-09 10:39 ` Phil Muldoon
  2013-12-10 20:57 ` Tom Tromey
  0 siblings, 2 replies; 11+ messages in thread
From: Doug Evans @ 2013-12-08  8:05 UTC (permalink / raw)
  To: gdb-patches

Hi.

When can we drop support for older Python versions?

2013-12-08  Doug Evans  <xdje42@gmail.com>

	* python/py-cmd.c (struct cmdpy_completer): Add comment.
	(completers): Make const.

diff --git a/gdb/python/py-cmd.c b/gdb/python/py-cmd.c
index c0e9d96..c845c7c 100644
--- a/gdb/python/py-cmd.c
+++ b/gdb/python/py-cmd.c
@@ -32,13 +32,15 @@
 /* Struct representing built-in completion types.  */
 struct cmdpy_completer
 {
-  /* Python symbol name.  */
+  /* Python symbol name.
+     This isn't a const char * for Python 2.4's sake.
+     PyModule_AddIntConstant only takes a char *, sigh.  */
   char *name;
   /* Completion function.  */
   completer_ftype *completer;
 };
 
-static struct cmdpy_completer completers[] =
+static const struct cmdpy_completer completers[] =
 {
   { "COMPLETE_NONE", noop_completer },
   { "COMPLETE_FILENAME", filename_completer },

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] Add some const-ness to py-cmd.c
  2013-12-08  8:05 [PATCH] Add some const-ness to py-cmd.c Doug Evans
@ 2013-12-09 10:39 ` Phil Muldoon
  2013-12-10 20:57 ` Tom Tromey
  1 sibling, 0 replies; 11+ messages in thread
From: Phil Muldoon @ 2013-12-09 10:39 UTC (permalink / raw)
  To: Doug Evans, gdb-patches

On 08/12/13 08:04, Doug Evans wrote:
> Hi.
> 
> When can we drop support for older Python versions?
> 
> 2013-12-08  Doug Evans  <xdje42@gmail.com>
> 
> 	* python/py-cmd.c (struct cmdpy_completer): Add comment.
> 	(completers): Make const.
> 
> diff --git a/gdb/python/py-cmd.c b/gdb/python/py-cmd.c
> index c0e9d96..c845c7c 100644
> --- a/gdb/python/py-cmd.c
> +++ b/gdb/python/py-cmd.c
> @@ -32,13 +32,15 @@
>  /* Struct representing built-in completion types.  */
>  struct cmdpy_completer
>  {
> -  /* Python symbol name.  */
> +  /* Python symbol name.
> +     This isn't a const char * for Python 2.4's sake.
> +     PyModule_AddIntConstant only takes a char *, sigh.  */
>    char *name;
>    /* Completion function.  */
>    completer_ftype *completer;
>  };
>  
> -static struct cmdpy_completer completers[] =
> +static const struct cmdpy_completer completers[] =
>  {
>    { "COMPLETE_NONE", noop_completer },
>    { "COMPLETE_FILENAME", filename_completer },
> 

It's really up to our downstream packagers.  It can't be soon enough
for me.  I spend an inordinate amount of time checking my code (both C
and Python works on 2.4 -> 3.x).  It is really a time consuming and
tedious task.

My thoughts are that from GDB version x.x, we declare from then on we
only support Python 3.x, and if your distribution does not support
Python 3.x to revert GDB to an older version.

I suspect though that his would encounter some resistance from the
folks who work in the enterprise sector, as I doubt various
enterprise systems have updated to Python 3.x.

tl;dr  We should probably ask around.

Cheers,

Phil

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] Add some const-ness to py-cmd.c
  2013-12-08  8:05 [PATCH] Add some const-ness to py-cmd.c Doug Evans
  2013-12-09 10:39 ` Phil Muldoon
@ 2013-12-10 20:57 ` Tom Tromey
  2013-12-11  3:24   ` Tom Tromey
  1 sibling, 1 reply; 11+ messages in thread
From: Tom Tromey @ 2013-12-10 20:57 UTC (permalink / raw)
  To: Doug Evans; +Cc: gdb-patches, Sergio Durigan

>>>>> "Doug" == Doug Evans <xdje42@gmail.com> writes:

Doug> When can we drop support for older Python versions?

I thought we were keeping old ones for Google :)

I'm asking internally what we need for how long.

Tom

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] Add some const-ness to py-cmd.c
  2013-12-10 20:57 ` Tom Tromey
@ 2013-12-11  3:24   ` Tom Tromey
  2013-12-11  7:53     ` Joel Brobecker
  0 siblings, 1 reply; 11+ messages in thread
From: Tom Tromey @ 2013-12-11  3:24 UTC (permalink / raw)
  To: Doug Evans; +Cc: gdb-patches, Sergio Durigan, Jan Kratochvil

Tom> I'm asking internally what we need for how long.

I think we could drop Python 2.4 and 2.5 for gdb 7.8.  My understanding
is that we (Red Hat) won't need support for these in future gdb
releases.

Tom

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] Add some const-ness to py-cmd.c
  2013-12-11  3:24   ` Tom Tromey
@ 2013-12-11  7:53     ` Joel Brobecker
  2013-12-11  8:11       ` Jan Kratochvil
  2013-12-11 15:12       ` Tom Tromey
  0 siblings, 2 replies; 11+ messages in thread
From: Joel Brobecker @ 2013-12-11  7:53 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Doug Evans, gdb-patches, Sergio Durigan, Jan Kratochvil

> I think we could drop Python 2.4 and 2.5 for gdb 7.8.  My understanding
> is that we (Red Hat) won't need support for these in future gdb
> releases.

Do we need to keep 2.6? Python 2.7 was released July 3rd 2010, so over
3 years ago. GDB 7.8 would probably be around mid summer 2014, so 4 years
after Python 2.7 got released.

-- 
Joel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] Add some const-ness to py-cmd.c
  2013-12-11  7:53     ` Joel Brobecker
@ 2013-12-11  8:11       ` Jan Kratochvil
  2013-12-11 15:12       ` Tom Tromey
  1 sibling, 0 replies; 11+ messages in thread
From: Jan Kratochvil @ 2013-12-11  8:11 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: Tom Tromey, Doug Evans, gdb-patches, Sergio Durigan

On Wed, 11 Dec 2013 08:53:28 +0100, Joel Brobecker wrote:
> Do we need to keep 2.6?

Yes, we do - RHEL-6 ships python-2.6.6.  We would have to keep downstream
backport patchset otherwise.


Thanks,
Jan

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] Add some const-ness to py-cmd.c
  2013-12-11  7:53     ` Joel Brobecker
  2013-12-11  8:11       ` Jan Kratochvil
@ 2013-12-11 15:12       ` Tom Tromey
  2013-12-11 15:36         ` Joel Brobecker
  1 sibling, 1 reply; 11+ messages in thread
From: Tom Tromey @ 2013-12-11 15:12 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: Doug Evans, gdb-patches, Sergio Durigan, Jan Kratochvil

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

>> I think we could drop Python 2.4 and 2.5 for gdb 7.8.  My understanding
>> is that we (Red Hat) won't need support for these in future gdb
>> releases.

Joel> Do we need to keep 2.6? Python 2.7 was released July 3rd 2010, so over
Joel> 3 years ago. GDB 7.8 would probably be around mid summer 2014, so 4 years
Joel> after Python 2.7 got released.

Red Hat at least needs 2.6 for a while still.  RHEL 6 ships Python 2.6.
It would be more convenient for us if this were supported by gdb.

Of course gdb can go its own route and we will cope somehow.
A few points though --

It seems likely that other groups will also want 2.6 support.

My recollection is that the compatibility difficulties have been with
Python 2.4 and that 2.6 hasn't presented any particular problems.

Looking at the code I see some C hacks for 2.4 and one minor for 2.6.
I'm actually not too concerned about these workarounds, the one that has
been more of a pain is that 2.4 and 2.5 don't have support for the "as"
clause to "except".

thanks,
Tom

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] Add some const-ness to py-cmd.c
  2013-12-11 15:12       ` Tom Tromey
@ 2013-12-11 15:36         ` Joel Brobecker
  2013-12-11 15:43           ` Tom Tromey
  2013-12-11 15:57           ` Phil Muldoon
  0 siblings, 2 replies; 11+ messages in thread
From: Joel Brobecker @ 2013-12-11 15:36 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Doug Evans, gdb-patches, Sergio Durigan, Jan Kratochvil

> Red Hat at least needs 2.6 for a while still.  RHEL 6 ships Python 2.6.
> It would be more convenient for us if this were supported by gdb.
> 
> Of course gdb can go its own route and we will cope somehow.
> A few points though --

Just to be clear, I have no objection whatsoever towards keeping
support for 2.6! I don't think it is going to be that much more
work in any case, but just wondered whether that was necessary.
The one transition that worries me is 3.x, and I think this one
is going to hurt (at AdaCore).

-- 
Joel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] Add some const-ness to py-cmd.c
  2013-12-11 15:36         ` Joel Brobecker
@ 2013-12-11 15:43           ` Tom Tromey
  2013-12-11 15:56             ` Joel Brobecker
  2013-12-11 15:57           ` Phil Muldoon
  1 sibling, 1 reply; 11+ messages in thread
From: Tom Tromey @ 2013-12-11 15:43 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: Doug Evans, gdb-patches, Sergio Durigan, Jan Kratochvil

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> The one transition that worries me is 3.x, and I think this one
Joel> is going to hurt (at AdaCore).

It does seem difficult.  Fedora is aiming to switch over for Fedora 22.
I think we may switch gdb in Fedora 21, though.  The Fedora feature
proposal is here:

    https://fedoraproject.org/wiki/Changes/Python_3_as_Default

Tom

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] Add some const-ness to py-cmd.c
  2013-12-11 15:43           ` Tom Tromey
@ 2013-12-11 15:56             ` Joel Brobecker
  0 siblings, 0 replies; 11+ messages in thread
From: Joel Brobecker @ 2013-12-11 15:56 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Doug Evans, gdb-patches, Sergio Durigan, Jan Kratochvil

> Joel> The one transition that worries me is 3.x, and I think this one
> Joel> is going to hurt (at AdaCore).
> 
> It does seem difficult.  Fedora is aiming to switch over for Fedora 22.
> I think we may switch gdb in Fedora 21, though.  The Fedora feature
> proposal is here:
> 
>     https://fedoraproject.org/wiki/Changes/Python_3_as_Default

Same here. We've only discussed it informally, but we had the same
feeling regarding difficulty and timeline.

-- 
Joel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] Add some const-ness to py-cmd.c
  2013-12-11 15:36         ` Joel Brobecker
  2013-12-11 15:43           ` Tom Tromey
@ 2013-12-11 15:57           ` Phil Muldoon
  1 sibling, 0 replies; 11+ messages in thread
From: Phil Muldoon @ 2013-12-11 15:57 UTC (permalink / raw)
  To: Joel Brobecker, Tom Tromey
  Cc: Doug Evans, gdb-patches, Sergio Durigan, Jan Kratochvil

On 11/12/13 15:36, Joel Brobecker wrote:
>> Red Hat at least needs 2.6 for a while still.  RHEL 6 ships Python 2.6.
>> It would be more convenient for us if this were supported by gdb.
>>
>> Of course gdb can go its own route and we will cope somehow.
>> A few points though --
> 
> Just to be clear, I have no objection whatsoever towards keeping
> support for 2.6! I don't think it is going to be that much more
> work in any case, but just wondered whether that was necessary.
> The one transition that worries me is 3.x, and I think this one
> is going to hurt (at AdaCore).

FWIW, GDB is ready to go with Python 3.x.  I check the builds weekly
against the test-suite.  There may still be some logic bugs hiding
(like a recent one I fixed: Python 3.x's internal representation of
integers changed to be longs only; that caused an out of order logic
bug in Python conversion routines in GDB which has to support 2.x and
3.x.)  So your GDB pain, at least, should be mitigated ;)

Cheers,

Phil


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2013-12-11 15:57 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-08  8:05 [PATCH] Add some const-ness to py-cmd.c Doug Evans
2013-12-09 10:39 ` Phil Muldoon
2013-12-10 20:57 ` Tom Tromey
2013-12-11  3:24   ` Tom Tromey
2013-12-11  7:53     ` Joel Brobecker
2013-12-11  8:11       ` Jan Kratochvil
2013-12-11 15:12       ` Tom Tromey
2013-12-11 15:36         ` Joel Brobecker
2013-12-11 15:43           ` Tom Tromey
2013-12-11 15:56             ` Joel Brobecker
2013-12-11 15:57           ` Phil Muldoon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).