Issue416901
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2001-04-18 00:42 by valaulmo, last changed 2022-04-10 16:03 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
config.tar.bz2 | valaulmo, 2001-04-18 00:42 | config.* (config.status, config.cache, etc.) |
Messages (5) | |||
---|---|---|---|
msg4318 - (view) | Author: Brad Allen (valaulmo) | Date: 2001-04-18 00:42 | |
I am doing a survey of current distributed information systems, to see if they are close to what they should be (I figured out what they should be in 1984), and am forced to find a Python which Mojo Nation is compatible with. I will probably go back to Python 2.0, but since the latest released version (released today!) was 2.1, I just started there (since the stable one for OpenBSD 2.8 was way back at Python 1.6 and I figured anything past that was experimenting anyway). --- Python 2.1 on OpenBSD 2.8 with Pentium I: I'm getting these warnings while compiling Python 2.1 on OpenBSD 2.8: cc -o python \ Modules/python.o \ libpython2.1.a -lc_r -lutil -L/usr/local/lib -lz -lm ./Modules/posixmodule.c:2995: warning: this program uses setreuid(), which is deprecated. ./Modules/posixmodule.c:3014: warning: this program uses setregid(), which is deprecated. ./Modules/posixmodule.c:4147: warning: tempnam() possibly used unsafely; consider using mkstemp() ./Modules/posixmodule.c:4193: warning: tmpnam() possibly used unsafely; consider using mkstemp() ld: libpython2.1.a(fileobject.o): RRS text relocation at 0x31168 for "_flockfile" ld: libpython2.1.a(fileobject.o): RRS text relocation at 0x311af for "_funlockfile" PYTHONPATH= ./python ./setup.py build running build Please consider fixing those things. --- *** HUNG test_bufio.py When running tests as "MAKE=gmake gmake test", it hung under test_bufio. It required a SIGKILL to stop. I tried two things: * Running test as README says manually with "python ...". python ./Lib/test/test_bufio.py This worked OK and produced no output that I was aware of (unless it was hidden). * Tried defining DONT_USE_FGETS_IN_GETLINE in the file where it was looked at (./Objects/fileobject.c). This did not help; it still hung. Running the test manually again at this point worked also. So, I had to find a way to skip that test (hid it in a subdirectory called HIDE). *** HUNG test_complex.py The same thing happened with test_complex.py: it hung during "...make test", but ran OK manually; then I hid it to skip. For test_dl, I got slightly different results; after the usual hanging, I then manually ran it and got: *** HUNG test_dl.py* Q:/usr/local/src/python/Python-2.1:2148$ python Lib/test/test_dl.py Traceback (most recent call last): File "Lib/test/test_dl.py", line 6, in ? import dl ImportError: No module named dl Q:/usr/local/src/python/Python-2.1:2149$ In each case, lots of CPU by the "python" process was used as its "hung" state. I waited approximately three minutes of CPU. A 133Megahertz Pentium with a CPU cache on a Dell computer is extremely fast, and ought to finish any test within two minutes. Tell me if I just failed to wait long enough for an increadibly inefficiently programmed test to complete, and I'll retry it. The fact that it did not respond to signals except KILL also indicates to me that it was comotose. (This discussion reminds me of a date where the person told me that the commands in Unix are very violent sounding and the names of the principles used by programmers are very anti-social. I'm glad someone thinks that way, since English itself is far, far worse, according to http://www.islandnet.com/~edonon/decoding.htm, and I said to myself "how can anybody use this language?" in disgust. Someday we'll fix that, too (and not just for historical politeness; for pureness of utility and efficiency -- snowballed efficiency!).) --- *** MEMORY FAULT test_fork1.py While the tests were running "test_fork1", I got a Memory Fault. Rerunning it manually worked, though, and I hid it also. (I did not test rerunning it.) While waiting for all these tests to hang, I got tired of it and now I want to request that you have all the tests run in parallel. That way, it is easier to weed out all the hanging ones in one shot. This is easy, right? *** HUNG test_compile.py Next to hang was this one: $ python ./Lib/test/test_compile.py Running tests on argument handling testing complex args 1 2 1 2 3 4 1 2 3 1 2 3 2 3 4 $ As you can see, it ran OK manually, and this time I had some output to look at. While looking at it I realized that I do not know if those are the expected results, and in the house I'm in, I have to listen to too much hollaring to be able to learn Python in a few minutes like I am usually able to do in proper environments. *** HUNG test_doctest.py test_doctest.py passed manually but automatically hung, too. It had too much output to include it all, but the last line said the test passed. *** HUNG & SEGFAULT test_threadedtempfile.py For test_threadedtempfile, I got a bad error: $ python Lib/test/test_threadedtempfile.py Creating Starting Reaping Segmentation fault (core dumped) $ rm *core $ python Lib/test/test_threadedtempfile.py Creating Starting Reaping ^C^C^C^Z ^Z^X^C Killed $ $ jobs [1]- Stopped less README [2]+ Stopped MAKE=gmake gmake test $ sync $ rm Lib/test/test_threadedt So far, a few tests ran better the second time than the first. Is the compiling working better than the interpreting? --- Brad Allen <Ulmo@Q.Net> * |
|||
msg4319 - (view) | Author: Fred Drake (fdrake) | Date: 2001-07-11 18:29 | |
Logged In: YES user_id=3066 The warnings are irrelevant -- any package that wraps those functions to make them available to applications will cause those warnings on OpenBSD, even if they are never used. The other issues require more attention than I can spare this week, so I'll leave this open. |
|||
msg4320 - (view) | Author: Fred Drake (fdrake) | Date: 2001-07-17 15:22 | |
Logged In: YES user_id=3066 I'm looking into getting access to an OpenBSD machine to test on. The last comment in the bug report makes me wonder a bit, however: did you wait for long to see if the tests terminated? Many of the tests will appear to run faster during the second phase of the test since the test modules will have already been byte-compiled, but the byte-code used to execute the tests will be the same during both phases. |
|||
msg4321 - (view) | Author: Fred Drake (fdrake) | Date: 2001-08-02 03:21 | |
Logged In: YES user_id=3066 --sigh-- Still having problems getting access on an OpenBSD machine. Appearantly one has been set up at my employers main office, but I can't get to it from the PythonLabs office yet. ;-( No, I'm not ignoring this, but the priority isn't high given that I can't get to a usable installation. (It would be great if SourceForge could provide one on the compile farm, or if their FreeBSD machine actually responded.) |
|||
msg4322 - (view) | Author: Fred Drake (fdrake) | Date: 2001-09-11 20:01 | |
Logged In: YES user_id=3066 Not able to reproduce this, and there are no corroborating reports. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:03:58 | admin | set | github: 34357 |
2001-04-18 00:42:05 | valaulmo | create |