PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73)
On Wed, Jun 28, 2000 at 02:57:20PM -0700, Guido van Rossum wrote:
Update of /cvsroot/python/python/dist/src/Objects In directory slayer.i.sourceforge.net:/tmp/cvs-serv5838
Modified Files: classobject.c object.c Log Message: Trent Mick: change a few casts for Win64 compatibility.
Index: classobject.c
RCS file: /cvsroot/python/python/dist/src/Objects/classobject.c,v retrieving revision 2.89 retrieving revision 2.90 diff -C2 -r2.89 -r2.90 *** classobject.c 2000/06/23 19:37:01 2.89 --- classobject.c 2000/06/28 21:57:18 2.90
*** 284,288 **** if (v == NULL || !PyString_Check(v)) return "__name__ must be a string object"; ! if ((long)strlen(PyString_AS_STRING(v)) != PyString_GET_SIZE(v)) return "__name__ must not contain null bytes"; set_slot(&c->cl_name, v); --- 284,288 ---- if (v == NULL || !PyString_Check(v)) return "__name__ must be a string object"; ! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v)) return "__name__ must not contain null bytes"; set_slot(&c->cl_name, v);
Actually, it would seem to make more sense to place the cast *inside* the PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.
May as well start some ANSI-fication while we can...
Guido: any problem with my changing the macro?
Cheers, -g
On Wed, Jun 28, 2000 at 03:17:58PM -0700, Greg Stein wrote:
On Wed, Jun 28, 2000 at 02:57:20PM -0700, Guido van Rossum wrote:
Update of /cvsroot/python/python/dist/src/Objects In directory slayer.i.sourceforge.net:/tmp/cvs-serv5838
Modified Files: classobject.c object.c Log Message: Trent Mick: change a few casts for Win64 compatibility.
Index: classobject.c
RCS file: /cvsroot/python/python/dist/src/Objects/classobject.c,v retrieving revision 2.89 retrieving revision 2.90 diff -C2 -r2.89 -r2.90 *** classobject.c 2000/06/23 19:37:01 2.89 --- classobject.c 2000/06/28 21:57:18 2.90
*** 284,288 **** if (v == NULL || !PyString_Check(v)) return "__name__ must be a string object"; ! if ((long)strlen(PyString_AS_STRING(v)) != PyString_GET_SIZE(v)) return "__name__ must not contain null bytes"; set_slot(&c->cl_name, v); --- 284,288 ---- if (v == NULL || !PyString_Check(v)) return "__name__ must be a string object"; ! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v)) return "__name__ must not contain null bytes"; set_slot(&c->cl_name, v);
Actually, it would seem to make more sense to place the cast *inside* the PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.
May as well start some ANSI-fication while we can...
I agree. Go to town, Greg. :)
Trent
! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v))
Actually, it would seem to make more sense to place the cast *inside* the PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.
May as well start some ANSI-fication while we can...
Guido: any problem with my changing the macro?
Please leave the macro alone. The type of the macro should be the same as the type of the function -- PyString_Size() -- which is int. If you change this, you potentially get tons of warnings because of the signed / unsigned nature.
ANSI-fication is a good project for after 1.6. But even then, it's a separate decision whether the size of a string should be a size_t instead of an int. (The ob_size field should also change, if so -- with even more consequences.)
--Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, Jun 28, 2000 at 08:11:36PM -0500, Guido van Rossum wrote:
! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v))
Actually, it would seem to make more sense to place the cast *inside* the PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.
May as well start some ANSI-fication while we can...
Guido: any problem with my changing the macro?
Please leave the macro alone. The type of the macro should be the same as the type of the function -- PyString_Size() -- which is int. If you change this, you potentially get tons of warnings because of the signed / unsigned nature.
ANSI-fication is a good project for after 1.6. But even then, it's a separate decision whether the size of a string should be a size_t instead of an int. (The ob_size field should also change, if so -- with even more consequences.)
Post 1.6, yes... I had figured on ob_size changing. Certainly not now :-)
But I understand the point about different return types. No problem.
[ of course, I would state that PyString_Size should also change and we fix those warnings... but I'll be patient :-) ]
How about removing Py_PROTO() usage, and changing function definitions from K&R arg declaration to ANSI declarations? That kind of work is pretty simple, straight-forward, and if somebody has free time to plod through the work... so much the better. I believe that these changes would not introduce any stability problems, and could be done independently from your busy schedule.
Hmm. Is there a good place to start listing these todo items? One that we can truly use for communicating this info? In Apache, we have a file named STATUS that everybody uses for dropping ideas, patch references, critical bugs, etc. As that file gets changed, we see it in the -checkins alias, so everybody is aware of the suggested changes/problems/available patches/etc. It also holds people's votes on particular changes.
Can we institute something similar? Possibly Misc/STATUS? Should I post Apache's STATUS file as an example?
Cheers, -g
[Greg Stein]
... How about removing Py_PROTO() usage, and changing function definitions from K&R arg declaration to ANSI declarations? That kind of work is pretty simple, straight-forward, and if somebody has free time to plod through the work... so much the better.
I think it's too late in the cycle to suggest work for others to do and get any payback from that. Unless you're the one with the free time -- in which case full speed ahead and God bless! I previously volunteered to take the Py_PROTO crap on, as I use an editor with a symbol database that gets confused by that stuff, but I'm sure not going to start that this week.
... Hmm. Is there a good place to start listing these todo items?
Not that I know of. "Group whiteboards" and shared journals etc are darned useful, though.
One that we can truly use for communicating this info? In Apache, we have a file named STATUS that everybody uses for dropping ideas, patch references, critical bugs, etc. As that file gets changed, we see it in the -checkins alias, so everybody is aware of the suggested changes/problems/available patches/etc. It also holds people's votes on particular changes.
Can we institute something similar? Possibly Misc/STATUS? Should I post Apache's STATUS file as an example?
Yes, sure, no: just check one in! If Guido hates it, we can remove it later. In the meantime, I bet we'll find great ways to use it. In the spirit of Unix, maybe it should be called Misc/gwtbd <wink>.
let-a-thousand-idiosyncracies-bloom-ly y'rs - tim
On Thu, 29 Jun 2000, Tim Peters wrote:
... Hmm. Is there a good place to start listing these todo items?
Not that I know of. "Group whiteboards" and shared journals etc are darned useful, though.
Wiki = Group whiteboard
Zope could do a lot of this stuff well. As is, ZWiki offers some organizational features. I've held off on pushing them because they're still baking - things like change notifications, discretion about change privileges, versions (with differences, based on your ndiff.py), etc are coming soonish. (Exactly how soonish is hard to say, the way time and more direct business obligations are - but this stuff actually is important to us, we're using them a lot for collaboration, and need for the dynamics to scale...)
I also have the feeling that our tracker would be good for patch management - except, i don't really know what the requirements are, there, and once again, tracker only gives notifications via email, it doesn't take input that way.
Anyway, to see leads on both zwikis and tracker, see:
http://www.zope.org/Members/klm/TrackerWiki
Oh, and it would be easy to set up a wiki for python dev on zope.org somewhere - i could put it in my account, or we could situate one more centrally, in a storage that's never packed, so the version history is maintained. Or any of you could get a zope.org membership and set some up, yerselves. Or set up a zope somewhere - it'd be !cool! if sourceforge were willing...
Ken klm@zope.org
On Thu, 29 Jun 2000, Ken Manheimer wrote:
Wiki = Group whiteboard [...] Oh, and it would be easy to set up a wiki for python dev on zope.org somewhere - i could put it in my account, or we could situate one more
http://www.zope.org/Members/klm/PythonDev/TodoLists
There's nothing else of substance there, but anyone who's a member at zope.org can edit and add pages...
Ken
[Tim]
... "Group whiteboards" and shared journals etc are darned useful, though.
[Ken Manheimer]
Wiki = Group whiteboard
Ya, I kind of picked that up from your last passionate advertisement for this stuff <wink>. Not knocking it! Never tried it. Believe it or not, I spend as little time on the web as possible. After I've gotten into a place to live here, and this current release crunch is behind us, I'm definitely going to check out your leads.
For the past several years my development group worked thru Lotus Notes, which I didn't much care for at the time, but I'm increasingly realizing just how essential group-modifiable shared persistent documents were to our productivity. Notes is the purest example of a whole being greater than the sum of its parts I've ever seen (lousy mail system, lousy database, lousy change manager, lousy bug tracker, lousy workflow manager, worse than lousy native scripting ... but they all sucked in ways that were downright synergistic <0.9 wink>).
... Anyway, to see leads on both zwikis and tracker, see:
can-beopen-zwiki-2.0-be-far-behind<wink>?-ly y'rs - tim
Tim Peters writes:
productivity. Notes is the purest example of a whole being greater than the sum of its parts I've ever seen (lousy mail system, lousy database, lousy change manager, lousy bug tracker, lousy workflow manager, worse than lousy native scripting ... but they all sucked in ways that were downright synergistic <0.9 wink>).
I had to use Notes before working at CNRI, and wouldn't have described all those sucky components as "synergistic". ;)
-Fred
Hmm. Is there a good place to start listing these todo items? One that we can truly use for communicating this info? In Apache, we have a file named STATUS that everybody uses for dropping ideas, patch references, critical bugs, etc. As that file gets changed, we see it in the -checkins alias, so everybody is aware of the suggested changes/problems/available patches/etc. It also holds people's votes on particular changes.
Can we institute something similar? Possibly Misc/STATUS? Should I post Apache's STATUS file as an example?
Possibly, but I'm somewhat skeptical. I used to have a large TODO file -- still have it -- but it's so full of long-term ideas that never happened that I rarely look in it any more. I never got into the discipline of using it for my day-to-day priorities -- it was more of a place to write down long-term ideas so I could forget about them. I'll append it. I appreciate a copy of Apache's STATUS file.
--Guido van Rossum (home page: http://www.python.org/~guido/)
NEW TODO LIST FOR 1.6 =====================
IDLE: set window class? socket/ssl version mystery
UNIFIED TODO LIST =================
guido wrote:
Hmm. Is there a good place to start listing these todo items? One that we can truly use for communicating this info? In Apache, we have a file named STATUS that everybody uses for dropping ideas, patch references, critical bugs, etc. As that file gets changed, we see it in the -checkins alias, so everybody is aware of the suggested changes/problems/available patches/etc. It also holds people's votes on particular changes.
Can we institute something similar? Possibly Misc/STATUS? Should I post Apache's STATUS file as an example?
Possibly, but I'm somewhat skeptical. I used to have a large TODO file -- still have it -- but it's so full of long-term ideas that never happened that I rarely look in it any more.
instead of a file, I suggest taking a look at ?!ng's Roundup (once 1.6 final is out, of course).
</F>
On Thu, Jun 29, 2000 at 08:49:32AM -0500, Guido van Rossum wrote:
Hmm. Is there a good place to start listing these todo items? One that we can truly use for communicating this info? In Apache, we have a file named STATUS that everybody uses for dropping ideas, patch references, critical bugs, etc. As that file gets changed, we see it in the -checkins alias, so everybody is aware of the suggested changes/problems/available patches/etc. It also holds people's votes on particular changes.
Can we institute something similar? Possibly Misc/STATUS? Should I post Apache's STATUS file as an example?
Possibly, but I'm somewhat skeptical. I used to have a large TODO file -- still have it -- but it's so full of long-term ideas that never happened that I rarely look in it any more. I never got into the discipline of using it for my day-to-day priorities -- it was more of a place to write down long-term ideas so I could forget about them. I'll append it. I appreciate a copy of Apache's STATUS file.
Attached below...
participants (7)
-
Fred L. Drake, Jr. -
Fredrik Lundh -
Greg Stein -
Guido van Rossum -
Ken Manheimer -
Tim Peters -
Trent Mick