Its taken longer than I'd hoped, however they're finally up for review. The updated bits have been attached to the previous patch entries in the patch manager: 435381: distutils changes http://sf.net/tracker/?func=detail&atid=305470&aid=435381&group_id=5470 450265: build files - self contained subdirectory in PC/ http://sf.net/tracker/?func=detail&atid=305470&aid=450265&group_id=5470 450266: library changes - 3 patch files covering:- - Lib/ (included os2emxpath.py as previously discussed here) - Lib/plat-os2emx/ (new subdirectory) - Lib/test/ (cope with 2 EMX limitations) http://sf.net/tracker/?func=detail&atid=305470&aid=450266&group_id=5470 450267: core changes - 4 patch files covering:- - Include/ - Modules/ (lots of changes; see below for more info) - Objects/ (see below for more info) - Python/ http://sf.net/tracker/?func=detail&atid=305470&aid=450267&group_id=5470 I hope that I got the patch links right... Particular notes wrt #450267: - the patch to Modules/import.c supports VACPP in addition to EMX. Michael Muller has trialled this patch with a VACPP build successfully. It is messy, but OS/2 isn't going to lose the 8.3 naming limit on DLLs anytime soon :-( Although truncating the DLL (PYD) name to 8 characters increases the chances of a name clash, the case-sensitive import support in the same patch alleviates it somewhat, and the fact that the "init<module>" entrypoint is maintained will result in an import failure when there is an actual name clash. - Modules/unicodedata.c is affected by a name clash between the internally defined _getname() and an EMX routine of the same name defined in <stdlib.h>. The patch renames the internal routine to _getucname() to avoid this, but this change may not be acceptable - advice please. - Objects/stringobject.c and Objects/unicodeobject.c contain changes to handle the EMX runtime library returning "0x" as the prefix for output formatted with a "%X" format. I have tried to minimise the changes in these patches to the minimum needed for the port to function, ie I've tried to eradicate the cosmetic changes in the earlier patches, and avoid picking up unwanted files (such as Modules/Setup). Please let me know if you find any such changes I missed. The patches uploaded apply cleanly to a copy of an anonoymously checked out CVS tree as of 0527 AEST this morning (Jan 27), and have been built and regression tested on both OS/2 EMX and FreeBSD 4.4R with no unexpected test failures. If there are no unresolvable objections, and approval to apply these patches is granted, I propose that the patches be applied as follows:- Stage 1: the build patch (creates+populates PC/os2emx/) Stage 2: the Lib/plat-os2emx/ patch Stage 3: the Lib/ and Lib/test/ patches Stage 4: the distutils patch Stage 5: the Include/, Objects/ and Python/ patches Stage 6: the Modules/ patch I would expect to allow at least 48 hours between stages. Comments/advice on this proposal also appreciated. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au | Snail: PO Box 370 andymac@pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia
Andrew MacIntyre <andymac@bullseye.apana.org.au> writes:
- Modules/unicodedata.c is affected by a name clash between the internally defined _getname() and an EMX routine of the same name defined in <stdlib.h>. The patch renames the internal routine to _getucname() to avoid this, but this change may not be acceptable - advice please.
My advice for renaming things because of name clashes: Always rename in a way that solves this particular problem for good, by using the Py prefix (or _Py to further indicate that this is not public API; it's a static function, anyway). Somebody may have a function _getucname somewhere, whereas it is really unlikely that people add a Py prefix to their functions (if they have been following the last 30 years of C programming).
- Objects/stringobject.c and Objects/unicodeobject.c contain changes to handle the EMX runtime library returning "0x" as the prefix for output formatted with a "%X" format.
I'd suggest a different approach here, which does not use #ifdefs: Instead of testing for the system, test for the bug. Then, if the bug goes away, or appears on other systems as well, the code will be good. Once formatting is complete, see whether it put in the right letter, and fix that in the result buffer if the native sprintf got it wrong. If you follow this strategy, you should still add a comment indicating that this was added for OS/2, to give people an idea where that came from. Another approach would be to autoconfiscate this particular issue. I'm in general in favour of autoconf'ed bug tests instead of runtime bug tests, but people on systems without /bin/sh might feel differently.
If there are no unresolvable objections, and approval to apply these patches is granted, I propose that the patches be applied as follows:-
Stage 1: the build patch (creates+populates PC/os2emx/) Stage 2: the Lib/plat-os2emx/ patch Stage 3: the Lib/ and Lib/test/ patches Stage 4: the distutils patch Stage 5: the Include/, Objects/ and Python/ patches Stage 6: the Modules/ patch
I would expect to allow at least 48 hours between stages.
Comments/advice on this proposal also appreciated.
Sounds good to me (although I'd probably process the "uncritical", i.e. truly platform-specific parts much more quickly). Who's going to work with Andrew to integrate this stuff? Regards, Martin
I've let this lie for a few days to see whether any other comments were forthcoming, but nothing's turned up... On 27 Jan 2002, Martin v. Loewis wrote:
Andrew MacIntyre <andymac@bullseye.apana.org.au> writes:
- Modules/unicodedata.c is affected by a name clash between the internally defined _getname() and an EMX routine of the same name defined in <stdlib.h>. The patch renames the internal routine to _getucname() to avoid this, but this change may not be acceptable - advice please.
My advice for renaming things because of name clashes: Always rename in a way that solves this particular problem for good, by using the Py prefix (or _Py to further indicate that this is not public API; it's a static function, anyway). Somebody may have a function _getucname somewhere, whereas it is really unlikely that people add a Py prefix to their functions (if they have been following the last 30 years of C programming).
Fair enough. I was trying to minimise stylistic differences in the fix, but if using _Py_getname is the canonical solution, that's easy fixed.
- Objects/stringobject.c and Objects/unicodeobject.c contain changes to handle the EMX runtime library returning "0x" as the prefix for output formatted with a "%X" format.
I'd suggest a different approach here, which does not use #ifdefs: Instead of testing for the system, test for the bug. Then, if the bug goes away, or appears on other systems as well, the code will be good.
I did it the way I did because there's already code dealing with other brokeness in this area which doesn't solve the EMX issue, and the #ifdef solution minimises the risk of EMX fixes breaking something else which I can't test. At this stage I can't see this bug being fixed in EMX :-(
Once formatting is complete, see whether it put in the right letter, and fix that in the result buffer if the native sprintf got it wrong.
If you follow this strategy, you should still add a comment indicating that this was added for OS/2, to give people an idea where that came from.
Definitely a more general approach, which I'll look at in detail.
Another approach would be to autoconfiscate this particular issue. I'm in general in favour of autoconf'ed bug tests instead of runtime bug tests, but people on systems without /bin/sh might feel differently.
While there are sh/bash shells for OS/2, they're not standard equipment. Autoconf also has a very spotty record on OS/2, although there are people trying to improve that.
If there are no unresolvable objections, and approval to apply these patches is granted, I propose that the patches be applied as follows:-
Stage 1: the build patch (creates+populates PC/os2emx/) Stage 2: the Lib/plat-os2emx/ patch Stage 3: the Lib/ and Lib/test/ patches Stage 4: the distutils patch Stage 5: the Include/, Objects/ and Python/ patches Stage 6: the Modules/ patch
I would expect to allow at least 48 hours between stages.
Comments/advice on this proposal also appreciated.
Sounds good to me (although I'd probably process the "uncritical", i.e. truly platform-specific parts much more quickly). Who's going to work with Andrew to integrate this stuff?
The last I heard, Guido expected I was going to commit my own patches (after review), so I was allowing time for my initial attempts to commit to be checked by regular builders/testers of the tree before getting to changes that affect non-EMX specific parts of Python. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au | Snail: PO Box 370 andymac@pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia
Andrew MacIntyre wrote:
On 27 Jan 2002, Martin v. Loewis wrote:
Andrew MacIntyre <andymac@bullseye.apana.org.au> writes:
- Modules/unicodedata.c is affected by a name clash between the internally defined _getname() and an EMX routine of the same name defined in <stdlib.h>. The patch renames the internal routine to _getucname() to avoid this, but this change may not be acceptable - advice please.
My advice for renaming things because of name clashes: Always rename in a way that solves this particular problem for good, by using the Py prefix (or _Py to further indicate that this is not public API; it's a static function, anyway). Somebody may have a function _getucname somewhere, whereas it is really unlikely that people add a Py prefix to their functions (if they have been following the last 30 years of C programming).
Fair enough. I was trying to minimise stylistic differences in the fix, but if using _Py_getname is the canonical solution, that's easy fixed.
+1
- Objects/stringobject.c and Objects/unicodeobject.c contain changes to handle the EMX runtime library returning "0x" as the prefix for output formatted with a "%X" format.
I'd suggest a different approach here, which does not use #ifdefs: Instead of testing for the system, test for the bug. Then, if the bug goes away, or appears on other systems as well, the code will be good.
I did it the way I did because there's already code dealing with other brokeness in this area which doesn't solve the EMX issue, and the #ifdef solution minimises the risk of EMX fixes breaking something else which I can't test. At this stage I can't see this bug being fixed in EMX :-(
I'd go with Martin's suggestion here: there already is code in formatint() which tests for '%#X' adding '0x' or not. This code should be made to handle the special case by testing for it -- who knows: there may be other platforms where this doesn't work as expected either. BTW, could you point me to your patch for this ? Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
On Thu, 31 Jan 2002, M.-A. Lemburg wrote:
- Objects/stringobject.c and Objects/unicodeobject.c contain changes to handle the EMX runtime library returning "0x" as the prefix for output formatted with a "%X" format.
I'd suggest a different approach here, which does not use #ifdefs: Instead of testing for the system, test for the bug. Then, if the bug goes away, or appears on other systems as well, the code will be good.
I did it the way I did because there's already code dealing with other brokeness in this area which doesn't solve the EMX issue, and the #ifdef solution minimises the risk of EMX fixes breaking something else which I can't test. At this stage I can't see this bug being fixed in EMX :-(
I'd go with Martin's suggestion here: there already is code in formatint() which tests for '%#X' adding '0x' or not. This code should be made to handle the special case by testing for it -- who knows: there may be other platforms where this doesn't work as expected either.
There are sure to be other platforms that have this bogosity. I'll look into this some more.
BTW, could you point me to your patch for this ?
The Objects patch in patch #450267, at http://sf.net/tracker/?func=detail&atid=305470&aid=450267&group_id=5470 -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au | Snail: PO Box 370 andymac@pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia
participants (3)
-
Andrew MacIntyre -
M.-A. Lemburg -
martin＠v.loewis.de