[ python-Bugs-1202946 ] Problem with abs function
Bugs item #1202946, was opened at 2005-05-16 16:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202946&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ric-b (ric-b) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with abs function Initial Comment: On windows version I get : >>> abs(-999) Traceback (most recent call last): File "", line 1, in -toplevel- abs(-999) OverflowError: long too big to convert does not handle new longs. I am using the following work around: t = a - b # calc t = abs(a - b) if t < 0 : t *= -1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202946&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202946 ] Problem with abs function
Bugs item #1202946, was opened at 2005-05-16 11:32 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202946&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ric-b (ric-b) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with abs function Initial Comment: On windows version I get : >>> abs(-999) Traceback (most recent call last): File "", line 1, in -toplevel- abs(-999) OverflowError: long too big to convert does not handle new longs. I am using the following work around: t = a - b # calc t = abs(a - b) if t < 0 : t *= -1 -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-16 12:33 Message: Logged In: YES user_id=80475 That's odd. It works for me: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> abs(-999) 999L -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202946&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-602627 ] pydoc -g dumps core on Solaris 2.8
Bugs item #602627, was opened at 2002-08-30 20:51 Message generated for change (Comment added) made by arkoenig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602627&group_id=5470 Category: Demos and Tools Group: Python 2.2.1 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc -g dumps core on Solaris 2.8 Initial Comment: Python 2.2.1, Solaris 2.8, gcc 3.2, binutils 2.12.1 When I execute "pydoc -g", it pops up a dialog box saying "Starting server" and "Search for", and then dumps core before I have time to type anything. The same problem happens on Solaris 2.7 The traceback: Core was generated by `/usr/gnu/bin/python /usr/gnu/bin/pydoc -g'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libsocket.so.1...done. Loaded symbols for /usr/lib/libsocket.so.1 Reading symbols from /usr/lib/libnsl.so.1...done. Loaded symbols for /usr/lib/libnsl.so.1 Reading symbols from /usr/lib/libdl.so.1...done. Loaded symbols for /usr/lib/libdl.so.1 Reading symbols from /usr/lib/libpthread.so.1...done. Loaded symbols for /usr/lib/libpthread.so.1 Reading symbols from /usr/lib/libthread.so.1...done. Loaded symbols for /usr/lib/libthread.so.1 Reading symbols from /usr/gnu/lib/libreadline.so.4...done. Loaded symbols for /usr/gnu/lib/libreadline.so.4 Reading symbols from /usr/lib/libcurses.so.1...done. Loaded symbols for /usr/lib/libcurses.so.1 Reading symbols from /usr/lib/libcrypt_i.so.1...done. Loaded symbols for /usr/lib/libcrypt_i.so.1 Reading symbols from /usr/gnu/lib/libtk8.3.so...done. Loaded symbols for /usr/gnu/lib/libtk8.3.so Reading symbols from /usr/gnu/lib/libtcl8.3.so...done. Loaded symbols for /usr/gnu/lib/libtcl8.3.so Reading symbols from /usr/lib/libX11.so.4...done. Loaded symbols for /usr/lib/libX11.so.4 Reading symbols from /usr/lib/libm.so.1...done. Loaded symbols for /usr/lib/libm.so.1 Reading symbols from /usr/lib/libc.so.1...done. Loaded symbols for /usr/lib/libc.so.1 Reading symbols from /usr/gnu/lib/libgcc_s.so.1...done. Loaded symbols for /usr/gnu/lib/libgcc_s.so.1 Reading symbols from /usr/lib/libmp.so.2...done. Loaded symbols for /usr/lib/libmp.so.2 Reading symbols from /usr/lib/libgen.so.1...done. Loaded symbols for /usr/lib/libgen.so.1 Reading symbols from /usr/openwin/lib/libXext.so.0...done. Loaded symbols for /usr/openwin/lib/libXext.so.0 Reading symbols from /usr/openwin/lib/libdga.so.1...done. Loaded symbols for /usr/openwin/lib/libdga.so.1 Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done. Loaded symbols for /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1 Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/strop.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/strop.so Reading symbols from /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2...done. Loaded symbols for /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2 Reading symbols from /usr/openwin/lib/locale/common/xlibi18n.so.2...done. Loaded symbols for /usr/openwin/lib/locale/common/xlibi18n.so.2 Reading symbols from /usr/openwin/lib/locale/common/ximlocal.so.2...done. Loaded symbols for /usr/openwin/lib/locale/common/ximlocal.so.2 Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/time.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/time.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/errno.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/errno.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/_socket.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/_socket.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/select.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/select.so #0 0xff0b2be0 in Tk_FreeGC () from /usr/gnu/lib/libtk8.3.so (gdb) bt #0 0xff0b2be0 in Tk_FreeGC () from /usr/gnu/lib/libtk8.3.so #1 0xff0da71c in TkButtonWorldChanged () from /usr/gnu/lib/libtk8.3.so #2 0xff0da66c in ConfigureButton () from /usr/gnu/lib/libtk8.3.so #3 0xff0d9dc8 in ButtonWidgetObjCmd () from /usr/gnu/lib/libtk8.3.so #4 0xfefe0b50 in EvalObjv () from /usr/gnu/lib/libtcl8.3.so #5 0xfefe0c80 in Tcl_EvalObjv () from /usr/gnu/lib/libtcl8.3.so #6 0x0008deb8 in Tkapp_Call (self=0x159c88, args=0x2c60d8) at Modules/_tkinter.c:619 #7 0x00049e28 in fast_cfunction (func=0x159c88, pp_stack=0xfe908780, na=1089160) at Python/ceval.c:3131 #8 0x00047ea0 in eval_frame (f=0x1cc7c0) at Python/ceval.c:2007 #9 0x00048b30 in PyEval_EvalCodeEx (co=0x220340, globals=0x1cc7c0, locals=0x0, args=0x8, argcount=1, kws=0x1c1dd8, kwcount=1, defs=0x1d76ec, defcount=1, closure=0x0) at Python/ceval.c:2585 #10 0x00049f20 in fast_function (func=0x1, pp_stack=0x8, n=1842656, na=1, nk=1) at Python/ceval.c:3161 #11 0x00047de0 in eval_frame (f=0x1c1c80) at Python/ceval.c:2024 #12 0x00048b30 in PyEval_EvalCodeEx (co=0x1983a8, globals=0x1c1c80, locals=0x0
[ python-Bugs-1199947 ] Python 2.4.1 Installer ended prematurely
Bugs item #1199947, was opened at 2005-05-11 09:01 Message generated for change (Comment added) made by tungwaiyip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199947&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.1 Installer ended prematurely Initial Comment: Similar symptom to bug 105470 http://sourceforge.net/tracker/index.php? func=detail&aid=1085208&group_id=5470&atid=105470 Running python-2.4.1.msi with all default setting. It ends quickly with a dialogbox titled "Python 2.4.1 Installer ended prematurely". Same problem running the 2.4 msi. Machine information: Windows XP Professional V2002 SP2 Dell Latitude D600 640MB RAM Symantec Antivirus 9.0.1.1000 (disable it does not help) cscript.exe version 5.6.0.8825 (upgraded from 8820?) The workaround mentioned in 105470 does not help. Running x.vbs gives me 0. Doing regsvr32 c:\windows\system32\scrrun.dll makes no difference. -- >Comment By: Wai Yip Tung (tungwaiyip) Date: 2005-05-16 13:32 Message: Logged In: YES user_id=561546 Problem solved: I copied the msi file to the root directory (e.g. c:\) and launch from there. it works prefectly. I found that not only Python installer gave me problem, any msi installer gave me problem on this machine. Then I found the clue from Ultramon's FAQ: http://www.realtimesoft.com/ultramon/support.asp#2 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199947&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1175396 ] codecs.readline sometimes removes newline chars
Bugs item #1175396, was opened at 2005-04-02 17:14 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175396&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Walter Dörwald (doerwalter) Summary: codecs.readline sometimes removes newline chars Initial Comment: In Python 2.4.1 i observed a new bug in codecs.readline, it seems that with certain inputs it removes newline characters from the end of the line Probably related to bug #1076985 (Incorrect behaviour of StreamReader.readline leads to crash) and bug #1098990 codec readline() splits lines apart (both with status closed) so I'm assigning this to Walter. See the attached files that demonstrate the problem. Reproduced with Python 2.4.1 on windows XP and on Linux. The problem does not occur with Python 2.4. (btw, it seems bug #1076985 was fixed in python 2.4.1, but the other one (#1098990) not? ) -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-05-16 16:20 Message: Logged In: YES user_id=89016 > > 1) How do we handle the problem of a truncated line, if the > > data comes from the charbuffer instead of being read from > > > the stream? > > > > My suggestion is to make the top of the loop look like: > > > > while True: > > havecharbuffer = bool(self.charbuffer) > > > > And then the break condition (when no line break found) > > should be: > > > > # we didn't get anything or this was our only try > > if not data or (size is not None and not havecharbuffer): > > > > (too many negatives in that). Anyway, the idea is that, if > > size specified, there will be at most one read of the > > underlying stream (using the size). So if you enter the > > loop with a charbuffer, and that charbuffer does not have a > > line break, then you redo the loop once (the second time it > > will break, because havecharbuffer will be False). This makes sense. However, with the current state of the tokenizer this might be to dangerous, because the resulting line might be twice as long. So fixing the tokenizer should be the first step. BTW, your patch fixes the problems with the fix for #1178484, so I think I'm going to apply the patch in the next days, if there are no objections. > > Also, not sure about this, but should the size parameter > > default to -1 (to keep it in sync with read)? None seems to be a better default from an API viewpoint, but -1 is better for "C compatibility". > > As to issue 2, it looks like it should be possible to get > > the line number right, because the UnicodeDecodeError > > exception object has all the necessary information in it > > (including the original string). I think this should be > > done by fp_readl (in tokenizer.c). The patch for #1178484 fixes this. Combined with this patch I think we're in good shape. > > By the way, using a findlinebreak function (using sre) turns > > out to be slower than splitting/joining when no size is > > specified (which I assume will be the overwhelmingly most > > common case), so that turned out to be a bad idea on my part. Coding this on the C level and using Py_UNICODE_ISLINEBREAK() should be the fastest version, but I don't know if this is worth it. -- Comment By: Greg Chapman (glchapman) Date: 2005-04-23 18:46 Message: Logged In: YES user_id=86307 > 1) How do we handle the problem of a truncated line, if the > data comes from the charbuffer instead of being read from > the stream? My suggestion is to make the top of the loop look like: while True: havecharbuffer = bool(self.charbuffer) And then the break condition (when no line break found) should be: # we didn't get anything or this was our only try if not data or (size is not None and not havecharbuffer): (too many negatives in that). Anyway, the idea is that, if size specified, there will be at most one read of the underlying stream (using the size). So if you enter the loop with a charbuffer, and that charbuffer does not have a line break, then you redo the loop once (the second time it will break, because havecharbuffer will be False). Also, not sure about this, but should the size parameter default to -1 (to keep it in sync with read)? As to issue 2, it looks like it should be possible to get the line number right, because the UnicodeDecodeError exception object has all the necessary information in it (including the original string). I think this should be done by fp_readl (in tokenizer.c). By the way, using a findlinebreak function (using sre) turns out to be slower than splitting/joining when no size is specified (which I assume will be the overwhelmingly most common case), so that turned out to be a bad idea on my part.
[ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1
Bugs item #1178484, was opened at 2005-04-07 14:33 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Timo Linna (tilinna) >Assigned to: Martin v. Löwis (loewis) Summary: Erroneous line number error in Py2.4.1 Initial Comment: For some reason Python 2.3.5 reports the error in the following program correctly: File "C:\Temp\problem.py", line 7 SyntaxError: unknown decode error ..whereas Python 2.4.1 reports an invalid line number: File "C:\Temp\problem.py", line 2 SyntaxError: unknown decode error - problem.py starts - # -*- coding: ascii -*- """ Foo bar """ # Ä is not allowed in ascii coding - problem.py ends - Without the encoding declaration both Python versions report the usual deprecation warning (just like they should be doing). My environment: Windows 2000 + SP3. -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-05-16 10:35 Message: Logged In: YES user_id=89016 OK, here is a patch. It adds an additional argument firstline to read(). If this argument is true (i.e. if called from readline()) and a decoding error happens, this error will only be reported if it is in the first line. Otherwise read() will decode up to the error position and put the rest in the bytebuffer. Unfortunately with this patch, I get a segfault with the following stacktrace if I run the test. I don't know if this is related to bug #1089395/patch #1101726. Martin, can you take a look? #0 0x08057ad1 in tok_nextc (tok=0x81ca7b0) at tokenizer.c:719 #1 0x08058558 in tok_get (tok=0x81ca7b0, p_start=0xb3d4, p_end=0xb3d0) at tokenizer.c:1075 #2 0x08059331 in PyTokenizer_Get (tok=0x81ca7b0, p_start=0xb3d4, p_end=0xb3d0) at tokenizer.c:1466 #3 0x080561b1 in parsetok (tok=0x81ca7b0, g=0x8167980, start=257, err_ret=0xb440, flags=0) at parsetok.c:125 #4 0x0805613c in PyParser_ParseFileFlags (fp=0x816bdb8, filename=0xb7b7 "./bug.py", g=0x8167980, start=257, ps1=0x0, ps2=0x0, err_ret=0xb440, flags=0) at parsetok.c:90 #5 0x080f3926 in PyParser_SimpleParseFileFlags (fp=0x816bdb8, filename=0xb7b7 "./bug.py", start=257, flags=0) at pythonrun.c:1345 #6 0x080f352b in PyRun_FileExFlags (fp=0x816bdb8, filename=0xb7b7 "./bug.py", start=257, globals=0xb7d62e94, locals=0xb7d62e94, closeit=1, flags=0xb544) at pythonrun.c:1239 #7 0x080f22f2 in PyRun_SimpleFileExFlags (fp=0x816bdb8, filename=0xb7b7 "./bug.py", closeit=1, flags=0xb544) at pythonrun.c:860 #8 0x080f1b16 in PyRun_AnyFileExFlags (fp=0x816bdb8, filename=0xb7b7 "./bug.py", closeit=1, flags=0xb544) at pythonrun.c:664 #9 0x08055e45 in Py_Main (argc=2, argv=0xb5f4) at main.c:484 #10 0x08055366 in main (argc=2, argv=0xb5f4) at python.c:23 -- Comment By: Walter Dörwald (doerwalter) Date: 2005-04-07 16:28 Message: Logged In: YES user_id=89016 The reason for this is the new codec buffering code in 2.4: The codec might read and decode more data from the byte stream than is neccessary for decoding one line. I.e. when reading line n, the codec might decode bytes that belong to line n+1, n+2 etc. too. If there's a decoding error in this data, line n gets reported. I don't think there's a simple fix for this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1183585 ] try to open /dev/null as directory
Bugs item #1183585, was opened at 2005-04-15 01:56
Message generated for change (Comment added) made by isandler
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183585&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Roberto A. Foglietta (robang)
Assigned to: Nobody/Anonymous (nobody)
Summary: try to open /dev/null as directory
Initial Comment:
bash-2.05b# strace python 2>&1 | grep open | grep null
open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1
ENOTDIR (Not a directory)
--
Comment By: Ilya Sandler (isandler)
Date: 2005-05-16 22:02
Message:
Logged In: YES
user_id=971153
2 questions though:
1. Does this cause any problems?
2. I observe exactly the same behaviour for ls! (I'm on
Debian, kernel 2.4.25)
bagira:~> strace ls | & grep open | grep null
open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1
ENOTDIR (Not a directory)
and for du:
bagira:~> strace du /etc | & grep open |grep null
open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1
ENOTDIR (Not a directory)
So, I'm almost ready to say that even if it's a bug, it's
not a python's bug... (Search for /dev/null in python source
also does not find anything interesting)..
--
Comment By: Roberto A. Foglietta (robang)
Date: 2005-04-20 11:02
Message:
Logged In: YES
user_id=36141
I downloaded the python-2.4.1 sources and compiled under
slack 10 and Mandrake 10.1 and in both case it tried to open
/dev/null as a directory.
Some debian users reported me the same behaviure.
[EMAIL PROTECTED] roberto]$ uname -ar
Linux wsraf.sad.it 2.6.8.1-24mdksmp #1 SMP Thu Jan 13
23:11:43 MST 2005 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz
unknown GNU/Linux
--
Comment By: Georg Brandl (gbrandl)
Date: 2005-04-16 00:54
Message:
Logged In: YES
user_id=849994
I don't quite understand what you're trying to tell us here.
Are you just calling Python this way and observing the
system calls? Then, what system do you use? What version?
What kernel, etc.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183585&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
