]> git.ipfire.org Git - thirdparty/Python/cpython.git/commitdiff
Put Cray fixes on the branch, too.
authorMichael W. Hudson <mwh@python.net>
Wed, 31 Jul 2002 11:19:49 +0000 (11:19 +0000)
committerMichael W. Hudson <mwh@python.net>
Wed, 31 Jul 2002 11:19:49 +0000 (11:19 +0000)
Modules/_sre.c
Modules/md5.h
README

index 769965f51a96d23914d43fec9e457b9767dfad48..78563093875ade73d5ea8794e87e92bf13958370 100644 (file)
@@ -1788,7 +1788,7 @@ deepcopy(PyObject** object, PyObject* memo)
 #endif
 
 static PyObject*
-join(PyObject* list, PyObject* pattern)
+join_list(PyObject* list, PyObject* pattern)
 {
     /* join list elements */
 
@@ -2241,7 +2241,7 @@ next:
     Py_DECREF(filter);
 
     /* convert list to single string (also removes list) */
-    item = join(list, self->pattern);
+    item = join_list(list, self->pattern);
 
     if (!item)
         return NULL;
index e169f779fab465e5bc0ae0b9d71b9c8cac314cb8..13628dfbc3f657d3fa19a53ac9643233476328d8 100644 (file)
@@ -30,17 +30,15 @@ documentation and/or software.
 /* POINTER defines a generic pointer type */
 typedef unsigned char *POINTER;
 
-/* UINT2 defines a two byte word */
-typedef unsigned short int UINT2;
-
 /* UINT4 defines a four byte word */
 #if SIZEOF_LONG == 4
 typedef unsigned long int UINT4;
-#else
-#if INT_MAX == 2147483647
+#elif SIZEOF_SHORT == 4
+typedef unsigned short int UINT4;
+#elif INT_MAX == 2147483647
 typedef unsigned int UINT4;
-#endif
-/* Too bad if neither is; pyport.h would need to be fixed. */
+#else
+#error "Can't find a 4-byte integral type"
 #endif
 
 /* ========== End global.h; continue md5.h ========== */
diff --git a/README b/README
index 748a1609f51a907511fc268c5e9288ba43e95148..4c6f889d06c8e71239d4ab0bddfe8d920c3b3fb7 100644 (file)
--- a/README
+++ b/README
@@ -369,15 +369,47 @@ BeOS:     Chris Herborth (chrish@qnx.com) writes:
        BeOS R3 or later.  Note that only the PowerPC platform is
        supported for R3; both PowerPC and x86 are supported for R4.
 
-Cray T3E: Konrad Hinsen writes:
-       1) Don't use gcc. It compiles Python/graminit.c into something
-          that the Cray assembler doesn't like. Cray's cc seems to work
-          fine.
-       2) Comment out modules md5 (won't compile) and audioop (will
-          crash the interpreter during the test suite).
-       If you run the test suite, two tests will fail (rotate and
-       binascii), but these are not the modules you'd expect to need
-       on a Cray.
+Cray T3E: Mark Hadfield (m.hadfield@niwa.co.nz) writes:
+       Python can be built satisfactorily on a Cray T3E but based on
+       my experience with the NIWA T3E (2002-05-22, version 2.2.1)
+       there are a few bugs and gotchas. For more information see a
+       thread on comp.lang.python in May 2002 entitled "Building
+       Python on Cray T3E".
+
+        1) Use Cray's cc and not gcc. The latter was reported not to
+           work by Konrad Hinsen. It may work now, but it may not.
+
+        2) To set sys.platform to something sensible, pass the
+           following environment variable to the configure script:
+
+             MACHDEP=unicosmk
+
+       2) Run configure with option "--enable-unicode=ucs4".
+
+       3) The Cray T3E does not support dynamic linking, so extension
+          modules have to be built by adding (or uncommenting) lines
+          in Modules/Setup. The minimum set of modules is
+
+            posix, new, _sre, unicodedata
+
+          On NIWA's vanilla T3E system the following have also been
+          included successfully:
+
+            _codecs, _locale, _socket, _symtable, _testcapi, _weakref
+            array, binascii, cmath, cPickle, crypt, cStringIO, dbm
+            errno, fcntl, grp, math, md5, operator, parser, pcre, pwd
+            regex, rotor, select, struct, strop, syslog, termios
+            time, timing, xreadlines
+
+       4) Once the python executable and library have been built, make
+          will execute setup.py, which will attempt to build remaining
+          extensions and link them dynamically. Each of these attempts
+          will fail but should not halt the make process. This is
+          normal.
+
+       5) Running "make test" uses a lot of resources and causes
+          problems on our system. You might want to try running tests
+          singly or in small groups.
 
 SGI:   SGI's standard "make" utility (/bin/make or /usr/bin/make)
        does not check whether a command actually changed the file it