From noreply@sourceforge.net  Fri Sep  1 00:04:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Aug 2000 16:04:39 -0700
Subject: [Python-bugs-list] [Bug #112468] sre/pre bug
Message-ID: <200008312304.QAA16658@delerium.i.sourceforge.net>

Bug #112468, was updated on 2000-Aug-21 22:05
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: sre/pre bug

Details: Compiling the simple pattern '(' with pre raises an exception while sre compiles it sucessfully. Further, the regex object that sre.compile returns will match any string.

Using Python 1.6b1 (#0, Aug  7 2000, 12:30:24) [MSC 32 bit (Intel)] on win32,

  >>> import sre
  >>> regex_ = sre.compile('(')
  >>> regex_.pattern
  '('
  >>> regex_.search('abc').group(0)
  ''

while

  >>> import pre
  >>> regex_ = pre.compile('(')
  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    File "C:\Python16\lib\pre.py", line 243, in compile
      code=pcre_compile(pattern, flags, groupindex)
  pcre.error: ('missing )', 1)



Follow-Ups:

Date: 2000-Aug-22 05:34
By: gvanrossum

Comment:
According to Fredrik, this is a minor parsing bug in SRE.
He'll fix it.
-------------------------------------------------------

Date: 2000-Aug-25 07:42
By: jhylton

Comment:
Bumping priority so its gets fixed before release.

-------------------------------------------------------

Date: 2000-Aug-31 08:24
By: effbot

Comment:
note: for some reason, the RE test harness ignores syntax errors under certain conditions.  ...and it has done so all the time, so this is just one of many cases where SRE is more tolerant than PCRE.  sigh :-(
-------------------------------------------------------

Date: 2000-Aug-31 16:04
By: effbot

Comment:
done.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112468&group_id=5470


From noreply@sourceforge.net  Fri Sep  1 01:54:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Aug 2000 17:54:44 -0700
Subject: [Python-bugs-list] [Bug #111403] 1.6b1 dumps core dereferencing a NULL tstate
Message-ID: <200009010054.RAA25959@bush.i.sourceforge.net>

Bug #111403, was updated on 2000-Aug-08 11:26
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: 1.6b1 dumps core dereferencing a NULL tstate

Details: 
  This is from an embeded python.  I've not yet been
able to reproduce this with a small example.  But
perhaps this stacktrace will be of some help.  The
problem seems to be that eval_code2() calls PyThreadState_GET() and gets a NULL pointer back.
This pointer is dereferenced in PyFrame_New() later
on which causes the core dump.  The documentation
seems to say that PyThreadState_GET() should never
return NULL.  So, there must be a bug in there
somewhere.  Here is the stack trace:

#0  0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, 
    locals=0x0) at frameobject.c:120
120             PyFrameObject *back = tstate->frame;
(gdb) bt
#0  0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, 
    locals=0x0) at frameobject.c:120
#1  0x866b022 in eval_code2 (co=0x90fff70, globals=0x9284378, locals=0x0, 
    args=0x8eb362c, argcount=5, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
    owner=0x925d2e8) at ceval.c:397
#2  0x866e4ee in call_function (func=0x911aca0, arg=0x95ea3b0, kw=0x0)
    at ceval.c:2521
#3  0x866e09d in PyEval_CallObjectWithKeywords (func=0x95f7a60, arg=0x95ea3b0, 
    kw=0x0) at ceval.c:2359
#4  0x863f6cf in PyObject_CallObject (o=0x95f7a60, a=0x95ea3b0)
    at abstract.c:1370
#5  0x83e56ed in DrawingArea::process (this=0x95f5f48, event=@0xbfffeb80)
    at DrawingArea.C:971
#6  0x83e5b3d in DrawingArea::dspCB (this=0x95e0b68) at DrawingArea.C:1027
#7  0x832050f in TkFDWatcher::callback (data=0x95e2048) at TkFDWatcher.C:169
#8  0x8752612 in FileHandlerEventProc (evPtr=0x935a4d8, flags=-1)
    at ./tclUnixNotfy.c:405
#9  0x8741d10 in Tcl_ServiceEvent (flags=-1) at ./../generic/tclNotify.c:444
#10 0x8741fae in Tcl_DoOneEvent (flags=2) at ./../generic/tclNotify.c:747
#11 0x86a8757 in Tkapp_MainLoop (self=0x8f6a178, args=0x8eb6af0)
    at ./_tkinter.c:1794
#12 0x866e19e in call_builtin (func=0x8f7b7f0, arg=0x8eb6af0, kw=0x0)
    at ceval.c:2396
#13 0x866e0ab in PyEval_CallObjectWithKeywords (func=0x8f7b7f0, arg=0x8eb6af0, 
    kw=0x0) at ceval.c:2361
#14 0x866d0cb in eval_code2 (co=0x8fb2d18, globals=0x903b9f8, locals=0x0, 
    args=0x8f277b4, argcount=0, kws=0x8f277b4, kwcount=0, defs=0x90447c4, 
    defcount=1, owner=0x0) at ceval.c:1680
#15 0x866cdda in eval_code2 (co=0x8f28b10, globals=0x8f294d0, locals=0x0, 
    args=0x8f27600, argcount=1, kws=0x8f27604, kwcount=0, defs=0x0, 
    defcount=0, owner=0x92c6238) at ceval.c:1579
#16 0x866cdda in eval_code2 (co=0x8f5b300, globals=0x8f294d0, locals=0x0, 
    args=0x8eb8600, argcount=0, kws=0x8eb8600, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1579
#17 0x866cdda in eval_code2 (co=0x8f27ae0, globals=0x8eb0038, 
    locals=0x8eb0038, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1579
#18 0x866afc8 in PyEval_EvalCode (co=0x8f27ae0, globals=0x8eb0038, 
    locals=0x8eb0038) at ceval.c:290
#19 0x867d7c7 in run_node (n=0x8f1d0e0, filename=0x89fcacf "<string>", 
    globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:885
#20 0x867d777 in run_err_node (n=0x8f1d0e0, filename=0x89fcacf "<string>", 
    globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:870
#21 0x867d719 in PyRun_String (str=0x8f1ca68 "import GFE; GFE.main()\n", 
    start=257, globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:847
#22 0x867ce4e in PyRun_SimpleString (
    command=0x8f1ca68 "import GFE; GFE.main()\n") at pythonrun.c:589
#23 0x8681c51 in Py_Main (argc=4, argv=0xbffff204) at main.c:248
#24 0x80d90e1 in main (argc=4, argv=0xbffff204) at main.C:30

Mike Romberg (romberg@fsl.noaa.gov)


Follow-Ups:

Date: 2000-Aug-10 10:23
By: none

Comment:
Followup:  This only happens when python is built
--with-threads.  There appears to be no problem when
threads are not enabled.  It should be noted that our
embeded application uses no threads of any kind (python or
pthreads from C++).  But it may be the case that our code
(C++) is not doing the right thing.

  It should be noted that our application works fine
with python-1.5.2 compiled --with-threads.

-------------------------------------------------------

Date: 2000-Aug-25 07:37
By: jhylton

Comment:
Mike -- Can you provide any more information about this bug?

-------------------------------------------------------

Date: 2000-Aug-25 09:59
By: romberg

Comment:
  My guess (and this is just a guess) is that this may have something
to do with the interaction of python threads and Tkinter.  Since most of
our embeded (and non threaded) python application works fine except
for one specific area, maybe that is thre problem with python 1.6.  Let me
attempt to explain what is going on since it may take some work to
produce a small test case to reproduce the problem.

  Our application uses Tkinter for most of the UI.  We do open a second
connection to the X server using Xlib.  This connection is used to
render complex images into windows.  Tkinter's canvas is just not fast
enough.  I am getting X events from these Xlib created windows via
the Tcl/Tk FileEventHandler (as seen on the stack trace).  I am using the
Tcl/Tk C API to register for these events.

  The case which seems to cause the crash in python comes when I get
a ButtonDown event on my second (non Tkinter) Display.  This event
is delivered from Tcl/Tk to some of our C++ code.  Now for the interesting
bit which I suspect might cause the problem.

  Our C++ code then releases the grab and calls into the python interpreter
for it to post a popup menu (using Tkinter).  This is seen on the stack
as the most recent PyObject_CallObject().  This code attempts to post
the Tkinter popuip menu but dies trying.

  This works fine under python-1.5.2 when it is built --with-thread and
without.  It works fine with python-1.6b2 as long as python is built
without threads.  But when it is built with threads I get this crash.  Is it possible that the Tkinter layer is doing something different threadwise
when python is built --with-threads?
-------------------------------------------------------

Date: 2000-Aug-28 11:28
By: none

Comment:
Another followup.  I've compiled python-1.6b1 on HP-UX-10.20 and
linked the whole thing with purify.  Purify does not show any errors
and everything runs fine when python is built --without-thread.  I was
unable to get python to build on HP-UX --with-thread.  I suspect that
this might have something to do with the DCE threads HPUX uses.

  But in any case.  The extra code linked into our embeded interpreter, is
not doing anything funny with pointers (as far as purify could find).

Mike (romberg@fsl.noaa.gov)

-------------------------------------------------------

Date: 2000-Aug-30 10:46
By: gvanrossum

Comment:
Looks like just another example of HP-UX build problems. (esp. w. threads?)
-------------------------------------------------------

Date: 2000-Aug-30 10:56
By: none

Comment:
  Yea.  I'm not really interested in the HP platform for use with
threads (they are a mess).  I was just using it because that is the
only platform I have access to which can run purify.

  The real problem is under linux (redhat-6.2) when threads are
enabled.  I just wanted to make sure that there were not any funny
memory problems caused by the python extensions we have
added to our embeded python.

  Purify (on HPUX-10.20) seems to give a clean bill of health.  So, I'm
guessing that whattever is causing the core dump under linux is
specific to the thread support in python.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=111403&group_id=5470


From noreply@sourceforge.net  Fri Sep  1 04:41:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Aug 2000 20:41:47 -0700
Subject: [Python-bugs-list] [Bug #110650] python with-threads core-dumps (PR#342)
Message-ID: <200009010341.UAA26038@delerium.i.sourceforge.net>

Bug #110650, was updated on 2000-Jul-31 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: python with-threads core-dumps (PR#342)

Details: Jitterbug-Id: 342
Submitted-By: michael.exner@mrz.uni-magdeburg.de
Date: Wed, 31 May 2000 09:43:38 -0400 (EDT)
Version: 1.5.2
OS: hpux-11.00


When I compile python with threads python core-dumps:
$ ./python
pthread_mutex_init: Invalid argument
Memory fault(coredump)
without thread-support everything works fine
I tried this with hpux-ansi-c and with gcc (2.95.2) but got the same result




====================================================================
Audit trail:
Tue Jul 11 08:25:57 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-28 20:43
By: tim_one

Comment:
Note that the only call to pthread_mutex_init Python makes is in function PyThread_allocate_lock in file phread_pthread.h.  If Python compiled at all, it's extremely unlikely that the first argument is in error.  It's very likely that the second argument is in error, though:  there were many imcompatible revisions of the pthreads std, and pthread_mutexattr_default is a macro conditionally defined near the top of the file.  If this OS actually support pthreads, you have to figure out which *version* of pthreads it defines and arrange for config to define the *correct* one of the

PY_PTHREAD_D4
PY_PTHREAD_D7
PY_PTHREAD_STD
PY_PTHREAD_D6

symbols for your platform.  Else disable threads entirely.
-------------------------------------------------------

Date: 2000-Aug-29 07:34
By: memaul

Comment:
Goto link below for instructions and patches for building
python 152 with threads on hpux 10.20

http://memaul.tripod.com/index.html
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110650&group_id=5470


From noreply@sourceforge.net  Fri Sep  1 04:42:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Aug 2000 20:42:26 -0700
Subject: [Python-bugs-list] [Bug #112289] NetBSD1.4.2 build issue
Message-ID: <200009010342.UAA26062@delerium.i.sourceforge.net>

Bug #112289, was updated on 2000-Aug-18 19:50
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: NetBSD1.4.2 build issue

Details: the recent fileobjects.c work done for large files (tmick) appears
broken when compiled against NetBSD1.4.2.

During the final link, you get the following output:

gcc   python.o  ../libpython2.0.a   -lutil -lm  -o python
fileobject.c:280: Undefined symbol `_TELL64' referenced from text segment

Follow-Ups:

Date: 2000-Aug-18 19:55
By: none

Comment:
NOTE:  I didn't include the configure output.  If that
would be helpful, go ahead and indicate that in this
tracking system.

If tmick (or whoever) would like me to contact them directly,
I would happily do so.
-------------------------------------------------------

Date: 2000-Aug-31 08:45
By: tmick

Comment:
Sent to python-dev:

1. Who reported this bug? He talked about providing more information and I
would like to speak with him. I cannot find his email address.
2. Does anybody have a NetBSD1.4.2 (or close) machine that I can get shell
access to? Do you know if they have such a machine at SourceForge that users
can get shell access to? Or failing that can someone with such a machine give
me the full ./configure and make output and maybe run this command:
   find /usr/include -name "*" -type f | xargs -l grep -nH _TELL64
and give me the output.


-------------------------------------------------------

Date: 2000-Aug-31 08:47
By: tmick

Comment:
I got no reponse and I have no NetBSD machine on which to reproduce so, as Jeremy suggested, if I wouldn't get it by this evening then assign back to him.

Other questions:
- How old/recent is version 1.4.2 of NetBSD?
- Where is _TELL64 coming from? Not from Python code.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470


From noreply@sourceforge.net  Fri Sep  1 04:42:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Aug 2000 20:42:48 -0700
Subject: [Python-bugs-list] [Bug #113037] auotconf/build problems on HP-UX
Message-ID: <200009010342.UAA26066@delerium.i.sourceforge.net>

Bug #113037, was updated on 2000-Aug-29 06:57
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: auotconf/build problems on HP-UX

Details: From: Mike Romberg <romberg@fsl.noaa.gov>
To: jeremy@beopen.com
Subject: Fwd: [Bug #111319] Autoconfig breakdown with gnu libc-2.1.3 (noreply@sourceforge.net)
Date: Mon, 28 Aug 2000 11:49:48 -0600 (MDT)

>>>>> " " == Jeremy Hylton <jeremy@beopen.com> writes:

     > Mike, I can't reproduce the bug you report.  Can you check
     > against the current CVS and see if it still has the problem?
     > It may be that the bug has been fixed since you reported it.

  Here is a followup.  Using the CVS tree from last friday, this is
what I get:

  1 - Default install seems to enable threads and cycle-gc.  This has
      core dumps.

  2 - --without-thread.  Dumps core as well.

  3 - --without-cycle-gc --without-thread.  This has some kind of
      problem with the importer.  It breaks with 'from foo import *'.

  4 - I attempted to build this CVS version on HP-UX so that I might
      run purify with it.  The CVS version did not build on HP-UX.
      The build fails with a 'no rule to make dynload-hpux' (or
      something really close).  I removed this object file from the
      Makefile.  But the build failed later on with undeclared
      functions.  I'm still going to try using purify with
      python-1.6b1 (which did compile on HP-UX).

  So, I tried getting a new CVS version this morning.  This core dumps
right off the bat (compiled with --without-cycle-gc --without-thread).

#0  do_mkvalue (p_format=0xbfffe710, p_va=0xbfffe714) at modsupport.c:353
#1  0x869f0c0 in do_mktuple (p_format=0xbfffe710, p_va=0xbfffe714, endchar=41, 
    n=4) at modsupport.c:223
#2  0x869f189 in do_mkvalue (p_format=0xbfffe710, p_va=0xbfffe714)
    at modsupport.c:247
#3  0x869f430 in Py_VaBuildValue (format=0x8a1d8a2 "(OOOO)", va=0xbfffe744)
    at modsupport.c:415
#4  0x869f3c6 in Py_BuildValue (format=0x8a1d8a2 "(OOOO)") at modsupport.c:390
#5  0x868f1f7 in eval_code2 (co=0x8f4c1b8, globals=0x8f4c288, 
    locals=0x8f4c288, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1630
#6  0x868d3b8 in PyEval_EvalCode (co=0x8f4c1b8, globals=0x8f4c288, 
    locals=0x8f4c288) at ceval.c:313
#7  0x869aaaf in PyImport_ExecCodeModuleEx (name=0xbfffe914 "site", 
    co=0x8f4c1b8, pathname=0x8a203ea "<frozen>") at import.c:497
#8  0x869bb82 in PyImport_ImportFrozenModule (name=0xbfffe914 "site")
    at import.c:1387
#9  0x869b869 in load_module (name=0xbfffeda4 "site", fp=0x0, 
    buf=0xbfffe914 "site", type=7) at import.c:1232
#10 0x869c44c in import_submodule (mod=0x8bfe48c, subname=0xbfffeda4 "site", 
    fullname=0xbfffeda4 "site") at import.c:1727
#11 0x869c00d in load_next (mod=0x8bfe48c, altmod=0x8bfe48c, 
    p_name=0xbffff1b0, buf=0xbfffeda4 "site", p_buflen=0xbfffeda0)
    at import.c:1583
#12 0x869bc83 in import_module_ex (name=0x0, globals=0x0, locals=0x0, 
    fromlist=0x0) at import.c:1434
#13 0x869bdbc in PyImport_ImportModuleEx (name=0x8a216c3 "site", globals=0x0, 
    locals=0x0, fromlist=0x0) at import.c:1475
#14 0x869bc20 in PyImport_ImportModule (name=0x8a216c3 "site") at import.c:1408
#15 0x86a014b in initsite () at pythonrun.c:429
#16 0x869fdca in Py_Initialize () at pythonrun.c:166
#17 0x80dbf4c in main (argc=1, argv=0xbffff2d4) at main.C:22



Follow-Ups:

Date: 2000-Aug-29 09:12
By: jhylton

Comment:
More details from comp.lang.python:

From: Philipp Jocham <philipp.jocham@salomon.at>
Subject: Re: need help with build on HP-UX
Newsgroups: comp.lang.python
Date: Tue, 29 Aug 2000 11:23:25 GMT
Message-ID: <N2Nq5.235$HH4.3438@nreader1.kpnqwest.net>

Python-1.6b1 on HP-UX 11.00 build with gcc-2.8.1

% ./configure --with-threads
[...]
checking for --with-thread... yes
checking for mach/cthreads.h... no
checking for pth_init in -lpth... no
checking for pthread_create in -lpthread... no
checking for pthread_detach... no
checking for kernel/OS.h... no
checking for pthread_create in -lpthreads... no
checking for pthread_create in -lc_r... no
checking for __d6_pthread_create in -lthread... no
checking for pthread_create in -lcma... yes
[...]
% make
% make test

yields

[...]
        PYTHONPATH= ./python -tt ./Lib/test/regrtest.py 
pthread_mutex_init: Invalid argument
sh: 5019 Memory fault(coredump)
*** Error exit code 139 (ignored)
	
I've experienced a similar problem with python-1.5.2
see
http://sourceforge.net/bugs/?group_id=5470&func=detailbug&bug_id=110665

The problem is the same. The function pthread_create is a macro
in sys/pthread.h and pointing to __pthread_create_system. Finally
pthread_create is detected in /usr/lib/libcma.a, which doesn't have
a compatible pthread_mutex_init function.

Hacking the Makefiles (after running configure) by changing
the LIBS= lines from
	LIBS=           -lnet -lnsl -ldld  -lcma
to
	LIBS=           -lnet -lnsl -ldld  -lpthread -lcl

links the object-files against the pthread library. 
This solution has worked for 1.5.2 and runs at least all tests
correctly for 1.6b1

A solution might be to add a test for 
	__pthread_create_system in /usr/lib/libpthread.a 
in the configure.in script.

-------------------------------------------------------

Date: 2000-Aug-29 09:15
By: jhylton

Comment:
Another suggestion from comp.lang.python

From: Michael Maul <mmaul@nortelnetworks.com>
Subject: Re: need help with build on HP-UX
Newsgroups: comp.lang.python
Date: Tue, 29 Aug 2000 10:33:05 -0400
Message-ID: <39ABC9A0.C584B210@nortelnetworks.com>

Goto link below for instructions and patches for building
python 152 with threads on hpux 10.20 with DCE threads

http://memaul.tripod.com/index.html



-------------------------------------------------------

Date: 2000-Aug-30 02:21
By: lemburg

Comment:
> #8  0x869bb82 in PyImport_ImportFrozenModule (name=0xbfffe914 "site")
>     at import.c:1387

Why does Python try to import site as frozen module ? Could
it be that you have frozen site.py using a pre-2.0 Python
version and that this causes the core dump ?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113037&group_id=5470


From noreply@sourceforge.net  Fri Sep  1 04:57:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Aug 2000 20:57:29 -0700
Subject: [Python-bugs-list] [Bug #113254] pre/sre difference breaks pyclbr
Message-ID: <200009010357.UAA26510@delerium.i.sourceforge.net>

Bug #113254, was updated on 2000-Aug-31 12:13
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: pre/sre difference breaks pyclbr

Details: """ 

pre and sre deal differently with groups that
"do not contribute to the match". Fredrick
points out that sre seems to be right but now
pyclbr is broken (though easy to fix). This
program demonstrates the difference in behavior
and the pyclbr breakage.

call it "pyclbrbug.py" The name matters because
it uses itself as a test case!
"""


import pre
import sre
import pyclbr
import sys

the_re=r"""
    (?P<Method>
	^
	(?P<MethodIndent> [ \t]* )
	def [ \t]+
	(?P<MethodName> [a-zA-Z_] \w* )
	[ \t]* \(
    )

|   (?P<Class>
	^
	(?P<ClassIndent> [ \t]* )
	class [ \t]+
	(?P<ClassName> [a-zA-Z_] \w* )
	[ \t]*
	(?P<ClassSupers> \( [^)\n]* \) )?
	[ \t]* :
    )
"""

eg="class foo: pass"

def test( mod ):
	print "===========", mod.__name__
	re=mod.compile(the_re, 
	              mod.VERBOSE | 
                      mod.DOTALL | 
	              mod.MULTILINE)
	match=re.search( eg )
	print match.start( "Method" )
	print match.group( "MethodIndent" )
	sys.modules["re"]=mod
	reload( pyclbr )
	pyclbr.readmodule_ex("pyclbrbug",["."])

test( pre )
test( sre )



Follow-Ups:

Date: 2000-Aug-31 20:57
By: jhylton

Comment:
Who should fix pyclbr?  If not you /F, please reassign.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113254&group_id=5470


From noreply@sourceforge.net  Fri Sep  1 05:05:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Aug 2000 21:05:18 -0700
Subject: [Python-bugs-list] [Bug #113145] config.h defines socklen_t, kills wxPython build
Message-ID: <200009010405.VAA32071@bush.i.sourceforge.net>

Bug #113145, was updated on 2000-Aug-30 12:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: config.h defines socklen_t, kills wxPython build

Details: Building wxPython fails with 1.6  because config.h defines socklen_t; according to a comment, it checks sys/types.h. But /usr/include/bits/socket.h on Linux at least, tries to make a typedef with this name.



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113145&group_id=5470


From noreply@sourceforge.net  Fri Sep  1 06:30:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Aug 2000 22:30:46 -0700
Subject: [Python-bugs-list] [Bug #111499] PyImport_AppendInittab undocument
Message-ID: <200009010530.WAA02384@bush.i.sourceforge.net>

Bug #111499, was updated on 2000-Aug-09 11:27
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: PyImport_AppendInittab undocument

Details: Both PyImport_AppendInittab and PyImport_ExtendInittab should be documented,
but aren't.

Follow-Ups:

Date: 2000-Aug-31 22:30
By: fdrake

Comment:
Documented.  This will be available with the Python 2.0 release; the 2.0b1 documentation package has already been assembled.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=111499&group_id=5470


From noreply@sourceforge.net  Fri Sep  1 09:44:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 1 Sep 2000 01:44:43 -0700
Subject: [Python-bugs-list] [Bug #112628] many extensions (wrongly?) use Py_FatalError
Message-ID: <200009010844.BAA03323@delerium.i.sourceforge.net>

Bug #112628, was updated on 2000-Aug-24 04:50
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: many extensions (wrongly?) use Py_FatalError 

Details: Many of the modules in the current CVS tree are handling errors in a
manner which I find unpythonic. A typical example is pyexpat.c which at
the end of initpyexpat does
    /* Check for errors */
    if (PyErr_Occurred())
        Py_FatalError("can't initialize module pyexpat");

the xml-sig group might regard this as a tragedy, but I might wish to
continue and use another parser. The correct behaviour for this sort of
error ought IMHO to be to raise an ImportError clean up any privately
allocated resources and return.

c sources which raise fatal errors

_cursesmodule.c:
_localemodule.c:
_tkinter.c:
almodule.c:
cdmodule.c:
errnomodule.c:
fcntlmodule.c:
fpectlmodule.c:
linuxaudiodev.c:
main.c:
mathmodule.c:
mpzmodule.c:
parsermodule.c:
pcremodule.c:
posixmodule.c:
puremodule.c:
pyexpat.c:
shamodule.c:
stropmodule.c:
syslogmodule.c:
timemodule.c:
timingmodule.c:

Follow-Ups:

Date: 2000-Aug-24 05:54
By: gvanrossum

Comment:
He's right!  The proper solution is

  if (PyErr_Occurred())
         return;

since the module initialization code explicitly checks for errors raised by the module's init function.

Assigned to Jeremy for pronouncement or delegation.
-------------------------------------------------------

Date: 2000-Aug-24 07:54
By: bwarsaw

Comment:
In that case, the PyErr_Occurred() call is /usually/ not necessary, since it's done as the last thing in the init() function and would just return anyway.  So given Guido's pronouncement, most of those checks can just be removed.
-------------------------------------------------------

Date: 2000-Sep-01 01:44
By: bwarsaw

Comment:
Fixed by removing PyErr_Occurred() checks and Py_FatalError() calls from module init functions.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112628&group_id=5470


From noreply@sourceforge.net  Fri Sep  1 10:01:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 1 Sep 2000 02:01:37 -0700
Subject: [Python-bugs-list] [Bug #112628] many extensions (wrongly?) use Py_FatalError
Message-ID: <200009010901.CAA09135@bush.i.sourceforge.net>

Bug #112628, was updated on 2000-Aug-24 04:50
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: many extensions (wrongly?) use Py_FatalError 

Details: Many of the modules in the current CVS tree are handling errors in a
manner which I find unpythonic. A typical example is pyexpat.c which at
the end of initpyexpat does
    /* Check for errors */
    if (PyErr_Occurred())
        Py_FatalError("can't initialize module pyexpat");

the xml-sig group might regard this as a tragedy, but I might wish to
continue and use another parser. The correct behaviour for this sort of
error ought IMHO to be to raise an ImportError clean up any privately
allocated resources and return.

c sources which raise fatal errors

_cursesmodule.c:
_localemodule.c:
_tkinter.c:
almodule.c:
cdmodule.c:
errnomodule.c:
fcntlmodule.c:
fpectlmodule.c:
linuxaudiodev.c:
main.c:
mathmodule.c:
mpzmodule.c:
parsermodule.c:
pcremodule.c:
posixmodule.c:
puremodule.c:
pyexpat.c:
shamodule.c:
stropmodule.c:
syslogmodule.c:
timemodule.c:
timingmodule.c:

Follow-Ups:

Date: 2000-Aug-24 05:54
By: gvanrossum

Comment:
He's right!  The proper solution is

  if (PyErr_Occurred())
         return;

since the module initialization code explicitly checks for errors raised by the module's init function.

Assigned to Jeremy for pronouncement or delegation.
-------------------------------------------------------

Date: 2000-Aug-24 07:54
By: bwarsaw

Comment:
In that case, the PyErr_Occurred() call is /usually/ not necessary, since it's done as the last thing in the init() function and would just return anyway.  So given Guido's pronouncement, most of those checks can just be removed.
-------------------------------------------------------

Date: 2000-Sep-01 01:44
By: bwarsaw

Comment:
Fixed by removing PyErr_Occurred() checks and Py_FatalError() calls from module init functions.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112628&group_id=5470


From noreply@sourceforge.net  Fri Sep  1 12:18:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 1 Sep 2000 04:18:58 -0700
Subject: [Python-bugs-list] [Bug #113328] Python 1.6b1 build failure on Solaris (with patch)
Message-ID: <200009011118.EAA13809@bush.i.sourceforge.net>

Bug #113328, was updated on 2000-Sep-01 04:18
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python 1.6b1 build failure on Solaris (with patch)

Details: Python 1.6b1 fails to build on Solaris due to Python's
config.h #define'ing socklen_t to be int.  socklen_t is a symbol many platforms' standard include files have a typedef for.

On Solaris, this results in the true typedef for socklen_t in sys/socket.h (one of the following):

typedef size_t          socklen_t;
typedef uint32_t        socklen_t;

being transformed into gibberish that will not compile.

Removing the offending socklen_t #define from config.h allows 1.6b1 to build on Solaris.

See also bugs 111319 and 113145.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113328&group_id=5470


From noreply@sourceforge.net  Fri Sep  1 15:30:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 1 Sep 2000 07:30:22 -0700
Subject: [Python-bugs-list] [Bug #113328] Python 1.6b1 build failure on Solaris (with patch)
Message-ID: <200009011430.HAA15394@delerium.i.sourceforge.net>

Bug #113328, was updated on 2000-Sep-01 04:18
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python 1.6b1 build failure on Solaris (with patch)

Details: Python 1.6b1 fails to build on Solaris due to Python's
config.h #define'ing socklen_t to be int.  socklen_t is a symbol many platforms' standard include files have a typedef for.

On Solaris, this results in the true typedef for socklen_t in sys/socket.h (one of the following):

typedef size_t          socklen_t;
typedef uint32_t        socklen_t;

being transformed into gibberish that will not compile.

Removing the offending socklen_t #define from config.h allows 1.6b1 to build on Solaris.

See also bugs 111319 and 113145.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113328&group_id=5470


From noreply@sourceforge.net  Fri Sep  1 16:07:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 1 Sep 2000 08:07:38 -0700
Subject: [Python-bugs-list] [Bug #113328] Python 1.6b1 build failure on Solaris (with patch)
Message-ID: <200009011507.IAA21918@bush.i.sourceforge.net>

Bug #113328, was updated on 2000-Sep-01 04:18
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python 1.6b1 build failure on Solaris (with patch)

Details: Python 1.6b1 fails to build on Solaris due to Python's
config.h #define'ing socklen_t to be int.  socklen_t is a symbol many platforms' standard include files have a typedef for.

On Solaris, this results in the true typedef for socklen_t in sys/socket.h (one of the following):

typedef size_t          socklen_t;
typedef uint32_t        socklen_t;

being transformed into gibberish that will not compile.

Removing the offending socklen_t #define from config.h allows 1.6b1 to build on Solaris.

See also bugs 111319 and 113145.

Follow-Ups:

Date: 2000-Sep-01 08:07
By: VizNut

Comment:
Oops.  Ignore the "(with patch)" piece in the Summary.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113328&group_id=5470


From noreply@sourceforge.net  Fri Sep  1 22:15:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 1 Sep 2000 14:15:27 -0700
Subject: [Python-bugs-list] [Bug #110675] Pth: test_fork1 fails, test_thread slow (PR#383)
Message-ID: <200009012115.OAA30182@delerium.i.sourceforge.net>

Bug #110675, was updated on 2000-Jul-31 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 1
Summary: Pth: test_fork1 fails, test_thread slow (PR#383)

Details: Jitterbug-Id: 383
Submitted-By: gregor@hoffleit.de
Date: Tue,  4 Jul 2000 12:07:06 -0400 (EDT)
Version: CVS version (06/04/00)
OS: Debian potato (i386)


When I use the current CVS version of Python to build on a Debian potato
system with GNU Pth 1.2.3 installed, test_fork1 fails with an error (see
below),
and test_thread takes significantly longer to complete than when I build the 
same sources with native LinuxThreads.


When running test.regrtest.main(), this happens:

  clapton:3> LD_LIBRARY_PATH=`pwd` ./python 
  Python 2.0b1 (#0, Jul  4 2000, 17:06:15)  [GCC 2.95.2 20000220 (Debian
GNU/Linux)] on linux2
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
  >>> from test import regrtest
  >>> regrtest.main()
  test_grammar
  test_opcodes
...
  test_extcall
  test_fcntl
  test_fork1
  test test_fork1 crashed -- exceptions.AssertionError : 
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 30, in f
      alive[id] = os.getpid()
  AttributeError: 'None' object has no attribute 'getpid'
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 32, in f    time.sleep(SHORTSLEEP)
  TypeError: illegal argument type for built-in operation
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 30, in f
      alive[id] = os.getpid()
  AttributeError: 'None' object has no attribute 'getpid'
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 30, in f
      alive[id] = os.getpid()
  AttributeError: 'None' object has no attribute 'getpid'
  test_format
  test_gc
...


When running test.test_fork1(), I get this:

  clapton:3> LD_LIBRARY_PATH=`pwd` ./python 
  Python 2.0b1 (#0, Jul  4 2000, 17:06:15)  [GCC 2.95.2 20000220 (Debian
GNU/Linux)] on linux2
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
  >>> from test import test_fork1
  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    File "./Lib/test/test_fork1.py", line 68, in ?
      main()
    File "./Lib/test/test_fork1.py", line 44, in main
      assert a == range(NUM_THREADS)
  AssertionError
  >>>


test_thread takes very long to complete (5 min compared to 40 sec with 
LinuxThreads); when you look at the following log, you'll see that it tends
to calls the threads serially !?

clapton:3> LD_LIBRARY_PATH=`pwd` ./python 
Python 2.0b1 (#0, Jul  4 2000, 17:06:15)  [GCC 2.95.2 20000220 (Debian
GNU/Linux)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> from test import test_thread
creating task 1
creating task 2
creating task 3
task 1 will run for 2.1 sec
task 1 done
creating task 4
task 2 will run for 3.2 sec
creating task 5
task 2 done
creating task task 3 will run for 9.1 6
sec
task 3 done
creating task 7
task 4 will run for 2.5 sec
task 4 done
creating task 8
task 5 will run for 0.9 sec
task 5 done
creating task 9
task 6 will run for 7.4 sec
task 6 done
creating task 10
waiting for all tasks to complete
task 7 will run for 5.3 sec
task 7 done
task 8 will run for 2.6 sec
task 8 done
task 9 will run for 2.7 sec
task 9 done
task 10 will run for 0.9 sec
task 10 done
all tasks done

*** Barrier Test ***
task 0 will run for 0.0 sec
task 0 entering barrier 0
task 1 will run for 6.2 sec
task 1 entering barrier 0
task 7 will run for 7.0 sec
task 7 entering barrier 0
task 3 will run for 5.9 sec
task 3 entering barrier 0
task 4 will run for 4.5 sec
task 4 entering barrier 0
task 5 will run for 9.2 sec
task 5 entering barrier 0
task 6 will run for 1.4 sec
task 6 entering barrier 0
task 2 will run for 6.0 sec
task 2 entering barrier 0
task 8 will run for 2.4 sec
task 8 entering barrier 0
task 9 will run for 9.6 sec
task 9 entering barrier 0
task 9 leaving barrier 0
task 0 leaving barrier 0
task task 1 leaving barrier 0
0 will run for 0.0 sec
task 0 entering barrier 1
task 7 leaving barrier 0
task 9 will run for 0.8 sec
task 9 entering barrier task 3 leaving barrier 0
1
task 1 task 4 leaving barrier 0
will run for 6.1 sec
task 5 leaving barrier 0
task 1 entering barrier 1
task 6 leaving barrier 0
task 7 will run for 7.9 sec
task 2 leaving barrier 0
task 7 entering barrier 1
task 3 task 8 leaving barrier 0
will run for 7.8 sec
task 3 entering barrier 1
task 4 will run for 5.7 sec
task 4 entering barrier 1
task 5 will run for 2.0 sec
task 5 entering barrier 1
task 6 will run for 0.5 sec
task 6 entering barrier 1
task 2 will run for 7.4 sec
task 2 entering barrier 1
task 8 will run for 1.0 sec
task 8 entering barrier 1
task 8 leaving barrier 1
task 7 leaving barrier 1
task 9 leaving barrier 1
task 1 leaving barrier 1
task 8 will run for 6.9 sec
task 0 leaving barrier 1
task 8 entering barrier 2
task 0 will run for task 4 leaving barrier 1 0.0 sec

task 7 will run for 4.3 sec task 0 entering barrier
2
task 3 leaving barrier 1
task 7 entering barrier 2
task 5 leaving barrier 1
task 6 leaving barrier 1 task 9 will run for
8.2 sec
task task 2 leaving barrier 9 entering barrier 2
1
task 5 will run for 8.9 sec
task 5 entering barrier 2
task 2 will run for 8.3 sec
task 2 entering barrier 2
task 3 will run for 4.5 sec
task 3 entering barrier 2
task 1 will run for 7.0 sec
task 1 entering barrier 2
task 6 will run for 1.9 sec
task 6 entering barrier 2
task 4 will run for 0.2 sec
task 4 entering barrier 2
task 4 leaving barrier 2
task 8 leaving barrier 2
task 9 leaving barrier 2
task 7 leaving barrier 2
task 5 leaving barrier 2
task 0 leaving barrier 2
task 2 leaving barrier 2
task 3 leaving barrier 2
task 1 leaving barrier 2
task 6 leaving barrier 2
all tasks done



while this is the log of the same test with Python 1.5.2 and LinuxThreads:

clapton:3> python
Python 1.5.2 (#0, Apr  3 2000, 14:46:48)  [GCC 2.95.2 20000313 (Debian
GNU/Linux)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from test import test_thread
creating task 1
creating task 2
creating task 3
creating task 4
creating task 5
creating task 6
creating task 7
creating task 8
creating task 9
creating task 10
waiting for all tasks to complete
task 1 will run for 8.9 sec
task 2 will run for 8.3 sec
task 3 will run for 9.1 sec
task 5 will run for 6.0 sec
task 4 will run for 7.5 sec
task 6 will run for 4.7 sec
task 7 will run for 4.2 sec
task 8 will run for 7.0 sec
task 9 will run for 8.7 sec
task 10 will run for 9.5 sec
task 7 done
task 6 done
task 5 done
task 8 done
task 4 done
task 2 done
task 9 done
task 1 done
task 3 done
task 10 done
all tasks done

*** Barrier Test ***
task 0 will run for 0.0 sec
task 1 will run for 2.8 sec
task 0 entering barrier 0
task 2 will run for 5.3 sec
task 3 will run for 9.2 sec
task 5 will run for 8.0 sec
task 4 will run for 8.9 sec
task 6 will run for 5.0 sec
task 7 will run for 1.3 sec
task 8 will run for 5.6 sec
task 9 will run for 4.7 sec
task 7 entering barrier 0
task 1 entering barrier 0
task 9 entering barrier 0
task 6 entering barrier 0
task 2 entering barrier 0
task 8 entering barrier 0
task 5 entering barrier 0
task 4 entering barrier 0
task 3 entering barrier 0
task 3 leaving barrier 0
task 3 will run for 0.1 sec
task 0 leaving barrier 0
task 0 will run for 0.0 sec
task 7 leaving barrier 0
task 7 will run for 6.6 sec
task 1 leaving barrier 0
task 1 will run for 1.0 sec
task 9 leaving barrier 0
task 9 will run for 8.2 sec
task 6 leaving barrier 0
task 6 will run for 1.0 sec
task 2 leaving barrier 0
task 2 will run for 9.2 sec
task 8 leaving barrier 0
task 8 will run for 4.4 sec
task 5 leaving barrier 0
task 5 will run for 9.6 sec
task 4 leaving barrier 0
task 4 will run for 1.7 sec
task 0 entering barrier 1
task 3 entering barrier 1
task 1 entering barrier 1
task 6 entering barrier 1
task 4 entering barrier 1
task 8 entering barrier 1
task 7 entering barrier 1
task 9 entering barrier 1
task 2 entering barrier 1
task 5 entering barrier 1
task 5 leaving barrier 1
task 5 will run for 6.6 sec
task 0 leaving barrier 1
task 0 will run for 0.0 sec
task 3 leaving barrier 1
task 3 will run for 8.5 sec
task 1 leaving barrier 1
task 1 will run for 0.1 sec
task 6 leaving barrier 1
task 6 will run for 4.7 sec
task 4 leaving barrier 1
task 4 will run for 4.7 sec
task 8 leaving barrier 1
task 8 will run for 1.7 sec
task 7 leaving barrier 1
task 7 will run for 1.8 sec
task 9 leaving barrier 1
task 9 will run for 2.8 sec
task 2 leaving barrier 1
task 2 will run for 3.3 sec
task 0 entering barrier 2
task 1 entering barrier 2
task 8 entering barrier 2
task 7 entering barrier 2
task 9 entering barrier 2
task 2 entering barrier 2
task 6 entering barrier 2
task 4 entering barrier 2
task 5 entering barrier 2
task 3 entering barrier 2
task 3 leaving barrier 2
task 0 leaving barrier 2
task 1 leaving barrier 2
task 8 leaving barrier 2
task 7 leaving barrier 2
task 9 leaving barrier 2
task 2 leaving barrier 2
task 6 leaving barrier 2
task 4 leaving barrier 2
task 5 leaving barrier 2
all tasks done
>>> 





====================================================================
Audit trail:
Tue Jul 11 08:24:22 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-23 10:31
By: jhylton

Comment:
Another report of test_fork1 problems.  Plan to resolve before 2.0b1.

-------------------------------------------------------

Date: 2000-Aug-23 10:36
By: tim_one

Comment:
Jeremy, my chances of helping someone with a problem specific to "Debian potato system with GNU Pth 1.2.3" are nil.  Assigned back to you since you seem to believe it's feasible <wink>.
-------------------------------------------------------

Date: 2000-Aug-31 14:53
By: jhylton

Comment:
Haven't heard back from the submittor.  This sounds like a problem with a buggy GNU Pth package; not a Python bug.

-------------------------------------------------------

Date: 2000-Sep-01 14:15
By: none

Comment:
I submitted the original pth support. pth has what I would consider a bug in that signals do not interrupt sleep(), usleep(), or select(), the latter being what Python uses to sleep. I'm going to look at this some more myself as soon as I can get the current CVS to configure with pth. -- andy@dustman.net
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110675&group_id=5470


From noreply@sourceforge.net  Fri Sep  1 22:22:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 1 Sep 2000 14:22:16 -0700
Subject: [Python-bugs-list] [Bug #110675] Pth: test_fork1 fails, test_thread slow (PR#383)
Message-ID: <200009012122.OAA30419@delerium.i.sourceforge.net>

Bug #110675, was updated on 2000-Jul-31 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 1
Summary: Pth: test_fork1 fails, test_thread slow (PR#383)

Details: Jitterbug-Id: 383
Submitted-By: gregor@hoffleit.de
Date: Tue,  4 Jul 2000 12:07:06 -0400 (EDT)
Version: CVS version (06/04/00)
OS: Debian potato (i386)


When I use the current CVS version of Python to build on a Debian potato
system with GNU Pth 1.2.3 installed, test_fork1 fails with an error (see
below),
and test_thread takes significantly longer to complete than when I build the 
same sources with native LinuxThreads.


When running test.regrtest.main(), this happens:

  clapton:3> LD_LIBRARY_PATH=`pwd` ./python 
  Python 2.0b1 (#0, Jul  4 2000, 17:06:15)  [GCC 2.95.2 20000220 (Debian
GNU/Linux)] on linux2
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
  >>> from test import regrtest
  >>> regrtest.main()
  test_grammar
  test_opcodes
...
  test_extcall
  test_fcntl
  test_fork1
  test test_fork1 crashed -- exceptions.AssertionError : 
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 30, in f
      alive[id] = os.getpid()
  AttributeError: 'None' object has no attribute 'getpid'
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 32, in f    time.sleep(SHORTSLEEP)
  TypeError: illegal argument type for built-in operation
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 30, in f
      alive[id] = os.getpid()
  AttributeError: 'None' object has no attribute 'getpid'
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 30, in f
      alive[id] = os.getpid()
  AttributeError: 'None' object has no attribute 'getpid'
  test_format
  test_gc
...


When running test.test_fork1(), I get this:

  clapton:3> LD_LIBRARY_PATH=`pwd` ./python 
  Python 2.0b1 (#0, Jul  4 2000, 17:06:15)  [GCC 2.95.2 20000220 (Debian
GNU/Linux)] on linux2
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
  >>> from test import test_fork1
  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    File "./Lib/test/test_fork1.py", line 68, in ?
      main()
    File "./Lib/test/test_fork1.py", line 44, in main
      assert a == range(NUM_THREADS)
  AssertionError
  >>>


test_thread takes very long to complete (5 min compared to 40 sec with 
LinuxThreads); when you look at the following log, you'll see that it tends
to calls the threads serially !?

clapton:3> LD_LIBRARY_PATH=`pwd` ./python 
Python 2.0b1 (#0, Jul  4 2000, 17:06:15)  [GCC 2.95.2 20000220 (Debian
GNU/Linux)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> from test import test_thread
creating task 1
creating task 2
creating task 3
task 1 will run for 2.1 sec
task 1 done
creating task 4
task 2 will run for 3.2 sec
creating task 5
task 2 done
creating task task 3 will run for 9.1 6
sec
task 3 done
creating task 7
task 4 will run for 2.5 sec
task 4 done
creating task 8
task 5 will run for 0.9 sec
task 5 done
creating task 9
task 6 will run for 7.4 sec
task 6 done
creating task 10
waiting for all tasks to complete
task 7 will run for 5.3 sec
task 7 done
task 8 will run for 2.6 sec
task 8 done
task 9 will run for 2.7 sec
task 9 done
task 10 will run for 0.9 sec
task 10 done
all tasks done

*** Barrier Test ***
task 0 will run for 0.0 sec
task 0 entering barrier 0
task 1 will run for 6.2 sec
task 1 entering barrier 0
task 7 will run for 7.0 sec
task 7 entering barrier 0
task 3 will run for 5.9 sec
task 3 entering barrier 0
task 4 will run for 4.5 sec
task 4 entering barrier 0
task 5 will run for 9.2 sec
task 5 entering barrier 0
task 6 will run for 1.4 sec
task 6 entering barrier 0
task 2 will run for 6.0 sec
task 2 entering barrier 0
task 8 will run for 2.4 sec
task 8 entering barrier 0
task 9 will run for 9.6 sec
task 9 entering barrier 0
task 9 leaving barrier 0
task 0 leaving barrier 0
task task 1 leaving barrier 0
0 will run for 0.0 sec
task 0 entering barrier 1
task 7 leaving barrier 0
task 9 will run for 0.8 sec
task 9 entering barrier task 3 leaving barrier 0
1
task 1 task 4 leaving barrier 0
will run for 6.1 sec
task 5 leaving barrier 0
task 1 entering barrier 1
task 6 leaving barrier 0
task 7 will run for 7.9 sec
task 2 leaving barrier 0
task 7 entering barrier 1
task 3 task 8 leaving barrier 0
will run for 7.8 sec
task 3 entering barrier 1
task 4 will run for 5.7 sec
task 4 entering barrier 1
task 5 will run for 2.0 sec
task 5 entering barrier 1
task 6 will run for 0.5 sec
task 6 entering barrier 1
task 2 will run for 7.4 sec
task 2 entering barrier 1
task 8 will run for 1.0 sec
task 8 entering barrier 1
task 8 leaving barrier 1
task 7 leaving barrier 1
task 9 leaving barrier 1
task 1 leaving barrier 1
task 8 will run for 6.9 sec
task 0 leaving barrier 1
task 8 entering barrier 2
task 0 will run for task 4 leaving barrier 1 0.0 sec

task 7 will run for 4.3 sec task 0 entering barrier
2
task 3 leaving barrier 1
task 7 entering barrier 2
task 5 leaving barrier 1
task 6 leaving barrier 1 task 9 will run for
8.2 sec
task task 2 leaving barrier 9 entering barrier 2
1
task 5 will run for 8.9 sec
task 5 entering barrier 2
task 2 will run for 8.3 sec
task 2 entering barrier 2
task 3 will run for 4.5 sec
task 3 entering barrier 2
task 1 will run for 7.0 sec
task 1 entering barrier 2
task 6 will run for 1.9 sec
task 6 entering barrier 2
task 4 will run for 0.2 sec
task 4 entering barrier 2
task 4 leaving barrier 2
task 8 leaving barrier 2
task 9 leaving barrier 2
task 7 leaving barrier 2
task 5 leaving barrier 2
task 0 leaving barrier 2
task 2 leaving barrier 2
task 3 leaving barrier 2
task 1 leaving barrier 2
task 6 leaving barrier 2
all tasks done



while this is the log of the same test with Python 1.5.2 and LinuxThreads:

clapton:3> python
Python 1.5.2 (#0, Apr  3 2000, 14:46:48)  [GCC 2.95.2 20000313 (Debian
GNU/Linux)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from test import test_thread
creating task 1
creating task 2
creating task 3
creating task 4
creating task 5
creating task 6
creating task 7
creating task 8
creating task 9
creating task 10
waiting for all tasks to complete
task 1 will run for 8.9 sec
task 2 will run for 8.3 sec
task 3 will run for 9.1 sec
task 5 will run for 6.0 sec
task 4 will run for 7.5 sec
task 6 will run for 4.7 sec
task 7 will run for 4.2 sec
task 8 will run for 7.0 sec
task 9 will run for 8.7 sec
task 10 will run for 9.5 sec
task 7 done
task 6 done
task 5 done
task 8 done
task 4 done
task 2 done
task 9 done
task 1 done
task 3 done
task 10 done
all tasks done

*** Barrier Test ***
task 0 will run for 0.0 sec
task 1 will run for 2.8 sec
task 0 entering barrier 0
task 2 will run for 5.3 sec
task 3 will run for 9.2 sec
task 5 will run for 8.0 sec
task 4 will run for 8.9 sec
task 6 will run for 5.0 sec
task 7 will run for 1.3 sec
task 8 will run for 5.6 sec
task 9 will run for 4.7 sec
task 7 entering barrier 0
task 1 entering barrier 0
task 9 entering barrier 0
task 6 entering barrier 0
task 2 entering barrier 0
task 8 entering barrier 0
task 5 entering barrier 0
task 4 entering barrier 0
task 3 entering barrier 0
task 3 leaving barrier 0
task 3 will run for 0.1 sec
task 0 leaving barrier 0
task 0 will run for 0.0 sec
task 7 leaving barrier 0
task 7 will run for 6.6 sec
task 1 leaving barrier 0
task 1 will run for 1.0 sec
task 9 leaving barrier 0
task 9 will run for 8.2 sec
task 6 leaving barrier 0
task 6 will run for 1.0 sec
task 2 leaving barrier 0
task 2 will run for 9.2 sec
task 8 leaving barrier 0
task 8 will run for 4.4 sec
task 5 leaving barrier 0
task 5 will run for 9.6 sec
task 4 leaving barrier 0
task 4 will run for 1.7 sec
task 0 entering barrier 1
task 3 entering barrier 1
task 1 entering barrier 1
task 6 entering barrier 1
task 4 entering barrier 1
task 8 entering barrier 1
task 7 entering barrier 1
task 9 entering barrier 1
task 2 entering barrier 1
task 5 entering barrier 1
task 5 leaving barrier 1
task 5 will run for 6.6 sec
task 0 leaving barrier 1
task 0 will run for 0.0 sec
task 3 leaving barrier 1
task 3 will run for 8.5 sec
task 1 leaving barrier 1
task 1 will run for 0.1 sec
task 6 leaving barrier 1
task 6 will run for 4.7 sec
task 4 leaving barrier 1
task 4 will run for 4.7 sec
task 8 leaving barrier 1
task 8 will run for 1.7 sec
task 7 leaving barrier 1
task 7 will run for 1.8 sec
task 9 leaving barrier 1
task 9 will run for 2.8 sec
task 2 leaving barrier 1
task 2 will run for 3.3 sec
task 0 entering barrier 2
task 1 entering barrier 2
task 8 entering barrier 2
task 7 entering barrier 2
task 9 entering barrier 2
task 2 entering barrier 2
task 6 entering barrier 2
task 4 entering barrier 2
task 5 entering barrier 2
task 3 entering barrier 2
task 3 leaving barrier 2
task 0 leaving barrier 2
task 1 leaving barrier 2
task 8 leaving barrier 2
task 7 leaving barrier 2
task 9 leaving barrier 2
task 2 leaving barrier 2
task 6 leaving barrier 2
task 4 leaving barrier 2
task 5 leaving barrier 2
all tasks done
>>> 





====================================================================
Audit trail:
Tue Jul 11 08:24:22 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-23 10:31
By: jhylton

Comment:
Another report of test_fork1 problems.  Plan to resolve before 2.0b1.

-------------------------------------------------------

Date: 2000-Aug-23 10:36
By: tim_one

Comment:
Jeremy, my chances of helping someone with a problem specific to "Debian potato system with GNU Pth 1.2.3" are nil.  Assigned back to you since you seem to believe it's feasible <wink>.
-------------------------------------------------------

Date: 2000-Aug-31 14:53
By: jhylton

Comment:
Haven't heard back from the submittor.  This sounds like a problem with a buggy GNU Pth package; not a Python bug.

-------------------------------------------------------

Date: 2000-Sep-01 14:15
By: none

Comment:
I submitted the original pth support. pth has what I would consider a bug in that signals do not interrupt sleep(), usleep(), or select(), the latter being what Python uses to sleep. I'm going to look at this some more myself as soon as I can get the current CVS to configure with pth. -- andy@dustman.net
-------------------------------------------------------

Date: 2000-Sep-01 14:22
By: none

Comment:
Another thing which may be a factor in this case: Since pth threads are user-space and so all run in the same process, the test used in signalmodule.c:125 doesn't work, i.e.

        if (getpid() == main_pid) {

It probably needs to be something more like this:

        if (PyThread_get_thread_ident() != main_thread) {

I submitted a patch to fix this around the time of the CNRI split, so it probably got lost.

-- andy@dustman.net
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110675&group_id=5470


From noreply@sourceforge.net  Sat Sep  2 05:24:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 1 Sep 2000 21:24:58 -0700
Subject: [Python-bugs-list] [Bug #113401] grant
Message-ID: <200009020424.VAA11938@delerium.i.sourceforge.net>

Bug #113401, was updated on 2000-Sep-01 21:24
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Trash
Priority: 5
Summary: grant

Details: Third party trash!!!

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113401&group_id=5470


From noreply@sourceforge.net  Sat Sep  2 05:26:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 1 Sep 2000 21:26:43 -0700
Subject: [Python-bugs-list] [Bug #113401] grant
Message-ID: <200009020426.VAA11955@delerium.i.sourceforge.net>

Bug #113401, was updated on 2000-Sep-01 21:24
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: None
Bug Group: Trash
Priority: 5
Summary: grant

Details: Third party trash!!!

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113401&group_id=5470


From noreply@sourceforge.net  Sat Sep  2 17:31:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 2 Sep 2000 09:31:02 -0700
Subject: [Python-bugs-list] [Bug #113254] pre/sre difference breaks pyclbr
Message-ID: <200009021631.JAA01963@delerium.i.sourceforge.net>

Bug #113254, was updated on 2000-Aug-31 12:13
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: Fixed
Bug Group: None
Priority: 6
Summary: pre/sre difference breaks pyclbr

Details: """ 

pre and sre deal differently with groups that
"do not contribute to the match". Fredrick
points out that sre seems to be right but now
pyclbr is broken (though easy to fix). This
program demonstrates the difference in behavior
and the pyclbr breakage.

call it "pyclbrbug.py" The name matters because
it uses itself as a test case!
"""


import pre
import sre
import pyclbr
import sys

the_re=r"""
    (?P<Method>
	^
	(?P<MethodIndent> [ \t]* )
	def [ \t]+
	(?P<MethodName> [a-zA-Z_] \w* )
	[ \t]* \(
    )

|   (?P<Class>
	^
	(?P<ClassIndent> [ \t]* )
	class [ \t]+
	(?P<ClassName> [a-zA-Z_] \w* )
	[ \t]*
	(?P<ClassSupers> \( [^)\n]* \) )?
	[ \t]* :
    )
"""

eg="class foo: pass"

def test( mod ):
	print "===========", mod.__name__
	re=mod.compile(the_re, 
	              mod.VERBOSE | 
                      mod.DOTALL | 
	              mod.MULTILINE)
	match=re.search( eg )
	print match.start( "Method" )
	print match.group( "MethodIndent" )
	sys.modules["re"]=mod
	reload( pyclbr )
	pyclbr.readmodule_ex("pyclbrbug",["."])

test( pre )
test( sre )



Follow-Ups:

Date: 2000-Aug-31 20:57
By: jhylton

Comment:
Who should fix pyclbr?  If not you /F, please reassign.

-------------------------------------------------------

Date: 2000-Sep-02 09:31
By: effbot

Comment:
after discussion with GvR, we decided to fix this in SRE.

fred, can you update the start/end/span documentation and close this bug?  (the code is right, the docs are wrong).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113254&group_id=5470


From noreply@sourceforge.net  Sun Sep  3 03:44:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 2 Sep 2000 19:44:38 -0700
Subject: [Python-bugs-list] [Bug #113463] Inconsistent handling of arg -/-- by getopt.getopt() ?
Message-ID: <200009030244.TAA22065@delerium.i.sourceforge.net>

Bug #113463, was updated on 2000-Sep-02 19:44
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Inconsistent handling of arg -/-- by getopt.getopt() ?

Details: Problem with function getopt of module getopt.py of Python 1.5.1?

Case 1:

>>> import getopt, string
>>> args = string.split('-a -b b_val - some more stuff -c')
>>> optlist, trailing_args = getopt.getopt(args, 'ab:c')
>>> optlist
[('-a', ''), ('-b', 'b_val')]
>>> trailing_args
['-', 'some', 'more', 'stuff', '-c']

Case 2:

>>> import getopt, string
>>> args = string.split('-a -b b_val -- some more stuff -c')
>>> optlist, trailing_args = getopt.getopt(args, 'ab:c')
>>> optlist
[('-a', ''), ('-b', 'b_val')]
>>> trailing_args
['some', 'more', 'stuff', '-c']

The differences are: 
In case 1, I have "-" in the args list and I get it as the first element of the trailing_args output list; In case 2, I have "--" in the args list and I get nothing about it in the trailing_args output list.

This happens because in line 7 of the function getopt (reproduced below) the "--" element of args is discarded.

~~~~~~~~~
Function getopt:

def getopt(args, shortopts, longopts = []):
    list = []
    longopts = longopts[:]
    longopts.sort()
    while args and args[0][:1] == '-' and args[0] != '-':
        if args[0] == '--':
            args = args[1:]
            break
        if args[0][:2] == '--':
            list, args = do_longs(list, args[0][2:], longopts, args[1:])
        else:
            list, args = do_shorts(list, args[0][1:], shortopts, args[1:])

    return list, args


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113463&group_id=5470


From noreply@sourceforge.net  Mon Sep  4 04:57:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 3 Sep 2000 20:57:58 -0700
Subject: [Python-bugs-list] [Bug #111203] 1.6b1 build (docs?) pyexpat problem on Windows
Message-ID: <200009040357.UAA06546@delerium.i.sourceforge.net>

Bug #111203, was updated on 2000-Aug-06 11:36
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: 1.6b1 build (docs?) pyexpat problem on Windows

Details: pyexpat is not documented as one of those subprojects needing external software, but apparently it is one; it needs xmlparse and xmltok, .h and .lib to build and .dll
to run.  The docs don't mention where to get those from,
but I had them around (from a Perl site build...) and
feeding them to the Python 1.6b1 build fixed it.  So I
think it's just a doc-bug.


Alex


Follow-Ups:

Date: 2000-Aug-29 21:59
By: fdrake

Comment:
What documentation is there on this?  Sounds like something needs to change in the Windows README file; not sure.

Tim, you're the Windows guy.  Fix it.  ;)
-------------------------------------------------------

Date: 2000-Aug-29 22:21
By: tim_one

Comment:
Assigned to Guido, because last I heard 1.6 was frozen, and he's got the 1.6 Windows build setup anyway.  The docs here were extensively rewritten for 2.0, and the complaint here doesn't exist there anymore.
-------------------------------------------------------

Date: 2000-Sep-03 20:57
By: gvanrossum

Comment:
This doc issue has been fixed a while ago.
The PCbuild/readme.txt lists it, and the Modules/Setup.in file also points to jclark.com.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=111203&group_id=5470


From noreply@sourceforge.net  Mon Sep  4 05:08:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 3 Sep 2000 21:08:28 -0700
Subject: [Python-bugs-list] [Bug #113145] config.h defines socklen_t, kills wxPython build
Message-ID: <200009040408.VAA11366@bush.i.sourceforge.net>

Bug #113145, was updated on 2000-Aug-30 12:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: config.h defines socklen_t, kills wxPython build

Details: Building wxPython fails with 1.6  because config.h defines socklen_t; according to a comment, it checks sys/types.h. But /usr/include/bits/socket.h on Linux at least, tries to make a typedef with this name.



Follow-Ups:

Date: 2000-Sep-03 21:08
By: gvanrossum

Comment:
Could this be dependent on the Linux version? It seems my config.h had socklen_t defined on Red Hat 6.1, but it is undefined on Red Hat 6.2 (which would fix your problem if I understand it correctly).

What platform are you using?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113145&group_id=5470


From noreply@sourceforge.net  Mon Sep  4 06:10:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 3 Sep 2000 22:10:25 -0700
Subject: [Python-bugs-list] [Bug #113145] config.h defines socklen_t, kills wxPython build
Message-ID: <200009040510.WAA08819@delerium.i.sourceforge.net>

Bug #113145, was updated on 2000-Aug-30 12:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: config.h defines socklen_t, kills wxPython build

Details: Building wxPython fails with 1.6  because config.h defines socklen_t; according to a comment, it checks sys/types.h. But /usr/include/bits/socket.h on Linux at least, tries to make a typedef with this name.



Follow-Ups:

Date: 2000-Sep-03 21:08
By: gvanrossum

Comment:
Could this be dependent on the Linux version? It seems my config.h had socklen_t defined on Red Hat 6.1, but it is undefined on Red Hat 6.2 (which would fix your problem if I understand it correctly).

What platform are you using?

-------------------------------------------------------

Date: 2000-Sep-03 22:10
By: dubois

Comment:
My system is 6.1 I think. (I didn't install it.) 
Here is uname -a:
Linux bruno.llnl.gov 2.2.12-20smp #1 SMP Mon Sep 27 10:34:45 EDT 1999 i686 unknown

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113145&group_id=5470


From noreply@sourceforge.net  Mon Sep  4 15:54:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 4 Sep 2000 07:54:46 -0700
Subject: [Python-bugs-list] [Bug #110607] Telnet close (PR#181)
Message-ID: <200009041454.HAA00432@bush.i.sourceforge.net>

Bug #110607, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Telnet close (PR#181)

Details: Jitterbug-Id: 181
Submitted-By: cha@tandberg.no
Date: Wed, 12 Jan 2000 09:49:29 -0500 (EST)
Version: 1.5.2
OS: Windows NT4.0


The telnet.close() object does not close the telnet session.
Session will only be closed after a timeout on the remote side.

 



====================================================================
Audit trail:
Wed Jan 12 18:29:38 2000	guido	changed notes
Wed Jan 12 18:29:38 2000	guido	changed notification
Wed Jan 12 18:29:38 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-23 18:50
By: montanaro

Comment:
Replied to the submitter asking for a short script that fails.  I don't run Windows so I may not be able to track
this down.

-------------------------------------------------------

Date: 2000-Sep-04 07:54
By: montanaro

Comment:
Never did get any response from the submitter.  This was
apparently originally submitted back in January.  I'm simply going to bounce this back to Tim since he at least runs Windows...

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110607&group_id=5470


From noreply@sourceforge.net  Mon Sep  4 22:14:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 4 Sep 2000 14:14:11 -0700
Subject: [Python-bugs-list] [Bug #113576] Py_PROTO missing from the include files
Message-ID: <200009042114.OAA13832@bush.i.sourceforge.net>

Bug #113576, was updated on 2000-Sep-04 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Py_PROTO missing from the include files

Details: Some old extensions still use the Py_PROTO() macro which was
present in Python 1.5.2 and ealier. After the ANSIfication of the sources,
this macro seems to have been removed from the Python include
files.

This breaks all extensions which used the macro.

Adding a 
#define Py_PROTO(args)       args
to pyport.h should remedy this.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113576&group_id=5470


From noreply@sourceforge.net  Tue Sep  5 06:21:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 4 Sep 2000 22:21:04 -0700
Subject: [Python-bugs-list] [Bug #113600] mmap module is undocumented
Message-ID: <200009050521.WAA26480@delerium.i.sourceforge.net>

Bug #113600, was updated on 2000-Sep-04 22:21
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: mmap module is undocumented

Details: The mmap module is undocumented, but should be.

Assigned to Mark Hammond since he touched the code most recently.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113600&group_id=5470


From noreply@sourceforge.net  Tue Sep  5 06:23:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 4 Sep 2000 22:23:29 -0700
Subject: [Python-bugs-list] [Bug #113600] mmap module is undocumented
Message-ID: <200009050523.WAA26604@delerium.i.sourceforge.net>

Bug #113600, was updated on 2000-Sep-04 22:21
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: mmap module is undocumented

Details: The mmap module is undocumented, but should be.

Assigned to Mark Hammond since he touched the code most recently.


Follow-Ups:

Date: 2000-Sep-04 22:23
By: fdrake

Comment:
Changed assignment to Andrew, since Tim says he agreed to document it long ago.

Bumped the priority since he actually said he'd do it.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113600&group_id=5470


From noreply@sourceforge.net  Tue Sep  5 13:21:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 5 Sep 2000 05:21:45 -0700
Subject: [Python-bugs-list] [Bug #113600] mmap module is undocumented
Message-ID: <200009051221.FAA11695@bush.i.sourceforge.net>

Bug #113600, was updated on 2000-Sep-04 22:21
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: mmap module is undocumented

Details: The mmap module is undocumented, but should be.

Assigned to Mark Hammond since he touched the code most recently.


Follow-Ups:

Date: 2000-Sep-04 22:23
By: fdrake

Comment:
Changed assignment to Andrew, since Tim says he agreed to document it long ago.

Bumped the priority since he actually said he'd do it.
-------------------------------------------------------

Date: 2000-Sep-05 05:21
By: akuchling

Comment:
Erm... Doc/lib/libmmap.tex was checked in on 2000/06/17.
It just doesn't seem to be included in lib.tex at the moment.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113600&group_id=5470


From noreply@sourceforge.net  Tue Sep  5 14:56:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 5 Sep 2000 06:56:15 -0700
Subject: [Python-bugs-list] [Bug #113600] mmap module is undocumented
Message-ID: <200009051356.GAA11699@delerium.i.sourceforge.net>

Bug #113600, was updated on 2000-Sep-04 22:21
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 6
Summary: mmap module is undocumented

Details: The mmap module is undocumented, but should be.

Assigned to Mark Hammond since he touched the code most recently.


Follow-Ups:

Date: 2000-Sep-04 22:23
By: fdrake

Comment:
Changed assignment to Andrew, since Tim says he agreed to document it long ago.

Bumped the priority since he actually said he'd do it.
-------------------------------------------------------

Date: 2000-Sep-05 05:21
By: akuchling

Comment:
Erm... Doc/lib/libmmap.tex was checked in on 2000/06/17.
It just doesn't seem to be included in lib.tex at the moment.
-------------------------------------------------------

Date: 2000-Sep-05 06:56
By: fdrake

Comment:
Okay, I foud the docco that Andrew wrote; I'd not added it to the driver file.  This is now done.

Sorry, Andrew!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113600&group_id=5470


From noreply@sourceforge.net  Tue Sep  5 15:14:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 5 Sep 2000 07:14:12 -0700
Subject: [Python-bugs-list] [Bug #112123] bdist_wininst crashes with no long_description
Message-ID: <200009051414.HAA12401@delerium.i.sourceforge.net>

Bug #112123, was updated on 2000-Aug-16 15:18
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Closed
Resolution: None
Bug Group: None
Priority: 5
Summary: bdist_wininst crashes with no long_description

Details: The bdist_wininst command crashes if no long_description
is specified:

  File "setup.py", line 48, in ?
    sources = [
  File "/www/python/lib/python1.5/site-packages/distutils/core.py", line 112, in setup
    dist.run_commands ()
  File "/www/python/lib/python1.5/site-packages/distutils/dist.py", line 776, in run_commands
    self.run_command (cmd)
  File "/www/python/lib/python1.5/site-packages/distutils/dist.py", line 797, in run_command
    cmd_obj.run ()
  File "/www/python/lib/python1.5/site-packages/distutils/command/bdist_wininst.py", line 115, in run
    self.create_exe (arcname, fullname)
  File "/www/python/lib/python1.5/site-packages/distutils/command/bdist_wininst.py", line 171, in create_exe
    cfgdata = open (self.create_inifile()).read()
  File "/www/python/lib/python1.5/site-packages/distutils/command/bdist_wininst.py", line 140, in create_inifile
    info = metadata.long_description + '\n'
TypeError: bad operand type(s) for +


Follow-Ups:

Date: 2000-Aug-27 13:47
By: gward

Comment:
Thomas fixed this in the latest wininst code drop, but
had some missing parens.  I just added them and checked
that in.  Can please someone check that "long_description"
behaves correctly with Windows installers?
-------------------------------------------------------

Date: 2000-Sep-05 07:14
By: akuchling

Comment:
I've verified that this bug is now fixed.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112123&group_id=5470


From noreply@sourceforge.net  Tue Sep  5 21:11:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 5 Sep 2000 13:11:08 -0700
Subject: [Python-bugs-list] [Bug #110686] cStringIO lacks the readlines method (PR#409)
Message-ID: <200009052011.NAA28640@bush.i.sourceforge.net>

Bug #110686, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 4
Summary: cStringIO lacks the readlines method (PR#409)

Details: Jitterbug-Id: 409
Submitted-By: pierre@saiph.com
Date: Sun, 23 Jul 2000 13:41:59 -0400 (EDT)
Version: 1.5.2
OS: sparc solaris


cStringIO is supposed to be the C version of  For some reason,
it does not provide the readlines method.
The obvious turnaround is to use StringIO instead: no hurry to fix,
at least on my side.



====================================================================
Audit trail:
Mon Jul 24 18:41:02 2000	jeremy	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-05 13:11
By: loewis

Comment:
Fixed in Patch #101423,
http://sourceforge.net/patch/?func=detailpatch&patch_id=101423&group_id=5470
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110686&group_id=5470


From noreply@sourceforge.net  Tue Sep  5 21:27:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 5 Sep 2000 13:27:50 -0700
Subject: [Python-bugs-list] [Bug #110692] urllib.URLopener does not work with proxies (PR#67)
Message-ID: <200009052027.NAA29230@bush.i.sourceforge.net>

Bug #110692, was updated on 2000-Jul-31 14:15
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: urllib.URLopener does not work with proxies (PR#67)

Details: Jitterbug-Id: 67
Submitted-By: andrew@fc.hp.com
Date: Thu, 26 Aug 1999 16:20:02 -0400 (EDT)
Version: 1.5.1
OS: 


When using urllib.URLopener(proxy) (instead of setting _PROXY env variables and

calling urllib.openurl(),
you get the following error message:

 File "./watchdog.py", line 118, in main
    url.open(urltocheck)
  File "/usr/lib/python1.5/urllib.py", line 158, in open
    return getattr(self, name)(url)
  File "/usr/lib/python1.5/urllib.py", line 258, in open_http
    return addinfourl(fp, headers, "http:" + url)
TypeError: illegal argument type for built-in operation 

When using explicti proxies, url is a tuple instead of a string.  You can't 
concatanate a tuple to a string, so the operation fails.

 



====================================================================
Audit trail:
Mon Aug 30 12:40:45 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-05 13:27
By: loewis

Comment:
This is likely incorrect usage of the module. The proxy argument must
be a dictionary mapping strings of protocol names to  strings of URLs.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110692&group_id=5470


From noreply@sourceforge.net  Tue Sep  5 21:41:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 5 Sep 2000 13:41:44 -0700
Subject: [Python-bugs-list] [Bug #110625] trouble building under Solaris 7 (PR#260)
Message-ID: <200009052041.NAA29809@bush.i.sourceforge.net>

Bug #110625, was updated on 2000-Jul-31 14:08
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: trouble building under Solaris 7 (PR#260)

Details: Jitterbug-Id: 260
Submitted-By: lipman@helix.nih.gov
Date: Fri, 31 Mar 2000 18:03:56 -0500 (EST)
Version: 1.5.2
OS: Solaris 7 106541-08


When I built Python on my machine:

SunOS 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-5_10

Python's internal symbols (for instance PySequence_Length) were not
included in the dynamic symbol table of the python executable.  This
prevented the Numerical-15.2 extensions from importing properly.  My
machine has both the Sun linker (in /usr/ccs/bin) and the GNU linker
installed.  I use the GNU linker, which is first in the $PATH under
which Python was built.

A workaround for this problem is to change the following line in
Modules/Makefile.pre from

LDFLAGS=

to

LDFLAGS= -export-dynamic

This will only work for the GNU linker.



====================================================================
Audit trail:
Mon May 22 17:39:59 2000	guido	changed notes
Mon May 22 17:39:59 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-06 14:25
By: twouters

Comment:
This might be fixed by newer autoconf ?
-------------------------------------------------------

Date: 2000-Aug-30 05:39
By: akuchling

Comment:
Reassigning to Jeremy, since I lack the time.
-------------------------------------------------------

Date: 2000-Sep-05 13:41
By: loewis

Comment:
I believe this is fixed in Python 2. I had the same problem in 1.5.2, as
GNU ld suddenly started printing its -V output to stderr instead of
stdout. Then, 

$CC -Xlinker -V 2>/dev/null | grep BFD >/dev/null

of 1.5.2 would not consider the linker as GNU ld. In 2.0,  the line is

$CC -Xlinker -V 2>&1 | grep BFD >/dev/null

so stderr is grepped as well and the bug is fixed.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110625&group_id=5470


From noreply@sourceforge.net  Tue Sep  5 22:00:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 5 Sep 2000 14:00:28 -0700
Subject: [Python-bugs-list] [Bug #110629] Tkinter Image names may be reused (PR#28)
Message-ID: <200009052100.OAA27574@delerium.i.sourceforge.net>

Bug #110629, was updated on 2000-Jul-31 14:08
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Tkinter Image names may be reused (PR#28)

Details: Jitterbug-Id: 28
Submitted-By: guido@python.org
Date: Wed, 14 Jul 1999 14:00:14 -0400 (EDT)
Version: 1.5.2b
OS: 


Mark Lutz wrote me:

(BTW, this will probably never surface again (I'm stressing
the image object a bit), but I think there's a problem
with using the id() of an image as its name.  I ran into
a situation where an image was drawn in the wrong place, 
because a newly allocated image object had the same id()
as one very recently reclaimed.  It's very obscure, will
only happen if you have > 1 canvas in a process and happen
to be creating and deleting images very quickly, and is
too complex for me to describe further at the moment ;-).
I worked around it by first generating image names from a
simple counter, and then prebuilding all images up front.)



====================================================================
Audit trail:
Wed Jul 14 14:00:28 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-05 14:00
By: loewis

Comment:
Fixed in patch 101424, http://sourceforge.net/patch/?func=detailpatch&patch_id=101424&group_id=5470
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110629&group_id=5470


From noreply@sourceforge.net  Tue Sep  5 22:42:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 5 Sep 2000 14:42:38 -0700
Subject: [Python-bugs-list] [Bug #110598] Fwd: Debian Bug#46993: py_compile.compile() won't compile files with CR+LF line endings (PR#101)
Message-ID: <200009052142.OAA29143@delerium.i.sourceforge.net>

Bug #110598, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Fwd: Debian Bug#46993: py_compile.compile() won't compile files with CR+LF line endings (PR#101)

Details: Jitterbug-Id: 101
Submitted-By: flight@mathi.uni-heidelberg.de
Date: Mon, 11 Oct 1999 15:10:37 +0200
Version: 1.5.2
OS: Debian GNU/Linux potato

[This was recorded as Debian bug#46993, cf.
http://www.debian.org/Bugs/db/46/46993.html]

Package: python-base
Version: 1.5.2-6
Severity: normal

On Unix systems, py_compile.compile() (and therefore compileall.py) won't
compile files with DOS/Windows lineendings (CR+LF). Commands like "import"
or "exec" will work, though.

The problem seems to be that py_compile.compile read()'s the whole file at
once and passes it as a string to __builtin__.compile(), while "import"
calls __builtin__.compile() for a file, so that __builtin__.compile seems to
do some magic while reading the file.

For a quick testcase:

  import __builtin__
  f=open("test.py","w")
  f.write('print "Hello"\015\012')
  f.close()
  f=open("test.py")
  c=f.read()
  f.close()
  __builtin__.compile(c,"test.py","exec")

results in:

  Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 9, in x
  File "<string>", line 1
    print "Hello"
                 ^
  SyntaxError: invalid syntax

while "import test" works fine and results in test.pyc.

Certainly the file.read() in py_compile.compile() isn't good enough for this
case.

    Gregor


====================================================================
Audit trail:
Mon Oct 11 18:12:13 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-30 23:28
By: mhammond

Comment:
Sorry, but I dont feel able to resolve this in time for 2.0 beta or final, so giving back to Jeremy to punt back off.  If post 2.0 is OK, give it on back!
-------------------------------------------------------

Date: 2000-Sep-05 14:42
By: loewis

Comment:
Fixed in 101425, see
http://sourceforge.net/patch/?func=detailpatch&patch_id=101425&group_id=5470
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110598&group_id=5470


From noreply@sourceforge.net  Tue Sep  5 23:00:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 5 Sep 2000 15:00:44 -0700
Subject: [Python-bugs-list] [Bug #110701] undefined symbol in custom interpeter (PR#191)
Message-ID: <200009052200.PAA29888@delerium.i.sourceforge.net>

Bug #110701, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: undefined symbol in custom interpeter (PR#191)

Details: Jitterbug-Id: 191
Submitted-By: gurney_j@efn.org
Date: Tue, 25 Jan 2000 12:33:51 -0500 (EST)
Version: 1.5.2
OS: FreeBSD 3.4R


When I try to run the following program I get an undefined symbol on
PyDict_SetString.

#include <Python.h>

void
main()
{
        Py_Initialize();
        PyRun_SimpleString("import base64\n");
        Py_Finalize();
}

I believe this is because the interpeter library doesn't reference all of the
symbols
that it may need when loading modules.  So the linker will throw out any
unecessary
symbols which happen to include PyDict_SetString.  I tried to include
PyDict_SetString into
my program, but was unable to make it work.


====================================================================
Audit trail:
Mon Feb 07 12:36:08 2000	guido	changed notes
Mon Feb 07 12:36:08 2000	guido	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Sep-05 15:00
By: loewis

Comment:
This is not a bug in Python. When linking a custom interpreter, you need
to make sure all symbols are exported to modules. On FreeBSD, you
do this by adding -Wl,--export-dynamic to the linker line.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110701&group_id=5470


From noreply@sourceforge.net  Tue Sep  5 23:14:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 5 Sep 2000 15:14:54 -0700
Subject: [Python-bugs-list] [Bug #110701] undefined symbol in custom interpeter (PR#191)
Message-ID: <200009052214.PAA30374@delerium.i.sourceforge.net>

Bug #110701, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: None
Bug Group: Not a Bug
Priority: 5
Summary: undefined symbol in custom interpeter (PR#191)

Details: Jitterbug-Id: 191
Submitted-By: gurney_j@efn.org
Date: Tue, 25 Jan 2000 12:33:51 -0500 (EST)
Version: 1.5.2
OS: FreeBSD 3.4R


When I try to run the following program I get an undefined symbol on
PyDict_SetString.

#include <Python.h>

void
main()
{
        Py_Initialize();
        PyRun_SimpleString("import base64\n");
        Py_Finalize();
}

I believe this is because the interpeter library doesn't reference all of the
symbols
that it may need when loading modules.  So the linker will throw out any
unecessary
symbols which happen to include PyDict_SetString.  I tried to include
PyDict_SetString into
my program, but was unable to make it work.


====================================================================
Audit trail:
Mon Feb 07 12:36:08 2000	guido	changed notes
Mon Feb 07 12:36:08 2000	guido	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Sep-05 15:00
By: loewis

Comment:
This is not a bug in Python. When linking a custom interpreter, you need
to make sure all symbols are exported to modules. On FreeBSD, you
do this by adding -Wl,--export-dynamic to the linker line.
-------------------------------------------------------

Date: 2000-Sep-05 15:14
By: jhylton

Comment:
On python-dev, Martin von Löwis wrote:

This is not a bug in Python. When linking a custom interpreter, you
need to make sure all symbols are exported to modules. On FreeBSD, you
do this by adding -Wl,--export-dynamic to the linker line.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110701&group_id=5470


From noreply@sourceforge.net  Wed Sep  6 00:25:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 5 Sep 2000 16:25:48 -0700
Subject: [Python-bugs-list] [Bug #112693] re behaves differently in 1.6 and 2.0 than 1.52
Message-ID: <200009052325.QAA03204@bush.i.sourceforge.net>

Bug #112693, was updated on 2000-Aug-24 20:04
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: re behaves differently in 1.6 and 2.0 than 1.52

Details: The output is diffrent when run with 1.52 when compared with 1.6 or 2.0

http://dorb.com/python/testRe.py



Follow-Ups:

Date: 2000-Aug-25 07:42
By: jhylton

Comment:
Just noting that we should resolve this bug before release.

-------------------------------------------------------

Date: 2000-Aug-28 00:34
By: effbot

Comment:
The pattern causes excessive recursion (nested repeats on a long target string).  SRE's stack check traps this, but the exception got lost on the way out.

With the current CVS version, the example gives a "maximum recursion limit exceeded".  That's an improvement, but not enough to close the bug...
-------------------------------------------------------

Date: 2000-Sep-05 16:25
By: dgallion

Comment:
Noticed a problem with a more simple pattern.

Python 2.0b1 (#2, Sep  4 2000, 11:03:25) [MSC 32 bit (Intel)] on win32
Copyright (c) 2000 BeOpen.com.
All Rights Reserved.

Copyright (c) 1995-2000 Corporation for National Research Initiatives.
All Rights Reserved.

Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam.
All Rights Reserved.
>>> buf=open('testRe.py').read()
>>> import re
>>> res= re.findall(".*",buf)
>>> len(res)
1
Python 1.5.2 (#0, Aug 12 2000, 14:54:22) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> buf=open('testRe.py').read()
>>> import re
>>> res=re.findall(".*",buf)
>>> len(res)
432

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112693&group_id=5470


From noreply@sourceforge.net  Wed Sep  6 13:09:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 05:09:27 -0700
Subject: [Python-bugs-list] [Bug #113693] freeze modulefinder broken
Message-ID: <200009061209.FAA26074@delerium.i.sourceforge.net>

Bug #113693, was updated on 2000-Sep-06 05:09
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: freeze modulefinder broken

Details: The following one-liner script can not be frozen:

import string

The traceback is included below. Line number are from revision 1.13 of modulefinder.py.

The problem appears to be related to recent changes to the import bytecodes

Traceback (most recent call last):
  File "d:\python\tools\freeze\freeze.py", line 457, in ?
    main()
  File "d:\python\tools\freeze\freeze.py", line 321, in main
    mf.import_hook(mod)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 281, in scan_code
    self.import_hook(name, m)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 281, in scan_code
    self.import_hook(name, m)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 303, in scan_code
    self.scan_code(c, m)
  File "d:\python\tools\freeze\modulefinder.py", line 281, in scan_code
    self.import_hook(name, m)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 289, in scan_code
    assert lastname is not None
AssertionError

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113693&group_id=5470


From noreply@sourceforge.net  Wed Sep  6 14:01:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 06:01:37 -0700
Subject: [Python-bugs-list] [Bug #113696] lib.pdf damaged in pdf-a4-2.0b1.tgz
Message-ID: <200009061301.GAA20580@bush.i.sourceforge.net>

Bug #113696, was updated on 2000-Sep-06 06:01
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: lib.pdf damaged in pdf-a4-2.0b1.tgz

Details: Platform: NT4 SP6, Acrobat Reader 4.05.

Tarball unpacks correctly and every other .pdf
file in it is fine; however, lib.pdf appears to
be corrupt, "can&#039;t repair", according to the
Acrobat Reader.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113696&group_id=5470


From noreply@sourceforge.net  Wed Sep  6 14:16:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 06:16:39 -0700
Subject: [Python-bugs-list] [Bug #113700] widespread bug in HTML files: lots of italics
Message-ID: <200009061316.GAA28589@delerium.i.sourceforge.net>

Bug #113700, was updated on 2000-Sep-06 06:16
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: widespread bug in HTML files: lots of italics

Details: I&#039;d already noticed this in AMK&#039;s and Moshe&#039;s doc about
"what&#039;s new in Python 2".  There&#039;s some bug in the
converter-to-HTML that, occasionally, for a big closed
bracket, outputs a </var> in front and a <var> in back
rather than vice-versa; so all the rest of the HTML is
italicized.  E.g., it shows up in built-in-funcs.html
in the description of int (x[, radix])  [possibly
later too, haven&#039;t checked].

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113700&group_id=5470


From noreply@sourceforge.net  Wed Sep  6 14:18:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 06:18:09 -0700
Subject: [Python-bugs-list] [Bug #113696] lib.pdf damaged in pdf-a4-2.0b1.tgz
Message-ID: <200009061318.GAA28623@delerium.i.sourceforge.net>

Bug #113696, was updated on 2000-Sep-06 06:01
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: lib.pdf damaged in pdf-a4-2.0b1.tgz

Details: Platform: NT4 SP6, Acrobat Reader 4.05.

Tarball unpacks correctly and every other .pdf
file in it is fine; however, lib.pdf appears to
be corrupt, "can&#039;t repair", according to the
Acrobat Reader.

Follow-Ups:

Date: 2000-Sep-06 06:18
By: aleax

Comment:
Same problem with lib.pdf (only) after downloading the
ZIP, and also in the Letter versions as opposed to A4.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113696&group_id=5470


From noreply@sourceforge.net  Wed Sep  6 15:02:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 07:02:05 -0700
Subject: [Python-bugs-list] [Bug #113704] asyncore.py / asynchat.py outdated
Message-ID: <200009061402.HAA30218@delerium.i.sourceforge.net>

Bug #113704, was updated on 2000-Sep-06 07:02
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: asyncore.py / asynchat.py outdated

Details: Sam Rushing has more recent versions of asyncore.py
and asynchat.py; the differences need to be merged into
the CVS tree.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113704&group_id=5470


From noreply@sourceforge.net  Wed Sep  6 15:05:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 07:05:05 -0700
Subject: [Python-bugs-list] [Bug #113704] asyncore.py / asynchat.py outdated
Message-ID: <200009061405.HAA30274@delerium.i.sourceforge.net>

Bug #113704, was updated on 2000-Sep-06 07:02
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: asyncore.py / asynchat.py outdated

Details: Sam Rushing has more recent versions of asyncore.py
and asynchat.py; the differences need to be merged into
the CVS tree.

Follow-Ups:

Date: 2000-Sep-06 07:05
By: akuchling

Comment:
This is also important to Zope.  I&#039;ll accept the job
of reconciling the two versions.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113704&group_id=5470


From noreply@sourceforge.net  Wed Sep  6 15:45:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 07:45:15 -0700
Subject: [Python-bugs-list] [Bug #112944] Partially initialized cPickle dumps core
Message-ID: <200009061445.HAA24574@bush.i.sourceforge.net>

Bug #112944, was updated on 2000-Aug-28 09:03
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: Partially initialized cPickle dumps core

Details: The second import of a library that failed the first time does not re-initialize the module, and returns a reference to the uninitialized module:

>>> import cPickle
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: No module named copy_reg
>>> ^P
  File "<stdin>", line 1
    
    ^
SyntaxError: invalid syntax
>>> import cPickle
>>> 

Subsequent use of the uninitialized module crashes the interpreter:

>>> cPickle.Pickler()
Segmentation fault (core dumped)

(and it happens the same way in scripts.)


Follow-Ups:

Date: 2000-Aug-29 14:30
By: gvanrossum

Comment:
The stated problem is not a bug but documented behavior.
However the fact that a partially initialized cPickle dumps core is a cPickle bug. I'll change the topic and see if I can get the cPickle author (Jim Fulton) to look at this.
-------------------------------------------------------

Date: 2000-Sep-06 07:45
By: dcjim

Comment:
The fix is pretty easy. I send Guido a new cPickle.c.

Basically, the init_stuff call needs to be moved to the top of
initcPickle and guarded, like so:

    if (init_stuff(m, d) < 0) return;

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112944&group_id=5470


From noreply@sourceforge.net  Wed Sep  6 16:43:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 08:43:07 -0700
Subject: [Python-bugs-list] [Bug #112289] NetBSD1.4.2 build issue
Message-ID: <200009061543.IAA26853@bush.i.sourceforge.net>

Bug #112289, was updated on 2000-Aug-18 19:50
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: NetBSD1.4.2 build issue

Details: the recent fileobjects.c work done for large files (tmick) appears
broken when compiled against NetBSD1.4.2.

During the final link, you get the following output:

gcc   python.o  ../libpython2.0.a   -lutil -lm  -o python
fileobject.c:280: Undefined symbol `_TELL64' referenced from text segment

Follow-Ups:

Date: 2000-Aug-18 19:55
By: none

Comment:
NOTE:  I didn't include the configure output.  If that
would be helpful, go ahead and indicate that in this
tracking system.

If tmick (or whoever) would like me to contact them directly,
I would happily do so.
-------------------------------------------------------

Date: 2000-Aug-31 08:45
By: tmick

Comment:
Sent to python-dev:

1. Who reported this bug? He talked about providing more information and I
would like to speak with him. I cannot find his email address.
2. Does anybody have a NetBSD1.4.2 (or close) machine that I can get shell
access to? Do you know if they have such a machine at SourceForge that users
can get shell access to? Or failing that can someone with such a machine give
me the full ./configure and make output and maybe run this command:
   find /usr/include -name "*" -type f | xargs -l grep -nH _TELL64
and give me the output.


-------------------------------------------------------

Date: 2000-Aug-31 08:47
By: tmick

Comment:
I got no reponse and I have no NetBSD machine on which to reproduce so, as Jeremy suggested, if I wouldn't get it by this evening then assign back to him.

Other questions:
- How old/recent is version 1.4.2 of NetBSD?
- Where is _TELL64 coming from? Not from Python code.

-------------------------------------------------------

Date: 2000-Sep-06 08:43
By: tmick

Comment:
Thanks to Brad (knotwell@NOSPAM f5 NOSPAM.com) who reported the bug I got shell access on his NetBSD 1.4.2 box to play a little bit. I found the problem but I don&#039;t have the Right (tm) fix. Here is what I found:

The _TELL64 compilation failure is for the #define TELL64 usage in fileobject.c for a 64-bit capable tell() system function. Currently this is only defined and used for Win64. The funny thing is that to get to the code section using TELL64 the NetBSD box had to (1) pass the configure test for HAVE_LARGEFILE_SUPPORT, (2) have sizeof(fpos_t) >= 8, and (3) *not* have fseeko (as required by the Single Unix Specification) or fseek64 defined.

As far as I can tell NetBSD *should* define fseeko() and ftello() if it wants to say that it supports largefiles. I *think* that you can manage it via fsetpos() and fgetpos(), which is what I did for largefile support on Win64 (although on Win64 I still relied on a 64-bit capable tell() function -- hence TELL64).  I don&#039;t have the time right now to get and verify a working fsetpos/fgetpos solution.

A quick fix is to ifdef out HAVE_LARGEFILE_SUPPORT for NetBSD 1.4.2 but I don&#039;t know the proper #define&#039;s for that. It is also ugly.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470


From noreply@sourceforge.net  Wed Sep  6 17:30:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 09:30:09 -0700
Subject: [Python-bugs-list] [Bug #113721] urllib handles proxy badly
Message-ID: <200009061630.JAA28583@bush.i.sourceforge.net>

Bug #113721, was updated on 2000-Sep-06 09:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: urllib handles proxy badly

Details: The following gives "host not found" when a proxy server is in use:

    import urllib
    w=urllib.urlopen("http://www.pythonlabs.com")

The host name is changed to "http=PROXYSERVER" and fails

This works under Python 1.5.2, but fails under Python 2.0b1

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113721&group_id=5470


From noreply@sourceforge.net  Wed Sep  6 18:24:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 10:24:18 -0700
Subject: [Python-bugs-list] [Bug #113727] Tkinter: _substitute call of getint(D) fails
Message-ID: <200009061724.KAA05220@delerium.i.sourceforge.net>

Bug #113727, was updated on 2000-Sep-06 10:24
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Tkinter: _substitute call of getint(D) fails

Details: Version: 2.0b1
OS: Solaris 2.6 Generic_105181-15 sun4m
Tcl/Tk: 8.0

All callbacks (even in the Demo code) give this:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/s/lib/python2.0/lib-tk/Tkinter.py", line 1283, in __call__
    args = apply(self.subst, args)
  File "/s/lib/python2.0/lib-tk/Tkinter.py", line 1053, in _substitute
    e.delta = getint(D)
ValueError: invalid literal for int(): D

It seems the variable D has been assigned the string value &#039;D&#039;.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113727&group_id=5470


From noreply@sourceforge.net  Wed Sep  6 19:22:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 11:22:14 -0700
Subject: [Python-bugs-list] [Bug #113733] xml package not included in windows installer
Message-ID: <200009061822.LAA00508@bush.i.sourceforge.net>

Bug #113733, was updated on 2000-Sep-06 11:22
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: xml package not included in windows installer

Details: Lib/xml/* are not installed when using BeOpen-Python-2.0b1.exe

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113733&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 00:53:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 16:53:51 -0700
Subject: [Python-bugs-list] [Bug #113760] 2.0b1: _xmlplus does not allow site xml to override Lib/xml
Message-ID: <200009062353.QAA19927@delerium.i.sourceforge.net>

Bug #113760, was updated on 2000-Sep-06 16:53
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b1: _xmlplus does not allow site xml to override Lib/xml

Details: _xmlplus is represented as a means of overriding the new standard lib xml package with a user-supplied xml package, such as the one from XML-SIG ("There's a special feature whereby a user-installed package named _xmlplus overrides the standard xmlpackage; this is intended to give the XML SIG a hook to distribute backwards-compatible updates to the standard xml package." - quote from News on BeOpen site). While this has _some_ effect, it does not work as described. Under 2.0b1, code using the xml package from the XML-SIG (installed in site-packages) will only work if the new standard xml package in lib is renamed or removed. If used with the new standard xml package, imports such as
from xml.sax import saxexts
fail. If the _xmlplus hook is used (by renaming site-packages/xml to site-packages/_xmlplus or using a symlink), the imports succeed, but later the code fails with a message stating that no parsers can be found. 

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113760&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 01:08:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 17:08:35 -0700
Subject: [Python-bugs-list] [Bug #110675] Pth: test_fork1 fails, test_thread slow (PR#383)
Message-ID: <200009070008.RAA13539@bush.i.sourceforge.net>

Bug #110675, was updated on 2000-Jul-31 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 1
Summary: Pth: test_fork1 fails, test_thread slow (PR#383)

Details: Jitterbug-Id: 383
Submitted-By: gregor@hoffleit.de
Date: Tue,  4 Jul 2000 12:07:06 -0400 (EDT)
Version: CVS version (06/04/00)
OS: Debian potato (i386)


When I use the current CVS version of Python to build on a Debian potato
system with GNU Pth 1.2.3 installed, test_fork1 fails with an error (see
below),
and test_thread takes significantly longer to complete than when I build the 
same sources with native LinuxThreads.


When running test.regrtest.main(), this happens:

  clapton:3> LD_LIBRARY_PATH=`pwd` ./python 
  Python 2.0b1 (#0, Jul  4 2000, 17:06:15)  [GCC 2.95.2 20000220 (Debian
GNU/Linux)] on linux2
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
  >>> from test import regrtest
  >>> regrtest.main()
  test_grammar
  test_opcodes
...
  test_extcall
  test_fcntl
  test_fork1
  test test_fork1 crashed -- exceptions.AssertionError : 
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 30, in f
      alive[id] = os.getpid()
  AttributeError: 'None' object has no attribute 'getpid'
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 32, in f    time.sleep(SHORTSLEEP)
  TypeError: illegal argument type for built-in operation
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 30, in f
      alive[id] = os.getpid()
  AttributeError: 'None' object has no attribute 'getpid'
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 30, in f
      alive[id] = os.getpid()
  AttributeError: 'None' object has no attribute 'getpid'
  test_format
  test_gc
...


When running test.test_fork1(), I get this:

  clapton:3> LD_LIBRARY_PATH=`pwd` ./python 
  Python 2.0b1 (#0, Jul  4 2000, 17:06:15)  [GCC 2.95.2 20000220 (Debian
GNU/Linux)] on linux2
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
  >>> from test import test_fork1
  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    File "./Lib/test/test_fork1.py", line 68, in ?
      main()
    File "./Lib/test/test_fork1.py", line 44, in main
      assert a == range(NUM_THREADS)
  AssertionError
  >>>


test_thread takes very long to complete (5 min compared to 40 sec with 
LinuxThreads); when you look at the following log, you'll see that it tends
to calls the threads serially !?

clapton:3> LD_LIBRARY_PATH=`pwd` ./python 
Python 2.0b1 (#0, Jul  4 2000, 17:06:15)  [GCC 2.95.2 20000220 (Debian
GNU/Linux)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> from test import test_thread
creating task 1
creating task 2
creating task 3
task 1 will run for 2.1 sec
task 1 done
creating task 4
task 2 will run for 3.2 sec
creating task 5
task 2 done
creating task task 3 will run for 9.1 6
sec
task 3 done
creating task 7
task 4 will run for 2.5 sec
task 4 done
creating task 8
task 5 will run for 0.9 sec
task 5 done
creating task 9
task 6 will run for 7.4 sec
task 6 done
creating task 10
waiting for all tasks to complete
task 7 will run for 5.3 sec
task 7 done
task 8 will run for 2.6 sec
task 8 done
task 9 will run for 2.7 sec
task 9 done
task 10 will run for 0.9 sec
task 10 done
all tasks done

*** Barrier Test ***
task 0 will run for 0.0 sec
task 0 entering barrier 0
task 1 will run for 6.2 sec
task 1 entering barrier 0
task 7 will run for 7.0 sec
task 7 entering barrier 0
task 3 will run for 5.9 sec
task 3 entering barrier 0
task 4 will run for 4.5 sec
task 4 entering barrier 0
task 5 will run for 9.2 sec
task 5 entering barrier 0
task 6 will run for 1.4 sec
task 6 entering barrier 0
task 2 will run for 6.0 sec
task 2 entering barrier 0
task 8 will run for 2.4 sec
task 8 entering barrier 0
task 9 will run for 9.6 sec
task 9 entering barrier 0
task 9 leaving barrier 0
task 0 leaving barrier 0
task task 1 leaving barrier 0
0 will run for 0.0 sec
task 0 entering barrier 1
task 7 leaving barrier 0
task 9 will run for 0.8 sec
task 9 entering barrier task 3 leaving barrier 0
1
task 1 task 4 leaving barrier 0
will run for 6.1 sec
task 5 leaving barrier 0
task 1 entering barrier 1
task 6 leaving barrier 0
task 7 will run for 7.9 sec
task 2 leaving barrier 0
task 7 entering barrier 1
task 3 task 8 leaving barrier 0
will run for 7.8 sec
task 3 entering barrier 1
task 4 will run for 5.7 sec
task 4 entering barrier 1
task 5 will run for 2.0 sec
task 5 entering barrier 1
task 6 will run for 0.5 sec
task 6 entering barrier 1
task 2 will run for 7.4 sec
task 2 entering barrier 1
task 8 will run for 1.0 sec
task 8 entering barrier 1
task 8 leaving barrier 1
task 7 leaving barrier 1
task 9 leaving barrier 1
task 1 leaving barrier 1
task 8 will run for 6.9 sec
task 0 leaving barrier 1
task 8 entering barrier 2
task 0 will run for task 4 leaving barrier 1 0.0 sec

task 7 will run for 4.3 sec task 0 entering barrier
2
task 3 leaving barrier 1
task 7 entering barrier 2
task 5 leaving barrier 1
task 6 leaving barrier 1 task 9 will run for
8.2 sec
task task 2 leaving barrier 9 entering barrier 2
1
task 5 will run for 8.9 sec
task 5 entering barrier 2
task 2 will run for 8.3 sec
task 2 entering barrier 2
task 3 will run for 4.5 sec
task 3 entering barrier 2
task 1 will run for 7.0 sec
task 1 entering barrier 2
task 6 will run for 1.9 sec
task 6 entering barrier 2
task 4 will run for 0.2 sec
task 4 entering barrier 2
task 4 leaving barrier 2
task 8 leaving barrier 2
task 9 leaving barrier 2
task 7 leaving barrier 2
task 5 leaving barrier 2
task 0 leaving barrier 2
task 2 leaving barrier 2
task 3 leaving barrier 2
task 1 leaving barrier 2
task 6 leaving barrier 2
all tasks done



while this is the log of the same test with Python 1.5.2 and LinuxThreads:

clapton:3> python
Python 1.5.2 (#0, Apr  3 2000, 14:46:48)  [GCC 2.95.2 20000313 (Debian
GNU/Linux)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from test import test_thread
creating task 1
creating task 2
creating task 3
creating task 4
creating task 5
creating task 6
creating task 7
creating task 8
creating task 9
creating task 10
waiting for all tasks to complete
task 1 will run for 8.9 sec
task 2 will run for 8.3 sec
task 3 will run for 9.1 sec
task 5 will run for 6.0 sec
task 4 will run for 7.5 sec
task 6 will run for 4.7 sec
task 7 will run for 4.2 sec
task 8 will run for 7.0 sec
task 9 will run for 8.7 sec
task 10 will run for 9.5 sec
task 7 done
task 6 done
task 5 done
task 8 done
task 4 done
task 2 done
task 9 done
task 1 done
task 3 done
task 10 done
all tasks done

*** Barrier Test ***
task 0 will run for 0.0 sec
task 1 will run for 2.8 sec
task 0 entering barrier 0
task 2 will run for 5.3 sec
task 3 will run for 9.2 sec
task 5 will run for 8.0 sec
task 4 will run for 8.9 sec
task 6 will run for 5.0 sec
task 7 will run for 1.3 sec
task 8 will run for 5.6 sec
task 9 will run for 4.7 sec
task 7 entering barrier 0
task 1 entering barrier 0
task 9 entering barrier 0
task 6 entering barrier 0
task 2 entering barrier 0
task 8 entering barrier 0
task 5 entering barrier 0
task 4 entering barrier 0
task 3 entering barrier 0
task 3 leaving barrier 0
task 3 will run for 0.1 sec
task 0 leaving barrier 0
task 0 will run for 0.0 sec
task 7 leaving barrier 0
task 7 will run for 6.6 sec
task 1 leaving barrier 0
task 1 will run for 1.0 sec
task 9 leaving barrier 0
task 9 will run for 8.2 sec
task 6 leaving barrier 0
task 6 will run for 1.0 sec
task 2 leaving barrier 0
task 2 will run for 9.2 sec
task 8 leaving barrier 0
task 8 will run for 4.4 sec
task 5 leaving barrier 0
task 5 will run for 9.6 sec
task 4 leaving barrier 0
task 4 will run for 1.7 sec
task 0 entering barrier 1
task 3 entering barrier 1
task 1 entering barrier 1
task 6 entering barrier 1
task 4 entering barrier 1
task 8 entering barrier 1
task 7 entering barrier 1
task 9 entering barrier 1
task 2 entering barrier 1
task 5 entering barrier 1
task 5 leaving barrier 1
task 5 will run for 6.6 sec
task 0 leaving barrier 1
task 0 will run for 0.0 sec
task 3 leaving barrier 1
task 3 will run for 8.5 sec
task 1 leaving barrier 1
task 1 will run for 0.1 sec
task 6 leaving barrier 1
task 6 will run for 4.7 sec
task 4 leaving barrier 1
task 4 will run for 4.7 sec
task 8 leaving barrier 1
task 8 will run for 1.7 sec
task 7 leaving barrier 1
task 7 will run for 1.8 sec
task 9 leaving barrier 1
task 9 will run for 2.8 sec
task 2 leaving barrier 1
task 2 will run for 3.3 sec
task 0 entering barrier 2
task 1 entering barrier 2
task 8 entering barrier 2
task 7 entering barrier 2
task 9 entering barrier 2
task 2 entering barrier 2
task 6 entering barrier 2
task 4 entering barrier 2
task 5 entering barrier 2
task 3 entering barrier 2
task 3 leaving barrier 2
task 0 leaving barrier 2
task 1 leaving barrier 2
task 8 leaving barrier 2
task 7 leaving barrier 2
task 9 leaving barrier 2
task 2 leaving barrier 2
task 6 leaving barrier 2
task 4 leaving barrier 2
task 5 leaving barrier 2
all tasks done
>>> 





====================================================================
Audit trail:
Tue Jul 11 08:24:22 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-23 10:31
By: jhylton

Comment:
Another report of test_fork1 problems.  Plan to resolve before 2.0b1.

-------------------------------------------------------

Date: 2000-Aug-23 10:36
By: tim_one

Comment:
Jeremy, my chances of helping someone with a problem specific to "Debian potato system with GNU Pth 1.2.3" are nil.  Assigned back to you since you seem to believe it's feasible <wink>.
-------------------------------------------------------

Date: 2000-Aug-31 14:53
By: jhylton

Comment:
Haven't heard back from the submittor.  This sounds like a problem with a buggy GNU Pth package; not a Python bug.

-------------------------------------------------------

Date: 2000-Sep-01 14:15
By: none

Comment:
I submitted the original pth support. pth has what I would consider a bug in that signals do not interrupt sleep(), usleep(), or select(), the latter being what Python uses to sleep. I'm going to look at this some more myself as soon as I can get the current CVS to configure with pth. -- andy@dustman.net
-------------------------------------------------------

Date: 2000-Sep-01 14:22
By: none

Comment:
Another thing which may be a factor in this case: Since pth threads are user-space and so all run in the same process, the test used in signalmodule.c:125 doesn't work, i.e.

        if (getpid() == main_pid) {

It probably needs to be something more like this:

        if (PyThread_get_thread_ident() != main_thread) {

I submitted a patch to fix this around the time of the CNRI split, so it probably got lost.

-- andy@dustman.net
-------------------------------------------------------

Date: 2000-Sep-06 17:08
By: adustman

Comment:
I submitted patch 101437 which should fix this.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110675&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 01:12:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 17:12:12 -0700
Subject: [Python-bugs-list] [Bug #112944] Partially initialized cPickle dumps core
Message-ID: <200009070012.RAA20622@delerium.i.sourceforge.net>

Bug #112944, was updated on 2000-Aug-28 09:03
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: Partially initialized cPickle dumps core

Details: The second import of a library that failed the first time does not re-initialize the module, and returns a reference to the uninitialized module:

>>> import cPickle
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: No module named copy_reg
>>> ^P
  File "<stdin>", line 1
    
    ^
SyntaxError: invalid syntax
>>> import cPickle
>>> 

Subsequent use of the uninitialized module crashes the interpreter:

>>> cPickle.Pickler()
Segmentation fault (core dumped)

(and it happens the same way in scripts.)


Follow-Ups:

Date: 2000-Aug-29 14:30
By: gvanrossum

Comment:
The stated problem is not a bug but documented behavior.
However the fact that a partially initialized cPickle dumps core is a cPickle bug. I'll change the topic and see if I can get the cPickle author (Jim Fulton) to look at this.
-------------------------------------------------------

Date: 2000-Sep-06 07:45
By: dcjim

Comment:
The fix is pretty easy. I send Guido a new cPickle.c.

Basically, the init_stuff call needs to be moved to the top of
initcPickle and guarded, like so:

    if (init_stuff(m, d) < 0) return;

-------------------------------------------------------

Date: 2000-Sep-06 17:12
By: gvanrossum

Comment:
Jim Fulton sent a simple fix.  Checked in.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112944&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 01:18:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 17:18:02 -0700
Subject: [Python-bugs-list] [Bug #110624] float("1.0e-309") inconsistency on win32 (PR#245)
Message-ID: <200009070018.RAA20849@delerium.i.sourceforge.net>

Bug #110624, was updated on 2000-Jul-31 14:08
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: Remind
Bug Group: None
Priority: 5
Summary: float("1.0e-309") inconsistency on win32 (PR#245)

Details: Jitterbug-Id: 245
Submitted-By: sde@recombinant.demon.co.uk
Date: Wed, 22 Mar 2000 16:13:26 -0500 (EST)
Version: 1.5.2
OS: win32


#! /usr/bin/python

# Inconsistent behaviour.

# Python 1.5.2 win32 fails the second print (why not both?)
# other versions print both expressions

#              Ok  Python 1.5.2 on SuSE Linux 6.3
#              Ok  JPython 1.1 on java1.1.7B
# Partial failure  Python 1.5.2 win32

print eval("float(1.0e-309)")
print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309




====================================================================
Audit trail:
Fri Mar 24 16:42:36 2000	guido	changed notes
Fri Mar 24 16:42:36 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:08
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Thu, 23 Mar 2000 01:43:30 -0500

> -----Original Message-----
> From: python-bugs-list-admin@python.org
> [mailto:python-bugs-list-admin@python.org]On Behalf Of
> sde@recombinant.demon.co.uk
> Sent: Wednesday, March 22, 2000 4:13 PM
> To: python-bugs-list@python.org
> Cc: bugs-py@python.org
> Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32
> (PR#245)
>
>
> Full_Name: Stephen D Evans
> Version: 1.5.2
> OS: win32
> Submission from: recombinant.demon.co.uk (212.229.73.7)
>
>
> #! /usr/bin/python
>
> # Inconsistent behaviour.
>
> # Python 1.5.2 win32 fails the second print (why not both?)
> # other versions print both expressions
>
> #              Ok  Python 1.5.2 on SuSE Linux 6.3
> #              Ok  JPython 1.1 on java1.1.7B
> # Partial failure  Python 1.5.2 win32
>
> print eval("float(1.0e-309)")
> print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309

First note that these don't do the same thing:  the first passes a float to
"float", the second passes a string to "float".  Change the first to

    print eval("float('1.0e-309')")

and it gives the same bogus error as the second one.

Then it turns out the error is Microsoft's fault.  This tiny C program shows
the bug:

#include <errno.h>
#include <stdlib.h>
#include <stdio.h>

void
main()
{
    double x;
    char* dontcare;
    errno = 0;
    x = strtod("1.0e-309", &dontcare);
    printf("errno after = %d\n", errno);
    printf("x after = %g\n", x);
}

This prints

    errno after = 34
    x after = 0

when compiled & linked with MS's VC5; don't know about VC6.  Same thing for
"1.0e-308".  Works fine for "1.0e-307".  Doubt this will get fixed before MS
fixes their library.




-------------------------------------------------------

Date: 2000-Jul-31 14:08
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Fri, 24 Mar 2000 04:51:57 -0500

> > Full_Name: Stephen D Evans
> > Version: 1.5.2
> > OS: win32
> > Submission from: recombinant.demon.co.uk (212.229.73.7)
> >
> >
> > #! /usr/bin/python
> >
> > # Inconsistent behaviour.
> >
> > # Python 1.5.2 win32 fails the second print (why not both?)
> > # other versions print both expressions
> >
> > #              Ok  Python 1.5.2 on SuSE Linux 6.3
> > #              Ok  JPython 1.1 on java1.1.7B
> > # Partial failure  Python 1.5.2 win32
> >
> > print eval("float(1.0e-309)")
> > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309
> 
> First note that these don't do the same thing:  the first passes a float to
> "float", the second passes a string to "float".  Change the first to
> 
>     print eval("float('1.0e-309')")
> 
> and it gives the same bogus error as the second one.
> 
> Then it turns out the error is Microsoft's fault.  This tiny C program shows
> the bug:
> 
> #include <errno.h>
> #include <stdlib.h>
> #include <stdio.h>
> 
> void
> main()
> {
>     double x;
>     char* dontcare;
>     errno = 0;
>     x = strtod("1.0e-309", &dontcare);
>     printf("errno after = %d\n", errno);
>     printf("x after = %g\n", x);
> }
> 
> This prints
> 
>     errno after = 34
>     x after = 0
> 
> when compiled & linked with MS's VC5; don't know about VC6.  Same thing for
> "1.0e-308".  Works fine for "1.0e-307".  Doubt this will get fixed before MS
> fixes their library.

The bizarre thing is that this is broken the same way on Solaris:

>>> 1.0e-309
1.0000000000000019e-309
>>> float("1.0e-309")
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: float() literal too large: 1.0e-309
>>>

I looked and it turns out that Python uses atof() in the first case
(string literal encountered in a Python expression) and strtod() in
the second case (string passed to float()).

Apparently strtod() and atof() differ in implementation, even though
the Solaris man page says "The atof(str) function call is equivalent
to strtod(str, (char **)NULL)."

We could fix this by changing float() to do its own syntax checking
and then use atof()...  Is it worth it?

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Jul-31 14:08
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Fri, 24 Mar 2000 22:48:50 -0500

[atof and strtod act differently given denormals on both Windows &
 Solaris]

[Guido]
> ...
> Apparently strtod() and atof() differ in implementation, even though
> the Solaris man page says "The atof(str) function call is equivalent
> to strtod(str, (char **)NULL)."

Ya, their man page is lying.  atof() existed in the mists of prehistory and
typically did no error checking at all.  IIRC, ANSI C introduced strtod(),
which generally got implemented as a layer of error-checking around atof.

I have to take it back that this is a bug in MS's strtod:  DBL_MIN is MS's
limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero
inputs with absolute value smaller than that.

> We could fix this by changing float() to do its own syntax checking
> and then use atof()...  Is it worth it?

Depends on your goal <wink>:  do you want more extreme cases, like 1e-500,
to blow up (strtod) or underflow to 0 (atof)?  The example in the original
test case is subtler because atof made it *appear* to be "a regular old
number"; in fact, it's not, it's small enough that it falls into 754's
"denormalized" range.  This means the conversion loses some extraordinary
amount of-- but not all --information (whereas 1e-500 is below even the
denorm range:  conversion loses all information).

Without a coherent strategy for dealing with 754 issues, it's hard to decide
which is better.  Since strtod() is more restrictive, if this is worth
bothering about at all now (for P3K I think 754 needs to be taken
seriously), I actually recommend changing  current atof() calls to use
native strtod() instead.




-------------------------------------------------------

Date: 2000-Jul-31 14:08
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Fri, 24 Mar 2000 23:14:29 -0500

> [atof and strtod act differently given denormals on both Windows &
>  Solaris]
> 
> [Guido]
> > ...
> > Apparently strtod() and atof() differ in implementation, even though
> > the Solaris man page says "The atof(str) function call is equivalent
> > to strtod(str, (char **)NULL)."

[Tim]
> Ya, their man page is lying.  atof() existed in the mists of prehistory and
> typically did no error checking at all.  IIRC, ANSI C introduced strtod(),
> which generally got implemented as a layer of error-checking around atof.
> 
> I have to take it back that this is a bug in MS's strtod:  DBL_MIN is MS's
> limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero
> inputs with absolute value smaller than that.
> 
> > We could fix this by changing float() to do its own syntax checking
> > and then use atof()...  Is it worth it?
> 
> Depends on your goal <wink>:  do you want more extreme cases, like 1e-500,
> to blow up (strtod) or underflow to 0 (atof)?  The example in the original
> test case is subtler because atof made it *appear* to be "a regular old
> number"; in fact, it's not, it's small enough that it falls into 754's
> "denormalized" range.  This means the conversion loses some extraordinary
> amount of-- but not all --information (whereas 1e-500 is below even the
> denorm range:  conversion loses all information).
> 
> Without a coherent strategy for dealing with 754 issues, it's hard to decide
> which is better.  Since strtod() is more restrictive, if this is worth
> bothering about at all now (for P3K I think 754 needs to be taken
> seriously), I actually recommend changing  current atof() calls to use
> native strtod() instead.

Hm, I'm not so sure.  Suppose I'm writing a program that reads a data
files generated by some Fortran program.  The Fortran program is
giving me points to plot for example.  If Fortran manages to output
1e-500, wouldn't it make more sense if I rounded that to zero instead
of rejecting it?  After all, after converting to plot precision it's
going to be zero anyway.

This way I could almost defend using strtod() for literals in
Python source code (where it makes more sense to warn about underflow)
but atof() for input.  Except that of course input could conceivably
be using eval()...

Another argument for turning underflow into zero is that that also
happens in regular arithmetic:

>>> 0.1**2**8
1.0000000000000275e-256
>>> 0.1**2**9
0.0

I like this uniform behavior: overflow -> exception, underflow ->
zero.  My calculator does this too.

Am I hopelessly naive about this?  What else can we do?  What control
does C give?  What does sscanf() do?

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Jul-31 14:08
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Fri, 24 Mar 2000 23:53:10 -0500

"In the face of ambiguity, refuse the temptation to guess".

That's one of the Pythonic Theses you're tempted to ignore too often <wink>.

Part of taking 754 seriously is that 754 gives the user complete control
over what happens in case of exceptions (including underflow):  ignore them,
raise a fatal error, or simply set a flag saying it occurred.
Unfortunately, we have to wait for C9x until there's a portable way to get
at that stuff.  Before then, it requires wildly varying platform-specific
hair.

> Hm, I'm not so sure.  Suppose I'm writing a program that reads a data
> files generated by some Fortran program.  The Fortran program is
> giving me points to plot for example.  If Fortran manages to output
> 1e-500, wouldn't it make more sense if I rounded that to zero instead
> of rejecting it?

This *may* make good sense if Python had certain knowledge that the program
is merely going to plot the points, but probably not even then.  That is,
"insignificantly small" is relative to the application, and e.g. for all we
know the Fortran program generated a million doubles *all* in the range
[1e-500, 10e-500]:  the intended plot of the data could very well be a
pointillistic version of the Mona Lisa rather than a straight line.

> After all, after converting to plot precision it's
> going to be zero anyway.

As above, this conclusion relies on the dubious assumption that 1e-500 is
very much smaller than the other values.

> This way I could almost defend using strtod() for literals in
> Python source code (where it makes more sense to warn about underflow)
> but atof() for input.  Except that of course input could conceivably
> be using eval()...
>
> Another argument for turning underflow into zero is that that also
> happens in regular arithmetic:
>
> >>> 0.1**2**8
> 1.0000000000000275e-256
> >>> 0.1**2**9
> 0.0

Which is often desired but sometimes a disaster -- the language simply can't
guess.  On whatever machine you ran this on, it almost certainly set the
"underflow happened" flag but continued on because the underflow exception
was masked out by default.

> I like this uniform behavior: overflow -> exception, underflow ->
> zero.  My calculator does this too.

Not mine <wink>.  Really, whether underflow gripes is controlled by a
user-settable flag on high end HP calculators.  Note too that neither does
float *overflow* raise an exception under most Pythons today:

D:\Python>python
Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> 1e500
1.#INF
>>> 1e200**2
1.#INF
>>>

I personally favor raising exceptions (by default) on 754's overflow, divide
by 0, and invalid operation conditions, while (again by default) letting
underflow and inexact pass without comment.  But it again requires fiddling
the HW's 754 control registers to make that happen.  P3K, not now.

> Am I hopelessly naive about this?

Not *entirely* hopeless, but close <wink>.  If we ever talk about it for an
hour, I'll convince you of the futility of fighting 754.  They beat all
resistance out of me in a mere decade <0.5 wink>.

> What else can we do?

Not much!  Switching uniformly to either atof() or strtod() would be OK by
me for now, although I don't think patching over the current inconsistency
buys enough bang for the buck to be worth the effort.

> What control does C give?

None, until C9X.

> What does sscanf() do?

I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI
C's numerics fight the *right* thing to do now just about every step of the
way.  C9x is supposed to fix all that.

In the meantime, I think what JPython does is much more interesting (but
don't know what that is):  whatever we do here should be consistent with The
Other Python too, and Java has a much better 754 story than ANSI C.  754 is
here to stay, but the last iteration of ANSI C isn't.  Best guess is that
Java acts more like atof than strtod in this case.




-------------------------------------------------------

Date: 2000-Jul-31 14:08
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Sat, 25 Mar 2000 14:15:54 -0500

> "In the face of ambiguity, refuse the temptation to guess".
> 
> That's one of the Pythonic Theses you're tempted to ignore too often <wink>.
> 
> Part of taking 754 seriously is that 754 gives the user complete control
> over what happens in case of exceptions (including underflow):  ignore them,
> raise a fatal error, or simply set a flag saying it occurred.
> Unfortunately, we have to wait for C9x until there's a portable way to get
> at that stuff.  Before then, it requires wildly varying platform-specific
> hair.

OK, so let's stick with the defaults that 754 presecribes until we can
give the user control.  That's the purpose of defaults, right?

> > Hm, I'm not so sure.  Suppose I'm writing a program that reads a data
> > files generated by some Fortran program.  The Fortran program is
> > giving me points to plot for example.  If Fortran manages to output
> > 1e-500, wouldn't it make more sense if I rounded that to zero instead
> > of rejecting it?
> 
> This *may* make good sense if Python had certain knowledge that the program
> is merely going to plot the points, but probably not even then.  That is,
> "insignificantly small" is relative to the application, and e.g. for all we
> know the Fortran program generated a million doubles *all* in the range
> [1e-500, 10e-500]:  the intended plot of the data could very well be a
> pointillistic version of the Mona Lisa rather than a straight line.

OK, forget the example.

> > After all, after converting to plot precision it's
> > going to be zero anyway.
> 
> As above, this conclusion relies on the dubious assumption that 1e-500 is
> very much smaller than the other values.

I think even 754 tells us that 1e-500 is smaller than what we normally
need to deal with.

> > This way I could almost defend using strtod() for literals in
> > Python source code (where it makes more sense to warn about underflow)
> > but atof() for input.  Except that of course input could conceivably
> > be using eval()...
> >
> > Another argument for turning underflow into zero is that that also
> > happens in regular arithmetic:
> >
> > >>> 0.1**2**8
> > 1.0000000000000275e-256
> > >>> 0.1**2**9
> > 0.0
> 
> Which is often desired but sometimes a disaster -- the language simply can't
> guess.  On whatever machine you ran this on, it almost certainly set the
> "underflow happened" flag but continued on because the underflow exception
> was masked out by default.

Again: 754 gives a default.  I want to conform to the default -- it's
better to provide control, but even when we provide control, there will
still be default behavior, and (if I understand 754 correctly) the
default is not to interrupt for underflow.

> > I like this uniform behavior: overflow -> exception, underflow ->
> > zero.  My calculator does this too.
> 
> Not mine <wink>.  Really, whether underflow gripes is controlled by a
> user-settable flag on high end HP calculators.  Note too that neither does
> float *overflow* raise an exception under most Pythons today:
> 
> D:\Python>python
> Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> 1e500
> 1.#INF
> >>> 1e200**2
> 1.#INF
> >>>

Oops, you're right.  Must be another 754 default behavior!

> I personally favor raising exceptions (by default) on 754's overflow, divide
> by 0, and invalid operation conditions, while (again by default) letting
> the HW's 754 control registers to make that happen.  P3K, not now.

I would personally also prefer an exception for overflow.  You don't
say what you want for underflow though.  I still like silent underflow
to zero by default.

> > Am I hopelessly naive about this?
> 
> Not *entirely* hopeless, but close <wink>.  If we ever talk about it for an
> hour, I'll convince you of the futility of fighting 754.  They beat all
> resistance out of me in a mere decade <0.5 wink>.

I'm not fighting it.  Say the ideal Python has full user control over
fp exceptions.  What should the defaults be?  Python 1.6 should have
the same defaults, even if it doesn't have the controls.

> > What else can we do?
> 
> Not much!  Switching uniformly to either atof() or strtod() would be OK by
> me for now, although I don't think patching over the current inconsistency
> buys enough bang for the buck to be worth the effort.
> 
> > What control does C give?
> 
> None, until C9X.
> 
> > What does sscanf() do?
> 
> I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI
> C's numerics fight the *right* thing to do now just about every step of the
> way.  C9x is supposed to fix all that.
> 
> In the meantime, I think what JPython does is much more interesting (but
> don't know what that is):  whatever we do here should be consistent with The
> Other Python too, and Java has a much better 754 story than ANSI C.  754 is
> here to stay, but the last iteration of ANSI C isn't.  Best guess is that
> Java acts more like atof than strtod in this case.

Bingo.  Indeed it does.  1e500 prints as Infinity; 1e-500 is 0.0,
either as literal or when converted from a string.

I'll change float() to use atof().

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Jul-31 14:08
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Tue, 4 Apr 2000 00:29:01 -0400

[Guido]
> OK, so let's stick with the defaults that 754 presecribes until we can
> give the user control.  That's the purpose of defaults, right?

In every world other 754 (see below), but we really have no choice now
(because C doesn't give us any control now).

> I think even 754 tells us that 1e-500 is smaller than what we normally
> need to deal with.

Well, there is no 1e-500 under 754, which is why there's some reason to at
least warn about it (if the user wanted 0, why didn't they type 0?).

> Again: 754 gives a default.  I want to conform to the default -- it's
> better to provide control, but even when we provide control, there will
> still be default behavior, and (if I understand 754 correctly) the
> default is not to interrupt for underflow.

The 754 default is never to raise an exception no matter what, whether
overflow, underflow, invalid operation (like sqrt(-4)), or divide by 0.  So
Python's current behavior wrt these two is non-conforming:

    math.sqrt(-4)
    1. / 0.

However, 754 is primarily a HW std, and the defaults were prescribed by a
committee of HW geeks and math library authors.  They were caught totally
off guard by how long it took for languages to provide the control features
the std also mandates -- for "regular users" it's plainly insane to avoid
griping about the two above, and it was never 754's intent to let them pass
silently for regular users.

Note that Java has been skewered mercilessly by Kahan (Mr. 754 Himself) for
accepting the defaults but not providing the also-mandated control
functions.  The std is subtler than it appears, and all the fiddly bits are
really needed.

>> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>> >>> 1e500
>> 1.#INF
>> >>> 1e200**2
>> 1.#INF
>> >>>

> Oops, you're right.  Must be another 754 default behavior!

Right.

> I would personally also prefer an exception for overflow.  You don't
> say what you want for underflow though.  I still like silent underflow
> to zero by default.

754 defines (almost) everything:  underflow when the underflow exception is
masked out must deliver a zero with the same sign as the infinite-precision
result.

> I'm not fighting it.

You will <wink>; e.g., returning 1 for "x == x" is incorrect when x is a
NaN.

> Say the ideal Python has full user control over fp exceptions.  What
> should the defaults be?

IMO, exception on overflow, divide-by-0 and invalid operation.  Let
underflow and inexact pass silently.  That's what I implemented at KSR, and
customers were *very* much happier with that than with the 754 defaults.  Of
course I also implemented all the 754 control and status inquiry functions,
so the one 754-savvy programmer per site was happy too (they need the
control to write robust numerical libraries for everyone else to use -- the
*true* purpose of the 754 HW defaults).

> Python 1.6 should have the same defaults, even if it doesn't have the
> controls.

This is a big project, as there's no portable way even to detect fp overflow
now.  The math libraries should play along too.

> I'll change float() to use atof().

OK by me!




-------------------------------------------------------

Date: 2000-Aug-03 05:43
By: twouters

Comment:
I *think* this one is fixed and closed. It looks like Guido promises to fix this, in any case, and it looks done.

-------------------------------------------------------

Date: 2000-Aug-10 11:48
By: gvanrossum

Comment:
No, it's not fixed, but it is platform dependent how it behaves.
The conclusion was that we should use atof() everywhere, and write a separate syntax checker (since atof() stops at the first invalid character).
I made a start at a syntax checker but then got distracted. Here's my code:

static char *
floatsyntax(char *s)
{
	/* Check for valid floating point syntax:
	   space*
	   [sign]
	   (digit+ [period digit*] | period digit+)
	   [(e|E) [sign] digit+]
	   space*
	*/
	int digits, period;

	while (isspace(*s))
		s++;
	if (*s == '+' || *s == '-')
		s++;
	digits = period = 0;
	for (;;) {
		if (isdigit(*s))
			digits++;
		else if (*s == '.') {
			if (period)
				return NULL;
			period++;
		}
		else
			break;
	}
	if (!digits)
		return NULL;
	if (*s == 'e' || *s == 'E') {
		s++;
		if (*s == '+' || *s == '-')
			s++;
		digits = 0;
		while (isdigit(*s))
			digits++;
		if (!digits)
			return NULL;
	}
	return s;
}

-------------------------------------------------------

Date: 2000-Aug-10 11:51
By: gvanrossum

Comment:
Shit. SF removes leading whitespace. Oh well, mail me for a properly formatted version of that code.
-------------------------------------------------------

Date: 2000-Aug-10 21:57
By: tim_one

Comment:
It's curious that in the change mail SF generated, leading indentation was *not* lost.  This must be a browser display thing.
Anyway, by eyeball the syntax checker has two bugs:

1. Infinite loop when looking at an exponent.

x   while (isdigit(*s)) digits++; 

should be

x   while (isdigit(*s)) {digits++; s++;)

2. Like atof, stops at an invalid character.  Before the

x   return s;

it should have, e.g.,

x   while (ispace(*s)) ++s;
x   if (*s) return NULL;

although I'm not sure what the assumptions are about the input to this function.

-------------------------------------------------------

Date: 2000-Aug-27 11:38
By: gvanrossum

Comment:
I'm mailing Tim a fixed version of floatsyntax().
-------------------------------------------------------

Date: 2000-Aug-30 00:39
By: tim_one

Comment:
I'm afraid the code here is a freakin' mess.  No wonder Guido assigned it to me <0.3 wink>.  Turnabout is fair play, so I'm assigning it back to him (for Pronouncements, or at least to alert him what's going on here).

I *think* you intended to change the guts of PyFloat_FromString.  Which appears to be a so-far undocumented public API function, with a strtod-like prototype, and where nobody calls it with anything but NULL for the 2nd argument.  Does the signature of this have to remain the same, or can I toss the 2nd argument?  Or even define it to do something useful <wink>?  Note that in the Unicode case, pend is set to point into stack trash!

Python has its own strtod.c and atof.c files too.  Are these really needed, or can I toss those as well?  (They're not used on Windows, but I don't understand the layers of Unix config.)  They're both ANSI std, so I don't think we should be supplying our own anymore (besides which, they suck numerically).

Bad news:  our strategy for fixing this bug relies on atof() behavior that's explicitly not defined by the std (if strtod sets errno on a given input, the result of atof on that same input is undefined).  Let's assume from here on that we're just lucky.

Note that complex_from_string (bltinmodule.c) does its own by-hand parsing, again calling strtod directly, so the bug here will just pop up there too.

Ditto for load_float in cpickle.c (we can *write out* flost strings that strtod won't read back in -- in effect, that *is* this bug, in another guise).

Ditto for strop_atof in stropmodule.c.

If we *don't* assume we're lucky, there are about 6 calls to atof that are vulnerable too.

Unfortunately, C did a bad job of defining float<->string facilities, and C's problems have propagated throughout Python (i.e., wherever atof or strtod are called).

Note that atof/strtod both get much hairier in C99 (they sprout new ways to spell NaN and Inf, and support a new binary floating-point notation too).  The Python code calling these guys now doesn't know anything about that, so it will again be a distributed mess to fix all the call sites.

I suggest there should be exactly one routine in the entire source tree that converts strings to doubles, exactly one in the other direction too; and outside of the former, calls to atof and strtod should be strictly banned.  C is a mess here, C99 is less of a mess but much more complex, and we can't afford to have the mess or the complexity spread throughout the codebase.
-------------------------------------------------------

Date: 2000-Sep-06 17:18
By: gvanrossum

Comment:
Back to Tim.

- You can ignore strtod.c and atof.c; these aren't used *except* on platforms that don't have them in libc. (Are there any left? It used to be necessary for some, but that was almost 10 years ago.)

- Let's not change existing APIs, even if they aren't documented.

- Let's assume we're "lucky".

- I agree with your proposed solution: one function each way. Go ahead! This is fine for 2.0b1.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110624&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 02:26:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 18:26:03 -0700
Subject: [Python-bugs-list] [Bug #113773] Python 2.0b1 selectmodule compile error under Redhat 5.2
Message-ID: <200009070126.SAA23186@delerium.i.sourceforge.net>

Bug #113773, was updated on 2000-Sep-06 18:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0b1 selectmodule compile error under Redhat 5.2

Details: Environment: Redhat 5.2 running the gcc compiler that comes with the
distribution (gcc 2.7.2.3).

'make' failed when compiling selectmodule.c ('./configure' ran ok)because
the following constants were undefined:

POLLRDNORM, POLLRDBAND, POLLWRBAND

The /usr/include/sys/poll.h file does not contain these constants.
Under Redhat 6.2 the constants are defined in the /usr/include/bits/poll.h
file (which is not present in the Redhat 5.2 distribution).

I used the Redhat 6.2 poll.h file and the selectmodule compiled (under
Redhat 5.2) but got the following error when running 
'make test' (it looks like it might be related to the compile problem):

test test_poll crashed -- select.error: (9, 'Bad file descriptor')

1 test failed: test_poll



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113773&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 05:08:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 21:08:25 -0700
Subject: [Python-bugs-list] [Bug #110629] Tkinter Image names may be reused (PR#28)
Message-ID: <200009070408.VAA28707@delerium.i.sourceforge.net>

Bug #110629, was updated on 2000-Jul-31 14:08
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Tkinter Image names may be reused (PR#28)

Details: Jitterbug-Id: 28
Submitted-By: guido@python.org
Date: Wed, 14 Jul 1999 14:00:14 -0400 (EDT)
Version: 1.5.2b
OS: 


Mark Lutz wrote me:

(BTW, this will probably never surface again (I'm stressing
the image object a bit), but I think there's a problem
with using the id() of an image as its name.  I ran into
a situation where an image was drawn in the wrong place, 
because a newly allocated image object had the same id()
as one very recently reclaimed.  It's very obscure, will
only happen if you have > 1 canvas in a process and happen
to be creating and deleting images very quickly, and is
too complex for me to describe further at the moment ;-).
I worked around it by first generating image names from a
simple counter, and then prebuilding all images up front.)



====================================================================
Audit trail:
Wed Jul 14 14:00:28 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-05 14:00
By: loewis

Comment:
Fixed in patch 101424, http://sourceforge.net/patch/?func=detailpatch&patch_id=101424&group_id=5470
-------------------------------------------------------

Date: 2000-Sep-06 21:08
By: fdrake

Comment:
Should be fixed by Martin's patch (#101424).  I've accepted the patch and assigned it and this bug to Martin for checkin and closure.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110629&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 05:44:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 21:44:42 -0700
Subject: [Python-bugs-list] [Bug #113779] test_gc coredump on Alpha
Message-ID: <200009070444.VAA23286@bush.i.sourceforge.net>

Bug #113779, was updated on 2000-Sep-06 21:44
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: test_gc coredump on Alpha

Details: Configured --with-cycle-gc --with-sigfpe

gc: collectable <list 0x12043d158>
gc: collectable <dictionary 0x12043d1d8>
gc: collectable <list 0x12043d158>
gc: collectable <tuple 0x12043d198>
gc: collectable <class 0x12043d218>
gc: collectable <dictionary 0x12043d278>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d2c8>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d328>
gc: collectable <instance method 0x12043d378>
gc: collectable <B instance at 0x12043d6b8>
gc: collectable <dictionary 0x12043d6f8>
gc: uncollectable <dictionary 0x12043d5f8>
gc: uncollectable <A instance at 0x12043d158>
Segmentation fault (core dumped)

gdb reports:

Core was generated by `./python -tt Lib/test/regrtest.py -l -v test_gc'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2.1...done.
Reading symbols from /lib/libutil.so.1.1...done.
Reading symbols from /lib/libm.so.6.1...done.
Reading symbols from /lib/libc.so.6.1...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
168             if (!PyList_Check(op)) {
(gdb) where
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
#1  0x120085fac in handle_finalizers (finalizers=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:312
#2  0x1200862d8 in collect (young=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:438
#3  0x120086704 in gc_collect (self=0x100000000, args=0x12043d158)
    at ./gcmodule.c:588
#4  0x120018ef0 in call_builtin (func=0x1, arg=0x12039e258, kw=0x0)
    at ceval.c:2628
#5  0x120018d30 in PyEval_CallObjectWithKeywords (func=0x1204377c0, 
    arg=0x12039e258, kw=0x0) at ceval.c:2596
#6  0x12001713c in eval_code2 (co=0x12043b890, globals=0x12043d158, 
    locals=0x120370488, args=0xffffffffffffffff, argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1929
#7  0x120016cc4 in eval_code2 (co=0x12043c400, globals=0x12043d158, 
    locals=0x120370488, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
...

(gdb) print op
$1 = (PyObject *) 0x100000000
(gdb) print newitem
$2 = (PyObject *) 0x12043d158



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113779&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 05:49:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 6 Sep 2000 21:49:18 -0700
Subject: [Python-bugs-list] [Bug #113779] test_gc coredump on Alpha
Message-ID: <200009070449.VAA23465@bush.i.sourceforge.net>

Bug #113779, was updated on 2000-Sep-06 21:44
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: test_gc coredump on Alpha

Details: Configured --with-cycle-gc --with-sigfpe

gc: collectable <list 0x12043d158>
gc: collectable <dictionary 0x12043d1d8>
gc: collectable <list 0x12043d158>
gc: collectable <tuple 0x12043d198>
gc: collectable <class 0x12043d218>
gc: collectable <dictionary 0x12043d278>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d2c8>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d328>
gc: collectable <instance method 0x12043d378>
gc: collectable <B instance at 0x12043d6b8>
gc: collectable <dictionary 0x12043d6f8>
gc: uncollectable <dictionary 0x12043d5f8>
gc: uncollectable <A instance at 0x12043d158>
Segmentation fault (core dumped)

gdb reports:

Core was generated by `./python -tt Lib/test/regrtest.py -l -v test_gc'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2.1...done.
Reading symbols from /lib/libutil.so.1.1...done.
Reading symbols from /lib/libm.so.6.1...done.
Reading symbols from /lib/libc.so.6.1...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
168             if (!PyList_Check(op)) {
(gdb) where
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
#1  0x120085fac in handle_finalizers (finalizers=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:312
#2  0x1200862d8 in collect (young=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:438
#3  0x120086704 in gc_collect (self=0x100000000, args=0x12043d158)
    at ./gcmodule.c:588
#4  0x120018ef0 in call_builtin (func=0x1, arg=0x12039e258, kw=0x0)
    at ceval.c:2628
#5  0x120018d30 in PyEval_CallObjectWithKeywords (func=0x1204377c0, 
    arg=0x12039e258, kw=0x0) at ceval.c:2596
#6  0x12001713c in eval_code2 (co=0x12043b890, globals=0x12043d158, 
    locals=0x120370488, args=0xffffffffffffffff, argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1929
#7  0x120016cc4 in eval_code2 (co=0x12043c400, globals=0x12043d158, 
    locals=0x120370488, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
...

(gdb) print op
$1 = (PyObject *) 0x100000000
(gdb) print newitem
$2 = (PyObject *) 0x12043d158



Follow-Ups:

Date: 2000-Sep-06 21:49
By: none

Comment:
Note that without -l to regrtest it does NOT dump core,
and completes correctly.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113779&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 09:51:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 01:51:17 -0700
Subject: [Python-bugs-list] [Bug #113785] SIGSEGV in PyDict_SetItem
Message-ID: <200009070851.BAA05786@delerium.i.sourceforge.net>

Bug #113785, was updated on 2000-Sep-07 01:51
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 5
Summary: SIGSEGV in PyDict_SetItem

Details: On a PC running FreeBSD 3.5
Python 1.5.2 (#1, Aug 23 2000, 10:14:09)  [GCC 2.95 19990728 (release)] on freebsd3
 I installed Python to run a filter that comes with inn 2.3.0 (usenet News)

Some time the fiter written in Python hangs with the following (from gdb)
Program received signal SIGSEGV, Segmentation fault.
0x810465b in PyDict_SetItem (op=0x83c6a80, key=0x83d4020, value=0x0)
    at dictobject.c:375
375             Py_INCREF(value);

I suspect that the Python filter may be 
#
# $Id: filter_innd.py,v 1.2 1999/09/23 14:24:23 kondou Exp $
#
# This is a sample filter for the Python innd hook.
#
# For details, see the file README.python_hook that came with INN.
#

import re
from string import *

# This looks weird, but creating and interning these strings should
# let us get faster access to header keys (which innd also interns) by
# losing some strcmps under the covers.
Approved = intern("Approved");           Control = intern("Control")
Date = intern("Date");                   Distribution = intern("Distribution")
Expires = intern("Expires");             From = intern("From")
Lines = intern("Lines");                 Message_ID = intern("Message-ID")
Newsgroups = intern("Newsgroups");       Path = intern("Path")
Reply_To = intern("Reply-To");           Sender = intern("Sender")
Subject = intern("Subject");             Supersedes = intern("Supersedes")
Bytes = intern("Bytes");                 Also_Control = intern("Also-Control")
References = intern("References");       Xref = intern("Xref")
Keywords = intern("Keywords");           X_Trace = intern("X-Trace")
NNTP_Posting_Host = intern("NNTP-Posting-Host")
Followup_To = intern("Followup-To");     Organization = intern("Organization")
Content_Type = intern("Content-Type");   Content_Base = intern("Content-Base")
Content_Disposition = intern("Content-Disposition")
X_Newsreader = intern("X-Newsreader");   X_Mailer = intern("X-Mailer")
X_Newsposter = intern("X-Newsposter")
X_Cancelled_By = intern("X-Cancelled-By")
X_Canceled_By = intern("X-Canceled-By"); Cancel_Key = intern("Cancel-Key")
__BODY__ = intern("__BODY__");           __LINES__ = intern("__LINES__")


class InndFilter:
    """Provide filtering callbacks to innd."""

    def __init__(self):
        """This runs every time the filter is loaded or reloaded.

        This is a good place to initialize variables and precompile
        regular expressions, or maybe reload stats from disk.
        """
        self.re_newrmgroup = re.compile('(?:new|rm)group\s')
        self.re_obsctl = re.compile('(?:sendsys|version|uuname)')
        # msgid  pattern from a once-common spambot.
        self.re_none44 = re.compile('none\d+\.yet>')
        # There is a mad newgrouper who likes to meow.
        self.re_meow = re.compile("^Meow\!", re.M)
        # One of my silly addresses.
        self.re_fluffymorph = re.compile("andruQ@myremarQ.coM", re.I)

    def filter_before_reload(self):
        """Runs just before the filter gets reloaded.

        You can use this method to save state information to be
        restored by the __init__() method or down in the main module.
        """
        syslog('notice', "filter_before_reload executing...")

    def filter_close(self):
        """Runs when innd exits.

        You can use this method to save state information to be
        restored by the __init__() method or down in the main module.
        """
        syslog('notice', "filter_close running, bye!")

    def filter_messageid(self, msgid):
        """Filter articles just by their message IDs.

        This method interacts with the IHAVE and CHECK NNTP commands.
        If you return a non-empty string here, the offered article
        will be refused before you ever have to waste any bandwidth
        looking at it.  This is not foolproof, so you should do your
        ID checks both here and in filter_art.  (TAKETHIS does not
        offer the ID for examination, and a TAKETHIS isn't always
        preceded by a CHECK.)
        """
        return ""               # deactivate the samples.
        
        if self.re_none44.search(msgid):
            return "But I don't like spam!"
        if msgid[0:8] == '<cancel.':
            return "I don't do cybercancels."

    def filter_art(self, art):
        """Decide whether to keep offered articles.

        art is a dictionary with a bunch of headers, the article's
        body, and innd's reckoning of the line count.  Itens not
        in the article will have a value of None.

        The available headers are the ones listed near the top of
        innd/art.c.  At this writing, they are:

            Approved, Control, Date, Distribution, Expires, From,
            Lines, Message-ID, Newsgroups, Path, Reply-To, Sender,
            Subject, Supersedes, Bytes, Also-Control, References,
            Xref, Keywords, X-Trace, NNTP-Posting-Host, Folowup-To,
            Organization, Content-Type, Content-Base,
            Content-Disposition, X-Newsreader, X-Mailer, X-Newsposter,
            X-Cancelled-By, X-Canceled-By and Cancel-Key.

        The body is the buffer in art['__BODY__'] and the INN-reckoned
        line count is held as an integer in art['__LINES__'].  (The
        Lines: header is often generated by the poster, and large
        differences can be a good indication of a corrupt article.)

        If you want to keep an article, return None or "".  If you
        want to reject, return a non-empty string.  The rejection
        string will appear in transfer and posting response banners,
        and local posters will see them if their messages are
        rejected.
        """
        return ""               # deactivate the samples.

        # catch bad IDs from articles fed with TAKETHIS but no CHECK.
        idcheck = self.filter_messageid(art[Message_ID])
        if idcheck:
            return idcheck

        # There are some control messages we don't want to process or
        # forward to other sites.
        try:
            if art[Control] is not None:
                if self.re_newrmgroup.match(art[Control]):
                    if self.re_meow.search(art[__BODY__]):
                        return "The fake tale meows again."
                    if art[Distribution] == buffer('mxyzptlk'):
                        return "Evil control message from the 10th dimension"
                if self.re_obsctl.match(art[Control]):
                    return "Obsolete control message"

            # If you don't know, you don't want to know.
            if self.re_fluffymorph.search(art[From]):
                return "No, you may NOT meow."
        except:
            syslog('n', str(sys.exc_info[1]))

    def filter_mode(self, oldmode, newmode, reason):
        """Capture server events and do something useful.

        When the admin throttles or pauses innd (and lets it go
        again), this method will be called.  oldmode is the state we
        just left, and newmode is where we are going.  reason is
        usually just a comment string.

        The possible values of newmode and oldmode are the four
        strings 'running', 'paused', 'throttled' and 'unknown'.
        Actually 'unknown' shouldn't happen, it's there in case
        feeping creatures invade innd.
        """
        syslog('notice', 'state change from %s to %s - %s'
               % (oldmode, newmode, reason))



"""
Okay, that's the end of our class definition.  What follows is the
stuff you need to do to get it all working inside innd.
"""

# This import must succeed, or your filter won't work.  I'll repeat
# that: You MUST import INN.
from INN import *


#   Some of the stuff below is gratuitous, just demonstrating how the
#   INN.syslog call works.  That first thingy tells the Unix syslogger
#   what severity to use; you can abbreviate down to one letter and
#   it's case insensitive.  Available levels are (in increasing levels
#   of seriousness) Debug, Info, Notice, Warning, Err, Crit, and
#   Alert.  If you provide any other string, it will be defaulted to
#   Notice.  You'll find the entries in the same log files innd itself
#   uses, with an 'innd: python:' prefix.
#
#   The native Python syslog module seems to clash with INN, so use
#   INN's.  Oh yeah -- you may notice that stdout and stderr have been
#   redirected to /dev/null -- if you want to print stuff, open your
#   own files.

try:
    import sys
except Exception, errmsg:
    syslog('Error', "import boo-boo: " + errmsg[0])


#     If you want to do something special when the server first starts
#     up, this is how to find out when it's time.

if 'spamfilter' not in dir():
    syslog ('n', "First load, so I can do initialization stuff.")
    #  You could unpickle a saved hash here, so that your hard-earned
    #  spam scores aren't lost whenver you shut down innd.
else:
    syslog ('NoTicE', "I'm just reloading, so skip the formalities.")


#  Finally, here is how we get our class on speaking terms with innd.
#  The hook is refreshed on every reload, so that you can change the
#  methods on a running server.  Don't forget to test your changes
#  before reloading!
spamfilter = InndFilter()
try:
    set_filter_hook(spamfilter)
    syslog('n', "spamfilter successfully hooked into INN")
except Exception, errmsg:
    syslog('e', "Cannot obtain INN hook for spamfilter: %s" % errmsg[0])



And the data would be something like:
        takethis <967664873.12710.1.nnrp-02.9e98fa8b@news.demon.co.uk>\r
        Path: news.nectec.or.th!news.loxinfo.co.th!news-out.cwix.com!newsfeed.\
        cwix.com!newsfeeds.belnet.be!news.belnet.be!newsgate.cistron.nl!bullse\
        ye.news.demon.net!demon!news.demon.co.uk!demon!inert.demon.co.uk!not-f\
        or-mail\r
        From: inert@inert.demon.co.uk\r
        Newsgroups: rec.music.industrial\r
        Subject: *** CLUB NOIR ***  31/8/00\r
        Date: Wed, 30 Aug 2000 19:47:53 GMT\r
        Organization: inertia\r
        Message-ID: <967664873.12710.1.nnrp-02.9e98fa8b@news.demon.co.uk>\r
        NNTP-Posting-Host: inert.demon.co.uk\r
        X-NNTP-Posting-Host: inert.demon.co.uk:158.152.250.139\r
        X-Trace: news.demon.co.uk 967664873 nnrp-02:12710 NO-IDENT inert.demon\
        .co.uk:158.152.250.139\r
        X-Complaints-To: abuse@demon.net\r
        X-Mailer: Mozilla 1.22 (Windows; I; 16bit)\r
        MIME-Version: 1.0\r
        Lines: 0\r
        Xref: news.nectec.or.th rec.music.industrial:137401\r
        \r
        .\r

So, for an easy solution, I can disable Python filtering and then inn will be working fine.
But even if the filter was not doing what it is supposed to do, Python should not SIGSEGV I presume.

Beside Python installed without problem and make test result is:
42 tests OK.
19 tests skipped: test_al test_audioop test_bsddb test_cd test_cl test_crypt test_dbm test_dl test_gdbm test_gl test_gzip test_imageop test_imgfile test_nis test_rgbimg test_sunaudiodev test_thread test_timing test_zlib

For more info: on@cs.ait.ac.th

Thank you,

Olivier

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113785&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 10:04:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 02:04:10 -0700
Subject: [Python-bugs-list] [Bug #113733] xml package not included in windows installer
Message-ID: <200009070904.CAA06232@delerium.i.sourceforge.net>

Bug #113733, was updated on 2000-Sep-06 11:22
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 8
Summary: xml package not included in windows installer

Details: Lib/xml/* are not installed when using BeOpen-Python-2.0b1.exe

Follow-Ups:

Date: 2000-Sep-07 02:04
By: tim_one

Comment:
Gross oversight!  Fixed in CVS.  Also built a new Windows installer, which the PythonLabs webmaster should get around to putting on the download page later today.  Thanks for noticing <wink>.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113733&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 10:56:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 02:56:18 -0700
Subject: [Python-bugs-list] [Bug #113786] copy.py doesn't support unicode strings
Message-ID: <200009070956.CAA08042@delerium.i.sourceforge.net>

Bug #113786, was updated on 2000-Sep-07 02:56
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: copy.py doesn't support unicode strings

Details: >>> import copy
>>> copy.copy(u"")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\PYTHON20\lib\copy.py", line 71, in copy
    raise error, \
copy.Error: un(shallow)copyable object of type <type 'unicode'>
>>>

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113786&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 11:29:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 03:29:46 -0700
Subject: [Python-bugs-list] [Bug #113788] NT 2.0b1 Doc/modindex.html is almost empty
Message-ID: <200009071029.DAA09259@delerium.i.sourceforge.net>

Bug #113788, was updated on 2000-Sep-07 03:29
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: NT 2.0b1 Doc/modindex.html is almost empty

Details: Doc/modindex.html in the 2.0b1 release on NT is empty. 
There is only the header and footer but no module list.

Can't login to sourceforge so:
tebeka@lycosmail.com


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113788&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 12:00:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 04:00:13 -0700
Subject: [Python-bugs-list] [Bug #113786] copy.py doesn't support unicode strings
Message-ID: <200009071100.EAA10285@delerium.i.sourceforge.net>

Bug #113786, was updated on 2000-Sep-07 02:56
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: copy.py doesn't support unicode strings

Details: >>> import copy
>>> copy.copy(u"")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\PYTHON20\lib\copy.py", line 71, in copy
    raise error, \
copy.Error: un(shallow)copyable object of type <type 'unicode'>
>>>

Follow-Ups:

Date: 2000-Sep-07 04:00
By: lemburg

Comment:
Fixed.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113786&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 14:09:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 06:09:47 -0700
Subject: [Python-bugs-list] [Bug #113793] getopt.c compile fails on Solaris 2.6/gcc 2.95.2
Message-ID: <200009071309.GAA15016@delerium.i.sourceforge.net>

Bug #113793, was updated on 2000-Sep-07 06:09
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: getopt.c compile fails on Solaris 2.6/gcc 2.95.2

Details: I configured python with the following options:
/ldatae/Misc/python/Python-1.6/configure  --program-prefix=g --target=sparc-su
n-solaris2.6 --prefix=/projects/gnu/sparc-sun-solaris2.6 --exec-prefix=/projects
/gnu/sparc-sun-solaris2.6 --with-gnu-gettext --with-rx --with-curses=/projects/g
nu/sparc-sun-solaris2.6/lib --with-shared --with-profile --enable-nls --x-includ
es=/usr/openwin/include --x-libraries=/usr/openwin/lib --with-wctype-functions -
-with-x-toolkit=motif --with-x --with-threads
After compiling for a while, the build stops with this error:

gcc -g -O2 -I/ldatae/Misc/python/Python-1.6/Python/../Include -I.. -DHAVE_CONFIG
_H   -c -o getopt.o getopt.c
getopt.c: In function `getopt':
getopt.c:51: argument `argv' doesn't match prototype
/usr/include/stdio.h:329: prototype declaration
getopt.c:51: argument `optstring' doesn't match prototype
/usr/include/stdio.h:329: prototype declaration
make[1]: *** [getopt.o] Error 1
make[1]: Leaving directory `/ldatae/Misc/python/Python-1.6/Python'
make: *** [Python] Error 


I can supply more details if someone emails me at lvirden@cas.org .

Thank you.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113793&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 14:49:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 06:49:22 -0700
Subject: [Python-bugs-list] [Bug #113795] IDLE 0.6 with Python 2.0b1 doesn't handle chinese characters
Message-ID: <200009071349.GAA16429@delerium.i.sourceforge.net>

Bug #113795, was updated on 2000-Sep-07 06:49
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: IDLE 0.6 with Python 2.0b1 doesn't handle chinese characters

Details: I just switched from 1.5.2 to 2.0b1 on W2K/Simplified Chinese version. I used to be able to input chinese characters directly into IDLE, and access violations did happen quite often. Now with 2.0b1, I can't even input chinese characters into the IDLE window anymore:IDLE automatically changed chinese characters into illegible stuff; it's the same when I copy from a text editor and paste into the IDLE window. I guess it's related to the induction of unicode support in 2.0, but is there a workaround I should know, or I should switch back to 1.5.2, or it's a bug worth fixing?

Thanks.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113795&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 15:33:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 07:33:57 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200009071433.HAA18059@delerium.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 15:59:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 07:59:49 -0700
Subject: [Python-bugs-list] [Bug #113727] Tkinter: _substitute call of getint(D) fails
Message-ID: <200009071459.HAA11983@bush.i.sourceforge.net>

Bug #113727, was updated on 2000-Sep-06 10:24
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Tkinter: _substitute call of getint(D) fails

Details: Version: 2.0b1
OS: Solaris 2.6 Generic_105181-15 sun4m
Tcl/Tk: 8.0

All callbacks (even in the Demo code) give this:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/s/lib/python2.0/lib-tk/Tkinter.py", line 1283, in __call__
    args = apply(self.subst, args)
  File "/s/lib/python2.0/lib-tk/Tkinter.py", line 1053, in _substitute
    e.delta = getint(D)
ValueError: invalid literal for int(): D

It seems the variable D has been assigned the string value &#039;D&#039;.

Follow-Ups:

Date: 2000-Sep-07 07:59
By: effbot

Comment:
Tkinter currently requires a Tk with mousewheel support (8.2 or later).  I just checked in a fix for this specific problems, but there may be other problems with pre-8.2 version of Tk.  It's probably a good idea to get a newer Tcl/Tk kit.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113727&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 16:01:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 08:01:41 -0700
Subject: [Python-bugs-list] [Bug #113727] Tkinter: _substitute call of getint(D) fails
Message-ID: <200009071501.IAA12023@bush.i.sourceforge.net>

Bug #113727, was updated on 2000-Sep-06 10:24
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Tkinter: _substitute call of getint(D) fails

Details: Version: 2.0b1
OS: Solaris 2.6 Generic_105181-15 sun4m
Tcl/Tk: 8.0

All callbacks (even in the Demo code) give this:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/s/lib/python2.0/lib-tk/Tkinter.py", line 1283, in __call__
    args = apply(self.subst, args)
  File "/s/lib/python2.0/lib-tk/Tkinter.py", line 1053, in _substitute
    e.delta = getint(D)
ValueError: invalid literal for int(): D

It seems the variable D has been assigned the string value &#039;D&#039;.

Follow-Ups:

Date: 2000-Sep-07 07:59
By: effbot

Comment:
Tkinter currently requires a Tk with mousewheel support (8.2 or later).  I just checked in a fix for this specific problems, but there may be other problems with pre-8.2 version of Tk.  It's probably a good idea to get a newer Tcl/Tk kit.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113727&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 16:18:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 08:18:36 -0700
Subject: [Python-bugs-list] [Bug #113800] \optional{} produces incorrect HTML
Message-ID: <200009071518.IAA12653@bush.i.sourceforge.net>

Bug #113800, was updated on 2000-Sep-07 08:18
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: \optional{} produces incorrect HTML

Details: This showed up in the Python 2.0 document: LaTeX2HTML
produces bad HTML with improperly nested tags, including a trailing <var> tag that leaves the rest of the document in italic on some browsers.  Sample document:

\documentclass{howto}
 
\title{What's New in Python 2.0}
\release{0.05}
\author{A.M. Kuchling and Moshe Zadka}
\authoraddress{\email{amk1@bigfoot.com}, \email{moshez@math.huji.ac.il} }
 
\begin{document}
 
\code{unicode(\var{string} \optional{, \var{encoding}}
\optional{, \var{errors}} ) } creates a Unicode string from an 8-bit
 
\end{document}  

The incorrect HTML output is:

<code>unicode(<var>string</var> </var><big>[</big><var>, <var>encoding</var></var><big>]</big><big>[</big><var>, <var>errors</var></var><big>]</big><var> ) </code> creates ...

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113800&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 16:23:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 08:23:36 -0700
Subject: [Python-bugs-list] [Bug #113779] test_gc coredump on Alpha
Message-ID: <200009071523.IAA12857@bush.i.sourceforge.net>

Bug #113779, was updated on 2000-Sep-06 21:44
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: test_gc coredump on Alpha

Details: Configured --with-cycle-gc --with-sigfpe

gc: collectable <list 0x12043d158>
gc: collectable <dictionary 0x12043d1d8>
gc: collectable <list 0x12043d158>
gc: collectable <tuple 0x12043d198>
gc: collectable <class 0x12043d218>
gc: collectable <dictionary 0x12043d278>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d2c8>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d328>
gc: collectable <instance method 0x12043d378>
gc: collectable <B instance at 0x12043d6b8>
gc: collectable <dictionary 0x12043d6f8>
gc: uncollectable <dictionary 0x12043d5f8>
gc: uncollectable <A instance at 0x12043d158>
Segmentation fault (core dumped)

gdb reports:

Core was generated by `./python -tt Lib/test/regrtest.py -l -v test_gc'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2.1...done.
Reading symbols from /lib/libutil.so.1.1...done.
Reading symbols from /lib/libm.so.6.1...done.
Reading symbols from /lib/libc.so.6.1...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
168             if (!PyList_Check(op)) {
(gdb) where
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
#1  0x120085fac in handle_finalizers (finalizers=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:312
#2  0x1200862d8 in collect (young=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:438
#3  0x120086704 in gc_collect (self=0x100000000, args=0x12043d158)
    at ./gcmodule.c:588
#4  0x120018ef0 in call_builtin (func=0x1, arg=0x12039e258, kw=0x0)
    at ceval.c:2628
#5  0x120018d30 in PyEval_CallObjectWithKeywords (func=0x1204377c0, 
    arg=0x12039e258, kw=0x0) at ceval.c:2596
#6  0x12001713c in eval_code2 (co=0x12043b890, globals=0x12043d158, 
    locals=0x120370488, args=0xffffffffffffffff, argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1929
#7  0x120016cc4 in eval_code2 (co=0x12043c400, globals=0x12043d158, 
    locals=0x120370488, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
...

(gdb) print op
$1 = (PyObject *) 0x100000000
(gdb) print newitem
$2 = (PyObject *) 0x12043d158



Follow-Ups:

Date: 2000-Sep-06 21:49
By: none

Comment:
Note that without -l to regrtest it does NOT dump core,
and completes correctly.

-------------------------------------------------------

Date: 2000-Sep-07 08:23
By: bwarsaw

Comment:
It could just be a bug in the debug printing of collected objects.  The -l switch for the regrtest simply adds a call to gc.set_debug(gc.DEBUG_LEAK) before the rest of the tests get going.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113779&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 16:33:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 08:33:05 -0700
Subject: [Python-bugs-list] [Bug #113803] [2.0b1 NT4.0] printing non asci char causes idle to abort
Message-ID: <200009071533.IAA20342@delerium.i.sourceforge.net>

Bug #113803, was updated on 2000-Sep-07 08:33
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: [2.0b1 NT4.0] printing non asci char causes idle to abort

Details: try:

alef = u'\u05d0'
print alef.encode('utf-8')

any enter after the last statement will cause idle to abort

on 'bare' python this does not cause any problem.

[tebeka@lycosmail.com]

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113803&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 17:11:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 09:11:07 -0700
Subject: [Python-bugs-list] [Bug #113807] PyArg_ParseTupleAndKeywords and Unicode...?
Message-ID: <200009071611.JAA14648@bush.i.sourceforge.net>

Bug #113807, was updated on 2000-Sep-07 09:11
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: PyArg_ParseTupleAndKeywords and Unicode...?

Details: I have a small extension that works OK with
PyArg_ParseTuple and a es# format; using the
same format with PyArg_ParseTupleAndKeywords
doesn't seem to work -- after importing that
module, Python thinks 2 args are needed, and
one of them is an 'impossible format character'.

Experimentally switching to s#, it works
_except_ when I use the name=value format
AND I pass a u'something' as the value, then
it crashes the interpreter.

So I'm going back to PyArg_ParseTuple, but,
the AndKeywords form _is_ also supposed to
work with Unicode, right...?

The platform I'm using is NT 4, SP6, with
MS VC++ 6 SP4 -- just in case it's platform
specific...


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113807&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 17:39:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 09:39:21 -0700
Subject: [Python-bugs-list] [Bug #113810] Global Module Index points to non-existant "About" page
Message-ID: <200009071639.JAA22728@delerium.i.sourceforge.net>

Bug #113810, was updated on 2000-Sep-07 09:39
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: Global Module Index points to non-existant "About" page

Details: Reported by Justin D. Pettit <jpettit@raznick.com> by email:

    - The "About this document..." hyperlink in the Global Module
      Index is broken.  There is no "Doc/about.html".


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113810&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 17:45:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 09:45:38 -0700
Subject: [Python-bugs-list] [Bug #113811] Python 2.0 beta 1 -- urllib.urlopen() fails
Message-ID: <200009071645.JAA15967@bush.i.sourceforge.net>

Bug #113811, was updated on 2000-Sep-07 09:45
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python 2.0 beta 1 -- urllib.urlopen() fails

Details: In performing a urllib.urlopen(url) with "url" containing a valid URL, I got the following error message:

Traceback (most recent call last):
  File "IGNRatings.py", line 249, in ?
    main(sys.argv[1:])
  File "IGNRatings.py", line 132, in main
    inStream = urllib.urlopen(url)
  File "E:\Python20\lib\urllib.py", line 61, in urlopen
    return _urlopener.open(url)
  File "E:\Python20\lib\urllib.py", line 163, in open
    return getattr(self, name)(url)
  File "E:\Python20\lib\urllib.py", line 259, in open_http
    h = httplib.HTTP(host)
  File "E:\Python20\lib\httplib.py", line 626, in __init__
    self._conn = self._connection_class(host, port)
  File "E:\Python20\lib\httplib.py", line 325, in __init__
    self._set_hostport(host, port)
  File "E:\Python20\lib\httplib.py", line 332, in _set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int():


I looked into this a tiny bit and found that HTTPConnection.__init__() is called with host="http:" -- probably not the right thing. Python 1.6 works correctly.

Thanks,
Bob Alexander
bobalex@home.com

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113811&group_id=5470


From nobody@sourceforge.net  Thu Sep  7 18:10:57 2000
From: nobody@sourceforge.net (Nobody)
Date: Thu, 7 Sep 2000 10:10:57 -0700
Subject: [Python-bugs-list] [Bug #113812] Serious garbage collection problems with 2.0b1
Message-ID: <200009071710.KAA23979@delerium.i.sourceforge.net>

From: noreply@sourceforge.net

Bug #113812, was updated on 2000-Sep-07 10:10
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Serious garbage collection problems with 2.0b1


Details: Since I've installed version 2.0b1, I ran into a few (serious) problems
with a non-trivial application (+80,000 lines of Python). It seems that
the are all related to the new garbage collection:

 - Suddenly, assertions fail because lists have become empty 
   while they shouldn't have. I looks like their elements have been
   garbage collected while they were still reachable.

 - Under other circumstances, I get coredumps which always 
   seem to happen in function "move_root_reachable" of gcmodule.c:
   the "traverse" function pointer seems to contain a bogus address.

 - When I run a Purified version of the interpreter, I can't reproduce
   either problem, but instead, the garbage collector seems to get
   stuck in an endless loop each time. This always happens in the
   same function "move_root_reachable". Purify doesn't produce any 
   relevant warning.

The code runs just fine with version 1.6 of the interpreter, or when I
disable the garbage collector.

Probably relevant is the fact that the objects (10,000's) in my application
are very heavily cross-linked (nearly all links are bi-directional), which 
probably puts a lot of stress on the garbage collector.

My platform: HP-UX 10.20 / c89 compiler


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113812&group_id=5470


From nobody@sourceforge.net  Thu Sep  7 18:14:31 2000
From: nobody@sourceforge.net (Nobody)
Date: Thu, 7 Sep 2000 10:14:31 -0700
Subject: [Python-bugs-list] [Bug #113812] Serious garbage collection problems with 2.0b1
Message-ID: <200009071714.KAA24114@delerium.i.sourceforge.net>

From: noreply@sourceforge.net

Bug #113812, was updated on 2000-Sep-07 10:10
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Serious garbage collection problems with 2.0b1


Details: Since I've installed version 2.0b1, I ran into a few (serious) problems
with a non-trivial application (+80,000 lines of Python). It seems that
the are all related to the new garbage collection:

 - Suddenly, assertions fail because lists have become empty 
   while they shouldn't have. I looks like their elements have been
   garbage collected while they were still reachable.

 - Under other circumstances, I get coredumps which always 
   seem to happen in function "move_root_reachable" of gcmodule.c:
   the "traverse" function pointer seems to contain a bogus address.

 - When I run a Purified version of the interpreter, I can't reproduce
   either problem, but instead, the garbage collector seems to get
   stuck in an endless loop each time. This always happens in the
   same function "move_root_reachable". Purify doesn't produce any 
   relevant warning.

The code runs just fine with version 1.6 of the interpreter, or when I
disable the garbage collector.

Probably relevant is the fact that the objects (10,000's) in my application
are very heavily cross-linked (nearly all links are bi-directional), which 
probably puts a lot of stress on the garbage collector.

My platform: HP-UX 10.20 / c89 compiler


Follow-Ups:

Date: 2000-Sep-07 10:14
By: edg

Comment:
Just one more thing: when I turn on the gc debugging,
the interpreter also seems to get stuck in an endless loop.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113812&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 18:30:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 10:30:41 -0700
Subject: [Python-bugs-list] [Bug #110606] ntpath.expandvars doesn't handle case properly (PR#162)
Message-ID: <200009071730.KAA24671@delerium.i.sourceforge.net>

Bug #110606, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: ntpath.expandvars doesn't handle case properly (PR#162)

Details: Jitterbug-Id: 162
Submitted-By: dwr2@ix.netcom.com
Date: Sun, 19 Dec 1999 08:38:21 -0500 (EST)
Version: 1.5
OS: Windows 95


When accessing os.environ under Windows 95/NT/etc., lower-case environment
variable names are automatically converted to upper-case before use.
However, ntpath.expandvars does not accept lower-case variable names.
This is inconsistent.
This also happens in dospath.expandvars and may happen in os2path.expandvars.

Here is a Python session demonstrating the problem:

>>> import os
>>> os.name
'nt'
>>> os.environ['abc']='xyz'
>>> os.environ['abc']
'xyz'
>>> os.path.expandvars('$abc')
''
>>> os.path.expandvars('$ABC')
'xyz'
>>> 

Note that you can access os.environ using a lower-case name, but you must use
upper-case for os.path.expandvars (-->ntpath.expandvars).
This can easily be fixed by changing "os.environ.has_key(var)" to
"os.environ.has_key(string.upper(key))" in two places in each of
ntpath.expandvars, dospath.expandvars, and possibly os2path.expandvars.
Another solution would be to add the following function to os._Environ, in the
"if name in ('os2', 'nt', 'dos')" block:
    def has_key(self, key): return UserDict.UserDict.has_key(self,
string.upper(key))
The latter solution seems better to me, but I don't know the possible negative
ramifications of making such a change to a class used in so many places.
(On the other had, it is consistent with the definitions of _Environ.__getitem__
and _Environ.__setitem__.)

Further argument that lower-case should be accepted in ntpath.expandvars:
A DOS window opened in Windows 95 expands a lower-case variable name, despite
the actual variable name being stored in upper-case:
C:\WINDOWS>set abc=xyz
C:\WINDOWS>set
[...(most of variable list elided)...]
ABC=xyz
C:\WINDOWS>echo %abc%
xyz



====================================================================
Audit trail:
Mon Jan 17 09:05:54 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 10:30
By: fdrake

Comment:
Fixed at some point in the past.  Tests OK using 2.0b1 on Win2K.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110606&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 18:34:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 10:34:06 -0700
Subject: [Python-bugs-list] [Bug #110690] Bug in os.environ for Windows (PR#50)
Message-ID: <200009071734.KAA24834@delerium.i.sourceforge.net>

Bug #110690, was updated on 2000-Jul-31 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: Bug in os.environ for Windows (PR#50)

Details: Jitterbug-Id: 50
Submitted-By: bobalex@uppercase.xerox.com
Date: Wed, 11 Aug 1999 19:19:16 -0400 (EDT)
Version: 1.5.2
OS: WinNT


os.environ for Windows appears to be a map-type object that converts its keys to
upper case. Retrieval using a mixed case key works in some cases, but some
overloaded "operators" don't seem to do the right thing unless I pass an
all-upper-case key. E.g.:

>>> os.environ["x"] = "y"               # Stores pair {"X": "y"}
>>> os.environ["x"]                     # Works, indicates an effort is made
'y'                                     #   to retrieve mixed case keys
>>> os.environ.get("x", "NOT FOUND")    # Doesn't see the key "x"
'NOT FOUND'
>>> os.environ.get("X", "NOT FOUND")    # Works with all-upper-case key
'y'
>>> del os.environ["x"]                 # Doesn't see the key "x"
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "E:\Program Files\Python\Lib\UserDict.py", line 16, in __delitem__
    def __delitem__(self, key): del self.data[key]
KeyError: x
>>> del os.environ["X"]                 # Works with all-upper-case key



====================================================================
Audit trail:
Mon Aug 30 12:33:44 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 10:34
By: fdrake

Comment:
Fixed at some point in the past.  Tested OK using 2.0b1 on Win2K.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110690&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 18:41:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 10:41:55 -0700
Subject: [Python-bugs-list] [Bug #110840] -with-cxx option to configure script (PR#24)
Message-ID: <200009071741.KAA25089@delerium.i.sourceforge.net>

Bug #110840, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Wont Fix
Bug Group: Feature Request
Priority: 5
Summary: -with-cxx option to configure script (PR#24)

Details: Jitterbug-Id: 24
Submitted-By: guido@python.org
Date: Wed, 14 Jul 1999 11:16:51 -0400 (EDT)
Version: 1.5.2
OS: Unix


Geoff Furnish has a patch for the configure script which might be reasonable.

See http://www.python.org/sigs/c++-sig/sig_code.html



====================================================================
Audit trail:
Wed Jul 14 11:18:10 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-31 10:33
By: fdrake

Comment:
Patch is old; needs to be updated relative to the current state of build control.  May need to be modified to suit recent versions of CXX (not sure on that one).

I'll post a message to the C++ SIG to see what the current state of this work is.
-------------------------------------------------------

Date: 2000-Sep-07 10:41
By: fdrake

Comment:
Email discussion on the C++ SIG indicates that this is no longer an issue, so I'm closing this with a "Won't Fix" resolution.

See http://www.python.org/pipermail/c++-sig/2000-September/000443.html
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110840&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 21:17:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 13:17:21 -0700
Subject: [Python-bugs-list] [Bug #113800] optional{} produces incorrect HTML
Message-ID: <200009072017.NAA31451@delerium.i.sourceforge.net>

Bug #113800, was updated on 2000-Sep-07 08:18
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: optional{} produces incorrect HTML

Details: This showed up in the Python 2.0 document: LaTeX2HTML
produces bad HTML with improperly nested tags, including a trailing <var> tag that leaves the rest of the document in italic on some browsers.  Sample document:

\documentclass{howto}
 
\title{What's New in Python 2.0}
\release{0.05}
\author{A.M. Kuchling and Moshe Zadka}
\authoraddress{\email{amk1@bigfoot.com}, \email{moshez@math.huji.ac.il} }
 
\begin{document}
 
\code{unicode(\var{string} \optional{, \var{encoding}}
\optional{, \var{errors}} ) } creates a Unicode string from an 8-bit
 
\end{document}  

The incorrect HTML output is:

<code>unicode(<var>string</var> </var><big>[</big><var>, <var>encoding</var></var><big>]</big><big>[</big><var>, <var>errors</var></var><big>]</big><var> ) </code> creates ...

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113800&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 21:46:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 13:46:45 -0700
Subject: [Python-bugs-list] [Bug #113828] getpythonregpath with null data in registry key
Message-ID: <200009072046.NAA32679@delerium.i.sourceforge.net>

Bug #113828, was updated on 2000-Sep-07 13:46
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: getpythonregpath with null data in registry key

Details: 
File pc/getpathp.c
Function:getpythonregpath

ppPaths[index] can be null but this fragment is not null protected:

len = _tcslen(ppPaths[index]);
_tcsncpy(szCur, ppPaths[index], len);

Grzegorz Makarewicz

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113828&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 22:05:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 14:05:08 -0700
Subject: [Python-bugs-list] [Bug #110712] MALLOC_ZERO_RETURNS_NULL problem
Message-ID: <200009072105.OAA26651@bush.i.sourceforge.net>

Bug #110712, was updated on 2000-Jul-31 14:30
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: MALLOC_ZERO_RETURNS_NULL problem

Details: Jitterbug-Id: 86
Submitted-By: Sean Dunn <sdunn@digitalanvil.com>
Date: Fri, 24 Sep 1999 14:44:22 -0500
Version: None
OS: None

The use of

    #define MALLOC_ZERO_RETURNS_NULL 1

at the top of mymalloc.h worked fine...
By curiousity.. I just tried compiling the following:

/*testmalloc.c*/
#include <stdio.h>
main()
{
    int *fp;
    int *sp;

    fp = (int*)malloc(0);
    sp = (int*)malloc(sizeof(int));
    printf("fp: %x\nsp: %x\n", fp, sp);
}
/**/

First, I just compiled normally:

> cc -o testmalloc testmalloc.c
> ./testmalloc
fp: 10015010
sp: 10015020

Then I compiled with the -lmalloc flag (libmalloc is the SGI high performance
memory library - which seems to be the default used after running the
configure script)

> cc -o testmalloc testmalloc.c
> ./testmalloc
fp: 0
sp: 10015048

So...  It looks like without libmalloc, we're actually getting memory when we
"shouldn't" - but from reading your source code it seems like that's the way
it is usually made to work (weird).  When compiling with libmalloc, the
returned 0 is triggering the MemError flag.

At ceval.c:2467, should it even get to this point if the passed in kwargs ==
{}?  It does a PyDict_Size of it, which returns 0 (which seems correct) but kw
isn't NULL.  It seems like at this point that it should be..

Sean


Guido van Rossum wrote:

> >       The builtin function apply() seems to barf on empty dictionaries
> >       when passed as the keyword list.  See the following output:
>
> > >>> apply(func, (1,), {})
> > Traceback (innermost last):
> >   File "<stdin>", line 1, in ?
> > MemoryError
> > >>>
>
> > The variable 'kwargs' in this case is {}.  The actual exception is thrown
> > at line 2467 of Python/ceval.c:
> >
> >       if (kw != NULL) {
> >               int pos, i;
> >               nk = PyDict_Size(kw);
> >
> > /* 2467 */    k = PyMem_NEW(PyObject *, 2*nk);
> > /* nk, the PyDict_Size (the size of ma_used) is 0 */
> >
> >               if (k == NULL) {
> >                       PyErr_NoMemory();
> >                       Py_DECREF(arg);
> >                       return NULL;
> >               }
> >               pos = i = 0;
> >               while (PyDict_Next(kw, &pos, &k[i], &k[i+1]))
> >                       i += 2;
> >               nk = i/2;
> >               /* XXX This is broken if the caller deletes dict items! */
> >       }
>
> Thanks very much for your detailed analysis!  The cause is probably
> that somehow the configure script doesn't compute the correct value
> for MALLOC_ZERO_RETURNS_NULL.  I don't know why; the test seems simple
> enough.  (Maybe you inherited a config.cache file from a previous Irix
> version?)  To work around this in the build, if "make clobber" and
> rerunning configure don't do the trick, add
>
>     #define MALLOC_ZERO_RETURNS_NULL 1
>
> to the top of Include/mymalloc.h.
>
> Please let me know if rerunning configure makes the bug go away; this
> will decides the classification of your bug report.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)





====================================================================
Audit trail:
Fri Sep 24 16:15:04 1999	guido	changed notes
Fri Sep 24 16:15:04 1999	guido	moved from incoming to platformbug

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110712&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 22:21:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 14:21:07 -0700
Subject: [Python-bugs-list] [Bug #110712] MALLOC_ZERO_RETURNS_NULL problem
Message-ID: <200009072121.OAA27204@bush.i.sourceforge.net>

Bug #110712, was updated on 2000-Jul-31 14:30
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: MALLOC_ZERO_RETURNS_NULL problem

Details: Jitterbug-Id: 86
Submitted-By: Sean Dunn <sdunn@digitalanvil.com>
Date: Fri, 24 Sep 1999 14:44:22 -0500
Version: None
OS: None

The use of

    #define MALLOC_ZERO_RETURNS_NULL 1

at the top of mymalloc.h worked fine...
By curiousity.. I just tried compiling the following:

/*testmalloc.c*/
#include <stdio.h>
main()
{
    int *fp;
    int *sp;

    fp = (int*)malloc(0);
    sp = (int*)malloc(sizeof(int));
    printf("fp: %x\nsp: %x\n", fp, sp);
}
/**/

First, I just compiled normally:

> cc -o testmalloc testmalloc.c
> ./testmalloc
fp: 10015010
sp: 10015020

Then I compiled with the -lmalloc flag (libmalloc is the SGI high performance
memory library - which seems to be the default used after running the
configure script)

> cc -o testmalloc testmalloc.c
> ./testmalloc
fp: 0
sp: 10015048

So...  It looks like without libmalloc, we're actually getting memory when we
"shouldn't" - but from reading your source code it seems like that's the way
it is usually made to work (weird).  When compiling with libmalloc, the
returned 0 is triggering the MemError flag.

At ceval.c:2467, should it even get to this point if the passed in kwargs ==
{}?  It does a PyDict_Size of it, which returns 0 (which seems correct) but kw
isn't NULL.  It seems like at this point that it should be..

Sean


Guido van Rossum wrote:

> >       The builtin function apply() seems to barf on empty dictionaries
> >       when passed as the keyword list.  See the following output:
>
> > >>> apply(func, (1,), {})
> > Traceback (innermost last):
> >   File "<stdin>", line 1, in ?
> > MemoryError
> > >>>
>
> > The variable 'kwargs' in this case is {}.  The actual exception is thrown
> > at line 2467 of Python/ceval.c:
> >
> >       if (kw != NULL) {
> >               int pos, i;
> >               nk = PyDict_Size(kw);
> >
> > /* 2467 */    k = PyMem_NEW(PyObject *, 2*nk);
> > /* nk, the PyDict_Size (the size of ma_used) is 0 */
> >
> >               if (k == NULL) {
> >                       PyErr_NoMemory();
> >                       Py_DECREF(arg);
> >                       return NULL;
> >               }
> >               pos = i = 0;
> >               while (PyDict_Next(kw, &pos, &k[i], &k[i+1]))
> >                       i += 2;
> >               nk = i/2;
> >               /* XXX This is broken if the caller deletes dict items! */
> >       }
>
> Thanks very much for your detailed analysis!  The cause is probably
> that somehow the configure script doesn't compute the correct value
> for MALLOC_ZERO_RETURNS_NULL.  I don't know why; the test seems simple
> enough.  (Maybe you inherited a config.cache file from a previous Irix
> version?)  To work around this in the build, if "make clobber" and
> rerunning configure don't do the trick, add
>
>     #define MALLOC_ZERO_RETURNS_NULL 1
>
> to the top of Include/mymalloc.h.
>
> Please let me know if rerunning configure makes the bug go away; this
> will decides the classification of your bug report.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)





====================================================================
Audit trail:
Fri Sep 24 16:15:04 1999	guido	changed notes
Fri Sep 24 16:15:04 1999	guido	moved from incoming to platformbug

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110712&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 22:28:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 14:28:38 -0700
Subject: [Python-bugs-list] [Bug #113829] hasattr() doesn't accept Unicode strings
Message-ID: <200009072128.OAA27404@bush.i.sourceforge.net>

Bug #113829, was updated on 2000-Sep-07 14:28
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: hasattr() doesn't accept Unicode strings  

Details: hasattr(), getattr(), and doubtless other built-in functions don't accept Unicode strings at all:
>>> import sys
>>> hasattr(sys, u'abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: hasattr, argument 2: expected string, unicode found

Questions raised by GvR:
There are probably a bunch of things that need to be changed before
this works though; getattr() c.s. require a string, then call
PyObject_GetAttr() which also checks for a string unless the object
supports tp_getattro -- but that's only true for classes and
instances.
 
Also, should we convert the string to 8-bit, or should we allow
Unicode attribute names?
 
It seems there's no easy fix -- better address this after 2.0 is
released.                                                                       

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113829&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 22:28:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 14:28:44 -0700
Subject: [Python-bugs-list] [Bug #110712] MALLOC_ZERO_RETURNS_NULL problem
Message-ID: <200009072128.OAA27408@bush.i.sourceforge.net>

Bug #110712, was updated on 2000-Jul-31 14:30
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: MALLOC_ZERO_RETURNS_NULL problem

Details: Jitterbug-Id: 86
Submitted-By: Sean Dunn <sdunn@digitalanvil.com>
Date: Fri, 24 Sep 1999 14:44:22 -0500
Version: None
OS: None

The use of

    #define MALLOC_ZERO_RETURNS_NULL 1

at the top of mymalloc.h worked fine...
By curiousity.. I just tried compiling the following:

/*testmalloc.c*/
#include <stdio.h>
main()
{
    int *fp;
    int *sp;

    fp = (int*)malloc(0);
    sp = (int*)malloc(sizeof(int));
    printf("fp: %x\nsp: %x\n", fp, sp);
}
/**/

First, I just compiled normally:

> cc -o testmalloc testmalloc.c
> ./testmalloc
fp: 10015010
sp: 10015020

Then I compiled with the -lmalloc flag (libmalloc is the SGI high performance
memory library - which seems to be the default used after running the
configure script)

> cc -o testmalloc testmalloc.c
> ./testmalloc
fp: 0
sp: 10015048

So...  It looks like without libmalloc, we're actually getting memory when we
"shouldn't" - but from reading your source code it seems like that's the way
it is usually made to work (weird).  When compiling with libmalloc, the
returned 0 is triggering the MemError flag.

At ceval.c:2467, should it even get to this point if the passed in kwargs ==
{}?  It does a PyDict_Size of it, which returns 0 (which seems correct) but kw
isn't NULL.  It seems like at this point that it should be..

Sean


Guido van Rossum wrote:

> >       The builtin function apply() seems to barf on empty dictionaries
> >       when passed as the keyword list.  See the following output:
>
> > >>> apply(func, (1,), {})
> > Traceback (innermost last):
> >   File "<stdin>", line 1, in ?
> > MemoryError
> > >>>
>
> > The variable 'kwargs' in this case is {}.  The actual exception is thrown
> > at line 2467 of Python/ceval.c:
> >
> >       if (kw != NULL) {
> >               int pos, i;
> >               nk = PyDict_Size(kw);
> >
> > /* 2467 */    k = PyMem_NEW(PyObject *, 2*nk);
> > /* nk, the PyDict_Size (the size of ma_used) is 0 */
> >
> >               if (k == NULL) {
> >                       PyErr_NoMemory();
> >                       Py_DECREF(arg);
> >                       return NULL;
> >               }
> >               pos = i = 0;
> >               while (PyDict_Next(kw, &pos, &k[i], &k[i+1]))
> >                       i += 2;
> >               nk = i/2;
> >               /* XXX This is broken if the caller deletes dict items! */
> >       }
>
> Thanks very much for your detailed analysis!  The cause is probably
> that somehow the configure script doesn't compute the correct value
> for MALLOC_ZERO_RETURNS_NULL.  I don't know why; the test seems simple
> enough.  (Maybe you inherited a config.cache file from a previous Irix
> version?)  To work around this in the build, if "make clobber" and
> rerunning configure don't do the trick, add
>
>     #define MALLOC_ZERO_RETURNS_NULL 1
>
> to the top of Include/mymalloc.h.
>
> Please let me know if rerunning configure makes the bug go away; this
> will decides the classification of your bug report.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)





====================================================================
Audit trail:
Fri Sep 24 16:15:04 1999	guido	changed notes
Fri Sep 24 16:15:04 1999	guido	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Sep-07 14:28
By: jhylton

Comment:
Please do triage
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110712&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 22:41:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 14:41:42 -0700
Subject: [Python-bugs-list] [Bug #113812] Serious garbage collection problems with 2.0b1
Message-ID: <200009072141.OAA27984@bush.i.sourceforge.net>

Bug #113812, was updated on 2000-Sep-07 10:10
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: Serious garbage collection problems with 2.0b1

Details: Since I've installed version 2.0b1, I ran into a few (serious) problems
with a non-trivial application (+80,000 lines of Python). It seems that
the are all related to the new garbage collection:

 - Suddenly, assertions fail because lists have become empty 
   while they shouldn't have. I looks like their elements have been
   garbage collected while they were still reachable.

 - Under other circumstances, I get coredumps which always 
   seem to happen in function "move_root_reachable" of gcmodule.c:
   the "traverse" function pointer seems to contain a bogus address.

 - When I run a Purified version of the interpreter, I can't reproduce
   either problem, but instead, the garbage collector seems to get
   stuck in an endless loop each time. This always happens in the
   same function "move_root_reachable". Purify doesn't produce any 
   relevant warning.

The code runs just fine with version 1.6 of the interpreter, or when I
disable the garbage collector.

Probably relevant is the fact that the objects (10,000's) in my application
are very heavily cross-linked (nearly all links are bi-directional), which 
probably puts a lot of stress on the garbage collector.

My platform: HP-UX 10.20 / c89 compiler


Follow-Ups:

Date: 2000-Sep-07 10:14
By: edg

Comment:
Just one more thing: when I turn on the gc debugging,
the interpreter also seems to get stuck in an endless loop.
-------------------------------------------------------

Date: 2000-Sep-07 14:41
By: jhylton

Comment:
If you set the GC threshold to 0, 
import gc
gc.set_threshold(0)

Do you get the same problem?  Not that I doubt there is some sort of gc problem, but I wonder if there is something going wrong in the accounting or in the collection.

How hard would it be for someone to try to reproduce this bug?  Obviously, it would be helpful to get a smaller test case that has the same behavior as your large program and also tickles the bug.

Do you have any C extension modules in your application or is it pure Python?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113812&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:01:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:01:17 -0700
Subject: [Python-bugs-list] [Bug #110687] mailbox module's maildir class broken? (PR#414)
Message-ID: <200009072201.PAA28721@bush.i.sourceforge.net>

Bug #110687, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: mailbox module's maildir class broken? (PR#414)

Details: Jitterbug-Id: 414
Submitted-By: arb@anand.org
Date: Wed, 26 Jul 2000 12:23:32 -0400 (EDT)
Version: 1.5.2
OS: i386-Redhat-linux 6.2


I'm using the "mailbox" module that comes with python. I'm trying to use the
maildir class in there, but I think it's not following the maildir protocol
properly. The maildir protocol specifies that in a Maildir, a message file
can have any name that is unique, as long as it doesn't begin with a period.
However, the maildir class looks for valid message filenames, by checking to
see if the filename has more than 1 period in it, ie. consists of 3 or more
sections separated by periods. Typically, this is the sort of name one finds
in a Maildir, because the Maildir protocol page describes one simple way of
creating a unique filename, ie. by using the timestamp, pid of the writer, and
the hostname. However, when I insert messages into a maildir which don't follow
that system of generating unique filenames,  the maildir class
of the module doesn't see them. Additioanlly, it _does_ see message files which
begin with a period, eg. .12345678.1234.hostname. This is also a violation of
the
maildir protocol. I believe that a maildir reader should simply look at all
files in a maildir, no matter what the name, except for those that begin with a
period.



====================================================================
Audit trail:
Wed Jul 26 18:15:33 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:02
By: none

Comment:
From: Guido van Rossum <guido@beopen.com>
Subject: Re: [Python-bugs-list] mailbox module's maildir class broken? (PR#414)
Date: Wed, 26 Jul 2000 17:31:29 -0500

> I'm using the "mailbox" module that comes with python. I'm trying to
> use the maildir class in there, but I think it's not following the
> maildir protocol properly. The maildir protocol specifies that in a
> Maildir, a message file can have any name that is unique, as long as
> it doesn't begin with a period.  However, the maildir class looks
> for valid message filenames, by checking to see if the filename has
> more than 1 period in it, ie. consists of 3 or more sections
> separated by periods. Typically, this is the sort of name one finds
> in a Maildir, because the Maildir protocol page describes one simple
> way of creating a unique filename, ie. by using the timestamp, pid
> of the writer, and the hostname. However, when I insert messages
> into a maildir which don't follow that system of generating unique
> filenames, the maildir class of the module doesn't see
> them. Additioanlly, it _does_ see message files which begin with a
> period, eg. .12345678.1234.hostname. This is also a violation of the
> maildir protocol. I believe that a maildir reader should simply look
> at all files in a maildir, no matter what the name, except for those
> that begin with a period.

You're probably right.  I've never used that code, and according to
the logs it was contributed to Mike Meyer (no email known).  Perhaps
you would be willing to create a patch?  See
http://www.python.org/patches/ for submission guidelines.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)


-------------------------------------------------------

Date: 2000-Aug-05 11:45
By: twouters

Comment:
This bug is still present. Fred is/was working on the 'mailbox' module, but I do not know whether he'll fix this, too. If not, I'll do it, it's not that big a chance.
-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110687&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:01:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:01:01 -0700
Subject: [Python-bugs-list] [Bug #110614] illegal argument type for built-in operation (PR#204)
Message-ID: <200009072201.PAA28698@bush.i.sourceforge.net>

Bug #110614, was updated on 2000-Jul-31 14:06
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 3
Summary: illegal argument type for built-in operation (PR#204)

Details: Jitterbug-Id: 204
Submitted-By: guido@python.org
Date: Tue, 15 Feb 2000 14:24:27 -0500 (EST)
Version: 1.5.2
OS: Solaris 2.7


When PyArg_ParseTuple() needs an int (for an 'i' format char) but finds
something else, it says

TypeError: illegal argument type for built-in operation

instead of the nice friendly error it usually gives.



====================================================================
Audit trail:
Wed Feb 23 21:31:39 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:06
By: none

Comment:
From: "Fred L. Drake, Jr." <fdrake@acm.org>
Subject: Re: [Python-bugs-list] illegal argument type for built-in operation (PR#204)
Date: Tue, 15 Feb 2000 14:33:49 -0500 (EST)


guido@python.org writes:
 > When PyArg_ParseTuple() needs an int (for an 'i' format char) but finds
 > something else, it says
 > 
 > TypeError: illegal argument type for built-in operation

  This is also the case for the 'l' format, which is what range()
uses.


  -Fred

--
Fred L. Drake, Jr.	  <fdrake at acm.org>
Corporation for National Research Initiatives

-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110614&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:01:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:01:02 -0700
Subject: [Python-bugs-list] [Bug #110635] test_signal hangs when running as part of testall (PR#288)
Message-ID: <200009072201.PAA28702@bush.i.sourceforge.net>

Bug #110635, was updated on 2000-Jul-31 14:09
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: test_signal hangs when running as part of testall (PR#288)

Details: Jitterbug-Id: 288
Submitted-By: kessler@ccdc.cam.ac.uk
Date: Tue, 11 Apr 2000 06:58:39 -0400 (EDT)
Version: 1.6a2
OS: Irix6.3


Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal
works fine (?) if you run it on its own:

>>> import test.test_signal
starting pause() loop...
call pause()...
+ kill -5 7487 
+ sleep 2 
handlerA (5, <frame object at 100cf928>)
pause() returned
call pause()...
+ kill -2 7487 
+ sleep 2 
handlerB (2, <frame object at 100cf928>)
HandlerBCalled exception caught
call pause()...
+ kill -3 7487 
KeyboardInterrupt (assume the alarm() went off)

however, as part of the test suite, this test hangs:

>>> import test.testall
[...]
test_signal
test_signal
+ sleep 2 
starting pause() loop...
call pause()...
+ kill -5 7454 
+ sleep 2 
+ kill -2 7454 
+ sleep 2 
+ kill -3 7454 





====================================================================
Audit trail:
Tue Jul 11 08:29:16 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:09
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] test_signal hangs when running as part of testall (PR#288)
Date: Tue, 11 Apr 2000 11:27:20 -0400

> Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal
> works fine (?) if you run it on its own:
> 
> >>> import test.test_signal
> starting pause() loop...
> call pause()...
> + kill -5 7487 
> + sleep 2 
> handlerA (5, <frame object at 100cf928>)
> pause() returned
> call pause()...
> + kill -2 7487 
> + sleep 2 
> handlerB (2, <frame object at 100cf928>)
> HandlerBCalled exception caught
> call pause()...
> + kill -3 7487 
> KeyboardInterrupt (assume the alarm() went off)
> 
> however, as part of the test suite, this test hangs:
> 
> >>> import test.testall
> [...]
> test_signal
> test_signal
> + sleep 2 
> starting pause() loop...
> call pause()...
> + kill -5 7454 
> + sleep 2 
> + kill -2 7454 
> + sleep 2 
> + kill -3 7454 

Yes, I've seen this too.  Unfortunately, I don't have a clue, and I
don't have the time to delve into it...  I bet there's a compile time
#define that might do it.  It may have something to do with threads...

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-02 04:05
By: twouters

Comment:
Unsure if this is still an actual problem, but I've seen similar behaviour of test_signal on BSDI 4.0 and 4.0.1 systems, when Python was compiled with threads. The problem appeared to be the BSDI thread library, which had (among other things) problems with pause() in threaded code.

I haven't tried to enable threading on 4.0.x for a while, since new systems are 4.1, and 4.1 works properly with threads.

Does disabling threads fix the problem ? (Or perhaps *en*abling them, if they weren't ?)


-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110635&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:01:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:01:03 -0700
Subject: [Python-bugs-list] [Bug #110659] IDLE-0.5 copy command (PR#354)
Message-ID: <200009072201.PAA28706@bush.i.sourceforge.net>

Bug #110659, was updated on 2000-Jul-31 14:11
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: IDLE-0.5 copy command (PR#354)

Details: Jitterbug-Id: 354
Submitted-By: gpk@bell-labs.com
Date: Tue, 13 Jun 2000 10:05:35 -0400 (EDT)
Version: 1.6a2+
OS: Solaris sparc 2.6


Alt-w is advertised to copy the selected text.
It doesn't.   It pops up the 'window' menu.
However, even if you are in the 'edit' menu,
alt-w apparently does nothing.

I can select text, do alt-E alt-W, move the pointer,
then do ctrl-Y, and nothing pops up.


By the way, 'ctl-U ctl-U ctl-S' is an absurdly long
sequence for something as common as searching for text.



====================================================================
Audit trail:
Tue Jul 11 08:26:00 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110659&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:01:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:01:13 -0700
Subject: [Python-bugs-list] [Bug #110678] rfc822.Message getaddr method bug (PR#39)
Message-ID: <200009072201.PAA28717@bush.i.sourceforge.net>

Bug #110678, was updated on 2000-Jul-31 14:13
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: rfc822.Message getaddr method bug (PR#39)

Details: Jitterbug-Id: 39
Submitted-By: piers@cs.su.oz.au
Date: Fri, 30 Jul 1999 01:34:24 -0400 (EDT)
Version: 1.5.2
OS: Solaris


The following mail header, when parsed by rfc822, returns an incorrect
address from the method getaddr:

        From nobody@bounces.amazon.com Thu Jul 29 18:09:07 1999
        Date: Thu, 29 Jul 1999 00:05:26 -0700
        MIME-Version: 1.0
        Content-Type: multipart/alternative; boundary=z
        Subject: A Message from Amazon.com Delivers
        From: Amazon.com <delivers-news2@amazon.com>

        >>> import rfc822
        >>> fd=open('mail/amazon.com')
        >>> M=rfc822.Message(fd, 1)
        >>> M.getaddr('From')
        ('', 'Amazon.com')

Python version is:
Python 1.5.2 (#10, May 11 1999, 15:32:03)  [GCC 2.8.1] on sunos5



====================================================================
Audit trail:
Fri Jul 30 08:25:26 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Sjoerd Mullender <sjoerd@oratrix.nl>
Subject: Re: [Python-bugs-list] rfc822.Message getaddr method bug (PR#39)
Date: Mon, 02 Aug 1999 14:09:40 +0200

On Fri, Jul 30 1999 piers@cs.su.oz.au wrote:

> Full_Name: Piers Lauder
> Version: 1.5.2
> OS: Solaris
> Submission from: metra.ucc.usyd.edu.au (129.78.64.5)
> 
> 
> The following mail header, when parsed by rfc822, returns an incorrect
> address from the method getaddr:
> 
>         From nobody@bounces.amazon.com Thu Jul 29 18:09:07 1999
>         Date: Thu, 29 Jul 1999 00:05:26 -0700
>         MIME-Version: 1.0
>         Content-Type: multipart/alternative; boundary=z
>         Subject: A Message from Amazon.com Delivers
>         From: Amazon.com <delivers-news2@amazon.com>
> 
>         >>> import rfc822
>         >>> fd=open('mail/amazon.com')
>         >>> M=rfc822.Message(fd, 1)
>         >>> M.getaddr('From')
>         ('', 'Amazon.com')
> 
> Python version is:
> Python 1.5.2 (#10, May 11 1999, 15:32:03)  [GCC 2.8.1] on sunos5

It's an incorrect mail header.  The period in Amazon.com is not
allowed there but the name has to be quoted with double quotes.

But I guess rfc822.py could (and should) be lenient and let you get
away with this.

-- Sjoerd Mullender <sjoerd.mullender@oratrix.com>

-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110678&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:01:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:01:19 -0700
Subject: [Python-bugs-list] [Bug #110696] strptime error (PR#149)
Message-ID: <200009072201.PAA28725@bush.i.sourceforge.net>

Bug #110696, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: strptime error (PR#149)

Details: Jitterbug-Id: 149
Submitted-By: python.org@netfinances.com
Date: Sat, 4 Dec 1999 22:03:43 -0500 (EST)
Version: 1.5.2
OS: RedHat Linux 6.0


strptime throws a ValueError exception when I feed it the hour 02, and a minute
value 
equal to 40 or greater the following session illustrates:

1017:26:fred@firestorm:~/public_html >python
Python 1.5.2 (#2, Dec  3 1999, 23:56:19)  [GCC egcs-2.91.66 19990314/Linux
(egcs- on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from time import strptime
>>> t = strptime('0230','%H%M')
>>> t
(1900, 1, 0, 23, 0, 0, 6, 1, 0)
>>> t = strptime('0240','%H%M')
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: format mismatch
>>> t = strptime('0140','%H%M')
>>> t = strptime('0340','%H%M')
>>> t = strptime('0345','%H%M')
>>> t = strptime('0339','%H%M')
>>> t = strptime('0240','%H%M')
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: format mismatch
>>> t = strptime('0245','%H%M')
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: format mismatch
>>> t = strptime('0250','%H%M')
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: format mismatch
>>> t = strptime('0259','%H%M')
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: format mismatch
>>> 



====================================================================
Audit trail:
Tue Dec 14 17:22:29 1999	guido	sent reply 1
Tue Dec 14 17:22:48 1999	guido	resent 149.reply.1
Tue Dec 14 17:24:30 1999	guido	sent reply 2
Tue Dec 14 17:24:51 1999	guido	changed notes
Tue Dec 14 17:24:51 1999	guido	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: strptime error (PR#149)
Date: Tue Dec 14 17:22:29 1999


-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: strptime error (PR#149)
Date: Tue Dec 14 17:24:30 1999

> strptime throws a ValueError exception when I feed it the hour 02, and a
minute
> value 
> equal to 40 or greater the following session illustrates:

Very strange.  I can't reproduce this; I presume your platform's strptime()
has a problem.

--Guido van Rossum

-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
Must be the strptime() implementation in his C library.

-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110696&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:01:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:01:20 -0700
Subject: [Python-bugs-list] [Bug #110705] combination of socket.gethostbyname and os.system hangs program (PR#401)
Message-ID: <200009072201.PAA28729@bush.i.sourceforge.net>

Bug #110705, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: combination of socket.gethostbyname and os.system hangs program (PR#401)

Details: Jitterbug-Id: 401
Submitted-By: andyg@one.net.au
Date: Mon, 17 Jul 2000 04:26:12 -0400 (EDT)
Version: Python 1.5.2 (#3, Jun 29 2000, 15:52:04)  [GCC 2.8.1] on sunos5
OS: SunOS psol002 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise


A combination of socket.gethostbyname and os.system appears to hang
python intermittently.  We run Dec and Sun systems - it only appears
to be a problem with sun systems.

The following is the simplest way I can reproduce the problem:

test.py:
--------------------------------
#!/usr/local/bin/python
import os
import socket
print socket.gethostbyname( "a hostname (but not localhost)" )
os.system("echo fred")

hang.sh:
--------------------------------
#!/bin/ksh
while true ; do
  ./test.py
done

output:
---------------------------------
10.666.666.666
fred
10.666.666.666
fred
... eventually ...
10.666.666.666
<hung>

If "a hostname" is "localhost" it doesn't hang.  For anything else which it 
can successfully resolve, it seems to hang.

Thanks !
Andy.



====================================================================
Audit trail:
Mon Jul 24 18:39:07 2000	jeremy	changed notes
Mon Jul 24 18:39:07 2000	jeremy	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110705&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:01:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:01:22 -0700
Subject: [Python-bugs-list] [Bug #110835] Find out size of primitive object (PR#214)
Message-ID: <200009072201.PAA28737@bush.i.sourceforge.net>

Bug #110835, was updated on 2000-Aug-01 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Find out size of primitive object (PR#214)

Details: Jitterbug-Id: 214
Submitted-By: loewis@informatik.hu-berlin.de
Date: Fri, 25 Feb 2000 14:28:33 -0500 (EST)
Version: 1.5.2
OS: Solaris


This is a feature request made on python-help. If you want to estimate
how much memory your application uses, you currently have to count the bytes
manually. If there was a builtin function (say, sys.sizeof), counting would
be much easier. It would be documented as

sizeof(object) -> integer
Return the number of bytes that an object uses internally. This only counts
the number of bytes used by the object itself, not those of any of its 
attributes.

Ie. sys.sizeof(0) would give 12 on my system, the size of a dictionary would
count the dictentries, but the size of an instanceobject would not count the
the size of the __dict__ attribute.



====================================================================
Audit trail:
Tue Mar 07 14:42:18 2000	guido	changed notes
Tue Mar 07 14:42:18 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:14
By: none

Comment:
Interesting idea.
Is this what we need?
-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110835&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:01:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:01:24 -0700
Subject: [Python-bugs-list] [Bug #110848] Fwd: Debian Bug#40891: urllib.urlopen/urlretrieve doesn't support passive FTP (PR#58)
Message-ID: <200009072201.PAA28741@bush.i.sourceforge.net>

Bug #110848, was updated on 2000-Aug-01 14:16
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Fwd: Debian Bug#40891: urllib.urlopen/urlretrieve doesn't support passive FTP (PR#58)

Details: Jitterbug-Id: 58
Submitted-By: flight@debian.org
Date: Fri, 20 Aug 1999 13:26:17 -0400 (EDT)
Version: 1.5.2
OS: Debian potato


[Forwarded from the Debian bug tracking system]

Sender: Chris Lawrence <quango@watervalley.net>
Package: python-base
Version: 1.5.2-4
Severity: normal
File: /usr/lib/python1.5/urllib.py

urllib doesn't support passive FTP, even though the underlying ftplib
module does.  I dunno what the right approach is (perhaps a urllib
module global variable).  I know some tools (I'm aware of at least
ncftp and wget) autodetect whether PASV is supported by FTP servers;
perhaps that intelligence could be added to ftplib.

(Also: the FTP class's set_pasv() method isn't documented in my
version of python-docs; I haven't checked the new 1.5.2 docs yet
however.)

At the moment, I'm using this ugly hack to get around it:

# Really ugly hack; don't try this at home:
def ftpwrapper_init(self):
    import ftplib
    self.busy = 0
    self.ftp = ftplib.FTP()
    self.ftp.set_pasv(1)
    self.ftp.connect(self.host, self.port)
    self.ftp.login(self.user, self.passwd)
    for dir in self.dirs:
        self.ftp.cwd(dir)

urllib.ftpwrapper.init = ftpwrapper_init
# End really ugly hack



====================================================================
Audit trail:
Mon Aug 30 12:35:03 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:16
By: none

Comment:
From: "Fred L. Drake, Jr." <fdrake@acm.org>
Subject: Re: [Python-bugs-list] Fwd: Debian Bug#40891: urllib.urlopen/urlretrieve doesn't support passive FTP (PR#58)
Date: Mon, 23 Aug 1999 10:03:44 -0400 (EDT)


flight@debian.org writes:
 > Sender: Chris Lawrence <quango@watervalley.net>
 > Package: python-base
 > Version: 1.5.2-4
 > Severity: normal
 > File: /usr/lib/python1.5/urllib.py
...
 > (Also: the FTP class's set_pasv() method isn't documented in my
 > version of python-docs; I haven't checked the new 1.5.2 docs yet

  set_pasv() is documented in the documentation release 1.5.2p1.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake@acm.org>
Corporation for National Research Initiatives

-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110848&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:01:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:01:21 -0700
Subject: [Python-bugs-list] [Bug #110821] Python 1.5.2 bug, tried to post but got error (PR#121)
Message-ID: <200009072201.PAA28733@bush.i.sourceforge.net>

Bug #110821, was updated on 2000-Aug-01 14:10
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Python 1.5.2 bug, tried to post but got error (PR#121)

Details: Jitterbug-Id: 121
Submitted-By: "Brad Clements" <bkc@murkworks.com>
Date: Wed, 3 Nov 1999 15:53:01 -0500
Version: None
OS: None

The system encountered a fatal error 
After command: 
Received: 
The last error code was: Connection refused 

Web interface using {HYPERLINK "http://samba.anu.edu.au/jitterbug/"}Jitterbug 
{HYPERLINK "../python-bugs/"}Public interface 
{HYPERLINK "../python-bugs.private"}Private interface (requires password) 
{HYPERLINK "http://www.python.org/"}Python home page 

-----
Here's what I said for Python 1.5.2 on Win32 #0

PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
usable on WIN32 from non-VC applications because python15.dll is statically 
linked to the MS runtime DLL. Embedding applications that try to use these 
functions are passing in FILE * structures that do not match MS's runtime 
format. 

For example, I'm using Python in a Borland C++ Builder application. Although I 
can open a FILE *, when passed to python15.dll the FILE * is not usable.

The addition of two helper functions would solve this problem:

FILE * PyRun_OpenFile(char *file, char *mode) 
{
  return fopen(file,mode)
}

int PyRun_CloseFile(FILE *ptr)
{
  return fclose(ptr)
}

This way embedding apps could get python15.dll to open the file and it would 
work.

A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..


Brad Clements,                bkc@murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               ICQ: 14856937


====================================================================
Audit trail:
Fri Nov 05 10:31:10 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:10
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121)
Date: Wed, 03 Nov 1999 20:08:11 -0500

> I tried to post a bug, but got this error:
> 
> The system encountered a fatal error 

We were being slammed by a defective spider (or, if you're more
paranoid, by a hacker) so we temporarily turned off the webserver.  It
should be back on now.

> Here's what I said for Python 1.5.2 on Win32 #0
> 
> PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
> usable on WIN32 from non-VC applications because python15.dll is statically 
> linked to the MS runtime DLL. Embedding applications that try to use these 
> functions are passing in FILE * structures that do not match MS's runtime 
> format. 
> 
> For example, I'm using Python in a Borland C++ Builder application. Although I 
> can open a FILE *, when passed to python15.dll the FILE * is not usable.
> 
> The addition of two helper functions would solve this problem:
> 
> FILE * PyRun_OpenFile(char *file, char *mode) 
> {
>   return fopen(file,mode)
> }
> 
> int PyRun_CloseFile(FILE *ptr)
> {
>   return fclose(ptr)
> }
> 
> This way embedding apps could get python15.dll to open the file and it would 
> work.
> 
> A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..

This is an elegant solution.  I think I'll add it.

Could you mail me your suggestion again with the legal boilerplate
included?  See http://www.python.org/1.5/bugrelease.html for the text
and explanation.  Our lawyers require that I request this silliness...

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:10
By: none

Comment:
From: "Brad Clements" <bkc@murkworks.com>
Subject: Re: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121)
Date: Wed, 3 Nov 1999 20:22:21 -0500

Here it is again.

Also, I believe this will resolve  FAQ entry 8.10


> 8.10. Can't get Py_RunSimpleFile() to work.
> This is very sensitive to the compiler vendor, version and (perhaps) even
> options. If the FILE* structure in your embedding program isn't the same as
> is assumed by the Python interpreter it won't work. The Python 1.5.* DLLs
> (python15.dll) are all compiled with MS VC++ 5.0 and with
> multithreading-DLL options (/MD, I think). 
> 
> If you can't change compilers or flags, try using Py_RunSimpleString(). A
> trick to get it to run an arbitrary file is to construct a call to
> execfile() with the name of your file as argument. 
> 
> 
> 
> ---------------------------------------------------------------------------
> -----


> Here's what I said for Python 1.5.2 on Win32 #0
> 
> PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
> usable on WIN32 from non-VC applications because python15.dll is statically 
> linked to the MS runtime DLL. Embedding applications that try to use these 
> functions are passing in FILE * structures that do not match MS's runtime 
> format. 
> 
> For example, I'm using Python in a Borland C++ Builder application. Although I 
> can open a FILE *, when passed to python15.dll the FILE * is not usable.
> 
> The addition of two helper functions would solve this problem:
> 
> FILE * PyRun_OpenFile(char *file, char *mode) 
> {
>   return fopen(file,mode)
> }
> 
> int PyRun_CloseFile(FILE *ptr)
> {
>   return fclose(ptr)
> }
> 
> This way embedding apps could get python15.dll to open the file and it would 
> work.
> 
> A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..


I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



Brad Clements,                bkc@murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               ICQ: 14856937

-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110821&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:01:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:01:25 -0700
Subject: [Python-bugs-list] [Bug #110856] Page fault in module KERNEL32.DLL (PR#186)
Message-ID: <200009072201.PAA28745@bush.i.sourceforge.net>

Bug #110856, was updated on 2000-Aug-01 14:37
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Irreproducible
Priority: 5
Summary: Page fault in module KERNEL32.DLL (PR#186)

Details: Jitterbug-Id: 186
Submitted-By: hauser@eos.ncsu.edu
Date: Fri, 21 Jan 2000 08:36:26 -0500 (EST)
Version: 1.5.2
OS: windows 95


I am new to Python and am having a problem on Windows 95 any time I use the
Tkinter module. An example follows:

>>>from Tkinter import *
>>>t = Button(None, {'text': 'Test', Pack: {}})
>>>q = Button(None, {'text': 'Quit', 'command': t.quit, Pack: {}})
>>>t.mainloop()

The window comes up and seems to work. Clicking on the 'Quit' button returns to
the Python screen.  Then:
>>>Ctrl-D    ->message comes up that illegal operation has been perforned:

Page fault in KERNEL32.DLL at 016f:6ff79ff3, computer hangs and has to be hard 
booted.
Everything else seems to work, the idle program comes up and everything is OK 
until I try to exit and the same problem happens.  If I don't use Tkinter I
don't have the problem and any time with Tkinter I make a window and exit from 
the window, and try to exit Python the same error appears.
I have found several references to Page faults in KERNEL32 in the Bug reports 
but have not seen any solutions.  Any help would be appreciated.  Thanks.




====================================================================
Audit trail:
Mon Jan 24 14:47:52 2000	guido	sent reply 1
Mon Jan 24 14:48:23 2000	guido	changed notes
Mon Jan 24 14:48:23 2000	guido	moved from incoming to irreproducible

Follow-Ups:

Date: 2000-Aug-01 14:38
By: none

Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: Page fault in module KERNEL32.DLL (PR#186)
Date: Mon Jan 24 14:47:52 2000

John,

I am afraid I can't reproduce your problem, and I've never heard
of this type of behavior before.

My best guess is that some other Windows app that you have installed
is causing this behavior; this is basically impossible to debug.

I suggest that you post your problem description to comp.lang.python;
maybe someone there has a clever idea.  If you find a solution, please
reply to this message, leaving the subject intact.

In the mean time, I;ll keep your bug report in the "irreproducuble"
category.

Thanks,

--Guido van Rossum

-------------------------------------------------------

Date: 2000-Aug-01 14:38
By: none

Comment:
From: "Dr. John R. Hauser" <hauser@eos.ncsu.edu>
Subject: Re: Page fault in module KERNEL32.DLL (PR#186)
Date: Thu, 27 Jan 2000 15:34:33 -0500

Guido,

Thanks very much for your help.  With your suggestion I have traced the
problem to a file CSINJECT.exe which was being loaded on startup.  This is
a file associated with the Norton Clean Sweep utility.  After removing it
from my startup file, everything works fine.  I guess it was loaded when I
installed Norton Utilities and I have no idea what it does.  

Thanks again for you thoughts.

John Hauser


At 02:47 PM 1/24/2000 -0500, you wrote:
>John,
>
>I am afraid I can't reproduce your problem, and I've never heard
>of this type of behavior before.
>
>My best guess is that some other Windows app that you have installed
>is causing this behavior; this is basically impossible to debug.
>
>I suggest that you post your problem description to comp.lang.python;
>maybe someone there has a clever idea.  If you find a solution, please
>reply to this message, leaving the subject intact.
>
>In the mean time, I;ll keep your bug report in the "irreproducuble"
>category.
>
>Thanks,
>
>--Guido van Rossum
>
>
>


-------------------------------------------------------

Date: 2000-Aug-01 14:38
By: none

Comment:
Could be caused by another Windows app?
-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110856&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:01:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:01:29 -0700
Subject: [Python-bugs-list] [Bug #111710] socket.send() can do partial writes on some systems.
Message-ID: <200009072201.PAA28749@bush.i.sourceforge.net>

Bug #111710, was updated on 2000-Aug-11 13:25
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: socket.send() can do partial writes on some systems.

Details: 0811 15:57 chronis:~% uname -a
FreeBSD chronis.pobox.com 4.0-STABLE FreeBSD 4.0-STABLE #0: Tue Mar 21 01:05:14 EST 2000     root@chronis.pobox.com:/usr/src/sys/compile/MYBSD  i386
0811 15:57 chronis:~% 


0811 15:57 chronis:~% cat scratch/sendtstsrv.py     
import socket         
                      
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind("chronis.pobox.com", 8010) 

while 1:
    s.listen(1)
    conn, addr = s.accept()
    print "connected from", addr
    while 1:
        data = conn.recv(1024)
        if not data: break
    print "done"
    conn.close()

0811 15:58 chronis:~% python scratch/sendtstsrv.py &
[2] 76562

0811 15:58 chronis:~% cat scratch/sendtst.py 
#!/usr/bin/env python

s = "0" * 10000000



import socket
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect("chronis.pobox.com", 8010)
sent = sock.send(s)
if sent != len(s):
    print "sent %d/%d chars" % (sent, len(s))
else:
    print "sent all chars"

0811 15:58 chronis:~% python !$
python scratch/sendtst.py
connected from ('208.210.124.49', 1258)
sent 17520/10000000 chars
done
0811 15:58 chronis:~%            


NOTE: there is nothing in any man page for send() under linux (RH 6.1), Solaris (SunOS 5.5.1), OSF1 V4.0, or FreeBSD{3,4} that states that send() must not perform a
partial write, though of those systems, it only seems
to reproducibly do partial writes under FreeBSD4.0 Stable.

Additionally, W.Richard Stevens' Unix Network Programming Vol 1, second edition states that """
A read or write on a stream socket might input or output fewer bytes than requested, but this is not an error condition.""" (page 77).  Later, Stevens says of send() and recv() "These two functions are similar to the standard read and write functions, but one additional argument is required". (page 354).

scott

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=111710&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:01:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:01:30 -0700
Subject: [Python-bugs-list] [Bug #113576] Py_PROTO missing from the include files
Message-ID: <200009072201.PAA28752@bush.i.sourceforge.net>

Bug #113576, was updated on 2000-Sep-04 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Py_PROTO missing from the include files

Details: Some old extensions still use the Py_PROTO() macro which was
present in Python 1.5.2 and ealier. After the ANSIfication of the sources,
this macro seems to have been removed from the Python include
files.

This breaks all extensions which used the macro.

Adding a 
#define Py_PROTO(args)       args
to pyport.h should remedy this.

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113576&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:01:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:01:54 -0700
Subject: [Python-bugs-list] [Bug #113793] getopt.c compile fails on Solaris 2.6/gcc 2.95.2
Message-ID: <200009072201.PAA28768@bush.i.sourceforge.net>

Bug #113793, was updated on 2000-Sep-07 06:09
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: getopt.c compile fails on Solaris 2.6/gcc 2.95.2

Details: I configured python with the following options:
/ldatae/Misc/python/Python-1.6/configure  --program-prefix=g --target=sparc-su
n-solaris2.6 --prefix=/projects/gnu/sparc-sun-solaris2.6 --exec-prefix=/projects
/gnu/sparc-sun-solaris2.6 --with-gnu-gettext --with-rx --with-curses=/projects/g
nu/sparc-sun-solaris2.6/lib --with-shared --with-profile --enable-nls --x-includ
es=/usr/openwin/include --x-libraries=/usr/openwin/lib --with-wctype-functions -
-with-x-toolkit=motif --with-x --with-threads
After compiling for a while, the build stops with this error:

gcc -g -O2 -I/ldatae/Misc/python/Python-1.6/Python/../Include -I.. -DHAVE_CONFIG
_H   -c -o getopt.o getopt.c
getopt.c: In function `getopt':
getopt.c:51: argument `argv' doesn't match prototype
/usr/include/stdio.h:329: prototype declaration
getopt.c:51: argument `optstring' doesn't match prototype
/usr/include/stdio.h:329: prototype declaration
make[1]: *** [getopt.o] Error 1
make[1]: Leaving directory `/ldatae/Misc/python/Python-1.6/Python'
make: *** [Python] Error 


I can supply more details if someone emails me at lvirden@cas.org .

Thank you.

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113793&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:01:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:01:31 -0700
Subject: [Python-bugs-list] [Bug #113760] 2.0b1: _xmlplus does not allow site xml to override Lib/xml
Message-ID: <200009072201.PAA28755@bush.i.sourceforge.net>

Bug #113760, was updated on 2000-Sep-06 16:53
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b1: _xmlplus does not allow site xml to override Lib/xml

Details: _xmlplus is represented as a means of overriding the new standard lib xml package with a user-supplied xml package, such as the one from XML-SIG ("There's a special feature whereby a user-installed package named _xmlplus overrides the standard xmlpackage; this is intended to give the XML SIG a hook to distribute backwards-compatible updates to the standard xml package." - quote from News on BeOpen site). While this has _some_ effect, it does not work as described. Under 2.0b1, code using the xml package from the XML-SIG (installed in site-packages) will only work if the new standard xml package in lib is renamed or removed. If used with the new standard xml package, imports such as
from xml.sax import saxexts
fail. If the _xmlplus hook is used (by renaming site-packages/xml to site-packages/_xmlplus or using a symlink), the imports succeed, but later the code fails with a message stating that no parsers can be found. 

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113760&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:02:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:02:21 -0700
Subject: [Python-bugs-list] [Bug #110635] test_signal hangs when running as part of testall (PR#288)
Message-ID: <200009072202.PAA28782@bush.i.sourceforge.net>

Bug #110635, was updated on 2000-Jul-31 14:09
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: test_signal hangs when running as part of testall (PR#288)

Details: Jitterbug-Id: 288
Submitted-By: kessler@ccdc.cam.ac.uk
Date: Tue, 11 Apr 2000 06:58:39 -0400 (EDT)
Version: 1.6a2
OS: Irix6.3


Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal
works fine (?) if you run it on its own:

>>> import test.test_signal
starting pause() loop...
call pause()...
+ kill -5 7487 
+ sleep 2 
handlerA (5, <frame object at 100cf928>)
pause() returned
call pause()...
+ kill -2 7487 
+ sleep 2 
handlerB (2, <frame object at 100cf928>)
HandlerBCalled exception caught
call pause()...
+ kill -3 7487 
KeyboardInterrupt (assume the alarm() went off)

however, as part of the test suite, this test hangs:

>>> import test.testall
[...]
test_signal
test_signal
+ sleep 2 
starting pause() loop...
call pause()...
+ kill -5 7454 
+ sleep 2 
+ kill -2 7454 
+ sleep 2 
+ kill -3 7454 





====================================================================
Audit trail:
Tue Jul 11 08:29:16 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:09
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] test_signal hangs when running as part of testall (PR#288)
Date: Tue, 11 Apr 2000 11:27:20 -0400

> Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal
> works fine (?) if you run it on its own:
> 
> >>> import test.test_signal
> starting pause() loop...
> call pause()...
> + kill -5 7487 
> + sleep 2 
> handlerA (5, <frame object at 100cf928>)
> pause() returned
> call pause()...
> + kill -2 7487 
> + sleep 2 
> handlerB (2, <frame object at 100cf928>)
> HandlerBCalled exception caught
> call pause()...
> + kill -3 7487 
> KeyboardInterrupt (assume the alarm() went off)
> 
> however, as part of the test suite, this test hangs:
> 
> >>> import test.testall
> [...]
> test_signal
> test_signal
> + sleep 2 
> starting pause() loop...
> call pause()...
> + kill -5 7454 
> + sleep 2 
> + kill -2 7454 
> + sleep 2 
> + kill -3 7454 

Yes, I've seen this too.  Unfortunately, I don't have a clue, and I
don't have the time to delve into it...  I bet there's a compile time
#define that might do it.  It may have something to do with threads...

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-02 04:05
By: twouters

Comment:
Unsure if this is still an actual problem, but I've seen similar behaviour of test_signal on BSDI 4.0 and 4.0.1 systems, when Python was compiled with threads. The problem appeared to be the BSDI thread library, which had (among other things) problems with pause() in threaded code.

I haven't tried to enable threading on 4.0.x for a while, since new systems are 4.1, and 4.1 works properly with threads.

Does disabling threads fix the problem ? (Or perhaps *en*abling them, if they weren't ?)


-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 15:02
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110635&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:02:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:02:16 -0700
Subject: [Python-bugs-list] [Bug #113811] Python 2.0 beta 1 -- urllib.urlopen() fails
Message-ID: <200009072202.PAA28773@bush.i.sourceforge.net>

Bug #113811, was updated on 2000-Sep-07 09:45
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python 2.0 beta 1 -- urllib.urlopen() fails

Details: In performing a urllib.urlopen(url) with "url" containing a valid URL, I got the following error message:

Traceback (most recent call last):
  File "IGNRatings.py", line 249, in ?
    main(sys.argv[1:])
  File "IGNRatings.py", line 132, in main
    inStream = urllib.urlopen(url)
  File "E:\Python20\lib\urllib.py", line 61, in urlopen
    return _urlopener.open(url)
  File "E:\Python20\lib\urllib.py", line 163, in open
    return getattr(self, name)(url)
  File "E:\Python20\lib\urllib.py", line 259, in open_http
    h = httplib.HTTP(host)
  File "E:\Python20\lib\httplib.py", line 626, in __init__
    self._conn = self._connection_class(host, port)
  File "E:\Python20\lib\httplib.py", line 325, in __init__
    self._set_hostport(host, port)
  File "E:\Python20\lib\httplib.py", line 332, in _set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int():


I looked into this a tiny bit and found that HTTPConnection.__init__() is called with host="http:" -- probably not the right thing. Python 1.6 works correctly.

Thanks,
Bob Alexander
bobalex@home.com

Follow-Ups:

Date: 2000-Sep-07 15:02
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113811&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:02:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:02:20 -0700
Subject: [Python-bugs-list] [Bug #110614] illegal argument type for built-in operation (PR#204)
Message-ID: <200009072202.PAA28777@bush.i.sourceforge.net>

Bug #110614, was updated on 2000-Jul-31 14:06
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 3
Summary: illegal argument type for built-in operation (PR#204)

Details: Jitterbug-Id: 204
Submitted-By: guido@python.org
Date: Tue, 15 Feb 2000 14:24:27 -0500 (EST)
Version: 1.5.2
OS: Solaris 2.7


When PyArg_ParseTuple() needs an int (for an 'i' format char) but finds
something else, it says

TypeError: illegal argument type for built-in operation

instead of the nice friendly error it usually gives.



====================================================================
Audit trail:
Wed Feb 23 21:31:39 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:06
By: none

Comment:
From: "Fred L. Drake, Jr." <fdrake@acm.org>
Subject: Re: [Python-bugs-list] illegal argument type for built-in operation (PR#204)
Date: Tue, 15 Feb 2000 14:33:49 -0500 (EST)


guido@python.org writes:
 > When PyArg_ParseTuple() needs an int (for an 'i' format char) but finds
 > something else, it says
 > 
 > TypeError: illegal argument type for built-in operation

  This is also the case for the 'l' format, which is what range()
uses.


  -Fred

--
Fred L. Drake, Jr.	  <fdrake at acm.org>
Corporation for National Research Initiatives

-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 15:02
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110614&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:02:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:02:57 -0700
Subject: [Python-bugs-list] [Bug #110610] .pyc writing/reading race condition (PR#189)
Message-ID: <200009072202.PAA28789@bush.i.sourceforge.net>

Bug #110610, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: Later
Bug Group: None
Priority: 1
Summary: .pyc writing/reading race condition (PR#189)

Details: Jitterbug-Id: 189
Submitted-By: gudo@python.org
Date: Mon, 24 Jan 2000 14:27:24 -0500 (EST)
Version: 1.5.2
OS: any


Patrick Miller reminded me that there's still a race condition in the reading
and writing of .pyc files.  If two processes decide to write the .pyc, and
a third reads the header after the first complete but before the second
starts, but reads the rest of the file after the second starts but before it
is done, the third can read corrupt data (and won't fall back to reading the
.py source).

Solution: when writing the .pyc file, (1) unlink the file before writing,
(2) use open() with the Unix flags that fail creation if the file exists
(and then just treat it like any open failure when writing the .pyc file).



====================================================================
Audit trail:
Mon Jan 24 14:28:42 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-10 11:52
By: gvanrossum

Comment:
No time to fix this now...
-------------------------------------------------------

Date: 2000-Sep-07 15:02
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110610&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:02:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:02:57 -0700
Subject: [Python-bugs-list] [Bug #110627] Floating point numbers (PR#277)
Message-ID: <200009072202.PAA28793@bush.i.sourceforge.net>

Bug #110627, was updated on 2000-Jul-31 14:08
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 3
Summary: Floating point numbers (PR#277)

Details: Jitterbug-Id: 277
Submitted-By: gellsmore@yahoo.com
Date: Wed,  5 Apr 2000 17:00:09 -0400 (EDT)
Version: Python CE 1.0b1
OS: Windows CE H/PC 3.01 pro


Floating point answer objects not returned correctly

>>>3.1
g

All floats return g but will work in scenario below where floats form part of
the expression but not the answer object

>>>int(3.1/2)
1

this works.



====================================================================
Audit trail:
Mon May 22 17:49:40 2000	guido	changed notes
Mon May 22 17:49:40 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-03 05:50
By: twouters

Comment:
Hm, Python CE 1.0b1 ? I'm not sure if that's an old version of Python ported to the CE, or a recent version of Python ported to the CE with a new version number. In any case, I dont believe the CE port is being maintained by the core Python group, so I don't think we can do much about it.

-------------------------------------------------------

Date: 2000-Sep-07 15:02
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110627&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:03:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:03:12 -0700
Subject: [Python-bugs-list] [Bug #110686] cStringIO lacks the readlines method (PR#409)
Message-ID: <200009072203.PAA28813@bush.i.sourceforge.net>

Bug #110686, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 4
Summary: cStringIO lacks the readlines method (PR#409)

Details: Jitterbug-Id: 409
Submitted-By: pierre@saiph.com
Date: Sun, 23 Jul 2000 13:41:59 -0400 (EDT)
Version: 1.5.2
OS: sparc solaris


cStringIO is supposed to be the C version of  For some reason,
it does not provide the readlines method.
The obvious turnaround is to use StringIO instead: no hurry to fix,
at least on my side.



====================================================================
Audit trail:
Mon Jul 24 18:41:02 2000	jeremy	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-05 13:11
By: loewis

Comment:
Fixed in Patch #101423,
http://sourceforge.net/patch/?func=detailpatch&patch_id=101423&group_id=5470
-------------------------------------------------------

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110686&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:03:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:03:16 -0700
Subject: [Python-bugs-list] [Bug #110695] complexobject.c optimization error on SGI (PR#144)
Message-ID: <200009072203.PAA28818@bush.i.sourceforge.net>

Bug #110695, was updated on 2000-Jul-31 14:28
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: complexobject.c optimization error on SGI (PR#144)

Details: Jitterbug-Id: 144
Submitted-By: robert.harrison@pnl.gov
Date: Fri, 3 Dec 1999 01:35:19 -0500 (EST)
Version: 1.5.2
OS: IRIX64 6.5


On an SGI (IRIX64 6.5, MIPSpro Compilers: Version 7.3.1m, -n32)
Python-1.5.2/Objects/complexobject.c does not compile correctly 
with optimization.  The problem shows up as a bus error in
PyComplex_ImagAsDouble when importing Numeric Python.  All works fine 
when this one file is compiled with -O0 (-O1 and higher fail).
I assume that this is probably just a compiler error.




====================================================================
Audit trail:
Fri Dec 03 10:39:28 1999	guido	changed notes
Fri Dec 03 10:39:28 1999	guido	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110695&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:03:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:03:17 -0700
Subject: [Python-bugs-list] [Bug #110704] IDLE (PR#400)
Message-ID: <200009072203.PAA28822@bush.i.sourceforge.net>

Bug #110704, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: IDLE (PR#400)

Details: Jitterbug-Id: 400
Submitted-By: crislipm@earthlink.net
Date: Sun, 16 Jul 2000 20:40:24 -0400 (EDT)
Version: 1.5.2
OS: Linuxppc, Suse dist


more for curiosity/FYI

Using 1.5.2 (the version that came with the suse linuxppc) and IDLE 0.5 on an
ibook (version 2).

IDLE causes the keyboard to stop working (I am not certain which, if any action,
causes this, but it is reproducable) and the problem continues when I warm boot
back to the MAC OS.  Have to do a cold boot to get keyboard to respond again.




====================================================================
Audit trail:
Mon Jul 24 18:30:07 2000	jeremy	changed notes
Mon Jul 24 18:30:07 2000	jeremy	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110704&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:03:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:03:21 -0700
Subject: [Python-bugs-list] [Bug #110844] Annoyance in ftpmirror.py script (PR#48)
Message-ID: <200009072203.PAA28834@bush.i.sourceforge.net>

Bug #110844, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Annoyance in ftpmirror.py script (PR#48)

Details: Jitterbug-Id: 48
Submitted-By: mok@imsb.au.dk
Date: Mon, 9 Aug 1999 10:27:00 -0400 (EDT)
Version: 1.5.2
OS: Linux Linux 2.0.36


The script ftpmirror.py contains some useful (for me) routines, but the file 
cannot be imported unless the following (trivial) patch is applied

395c395,396
< main()
---
> if __name__ == "__main__":
>       main()




====================================================================
Audit trail:
Tue Aug 10 17:46:08 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110844&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:03:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:03:18 -0700
Subject: [Python-bugs-list] [Bug #110820] Jonathan Craft: Possible to-do addition (PR#116)
Message-ID: <200009072203.PAA28826@bush.i.sourceforge.net>

Bug #110820, was updated on 2000-Aug-01 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Jonathan Craft: Possible to-do addition (PR#116)

Details: Jitterbug-Id: 116
Submitted-By: Guido van Rossum <guido@CNRI.Reston.VA.US>
Date: Mon, 25 Oct 1999 10:38:58 -0400
Version: None
OS: None

A worthy to-do item.

------- Forwarded Message

Date:    Sat, 23 Oct 1999 08:24:32 -0000
From:    Jonathan Craft <jcchina@bigfoot.com>
To:      guido@python.org
Subject: Possible to-do addition

Hi Guido,

  Is there a visual interface builder (as in VBasic, Hypercard, Icon)
  for Tkinter? I haven't been able to find any information on it (I'm
  new to Python). If not, that would be a good to-do.


 Jonathan Craft                         mailto:jcchina@bigfoot.com



------- End of Forwarded Message



====================================================================
Audit trail:
Mon Oct 25 15:13:11 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-06 10:03
By: twouters

Comment:
I believe several people are working on something like this (or at least said they were... they might have quit in despair :-) I'm not sure if this belongs on the Python buglist, though.

-------------------------------------------------------

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110820&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:03:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:03:19 -0700
Subject: [Python-bugs-list] [Bug #110834] urlparse and HTTP parameters (PR#205)
Message-ID: <200009072203.PAA28830@bush.i.sourceforge.net>

Bug #110834, was updated on 2000-Aug-01 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: Later
Bug Group: Feature Request
Priority: 3
Summary: urlparse and HTTP parameters (PR#205)

Details: Jitterbug-Id: 205
Submitted-By: mnot@akamai.com
Date: Tue, 15 Feb 2000 17:09:44 -0500 (EST)
Version: 1.5.2
OS: All


Python parses urls into the following data structure:
  (scheme, netloc, path, params, query, fragment)
and references RFC1808. 1808 has been updated by RFC2396, which allows
on each path segment, not just the last. This would imply a data structure
either like this:
  (scheme, netloc, path, query, fragment)
or this:
  (scheme, netloc, [(segment, parameters)...], query, fragment)

Rather than updating urlparse.py (and introducing incompatibility), it may be
nice to introduce a new class (say, uriparse.py) that implements 2396. If
there's enough interest, I may give it a go...


====================================================================
Audit trail:
Wed Feb 23 21:39:30 2000	guido	sent reply 1
Wed Feb 23 21:39:42 2000	guido	changed notes
Wed Feb 23 21:39:42 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:13
By: none

Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: urlparse and HTTP parameters (PR#205)
Date: Wed Feb 23 21:39:30 2000

Go for it!

--Guido van Rossum

-------------------------------------------------------

Date: 2000-Aug-01 14:13
By: none

Comment:
Go for it!
-------------------------------------------------------

Date: 2000-Aug-16 19:02
By: fdrake

Comment:
An excellent idea; it can be incorporated in the existing urlparse module using new names.  This won't be done for Python 2.0 at any rate, however.
-------------------------------------------------------

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110834&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:03:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:03:22 -0700
Subject: [Python-bugs-list] [Bug #110855] test_array.py fails (PR#143)
Message-ID: <200009072203.PAA28838@bush.i.sourceforge.net>

Bug #110855, was updated on 2000-Aug-01 14:37
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Irreproducible
Priority: 1
Summary: test_array.py fails (PR#143)

Details: Jitterbug-Id: 143
Submitted-By: ellement@sdd.hp.com
Date: Thu, 2 Dec 1999 14:04:38 -0500 (EST)
Version: 1.5.2
OS: HP-UX 10.20


After building python, 'make test' fails when test_array is run:

> python Lib/test/test_array.py
Traceback (innermost last):
  File "Lib/test/test_array.py", line 85, in ?
    main()
  File "Lib/test/test_array.py", line 10, in main
    testtype('c', 'c')
  File "Lib/test/test_array.py", line 21, in testtype
    a.append(example)
AttributeError: '' object has no attribute 'append'
Memory fault(coredump)


How do I go about debugging this?


====================================================================
Audit trail:
Fri Dec 03 10:38:53 1999	guido	changed notes
Fri Dec 03 10:38:53 1999	guido	moved from incoming to irreproducible

Follow-Ups:

Date: 2000-Aug-01 14:37
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] test_array.py fails (PR#143)
Date: Thu, 02 Dec 1999 14:07:32 -0500

> Full_Name: David Ellement
> Version: 1.5.2
> OS: HP-UX 10.20
> Submission from: sanrel1.sdd.hp.com (192.6.114.30)
> 
> 
> After building python, 'make test' fails when test_array is run:
> 
> > python Lib/test/test_array.py
> Traceback (innermost last):
>   File "Lib/test/test_array.py", line 85, in ?
>     main()
>   File "Lib/test/test_array.py", line 10, in main
>     testtype('c', 'c')
>   File "Lib/test/test_array.py", line 21, in testtype
>     a.append(example)
> AttributeError: '' object has no attribute 'append'
> Memory fault(coredump)
> 
> 
> How do I go about debugging this?

Seems like a pretty serious problem in your build.  Use a debugger
(e.g. gdb).  The bugs list is not the forum to discuss this, since the
bug is likely in your installation and not in Python.  Try
comp.lang.python for help.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:37
By: none

Comment:
Build problems?
-------------------------------------------------------

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110855&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:03:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:03:26 -0700
Subject: [Python-bugs-list] [Bug #110924] support Unicode for Python source code
Message-ID: <200009072203.PAA28842@bush.i.sourceforge.net>

Bug #110924, was updated on 2000-Aug-02 08:17
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 1
Summary: support Unicode for Python source code

Details: exec u"print 42"
doesn't work.

Follow-Ups:

Date: 2000-Aug-09 02:35
By: effbot

Comment:
python doesn't support 16-bit source code -- so what exactly do you want exec to do?
-------------------------------------------------------

Date: 2000-Aug-17 05:17
By: none

Comment:
That's exactly my point. Python should support Unicode
everywhere, in __str__ and __repr__, exec and eval, in open(), as a format for the source code (which would result in all variable names to be Unicode)...

Currenly working with Unicode (e.g. for XML) is a mess, because it's supported nowhere.

exec "a='ü'" seems to work and seems to treat the string as iso-8859-1 (or not at all)

-------------------------------------------------------

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110924&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:03:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:03:01 -0700
Subject: [Python-bugs-list] [Bug #110656] IDLE goto file/line (PR#352)
Message-ID: <200009072203.PAA28800@bush.i.sourceforge.net>

Bug #110656, was updated on 2000-Jul-31 14:11
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: IDLE goto file/line (PR#352)

Details: Jitterbug-Id: 352
Submitted-By: gpk@bell-labs.com
Date: Fri,  9 Jun 2000 22:45:05 -0400 (EDT)
Version: 1.6  CVS today
OS: Solaris 2.6


When using IDLE's shell window   Debug->Go to file/line,
you have to be overly careful what you select.
Specifically, if you select a region that contains a newline,
IDLE won't be able to find a file and line number.

For example, if you select
  v-- from there
   File "/export/h1/gpk/schoolweb.local/schoolweb/parse.py", line 199, in
__str__
  
  ^-- to there  (i.e. 2 characters in, on the following line),
you will get the following error message: "No special line: X the line you
point
to doesn't look like a file name followed by a line number."

That is unfortunate, as it's really convenient to make a quick flick
down from one line to the next, to select a complete line.



By the way, the error box requires you to click "OK".
That's a bug.   It isn't OK.
It's a crime against the King's English, committed by the minions
of Bill Gates.  You should not be following their lead.



====================================================================
Audit trail:
Tue Jul 11 08:25:59 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110656&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:03:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:03:02 -0700
Subject: [Python-bugs-list] [Bug #110676] fd.readlines() hangs (via popen3) (PR#385)
Message-ID: <200009072203.PAA28804@bush.i.sourceforge.net>

Bug #110676, was updated on 2000-Jul-31 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: fd.readlines() hangs (via popen3) (PR#385)

Details: Jitterbug-Id: 385
Submitted-By: aron@gweep.net
Date: Tue,  4 Jul 2000 19:07:55 -0400 (EDT)
Version: 1.5.2
OS: Red Hat Linux 6.1 (2.1.12-20)


The following scripts cause a hang at the denoted line. To execute
this code, copy the first bit to master.py and the second to slave.py
(both should be in the same directory). Then, "cd" to that directory
and "python master.py".

Manually killing the program is necessary.

This script has also been tested on a Solaris 5.7 box and worked.

---master.py---
import popen2

r,w,e = popen2.popen3 ( 'python slave.py' )
r.readlines() # Hangs here
e.readlines()
r.close()
e.close()
w.close()

---end---

---slave.py---
import sys

e = sys.stderr.write
w = sys.stdout.write

e(400*'this is a test\n')
w(400*'this is another test\n')
---end---



====================================================================
Audit trail:
Tue Jul 11 08:24:23 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110676&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:03:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:03:28 -0700
Subject: [Python-bugs-list] [Bug #113463] Inconsistent handling of arg -/-- by getopt.getopt() ?
Message-ID: <200009072203.PAA28846@bush.i.sourceforge.net>

Bug #113463, was updated on 2000-Sep-02 19:44
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Inconsistent handling of arg -/-- by getopt.getopt() ?

Details: Problem with function getopt of module getopt.py of Python 1.5.1?

Case 1:

>>> import getopt, string
>>> args = string.split('-a -b b_val - some more stuff -c')
>>> optlist, trailing_args = getopt.getopt(args, 'ab:c')
>>> optlist
[('-a', ''), ('-b', 'b_val')]
>>> trailing_args
['-', 'some', 'more', 'stuff', '-c']

Case 2:

>>> import getopt, string
>>> args = string.split('-a -b b_val -- some more stuff -c')
>>> optlist, trailing_args = getopt.getopt(args, 'ab:c')
>>> optlist
[('-a', ''), ('-b', 'b_val')]
>>> trailing_args
['some', 'more', 'stuff', '-c']

The differences are: 
In case 1, I have "-" in the args list and I get it as the first element of the trailing_args output list; In case 2, I have "--" in the args list and I get nothing about it in the trailing_args output list.

This happens because in line 7 of the function getopt (reproduced below) the "--" element of args is discarded.

~~~~~~~~~
Function getopt:

def getopt(args, shortopts, longopts = []):
    list = []
    longopts = longopts[:]
    longopts.sort()
    while args and args[0][:1] == '-' and args[0] != '-':
        if args[0] == '--':
            args = args[1:]
            break
        if args[0][:2] == '--':
            list, args = do_longs(list, args[0][2:], longopts, args[1:])
        else:
            list, args = do_shorts(list, args[0][1:], shortopts, args[1:])

    return list, args


Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113463&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:03:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:03:32 -0700
Subject: [Python-bugs-list] [Bug #113721] urllib handles proxy badly
Message-ID: <200009072203.PAA28849@bush.i.sourceforge.net>

Bug #113721, was updated on 2000-Sep-06 09:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: urllib handles proxy badly

Details: The following gives "host not found" when a proxy server is in use:

    import urllib
    w=urllib.urlopen("http://www.pythonlabs.com")

The host name is changed to "http=PROXYSERVER" and fails

This works under Python 1.5.2, but fails under Python 2.0b1

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113721&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:03:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:03:33 -0700
Subject: [Python-bugs-list] [Bug #113788] NT 2.0b1 Doc/modindex.html is almost empty
Message-ID: <200009072203.PAA28853@bush.i.sourceforge.net>

Bug #113788, was updated on 2000-Sep-07 03:29
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: NT 2.0b1 Doc/modindex.html is almost empty

Details: Doc/modindex.html in the 2.0b1 release on NT is empty. 
There is only the header and footer but no module list.

Can't login to sourceforge so:
tebeka@lycosmail.com


Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113788&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:04:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:04:08 -0700
Subject: [Python-bugs-list] [Bug #110690] Bug in os.environ for Windows (PR#50)
Message-ID: <200009072204.PAA28877@bush.i.sourceforge.net>

Bug #110690, was updated on 2000-Jul-31 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Bug in os.environ for Windows (PR#50)

Details: Jitterbug-Id: 50
Submitted-By: bobalex@uppercase.xerox.com
Date: Wed, 11 Aug 1999 19:19:16 -0400 (EDT)
Version: 1.5.2
OS: WinNT


os.environ for Windows appears to be a map-type object that converts its keys to
upper case. Retrieval using a mixed case key works in some cases, but some
overloaded "operators" don't seem to do the right thing unless I pass an
all-upper-case key. E.g.:

>>> os.environ["x"] = "y"               # Stores pair {"X": "y"}
>>> os.environ["x"]                     # Works, indicates an effort is made
'y'                                     #   to retrieve mixed case keys
>>> os.environ.get("x", "NOT FOUND")    # Doesn't see the key "x"
'NOT FOUND'
>>> os.environ.get("X", "NOT FOUND")    # Works with all-upper-case key
'y'
>>> del os.environ["x"]                 # Doesn't see the key "x"
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "E:\Program Files\Python\Lib\UserDict.py", line 16, in __delitem__
    def __delitem__(self, key): del self.data[key]
KeyError: x
>>> del os.environ["X"]                 # Works with all-upper-case key



====================================================================
Audit trail:
Mon Aug 30 12:33:44 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 10:34
By: fdrake

Comment:
Fixed at some point in the past.  Tested OK using 2.0b1 on Win2K.
-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110690&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:04:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:04:13 -0700
Subject: [Python-bugs-list] [Bug #110655] getpass.getpass (PR#349)
Message-ID: <200009072204.PAA28893@bush.i.sourceforge.net>

Bug #110655, was updated on 2000-Jul-31 14:10
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: getpass.getpass (PR#349)

Details: Jitterbug-Id: 349
Submitted-By: ctalley@caci.com
Date: Thu,  8 Jun 2000 15:52:19 -0400 (EDT)
Version: 1.5.2
OS: W95


When using this code, the third line is skipped.  That is, the prompt
appears, but the program doesn't pause to accept input data.  It goes
right to the fourth line and pauses there.  I end up with a null string
for "fromaddr".

username=raw_input('Enter FTP server account username: ')
password=getpass.getpass('Enter FTP server account password: ')
fromaddr=raw_input('Enter your e-mail address: ')
toaddr=raw_input('Enter e-mail address for notification: ')

When using this code, everything works (although echo of the
password isn't suppressed.)

username=raw_input('Enter FTP server account username: ')
password=raw_input('Enter FTP server account password: ')
fromaddr=raw_input('Enter your e-mail address: ')
toaddr=raw_input('Enter e-mail address for notification: ')

The difference between the two code segments is that the first uses
the getpass method on the second line and the second uses raw_input.
What I think is happening is that getpass is leaving some garbage
in a buffer somewhere which is seen by raw_input as data.  raw_input
happily accepts the data and goes to the next line.  I've devised
several workarounds including "flush_input_buffer=raw_input('')"
immediately following the call to getpass.  It's ugly, but it works.

Thanks,
Carl Talley



====================================================================
Audit trail:
Tue Jul 11 08:25:59 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110655&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:03:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:03:34 -0700
Subject: [Python-bugs-list] [Bug #113807] PyArg_ParseTupleAndKeywords and Unicode...?
Message-ID: <200009072203.PAA28857@bush.i.sourceforge.net>

Bug #113807, was updated on 2000-Sep-07 09:11
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: PyArg_ParseTupleAndKeywords and Unicode...?

Details: I have a small extension that works OK with
PyArg_ParseTuple and a es# format; using the
same format with PyArg_ParseTupleAndKeywords
doesn't seem to work -- after importing that
module, Python thinks 2 args are needed, and
one of them is an 'impossible format character'.

Experimentally switching to s#, it works
_except_ when I use the name=value format
AND I pass a u'something' as the value, then
it crashes the interpreter.

So I'm going back to PyArg_ParseTuple, but,
the AndKeywords form _is_ also supposed to
work with Unicode, right...?

The platform I'm using is NT 4, SP6, with
MS VC++ 6 SP4 -- just in case it's platform
specific...


Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113807&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:04:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:04:27 -0700
Subject: [Python-bugs-list] [Bug #110694] PRIVATE: Threads and readline (PR#120)
Message-ID: <200009072204.PAA28905@bush.i.sourceforge.net>

Bug #110694, was updated on 2000-Jul-31 14:28
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: PRIVATE: Threads and readline (PR#120)

Details: Jitterbug-Id: 120
Submitted-By: xfb52@dial.pipex.com
Date: Fri, 29 Oct 1999 14:33:55 -0400 (EDT)
Version: 1.5.2
OS: FreeBSD 3.2


When python is compiled with thread support and readline, ^C no longer
works properly (interpreter goes into an infinite loop).
(Tried with readline 2.0, 2.2 and 4.0).

The same system compiled without readline but with threads works fine,
and compiled without threads but with readline works fine.

The error seems to centre around the signal handler installed by
call_readline in Modules/readline.c which does not call signal_handler
in Modules/signalmodule.c (which is what happens without readline).

I have found an inadequate fix which works with readline-4.0 (but
not earlier realeases).  This makes ^C work but only after a RETURN
is pressed.  Whilst not perfect, it does at least allow readline
and threads.

Hopefully this may point someone who can better understand the signal
handling to find a better fix.

I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.

--Alex

*** Modules/readline.c  Fri Oct 29 19:31:13 1999
--- Modules/readline.c.ORIG     Fri Oct 29 19:14:27 1999
***************
*** 34,40 ****
  extern int rl_bind_key_in_map();
  extern int rl_initialize();
  extern int add_history();
- extern int rl_catch_signals;
  extern Function *rl_event_hook;
  #endif
  
--- 34,39 ----
***************
*** 233,239 ****
  static void
  setup_readline()
  {
-         rl_catch_signals=0;
        rl_readline_name = "python";
        /* Force rebind of TAB to insert-tab */
        rl_bind_key('\t', rl_insert);
--- 232,237 ----
***************
*** 277,283 ****
        int n;
        char *p;
        RETSIGTYPE (*old_inthandler)();
! /*    old_inthandler = signal(SIGINT, onintr); */
        if (setjmp(jbuf)) {
  #ifdef HAVE_SIGRELSE
                /* This seems necessary on SunOS 4.1 (Rasmus Hahn) */
--- 275,281 ----
        int n;
        char *p;
        RETSIGTYPE (*old_inthandler)();
!       old_inthandler = signal(SIGINT, onintr);
        if (setjmp(jbuf)) {
  #ifdef HAVE_SIGRELSE
                /* This seems necessary on SunOS 4.1 (Rasmus Hahn) */
***************
*** 288,294 ****
        }
        rl_event_hook = PyOS_InputHook;
        p = readline(prompt);
! /*    signal(SIGINT, old_inthandler); */
        if (p == NULL) {
                p = malloc(1);
                if (p != NULL)
--- 286,292 ----
        }
        rl_event_hook = PyOS_InputHook;
        p = readline(prompt);
!       signal(SIGINT, old_inthandler);
        if (p == NULL) {
                p = malloc(1);
                if (p != NULL)




====================================================================
Audit trail:
Tue Nov 02 20:44:47 1999	guido	changed notes
Tue Nov 02 20:44:47 1999	guido	moved from incoming to platformbug
Wed Nov 03 10:41:38 1999	guido	changed notes
Wed Nov 03 10:41:39 1999	guido	changed notes
Wed Nov 03 10:44:43 1999	guido	changed notes

Follow-Ups:

Date: 2000-Aug-01 14:02
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] PRIVATE: Threads and readline (PR#120)
Date: Mon, 01 Nov 1999 17:53:46 -0500

> When python is compiled with thread support and readline, ^C no longer
> works properly (interpreter goes into an infinite loop).
> (Tried with readline 2.0, 2.2 and 4.0).

Thanks for your bug report.  I see that you are using FreeBSD.  Could
it be a FreeBSD related problem?  I don't see the same thing on
Solaris or Red Hat Linux.

Also, can you describe exactly how you reproduce the problem?

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:02
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] PRIVATE: Threads and readline (PR#120)
Date: Wed, 03 Nov 1999 10:40:18 -0500

Resolution.

------- Forwarded Message

Date:    Wed, 03 Nov 1999 15:24:59 +0000
From:    Alex Zbyslaw <xfb52@dial.pipex.com>
To:      guido@cnri.reston.va.us
Subject: Re: [Python-bugs-list] PRIVATE: Threads and readline

I believe that you were right and that this is a FreeBSD bug.  I finally
traced  the problem back to the use of the setjmp/longjmp in
readline.c.  For whatever reason, this messes up on FreeBSD.

I'll post my final patches on comp.lang.python myself.  Please consider
the problem closed.

Thanks for following up.  I think I'll stick to FreeBSD.  I grew up on
BSD4.2/3 and system v still gives me the heebie jeebies :-)

All the best,

- --Alex

------- End of Forwarded Message


-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] PRIVATE: Threads and readline (PR#120)
Date: Wed, 03 Nov 1999 10:42:33 -0500


------- Forwarded Message

Date:    Tue, 02 Nov 1999 11:57:23 +0000
From:    Alex Zbyslaw <xfb52@dial.pipex.com>
To:      guido@cnri.reston.va.us
Subject: RE: Re: [Python-bugs-list] PRIVATE: Threads and readline

>> When python is compiled with thread support and readline, ^C no longer
>> works properly (interpreter goes into an infinite loop).
>> (Tried with readline 2.0, 2.2 and 4.0).

>Thanks for your bug report.  I see that you are using FreeBSD.  Could
>it be a FreeBSD related problem?  I don't see the same thing on
>Solaris or Red Hat Linux.
>
>Also, can you describe exactly how you reproduce the problem?
>
>--Guido van Rossum (home page: http://www.python.org/~guido/)

Thanks for your mail, Guido.  Yes, I suppose it could be a FreeBSD
problem, though I was originally put on to the readline connection by
some articles in comp.lang.python which mentioned extremely similar
symptoms under Debian Linux.  What those articles did not mention was
the thread connection which I guessed for myself.  See articles titled
"Control-C on Unix meisbehaviour?" on 18th Oct 1999.  People in that
thread reported similar problems on various systems, whilst others had
no problem on apparently identical systems.  No one mentioned if they
had thread support.

Creating the problem is, for me, simple.  I compile python 1.5.2 with
thread support enabled.  (Thread and signal tests are passed by make
test and a quickie thread program works as expected).  If I go into the
interpreter
	python
and type ^C, everything goes into an infinite loop.

If I recompile python without threads, but with readline, then go into
the interpreter then press ^C I get KeyboardInterrupt as expected.

If I recompile with threads but without readline, then again, I get
KeyboardInterrupt as expected.

In all three cases, pressing ^C while a program is running gets correct
behaviour.



>From what I can determine:
	The readline module was written so that it bypassed any signal handler
installed by the readline library.  It institutes its own handler in
readline.c (onintr) which catches the interrupt and returns NULL (which
somewhere back down the line is interpreted as KeyboardInterrupt).

	However, with threads enabled (but no readline) there seems to be a
different behaviour, where the interrupt is caught by the regular signal
handler (I forget the name but its in my bug report - in
signalmodule.c).  My guess was that with threads enabled this signal
handler was doing something important.  But with readline support turned
on, this handler was not being called which caused some problem occur. 
I did try adapting the code in readline.c to call this signal handler
itself, but that didn't seem to work (though I forget what happened).

What my patch does is to forget about the local signal handler 'onintr'
and, instead, stick with whatever the "default" signal handler is. 
readline_4.0 allows you to turn off any signal handling in the readline
library itself, so the "default" handler will be whatever python
installs (in signalmodule.c).

This then "works" in that pressing ^C does not generate an infinite
loop.  But the call_readline function in readline.c does not immediately
return NULL, so you have to press RETURN before the KeyboardInterrupt is
generated.  

I never did figure out a way to both call the default signal handler and
return a NULL from call_readline -- which I believe would cause
"correct" ^C behaviour.  My C is somewhat rusty as I spend my time in
Python (by choice) and Perl (by neccessity).


I'm not sure what else I can tell you about the problem, but if there is
any more data I could provide for you, please ask.



As another bizarre data point: when I run a threaded python interpreter
on a program which does not use threads, and pipe the output to less,
less gets very confused and fails to update about half the screen,
leaving it blank.  This happens after hitting SPACE a couple of times. 
All the data is there, and if I jump less to the end of input and then
go back through the the data, I can see it all normally. Same program
and unthreaded python and less works just fine.  If you have ANY idea
why adding thread support could affect a program further down a pipe I'd
love to know.


By the way, I have no objection to making my bug report and patch
public, as long as there is some way to remove my email address from
it.  I have had only one piece of spam in the last year and I'd like to
keep it that way :-) As the good cafe owner said "Spam's orf"!  Although
it's not perfect, the patch has made threaded python usable for me. If
there are other people out there in the same boat and it helped them,
that would be great.


- -- 
Phone: 0131 468 2422
Email: xfb52@dial.pipex.com

------- End of Forwarded Message


-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Jack Jansen <jack@oratrix.nl>
Subject: Re: [Python-bugs-list] PRIVATE: Threads and readline (PR#120)
Date: Wed, 03 Nov 1999 23:32:19 +0100

> As another bizarre data point: when I run a threaded python interpreter
> on a program which does not use threads, and pipe the output to less,
> less gets very confused and fails to update about half the screen,
> leaving it blank.  This happens after hitting SPACE a couple of times. 
> All the data is there, and if I jump less to the end of input and then
> go back through the the data, I can see it all normally. Same program
> and unthreaded python and less works just fine.  If you have ANY idea
> why adding thread support could affect a program further down a pipe I'd
> love to know.

As I like puzzles I spent some time thinking on this, and it must be
either (a) kernel bug, (b) a very strange stdio bug or (c) an incorrect 
observation. If your system supports memory-mapped I/O and stdio uses
it and it can somehow signal that a whole buffer is available while it 
isn't but only the tail end is available (because it uses an
overlapping memcopy which goes back-to-front, for instance) the reader 
in the pipe might wakeup too early and see null bytes. But if this was 
a bet I think I'd put my money on (c) (but absolutely no offense meant!).
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 

-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Alex Zbyslaw: RE: Re: [Python-bugs-list] PRIVATE: Threads and readline (PR#120)
Date: Mon, 08 Nov 1999 10:30:24 -0500


------- Forwarded Message

Date:    Sat, 06 Nov 1999 11:17:00 +0000
From:    Alex Zbyslaw <xfb52@dial.pipex.com>
To:      guido@cnri.reston.va.us
Subject: RE: Re: [Python-bugs-list] PRIVATE: Threads and readline

This is the message I posted today on comp.lang.python.

Btw, I forgot to mention that to compile for thread support on FreeBSD
3.2 (and I would think 3.3) you only need to specify "-pthread" on the
link line.  That automatically links in the threaded C libraries. 
Everything else from the standard configure would appear to be correct.

All the best,

- --Alex


Subject:  Re: Control-C on Unix misbehaviour?
Date:  Sat, 06 Nov 1999 11:08:05 +0000

Quinn Dunkan wrote:
>
> On Mon, 18 Oct 1999 15:47:52 +0200, flight@mathi.uni-heidelberg.de
> Here's a data point for Irix6:
> If you hit ^C at the >>> prompt with readline loaded (python 1.5), python
> stops responding.  Further ^Cs do nothing, in fact the only way I've found
> to get out is to kill from another shell or hit ^z kill %.

I had exactly the same problem on FreeBSD 3.2  but ONLY when I had
thread support enabled.

I have eventually tracked the problem down to a bad interaction (read
library/kernel bug) between threads/sigjmp and interrupted reads.

I have created two "fixes" which can be applied either to a) python or
b) python and readline which fix the problems differently.  The fixes
are pretty trivial and so far they work for me.  You can check them out
at http://www.xfb52.dial.pipex.com/patches/python.shtml

I don't know how they may affect people who have had ^C dumping them
into a shell.  No one else has mentioned whether they had thread support
enabled or not.

>From extensive poking around I am quite sure that this misbehaviour is
not a bug in either Python or readline.

Good luck,

- --Alex

------- End of Forwarded Message


-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
There is a problem with threads + readline + signals on FreeBSD.
Apparently readline is using longjmp and this messes things up.
(I told you longjmp was evil. :-)
-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110694&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:04:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:04:28 -0700
Subject: [Python-bugs-list] [Bug #110710] Segmentation fault on range (PR#71)
Message-ID: <200009072204.PAA28913@bush.i.sourceforge.net>

Bug #110710, was updated on 2000-Jul-31 14:30
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: Segmentation fault on range (PR#71)

Details: Jitterbug-Id: 71
Submitted-By: mz@pdm.pvt.net
Date: Mon, 6 Sep 1999 06:45:45 -0400 (EDT)
Version: 1.5.2
OS: Debian GNU/Linux 2.1


When I start python and try to evaluate `range(1000000000)', I receive
segmentation fault:

  $ python
  Python 1.5.2 (#0, May  4 1999, 14:45:33)  [GCC 2.7.2.3] on linux2
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  >>> range(1000000000)
  Segmentation fault

This can also be reproduced with Python 1.5.1 from the Debian 2.1 i386
distribution.



====================================================================
Audit trail:
Tue Sep 07 11:13:29 1999	guido	changed notes
Tue Sep 07 11:13:29 1999	guido	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Aug-04 07:00
By: jhylton

Comment:
I can't reproduce this bug on 1.5.2 or current CVS.  In both cases, I get a MemoryError.

-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110710&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:04:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:04:25 -0700
Subject: [Python-bugs-list] [Bug #110685] isdir bad behaviouring (PR#408)
Message-ID: <200009072204.PAA28901@bush.i.sourceforge.net>

Bug #110685, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: isdir bad behaviouring (PR#408)

Details: Jitterbug-Id: 408
Submitted-By: thomas.mangin@free.fr
Date: Sun, 23 Jul 2000 08:39:25 -0400 (EDT)
Version: 1.5.2
OS: Linux


This report is not a "Bug" report but more a library "Misbehaviouring" report.
I am concern about os.path.isdir return code. (this can probably applied to
isfile)

The return code express a boolean value : the file is a directory or not.

But I notice that if you don't have read access into the directory where the
file is stored, the function always return 0.
Or the path can refer a directory, returning 0 simply isn't right.

I beleve an exception must be raised to inform the programmer about this access
right problem and must be silently ignored.




====================================================================
Audit trail:
Mon Jul 24 18:32:17 2000	jeremy	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110685&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:04:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:04:34 -0700
Subject: [Python-bugs-list] [Bug #110854] Re: Date problem unresolved [DIN 2646] (fwd) (PR#109)
Message-ID: <200009072204.PAA28926@bush.i.sourceforge.net>

Bug #110854, was updated on 2000-Aug-01 14:37
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Irreproducible
Priority: 3
Summary: Re: Date problem unresolved [DIN 2646] (fwd) (PR#109)

Details: Jitterbug-Id: 109
Submitted-By: Curt Finch <curt@journyx.com>
Date: Thu, 14 Oct 1999 14:58:08 -0500 (CDT)
Version: None
OS: None

anyone heard of any python time bugs?

__________________________________________________________________
Web-Based Project Management,                              Journyx
TimeSheet and Tracking Software       FREE           (800)755-9878
FREE at http://journyx.com/wts.html           curt@www.JOURNYX.com
------------------------------------------------------------------


---------- Forwarded message ----------
Date: Thu, 14 Oct 1999 14:09:35 -0500 (CDT)
From: John Maddalozzo <john@journyx.com>
To: "Stappert, Andreas" <andreas.stappert@key-work.de>
Cc: support@journyx.com
Subject: Re: Date problem unresolved [DIN 2646]


Andreas, 

I'm stumped. It seems there is a problem in the python time library.
I may have to post a message to a python news group if code inspection
doesn't turn anything up. 2646 is the problem report number. 
We'll dig around and see what we can find out.

Meanwhile, you might want to send me the output of the uname -a command
and any other information you have that might help. (Linux level, etc)

Regards, John


__________________________________________________________________
Web-Based Project Management and TimeSheet Software    JournyxTime
FREE at http://journyx.com/wts.html
John Maddalozzo  - john@JOURNYX.com  (512)834-8888 / (800)755-9878
------------------------------------------------------------------

On Thu, 14 Oct 1999, Stappert, Andreas wrote:

> Hi John,
> 
> Well, for some reason I always have the strangest thing happen to me :-)
> even though I try to conform to every standards I know of...
> 
> Here is what I get. Looks like it matches your machine (our server date is
> set a day off). Do you think it would help if we change the timezone to EST
> or something?
> 
> > date +%s
> 939838233
> timesheet:~>
> 
> The hardware is an (old) 486 (yes I know old ... that is just our
> testserver, once we are putting Journyx to real use, we are going to put a
> nicer machine underneath it). I don't know the mainboard type by heart.
> 
> Oh, I should probably also tell you this: At the beginning, the time was
> right but once we got some modifications done and rebootet the machine, it
> started acting this strange.
> 
> Regards,
> Andreas
> 
> -----Ursprungliche Nachricht-----
> Von: John Maddalozzo [mailto:john@journyx.com]
> Gesendet: Donnerstag, 14. Oktober 1999 20:05
> An: Stappert, Andreas
> Betreff: Re: AW: AW: Date problem unresolved
> 
> 
> 
> Very strange, Andreas.
> the time.time() result shows the number of seconds since the "epoch"
> (see http://python.org/doc/current/lib/module-time.html)
> Your number of seconds should be somewhere between
> 939916983.851	(the time on my computer when I wrote example note below)
> and
> 939923915.897   (the time on my computer I just now checked)
> 
> What does the command
> date +%s
> say?
> What hardware are you using?
> 
> __________________________________________________________________
> Web-Based Project Management and TimeSheet Software    JournyxTime
> FREE at http://journyx.com/wts.html
> John Maddalozzo  - john@JOURNYX.com  (512)834-8888 / (800)755-9878
> ------------------------------------------------------------------
> 
> On Thu, 14 Oct 1999, Stappert, Andreas wrote:
> 
> > Here you go (my mistake):
> >
> > timesheet:~/jtime/jtime/pi/bin> python
> > Python 1.5.2 (#1, Sep 27 1999, 17:01:09)  [GCC egcs-2.91.66 19990314/Linux
> > (egcs
> > - on linux2
> > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> > >>> import time
> > >>> import wtdate
> > >>> wtdate.today()
> > Thu 13 Jul 1995
> > >>> time.localtime(time.time())
> > (1995, 7, 13, 8, 38, 9, 3, 194, 1)
> > >>> time.time()
> > 805617494.587
> > >>> time.gmtime(time.time())
> > (1995, 7, 13, 6, 38, 54, 3, 194, 0)
> > >>> time.gzname
> > Traceback (innermost last):
> >   File "<stdin>", line 1, in ?
> > AttributeError: gzname
> > >>> time.timezone
> > -3600
> > >>> time.tzname
> > ('CET', 'CEST')
> > >>>
> >
> > -----Ursprungliche Nachricht-----
> > Von: John Maddalozzo [mailto:john@journyx.com]
> > Gesendet: Donnerstag, 14. Oktober 1999 19:09
> > An: Stappert, Andreas
> > Betreff: Re: AW: Date problem unresolved
> >
> >
> >
> > Hi Andreas,
> > Did you remember to source setup?
> > In pi/bin at the shell prompt do:
> > . ./setup
> > You need to do that first. To check that it has been sourced, do
> > echo $PYTHONPATH
> > that should return something like this:
> > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 753>. ./setup
> > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 754>echo $PYTHONPATH
> >
> //home/john_scratch/jtime/jtime/pi/apache/wtlib://home/john_scratch/jtime/jt
> >
> ime/pd/Linux/python/lib/python1.5/://home/john_scratch/jtime/jtime/pi/apache
> > /serverroot/cgi-bin
> >
> > Then it should be able to find wtdate.pyc in pi/apache/wtlib
> >
> > Regards, John
> >
> > On Thu, 14 Oct 1999, Stappert, Andreas wrote:
> >
> > > Hi John,
> > >
> > > I already get stuck when I try to import wtdate:
> > >
> > >  python
> > > Python 1.5.1 (#1, Mar 21 1999, 22:49:36)  [GCC egcs-2.91.66 19990314/Li
> on
> > > linux
> > > -i386
> > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> > > >>> import time
> > > >>> import wtdate
> > > Traceback (innermost last):
> > >   File "<stdin>", line 1, in ?
> > > ImportError: No module named wtdate
> > >
> > > -----Ursprungliche Nachricht-----
> > > Von: John Maddalozzo [mailto:john@journyx.com]
> > > Gesendet: Donnerstag, 14. Oktober 1999 18:05
> > > An: Stappert, Andreas
> > > Cc: support@journyx.com
> > > Betreff: Re: Date problem unresolved
> > >
> > >
> > >
> > > Andreas,
> > > This must be some problem with resolving the time zone.
> > > Please do the following and send me the output.
> > >
> > > What this is doing is invoking python and using its libraries to get
> > dates.
> > > I'm hoping that this will give us some idea of what is wrong.
> > > Regards, John
> > >
> > > cd <jtime install dir>/jtime/pi/bin
> > > . ./setup
> > > python
> > > import time
> > > import wtdate
> > > wtdate.today()
> > > time.localtime(time.time())
> > > time.time()
> > > time.gmtime(time.time())
> > > time.gzname
> > > time.timezone
> > >
> > > For example when I do it here I get...
> > >
> > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 743>python
> > > Python 1.5.2 (#1, Oct  2 1999, 23:28:23)  [GCC egcs-2.91.66
> 19990314/Linux
> > > (egcs- on linux2
> > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> > > >>> import time
> > > >>> import wtdate
> > > >>> wtdate.today()
> > > Thu 14 Oct 1999
> > > >>> time.localtime(time.time())
> > > (1999, 10, 14, 11, 2, 51, 3, 287, 1)
> > > >>> time.time()
> > > 939916983.851
> > > >>> time.gmtime(time.time())
> > > (1999, 10, 14, 16, 7, 10, 3, 287, 0)
> > > >>> time.tzname
> > > ('CST', 'CDT')
> > > >>> time.timezone
> > > 21600
> > >
> > >
> > >
> > > __________________________________________________________________
> > > Web-Based Project Management and TimeSheet Software    JournyxTime
> > > FREE at http://journyx.com/wts.html
> > > John Maddalozzo  - john@JOURNYX.com  (512)834-8888 / (800)755-9878
> > > ------------------------------------------------------------------
> > >
> > > 	On Thu, 14 Oct 1999, Stappert, Andreas wrote:
> > >
> > > > Hello there,
> > > > We are still having a major problem with the Journyx installation on
> our
> > > > Linux server:
> > > > The current date on the Linux machine is
> > > > 	Mit Okt 13 10:35:14 CEST 1999
> > > > but Journyx uses the below July 12, 1995 as current date. Is there any
> > way
> > > > to correct this problem?
> > > > We would like to go and find some more customers for Journyx but if we
> > can
> > > > not figure out how to correct this problem, we will not be able to
> > > > demonstrate it.
> > > > Thanks for your immediate attention
> > > > Andreas
> > > >
> > > > License Key Data
> > > > *	Dates
> > > > *	Install Date: Mon Okt 4 17:36:04 CEST 1999
> > > > *	Product Expiration Date: Never
> > > > *	Current Date: Wed 12 Jul 1995
> > > > *	Users
> > > > *	Licensed Number of Users: 10
> > > > *	Current Number of User Data Unavailable
> > > > *	Hosts
> > > > *	Licensed Host: 192
> > > > *	Current Host: 192
> > > > Operating System Information
> > > > *	Current: Linux 192.168.0.100 2.2.5-15de #1 Tue May 25 00:43:15 EDT
> > > > 1999 i486
> > > > *	Original: Linux karsrv01.key-work.de 2.2.5-15de #1 Tue May 25
> > > > 00:43:15 EDT 1999 i486 unknown
> > > > Credits
> > > > *	Docs: Sarah Griswold
> > > > *	Testing: Matt Neiman
> > > > *	Coding:
> > > > *	Chris Anderson
> > > > *	Curt Finch
> > > > *	John Maddalozzo
> > > > *	Andrew Reutter
> > > > *	Design and enhancement ideas: literally thousands of registered
> > > > users just like you. <http://journyx.com/featureq.html>
> > > >
> > > >
> > > >
> > > > -----------------------------------------------
> > > > Andreas Stappert
> > > > Key-Work Consulting GmbH
> > > >
> > > > Haid-und-Neu-Strasse 7 - 76131 Karlsruhe - Germany
> > > > +49 721 664936-0 - mailto:andreas.stappert@key-work.de
> > > >
> > > >
> > >
> >
> 
> 



====================================================================
Audit trail:
Mon Oct 18 17:53:07 1999	guido	changed notes
Mon Oct 18 17:53:07 1999	guido	changed notification
Mon Oct 18 17:53:08 1999	guido	moved from incoming to open
Tue Oct 19 00:42:35 1999	guido	changed notes
Tue Oct 19 00:42:37 1999	guido	moved from open to irreproducible

Follow-Ups:

Date: 2000-Aug-01 14:37
By: none

Comment:
Can't reproduce this here.
Your best bet is to look into the conversion of the time() value
to floating point -- maybe you are using a bogus floating point
emulation?

BTW, forwarding such a long thread of email without a clear summary of
the problem at the top makes it hard for me to read the bug report.

-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110854&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:04:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:04:44 -0700
Subject: [Python-bugs-list] [Bug #113700] widespread bug in HTML files: lots of italics
Message-ID: <200009072204.PAA29032@bush.i.sourceforge.net>

Bug #113700, was updated on 2000-Sep-06 06:16
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: widespread bug in HTML files: lots of italics

Details: I&#039;d already noticed this in AMK&#039;s and Moshe&#039;s doc about
"what&#039;s new in Python 2".  There&#039;s some bug in the
converter-to-HTML that, occasionally, for a big closed
bracket, outputs a </var> in front and a <var> in back
rather than vice-versa; so all the rest of the HTML is
italicized.  E.g., it shows up in built-in-funcs.html
in the description of int (x[, radix])  [possibly
later too, haven&#039;t checked].

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113700&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:04:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:04:45 -0700
Subject: [Python-bugs-list] [Bug #113785] SIGSEGV in PyDict_SetItem
Message-ID: <200009072204.PAA29035@bush.i.sourceforge.net>

Bug #113785, was updated on 2000-Sep-07 01:51
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 5
Summary: SIGSEGV in PyDict_SetItem

Details: On a PC running FreeBSD 3.5
Python 1.5.2 (#1, Aug 23 2000, 10:14:09)  [GCC 2.95 19990728 (release)] on freebsd3
 I installed Python to run a filter that comes with inn 2.3.0 (usenet News)

Some time the fiter written in Python hangs with the following (from gdb)
Program received signal SIGSEGV, Segmentation fault.
0x810465b in PyDict_SetItem (op=0x83c6a80, key=0x83d4020, value=0x0)
    at dictobject.c:375
375             Py_INCREF(value);

I suspect that the Python filter may be 
#
# $Id: filter_innd.py,v 1.2 1999/09/23 14:24:23 kondou Exp $
#
# This is a sample filter for the Python innd hook.
#
# For details, see the file README.python_hook that came with INN.
#

import re
from string import *

# This looks weird, but creating and interning these strings should
# let us get faster access to header keys (which innd also interns) by
# losing some strcmps under the covers.
Approved = intern("Approved");           Control = intern("Control")
Date = intern("Date");                   Distribution = intern("Distribution")
Expires = intern("Expires");             From = intern("From")
Lines = intern("Lines");                 Message_ID = intern("Message-ID")
Newsgroups = intern("Newsgroups");       Path = intern("Path")
Reply_To = intern("Reply-To");           Sender = intern("Sender")
Subject = intern("Subject");             Supersedes = intern("Supersedes")
Bytes = intern("Bytes");                 Also_Control = intern("Also-Control")
References = intern("References");       Xref = intern("Xref")
Keywords = intern("Keywords");           X_Trace = intern("X-Trace")
NNTP_Posting_Host = intern("NNTP-Posting-Host")
Followup_To = intern("Followup-To");     Organization = intern("Organization")
Content_Type = intern("Content-Type");   Content_Base = intern("Content-Base")
Content_Disposition = intern("Content-Disposition")
X_Newsreader = intern("X-Newsreader");   X_Mailer = intern("X-Mailer")
X_Newsposter = intern("X-Newsposter")
X_Cancelled_By = intern("X-Cancelled-By")
X_Canceled_By = intern("X-Canceled-By"); Cancel_Key = intern("Cancel-Key")
__BODY__ = intern("__BODY__");           __LINES__ = intern("__LINES__")


class InndFilter:
    """Provide filtering callbacks to innd."""

    def __init__(self):
        """This runs every time the filter is loaded or reloaded.

        This is a good place to initialize variables and precompile
        regular expressions, or maybe reload stats from disk.
        """
        self.re_newrmgroup = re.compile('(?:new|rm)group\s')
        self.re_obsctl = re.compile('(?:sendsys|version|uuname)')
        # msgid  pattern from a once-common spambot.
        self.re_none44 = re.compile('none\d+\.yet>')
        # There is a mad newgrouper who likes to meow.
        self.re_meow = re.compile("^Meow\!", re.M)
        # One of my silly addresses.
        self.re_fluffymorph = re.compile("andruQ@myremarQ.coM", re.I)

    def filter_before_reload(self):
        """Runs just before the filter gets reloaded.

        You can use this method to save state information to be
        restored by the __init__() method or down in the main module.
        """
        syslog('notice', "filter_before_reload executing...")

    def filter_close(self):
        """Runs when innd exits.

        You can use this method to save state information to be
        restored by the __init__() method or down in the main module.
        """
        syslog('notice', "filter_close running, bye!")

    def filter_messageid(self, msgid):
        """Filter articles just by their message IDs.

        This method interacts with the IHAVE and CHECK NNTP commands.
        If you return a non-empty string here, the offered article
        will be refused before you ever have to waste any bandwidth
        looking at it.  This is not foolproof, so you should do your
        ID checks both here and in filter_art.  (TAKETHIS does not
        offer the ID for examination, and a TAKETHIS isn't always
        preceded by a CHECK.)
        """
        return ""               # deactivate the samples.
        
        if self.re_none44.search(msgid):
            return "But I don't like spam!"
        if msgid[0:8] == '<cancel.':
            return "I don't do cybercancels."

    def filter_art(self, art):
        """Decide whether to keep offered articles.

        art is a dictionary with a bunch of headers, the article's
        body, and innd's reckoning of the line count.  Itens not
        in the article will have a value of None.

        The available headers are the ones listed near the top of
        innd/art.c.  At this writing, they are:

            Approved, Control, Date, Distribution, Expires, From,
            Lines, Message-ID, Newsgroups, Path, Reply-To, Sender,
            Subject, Supersedes, Bytes, Also-Control, References,
            Xref, Keywords, X-Trace, NNTP-Posting-Host, Folowup-To,
            Organization, Content-Type, Content-Base,
            Content-Disposition, X-Newsreader, X-Mailer, X-Newsposter,
            X-Cancelled-By, X-Canceled-By and Cancel-Key.

        The body is the buffer in art['__BODY__'] and the INN-reckoned
        line count is held as an integer in art['__LINES__'].  (The
        Lines: header is often generated by the poster, and large
        differences can be a good indication of a corrupt article.)

        If you want to keep an article, return None or "".  If you
        want to reject, return a non-empty string.  The rejection
        string will appear in transfer and posting response banners,
        and local posters will see them if their messages are
        rejected.
        """
        return ""               # deactivate the samples.

        # catch bad IDs from articles fed with TAKETHIS but no CHECK.
        idcheck = self.filter_messageid(art[Message_ID])
        if idcheck:
            return idcheck

        # There are some control messages we don't want to process or
        # forward to other sites.
        try:
            if art[Control] is not None:
                if self.re_newrmgroup.match(art[Control]):
                    if self.re_meow.search(art[__BODY__]):
                        return "The fake tale meows again."
                    if art[Distribution] == buffer('mxyzptlk'):
                        return "Evil control message from the 10th dimension"
                if self.re_obsctl.match(art[Control]):
                    return "Obsolete control message"

            # If you don't know, you don't want to know.
            if self.re_fluffymorph.search(art[From]):
                return "No, you may NOT meow."
        except:
            syslog('n', str(sys.exc_info[1]))

    def filter_mode(self, oldmode, newmode, reason):
        """Capture server events and do something useful.

        When the admin throttles or pauses innd (and lets it go
        again), this method will be called.  oldmode is the state we
        just left, and newmode is where we are going.  reason is
        usually just a comment string.

        The possible values of newmode and oldmode are the four
        strings 'running', 'paused', 'throttled' and 'unknown'.
        Actually 'unknown' shouldn't happen, it's there in case
        feeping creatures invade innd.
        """
        syslog('notice', 'state change from %s to %s - %s'
               % (oldmode, newmode, reason))



"""
Okay, that's the end of our class definition.  What follows is the
stuff you need to do to get it all working inside innd.
"""

# This import must succeed, or your filter won't work.  I'll repeat
# that: You MUST import INN.
from INN import *


#   Some of the stuff below is gratuitous, just demonstrating how the
#   INN.syslog call works.  That first thingy tells the Unix syslogger
#   what severity to use; you can abbreviate down to one letter and
#   it's case insensitive.  Available levels are (in increasing levels
#   of seriousness) Debug, Info, Notice, Warning, Err, Crit, and
#   Alert.  If you provide any other string, it will be defaulted to
#   Notice.  You'll find the entries in the same log files innd itself
#   uses, with an 'innd: python:' prefix.
#
#   The native Python syslog module seems to clash with INN, so use
#   INN's.  Oh yeah -- you may notice that stdout and stderr have been
#   redirected to /dev/null -- if you want to print stuff, open your
#   own files.

try:
    import sys
except Exception, errmsg:
    syslog('Error', "import boo-boo: " + errmsg[0])


#     If you want to do something special when the server first starts
#     up, this is how to find out when it's time.

if 'spamfilter' not in dir():
    syslog ('n', "First load, so I can do initialization stuff.")
    #  You could unpickle a saved hash here, so that your hard-earned
    #  spam scores aren't lost whenver you shut down innd.
else:
    syslog ('NoTicE', "I'm just reloading, so skip the formalities.")


#  Finally, here is how we get our class on speaking terms with innd.
#  The hook is refreshed on every reload, so that you can change the
#  methods on a running server.  Don't forget to test your changes
#  before reloading!
spamfilter = InndFilter()
try:
    set_filter_hook(spamfilter)
    syslog('n', "spamfilter successfully hooked into INN")
except Exception, errmsg:
    syslog('e', "Cannot obtain INN hook for spamfilter: %s" % errmsg[0])



And the data would be something like:
        takethis <967664873.12710.1.nnrp-02.9e98fa8b@news.demon.co.uk>\r
        Path: news.nectec.or.th!news.loxinfo.co.th!news-out.cwix.com!newsfeed.\
        cwix.com!newsfeeds.belnet.be!news.belnet.be!newsgate.cistron.nl!bullse\
        ye.news.demon.net!demon!news.demon.co.uk!demon!inert.demon.co.uk!not-f\
        or-mail\r
        From: inert@inert.demon.co.uk\r
        Newsgroups: rec.music.industrial\r
        Subject: *** CLUB NOIR ***  31/8/00\r
        Date: Wed, 30 Aug 2000 19:47:53 GMT\r
        Organization: inertia\r
        Message-ID: <967664873.12710.1.nnrp-02.9e98fa8b@news.demon.co.uk>\r
        NNTP-Posting-Host: inert.demon.co.uk\r
        X-NNTP-Posting-Host: inert.demon.co.uk:158.152.250.139\r
        X-Trace: news.demon.co.uk 967664873 nnrp-02:12710 NO-IDENT inert.demon\
        .co.uk:158.152.250.139\r
        X-Complaints-To: abuse@demon.net\r
        X-Mailer: Mozilla 1.22 (Windows; I; 16bit)\r
        MIME-Version: 1.0\r
        Lines: 0\r
        Xref: news.nectec.or.th rec.music.industrial:137401\r
        \r
        .\r

So, for an easy solution, I can disable Python filtering and then inn will be working fine.
But even if the filter was not doing what it is supposed to do, Python should not SIGSEGV I presume.

Beside Python installed without problem and make test result is:
42 tests OK.
19 tests skipped: test_al test_audioop test_bsddb test_cd test_cl test_crypt test_dbm test_dl test_gdbm test_gl test_gzip test_imageop test_imgfile test_nis test_rgbimg test_sunaudiodev test_thread test_timing test_zlib

For more info: on@cs.ait.ac.th

Thank you,

Olivier

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113785&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:04:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:04:12 -0700
Subject: [Python-bugs-list] [Bug #110619] urllib.py fails with username/password proxies (PR#221)
Message-ID: <200009072204.PAA28889@bush.i.sourceforge.net>

Bug #110619, was updated on 2000-Jul-31 14:06
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 4
Summary: urllib.py fails with username/password proxies (PR#221)

Details: Jitterbug-Id: 221
Submitted-By: tarka@zip.com.au
Date: Tue, 29 Feb 2000 19:15:45 -0500 (EST)
Version: 1.5.2
OS: Irix


urllib.py fails to handle proxies with user and password information 
included in the proxy URL, e.g. http://ssmith:testpass@10.11.12.13:1234

The following example ...

	import os, urllib
	os.environ['http_proxy'] = "http://ssmith:testpass01@10.11.12.13:1234"
	f = urllib.urlopen('http://www.python.org')
	data = f.read()
	print data

fails with the following errors :

Traceback (innermost last):
  File "url.py", line 3, in ?
    f = urllib.urlopen('http://www.python.org')
  File "/var/share//lib/python1.5/urllib.py", line 59, in urlopen
    return _urlopener.open(url)
  File "/var/share//lib/python1.5/urllib.py", line 157, in open
    return getattr(self, name)(url)
  File "/var/share//lib/python1.5/urllib.py", line 253, in open_http
    h = httplib.HTTP(host)
  File "/var/share//lib/python1.5/httplib.py", line 51, in __init__
    if host: self.connect(host, port)
  File "/var/share//lib/python1.5/httplib.py", line 75, in connect
    raise socket.error, "nonnumeric port"
IOError: [Errno socket error] nonnumeric port






====================================================================
Audit trail:
Mon May 22 17:35:04 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-31 10:15
By: fdrake

Comment:
Will be documented as a limitation in the implementation, as suggested in bug #111725.  I'm converting this to a feature request that can be dealt with in a subsequent version of Python.
-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110619&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:04:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:04:14 -0700
Subject: [Python-bugs-list] [Bug #110666] PRIVATE: interned-&gt;ma_table never free'd (PR#361)
Message-ID: <200009072204.PAA28897@bush.i.sourceforge.net>

Bug #110666, was updated on 2000-Jul-31 14:12
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: PRIVATE: interned-&gt;ma_table never free'd (PR#361)

Details: Jitterbug-Id: 361
Submitted-By: cfandrich@8cs.com
Date: Fri, 16 Jun 2000 20:08:33 -0400 (EDT)
Version: 1.5.2
OS: Windows


I'm embedding Python in an application.  For now, all I'm doing is initializing
and finalizing Python.

When I run my app I get a memory leak of 12288 bytes.  The memory is malloc'ed
by dictresize() which is called by PyDict_SetItem() which is called by
PyString_InternInPlace().

For now, I've added 
    PyDict_Clear(interned);
    interned = NULL;
to PyString_Fini().  So far it works fine, but I don't know if it's safe to do
in the grand scheme of things.

-Chris




====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "M.-A. Lemburg" <mal@lemburg.com>
Subject: Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361)
Date: Sat, 17 Jun 2000 10:53:20 +0200

cfandrich@8cs.com wrote:
> 
> Full_Name: Christopher Fandrich
> Version: 1.5.2
> OS: Windows
> Submission from: (NULL) (208.41.174.4)
> 
> I'm embedding Python in an application.  For now, all I'm doing is initializing
> and finalizing Python.
> 
> When I run my app I get a memory leak of 12288 bytes.  The memory is malloc'ed
> by dictresize() which is called by PyDict_SetItem() which is called by
> PyString_InternInPlace().
> 
> For now, I've added
>     PyDict_Clear(interned);
>     interned = NULL;
> to PyString_Fini().  So far it works fine, but I don't know if it's safe to do
> in the grand scheme of things.

I would suggest adding code to dealloc the interned dict
iff it is empty after the sweeping action in PyString_Fini().
I have a feeling that this is not the case though, since interned
strings are used quite a lot in the core interpreter (e.g. in
classobject.c) and these are usually not recovered.

Perhaps we ought to add some code which takes care of cleaning
up all remaining garbage left over after the call to
call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing
of all interned strings and cached ints/floats and associated
free lists or dicts.

We'd need new APIs in string|float|intobject.c to implement this.

Thoughts ? Patches ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110666&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:04:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:04:30 -0700
Subject: [Python-bugs-list] [Bug #110831] readline on QNX (PR#192)
Message-ID: <200009072204.PAA28917@bush.i.sourceforge.net>

Bug #110831, was updated on 2000-Aug-01 14:12
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: readline on QNX (PR#192)

Details: Jitterbug-Id: 192
Submitted-By: davidv@elisra.com
Date: Thu, 27 Jan 2000 13:31:16 -0500 (EST)
Version: 1.52
OS: Qnx


This is not a bug.
I have compiled Python 1.52 with Watcom on QNX. The Linux readline doesn't
work good with QNX. This  simple patch for /Parser/myreadline.c
replaces readline with QNX input_line function.

------------------------------------------------------------
60,68d59
<
< #ifdef __QNX__
<   p = input_line( fp, buf, len );
<   if( p ) {
<    int n = strlen(p);
<    p[n] = '\n';
<    p[n+1] = 0;
<   }
< #else
70d60
< #endif
-------------------------------------------------------------


====================================================================
Audit trail:
Mon Feb 07 12:34:32 2000	guido	sent reply 1
Mon Feb 07 12:34:49 2000	guido	changed notes
Mon Feb 07 12:34:49 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:13
By: none

Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: readline on QNX (PR#192)
Date: Mon Feb  7 12:34:32 2000

> This is not a bug.
> I have compiled Python 1.52 with Watcom on QNX. The Linux readline doesn't
> work good with QNX. This  simple patch for /Parser/myreadline.c
> replaces readline with QNX input_line function.
> 
> ------------------------------------------------------------
> 60,68d59
> <
> < #ifdef __QNX__
> <   p = input_line( fp, buf, len );
> <   if( p ) {
> <    int n = strlen(p);
> <    p[n] = '\n';
> <    p[n+1] = 0;
> <   }
> < #else
> 70d60
> < #endif
> -------------------------------------------------------------

David, please see www.python.org/patches for instructions on how to send
patches.  The Bugs List is not the right place, sorry!

--Guido van Rossum

-------------------------------------------------------

Date: 2000-Aug-01 14:13
By: none

Comment:
Should go to patches@python.org.

-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110831&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:04:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:04:31 -0700
Subject: [Python-bugs-list] [Bug #110842] dl.RTLD_GLOBAL missing (PR#313)
Message-ID: <200009072204.PAA28921@bush.i.sourceforge.net>

Bug #110842, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: dl.RTLD_GLOBAL missing (PR#313)

Details: Jitterbug-Id: 313
Submitted-By: loewis@informatik.hu-berlin.de
Date: Thu,  4 May 2000 09:54:13 -0400 (EDT)
Version: 1.5.2
OS: Solaris


The dl module does not support all flags to dlopen available on a specific
system; eg. dl.open("foo.so",dl.RTLD_GLOBAL) does not work.

On Solaris, the following constants are defined, in addition
RTLD_NOLOAD
RTLD_GLOBAL
RTLD_LOCAL
RTLD_PARENT
RTLD_GROUP
RTLD_WORLD
RTLD_NODELETE





====================================================================
Audit trail:
Mon May 22 17:25:17 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110842&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:04:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:04:27 -0700
Subject: [Python-bugs-list] [Bug #110703] select with dec-threads core dumps (PR#35)
Message-ID: <200009072204.PAA28909@bush.i.sourceforge.net>

Bug #110703, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: select with dec-threads core dumps (PR#35)

Details: Jitterbug-Id: 35
Submitted-By: ddula@alfomc.net
Date: Thu, 22 Jul 1999 17:01:04 -0400 (EDT)
Version: 1.5.2
OS: Digital Unix (OSF/1) 4.0E with latest patches


Select cores while waiting on a socket

spoo.alfomc.net> dbx  /usr/local/ddula/tar/Python-1.5.2/python core

dbx version 3.11.10
Type 'help' for help.
Core file created by program "python"
thread 0xb signal Segmentation fault at >*[nxm_thread_kill, 0x3ff805ab3b8]
retr31, (r26), 1
(dbx) t
>  0 nxm_thread_kill(0x14003bb40, 0x3ff807e31c8, 0x3ffc0085c98, 0x3ff805ab0a8,
0x14003bb40) [0x3ff805ab3b8]
   1 pthread_kill(0x1, 0x0, 0x0, 0x1400df980, 0x3ff00000000) [0x3ff80598b94]
   2 (unknown)() [0x3ff8058cb38]
   3 (unknown)() [0x3ff807e35ec]
   4 exc_unwind(0x1400dde78, 0x1400dc5a0, 0xabadabad00beed00, 0x0,
0x3ff807e3964) [0x3ff807e36d4]
   5 exc_raise_signal_exception(0x86, 0x0, 0x1200735b8, 0x1, 0x2)
[0x3ff807e3960]
   6 (unknown)() [0x3ff8059a248]
   7 select_select(args = (nil)) ["./selectmodule.c":221, 0x1200735b4]
   8 eval_code2(co = [bad address (0x14010d838)], globals = 0xfc50, locals =
(nil), args = [bad address (0x14010d840)], kws = [bad address (0x14010d848)],
kwcount = [bad address (0x14010d9a8)], defs = [bad address (0x14010d9b0)],
defcount = [bad address (0x14010d9b8)]) ["ceval.c":1654, 0x12003e57c]

Appears eval_code2 is getting passed bad addresses?

My code snipped 

<--SNIP-->
class TelnetProxy(SocketServer.StreamRequestHandler,SocketServer.BaseRequestHand
ler):
        def handle(self):
                o = socket(AF_INET,SOCK_STREAM)
                o.connect(OHOST,OPORT)
                while 1:
                        print o.fileno()
                        print self.rfile.fileno()
                        r,w,e = select.select([o,self.rfile],[],[],1) <---CORE
HERE
                        if o in r:

<--SNIP-->

Same problem under 1.5.1 as well.

The 1.5.2 is the latest source I downloaded Jul 20

This same code works fine on NT and LINUX I believe.

Dave Dula
ddula@alfomc.net


====================================================================
Audit trail:
Sat Jul 24 16:52:19 1999	guido	changed notes
Sat Jul 24 16:52:19 1999	guido	moved from incoming to open
Sat Jul 24 17:05:25 1999	guido	moved from open to platformbug

Follow-Ups:

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] select with dec-threads core dumps (PR#35)
Date: Thu, 22 Jul 1999 17:46:26 -0400

I seriously suspect that this is a bug in your C library, not in
Python.  Select is rock-solid on other platforms.  Do you feel
confident enough to try debugging this some more?  Otherwise, you have
no choice but to post a question to the newsgrup, maybe someone has
seen this before or is willing to help debugging it.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
From: David Dula <ddula@alfomc.net>
Subject: Re: [Python-bugs-list] select with dec-threads core dumps (PR#35)
Date: Thu, 22 Jul 1999 18:43:48 -0400

Guido van Rossum wrote:

> I seriously suspect that this is a bug in your C library, not in
> Python.  Select is rock-solid on other platforms.  Do you feel
> confident enough to try debugging this some more?  Otherwise, you have
> no choice but to post a question to the newsgrup, maybe someone has
> seen this before or is willing to help debugging it.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)

Well a little more debugging shows that this is certainly a threading
+ select problem
because a forking method works.  The forks will serve my purposes so I
have a work around.

Thanks
Dave Dula


-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
Digital Unix problem when combining threads with select?
-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110703&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:04:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:04:36 -0700
Subject: [Python-bugs-list] [Bug #110860] IDLE class browser and decimal comma don't agree (PR#298)
Message-ID: <200009072204.PAA29019@bush.i.sourceforge.net>

Bug #110860, was updated on 2000-Aug-01 14:38
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Irreproducible
Priority: 5
Summary: IDLE class browser and decimal comma don't agree (PR#298)

Details: Jitterbug-Id: 298
Submitted-By: magnus@thinkware.se
Date: Tue, 18 Apr 2000 08:37:02 -0400 (EDT)
Version: 1.5.2
OS: NT 4


As soon as I open the class browser in IDLE (0.5) I get the traceback
below. Previously I had another strange bug that I suspect has to do
with Tcl/Tk and the fact that I have national settings with , (comma)
as decimal separator. With IDLE 0.4, >>> 5 / float(2) would result in
2,5 (not 2.5). It also wanted me to enter data like that. >>> 2.5 * 2
was rejected, and obviously >>> 2,5 * 2 was interpreted as (2, 5) * 2.
This was only a problem in the IDLE shell. Program files ran OK.

Considering "ValueError: invalid literal for float(): 0.0" below I
suspect the errors are related. (A hint is that the problem goes away
if I change the regional settings to decimal . in the control panel.)

>>> Exception in Tkinter callback
Traceback (innermost last):
  File "C:\Program\Python\Lib\lib-tk\Tkinter.py", line 764, in __call__
    return apply(self.func, args)
  File "C:\Program\Python\Tools\idle\EditorWindow.py", line 355, in
open_class_browser
    ClassBrowser.ClassBrowser(self.flist, base, [head])
  File "C:\Program\Python\Tools\idle\ClassBrowser.py", line 37, in __init__
    self.init(flist)
  File "C:\Program\Python\Tools\idle\ClassBrowser.py", line 59, in init
    node.expand()
  File "C:\Program\Python\Tools\idle\TreeWidget.py", line 133, in expand
    self.view()
  File "C:\Program\Python\Tools\idle\TreeWidget.py", line 144, in view
    visible_top = self.canvas.canvasy(0)
  File "C:\Program\Python\Lib\lib-tk\Tkinter.py", line 1200, in canvasy
    return getdouble(self.tk.call(
ValueError: invalid literal for float(): 0.0




====================================================================
Audit trail:
Mon May 22 17:17:16 2000	guido	changed notes
Mon May 22 17:17:16 2000	guido	moved from incoming to irreproducible

Follow-Ups:

Date: 2000-Aug-01 14:39
By: none

Comment:
Bizarrely, his locale affects Python number parsing.
Can't reproduce this.
-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110860&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:04:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:04:40 -0700
Subject: [Python-bugs-list] [Bug #112786] Build under Cygwin fails
Message-ID: <200009072204.PAA29028@bush.i.sourceforge.net>

Bug #112786, was updated on 2000-Aug-26 01:39
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Build under Cygwin fails

Details: Py1.6b1
========
1) socketmodule.c -- looks for netinet/tcp.h, which does not exist on cygwin.

2) gcc   python.o \
          ../libpython1.6.a    -lm  -o python
python.o: In function `main':
/usr/local/bin/Python-1.6b1/Modules/python.c:12: undefined reference to `Py_Main


Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112786&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:04:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:04:46 -0700
Subject: [Python-bugs-list] [Bug #113803] [2.0b1 NT4.0] printing non asci char causes idle to abort
Message-ID: <200009072204.PAA29039@bush.i.sourceforge.net>

Bug #113803, was updated on 2000-Sep-07 08:33
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: [2.0b1 NT4.0] printing non asci char causes idle to abort

Details: try:

alef = u'\u05d0'
print alef.encode('utf-8')

any enter after the last statement will cause idle to abort

on 'bare' python this does not cause any problem.

[tebeka@lycosmail.com]

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113803&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:05:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:05:10 -0700
Subject: [Python-bugs-list] [Bug #110618] IDLE: Modifying argv prevents source of ~/.idle.py (PR#219)
Message-ID: <200009072205.PAA29058@bush.i.sourceforge.net>

Bug #110618, was updated on 2000-Jul-31 14:06
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: IDLE: Modifying argv prevents source of ~/.idle.py (PR#219)

Details: Jitterbug-Id: 219
Submitted-By: aa8vb@yahoo.com
Date: Mon, 28 Feb 2000 07:49:55 -0500 (EST)
Version: 1.5.2
OS: IRIX 6.5.6f


(Two problems leading up to allowing IDLE to read color settings from
~/.idle.py.
They're separate problems so I'll put each in separate bug reports.)

As Bernhard Herzog recently pointed out, Tkinter apps try to load
.<classname>.tcl, .<classname>.py, .<appname>.tcl and .<appname>.py out of a
user's home directory, if present.  <classname> defaults to "Tk" and <appname>
defaults to the base of argv[0] (e.g. "idle").

With these reasonable defaults, one would expect they could create a ~/.idle.py
which IDLE would read for configuration info.  However, Tkinter "won't" try
to read ~/.idle.py unless -e is specified.  This is because IDLE is
hacking up sys.argv for some reason when -e isn't specified, which results in
sys.argv[0] being empty, which prevents baseName from being set, which 
in turn causes Tkinter to look for these files:

   ~/.Tk.tcl ~/.Tk.py ~/..tcl ~/..py

instead of:

   ~/.Tk.tcl ~/.Tk.py ~/.idle.tcl ~/.idle.py

Seeing this, I verified that IDLE does indeed read ~/.idle.py when invoked
as "idle.py -e".

This appears to be a bug.  If so, please update IDLE so that argv[0] is
left unadulterated at least until Tkinter is initialized, so that it can
read ~/.<basename>.py for configuration.

Also, it might be worthwhile to set the className (argument to Tk()) to
"Idle" or "IDLE" so an IDLE configuration file can be created which will 
be executed independent of what the idle script itself is named.




====================================================================
Audit trail:
Tue Mar 07 14:38:27 2000	guido	changed notes
Tue Mar 07 14:38:27 2000	guido	changed notification
Tue Mar 07 14:38:27 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110618&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:05:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:05:29 -0700
Subject: [Python-bugs-list] [Bug #110859] Environment dependency in re parser (PR#290)
Message-ID: <200009072205.PAA29099@bush.i.sourceforge.net>

Bug #110859, was updated on 2000-Aug-01 14:38
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Not a Bug
Priority: 3
Summary: Environment dependency in re parser (PR#290)

Details: Jitterbug-Id: 290
Submitted-By: nmm1@cam.ac.uk
Date: Wed, 12 Apr 2000 07:44:54 -0400 (EDT)
Version: 1.5.2
OS: Irix 6.5


The following code works perfectly when used interactively:

from re import match

if match(r'"([^\"]|\?""|\\?)*"','"abc"') :
    print "Hello"

When run non-interactively (e.g. 'python junk.py'), it fails:

  File "junk.py", line 3, in ?
    if match(r'"([^\"]|\?""|\\?)*"','"abc"') :
  File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 40, in match
    return _cachecompile(pattern, flags).match(string)
  File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 33, in _cachecompile
    value = compile(pattern, flags)
  File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 79, in compile
    code=pcre_compile(pattern, flags, groupindex)
pcre.error: ('operand of unlimited repeat could match the empty string', 17)




====================================================================
Audit trail:
Tue Jul 11 08:29:16 2000	guido	moved from incoming to open
Thu Jul 13 20:37:02 2000	fdrake	changed notes
Thu Jul 13 20:37:02 2000	fdrake	moved from open to irreproducible

Follow-Ups:

Date: 2000-Aug-01 14:38
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] Environment dependency in re parser (PR#290)
Date: Wed, 12 Apr 2000 22:30:46 -0400

> Full_Name: Nick Maclaren
> Version: 1.5.2
> OS: Irix 6.5
> Submission from: posh.mcc.wwwcache.ja.net (194.83.240.29)
>
>
> The following code works perfectly when used interactively:
>
> from re import match
>
> if match(r'"([^\"]|\?""|\\?)*"','"abc"') :
>     print "Hello"
>
> When run non-interactively (e.g. 'python junk.py'), it fails:
>
>   File "junk.py", line 3, in ?
>     if match(r'"([^\"]|\?""|\\?)*"','"abc"') :
>   File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 40, in match
>     return _cachecompile(pattern, flags).match(string)
>   File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 33, in
> _cachecompile
>     value = compile(pattern, flags)
>   File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 79, in compile
>     code=pcre_compile(pattern, flags, groupindex)
> pcre.error: ('operand of unlimited repeat could match the empty
> string', 17)

It yields the same error for me whether run interactively or from file,
under the released 1.5.2 for Windows, here run from a DOS box:

D:\Python>python
Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from re import match
>>> if match(r'"([^\"]|\?""|\\?)*"','"abc"') :
...    print "Hello"
...
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "D:\Python\Lib\re.py", line 40, in match
    return _cachecompile(pattern, flags).match(string)
  File "D:\Python\Lib\re.py", line 33, in _cachecompile
    value = compile(pattern, flags)
  File "D:\Python\Lib\re.py", line 79, in compile
    code=pcre_compile(pattern, flags, groupindex)
pcre.error: ('operand of unlimited repeat could match the empty string', 17)
>>>

The error msg is appropriate, since the third branch of the alternative
matches 0 or 1 backslashes, so the alternative as a whole can match the
empty string -- the error msg means exactly what it says.  This is
functioning correctly as designed.

Perhaps you're using an interactive shell with a filter (readline?) that's
chewing up some of the backslashes itself?




-------------------------------------------------------

Date: 2000-Aug-01 14:38
By: none

Comment:
Something from outside of Python appears to causing this.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110859&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:05:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:05:37 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200009072205.PAA29114@bush.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:06:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:06:37 -0700
Subject: [Python-bugs-list] [Bug #110826] WebBugRptBroken &amp; &quot;Python mymalloc.h; not C++ compatible&quot; (PR#136)
Message-ID: <200009072206.PAA29152@bush.i.sourceforge.net>

Bug #110826, was updated on 2000-Aug-01 14:11
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: WebBugRptBroken &amp; &quot;Python mymalloc.h; not C++ compatible&quot; (PR#136)

Details: Jitterbug-Id: 136
Submitted-By: Randall Hopper <aa8vb@yahoo.com>
Date: Wed, 24 Nov 1999 09:51:10 -0500
Version: None
OS: None

Just tried to submit this via the web interface which has worked in the
past.  This time, I got:

    The system encountered a fatal error

    After command: 
    Received: 

    The last error code was: Connection refused 

This was a non-private bug report, as usual.

Anyway, here's the bug report:

==============================================================================

aa8vb@yahoo.com
Python mymalloc.h; not C++ compatible
Randall Hopper
1.5.2
IRIX 6.5
Private: NO

I hit a problem trying to compile wxPython on IRIX 6.5.  The issue is NULL
should be "0" when compiling for C++.  The IRIX headers define it this way.
The Python mymalloc.h header doesn't.  A work-around is to require clients
to include stdio.h before including any Python header files, but this is a
hack.

Here's a snip from a recent Python post I made with a proposed fix:

------------------------------------------------------------------------------

...After a bit of grepping, the culprit seems to be Python (1.5.2):

     /usr/local/include/python1.5/mymalloc.h:

         #ifndef NULL
         #define NULL ((ANY *)0)
         #endif

...

It appears to me that the right fix is for Python's mymalloc.h, if it must
define NULL (does it?), be updated to be more C++ friendly.  E.g.:

         #ifndef NULL
         #  ifdef __cplusplus
         #    define NULL 0
         #  else
         #    define NULL ((ANY *)0)
         #  endif
         #endif

I'm assuming there's some reason we can't just #include <stdio.h> from 
mymalloc.h (?)

------------------------------------------------------------------------------

Thanks,

Randall


====================================================================
Audit trail:
Fri Dec 03 10:32:05 1999	guido	sent reply 1
Fri Dec 03 10:32:19 1999	guido	changed notes
Fri Dec 03 10:32:20 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:11
By: none

Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible" (PR#136)
Date: Fri Dec  3 10:32:05 1999

> I hit a problem trying to compile wxPython on IRIX 6.5.  The issue is NULL
> should be "0" when compiling for C++.  The IRIX headers define it this way.
> The Python mymalloc.h header doesn't.  A work-around is to require clients
> to include stdio.h before including any Python header files, but this is a
> hack.

Why is wxPython using mymalloc.h directly?  It should use Python.h,
which *does* include stdio.h first.

-------------------------------------------------------

Date: 2000-Aug-01 14:11
By: none

Comment:
From: "Robin Dunn" <robin@alldunn.com>
Subject: Re: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible" (PR#136)
Date: Wed, 8 Dec 1999 12:03:08 -0800

> ----- Forwarded message from Guido van Rossum <bugs-py@python.org> -----
>
> Date: Fri, 3 Dec 1999 10:32:03 -0500 (EST)
> From: Guido van Rossum <bugs-py@python.org>
> Subject: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible"
(PR#136)
>
> > I hit a problem trying to compile wxPython on IRIX 6.5.  The issue is
NULL
> > should be "0" when compiling for C++.  The IRIX headers define it this
way.
> > The Python mymalloc.h header doesn't.  A work-around is to require
clients
> > to include stdio.h before including any Python header files, but this is
a
> > hack.
>
> Why is wxPython using mymalloc.h directly?  It should use Python.h,
> which *does* include stdio.h first.
>
>
> ----- End forwarded message -----
>

wxPython does use Python.h and if I remember correctly, moving it to be the
first #include (to ensure that none of the wx or my headers were screwing
things up) didn't help Randall at all.  He had to put an #include <stdio.h>
before it.

--
Robin Dunn
Software Craftsman
robin@AllDunn.com
http://AllDunn.com/robin/
http://AllDunn.com/wxPython/  Check it out!



-------------------------------------------------------

Date: 2000-Aug-01 14:11
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Re: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible" (PR#136)
Date: Wed, 08 Dec 1999 17:04:30 -0500

> > ----- Forwarded message from Guido van Rossum <bugs-py@python.org> -----
> >
> > Date: Fri, 3 Dec 1999 10:32:03 -0500 (EST)
> > From: Guido van Rossum <bugs-py@python.org>
> > Subject: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible"
> (PR#136)
> >
> > > I hit a problem trying to compile wxPython on IRIX 6.5.  The issue is
> NULL
> > > should be "0" when compiling for C++.  The IRIX headers define it this
> way.
> > > The Python mymalloc.h header doesn't.  A work-around is to require
> clients
> > > to include stdio.h before including any Python header files, but this is
> a
> > > hack.
> >
> > Why is wxPython using mymalloc.h directly?  It should use Python.h,
> > which *does* include stdio.h first.
> >
> >
> > ----- End forwarded message -----
> >
> 
> wxPython does use Python.h and if I remember correctly, moving it to be the
> first #include (to ensure that none of the wx or my headers were screwing
> things up) didn't help Randall at all.  He had to put an #include <stdio.h>
> before it.

Strange.  I don't have your source so there's no point arguing about
it here.  Python.h definitely includes <stdio.h> before including
"mymalloc.h".  At least in 1.5(.x), I haven't checked older versions.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:11
By: none

Comment:
Maybe, maybe not.

-------------------------------------------------------

Date: 2000-Aug-06 10:33
By: twouters

Comment:
Looks like a "won't fix" to me, unless there is a good reason not to include Python.h. If you start including other python header files, you better know damn well what you're doing, and include the necessary files beforehand, yourself. But that's just me.
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110826&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:06:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:06:22 -0700
Subject: [Python-bugs-list] [Bug #110617] IDLE and -t (PR#213)
Message-ID: <200009072206.PAA29123@bush.i.sourceforge.net>

Bug #110617, was updated on 2000-Jul-31 14:06
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: IDLE and -t (PR#213)

Details: Jitterbug-Id: 213
Submitted-By: aa8vb@yahoo.com
Date: Fri, 25 Feb 2000 07:36:01 -0500 (EST)
Version: 1.5.2 (w/ IDLE 0.5)
OS: IRIX


Since no other X app I know of works this way, I think this is a bug.

If you set the title of the IDLE window:

     idle.py -t IDLE

the title is set correctly, but the icon name is not.
It is set to "*IDLE" rather than "IDLE".




====================================================================
Audit trail:
Tue Mar 07 14:41:55 2000	guido	changed notes
Tue Mar 07 14:41:55 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Fri, 25 Feb 2000 08:26:32 -0500

> Since no other X app I know of works this way, I think this is a bug.
> 
> If you set the title of the IDLE window:
> 
>      idle.py -t IDLE
> 
> the title is set correctly, but the icon name is not.
> It is set to "*IDLE" rather than "IDLE".

Not a bug -- IDLE adds * before (and after!) the window title and
icon name to indicate that the window is modified and unsaved.

Does this bother you in some way?

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Randall Hopper <aa8vb@yahoo.com>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Mon, 28 Feb 2000 07:25:31 -0500

Guido van Rossum:
 |> Since no other X app I know of works this way, I think this is a bug.
 |> 
 |> If you set the title of the IDLE window:
 |> 
 |>      idle.py -t IDLE
 |> 
 |> the title is set correctly, but the icon name is not.
 |> It is set to "*IDLE" rather than "IDLE".
 |
 |Not a bug -- IDLE adds * before (and after!) the window title and
 |icon name to indicate that the window is modified and unsaved.

The icon name doesn't follow this convention:

        if not self.get_saved():            
            title = "*%s*" % title
            icon = "*%s" % icon

The reason I took note of this inconsistency is that I was assigning a
window manager icon to IDLE based on the startup icon string.

 |Does this bother you in some way?

Well, no other X app I know of communicates unsaved status by putting '*'s
in the title and icon, but I don't have a big problem with it.  

I do think the icon should have a '*' both before "and after", as you
described though.  I'm guessing this was just a typo.

Thanks,

Randall

-- 
Randall Hopper
aa8vb@yahoo.com


-------------------------------------------------------

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Mon, 28 Feb 2000 08:16:48 -0500

>  |Not a bug -- IDLE adds * before (and after!) the window title and
>  |icon name to indicate that the window is modified and unsaved.
> 
> The icon name doesn't follow this convention:
> 
>         if not self.get_saved():            
>             title = "*%s*" % title
>             icon = "*%s" % icon
> 
> The reason I took note of this inconsistency is that I was assigning a
> window manager icon to IDLE based on the startup icon string.
> 
>  |Does this bother you in some way?
> 
> Well, no other X app I know of communicates unsaved status by putting '*'s
> in the title and icon, but I don't have a big problem with it.  

Hm, I have to admit that I have given up years ago on configuring X
apps through their app name.  Is that still a common practice?  I could
certainly change things around so that the title and icon are always "idle:
*file*" or "idle: file" depending on saved status.

> I do think the icon should have a '*' both before "and after", as you
> described though.  I'm guessing this was just a typo.

I think it was intentional, trying to save some space in the icon
label.  Not worth it, probably.

--Guido van Rossum (home page: http://www.python.org/~guido/)



-------------------------------------------------------

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Randall Hopper <aa8vb@yahoo.com>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Tue, 29 Feb 2000 14:26:37 -0500


--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii

Guido van Rossum:
 |Hm, I have to admit that I have given up years ago on configuring X
 |apps through their app name.  Is that still a common practice?  I could

Definitely.  Most all (all?) use WM_CLASS, and many use WM_NAME and
WM_ICONNAME as fallbacks.  This is useful if WM_CLASS isn't set to a useful
value (as in this case).

IDLE doesn't set a class name property on it's window, so the window name
and icon name are all the window manager has to go on when matching it up
with configuration settings.

However, I believe IDLE could set a class name easily by passing it to
Tkinter -- e.g.  root = Tk( className="IDLE" ).  See attached.

More info: the properties used by many window managers as a key into a
configuration database are: CLASS, NAME, and ICON_NAME.  For example,
running 'xprop' on my xterm window here:

   > xprop
   ...
   WM_CLASS(STRING) = "xterm-color", "XTerm"
   ...
   WM_ICON_NAME(STRING) = "Local"
   WM_NAME(STRING) = "Local"

So I can set window manager resources for this window using "XTerm",
"xterm-color", or "Local" -- with overrides in that order I believe.
So I can have a default icon for xterms, and then an override icon for
xterm windows with a certain title.

IDLE doesn't set CLASS so it's basically useless for this configuration
purpose.  On stock IDLE:

   WM_CLASS(STRING) = "270515832", "Toplevel"

 |certainly change things around so that the title and icon are always "idle:
 |*file*" or "idle: file" depending on saved status.

If IDLE could set WM_CLASS to a static (or cmd-line-specified) value on
it's shell windows, that'd be enough for me.  For now I'm using -t IDLE,
but that doesn't cover opening new windows inside of IDLE (opening files,
File->New Window, etc.)

A unique prefix on the WM_NAME (title string) would work too.

 |> I do think the icon should have a '*' both before "and after", as you
 |> described though.  I'm guessing this was just a typo.
 |
 |I think it was intentional, trying to save some space in the icon
 |label.  Not worth it, probably.

Thanks,

Randall


-- 
Randall Hopper
aa8vb@yahoo.com

--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="tk.py"

from Tkinter import *
root = Tk( className="Test" )
btn = Button( root )
btn.pack()
root.mainloop()

--oyUTqETQ0mS9luUI--


-------------------------------------------------------

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Wed, 01 Mar 2000 09:21:41 -0500

Randall,

Thanks for your enlightenment.  I looked at your example, and it
works; but I need more, because IDLE creates windows using Toplevel(),
not using Tk().  (Using Tk() would create a new Tcl interpreter for
each window, which wastes time and memory resources, and re-reads the
~/.<whatever>.py file each time.)

I've experimented with xprop a bit, and I'm not getting results I
like.  If I write root = Tk(className="foo"), WM_CLASS is "foo",
"Foo".  Them if I write top = Toplevel(root), WM_CLASS for that window
is "1234567", "Toplevel".  If I try top = Toplevel(root, name="bar"),
I get "bar", "Toplevel".  Shouldn't I be able to set the second
component of WM_CLASS somehow?

Got any ideas?

If you can send me a patch, that would be greatly appreciated!

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Randall Hopper <aa8vb@yahoo.com>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Mon, 6 Mar 2000 08:50:29 -0500


--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii

Guido van Rossum:
 |Thanks for your enlightenment.  I looked at your example, and it
 |works; but I need more, because IDLE creates windows using Toplevel(),
 |not using Tk().  (Using Tk() would create a new Tcl interpreter for
 |each window, which wastes time and memory resources, and re-reads the
 |~/.<whatever>.py file each time.)
 |
 |I've experimented with xprop a bit, and I'm not getting results I
 |like.  If I write root = Tk(className="foo"), WM_CLASS is "foo",
 |"Foo".  Them if I write top = Toplevel(root), WM_CLASS for that window
 |is "1234567", "Toplevel".  If I try top = Toplevel(root, name="bar"),
 |I get "bar", "Toplevel".  Shouldn't I be able to set the second
 |component of WM_CLASS somehow?
 |
 |Got any ideas?

Sorry about that last message.  This issue is very closely related to the
resource loading issue on idle-dev, but not the same.  Once the small
change below is in-place (to solve this problem), the platform-independent
Tkinter methods for resource loading can be used to solve the idle-dev
problem, if desired.

Research indicates that the Tk-ism for setting Toplevel classes is:

      "toplevel .mytop -class classname"

So the Tkinter syntax is:

      top1   = Toplevel( root, class_=classname )

The attached test app demonstrates this.  I verified that I am able to set
X resources for these windows using the class name "Idle".

-- 
Randall Hopper
aa8vb@yahoo.com

--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="tk_class.py"

from Tkinter import *

CLASSNAME = "Idle"

root = Tk( className=CLASSNAME )
root.wm_withdraw()

# A toplevel with a WM_CLASS
top1   = Toplevel( root, class_=CLASSNAME )
label1 = Label( top1, text="Toplevel 1" )
label1.pack()

# Another one
top2   = Toplevel( root, class_=CLASSNAME )
label2 = Label( top2, text="Toplevel 2" )
label2.pack()

root.mainloop()

--MGYHOYXEY6WxJCY8--


-------------------------------------------------------

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Mon, 06 Mar 2000 09:11:30 -0500

> Sorry about that last message.  This issue is very closely related to the
> resource loading issue on idle-dev, but not the same.  Once the small
> change below is in-place (to solve this problem), the platform-independent
> Tkinter methods for resource loading can be used to solve the idle-dev
> problem, if desired.

See my response in idle-dev :-)

Of course the Tk options can still be used for changing things that
the config file or prefs dialog doesn't support.

> Research indicates that the Tk-ism for setting Toplevel classes is:
> 
>       "toplevel .mytop -class classname"
> 
> So the Tkinter syntax is:
> 
>       top1   = Toplevel( root, class_=classname )
> 
> The attached test app demonstrates this.  I verified that I am able to set
> X resources for these windows using the class name "Idle".

OK, I'll try to support this!

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110617&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:06:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:06:23 -0700
Subject: [Python-bugs-list] [Bug #110647] Segmentation violation on very long lists (PR#334)
Message-ID: <200009072206.PAA29127@bush.i.sourceforge.net>

Bug #110647, was updated on 2000-Jul-31 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: Later
Bug Group: None
Priority: 3
Summary: Segmentation violation on very long lists (PR#334)

Details: Jitterbug-Id: 334
Submitted-By: haase@media.mit.edu
Date: Sat, 20 May 2000 20:08:00 -0400 (EDT)
Version: Both Python 1.5.2 and 1.6a2
OS: SUSE Linux


Loading a .py file which attempts to define a very long list causes
a segmentation violation.  An example file can be found at
ftp:/pub/haase/todo.py, but I expect that most any long file defining a long
list (20K elements) would do.

Thanks,

Ken Haase






====================================================================
Audit trail:
Mon May 22 17:08:11 2000	guido	changed notes
Mon May 22 17:08:11 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:10
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] Segmentation violation on very long lists (PR#334)
Date: Sun, 21 May 2000 12:12:22 -0700

> Loading a .py file which attempts to define a very long list causes
> a segmentation violation.  An example file can be found at
> ftp:/pub/haase/todo.py, but I expect that most any long file defining a long
> list (20K elements) would do.

Thanks -- this is a known problem, it probably has to do with bytecode
field overflow (offsets are signed shorts).

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-01 15:54
By: jhylton

Comment:
Currently raises SyntaxError.  A better fix is in progress.
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110647&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:05:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:05:11 -0700
Subject: [Python-bugs-list] [Bug #110650] python with-threads core-dumps (PR#342)
Message-ID: <200009072205.PAA29063@bush.i.sourceforge.net>

Bug #110650, was updated on 2000-Jul-31 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: python with-threads core-dumps (PR#342)

Details: Jitterbug-Id: 342
Submitted-By: michael.exner@mrz.uni-magdeburg.de
Date: Wed, 31 May 2000 09:43:38 -0400 (EDT)
Version: 1.5.2
OS: hpux-11.00


When I compile python with threads python core-dumps:
$ ./python
pthread_mutex_init: Invalid argument
Memory fault(coredump)
without thread-support everything works fine
I tried this with hpux-ansi-c and with gcc (2.95.2) but got the same result




====================================================================
Audit trail:
Tue Jul 11 08:25:57 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-28 20:43
By: tim_one

Comment:
Note that the only call to pthread_mutex_init Python makes is in function PyThread_allocate_lock in file phread_pthread.h.  If Python compiled at all, it's extremely unlikely that the first argument is in error.  It's very likely that the second argument is in error, though:  there were many imcompatible revisions of the pthreads std, and pthread_mutexattr_default is a macro conditionally defined near the top of the file.  If this OS actually support pthreads, you have to figure out which *version* of pthreads it defines and arrange for config to define the *correct* one of the

PY_PTHREAD_D4
PY_PTHREAD_D7
PY_PTHREAD_STD
PY_PTHREAD_D6

symbols for your platform.  Else disable threads entirely.
-------------------------------------------------------

Date: 2000-Aug-29 07:34
By: memaul

Comment:
Goto link below for instructions and patches for building
python 152 with threads on hpux 10.20

http://memaul.tripod.com/index.html
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110650&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:05:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:05:12 -0700
Subject: [Python-bugs-list] [Bug #110665] Compiling python on hpux 11.00 with threads (PR#360)
Message-ID: <200009072205.PAA29067@bush.i.sourceforge.net>

Bug #110665, was updated on 2000-Jul-31 14:12
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Compiling python on hpux 11.00 with threads (PR#360)

Details: Jitterbug-Id: 360
Submitted-By: philipp.jocham@salomon.at
Date: Fri, 16 Jun 2000 08:47:06 -0400 (EDT)
Version: 1.5.2
OS: HP-UX 11.00


There are two missing details in the configure process to make this work
out of the box.

First: The function 
	pthread_create
isn't found in library libpthread.a but in libcma.a, because
pthread_create is just a macro in sys/pthread.h pointing to 
	__pthread_create_system

After patching ./configure directly and running 
	./configure --with-thread
(now detecting the correct library /usr/lib/libpthread.a) I also
added -lcl to Modules/Makefile at
	LIBS=           -lnet -lnsl -ldld  -lpthread -lcl

otherwise importing of modules with threads didn't work 
(in this case oci_.sl from DCOracle). 

I'm not sure about the correct syntax or wether it's the correct
place and method, but I would suggest a solution like the following
code snippet.

[...]
AC_MSG_CHECKING(for --with-thread)
[...]
AC_DEFINE(_POSIX_THREADS)
LIBS="$LIBS -lpthread -lcl"
LIBOBJS="$LIBOBJS thread.o"], [
AC_CHECK_LIB(pthread, __pthread_create_system, [AC_DEFINE(WITH_THREAD)
[...]

I hope this helps to make installation process smoother.
Fell free to contact me, if there are further questions.
Philipp
-- 
I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110665&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:05:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:05:12 -0700
Subject: [Python-bugs-list] [Bug #110683] can't compile with SSL support on WinNT (PR#403)
Message-ID: <200009072205.PAA29071@bush.i.sourceforge.net>

Bug #110683, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: can't compile with SSL support on WinNT (PR#403)

Details: Jitterbug-Id: 403
Submitted-By: falk.lehmann@gmx.net
Date: Mon, 17 Jul 2000 21:59:56 -0400 (EDT)
Version: 1.6a2
OS: WinNT 4.0


I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00.
The compiler stops with some warnings and an error message:
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2081) : error C2099: initializer
is not a constant

K:\Projects\Python-1.6a2\Modules\socketmodule.c(1947) : warning C4047:
'function' : 'int ' differs in levels of indirection from 'void *'
K:\Projects\Python-1.6a2\Modules\socketmodule.c(1947) : warning C4024: 'memset'
: different types for formal and actual parameter 2
K:\Projects\Python-1.6a2\Modules\socketmodule.c(1948) : warning C4047:
'function' : 'int ' differs in levels of indirection from 'void *'
K:\Projects\Python-1.6a2\Modules\socketmodule.c(1948) : warning C4024: 'memset'
: different types for formal and actual parameter 2
K:\Projects\Python-1.6a2\Modules\socketmodule.c(1933) : warning C4101: 'str' :
unreferenced local variable
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2083) : warning C4047:
'initializing' : 'int ' differs in levels of indirection from 'char [4]'
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2084) : warning C4047:
'initializing' : 'char *' differs in levels of indirection from 'unsigned int '
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2087) : warning C4047:
'initializing' : 'int ' differs in levels of indirection from 'void (__cdecl
*)(struct _object *)'
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2089) : warning C4047:
'initializing' : 'int (__cdecl *)(struct _object *,struct _iobuf *,int )'
differs in levels of indirection from 'struct _object *(__cdecl *)(struct
_object *,char *)'

Thanks in advance for fixing (at least the error).

Falk



====================================================================
Audit trail:
Tue Jul 25 07:25:55 2000	guido	changed notes
Tue Jul 25 07:25:55 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Guido van Rossum <guido@beopen.com>
Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403)
Date: Mon, 24 Jul 2000 11:35:24 -0500

> I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00.

Please try the current CVS tree (on its way to 2.0); we have no
problems compiling this on VC 6.0.

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-01 14:02
By: none

Comment:
From: Falk Lehmann <Falk.Lehmann@gmx.net>
Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403)
Date: Mon, 24 Jul 2000 13:46:45 -0500

[magical fwd by GvR]

Guido,
sorry, but forgot to write, that I switched on the USE_SSL macro.
And then the _socket module does not compile.

Falk

> > I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00.
> 
> Please try the current CVS tree (on its way to 2.0); we have no
> problems compiling this on VC 6.0.
> 
> --Guido van Rossum (home page: http://dinsdale.python.org/~guido/)
> 


-------------------------------------------------------

Date: 2000-Aug-01 14:02
By: none

Comment:
From: Guido van Rossum <guido@beopen.com>
Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403)
Date: Mon, 24 Jul 2000 14:00:20 -0500

> sorry, but forgot to write, that I switched on the USE_SSL macro.
> And then the _socket module does not compile.

It appears that the Python SSL code hasn't been ported to Windows.
We'll add this to our TODO list, but it's low priority...  Perhaps you
could give it a shot yourself?  See www.python.org/patches/ for how to
contribute.

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-01 14:02
By: none

Comment:
Windows compile fails when using openSSL.
-------------------------------------------------------

Date: 2000-Aug-23 10:35
By: jhylton

Comment:
This is a bug.  Standard extensions modules should compile, even on obscure platforms like Windows NT.  Need a Windows user with time to install OpenSSL to fix this.

-------------------------------------------------------

Date: 2000-Aug-30 12:01
By: gvanrossum

Comment:
Let's not worry about this for 2.0. While the OpenSSL support is part of the socket module, we don't have the resources right now to port that support to Windows.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110683&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:06:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:06:24 -0700
Subject: [Python-bugs-list] [Bug #110660] IDLE-0.5  ctrl-F5 (PR#355)
Message-ID: <200009072206.PAA29131@bush.i.sourceforge.net>

Bug #110660, was updated on 2000-Jul-31 14:11
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: IDLE-0.5  ctrl-F5 (PR#355)

Details: Jitterbug-Id: 355
Submitted-By: gpk@bell-labs.com
Date: Tue, 13 Jun 2000 11:30:14 -0400 (EDT)
Version: yesterday's CVS
OS: Solaris 2.6


If you type ctrl-f5 to run a script twice in sucession,
IDLE will incorrectly pop up a window saying
"Not Saved.  Please Save First."

If you save (even though you haven't changed anything,
and even though there are no asterisks around the window
title), then ctrl-f5 will work again.

This *doesn't* happen if you run the script twice in
succession from the menu.



====================================================================
Audit trail:
Tue Jul 11 08:26:00 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] IDLE-0.5  ctrl-F5 (PR#355)
Date: Tue, 13 Jun 2000 11:55:09 -0400

Pretty mysterious!  Doesn't happen under IDLE 0.5 for me.  Running under
Windows, but darned hard to see why that would matter.  Can anyone else try
this under Solaris 2.6?  May have something to do with the specific script
you're running, Greg; e.g., does it happen if the script file contains just

print "Hi!"

?

> -----Original Message-----
> From: python-bugs-list-admin@python.org
> [mailto:python-bugs-list-admin@python.org]On Behalf Of gpk@bell-labs.com
> Sent: Tuesday, June 13, 2000 11:30 AM
> To: python-bugs-list@python.org
> Cc: bugs-py@python.org
> Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355)
>
>
> Full_Name: Greg Kochanski
> Version: yesterday's CVS
> OS: Solaris 2.6
> Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130)
>
>
> If you type ctrl-f5 to run a script twice in sucession,
> IDLE will incorrectly pop up a window saying
> "Not Saved.  Please Save First."
>
> If you save (even though you haven't changed anything,
> and even though there are no asterisks around the window
> title), then ctrl-f5 will work again.
>
> This *doesn't* happen if you run the script twice in
> succession from the menu.
>
>
>
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list
>




-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355)
Date: Tue, 20 Jun 2000 16:42:57 -0500

I think I understand this.  It's happened to me too.  Pressing ^F5
changes the focus to the PyShell window.  Pressing ^F5 again then
indeed complains about that window being unsaved.

--Guido van Rossum (home page: http://www.python.org/~guido/)

[Tim]
> Pretty mysterious!  Doesn't happen under IDLE 0.5 for me.  Running under
> Windows, but darned hard to see why that would matter.  Can anyone else try
> this under Solaris 2.6?  May have something to do with the specific script
> you're running, Greg; e.g., does it happen if the script file contains just
> 
> print "Hi!"
> 
> ?
> 
> > -----Original Message-----
> > From: python-bugs-list-admin@python.org
> > [mailto:python-bugs-list-admin@python.org]On Behalf Of gpk@bell-labs.com
> > Sent: Tuesday, June 13, 2000 11:30 AM
> > To: python-bugs-list@python.org
> > Cc: bugs-py@python.org
> > Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355)
> >
> >
> > Full_Name: Greg Kochanski
> > Version: yesterday's CVS
> > OS: Solaris 2.6
> > Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130)
> >
> >
> > If you type ctrl-f5 to run a script twice in sucession,
> > IDLE will incorrectly pop up a window saying
> > "Not Saved.  Please Save First."
> >
> > If you save (even though you haven't changed anything,
> > and even though there are no asterisks around the window
> > title), then ctrl-f5 will work again.
> >
> > This *doesn't* happen if you run the script twice in
> > succession from the menu.
> >
> >
> >
> > _______________________________________________
> > Python-bugs-list maillist  -  Python-bugs-list@python.org
> > http://www.python.org/mailman/listinfo/python-bugs-list
> >
> 
> 
> 
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Greg Kochanski <gpk@bell-labs.com>
Subject: Re: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355)
Date: Tue, 20 Jun 2000 17:25:37 -0400

Guido van Rossum wrote:
> 
> I think I understand this.  It's happened to me too.  Pressing ^F5
> changes the focus to the PyShell window.  Pressing ^F5 again then
> indeed complains about that window being unsaved.
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

Ah. Sure enough.   Perhaps the best thing to do
is just to have the little error message explain
which window is unsaved.  Include the title
of the unsaved window in the error box, maybe.

I'd be happy to send a patch, but the paperwork
would be terrible...


-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355)
Date: Tue, 20 Jun 2000 18:10:35 -0500

> > I think I understand this.  It's happened to me too.  Pressing ^F5
> > changes the focus to the PyShell window.  Pressing ^F5 again then
> > indeed complains about that window being unsaved.
> > 
> > --Guido van Rossum (home page: http://www.python.org/~guido/)
> 
> Ah. Sure enough.   Perhaps the best thing to do
> is just to have the little error message explain
> which window is unsaved.  Include the title
> of the unsaved window in the error box, maybe.
> 
> I'd be happy to send a patch, but the paperwork
> would be terrible...

No need for paperwork, just the disclaimer text.

But I think the better patch would be to make PyShell a special case
and make it rerun the last window that had the focus.

--Guido van Rossum (home page: http://www.python.org/~guido/)



-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110660&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:06:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:06:25 -0700
Subject: [Python-bugs-list] [Bug #110679] profile.py: self-profiling bug (PR#394)
Message-ID: <200009072206.PAA29135@bush.i.sourceforge.net>

Bug #110679, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: profile.py: self-profiling bug (PR#394)

Details: Jitterbug-Id: 394
Submitted-By: akuchlin@mems-exchange.org
Date: Fri,  7 Jul 2000 09:03:04 -0400 (EDT)
Version: 2.0cvs
OS: 


Reported by jtravis@cse.unl.edu (Jon Travis) in comp.lang.python:

There is a small bug while running some of
the profiling code from within the profiler.  
Specifically:

import profile
x = profile.Profile()
x.run("x.dump_stats('/tmp/foo')")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "./Lib/profile.py", line 347, in run
    return self.runctx(cmd, dict, dict)
  File "./Lib/profile.py", line 353, in runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "./Lib/profile.py", line 322, in dump_stats
    self.create_stats()
  File "./Lib/profile.py", line 327, in create_stats
    self.simulate_cmd_complete()
  File "./Lib/profile.py", line 312, in simulate_cmd_complete
    self.t = self.get_time() - t
  File "./Lib/profile.py", line 191, in trace_dispatch_i
    if self.dispatch[event](frame,t):
  File "./Lib/profile.py", line 248, in trace_dispatch_return
    pt, ptt, pct, pfn, pframe, pcur = rcur
TypeError: unpack non-sequence

I have a small 2 liner fix, but I doubt it is correct,
merely a band-aid, so I won't post it.

-- Jon






====================================================================
Audit trail:
Tue Jul 11 08:24:32 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110679&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:06:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:06:26 -0700
Subject: [Python-bugs-list] [Bug #110688] Reuben Sumner: Py_REF_COUNT (PR#43)
Message-ID: <200009072206.PAA29139@bush.i.sourceforge.net>

Bug #110688, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: Reuben Sumner: Py_REF_COUNT (PR#43)

Details: Jitterbug-Id: 43
Submitted-By: Guido van Rossum <guido@CNRI.Reston.VA.US>
Date: Fri, 30 Jul 1999 13:52:16 -0400
Version: None
OS: None

------- Forwarded Message

Date:    Tue, 20 Jul 1999 10:53:34 +0300
From:    Reuben Sumner <rasumner@iname.com>
To:      guido@python.org
Subject: Py_REF_COUNT

I posted a message through DejaNews which didn't seem to propogate (at
least it didn't reach here).

Try the following in a Python with Py_REF_DEBUG but without Py_TRACE_REFS

class C:
	def __init__(self): pass

while 1:
	c=C()

Stop it after a while and look at the reference count printed!  Python
is not actually using all that memory though.  With Py_TRACE_REFS things
are ok.  I can't figure it out.  The class instance dealloc routine is rather
hairy.

With Py_TRACE_REFS some code of mine is doing some really bizarre things
but I would rather deal with one thing at a time.

Python version is 1.5.2 (tried on at least two platforms, both using gcc)

Many thanks,

Reuben

------- End of Forwarded Message



====================================================================
Audit trail:
Wed Aug 04 12:12:39 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-28 11:52
By: jhylton

Comment:
This report is a bit too vague to be useful.  I've queried the original poster to see if he is still having problems.

-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110688&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:06:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:06:30 -0700
Subject: [Python-bugs-list] [Bug #110698] strptime gives format mismatch when time zone present (PR#164)
Message-ID: <200009072206.PAA29144@bush.i.sourceforge.net>

Bug #110698, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: strptime gives format mismatch when time zone present (PR#164)

Details: Jitterbug-Id: 164
Submitted-By: python-bugreport@derf.net
Date: Tue, 21 Dec 1999 08:27:27 -0500 (EST)
Version: 1.5.2
OS: RedHat 5.2; Linux 2.2.12


time.strptime() seems to fail when the time zone ('%Z') appears in the format
string.  when it is omitted from the format string (and from the string being 
parsed), strptime() works fine.

here is a sample script which demonstrates the bug:

------
#!/usr/bin/python

import time

timetuple0 = time.localtime(time.time())
print timetuple0

format1 = '%a %b %d %H:%M:%S %Y'
timestring1 = time.strftime( format1 , timetuple0 )
print timestring1
timetuple1 = time.strptime( timestring1 , format1 )
print timetuple1

format2 = '%a %b %d %H:%M:%S %Z %Y'
timestring2 = time.strftime( format2 , timetuple0 )
print timestring2
timetuple2 = time.strptime( timestring2 , format2 )
print timetuple2
------

when i run the above, i get the following output:

------
(1999, 12, 21, 5, 25, 35, 1, 355, 0)
Tue Dec 21 05:25:35 1999
(1999, 12, 21, 5, 25, 35, 1, 355, 0)
Tue Dec 21 05:25:35 PST 1999
Traceback (innermost last):
  File "./test.py", line 17, in ?
    timetuple2 = time.strptime( timestring2 , format2 )
ValueError: format mismatch
------



====================================================================
Audit trail:
Tue Dec 21 11:47:04 1999	guido	changed notes
Tue Dec 21 11:47:05 1999	guido	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] strptime gives format mismatch when time zone present (PR#164)
Date: Tue, 21 Dec 1999 09:12:15 -0500

> time.strptime() seems to fail when the time zone ('%Z') appears in
> the format string.  when it is omitted from the format string (and
> from the string being parsed), strptime() works fine.

Reporting this as a Python bug is not going to fix it.  The
time.strptime() function in Python is a very thin wrapper around the
strptime() function in the C library.  We get a lot of complaints
about this, but there's no way that we're able to fix this -- it's the
C strptime() function that needs to be fixed.  Write to your friendly
Linux support people!

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
The C library strptime() needs fixin'.
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110698&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:06:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:06:33 -0700
Subject: [Python-bugs-list] [Bug #110706] Compile error (PR#44)
Message-ID: <200009072206.PAA29148@bush.i.sourceforge.net>

Bug #110706, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Compile error (PR#44)

Details: Jitterbug-Id: 44
Submitted-By: rene@kronos.szabinet.hu
Date: Sun, 1 Aug 1999 16:39:42 -0400 (EDT)
Version: 1.5.2
OS: Linux


Compile error with Python-1.5.2 on
Linux Slackware 4.0, kernel 2.2.10-ac8, gcc 2.7.2.3, make 3.76.1

./configure --prefix=/usr/local --with-threads && make
...
./socketmodule.c: In function `setipaddr':
./socketmodule.c:392: warning: passing arg 5 of `gethostbyname_r' from
incompatible pointer type
./socketmodule.c:392: too many arguments to function `gethostbyname_r'
./socketmodule.c:392: warning: assignment makes integer from pointer without a
cast
./socketmodule.c: In function `PySocket_gethostbyname_ex':
./socketmodule.c:1471: warning: passing arg 5 of `gethostbyname_r' from
incompatible pointer type
./socketmodule.c:1471: too many arguments to function `gethostbyname_r'
./socketmodule.c:1471: warning: assignment makes integer from pointer without a
cast
./socketmodule.c: In function `PySocket_gethostbyaddr':
./socketmodule.c:1534: warning: passing arg 7 of `gethostbyaddr_r' from
incompatible pointer type
./socketmodule.c:1534: too many arguments to function `gethostbyaddr_r'
./socketmodule.c:1534: warning: assignment makes integer from pointer without a
cast
make[1]: *** [socketmodule.o] Error 1
make: *** [Modules] Error 2



====================================================================
Audit trail:
Wed Aug 04 12:12:39 1999	guido	moved from incoming to platformbug
Mon Aug 30 12:37:34 1999	guido	changed notes
Mon Oct 25 15:15:46 1999	guido	changed notes

Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110706&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:06:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:06:39 -0700
Subject: [Python-bugs-list] [Bug #110839] PRIVATE: CGIHTTPServer (PR#239)
Message-ID: <200009072206.PAA29156@bush.i.sourceforge.net>

Bug #110839, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 3
Summary: PRIVATE: CGIHTTPServer (PR#239)

Details: Jitterbug-Id: 239
Submitted-By: Michael_Frericks@informatik-kooperation.de
Date: Fri, 17 Mar 2000 11:27:23 -0500 (EST)
Version: 1.5.2
OS: WinNT 4.0


The module CGIHTTPServer does not run on WinNT since 

a) the function executable() seems to return a false value, if you omit the call
of executable() you come to
b) the function nobody_uid() imports the module pwd available only for unix
c) other unix-functions as fork... are used to create a process with the user
nobody



====================================================================
Audit trail:
Mon Apr 03 18:39:48 2000	guido	changed notes
Mon Apr 03 18:39:48 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:15
By: none

Comment:
This module still needs to be ported to Windows...
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110839&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:06:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:06:40 -0700
Subject: [Python-bugs-list] [Bug #110849] Fwd: Debian Bug#42318: urllib.py has problems with malformed proxy env. variables (PR#59)
Message-ID: <200009072206.PAA29160@bush.i.sourceforge.net>

Bug #110849, was updated on 2000-Aug-01 14:16
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Fwd: Debian Bug#42318: urllib.py has problems with malformed proxy env. variables (PR#59)

Details: Jitterbug-Id: 59
Submitted-By: flight@debian.org
Date: Fri, 20 Aug 1999 13:40:04 -0400 (EDT)
Version: 1.5.2
OS: Debian potato


Summary: Python's urllib expects a fully qualified URL in HTTP_PROXY (like
"http://proxy:8080/"). Many applications allow short forms in HTTP_PROXY
(like "proxy:8080"). If HTTP_PROXY is set to a short form, urllib.py will
fail with an uncomprehensible error message.


Long form:

Francesco Potorti` <F.Potorti@cnuce.cnr.it> says (in the Debian bug report
http://www.debian.org/Bugs/db/42/42318.html):

  "when setting a proxy variable that is not parsed by urllib, urllib does
   not print a comprehensible error message."

An example:


Short form HTTP_PROXY:

  master% HTTP_PROXY="proxy.cnr.it:8081" \
    python -c 'import urllib; print
urllib.urlretrieve("http://www.olemiss.edu/")'
  Traceback (innermost last):
    File "<string>", line 1, in ?
    File "/usr/lib/python1.5/urllib.py", line 69, in urlretrieve
      return _urlopener.retrieve(url)
    File "/usr/lib/python1.5/urllib.py", line 186, in retrieve
      fp = self.open(url)
    File "/usr/lib/python1.5/urllib.py", line 154, in open
      return self.open_unknown(fullurl)
    File "/usr/lib/python1.5/urllib.py", line 168, in open_unknown
      raise IOError, ('url error', 'unknown url type', type)
  IOError: ('url error', 'unknown url type', 'http')


Fully qualified URL in HTTP_PROXY:

  master% HTTP_PROXY="http://proxy.cnr.it:8081" \
    python -c 'import urllib; print
urllib.urlretrieve("http://www.olemiss.edu/")'
  ('/tmp/@15884.1', <mimetools.Message instance at 80adb08>)



====================================================================
Audit trail:
Mon Aug 30 12:35:03 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110849&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:06:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:06:42 -0700
Subject: [Python-bugs-list] [Bug #110857] it don't make (PR#269)
Message-ID: <200009072206.PAA29164@bush.i.sourceforge.net>

Bug #110857, was updated on 2000-Aug-01 14:38
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Irreproducible
Priority: 3
Summary: it don't make (PR#269)

Details: Jitterbug-Id: 269
Submitted-By: mitch.harris@usa.net
Date: Mon,  3 Apr 2000 13:29:25 -0400 (EDT)
Version: 1.6
OS: sun 5.6


First time I tried to install Python. 


/usr2/t_mitchh/python/Python-1.6a1>version
Machine hardware:   sun4u
OS version:         5.6
Processor type:     sparc
Hardware:           SUNW,Ultra-1

The following components are installed on your system:


Sun Visual WorkShop C++ 3.0
        Sun WorkShop Compiler C 4.2 
        Sun WorkShop Compiler C++ 4.2 
        Sun WorkShop Tools.h++ 7.0 
        Sun WorkShop Tools.h++ 6.0.4 
        Sun WorkShop Visual 2.0 
        Sun WorkShop IPE 4.0 
        Sun WorkShop CodeManager 2.0 
        Sun WorkShop Distributed Make 2.0 
        Sun WorkShop FileMerge 3.0 
        Sun WorkShop FreezePoint 2.0 
        Sun WorkShop Maketool 2.0 
        Sun WorkShop VersionTool 2.0 
        Sun WorkShop Dbx 4.0 
        Sun WorkShop Performance Analyzer 4.0 
        Sun WorkShop LoopTool 2.1 
        Sun WorkShop LockLint 2.1 
        Sun WorkShop Thread Analyzer 1.2 
        Sun WorkShop XEmacs 20.00 

/usr2/t_mitchh/python/Python-1.6a1>./configure
creating cache ./config.cache
checking MACHDEP... sunos5
checking for --without-gcc... no
checking for --with-cxx=<compiler>... no
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking LINKCC... $(PURIFY) $(CC)
checking LDLIBRARY... 
checking for ranlib... ranlib
checking for ar... ar
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking for minix/config.h... no
checking whether gcc accepts -OPT:Olimit=0... no
checking whether gcc accepts -Olimit 1500... no
checking for C preprocessor type... ansi
checking for ANSI C header files... yes
checking for dlfcn.h... yes
checking for fcntl.h... yes
checking for limits.h... yes
checking for locale.h... yes
checking for ncurses.h... no
checking for pthread.h... yes
checking for signal.h... yes
checking for stdarg.h... yes
checking for stddef.h... yes
checking for stdlib.h... yes
checking for thread.h... yes
checking for unistd.h... yes
checking for utime.h... yes
checking for sys/audioio.h... yes
checking for sys/file.h... no
checking for sys/lock.h... yes
checking for sys/param.h... no
checking for sys/select.h... yes
checking for sys/time.h... yes
checking for sys/times.h... yes
checking for sys/un.h... yes
checking for sys/utsname.h... yes
checking for sys/wait.h... yes
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking for clock_t in time.h... yes
checking for mode_t... yes
checking for off_t... yes
checking for pid_t... yes
checking return type of signal handlers... void
checking for size_t... yes
checking for uid_t in sys/types.h... yes
checking size of int... 4
checking size of long... 4
checking size of void *... 4
checking size of char... 1
checking size of short... 2
checking size of float... 4
checking size of double... 8
checking for long long support... yes
checking size of long long... 8
checking size of off_t... 4
checking whether to enable large file support... no
checking for --with-next-framework... no
checking for --with-dyld... no
checking SO... .so
checking LDSHARED... ld -G
checking CCSHARED... 
checking LINKFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for t_open in -lnsl... yes
checking for socket in -lsocket... yes
checking for socket in -lnet... no
checking for --with-libs... no
checking for --with(out)-readline... not specified.
checking for --with-dec-threads... no
checking for --with-threads... no
checking for --with-thread... no
checking for --with-sgi-dl... no
checking for --with-dl-dld... no
checking for dlopen... yes
checking DYNLOADFILE... dynload_shlib.o
checking for alarm... yes
checking for chown... yes
checking for clock... yes
checking for confstr... yes
checking for ctermid... yes
checking for ctermid_r... yes
checking for dlopen... (cached) yes
checking for execv... yes
checking for flock... no
checking for fork... yes
checking for fsync... yes
checking for fdatasync... no
checking for fpathconf... yes
checking for ftime... yes
checking for ftruncate... yes
checking for getgroups... yes
checking for getlogin... yes
checking for getpeername... yes
checking for getpgrp... yes
checking for getpid... yes
checking for getpwent... yes
checking for gettimeofday... yes
checking for getwd... yes
checking for kill... yes
checking for link... yes
checking for lstat... yes
checking for mkfifo... yes
checking for mktime... yes
checking for nice... yes
checking for pathconf... yes
checking for pause... yes
checking for plock... yes
checking for pthread_init... no
checking for putenv... yes
checking for readlink... yes
checking for select... yes
checking for setgid... yes
checking for setlocale... yes
checking for setuid... yes
checking for setsid... yes
checking for setpgid... yes
checking for setpgrp... yes
checking for setvbuf... yes
checking for sigaction... yes
checking for siginterrupt... yes
checking for sigrelse... yes
checking for strftime... yes
checking for strptime... yes
checking for symlink... yes
checking for sysconf... yes
checking for tcgetpgrp... yes
checking for tcsetpgrp... yes
checking for tempnam... yes
checking for timegm... no
checking for times... yes
checking for tmpfile... yes
checking for tmpnam... yes
checking for tmpnam_r... yes
checking for truncate... yes
checking for uname... yes
checking for waitpid... yes
checking for fseek64... no
checking for fseeko... yes
checking for fstatvfs... yes
checking for ftell64... no
checking for ftello... yes
checking for statvfs... yes
checking for dup2... yes
checking for getcwd... yes
checking for strdup... yes
checking for strerror... yes
checking for memmove... yes
checking for getpgrp... (cached) yes
checking for setpgrp... (cached) yes
checking for gettimeofday... (cached) yes
checking whether time.h and sys/time.h may both be included... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for tm_zone in struct tm... no
checking for tzname... yes
checking for time.h that defines altzone... yes
checking whether sys/select.h and sys/time.h may both be included... yes
checking whether char is unsigned... no
checking for working const... yes
checking for inline... inline
checking for working volatile... yes
checking for working signed char... yes
checking for prototypes... yes
checking for variable length prototypes and stdarg.h... yes
checking for bad exec* prototypes... no
checking for bad static forward... no
checking whether va_list is an array... no
checking for gethostbyname_r... yes
checking gethostbyname_r with 6 args... no
checking gethostbyname_r with 5 args... no
checking gethostbyname_r with 3 args... no
checking for __fpu_control in -lieee... no
checking for --with-fpectl... no
checking for --with-libm=STRING... default LIBM="-lm"
checking for --with-libc=STRING... default LIBC=""
checking for hypot... yes
checking for hypot... (cached) yes
checking for genuine getopt... yes
checking what malloc(0) returns... nonnull
checking for wchar.h... yes
checking for usable wchar_t... no
checking whether byte ordering is bigendian... yes
checking for --with-wctype-functions... no
updating cache ./config.cache
creating ./config.status
creating Makefile
creating Objects/Makefile
creating Parser/Makefile
creating Python/Makefile
creating Modules/Makefile.pre
creating Modules/Setup.thread
creating config.h


/usr2/t_mitchh/python/Python-1.6a1/Modules>make
gcc  -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c
In file included from ./posixmodule.c:3194:
/usr/include/sys/statvfs.h:38: parse error before `fsblkcnt_t'
/usr/include/sys/statvfs.h:38: warning: no semicolon at end of struct or union
/usr/include/sys/statvfs.h:39: warning: data definition has no type or storage
class
/usr/include/sys/statvfs.h:40: parse error before `f_bavail'
/usr/include/sys/statvfs.h:40: warning: data definition has no type or storage
class
/usr/include/sys/statvfs.h:41: parse error before `f_files'
/usr/include/sys/statvfs.h:41: warning: data definition has no type or storage
class
/usr/include/sys/statvfs.h:42: parse error before `f_ffree'
/usr/include/sys/statvfs.h:42: warning: data definition has no type or storage
class
/usr/include/sys/statvfs.h:43: parse error before `f_favail'
/usr/include/sys/statvfs.h:43: warning: data definition has no type or storage
class
/usr/include/sys/statvfs.h:51: parse error before `}'
/usr/include/sys/statvfs.h:51: warning: data definition has no type or storage
class
./posixmodule.c: In function `posix_fstatvfs':
./posixmodule.c:3207: storage size of `st' isn't known
./posixmodule.c: In function `posix_statvfs':
./posixmodule.c:3259: storage size of `st' isn't known
make: *** [posixmodule.o] Error 1

I tried this 

#if defined(HAVE_FSTATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
#if defined(HAVE_STATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
#ifdef HAVE_FSTATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
#ifdef HAVE_STATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

and got this

/prj/qed2/local//lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.1/include/sys/param.h:187:
warning: `NBBY' r
/usr/include/sys/select.h:45: warning: this is the location of the previous
definition
In file included from /usr/include/sys/stream.h:26,
                 from /usr/include/netinet/in.h:38,
                 from /usr/include/netdb.h:96,
                 from ./socketmodule.c:163:
/usr/include/sys/model.h:32: #error "No DATAMODEL_NATIVE specified"
make[1]: *** [socketmodule.o] Error 1
make[1]: Leaving directory `/usr2/t_mitchh/python/Python-1.6a1/Modules'
make: *** [Modules] Error 2



====================================================================
Audit trail:
Mon May 22 17:44:30 2000	guido	changed notes
Mon May 22 17:44:30 2000	guido	moved from incoming to irreproducible

Follow-Ups:

Date: 2000-Aug-01 14:38
By: none

Comment:
Sun's compiler sucks?
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110857&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:06:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:06:53 -0700
Subject: [Python-bugs-list] [Bug #113795] IDLE 0.6 with Python 2.0b1 doesn't handle chinese characters
Message-ID: <200009072206.PAA29178@bush.i.sourceforge.net>

Bug #113795, was updated on 2000-Sep-07 06:49
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: IDLE 0.6 with Python 2.0b1 doesn't handle chinese characters

Details: I just switched from 1.5.2 to 2.0b1 on W2K/Simplified Chinese version. I used to be able to input chinese characters directly into IDLE, and access violations did happen quite often. Now with 2.0b1, I can't even input chinese characters into the IDLE window anymore:IDLE automatically changed chinese characters into illegible stuff; it's the same when I copy from a text editor and paste into the IDLE window. I guess it's related to the induction of unicode support in 2.0, but is there a workaround I should know, or I should switch back to 1.5.2, or it's a bug worth fixing?

Thanks.


Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113795&group_id=5470


From nobody@sourceforge.net  Thu Sep  7 23:06:54 2000
From: nobody@sourceforge.net (Nobody)
Date: Thu, 7 Sep 2000 15:06:54 -0700
Subject: [Python-bugs-list] [Bug #113812] Serious garbage collection problems with 2.0b1
Message-ID: <200009072206.PAA29182@bush.i.sourceforge.net>

From: noreply@sourceforge.net

Bug #113812, was updated on 2000-Sep-07 10:10
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Serious garbage collection problems with 2.0b1


Details: Since I've installed version 2.0b1, I ran into a few (serious) problems
with a non-trivial application (+80,000 lines of Python). It seems that
the are all related to the new garbage collection:

 - Suddenly, assertions fail because lists have become empty 
   while they shouldn't have. I looks like their elements have been
   garbage collected while they were still reachable.

 - Under other circumstances, I get coredumps which always 
   seem to happen in function "move_root_reachable" of gcmodule.c:
   the "traverse" function pointer seems to contain a bogus address.

 - When I run a Purified version of the interpreter, I can't reproduce
   either problem, but instead, the garbage collector seems to get
   stuck in an endless loop each time. This always happens in the
   same function "move_root_reachable". Purify doesn't produce any 
   relevant warning.

The code runs just fine with version 1.6 of the interpreter, or when I
disable the garbage collector.

Probably relevant is the fact that the objects (10,000's) in my application
are very heavily cross-linked (nearly all links are bi-directional), which 
probably puts a lot of stress on the garbage collector.

My platform: HP-UX 10.20 / c89 compiler


Follow-Ups:

Date: 2000-Sep-07 10:14
By: edg

Comment:
Just one more thing: when I turn on the gc debugging,
the interpreter also seems to get stuck in an endless loop.
-------------------------------------------------------

Date: 2000-Sep-07 14:41
By: jhylton

Comment:
If you set the GC threshold to 0, 
import gc
gc.set_threshold(0)

Do you get the same problem?  Not that I doubt there is some sort of gc problem, but I wonder if there is something going wrong in the accounting or in the collection.

How hard would it be for someone to try to reproduce this bug?  Obviously, it would be helpful to get a smaller test case that has the same behavior as your large program and also tickles the bug.

Do you have any C extension modules in your application or is it pure Python?
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113812&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:05:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:05:14 -0700
Subject: [Python-bugs-list] [Bug #110692] urllib.URLopener does not work with proxies (PR#67)
Message-ID: <200009072205.PAA29075@bush.i.sourceforge.net>

Bug #110692, was updated on 2000-Jul-31 14:15
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: urllib.URLopener does not work with proxies (PR#67)

Details: Jitterbug-Id: 67
Submitted-By: andrew@fc.hp.com
Date: Thu, 26 Aug 1999 16:20:02 -0400 (EDT)
Version: 1.5.1
OS: 


When using urllib.URLopener(proxy) (instead of setting _PROXY env variables and

calling urllib.openurl(),
you get the following error message:

 File "./watchdog.py", line 118, in main
    url.open(urltocheck)
  File "/usr/lib/python1.5/urllib.py", line 158, in open
    return getattr(self, name)(url)
  File "/usr/lib/python1.5/urllib.py", line 258, in open_http
    return addinfourl(fp, headers, "http:" + url)
TypeError: illegal argument type for built-in operation 

When using explicti proxies, url is a tuple instead of a string.  You can't 
concatanate a tuple to a string, so the operation fails.

 



====================================================================
Audit trail:
Mon Aug 30 12:40:45 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-05 13:27
By: loewis

Comment:
This is likely incorrect usage of the module. The proxy argument must
be a dictionary mapping strings of protocol names to  strings of URLs.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110692&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:05:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:05:15 -0700
Subject: [Python-bugs-list] [Bug #110702] closing a popen file descriptor (PR#33)
Message-ID: <200009072205.PAA29079@bush.i.sourceforge.net>

Bug #110702, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: closing a popen file descriptor (PR#33)

Details: Jitterbug-Id: 33
Submitted-By: laik@cs.stanford.edu
Date: Tue, 20 Jul 1999 14:00:11 -0400 (EDT)
Version: 1.5.2
OS: Linux 2.2.10


I can't close a pipe's file descriptor without an error:

>>> import os
>>> p1 = os.popen("cat dummy1", "r")
>>> p2 = os.popen("cat dummy2", "r")
>>> p1.close()
Traceback (innermost last):
  File "<stdin>", line 1, in ?
IOError: (0, 'Error')

It only happens if I do two or more popens. If I try to close any file
descriptor
but the last one I opened, I get this mysterious IOError. It happens regardless
of the order I try to close the descriptors.



====================================================================
Audit trail:
Sat Jul 24 17:02:54 1999	guido	sent reply 1
Sat Jul 24 17:03:22 1999	guido	changed notes
Sat Jul 24 17:03:22 1999	guido	moved from incoming to open
Sat Jul 24 17:05:25 1999	guido	moved from open to platformbug

Follow-Ups:

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: closing a popen file descriptor (PR#33)
Date: Sat Jul 24 17:02:54 1999

> Full_Name: Kevin Lai
> Version: 1.5.2
> OS: Linux 2.2.10
> Submission from: (NULL) (192.25.214.6)
> 
> 
> I can't close a pipe's file descriptor without an error:
> 
>>>> import os
>>>> p1 = os.popen("cat dummy1", "r")
>>>> p2 = os.popen("cat dummy2", "r")
>>>> p1.close()
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> IOError: (0, 'Error')
> 
> It only happens if I do two or more popens. If I try to close any file
> descriptor
> but the last one I opened, I get this mysterious IOError. It happens
regardless
> of the order I try to close the descriptors.

Kevin, this works on other platforms I can try (Solaris 2.6, linux 2.0.34).
One possibility is that the C library in the Linux version you are using
has changed; the IOError means that its pclose() returns an error indicator.
The (0, 'Error') message means that pclose() didn't set the errno variable.
It could be a bug in the Linux C library, or a change in interface that
requires Python to interpret the error return differently.

Can you help us discover which is the case?  Does the man page for pclose()
say anything about this?  Does this fail in an equivalent C program?

--Guido van Rossum

-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
From: laik@tnt.Stanford.EDU
Subject: Re: closing a popen file descriptor (PR#33)
Date: Tue, 27 Jul 1999 01:41:15 -0700


Guido,

Thanks for your quick reply. As far as I can tell, the man page for
pclose() doesn't mention any API changes. I have included the popen()
and wait4() man pages for the system I am using (PII 300, Linux
2.2.10, glibc 2.1.1). 

I have written a short C program which tries to exercise the bug. On my
system, it gives these results:

[laik@nebraska]~>gcc popen.c
[laik@nebraska]~>a.out
pclose(p1): 0, WIFEXITED: 1, WEXITSTATUS:0, WIFSIGNALED:0
pclose(p2): 0, WIFEXITED: 1, WEXITSTATUS:0, WIFSIGNALED:0
pclose(p3): 0, WIFEXITED: 1, WEXITSTATUS:0, WIFSIGNALED:0

On a Linux 2.0.33, glibc 2.0.7 system, it gives the same
results. However, my system exhibits the problem under Python, while
the other does not. I conclude that my C program doesn't mimic the
Python program well enough to trigger the bug, but I don't know how to
fix that.

#include <stdio.h>
#define _USE_BSD
#include <sys/types.h>
#include <sys/resource.h>
#include <sys/wait.h>

main()
{
    FILE *p1, *p2, *p3;
    int pc1, pc2, pc3;

    p1 = popen("ls", "r");
    p2 = popen("ls", "r");
    p3 = popen("ls", "r");
    sleep(1);
    pc1 = pclose(p1);
    printf("pclose(p1): %d, WIFEXITED: %d, WEXITSTATUS:%d, WIFSIGNALED:%d\n", 
	   pc1, WIFEXITED(pc1), WEXITSTATUS(pc1), WIFSIGNALED(pc1));
    pc2 = pclose(p2);
    printf("pclose(p2): %d, WIFEXITED: %d, WEXITSTATUS:%d, WIFSIGNALED:%d\n", 
	   pc1, WIFEXITED(pc2), WEXITSTATUS(pc2), WIFSIGNALED(pc2));
    pc3 = pclose(p3);
    printf("pclose(p3): %d, WIFEXITED: %d, WEXITSTATUS:%d, WIFSIGNALED:%d\n", 
	   pc3, WIFEXITED(pc3), WEXITSTATUS(pc3), WIFSIGNALED(pc3));
}


POPEN(3)            Linux Programmer's Manual            POPEN(3)

NAME
       popen, pclose - process I/O

SYNOPSIS
       #include <stdio.h>

       FILE *popen(const char *command, const char *type);

       int pclose(FILE *stream);

DESCRIPTION
       The  popen()  function opens a process by creating a pipe,
       forking, and invoking the shell.  Since a pipe is by defi-
       nition  unidirectional, the type argument may specify only
       reading or writing, not both; the resulting stream is cor-
       respondingly read-only or write-only.

       The  command  argument  is  a pointer to a null-terminated
       string containing a shell command line.  This  command  is
       passed  to  /bin/sh  using the -c flag; interpretation, if
       any, is performed by the shell.  The mode  argument  is  a
       pointer  to  a null-terminated string which must be either
       `r' for reading or `w' for writing.

       The return value from popen() is  a  normal  standard  I/O
       stream  in  all  respects save that it must be closed with
       pclose() rather than fclose().  Writing to such  a  stream
       writes to the standard input of the command; the command's
       standard output is the same as that of  the  process  that
       called  popen(),  unless  this  is  altered by the command
       itself.  Conversely, reading  from  a  ``popened''  stream
       reads  the  command's  standard  output, and the command's
       standard input is the same as that  of  the  process  that
       called popen.

       Note  that  output  popen  streams  are  fully buffered by
       default.

       The pclose function waits for the  associated  process  to
       terminate  and  returns  the exit status of the command as
       returned by wait4.

RETURN VALUE
       The popen function returns NULL if the fork(2) or  pipe(2)
       calls fail, or if it cannot allocate memory.

       The  pclose function returns -1 if wait4 returns an error,
       or some other error is detected.

ERRORS
       The popen function does not set errno if memory allocation
       fails.  If the underlying fork() or pipe() fails, errno is
       set appropriately.  If the mode argument is  invalid,  and
       this condition is detected, errno is set to EINVAL.

       If  pclose()  cannot obtain the child status, errno is set
       to ECHILD.

CONFORMING TO
       POSIX.2

BUGS
       Since the standard input of a command opened  for  reading
       shares  its  seek  offset  with  the  process  that called
       popen(), if the original process has done a buffered read,
       the command's input position may not be as expected.  Sim-
       ilarly, the output from a command opened for  writing  may
       become  intermingled  with  that  of the original process.
       The latter can be  avoided  by  calling  fflush(3)  before
       popen.

       Failure to execute the shell is indistinguishable from the
       shell's failure to execute command, or an  immediate  exit
       of the command.  The only hint is an exit status of 127.

HISTORY
       A  popen()  and  a pclose() function appeared in Version 7
       AT&T UNIX.

SEE ALSO
       fork(2), sh(1), pipe(2), wait4(2),  fflush(3),  fclose(3),
       fopen(3), stdio(3), system(3).

BSD MANPAGE                 7 May 1998                          1


WAIT4(2)            Linux Programmer's Manual            WAIT4(2)

NAME
       wait3, wait4 - wait for process termination, BSD style

SYNOPSIS
       #define _USE_BSD
       #include <sys/types.h>
       #include <sys/resource.h>
       #include <sys/wait.h>

       pid_t wait3(int *status, int options,
             struct rusage *rusage)

       pid_t wait4(pid_t pid, int *status, int options,
             struct rusage *rusage)

DESCRIPTION
       The  wait3 function suspends execution of the current pro-
       cess until a child has exited, or until a signal is deliv-
       ered  whose  action is to terminate the current process or
       to call a  signal  handling  function.   If  a  child  has
       already  exited by the time of the call (a so-called "zom-
       bie" process), the function returns immediately.  Any sys-
       tem resources used by the child are freed.

       The  wait4 function suspends execution of the current pro-
       cess until a child as specified by the  pid  argument  has
       exited,  or until a signal is delivered whose action is to
       terminate the current process or to call a signal handling
       function.   If  a  child  as  requested by pid has already
       exited by the time of the call (a so-called "zombie"  pro-
       cess),  the  function  returns  immediately.   Any  system
       resources used by the child are freed.

       The value of pid can be one of:

       < -1   which means to wait for  any  child  process  whose
              process  group ID is equal to the absolute value of
              pid.

       -1     which means to wait for any child process; this  is
              equivalent to calling wait3.

       0      which  means  to  wait  for any child process whose
              process group ID is equal to that  of  the  calling
              process.

       > 0    which  means to wait for the child whose process ID
              is equal to the value of pid.

       The value of options is a bitwise OR of zero  or  more  of
       the following constants:

       WNOHANG which  means  to return immediately if no child is
               there to be waited for.

       WUNTRACED
               which means to also return for children which  are
               stopped, and whose status has not been reported.

       If  status is not NULL, wait3 or wait4 store status infor-
       mation in the location pointed to by status.

       This status can be evaluated  with  the  following  macros
       (these macros take the stat buffer (an int) as an argument
       -- not a pointer to the buffer!):

       WIFEXITED(status)
               is non-zero if the child exited normally.

       WEXITSTATUS(status)
               evaluates to the least significant eight  bits  of
               the  return  code  of  the child which terminated,
               which may have been set as the argument to a  call
               to  exit()  or as the argument for a return state-
               ment in the main program.  This macro can only  be
               evaluated if WIFEXITED returned non-zero.

       WIFSIGNALED(status)
               returns  true  if the child process exited because
               of a signal which was not caught.

       WTERMSIG(status)
               returns the number of the signal that  caused  the
               child process to terminate. This macro can only be
               evaluated if WIFSIGNALED returned non-zero.

       WIFSTOPPED(status)
               returns true if the child process which caused the
               return is currently stopped; this is only possible
               if the call was done using WUNTRACED.

       WSTOPSIG(status)
               returns the number of the signal which caused  the
               child  to  stop.  This macro can only be evaluated
               if WIFSTOPPED returned non-zero.

               If rusage  is  not  NULL,  the  struct  rusage  as
               defined  in  <sys/resource.h> it points to will be
               filled   with   accounting    information.     See
               getrusage(2) for details.

RETURN VALUE
       The  process ID of the child which exited, -1 on error (in
       particular, when no unwaited-for child  processes  of  the
       specified  kind  exist) or zero if WNOHANG was used and no
       child was available yet.  In the latter  two  cases  errno
       will be set appropriately.

ERRORS
       ECHILD No  unwaited-for  child  process  as specified does
              exist.

       ERESTARTSYS
              if WNOHANG was not set and an unblocked signal or a
              SIGCHLD  was  caught. This error is returned by the
              system call.  The library interface is not  allowed
              to return ERESTARTSYS, but will return EINTR.

CONFORMING TO
       SVr4, POSIX.1

SEE ALSO
       signal(2), getrusage(2), wait(2), signal(7)

Linux                      23 June 1997                         1

-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
Perhaps a bug or interface change in Linux popen()?
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110702&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:05:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:05:17 -0700
Subject: [Python-bugs-list] [Bug #110830] Syntax (PR#177)
Message-ID: <200009072205.PAA29087@bush.i.sourceforge.net>

Bug #110830, was updated on 2000-Aug-01 14:12
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: Later
Bug Group: Feature Request
Priority: 1
Summary: Syntax (PR#177)

Details: Jitterbug-Id: 177
Submitted-By: simonb@logical.co.za
Date: Tue, 11 Jan 2000 05:17:37 -0500 (EST)
Version: 1-5-2
OS: NT 4.0


Hi there

I don't know if this is a bug, or is intentional behaviour for a specific
reason.

The following code produces a syntax error about the continue not being within a
looping structure rather than a prefectly silly infinite loop...

while 1:
  try:
    continue
  except:
    pass

where the following works as one would expect...

while 1:
  try:
    raise 1
  except:
    continue

I figure that there is more likely a sane reason for this behaviour than being a
bug, but I am curious.

Thanks
Simon



====================================================================
Audit trail:
Wed Jan 12 18:11:45 2000	guido	changed notes
Wed Jan 12 18:11:45 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:12
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] Syntax (PR#177)
Date: Tue, 11 Jan 2000 12:10:17 -0500

[Simon Barratt, putting "continue" in a "try" block]
> I don't know if this is a bug, or is intentional behaviour
> for a specific reason.

Actually, it's a bit of both <wink>.  See the Language Reference Manual's
section on the "continue" statement, particularly the footnote:

    The restriction on occurring in the try clause is
    implementer's laziness and will eventually be lifted.

It's been this way (and documented) forever; it's simply hard to implement
given the current structure of the interpreter loop.

Rest assured there's nothing *conceptually* wrong with putting continue in a
try!  It's simply an implementation restriction; the error msg should
probably make that clearer.  IIRC, JPython doesn't have this restriction.
"Someday" it will get repaired in CPython too.



-------------------------------------------------------

Date: 2000-Aug-01 14:12
By: none

Comment:
It's a zero-priority bug (i.e. not likely to be fixed).

-------------------------------------------------------

Date: 2000-Aug-03 13:00
By: twouters

Comment:
Like the bot said, low priority 'to be fixed' bug.

-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110830&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:05:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:05:16 -0700
Subject: [Python-bugs-list] [Bug #110707] does not compile under BSDI (PR#57)
Message-ID: <200009072205.PAA29083@bush.i.sourceforge.net>

Bug #110707, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: does not compile under BSDI (PR#57)

Details: Jitterbug-Id: 57
Submitted-By: jital@knoggin.com
Date: Fri, 20 Aug 1999 04:18:04 -0400 (EDT)
Version: py152
OS: BSDI IServer


seems to think it is a NeXT arch or something



$ ./configure --prefix=/usr/home/knoggin/usr/local/
--exec-prefix=/usr/home/knoggin/usr/local/

creating cache ./config.cache
checking MACHDEP... bsdos3
checking CCC... 
checking for --without-gcc... no
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking LINKCC... $(PURIFY) $(CC)
checking LDLIBRARY... 
checking for ranlib... ranlib
checking for ar... ar
checking how to run the C preprocessor... gcc -D_HAVE_BSDI -E
checking for AIX... no
checking for minix/config.h... no
checking whether gcc -D_HAVE_BSDI accepts -OPT:Olimit=0... no
checking whether gcc -D_HAVE_BSDI accepts -Olimit 1500... no
checking for C preprocessor type... ansi
checking for ANSI C header files... yes
checking for dlfcn.h... yes
checking for fcntl.h... yes
checking for limits.h... yes
checking for locale.h... yes
checking for ncurses.h... yes
checking for pthread.h... yes
checking for signal.h... yes
checking for stdarg.h... yes
checking for stddef.h... yes
checking for stdlib.h... yes
checking for thread.h... no
checking for unistd.h... yes
checking for utime.h... yes
checking for sys/audioio.h... no
checking for sys/file.h... yes
checking for sys/lock.h... yes
checking for sys/param.h... yes
checking for sys/select.h... yes
checking for sys/time.h... yes
checking for sys/times.h... yes
checking for sys/un.h... yes
checking for sys/utsname.h... yes
checking for sys/wait.h... yes
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking for clock_t in time.h... yes
checking for mode_t... yes
checking for off_t... yes
checking for pid_t... yes
checking return type of signal handlers... void
checking for size_t... yes
checking for uid_t in sys/types.h... yes
checking size of int... 4
checking size of long... 4
checking size of void *... 4
checking for long long support... yes
checking size of long long... 8
checking size of off_t... 8
checking whether to enable large file support... yes
checking for --with-next-framework... no
checking for --with-dyld... required for framework build
checking SO... .so
checking LDSHARED... ld
checking CCSHARED... 
checking LINKFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for t_open in -lnsl... no
checking for socket in -lsocket... no
checking for socket in -lnet... no
checking for --with-libs... no
checking for --with(out)-readline... not specified.
checking for --with-dec-threads... no
checking for --with-threads... no
checking for --with-thread... no
checking for --with-sgi-dl... no
checking for --with-dl-dld... no
checking for alarm... yes
checking for chown... yes
checking for clock... yes
checking for dlopen... yes
checking for execv... yes
checking for flock... yes
checking for fork... yes
checking for fsync... yes
checking for fdatasync... no
checking for ftime... no
checking for ftruncate... yes
checking for getpeername... yes
checking for getpgrp... yes
checking for getpid... yes
checking for getpwent... yes
checking for gettimeofday... yes
checking for getwd... yes
checking for kill... yes
checking for link... yes
checking for lstat... yes
checking for mkfifo... yes
checking for mktime... yes
checking for nice... yes
checking for pause... yes
checking for plock... no
checking for pthread_init... yes
checking for putenv... yes
checking for readlink... yes
checking for select... yes
checking for setgid... yes
checking for setlocale... yes
checking for setuid... yes
checking for setsid... yes
checking for setpgid... yes
checking for setpgrp... yes
checking for setvbuf... yes
checking for sigaction... yes
checking for siginterrupt... yes
checking for sigrelse... no
checking for strftime... yes
checking for strptime... no
checking for symlink... yes
checking for tcgetpgrp... yes
checking for tcsetpgrp... yes
checking for timegm... no
checking for times... yes
checking for truncate... yes
checking for uname... yes
checking for waitpid... yes
checking for fseek64... no
checking for fseeko... no
checking for fstatvfs... no
checking for ftell64... no
checking for ftello... no
checking for statvfs... no
checking for dup2... yes
checking for getcwd... yes
checking for strdup... yes
checking for strerror... yes
checking for memmove... yes
checking for getpgrp... (cached) yes
checking for setpgrp... (cached) yes
checking for gettimeofday... (cached) yes
checking whether time.h and sys/time.h may both be included... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for tm_zone in struct tm... yes
checking for time.h that defines altzone... no
checking whether sys/select.h and sys/time.h may both be included... yes
checking whether char is unsigned... no
checking for working const... yes
checking for working volatile... yes
checking for working signed char... yes
checking for prototypes... yes
checking for variable length prototypes and stdarg.h... yes
checking for bad exec* prototypes... no
checking for bad static forward... no
checking whether va_list is an array... no
checking for gethostbyname_r... no
checking for gethostbyname... yes
checking for __fpu_control in -lieee... no
checking for --with-fpectl... checking for --with-libm=STRING... default
LIBM="-
lm"
checking for --with-libc=STRING... default LIBC=""
checking for hypot... yes
checking for hypot... (cached) yes
checking for genuine getopt... yes
checking what malloc(0) returns... nonnull
updating cache ./config.cache
creating ./config.status
creating Makefile
creating Objects/Makefile
creating Parser/Makefile
creating Python/Makefile
creating Modules/Makefile.pre
creating Modules/Setup.thread
creating config.h
pcvendor:~/usr/local/src/Python-1.5.2 $ make
(cd Modules; make -f Makefile.pre Makefile)
cp ./Setup.in Setup
echo "# Edit this file for local setup changes" >Setup.local
rm -f ../libpython1.5.a
/bin/sh ./makesetup Setup.thread Setup.local Setup
making Makefile in subdirectory .
`Makefile' is up to date.
making Makefile in subdirectory Parser
`Makefile' is up to date.
making Makefile in subdirectory Objects
`Makefile' is up to date.
making Makefile in subdirectory Python
`Makefile' is up to date.
making Makefile in subdirectory Modules
`Makefile' is up to date.
(rm -f Modules/hassignal; cd Modules; make hassignal)
rm -f hassignal
for i in regexmodule.o regexpr.o  pcremodule.o pypcre.o  posixmodule.o 
signalmo
dule.o  arraymodule.o  cmathmodule.o  mathmodule.o  stropmodule.o 
structmodule.
o  timemodule.o  operator.o  fcntlmodule.o  pwdmodule.o  grpmodule.o 
selectmodu
le.o  socketmodule.o  errnomodule.o  md5module.o md5c.o  shamodule.o 
rotormodul
e.o  newmodule.o  binascii.o  parsermodule.o  cStringIO.o  cPickle.o config.o
ge
tpath.o main.o getbuildinfo.o; do  if test "$i" = "signalmodule.o"; then  echo
y
es >hassignal; break;  fi;  done
cd Parser ; make OPT="-g -O2" VERSION="1.5" 
prefix="/usr/home/knoggin/usr/local
/" exec_prefix="/usr/home/knoggin/usr/local/" all
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c pgenmain.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c acceler.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar1.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c listnode.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c node.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c parser.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c parsetok.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c tokenizer.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bitset.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c metagrammar.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c firstsets.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c pgen.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c printgrammar.c
gcc -D_HAVE_BSDI -g -O2 pgenmain.o acceler.o grammar1.o  listnode.o node.o
parse
r.o  parsetok.o tokenizer.o bitset.o  metagrammar.o firstsets.o grammar.o
pgen.o
 printgrammar.o -ldl -o pgen
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c myreadline.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c intrcheck.c
cd Objects ; make OPT="-g -O2" VERSION="1.5" 
prefix="/usr/home/knoggin/usr/local/" exec_prefix="/usr/home/knoggin/usr/local/"
all
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c abstract.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c cobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c complexobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c fileobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c floatobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frameobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c funcobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c intobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c listobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c longobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c dictobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c moduleobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c object.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c rangeobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c sliceobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c stringobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c tupleobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c typeobject.c
cd Python ; make OPT="-g -O2" VERSION="1.5" 
prefix="/usr/home/knoggin/usr/local/" exec_prefix="/usr/home/knoggin/usr/local/"
all
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bltinmodule.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ceval.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c compile.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c errors.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frozen.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frozenmain.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getargs.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getcompiler.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getcopyright.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getmtime.c
gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H
-DPLATFORM='"bsdos3"'  ./getplatform.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getversion.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c graminit.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c import.c
gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c
./importdl.c:269: mach-o/dyld.h: No such file or directory
*** Error code 1

Stop.
*** Error code 1

Stop.



====================================================================
Audit trail:
Mon Aug 30 12:40:26 1999	guido	changed notes
Mon Aug 30 12:40:26 1999	guido	moved from incoming to irreproducible
Tue Oct 19 23:20:49 1999	guido	sent reply 1
Tue Oct 19 23:21:36 1999	guido	changed notes
Tue Oct 19 23:21:36 1999	guido	moved from irreproducible to open
Tue Oct 19 23:30:25 1999	guido	changed notes
Tue Oct 19 23:30:25 1999	guido	moved from open to platformbug

Follow-Ups:

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: does not compile under BSDI (PR#57)
Date: Tue Oct 19 23:20:49 1999

This same bug was reported by someone else for the same platform.

We arrived at the work-around of deleting the line

#define WITH_DYLD

from the config.h generated by the configure script.

If you are still experiencing problems building Python, please
try this.

--Guido van Rossum

-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] does not compile under BSDI (PR#57)
Date: Fri, 20 Aug 1999 07:57:10 -0400

> Full_Name: John Ital
> Version: py152
> OS: BSDI IServer
> 
> seems to think it is a NeXT arch or something
>
[...]
> gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c
> ./importdl.c:269: mach-o/dyld.h: No such file or directory
> *** Error code 1

Very strange.  I've never seen this before.  It appears that somehow
USE_DYLD is defined at that point, which can only happen if WITH_DYLD
is defined, which can only happen if you specify --with-next-framework
or --with-dyld on the configure command line, which you didn't.

Perhaps you have a buggy preprocessor that is confused by the tangle
of #ifdefs in importdl.c?

I don't know how to help you; I know Python has been built
successfully on bsdos3 before, so I'm guessing it's something in your
setup, not a Python bug.

If you need more help, please ask a newsgroup -- either
comp.lang.python or a BSD specific one.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
Work-around: if you delete
 #define WITH_DYLD
from config.h, the build succeeds.

-------------------------------------------------------

Date: 2000-Aug-03 09:00
By: twouters

Comment:
For the record, I cannot reproduce this on the BSDI 3.1 systems we still have lying around. It *might* have been specific to BSDI 3.0, which we no longer have (for various reasons, like y2k bugs ;) and I've heard similar (but not the same) reports about BSD/OS running under a 'virtual' machine. However, I've never seen or heard about those 'virtual' BSD/OSes, other than in that c.l.py posting.



-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110707&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:05:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:05:19 -0700
Subject: [Python-bugs-list] [Bug #110853] Segmentation fault with kernel 2.2.12 (PR#103)
Message-ID: <200009072205.PAA29095@bush.i.sourceforge.net>

Bug #110853, was updated on 2000-Aug-01 14:37
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Irreproducible
Priority: 1
Summary: Segmentation fault with kernel 2.2.12 (PR#103)

Details: Jitterbug-Id: 103
Submitted-By: apsteffe@netwood.net
Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT)
Version: 1.5.2
OS: Linux


I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 .  When I try to
 execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault.
The functions work ok with kernel 1.2.13 .



====================================================================
Audit trail:
Mon Oct 18 18:08:00 1999	guido	changed notes
Mon Oct 18 18:08:00 1999	guido	changed notification
Mon Oct 18 18:08:00 1999	guido	moved from incoming to irreproducible

Follow-Ups:

Date: 2000-Aug-01 14:37
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Segmentation fault with kernel 2.2.12 (PR#103)
Date: Mon, 11 Oct 1999 23:09:13 -0400

> Full_Name: Alfred Steffens Jr.
> Version: 1.5.2
> OS: Linux
> Submission from: p138.netwood.net (209.247.185.38)
> 
> I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 .  When I try to
>  execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault.
> The functions work ok with kernel 1.2.13 .

The Linux and glibc kernel versions don't mean much to me.  Can you
fire up a debugger and see where in the C code it crashes?  Also, is
this for a specific URL or is it for any URL?  If a specific URL, I'd
like to know which one.

Finally, did you get or build the Python executable matching your
kernel?  A Linux upgrade from 1.x to 2.x seems a big deal, it's
possible that you'll need a new Python installation or build.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:37
By: none

Comment:
Probably caused by a huge jump in Linux kernel version without recompiling
Python.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110853&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:05:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:05:18 -0700
Subject: [Python-bugs-list] [Bug #110841] idle dosnt recompile modules changed externally (PR#308)
Message-ID: <200009072205.PAA29091@bush.i.sourceforge.net>

Bug #110841, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 3
Summary: idle dosnt recompile modules changed externally (PR#308)

Details: Jitterbug-Id: 308
Submitted-By: jnc@ecs.soton.ac.uk
Date: Fri, 28 Apr 2000 13:41:55 -0400 (EDT)
Version: 1.5.2
OS: windows 98


Consider two scripts

showbug.py
=====

import bug1

bug1.bug()
=====
and bug1.py
=====
def bug():
    print 'Bug 5'
=====

both in the same directory.

load showbug.py into idle (0.5) and runit with F5,

the bug function prints Bug 5

Now change bug1.py outside or even with idle, save it. 
dates on disk now show bug1.py is newer than bug1.pyc

rerun showbug.py pressing F5 or ctrl-F5

it still prints Bug 5.

I dont think this behaviour is what is required.Certainly it cost me most
of the afternoon tracking down non-existant problems in my code.

John Carter



====================================================================
Audit trail:
Mon May 22 17:23:04 2000	guido	changed notes
Mon May 22 17:23:04 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:15
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] idle dosnt recompile modules changed externally (PR#308)
Date: Fri, 28 Apr 2000 14:45:30 -0400

> Consider two scripts
> 
> showbug.py
> =====
> 
> import bug1
> 
> bug1.bug()
> =====
> and bug1.py
> =====
> def bug():
>     print 'Bug 5'
> =====
> 
> both in the same directory.
> 
> load showbug.py into idle (0.5) and runit with F5,
> 
> the bug function prints Bug 5
> 
> Now change bug1.py outside or even with idle, save it. 
> dates on disk now show bug1.py is newer than bug1.pyc
> 
> rerun showbug.py pressing F5 or ctrl-F5
> 
> it still prints Bug 5.
> 
> I dont think this behaviour is what is required.Certainly it cost me most
> of the afternoon tracking down non-existant problems in my code.

I appreciate the bug report.  The current definitions of running a
script and importing a module all conspire to get this behavior.
We're working on a major change where IDLE executes your script in a
separate process that is created from scratch each time you use
[ctrl-]F5, and then it will go away.

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-01 14:15
By: none

Comment:
This is all explainable, but I agree it's bad for the user.
We'll fix it by running scripts in a new process.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110841&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:05:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:05:33 -0700
Subject: [Python-bugs-list] [Bug #112317] os.rename transparent handling of cross-filesystem issues
Message-ID: <200009072205.PAA29103@bush.i.sourceforge.net>

Bug #112317, was updated on 2000-Aug-19 10:09
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 3
Summary: os.rename transparent handling of cross-filesystem issues

Details: On some systems (specifically, Linux), the rename system call will throw
an EXDEV error if rename is used across filesystems.  It would be convenient for the user if os.rename were extended to handle this transparently (like most mv commands do).

The benefits of this. . .getting rid of code like the following:

try:
    os.rename('ff','/tmp/ff')
except:
    open('/tmp/ff','w').write(open('ff','r').read())
    os.unlink('ff')

Actually, the real benefit is that code (written by morons like myself) using os.rename will continue to work even after the administrator moves the target directory to another filesystem.

I took a quick look at posixmodule.c.  A quick hack changes posix_2str's
signature to the following:

PyObject *args
char *format
int (*func)(const char*, const char *)
int (*special_handler)(const char *, const char *)

and the inner function to:

if (res != 0)
    if ((! special_handler) || (*special_handler)(path1,path2))
         return posix_error()

Of course, then a smart copy routine (includes an unlink step).  The most unclear thing at this point is what to do with the errno.  Would a failure in
the errorhandler report the original errno or its own errno???

Personally, a more general solution would allow the user (python-level) to optionally pass in *their own* error handling function/method.




Follow-Ups:

Date: 2000-Aug-25 07:44
By: jhylton

Comment:
revisit this after 2.0

-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112317&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:05:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:05:34 -0700
Subject: [Python-bugs-list] [Bug #113696] lib.pdf damaged in pdf-a4-2.0b1.tgz
Message-ID: <200009072205.PAA29107@bush.i.sourceforge.net>

Bug #113696, was updated on 2000-Sep-06 06:01
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: lib.pdf damaged in pdf-a4-2.0b1.tgz

Details: Platform: NT4 SP6, Acrobat Reader 4.05.

Tarball unpacks correctly and every other .pdf
file in it is fine; however, lib.pdf appears to
be corrupt, "can&#039;t repair", according to the
Acrobat Reader.

Follow-Ups:

Date: 2000-Sep-06 06:18
By: aleax

Comment:
Same problem with lib.pdf (only) after downloading the
ZIP, and also in the Letter versions as opposed to A4.

-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113696&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:05:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:05:36 -0700
Subject: [Python-bugs-list] [Bug #113779] test_gc coredump on Alpha
Message-ID: <200009072205.PAA29110@bush.i.sourceforge.net>

Bug #113779, was updated on 2000-Sep-06 21:44
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: test_gc coredump on Alpha

Details: Configured --with-cycle-gc --with-sigfpe

gc: collectable <list 0x12043d158>
gc: collectable <dictionary 0x12043d1d8>
gc: collectable <list 0x12043d158>
gc: collectable <tuple 0x12043d198>
gc: collectable <class 0x12043d218>
gc: collectable <dictionary 0x12043d278>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d2c8>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d328>
gc: collectable <instance method 0x12043d378>
gc: collectable <B instance at 0x12043d6b8>
gc: collectable <dictionary 0x12043d6f8>
gc: uncollectable <dictionary 0x12043d5f8>
gc: uncollectable <A instance at 0x12043d158>
Segmentation fault (core dumped)

gdb reports:

Core was generated by `./python -tt Lib/test/regrtest.py -l -v test_gc'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2.1...done.
Reading symbols from /lib/libutil.so.1.1...done.
Reading symbols from /lib/libm.so.6.1...done.
Reading symbols from /lib/libc.so.6.1...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
168             if (!PyList_Check(op)) {
(gdb) where
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
#1  0x120085fac in handle_finalizers (finalizers=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:312
#2  0x1200862d8 in collect (young=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:438
#3  0x120086704 in gc_collect (self=0x100000000, args=0x12043d158)
    at ./gcmodule.c:588
#4  0x120018ef0 in call_builtin (func=0x1, arg=0x12039e258, kw=0x0)
    at ceval.c:2628
#5  0x120018d30 in PyEval_CallObjectWithKeywords (func=0x1204377c0, 
    arg=0x12039e258, kw=0x0) at ceval.c:2596
#6  0x12001713c in eval_code2 (co=0x12043b890, globals=0x12043d158, 
    locals=0x120370488, args=0xffffffffffffffff, argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1929
#7  0x120016cc4 in eval_code2 (co=0x12043c400, globals=0x12043d158, 
    locals=0x120370488, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
...

(gdb) print op
$1 = (PyObject *) 0x100000000
(gdb) print newitem
$2 = (PyObject *) 0x12043d158



Follow-Ups:

Date: 2000-Sep-06 21:49
By: none

Comment:
Note that without -l to regrtest it does NOT dump core,
and completes correctly.

-------------------------------------------------------

Date: 2000-Sep-07 08:23
By: bwarsaw

Comment:
It could just be a bug in the debug printing of collected objects.  The -l switch for the regrtest simply adds a call to gc.set_debug(gc.DEBUG_LEAK) before the rest of the tests get going.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113779&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:06:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:06:52 -0700
Subject: [Python-bugs-list] [Bug #113773] Python 2.0b1 selectmodule compile error under Redhat 5.2
Message-ID: <200009072206.PAA29175@bush.i.sourceforge.net>

Bug #113773, was updated on 2000-Sep-06 18:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0b1 selectmodule compile error under Redhat 5.2

Details: Environment: Redhat 5.2 running the gcc compiler that comes with the
distribution (gcc 2.7.2.3).

'make' failed when compiling selectmodule.c ('./configure' ran ok)because
the following constants were undefined:

POLLRDNORM, POLLRDBAND, POLLWRBAND

The /usr/include/sys/poll.h file does not contain these constants.
Under Redhat 6.2 the constants are defined in the /usr/include/bits/poll.h
file (which is not present in the Redhat 5.2 distribution).

I used the Redhat 6.2 poll.h file and the selectmodule compiled (under
Redhat 5.2) but got the following error when running 
'make test' (it looks like it might be related to the compile problem):

test test_poll crashed -- select.error: (9, 'Bad file descriptor')

1 test failed: test_poll



Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113773&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:06:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:06:51 -0700
Subject: [Python-bugs-list] [Bug #113693] freeze modulefinder broken
Message-ID: <200009072206.PAA29172@bush.i.sourceforge.net>

Bug #113693, was updated on 2000-Sep-06 05:09
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: freeze modulefinder broken

Details: The following one-liner script can not be frozen:

import string

The traceback is included below. Line number are from revision 1.13 of modulefinder.py.

The problem appears to be related to recent changes to the import bytecodes

Traceback (most recent call last):
  File "d:\python\tools\freeze\freeze.py", line 457, in ?
    main()
  File "d:\python\tools\freeze\freeze.py", line 321, in main
    mf.import_hook(mod)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 281, in scan_code
    self.import_hook(name, m)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 281, in scan_code
    self.import_hook(name, m)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 303, in scan_code
    self.scan_code(c, m)
  File "d:\python\tools\freeze\modulefinder.py", line 281, in scan_code
    self.import_hook(name, m)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 289, in scan_code
    assert lastname is not None
AssertionError

Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113693&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:06:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:06:46 -0700
Subject: [Python-bugs-list] [Bug #112244] time.strptime() not present in Python 1.5.2 for MSWin
Message-ID: <200009072206.PAA29169@bush.i.sourceforge.net>

Bug #112244, was updated on 2000-Aug-18 06:54
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 3
Summary: time.strptime() not present in Python 1.5.2 for MSWin

Details: Using Python 1.5.2 for MSWin, any attempt to use the time.strptime() function from the time module results in the error:
AttributeError: strptime

This error does not occur for the Unix version of Python 1.5.2.


Follow-Ups:

Date: 2000-Aug-18 10:38
By: tim_one

Comment:
Changed to group Feature Request.
strptime is available from Python only on those platforms where this (non-standard) C function happens to be available from the platform C library.  Windows is not one of those.  Not all Unix versions have it either.  The docs already say that.  The only way it will become available is if someone contributes an implementation.

-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112244&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:08:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:08:52 -0700
Subject: [Python-bugs-list] [Bug #110683] can't compile with SSL support on WinNT (PR#403)
Message-ID: <200009072208.PAA29208@bush.i.sourceforge.net>

Bug #110683, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: Later
Bug Group: Platform-specific
Priority: 4
Summary: can't compile with SSL support on WinNT (PR#403)

Details: Jitterbug-Id: 403
Submitted-By: falk.lehmann@gmx.net
Date: Mon, 17 Jul 2000 21:59:56 -0400 (EDT)
Version: 1.6a2
OS: WinNT 4.0


I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00.
The compiler stops with some warnings and an error message:
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2081) : error C2099: initializer
is not a constant

K:\Projects\Python-1.6a2\Modules\socketmodule.c(1947) : warning C4047:
'function' : 'int ' differs in levels of indirection from 'void *'
K:\Projects\Python-1.6a2\Modules\socketmodule.c(1947) : warning C4024: 'memset'
: different types for formal and actual parameter 2
K:\Projects\Python-1.6a2\Modules\socketmodule.c(1948) : warning C4047:
'function' : 'int ' differs in levels of indirection from 'void *'
K:\Projects\Python-1.6a2\Modules\socketmodule.c(1948) : warning C4024: 'memset'
: different types for formal and actual parameter 2
K:\Projects\Python-1.6a2\Modules\socketmodule.c(1933) : warning C4101: 'str' :
unreferenced local variable
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2083) : warning C4047:
'initializing' : 'int ' differs in levels of indirection from 'char [4]'
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2084) : warning C4047:
'initializing' : 'char *' differs in levels of indirection from 'unsigned int '
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2087) : warning C4047:
'initializing' : 'int ' differs in levels of indirection from 'void (__cdecl
*)(struct _object *)'
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2089) : warning C4047:
'initializing' : 'int (__cdecl *)(struct _object *,struct _iobuf *,int )'
differs in levels of indirection from 'struct _object *(__cdecl *)(struct
_object *,char *)'

Thanks in advance for fixing (at least the error).

Falk



====================================================================
Audit trail:
Tue Jul 25 07:25:55 2000	guido	changed notes
Tue Jul 25 07:25:55 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Guido van Rossum <guido@beopen.com>
Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403)
Date: Mon, 24 Jul 2000 11:35:24 -0500

> I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00.

Please try the current CVS tree (on its way to 2.0); we have no
problems compiling this on VC 6.0.

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-01 14:02
By: none

Comment:
From: Falk Lehmann <Falk.Lehmann@gmx.net>
Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403)
Date: Mon, 24 Jul 2000 13:46:45 -0500

[magical fwd by GvR]

Guido,
sorry, but forgot to write, that I switched on the USE_SSL macro.
And then the _socket module does not compile.

Falk

> > I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00.
> 
> Please try the current CVS tree (on its way to 2.0); we have no
> problems compiling this on VC 6.0.
> 
> --Guido van Rossum (home page: http://dinsdale.python.org/~guido/)
> 


-------------------------------------------------------

Date: 2000-Aug-01 14:02
By: none

Comment:
From: Guido van Rossum <guido@beopen.com>
Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403)
Date: Mon, 24 Jul 2000 14:00:20 -0500

> sorry, but forgot to write, that I switched on the USE_SSL macro.
> And then the _socket module does not compile.

It appears that the Python SSL code hasn't been ported to Windows.
We'll add this to our TODO list, but it's low priority...  Perhaps you
could give it a shot yourself?  See www.python.org/patches/ for how to
contribute.

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-01 14:02
By: none

Comment:
Windows compile fails when using openSSL.
-------------------------------------------------------

Date: 2000-Aug-23 10:35
By: jhylton

Comment:
This is a bug.  Standard extensions modules should compile, even on obscure platforms like Windows NT.  Need a Windows user with time to install OpenSSL to fix this.

-------------------------------------------------------

Date: 2000-Aug-30 12:01
By: gvanrossum

Comment:
Let's not worry about this for 2.0. While the OpenSSL support is part of the socket module, we don't have the resources right now to port that support to Windows.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 15:08
By: fdrake

Comment:
As we've discussed, this is not an issue for 2.0.  Assigned to Tim for resurrection when appropriate since this is Windows-specific. 
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110683&group_id=5470


From aleaxit@yahoo.com  Thu Sep  7 23:10:05 2000
From: aleaxit@yahoo.com (Alex Martelli)
Date: Fri, 8 Sep 2000 00:10:05 +0200
Subject: [Python-bugs-list] Re: [Bug #113807] PyArg_ParseTupleAndKeywords and Unicode...?
References: <200009072203.PAA28857@bush.i.sourceforge.net>
Message-ID: <02ec01c01918$7c2ce380$aca1abd4@martelli>

> Date: 2000-Sep-07 15:03
> By: jhylton
> 
> Comment:
> Please do triage on this bug.

Sorry, I don't understand what "triage" means in
this context.  Want a small extension that will
reproduce the bug?  I can do that -- two functions
each taking a es# format argument, one without
kw args, one with, otherwise identical.  Would that
be useful?  Where should I send the source code
to reproduce the bug?


Alex



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



From fdrake@beopen.com  Thu Sep  7 23:14:09 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Thu, 7 Sep 2000 18:14:09 -0400 (EDT)
Subject: [Python-bugs-list] Re: [Bug #113807] PyArg_ParseTupleAndKeywords and Unicode...?
In-Reply-To: <02ec01c01918$7c2ce380$aca1abd4@martelli>
References: <200009072203.PAA28857@bush.i.sourceforge.net>
 <02ec01c01918$7c2ce380$aca1abd4@martelli>
Message-ID: <14776.4913.209019.358778@cj42289-a.reston1.va.home.com>

Alex Martelli writes:
 > > Date: 2000-Sep-07 15:03
 > > By: jhylton
 > > 
 > > Comment:
 > > Please do triage on this bug.
 > 
 > Sorry, I don't understand what "triage" means in
 > this context.  Want a small extension that will
 > reproduce the bug?  I can do that -- two functions
 > each taking a es# format argument, one without
 > kw args, one with, otherwise identical.  Would that
 > be useful?  Where should I send the source code
 > to reproduce the bug?

Alex,
  Sorry for the confusion!  We've assigned all the bugs to a developer
so that each is examined and dealt with in some way.  This message is
for the developer the bug report was assigned to; you don't need to do
anything further based on this notice.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From noreply@sourceforge.net  Thu Sep  7 23:52:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:52:09 -0700
Subject: [Python-bugs-list] [Bug #113800] optional{} produces incorrect HTML
Message-ID: <200009072252.PAA30726@bush.i.sourceforge.net>

Bug #113800, was updated on 2000-Sep-07 08:18
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: optional{} produces incorrect HTML

Details: This showed up in the Python 2.0 document: LaTeX2HTML
produces bad HTML with improperly nested tags, including a trailing <var> tag that leaves the rest of the document in italic on some browsers.  Sample document:

\documentclass{howto}
 
\title{What's New in Python 2.0}
\release{0.05}
\author{A.M. Kuchling and Moshe Zadka}
\authoraddress{\email{amk1@bigfoot.com}, \email{moshez@math.huji.ac.il} }
 
\begin{document}
 
\code{unicode(\var{string} \optional{, \var{encoding}}
\optional{, \var{errors}} ) } creates a Unicode string from an 8-bit
 
\end{document}  

The incorrect HTML output is:

<code>unicode(<var>string</var> </var><big>[</big><var>, <var>encoding</var></var><big>]</big><big>[</big><var>, <var>errors</var></var><big>]</big><var> ) </code> creates ...

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113800&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:53:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:53:34 -0700
Subject: [Python-bugs-list] [Bug #113793] getopt.c compile fails on Solaris 2.6/gcc 2.95.2
Message-ID: <200009072253.PAA30797@bush.i.sourceforge.net>

Bug #113793, was updated on 2000-Sep-07 06:09
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: getopt.c compile fails on Solaris 2.6/gcc 2.95.2

Details: I configured python with the following options:
/ldatae/Misc/python/Python-1.6/configure  --program-prefix=g --target=sparc-su
n-solaris2.6 --prefix=/projects/gnu/sparc-sun-solaris2.6 --exec-prefix=/projects
/gnu/sparc-sun-solaris2.6 --with-gnu-gettext --with-rx --with-curses=/projects/g
nu/sparc-sun-solaris2.6/lib --with-shared --with-profile --enable-nls --x-includ
es=/usr/openwin/include --x-libraries=/usr/openwin/lib --with-wctype-functions -
-with-x-toolkit=motif --with-x --with-threads
After compiling for a while, the build stops with this error:

gcc -g -O2 -I/ldatae/Misc/python/Python-1.6/Python/../Include -I.. -DHAVE_CONFIG
_H   -c -o getopt.o getopt.c
getopt.c: In function `getopt':
getopt.c:51: argument `argv' doesn't match prototype
/usr/include/stdio.h:329: prototype declaration
getopt.c:51: argument `optstring' doesn't match prototype
/usr/include/stdio.h:329: prototype declaration
make[1]: *** [getopt.o] Error 1
make[1]: Leaving directory `/ldatae/Misc/python/Python-1.6/Python'
make: *** [Python] Error 


I can supply more details if someone emails me at lvirden@cas.org .

Thank you.

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113793&group_id=5470


From noreply@sourceforge.net  Thu Sep  7 23:58:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 15:58:42 -0700
Subject: [Python-bugs-list] [Bug #113576] Py_PROTO missing from the include files
Message-ID: <200009072258.PAA30973@bush.i.sourceforge.net>

Bug #113576, was updated on 2000-Sep-04 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: Py_PROTO missing from the include files

Details: Some old extensions still use the Py_PROTO() macro which was
present in Python 1.5.2 and ealier. After the ANSIfication of the sources,
this macro seems to have been removed from the Python include
files.

This breaks all extensions which used the macro.

Adding a 
#define Py_PROTO(args)       args
to pyport.h should remedy this.

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 15:58
By: jhylton

Comment:
Sounds reasonable to me.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113576&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 00:02:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 16:02:45 -0700
Subject: [Python-bugs-list] [Bug #113760] 2.0b1: _xmlplus does not allow site xml to override Lib/xml
Message-ID: <200009072302.QAA31134@bush.i.sourceforge.net>

Bug #113760, was updated on 2000-Sep-06 16:53
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: 2.0b1: _xmlplus does not allow site xml to override Lib/xml

Details: _xmlplus is represented as a means of overriding the new standard lib xml package with a user-supplied xml package, such as the one from XML-SIG ("There's a special feature whereby a user-installed package named _xmlplus overrides the standard xmlpackage; this is intended to give the XML SIG a hook to distribute backwards-compatible updates to the standard xml package." - quote from News on BeOpen site). While this has _some_ effect, it does not work as described. Under 2.0b1, code using the xml package from the XML-SIG (installed in site-packages) will only work if the new standard xml package in lib is renamed or removed. If used with the new standard xml package, imports such as
from xml.sax import saxexts
fail. If the _xmlplus hook is used (by renaming site-packages/xml to site-packages/_xmlplus or using a symlink), the imports succeed, but later the code fails with a message stating that no parsers can be found. 

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113760&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 00:12:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 16:12:42 -0700
Subject: [Python-bugs-list] [Bug #113760] 2.0b1: _xmlplus does not allow site xml to override Lib/xml
Message-ID: <200009072312.QAA05438@delerium.i.sourceforge.net>

Bug #113760, was updated on 2000-Sep-06 16:53
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: 2.0b1: _xmlplus does not allow site xml to override Lib/xml

Details: _xmlplus is represented as a means of overriding the new standard lib xml package with a user-supplied xml package, such as the one from XML-SIG ("There's a special feature whereby a user-installed package named _xmlplus overrides the standard xmlpackage; this is intended to give the XML SIG a hook to distribute backwards-compatible updates to the standard xml package." - quote from News on BeOpen site). While this has _some_ effect, it does not work as described. Under 2.0b1, code using the xml package from the XML-SIG (installed in site-packages) will only work if the new standard xml package in lib is renamed or removed. If used with the new standard xml package, imports such as
from xml.sax import saxexts
fail. If the _xmlplus hook is used (by renaming site-packages/xml to site-packages/_xmlplus or using a symlink), the imports succeed, but later the code fails with a message stating that no parsers can be found. 

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 16:12
By: mfavas

Comment:
Martin v. Loewis has justed posted a link on xml-sig to a patch for the "no parsers can be found" problem. I've applied the patch (by hand - "patch" failed) and all seems OK. Custom, tricky ways of finding/doing imports abound... Wasn't there some talk of tidying-up imports and import hooks? (MvL's patch is at http://sourceforge.net/patch/?func=detailpatch&patch_id=101444&group_id=6473 )
- Mark
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113760&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 00:17:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 16:17:43 -0700
Subject: [Python-bugs-list] [Bug #113760] 2.0b1: _xmlplus does not allow site xml to override Lib/xml
Message-ID: <200009072317.QAA05609@delerium.i.sourceforge.net>

Bug #113760, was updated on 2000-Sep-06 16:53
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: 2.0b1: _xmlplus does not allow site xml to override Lib/xml

Details: _xmlplus is represented as a means of overriding the new standard lib xml package with a user-supplied xml package, such as the one from XML-SIG ("There's a special feature whereby a user-installed package named _xmlplus overrides the standard xmlpackage; this is intended to give the XML SIG a hook to distribute backwards-compatible updates to the standard xml package." - quote from News on BeOpen site). While this has _some_ effect, it does not work as described. Under 2.0b1, code using the xml package from the XML-SIG (installed in site-packages) will only work if the new standard xml package in lib is renamed or removed. If used with the new standard xml package, imports such as
from xml.sax import saxexts
fail. If the _xmlplus hook is used (by renaming site-packages/xml to site-packages/_xmlplus or using a symlink), the imports succeed, but later the code fails with a message stating that no parsers can be found. 

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 16:12
By: mfavas

Comment:
Martin v. Loewis has justed posted a link on xml-sig to a patch for the "no parsers can be found" problem. I've applied the patch (by hand - "patch" failed) and all seems OK. Custom, tricky ways of finding/doing imports abound... Wasn't there some talk of tidying-up imports and import hooks? (MvL's patch is at http://sourceforge.net/patch/?func=detailpatch&patch_id=101444&group_id=6473 )
- Mark
-------------------------------------------------------

Date: 2000-Sep-07 16:17
By: mfavas

Comment:
Martin v. Loewis has justed posted a link on xml-sig to a patch for the "no parsers can be found" problem. I've applied the patch (by hand - "patch" failed) and all seems OK. Custom, tricky ways of finding/doing imports abound... Wasn't there some talk of tidying-up imports and import hooks? (MvL's patch is at http://sourceforge.net/patch/?func=detailpatch&patch_id=101444&group_id=6473 )
- Mark
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113760&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 03:51:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 19:51:00 -0700
Subject: [Python-bugs-list] [Bug #110702] [Linux] closing a popen file descriptor (PR#33)
Message-ID: <200009080251.TAA06407@bush.i.sourceforge.net>

Bug #110702, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Works For Me
Bug Group: Platform-specific
Priority: 5
Summary: [Linux] closing a popen file descriptor (PR#33)

Details: Jitterbug-Id: 33
Submitted-By: laik@cs.stanford.edu
Date: Tue, 20 Jul 1999 14:00:11 -0400 (EDT)
Version: 1.5.2
OS: Linux 2.2.10


I can't close a pipe's file descriptor without an error:

>>> import os
>>> p1 = os.popen("cat dummy1", "r")
>>> p2 = os.popen("cat dummy2", "r")
>>> p1.close()
Traceback (innermost last):
  File "<stdin>", line 1, in ?
IOError: (0, 'Error')

It only happens if I do two or more popens. If I try to close any file
descriptor
but the last one I opened, I get this mysterious IOError. It happens regardless
of the order I try to close the descriptors.



====================================================================
Audit trail:
Sat Jul 24 17:02:54 1999	guido	sent reply 1
Sat Jul 24 17:03:22 1999	guido	changed notes
Sat Jul 24 17:03:22 1999	guido	moved from incoming to open
Sat Jul 24 17:05:25 1999	guido	moved from open to platformbug

Follow-Ups:

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: closing a popen file descriptor (PR#33)
Date: Sat Jul 24 17:02:54 1999

> Full_Name: Kevin Lai
> Version: 1.5.2
> OS: Linux 2.2.10
> Submission from: (NULL) (192.25.214.6)
> 
> 
> I can't close a pipe's file descriptor without an error:
> 
>>>> import os
>>>> p1 = os.popen("cat dummy1", "r")
>>>> p2 = os.popen("cat dummy2", "r")
>>>> p1.close()
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> IOError: (0, 'Error')
> 
> It only happens if I do two or more popens. If I try to close any file
> descriptor
> but the last one I opened, I get this mysterious IOError. It happens
regardless
> of the order I try to close the descriptors.

Kevin, this works on other platforms I can try (Solaris 2.6, linux 2.0.34).
One possibility is that the C library in the Linux version you are using
has changed; the IOError means that its pclose() returns an error indicator.
The (0, 'Error') message means that pclose() didn't set the errno variable.
It could be a bug in the Linux C library, or a change in interface that
requires Python to interpret the error return differently.

Can you help us discover which is the case?  Does the man page for pclose()
say anything about this?  Does this fail in an equivalent C program?

--Guido van Rossum

-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
From: laik@tnt.Stanford.EDU
Subject: Re: closing a popen file descriptor (PR#33)
Date: Tue, 27 Jul 1999 01:41:15 -0700


Guido,

Thanks for your quick reply. As far as I can tell, the man page for
pclose() doesn't mention any API changes. I have included the popen()
and wait4() man pages for the system I am using (PII 300, Linux
2.2.10, glibc 2.1.1). 

I have written a short C program which tries to exercise the bug. On my
system, it gives these results:

[laik@nebraska]~>gcc popen.c
[laik@nebraska]~>a.out
pclose(p1): 0, WIFEXITED: 1, WEXITSTATUS:0, WIFSIGNALED:0
pclose(p2): 0, WIFEXITED: 1, WEXITSTATUS:0, WIFSIGNALED:0
pclose(p3): 0, WIFEXITED: 1, WEXITSTATUS:0, WIFSIGNALED:0

On a Linux 2.0.33, glibc 2.0.7 system, it gives the same
results. However, my system exhibits the problem under Python, while
the other does not. I conclude that my C program doesn't mimic the
Python program well enough to trigger the bug, but I don't know how to
fix that.

#include <stdio.h>
#define _USE_BSD
#include <sys/types.h>
#include <sys/resource.h>
#include <sys/wait.h>

main()
{
    FILE *p1, *p2, *p3;
    int pc1, pc2, pc3;

    p1 = popen("ls", "r");
    p2 = popen("ls", "r");
    p3 = popen("ls", "r");
    sleep(1);
    pc1 = pclose(p1);
    printf("pclose(p1): %d, WIFEXITED: %d, WEXITSTATUS:%d, WIFSIGNALED:%d\n", 
	   pc1, WIFEXITED(pc1), WEXITSTATUS(pc1), WIFSIGNALED(pc1));
    pc2 = pclose(p2);
    printf("pclose(p2): %d, WIFEXITED: %d, WEXITSTATUS:%d, WIFSIGNALED:%d\n", 
	   pc1, WIFEXITED(pc2), WEXITSTATUS(pc2), WIFSIGNALED(pc2));
    pc3 = pclose(p3);
    printf("pclose(p3): %d, WIFEXITED: %d, WEXITSTATUS:%d, WIFSIGNALED:%d\n", 
	   pc3, WIFEXITED(pc3), WEXITSTATUS(pc3), WIFSIGNALED(pc3));
}


POPEN(3)            Linux Programmer's Manual            POPEN(3)

NAME
       popen, pclose - process I/O

SYNOPSIS
       #include <stdio.h>

       FILE *popen(const char *command, const char *type);

       int pclose(FILE *stream);

DESCRIPTION
       The  popen()  function opens a process by creating a pipe,
       forking, and invoking the shell.  Since a pipe is by defi-
       nition  unidirectional, the type argument may specify only
       reading or writing, not both; the resulting stream is cor-
       respondingly read-only or write-only.

       The  command  argument  is  a pointer to a null-terminated
       string containing a shell command line.  This  command  is
       passed  to  /bin/sh  using the -c flag; interpretation, if
       any, is performed by the shell.  The mode  argument  is  a
       pointer  to  a null-terminated string which must be either
       `r' for reading or `w' for writing.

       The return value from popen() is  a  normal  standard  I/O
       stream  in  all  respects save that it must be closed with
       pclose() rather than fclose().  Writing to such  a  stream
       writes to the standard input of the command; the command's
       standard output is the same as that of  the  process  that
       called  popen(),  unless  this  is  altered by the command
       itself.  Conversely, reading  from  a  ``popened''  stream
       reads  the  command's  standard  output, and the command's
       standard input is the same as that  of  the  process  that
       called popen.

       Note  that  output  popen  streams  are  fully buffered by
       default.

       The pclose function waits for the  associated  process  to
       terminate  and  returns  the exit status of the command as
       returned by wait4.

RETURN VALUE
       The popen function returns NULL if the fork(2) or  pipe(2)
       calls fail, or if it cannot allocate memory.

       The  pclose function returns -1 if wait4 returns an error,
       or some other error is detected.

ERRORS
       The popen function does not set errno if memory allocation
       fails.  If the underlying fork() or pipe() fails, errno is
       set appropriately.  If the mode argument is  invalid,  and
       this condition is detected, errno is set to EINVAL.

       If  pclose()  cannot obtain the child status, errno is set
       to ECHILD.

CONFORMING TO
       POSIX.2

BUGS
       Since the standard input of a command opened  for  reading
       shares  its  seek  offset  with  the  process  that called
       popen(), if the original process has done a buffered read,
       the command's input position may not be as expected.  Sim-
       ilarly, the output from a command opened for  writing  may
       become  intermingled  with  that  of the original process.
       The latter can be  avoided  by  calling  fflush(3)  before
       popen.

       Failure to execute the shell is indistinguishable from the
       shell's failure to execute command, or an  immediate  exit
       of the command.  The only hint is an exit status of 127.

HISTORY
       A  popen()  and  a pclose() function appeared in Version 7
       AT&T UNIX.

SEE ALSO
       fork(2), sh(1), pipe(2), wait4(2),  fflush(3),  fclose(3),
       fopen(3), stdio(3), system(3).

BSD MANPAGE                 7 May 1998                          1


WAIT4(2)            Linux Programmer's Manual            WAIT4(2)

NAME
       wait3, wait4 - wait for process termination, BSD style

SYNOPSIS
       #define _USE_BSD
       #include <sys/types.h>
       #include <sys/resource.h>
       #include <sys/wait.h>

       pid_t wait3(int *status, int options,
             struct rusage *rusage)

       pid_t wait4(pid_t pid, int *status, int options,
             struct rusage *rusage)

DESCRIPTION
       The  wait3 function suspends execution of the current pro-
       cess until a child has exited, or until a signal is deliv-
       ered  whose  action is to terminate the current process or
       to call a  signal  handling  function.   If  a  child  has
       already  exited by the time of the call (a so-called "zom-
       bie" process), the function returns immediately.  Any sys-
       tem resources used by the child are freed.

       The  wait4 function suspends execution of the current pro-
       cess until a child as specified by the  pid  argument  has
       exited,  or until a signal is delivered whose action is to
       terminate the current process or to call a signal handling
       function.   If  a  child  as  requested by pid has already
       exited by the time of the call (a so-called "zombie"  pro-
       cess),  the  function  returns  immediately.   Any  system
       resources used by the child are freed.

       The value of pid can be one of:

       < -1   which means to wait for  any  child  process  whose
              process  group ID is equal to the absolute value of
              pid.

       -1     which means to wait for any child process; this  is
              equivalent to calling wait3.

       0      which  means  to  wait  for any child process whose
              process group ID is equal to that  of  the  calling
              process.

       > 0    which  means to wait for the child whose process ID
              is equal to the value of pid.

       The value of options is a bitwise OR of zero  or  more  of
       the following constants:

       WNOHANG which  means  to return immediately if no child is
               there to be waited for.

       WUNTRACED
               which means to also return for children which  are
               stopped, and whose status has not been reported.

       If  status is not NULL, wait3 or wait4 store status infor-
       mation in the location pointed to by status.

       This status can be evaluated  with  the  following  macros
       (these macros take the stat buffer (an int) as an argument
       -- not a pointer to the buffer!):

       WIFEXITED(status)
               is non-zero if the child exited normally.

       WEXITSTATUS(status)
               evaluates to the least significant eight  bits  of
               the  return  code  of  the child which terminated,
               which may have been set as the argument to a  call
               to  exit()  or as the argument for a return state-
               ment in the main program.  This macro can only  be
               evaluated if WIFEXITED returned non-zero.

       WIFSIGNALED(status)
               returns  true  if the child process exited because
               of a signal which was not caught.

       WTERMSIG(status)
               returns the number of the signal that  caused  the
               child process to terminate. This macro can only be
               evaluated if WIFSIGNALED returned non-zero.

       WIFSTOPPED(status)
               returns true if the child process which caused the
               return is currently stopped; this is only possible
               if the call was done using WUNTRACED.

       WSTOPSIG(status)
               returns the number of the signal which caused  the
               child  to  stop.  This macro can only be evaluated
               if WIFSTOPPED returned non-zero.

               If rusage  is  not  NULL,  the  struct  rusage  as
               defined  in  <sys/resource.h> it points to will be
               filled   with   accounting    information.     See
               getrusage(2) for details.

RETURN VALUE
       The  process ID of the child which exited, -1 on error (in
       particular, when no unwaited-for child  processes  of  the
       specified  kind  exist) or zero if WNOHANG was used and no
       child was available yet.  In the latter  two  cases  errno
       will be set appropriately.

ERRORS
       ECHILD No  unwaited-for  child  process  as specified does
              exist.

       ERESTARTSYS
              if WNOHANG was not set and an unblocked signal or a
              SIGCHLD  was  caught. This error is returned by the
              system call.  The library interface is not  allowed
              to return ERESTARTSYS, but will return EINTR.

CONFORMING TO
       SVr4, POSIX.1

SEE ALSO
       signal(2), getrusage(2), wait(2), signal(7)

Linux                      23 June 1997                         1

-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
Perhaps a bug or interface change in Linux popen()?
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 19:51
By: fdrake

Comment:
I can't reproduce this on a Linux 2.2.15 kernel (Mandrake 7.1) using Python 2.0beta1.  Will ask the submitter to test with a more recent Python and request a re-open of the report if the problem persists.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110702&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 03:56:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 19:56:00 -0700
Subject: [Python-bugs-list] [Bug #113696] lib.pdf damaged in pdf-a4-2.0b1.tgz
Message-ID: <200009080256.TAA06574@bush.i.sourceforge.net>

Bug #113696, was updated on 2000-Sep-06 06:01
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: lib.pdf damaged in pdf-a4-2.0b1.tgz

Details: Platform: NT4 SP6, Acrobat Reader 4.05.

Tarball unpacks correctly and every other .pdf
file in it is fine; however, lib.pdf appears to
be corrupt, "can&#039;t repair", according to the
Acrobat Reader.

Follow-Ups:

Date: 2000-Sep-06 06:18
By: aleax

Comment:
Same problem with lib.pdf (only) after downloading the
ZIP, and also in the Letter versions as opposed to A4.

-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 19:56
By: fdrake

Comment:
Fixed earlier today by removing some fragile markup in a section title.  Updated PDF packages in the appropriate download areas.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113696&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 04:00:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 20:00:45 -0700
Subject: [Python-bugs-list] [Bug #113254] pre/sre difference breaks pyclbr
Message-ID: <200009080300.UAA06751@bush.i.sourceforge.net>

Bug #113254, was updated on 2000-Aug-31 12:13
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 6
Summary: pre/sre difference breaks pyclbr

Details: """ 

pre and sre deal differently with groups that
"do not contribute to the match". Fredrick
points out that sre seems to be right but now
pyclbr is broken (though easy to fix). This
program demonstrates the difference in behavior
and the pyclbr breakage.

call it "pyclbrbug.py" The name matters because
it uses itself as a test case!
"""


import pre
import sre
import pyclbr
import sys

the_re=r"""
    (?P<Method>
	^
	(?P<MethodIndent> [ \t]* )
	def [ \t]+
	(?P<MethodName> [a-zA-Z_] \w* )
	[ \t]* \(
    )

|   (?P<Class>
	^
	(?P<ClassIndent> [ \t]* )
	class [ \t]+
	(?P<ClassName> [a-zA-Z_] \w* )
	[ \t]*
	(?P<ClassSupers> \( [^)\n]* \) )?
	[ \t]* :
    )
"""

eg="class foo: pass"

def test( mod ):
	print "===========", mod.__name__
	re=mod.compile(the_re, 
	              mod.VERBOSE | 
                      mod.DOTALL | 
	              mod.MULTILINE)
	match=re.search( eg )
	print match.start( "Method" )
	print match.group( "MethodIndent" )
	sys.modules["re"]=mod
	reload( pyclbr )
	pyclbr.readmodule_ex("pyclbrbug",["."])

test( pre )
test( sre )



Follow-Ups:

Date: 2000-Aug-31 20:57
By: jhylton

Comment:
Who should fix pyclbr?  If not you /F, please reassign.

-------------------------------------------------------

Date: 2000-Sep-02 09:31
By: effbot

Comment:
after discussion with GvR, we decided to fix this in SRE.

fred, can you update the start/end/span documentation and close this bug?  (the code is right, the docs are wrong).
-------------------------------------------------------

Date: 2000-Sep-07 20:00
By: fdrake

Comment:
Documentation update included in Doc/lib/libre.tex revision 1.53.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113254&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 04:01:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 20:01:09 -0700
Subject: [Python-bugs-list] [Bug #111481] os.stat() doesn't return st_rdev
Message-ID: <200009080301.UAA06765@bush.i.sourceforge.net>

Bug #111481, was updated on 2000-Aug-09 06:38
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 4
Summary: os.stat() doesn't return st_rdev

Details: The call os.stat() returns the fields st_mode, st_ino,
st_nlink, st_uid, st_gid, st_size, st_atime, st_mtime
st_ctime from "struct stat".
To be able to explore device nodes on a linux system
the field st_rdev needed as the major and minor device number is stored in this field.
It would be nice if it could be added as an extra element
in the tuple returned by os.stat, os.lstat etc.


Follow-Ups:

Date: 2000-Aug-29 21:51
By: fdrake

Comment:
We could add an additional element to the end with the st_rdev value, but I'm not convinced that's really the right approach; some other platform that defines another field could get that added at the end of the return tuple, and the the 11th position would have incompatible values.

The "right" solution may be to create a new function (nstat?) that returns either a dictionary or other object that has entries for all the fields (using None for fields a platform doesn't provide values for).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=111481&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 05:43:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 7 Sep 2000 21:43:25 -0700
Subject: [Python-bugs-list] [Bug #113850] posixfile __del__ method is wrong
Message-ID: <200009080443.VAA16823@delerium.i.sourceforge.net>

Bug #113850, was updated on 2000-Sep-07 21:43
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: posixfile __del__ method is wrong

Details: The posixfile __del__ method attempts to close the
file (_file_) it contains.  However, if the open
method fails, then _file_ is never assigned.
The solution is to modify __del__ as follows:

def __del__(self):
  if hasattr(self, '_file_'):
    self._file_.close()

-Kevin Jacobs (jacobs@darwin.cwru.edu)


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113850&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 09:02:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 01:02:10 -0700
Subject: [Python-bugs-list] [Bug #113779] test_gc coredump on Alpha
Message-ID: <200009080802.BAA16838@bush.i.sourceforge.net>

Bug #113779, was updated on 2000-Sep-06 21:44
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: test_gc coredump on Alpha

Details: Configured --with-cycle-gc --with-sigfpe

gc: collectable <list 0x12043d158>
gc: collectable <dictionary 0x12043d1d8>
gc: collectable <list 0x12043d158>
gc: collectable <tuple 0x12043d198>
gc: collectable <class 0x12043d218>
gc: collectable <dictionary 0x12043d278>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d2c8>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d328>
gc: collectable <instance method 0x12043d378>
gc: collectable <B instance at 0x12043d6b8>
gc: collectable <dictionary 0x12043d6f8>
gc: uncollectable <dictionary 0x12043d5f8>
gc: uncollectable <A instance at 0x12043d158>
Segmentation fault (core dumped)

gdb reports:

Core was generated by `./python -tt Lib/test/regrtest.py -l -v test_gc'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2.1...done.
Reading symbols from /lib/libutil.so.1.1...done.
Reading symbols from /lib/libm.so.6.1...done.
Reading symbols from /lib/libc.so.6.1...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
168             if (!PyList_Check(op)) {
(gdb) where
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
#1  0x120085fac in handle_finalizers (finalizers=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:312
#2  0x1200862d8 in collect (young=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:438
#3  0x120086704 in gc_collect (self=0x100000000, args=0x12043d158)
    at ./gcmodule.c:588
#4  0x120018ef0 in call_builtin (func=0x1, arg=0x12039e258, kw=0x0)
    at ceval.c:2628
#5  0x120018d30 in PyEval_CallObjectWithKeywords (func=0x1204377c0, 
    arg=0x12039e258, kw=0x0) at ceval.c:2596
#6  0x12001713c in eval_code2 (co=0x12043b890, globals=0x12043d158, 
    locals=0x120370488, args=0xffffffffffffffff, argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1929
#7  0x120016cc4 in eval_code2 (co=0x12043c400, globals=0x12043d158, 
    locals=0x120370488, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
...

(gdb) print op
$1 = (PyObject *) 0x100000000
(gdb) print newitem
$2 = (PyObject *) 0x12043d158



Follow-Ups:

Date: 2000-Sep-06 21:49
By: none

Comment:
Note that without -l to regrtest it does NOT dump core,
and completes correctly.

-------------------------------------------------------

Date: 2000-Sep-07 08:23
By: bwarsaw

Comment:
It could just be a bug in the debug printing of collected objects.  The -l switch for the regrtest simply adds a call to gc.set_debug(gc.DEBUG_LEAK) before the rest of the tests get going.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 01:02
By: none

Comment:
By the way, the original post was made by tomh@po.crl.go.jp,
who can test a fix.  However, he's out of town until 9/14.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113779&group_id=5470


From nobody@sourceforge.net  Fri Sep  8 09:33:47 2000
From: nobody@sourceforge.net (Nobody)
Date: Fri, 8 Sep 2000 01:33:47 -0700
Subject: [Python-bugs-list] [Bug #113812] Serious garbage collection problems with 2.0b1
Message-ID: <200009080833.BAA17894@bush.i.sourceforge.net>

From: noreply@sourceforge.net

Bug #113812, was updated on 2000-Sep-07 10:10
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Serious garbage collection problems with 2.0b1


Details: Since I've installed version 2.0b1, I ran into a few (serious) problems
with a non-trivial application (+80,000 lines of Python). It seems that
the are all related to the new garbage collection:

 - Suddenly, assertions fail because lists have become empty 
   while they shouldn't have. I looks like their elements have been
   garbage collected while they were still reachable.

 - Under other circumstances, I get coredumps which always 
   seem to happen in function "move_root_reachable" of gcmodule.c:
   the "traverse" function pointer seems to contain a bogus address.

 - When I run a Purified version of the interpreter, I can't reproduce
   either problem, but instead, the garbage collector seems to get
   stuck in an endless loop each time. This always happens in the
   same function "move_root_reachable". Purify doesn't produce any 
   relevant warning.

The code runs just fine with version 1.6 of the interpreter, or when I
disable the garbage collector.

Probably relevant is the fact that the objects (10,000's) in my application
are very heavily cross-linked (nearly all links are bi-directional), which 
probably puts a lot of stress on the garbage collector.

My platform: HP-UX 10.20 / c89 compiler


Follow-Ups:

Date: 2000-Sep-07 10:14
By: edg

Comment:
Just one more thing: when I turn on the gc debugging,
the interpreter also seems to get stuck in an endless loop.
-------------------------------------------------------

Date: 2000-Sep-07 14:41
By: jhylton

Comment:
If you set the GC threshold to 0, 
import gc
gc.set_threshold(0)

Do you get the same problem?  Not that I doubt there is some sort of gc problem, but I wonder if there is something going wrong in the accounting or in the collection.

How hard would it be for someone to try to reproduce this bug?  Obviously, it would be helpful to get a smaller test case that has the same behavior as your large program and also tickles the bug.

Do you have any C extension modules in your application or is it pure Python?
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 01:33
By: edg

Comment:
The code is 100% pure Python. 
When I set the threshold to 0, the problem doesn't occur.

The problem is probably very hard to reproduce by anyone else.
The slightest change in the input data for my application
can make the problem go away. Even running an optimized instead
of a debug version of the interpreter can make a difference.

I'm certainly going to try to strip it down, but that won't be 
easy (the same application, using other input data, running 
6 times as long, runs just fine).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113812&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 09:48:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 01:48:17 -0700
Subject: [Python-bugs-list] [Bug #113862] 2.0b1 lib.pdf, problems with bookmark titles
Message-ID: <200009080848.BAA24762@delerium.i.sourceforge.net>

Bug #113862, was updated on 2000-Sep-08 01:48
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b1 lib.pdf, problems with bookmark titles

Details: In Acrobat Reader, 3.25 shows in the Bookmarks as "protect unhbox voidb@x kern.06envbox" etc.  It does show correctly as "__builtin__ -- Built-in functions" in the main window, and when printed.  3.26, same problem.  Other titles seem OK (haven't checked them all, though).



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113862&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 09:49:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 01:49:27 -0700
Subject: [Python-bugs-list] [Bug #113800] optional{} produces incorrect HTML
Message-ID: <200009080849.BAA24788@delerium.i.sourceforge.net>

Bug #113800, was updated on 2000-Sep-07 08:18
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: optional{} produces incorrect HTML

Details: This showed up in the Python 2.0 document: LaTeX2HTML
produces bad HTML with improperly nested tags, including a trailing <var> tag that leaves the rest of the document in italic on some browsers.  Sample document:

\documentclass{howto}
 
\title{What's New in Python 2.0}
\release{0.05}
\author{A.M. Kuchling and Moshe Zadka}
\authoraddress{\email{amk1@bigfoot.com}, \email{moshez@math.huji.ac.il} }
 
\begin{document}
 
\code{unicode(\var{string} \optional{, \var{encoding}}
\optional{, \var{errors}} ) } creates a Unicode string from an 8-bit
 
\end{document}  

The incorrect HTML output is:

<code>unicode(<var>string</var> </var><big>[</big><var>, <var>encoding</var></var><big>]</big><big>[</big><var>, <var>errors</var></var><big>]</big><var> ) </code> creates ...

Follow-Ups:

Date: 2000-Sep-08 01:49
By: aleax

Comment:
bug 113700 is a consequence of this, I think.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113800&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 09:50:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 01:50:05 -0700
Subject: [Python-bugs-list] [Bug #113700] widespread bug in HTML files: lots of italics
Message-ID: <200009080850.BAA24886@delerium.i.sourceforge.net>

Bug #113700, was updated on 2000-Sep-06 06:16
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: widespread bug in HTML files: lots of italics

Details: I&#039;d already noticed this in AMK&#039;s and Moshe&#039;s doc about
"what&#039;s new in Python 2".  There&#039;s some bug in the
converter-to-HTML that, occasionally, for a big closed
bracket, outputs a </var> in front and a <var> in back
rather than vice-versa; so all the rest of the HTML is
italicized.  E.g., it shows up in built-in-funcs.html
in the description of int (x[, radix])  [possibly
later too, haven&#039;t checked].

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 01:50
By: aleax

Comment:
A consequence of bug 113800, I believe.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113700&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 12:49:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 04:49:45 -0700
Subject: [Python-bugs-list] [Bug #113807] PyArg_ParseTupleAndKeywords and Unicode...?
Message-ID: <200009081149.EAA30994@delerium.i.sourceforge.net>

Bug #113807, was updated on 2000-Sep-07 09:11
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: PyArg_ParseTupleAndKeywords and Unicode...?

Details: I have a small extension that works OK with
PyArg_ParseTuple and a es# format; using the
same format with PyArg_ParseTupleAndKeywords
doesn't seem to work -- after importing that
module, Python thinks 2 args are needed, and
one of them is an 'impossible format character'.

Experimentally switching to s#, it works
_except_ when I use the name=value format
AND I pass a u'something' as the value, then
it crashes the interpreter.

So I'm going back to PyArg_ParseTuple, but,
the AndKeywords form _is_ also supposed to
work with Unicode, right...?

The platform I'm using is NT 4, SP6, with
MS VC++ 6 SP4 -- just in case it's platform
specific...


Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 04:49
By: lemburg

Comment:
I've just checked in a patch which should fix this.
As I don't have code which uses keywords *and*
"es#", could you perhaps check whether this does
solve the problem ?

You'll have to download and recompile Python from the CVS
tree version for this. Alternatively, perhaps you could provide
some C code demonstrating the bug, which I could then
check on Unix.

Thanks.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113807&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 13:14:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 05:14:32 -0700
Subject: [Python-bugs-list] [Bug #110835] Find out size of primitive object (PR#214)
Message-ID: <200009081214.FAA25593@bush.i.sourceforge.net>

Bug #110835, was updated on 2000-Aug-01 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Find out size of primitive object (PR#214)

Details: Jitterbug-Id: 214
Submitted-By: loewis@informatik.hu-berlin.de
Date: Fri, 25 Feb 2000 14:28:33 -0500 (EST)
Version: 1.5.2
OS: Solaris


This is a feature request made on python-help. If you want to estimate
how much memory your application uses, you currently have to count the bytes
manually. If there was a builtin function (say, sys.sizeof), counting would
be much easier. It would be documented as

sizeof(object) -> integer
Return the number of bytes that an object uses internally. This only counts
the number of bytes used by the object itself, not those of any of its 
attributes.

Ie. sys.sizeof(0) would give 12 on my system, the size of a dictionary would
count the dictentries, but the size of an instanceobject would not count the
the size of the __dict__ attribute.



====================================================================
Audit trail:
Tue Mar 07 14:42:18 2000	guido	changed notes
Tue Mar 07 14:42:18 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:14
By: none

Comment:
Interesting idea.
Is this what we need?
-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 05:14
By: lemburg

Comment:
See mxTools at http://starship.python.net/~lemburg/ for an example of how
to implement a sizeof() function.

The problem with this approach is that it only counts the size of the
object struct itself and doesn't account for any external storage
which may have been allocated by the object (e.g. Unicode objects
and dictionaries use such external resources).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110835&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 13:21:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 05:21:36 -0700
Subject: [Python-bugs-list] [Bug #110924] support Unicode for Python source code
Message-ID: <200009081221.FAA25926@bush.i.sourceforge.net>

Bug #110924, was updated on 2000-Aug-02 08:17
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 1
Summary: support Unicode for Python source code

Details: exec u"print 42"
doesn't work.

Follow-Ups:

Date: 2000-Aug-09 02:35
By: effbot

Comment:
python doesn't support 16-bit source code -- so what exactly do you want exec to do?
-------------------------------------------------------

Date: 2000-Aug-17 05:17
By: none

Comment:
That's exactly my point. Python should support Unicode
everywhere, in __str__ and __repr__, exec and eval, in open(), as a format for the source code (which would result in all variable names to be Unicode)...

Currenly working with Unicode (e.g. for XML) is a mess, because it's supported nowhere.

exec "a='ü'" seems to work and seems to treat the string as iso-8859-1 (or not at all)

-------------------------------------------------------

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 05:21
By: lemburg

Comment:
I don't think that the situation is that bad. You can't program
Python in Unicode, but this doesn't stop you from using it
in your Python programs.

Note that __str__ and __repr__ do support Unicode (it gets converted
to an 8-bit string using the default encoding).

There's currently not much need to have exec or eval() automatically
apply any conversion... you can always use str() around the argument
to make it support both 8-bit strings and Unicode.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110924&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 13:27:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 05:27:47 -0700
Subject: [Python-bugs-list] [Bug #110698] strptime gives format mismatch when time zone present (PR#164)
Message-ID: <200009081227.FAA26174@bush.i.sourceforge.net>

Bug #110698, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: strptime gives format mismatch when time zone present (PR#164)

Details: Jitterbug-Id: 164
Submitted-By: python-bugreport@derf.net
Date: Tue, 21 Dec 1999 08:27:27 -0500 (EST)
Version: 1.5.2
OS: RedHat 5.2; Linux 2.2.12


time.strptime() seems to fail when the time zone ('%Z') appears in the format
string.  when it is omitted from the format string (and from the string being 
parsed), strptime() works fine.

here is a sample script which demonstrates the bug:

------
#!/usr/bin/python

import time

timetuple0 = time.localtime(time.time())
print timetuple0

format1 = '%a %b %d %H:%M:%S %Y'
timestring1 = time.strftime( format1 , timetuple0 )
print timestring1
timetuple1 = time.strptime( timestring1 , format1 )
print timetuple1

format2 = '%a %b %d %H:%M:%S %Z %Y'
timestring2 = time.strftime( format2 , timetuple0 )
print timestring2
timetuple2 = time.strptime( timestring2 , format2 )
print timetuple2
------

when i run the above, i get the following output:

------
(1999, 12, 21, 5, 25, 35, 1, 355, 0)
Tue Dec 21 05:25:35 1999
(1999, 12, 21, 5, 25, 35, 1, 355, 0)
Tue Dec 21 05:25:35 PST 1999
Traceback (innermost last):
  File "./test.py", line 17, in ?
    timetuple2 = time.strptime( timestring2 , format2 )
ValueError: format mismatch
------



====================================================================
Audit trail:
Tue Dec 21 11:47:04 1999	guido	changed notes
Tue Dec 21 11:47:05 1999	guido	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] strptime gives format mismatch when time zone present (PR#164)
Date: Tue, 21 Dec 1999 09:12:15 -0500

> time.strptime() seems to fail when the time zone ('%Z') appears in
> the format string.  when it is omitted from the format string (and
> from the string being parsed), strptime() works fine.

Reporting this as a Python bug is not going to fix it.  The
time.strptime() function in Python is a very thin wrapper around the
strptime() function in the C library.  We get a lot of complaints
about this, but there's no way that we're able to fix this -- it's the
C strptime() function that needs to be fixed.  Write to your friendly
Linux support people!

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
The C library strptime() needs fixin'.
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 05:27
By: lemburg

Comment:
FYI, you could check out mxDateTime which provides a parser
for various date/time formats instead of waiting for your strptime()
C API to get fixed.

mxDateTime is available at http://starship.python.net/~lemburg/.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110698&group_id=5470


From mal@lemburg.com  Fri Sep  8 13:29:42 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 08 Sep 2000 14:29:42 +0200
Subject: [Python-bugs-list] Re: [Bug #113807] PyArg_ParseTupleAndKeywords and
 Unicode...?
References: <200009072203.PAA28857@bush.i.sourceforge.net> <02ec01c01918$7c2ce380$aca1abd4@martelli>
Message-ID: <39B8DBB6.FB4E88DB@lemburg.com>

Alex Martelli wrote:
> 
> > Date: 2000-Sep-07 15:03
> > By: jhylton
> >
> > Comment:
> > Please do triage on this bug.
> 
> Sorry, I don't understand what "triage" means in
> this context.  Want a small extension that will
> reproduce the bug?  I can do that -- two functions
> each taking a es# format argument, one without
> kw args, one with, otherwise identical.  Would that
> be useful?  Where should I send the source code
> to reproduce the bug?

Yes, please.

Note that I've just checked in a patch which should fix the
problem. A test program would be great to verify this.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From noreply@sourceforge.net  Fri Sep  8 13:56:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 05:56:03 -0700
Subject: [Python-bugs-list] [Bug #113576] Py_PROTO missing from the include files
Message-ID: <200009081256.FAA00961@delerium.i.sourceforge.net>

Bug #113576, was updated on 2000-Sep-04 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: Py_PROTO missing from the include files

Details: Some old extensions still use the Py_PROTO() macro which was
present in Python 1.5.2 and ealier. After the ANSIfication of the sources,
this macro seems to have been removed from the Python include
files.

This breaks all extensions which used the macro.

Adding a 
#define Py_PROTO(args)       args
to pyport.h should remedy this.

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 15:58
By: jhylton

Comment:
Sounds reasonable to me.
-------------------------------------------------------

Date: 2000-Sep-08 05:56
By: marangoz

Comment:
to mee too.
But I'd better leave the HAVE_PROTOTYPE ifdef as it was defined
in the old myproto.h. Some weird extensions might have fiddled with this.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113576&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 15:39:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 07:39:53 -0700
Subject: [Python-bugs-list] [Bug #113888] Compiling on alpha-osf1v4: Py_IS_INFINITY not defined
Message-ID: <200009081439.HAA31031@bush.i.sourceforge.net>

Bug #113888, was updated on 2000-Sep-08 07:39
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Compiling on alpha-osf1v4: Py_IS_INFINITY not defined

Details: In line 168 of Include/pyport.h the definition of Py_IS_INFINITY does not start in column 0. This leads the osf compiler to ignoring the entire line.
Patch: Remove the blank.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113888&group_id=5470


From lvirden@cas.org  Fri Sep  8 16:12:17 2000
From: lvirden@cas.org (Larry W. Virden)
Date: Fri, 8 Sep 2000 11:12:17 -0400 (EDT)
Subject: [Python-bugs-list] Re: [Bug #113793] getopt.c compile fails on Solaris 2.6/gcc 2.95.2
In-Reply-To: <200009072253.PAA30797@bush.i.sourceforge.net> of Thu, 7 Sep 2000 15:53:34 -0700
Message-ID: <0009081112.AA6147@cas.org>

> Date: 2000-Sep-07 15:01
> By: jhylton
> 
> Comment:
> Please do triage on this bug.

What does "triage" mean?
-- 
Never apply a Star Trek solution to a Babylon 5 problem.
Larry W. Virden <mailto:lvirden@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
-><-


From noreply@sourceforge.net  Fri Sep  8 16:20:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 08:20:43 -0700
Subject: [Python-bugs-list] [Bug #113807] PyArg_ParseTupleAndKeywords and Unicode...?
Message-ID: <200009081520.IAA06220@delerium.i.sourceforge.net>

Bug #113807, was updated on 2000-Sep-07 09:11
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: PyArg_ParseTupleAndKeywords and Unicode...?

Details: I have a small extension that works OK with
PyArg_ParseTuple and a es# format; using the
same format with PyArg_ParseTupleAndKeywords
doesn't seem to work -- after importing that
module, Python thinks 2 args are needed, and
one of them is an 'impossible format character'.

Experimentally switching to s#, it works
_except_ when I use the name=value format
AND I pass a u'something' as the value, then
it crashes the interpreter.

So I'm going back to PyArg_ParseTuple, but,
the AndKeywords form _is_ also supposed to
work with Unicode, right...?

The platform I'm using is NT 4, SP6, with
MS VC++ 6 SP4 -- just in case it's platform
specific...


Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 04:49
By: lemburg

Comment:
I've just checked in a patch which should fix this.
As I don't have code which uses keywords *and*
"es#", could you perhaps check whether this does
solve the problem ?

You'll have to download and recompile Python from the CVS
tree version for this. Alternatively, perhaps you could provide
some C code demonstrating the bug, which I could then
check on Unix.

Thanks.

-------------------------------------------------------

Date: 2000-Sep-08 08:20
By: lemburg

Comment:
Verified the fix using an example test extension from
Alex Martelli.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113807&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 16:22:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 08:22:56 -0700
Subject: [Python-bugs-list] [Bug #113890] eval() fails with unicode string
Message-ID: <200009081522.IAA32671@bush.i.sourceforge.net>

Bug #113890, was updated on 2000-Sep-08 08:22
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: eval() fails with unicode string

Details: Python 2.0b1 (#3, Sep  6 2000, 12:34:06) 
[GCC 2.95.2 19991024 (release)] on sunos5
Type "copyright", "credits" or "license" for more information.
>>> eval("1+2)
  File "<stdin>", line 1
    eval("1+2)
             ^
SyntaxError: invalid token
>>> eval("1+2")
3
>>> eval(u"1+2")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: eval() argument 1 must be string or code object


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113890&group_id=5470


From fdrake@beopen.com  Fri Sep  8 16:22:20 2000
From: fdrake@beopen.com (Fred L. Drake, Jr.)
Date: Fri, 8 Sep 2000 11:22:20 -0400 (EDT)
Subject: [Python-bugs-list] Re: [Bug #113793] getopt.c compile fails on Solaris 2.6/gcc 2.95.2
In-Reply-To: <0009081112.AA6147@cas.org>
References: <200009072253.PAA30797@bush.i.sourceforge.net>
 <0009081112.AA6147@cas.org>
Message-ID: <14777.1068.439552.164034@cj42289-a.reston1.va.home.com>

Larry W. Virden writes:
 > What does "triage" mean?

  We're going through the bugs database and making sure we've looked
at every bug to determine if it can or should be fixed in Python 2.0.
We expect to find that many bugs have become non-issues for a variety
of reasons, and would like to close those out if needed.
  If we have a specific question about a bug, we'll be sending email
to the submitter.  The triage notice does not indicate a request from
the Python developers, but a request *to* whichever develop was
assigned the bug.
  We're sorry if this has caused any confusion.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at beopen.com>
BeOpen PythonLabs Team Member



From noreply@sourceforge.net  Fri Sep  8 16:26:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 08:26:53 -0700
Subject: [Python-bugs-list] [Bug #113829] hasattr() doesn't accept Unicode strings
Message-ID: <200009081526.IAA06457@delerium.i.sourceforge.net>

Bug #113829, was updated on 2000-Sep-07 14:28
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: hasattr() doesn't accept Unicode strings  

Details: hasattr(), getattr(), and doubtless other built-in functions don't accept Unicode strings at all:
>>> import sys
>>> hasattr(sys, u'abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: hasattr, argument 2: expected string, unicode found

Questions raised by GvR:
There are probably a bunch of things that need to be changed before
this works though; getattr() c.s. require a string, then call
PyObject_GetAttr() which also checks for a string unless the object
supports tp_getattro -- but that's only true for classes and
instances.
 
Also, should we convert the string to 8-bit, or should we allow
Unicode attribute names?
 
It seems there's no easy fix -- better address this after 2.0 is
released.                                                                       

Follow-Ups:

Date: 2000-Sep-08 08:26
By: lemburg

Comment:
Just for the record and to take the discussion to SF,
here's my reply on the topic in the python-dev thread 
"hasattr() and Unicode strings".

> Also, should we convert the string to 8-bit, or should we allow
> Unicode attribute names?

Attribute names will have to be 8-bit strings (at least in 2.0).

The reason here is that attributes are normally Python identifiers
which are plain ASCII and stored as 8-bit strings in the namespace
dictionaries, i.e. there's no way to add Unicode attribute names
other than by assigning directly to __dict__.

Note that keyword lookups already automatically convert Unicode
lookup strings to 8-bit using the default encoding. The same should
happen here, IMHO.
 
> It seems there's no easy fix -- better address this after 2.0 is
> released.

Why wait for 2.1 ?

What remains is to decide where to apply the change: in hasattr()
et al. or in PyObject_GetAttr() directly. I'd opt for the latter due to
its wider range of application.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113829&group_id=5470


From bwarsaw@beopen.com  Fri Sep  8 16:33:00 2000
From: bwarsaw@beopen.com (Barry A. Warsaw)
Date: Fri, 8 Sep 2000 11:33:00 -0400 (EDT)
Subject: [Python-bugs-list] Re: [Bug #113793] getopt.c compile fails on Solaris 2.6/gcc 2.95.2
References: <200009072253.PAA30797@bush.i.sourceforge.net>
 <0009081112.AA6147@cas.org>
Message-ID: <14777.1708.180345.407190@anthem.concentric.net>

>>>>> "LWV" =3D=3D Larry W Virden <lvirden@cas.org> writes:

    LWV> What does "triage" mean?

Main Entry: tri=B7age
Pronunciation: trE-'=E4zh, 'trE-"
Function: noun
Etymology: French, sorting, sifting, from trier to sort, from Old
French -- more at TRY
Date: 1918
: the sorting of and allocation of treatment to patients and
especially battle and disaster victims according to a system of
priorities designed to maximize the number of survivors; broadly : the
assigning of priority order to projects on the basis of where funds
and resources can be best used or are most needed
- triage transitive verb=20


From jeremy@beopen.com  Fri Sep  8 16:34:55 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 8 Sep 2000 11:34:55 -0400 (EDT)
Subject: [Python-bugs-list] Re: [Bug #113793] getopt.c compile fails on Solaris 2.6/gcc 2.95.2
In-Reply-To: <0009081112.AA6147@cas.org>
References: <200009072253.PAA30797@bush.i.sourceforge.net>
 <0009081112.AA6147@cas.org>
Message-ID: <14777.1823.39014.148155@bitdiddle.concentric.net>

It is a comment to Barry (bwarsaw), to whom the bug was just assigned,
to figure out the priority and category for the bug, whether we need
more information from you, etc.

I did not expect the assignment to Barry to generate a comment to you,
although I should have.

Jeremy


From noreply@sourceforge.net  Fri Sep  8 16:35:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 08:35:06 -0700
Subject: [Python-bugs-list] [Bug #113890] eval() fails with unicode string
Message-ID: <200009081535.IAA06702@delerium.i.sourceforge.net>

Bug #113890, was updated on 2000-Sep-08 08:22
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: eval() fails with unicode string

Details: Python 2.0b1 (#3, Sep  6 2000, 12:34:06) 
[GCC 2.95.2 19991024 (release)] on sunos5
Type "copyright", "credits" or "license" for more information.
>>> eval("1+2)
  File "<stdin>", line 1
    eval("1+2)
             ^
SyntaxError: invalid token
>>> eval("1+2")
3
>>> eval(u"1+2")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: eval() argument 1 must be string or code object


Follow-Ups:

Date: 2000-Sep-08 08:35
By: lemburg

Comment:
It would be fairly straight forward to fix this by having
eval() and exec auto-convert the input to an 8-bit string
using the default encoding.

Should we proceed this way ?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113890&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 16:46:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 08:46:42 -0700
Subject: [Python-bugs-list] [Bug #113888] Compiling on alpha-osf1v4: Py_IS_INFINITY not defined
Message-ID: <200009081546.IAA07232@delerium.i.sourceforge.net>

Bug #113888, was updated on 2000-Sep-08 07:39
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Compiling on alpha-osf1v4: Py_IS_INFINITY not defined

Details: In line 168 of Include/pyport.h the definition of Py_IS_INFINITY does not start in column 0. This leads the osf compiler to ignoring the entire line.
Patch: Remove the blank.

Follow-Ups:

Date: 2000-Sep-08 08:46
By: tim_one

Comment:
Thanks!  Your fix has been checked in.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113888&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 16:55:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 08:55:04 -0700
Subject: [Python-bugs-list] [Bug #113894] os.listdir gives fails on Win32 platforms
Message-ID: <200009081555.IAA07486@delerium.i.sourceforge.net>

Bug #113894, was updated on 2000-Sep-08 08:55
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: os.listdir gives fails on Win32 platforms

Details: On windows NT the os.listdir() function doesn't correctly handle paths containing a drive specification, but no other directory spec. It incorrectly references the root directory on the specified drive rather than the current directory.
For example these two calls should return the same thing (the actual output has been slightly trimmed):

>>> import os
>>> os.listdir('c:')
['3DCube', 'Acrobat3', 'ADOBEAPP', ...]
>>> os.listdir('c:.')
['Capture', 'Catalog', ...]

The same problem shows up in os.glob, for example os.glob('d:*.py') will expand to all .py files in the root of drive d rather than the current directory.

One possible fix is that in posixmodule.c, function posix_listdir, the lines:
	strcpy(namebuf, name);
	if (namebuf[len-1] != '/' && namebuf[len-1] != '\\')
		namebuf[len++] = '/';
	strcpy(namebuf + len, "*.*");
should read:
	strcpy(namebuf, name);
	if (namebuf[len-1] != '/' && namebuf[len-1] != '\\' && namebuf[len-1] != ':')
		namebuf[len++] = '/';
	strcpy(namebuf + len, "*.*");


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113894&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 17:13:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 09:13:03 -0700
Subject: [Python-bugs-list] [Bug #110698] strptime gives format mismatch when time zone present (PR#164)
Message-ID: <200009081613.JAA02100@bush.i.sourceforge.net>

Bug #110698, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Invalid
Bug Group: Platform-specific
Priority: 5
Summary: strptime gives format mismatch when time zone present (PR#164)

Details: Jitterbug-Id: 164
Submitted-By: python-bugreport@derf.net
Date: Tue, 21 Dec 1999 08:27:27 -0500 (EST)
Version: 1.5.2
OS: RedHat 5.2; Linux 2.2.12


time.strptime() seems to fail when the time zone ('%Z') appears in the format
string.  when it is omitted from the format string (and from the string being 
parsed), strptime() works fine.

here is a sample script which demonstrates the bug:

------
#!/usr/bin/python

import time

timetuple0 = time.localtime(time.time())
print timetuple0

format1 = '%a %b %d %H:%M:%S %Y'
timestring1 = time.strftime( format1 , timetuple0 )
print timestring1
timetuple1 = time.strptime( timestring1 , format1 )
print timetuple1

format2 = '%a %b %d %H:%M:%S %Z %Y'
timestring2 = time.strftime( format2 , timetuple0 )
print timestring2
timetuple2 = time.strptime( timestring2 , format2 )
print timetuple2
------

when i run the above, i get the following output:

------
(1999, 12, 21, 5, 25, 35, 1, 355, 0)
Tue Dec 21 05:25:35 1999
(1999, 12, 21, 5, 25, 35, 1, 355, 0)
Tue Dec 21 05:25:35 PST 1999
Traceback (innermost last):
  File "./test.py", line 17, in ?
    timetuple2 = time.strptime( timestring2 , format2 )
ValueError: format mismatch
------



====================================================================
Audit trail:
Tue Dec 21 11:47:04 1999	guido	changed notes
Tue Dec 21 11:47:05 1999	guido	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] strptime gives format mismatch when time zone present (PR#164)
Date: Tue, 21 Dec 1999 09:12:15 -0500

> time.strptime() seems to fail when the time zone ('%Z') appears in
> the format string.  when it is omitted from the format string (and
> from the string being parsed), strptime() works fine.

Reporting this as a Python bug is not going to fix it.  The
time.strptime() function in Python is a very thin wrapper around the
strptime() function in the C library.  We get a lot of complaints
about this, but there's no way that we're able to fix this -- it's the
C strptime() function that needs to be fixed.  Write to your friendly
Linux support people!

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
The C library strptime() needs fixin'.
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 05:27
By: lemburg

Comment:
FYI, you could check out mxDateTime which provides a parser
for various date/time formats instead of waiting for your strptime()
C API to get fixed.

mxDateTime is available at http://starship.python.net/~lemburg/.
-------------------------------------------------------

Date: 2000-Sep-08 09:13
By: tim_one

Comment:
Closed it, as it's not a Python bug but a bug in the platform libc (if a non-std fnc can be called "buggy" at all ...).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110698&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 17:31:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 09:31:36 -0700
Subject: [Python-bugs-list] [Bug #110629] Tkinter Image names may be reused (PR#28)
Message-ID: <200009081631.JAA02818@bush.i.sourceforge.net>

Bug #110629, was updated on 2000-Jul-31 14:08
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: None
Bug Group: None
Priority: 5
Summary: Tkinter Image names may be reused (PR#28)

Details: Jitterbug-Id: 28
Submitted-By: guido@python.org
Date: Wed, 14 Jul 1999 14:00:14 -0400 (EDT)
Version: 1.5.2b
OS: 


Mark Lutz wrote me:

(BTW, this will probably never surface again (I'm stressing
the image object a bit), but I think there's a problem
with using the id() of an image as its name.  I ran into
a situation where an image was drawn in the wrong place, 
because a newly allocated image object had the same id()
as one very recently reclaimed.  It's very obscure, will
only happen if you have > 1 canvas in a process and happen
to be creating and deleting images very quickly, and is
too complex for me to describe further at the moment ;-).
I worked around it by first generating image names from a
simple counter, and then prebuilding all images up front.)



====================================================================
Audit trail:
Wed Jul 14 14:00:28 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-05 14:00
By: loewis

Comment:
Fixed in patch 101424, http://sourceforge.net/patch/?func=detailpatch&patch_id=101424&group_id=5470
-------------------------------------------------------

Date: 2000-Sep-06 21:08
By: fdrake

Comment:
Should be fixed by Martin's patch (#101424).  I've accepted the patch and assigned it and this bug to Martin for checkin and closure.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110629&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 17:37:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 09:37:00 -0700
Subject: [Python-bugs-list] [Bug #110830] "continue" inside "try" (PR#177)
Message-ID: <200009081637.JAA09045@delerium.i.sourceforge.net>

Bug #110830, was updated on 2000-Aug-01 14:12
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: Later
Bug Group: Feature Request
Priority: 1
Summary: "continue" inside "try" (PR#177)

Details: Jitterbug-Id: 177
Submitted-By: simonb@logical.co.za
Date: Tue, 11 Jan 2000 05:17:37 -0500 (EST)
Version: 1-5-2
OS: NT 4.0


Hi there

I don't know if this is a bug, or is intentional behaviour for a specific
reason.

The following code produces a syntax error about the continue not being within a
looping structure rather than a prefectly silly infinite loop...

while 1:
  try:
    continue
  except:
    pass

where the following works as one would expect...

while 1:
  try:
    raise 1
  except:
    continue

I figure that there is more likely a sane reason for this behaviour than being a
bug, but I am curious.

Thanks
Simon



====================================================================
Audit trail:
Wed Jan 12 18:11:45 2000	guido	changed notes
Wed Jan 12 18:11:45 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:12
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] Syntax (PR#177)
Date: Tue, 11 Jan 2000 12:10:17 -0500

[Simon Barratt, putting "continue" in a "try" block]
> I don't know if this is a bug, or is intentional behaviour
> for a specific reason.

Actually, it's a bit of both <wink>.  See the Language Reference Manual's
section on the "continue" statement, particularly the footnote:

    The restriction on occurring in the try clause is
    implementer's laziness and will eventually be lifted.

It's been this way (and documented) forever; it's simply hard to implement
given the current structure of the interpreter loop.

Rest assured there's nothing *conceptually* wrong with putting continue in a
try!  It's simply an implementation restriction; the error msg should
probably make that clearer.  IIRC, JPython doesn't have this restriction.
"Someday" it will get repaired in CPython too.



-------------------------------------------------------

Date: 2000-Aug-01 14:12
By: none

Comment:
It's a zero-priority bug (i.e. not likely to be fixed).

-------------------------------------------------------

Date: 2000-Aug-03 13:00
By: twouters

Comment:
Like the bot said, low priority 'to be fixed' bug.

-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 09:37
By: fdrake

Comment:
Improved exception messages when 'continue' is in a 'try' block, checked in as Python/compile.c revision 2.141.  This still doesn't do the "right thing" by implementing 'continue' in this context, but makes it easier for users to understand the exception.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110830&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 18:19:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 10:19:15 -0700
Subject: [Python-bugs-list] [Bug #110859] Environment dependency in re parser (PR#290)
Message-ID: <200009081719.KAA10484@delerium.i.sourceforge.net>

Bug #110859, was updated on 2000-Aug-01 14:38
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 3
Summary: Environment dependency in re parser (PR#290)

Details: Jitterbug-Id: 290
Submitted-By: nmm1@cam.ac.uk
Date: Wed, 12 Apr 2000 07:44:54 -0400 (EDT)
Version: 1.5.2
OS: Irix 6.5


The following code works perfectly when used interactively:

from re import match

if match(r'"([^\"]|\?""|\\?)*"','"abc"') :
    print "Hello"

When run non-interactively (e.g. 'python junk.py'), it fails:

  File "junk.py", line 3, in ?
    if match(r'"([^\"]|\?""|\\?)*"','"abc"') :
  File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 40, in match
    return _cachecompile(pattern, flags).match(string)
  File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 33, in _cachecompile
    value = compile(pattern, flags)
  File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 79, in compile
    code=pcre_compile(pattern, flags, groupindex)
pcre.error: ('operand of unlimited repeat could match the empty string', 17)




====================================================================
Audit trail:
Tue Jul 11 08:29:16 2000	guido	moved from incoming to open
Thu Jul 13 20:37:02 2000	fdrake	changed notes
Thu Jul 13 20:37:02 2000	fdrake	moved from open to irreproducible

Follow-Ups:

Date: 2000-Aug-01 14:38
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] Environment dependency in re parser (PR#290)
Date: Wed, 12 Apr 2000 22:30:46 -0400

> Full_Name: Nick Maclaren
> Version: 1.5.2
> OS: Irix 6.5
> Submission from: posh.mcc.wwwcache.ja.net (194.83.240.29)
>
>
> The following code works perfectly when used interactively:
>
> from re import match
>
> if match(r'"([^\"]|\?""|\\?)*"','"abc"') :
>     print "Hello"
>
> When run non-interactively (e.g. 'python junk.py'), it fails:
>
>   File "junk.py", line 3, in ?
>     if match(r'"([^\"]|\?""|\\?)*"','"abc"') :
>   File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 40, in match
>     return _cachecompile(pattern, flags).match(string)
>   File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 33, in
> _cachecompile
>     value = compile(pattern, flags)
>   File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 79, in compile
>     code=pcre_compile(pattern, flags, groupindex)
> pcre.error: ('operand of unlimited repeat could match the empty
> string', 17)

It yields the same error for me whether run interactively or from file,
under the released 1.5.2 for Windows, here run from a DOS box:

D:\Python>python
Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from re import match
>>> if match(r'"([^\"]|\?""|\\?)*"','"abc"') :
...    print "Hello"
...
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "D:\Python\Lib\re.py", line 40, in match
    return _cachecompile(pattern, flags).match(string)
  File "D:\Python\Lib\re.py", line 33, in _cachecompile
    value = compile(pattern, flags)
  File "D:\Python\Lib\re.py", line 79, in compile
    code=pcre_compile(pattern, flags, groupindex)
pcre.error: ('operand of unlimited repeat could match the empty string', 17)
>>>

The error msg is appropriate, since the third branch of the alternative
matches 0 or 1 backslashes, so the alternative as a whole can match the
empty string -- the error msg means exactly what it says.  This is
functioning correctly as designed.

Perhaps you're using an interactive shell with a filter (readline?) that's
chewing up some of the backslashes itself?




-------------------------------------------------------

Date: 2000-Aug-01 14:38
By: none

Comment:
Something from outside of Python appears to causing this.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 10:19
By: fdrake

Comment:
Should have already been closed; this was marked as "Not a Bug."
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110859&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 21:45:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 13:45:55 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200009082045.NAA12331@bush.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 13:45
By: fdrake

Comment:
We need to know the output of "uname -s" and "uname -r" for this system.  (If "uname -r" reports an error, please try "uname -v".)

Are you willing to test a modified configure script on this platform?

What additional library is required for the mmap module?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 21:51:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 13:51:59 -0700
Subject: [Python-bugs-list] [Bug #113760] 2.0b1: _xmlplus does not allow site xml to override Lib/xml
Message-ID: <200009082051.NAA12644@bush.i.sourceforge.net>

Bug #113760, was updated on 2000-Sep-06 16:53
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: 2.0b1: _xmlplus does not allow site xml to override Lib/xml

Details: _xmlplus is represented as a means of overriding the new standard lib xml package with a user-supplied xml package, such as the one from XML-SIG ("There's a special feature whereby a user-installed package named _xmlplus overrides the standard xmlpackage; this is intended to give the XML SIG a hook to distribute backwards-compatible updates to the standard xml package." - quote from News on BeOpen site). While this has _some_ effect, it does not work as described. Under 2.0b1, code using the xml package from the XML-SIG (installed in site-packages) will only work if the new standard xml package in lib is renamed or removed. If used with the new standard xml package, imports such as
from xml.sax import saxexts
fail. If the _xmlplus hook is used (by renaming site-packages/xml to site-packages/_xmlplus or using a symlink), the imports succeed, but later the code fails with a message stating that no parsers can be found. 

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 16:12
By: mfavas

Comment:
Martin v. Loewis has justed posted a link on xml-sig to a patch for the "no parsers can be found" problem. I've applied the patch (by hand - "patch" failed) and all seems OK. Custom, tricky ways of finding/doing imports abound... Wasn't there some talk of tidying-up imports and import hooks? (MvL's patch is at http://sourceforge.net/patch/?func=detailpatch&patch_id=101444&group_id=6473 )
- Mark
-------------------------------------------------------

Date: 2000-Sep-07 16:17
By: mfavas

Comment:
Martin v. Loewis has justed posted a link on xml-sig to a patch for the "no parsers can be found" problem. I've applied the patch (by hand - "patch" failed) and all seems OK. Custom, tricky ways of finding/doing imports abound... Wasn't there some talk of tidying-up imports and import hooks? (MvL's patch is at http://sourceforge.net/patch/?func=detailpatch&patch_id=101444&group_id=6473 )
- Mark
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113760&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 22:55:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 14:55:51 -0700
Subject: [Python-bugs-list] [Bug #113810] Global Module Index points to non-existant "About" page
Message-ID: <200009082155.OAA20760@delerium.i.sourceforge.net>

Bug #113810, was updated on 2000-Sep-07 09:39
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 6
Summary: Global Module Index points to non-existant "About" page

Details: Reported by Justin D. Pettit <jpettit@raznick.com> by email:

    - The "About this document..." hyperlink in the Global Module
      Index is broken.  There is no "Doc/about.html".


Follow-Ups:

Date: 2000-Sep-08 14:55
By: fdrake

Comment:
Added Doc/html/about.html with some reasonable content for the document collection.  This is linked to from the main index and the Global Module Index.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113810&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 22:57:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 14:57:36 -0700
Subject: [Python-bugs-list] [Bug #110853] Segmentation fault with kernel 2.2.12 (PR#103)
Message-ID: <200009082157.OAA20782@delerium.i.sourceforge.net>

Bug #110853, was updated on 2000-Aug-01 14:37
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: None
Bug Group: Irreproducible
Priority: 1
Summary: Segmentation fault with kernel 2.2.12 (PR#103)

Details: Jitterbug-Id: 103
Submitted-By: apsteffe@netwood.net
Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT)
Version: 1.5.2
OS: Linux


I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 .  When I try to
 execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault.
The functions work ok with kernel 1.2.13 .



====================================================================
Audit trail:
Mon Oct 18 18:08:00 1999	guido	changed notes
Mon Oct 18 18:08:00 1999	guido	changed notification
Mon Oct 18 18:08:00 1999	guido	moved from incoming to irreproducible

Follow-Ups:

Date: 2000-Aug-01 14:37
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Segmentation fault with kernel 2.2.12 (PR#103)
Date: Mon, 11 Oct 1999 23:09:13 -0400

> Full_Name: Alfred Steffens Jr.
> Version: 1.5.2
> OS: Linux
> Submission from: p138.netwood.net (209.247.185.38)
> 
> I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 .  When I try to
>  execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault.
> The functions work ok with kernel 1.2.13 .

The Linux and glibc kernel versions don't mean much to me.  Can you
fire up a debugger and see where in the C code it crashes?  Also, is
this for a specific URL or is it for any URL?  If a specific URL, I'd
like to know which one.

Finally, did you get or build the Python executable matching your
kernel?  A Linux upgrade from 1.x to 2.x seems a big deal, it's
possible that you'll need a new Python installation or build.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:37
By: none

Comment:
Probably caused by a huge jump in Linux kernel version without recompiling
Python.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 14:57
By: fdrake

Comment:
Closed since this is not reproducible.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110853&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 23:12:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 15:12:26 -0700
Subject: [Python-bugs-list] [Bug #110707] does not compile under BSDI (PR#57)
Message-ID: <200009082212.PAA21346@delerium.i.sourceforge.net>

Bug #110707, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Works For Me
Bug Group: Platform-specific
Priority: 5
Summary: does not compile under BSDI (PR#57)

Details: Jitterbug-Id: 57
Submitted-By: jital@knoggin.com
Date: Fri, 20 Aug 1999 04:18:04 -0400 (EDT)
Version: py152
OS: BSDI IServer


seems to think it is a NeXT arch or something



$ ./configure --prefix=/usr/home/knoggin/usr/local/
--exec-prefix=/usr/home/knoggin/usr/local/

creating cache ./config.cache
checking MACHDEP... bsdos3
checking CCC... 
checking for --without-gcc... no
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking LINKCC... $(PURIFY) $(CC)
checking LDLIBRARY... 
checking for ranlib... ranlib
checking for ar... ar
checking how to run the C preprocessor... gcc -D_HAVE_BSDI -E
checking for AIX... no
checking for minix/config.h... no
checking whether gcc -D_HAVE_BSDI accepts -OPT:Olimit=0... no
checking whether gcc -D_HAVE_BSDI accepts -Olimit 1500... no
checking for C preprocessor type... ansi
checking for ANSI C header files... yes
checking for dlfcn.h... yes
checking for fcntl.h... yes
checking for limits.h... yes
checking for locale.h... yes
checking for ncurses.h... yes
checking for pthread.h... yes
checking for signal.h... yes
checking for stdarg.h... yes
checking for stddef.h... yes
checking for stdlib.h... yes
checking for thread.h... no
checking for unistd.h... yes
checking for utime.h... yes
checking for sys/audioio.h... no
checking for sys/file.h... yes
checking for sys/lock.h... yes
checking for sys/param.h... yes
checking for sys/select.h... yes
checking for sys/time.h... yes
checking for sys/times.h... yes
checking for sys/un.h... yes
checking for sys/utsname.h... yes
checking for sys/wait.h... yes
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking for clock_t in time.h... yes
checking for mode_t... yes
checking for off_t... yes
checking for pid_t... yes
checking return type of signal handlers... void
checking for size_t... yes
checking for uid_t in sys/types.h... yes
checking size of int... 4
checking size of long... 4
checking size of void *... 4
checking for long long support... yes
checking size of long long... 8
checking size of off_t... 8
checking whether to enable large file support... yes
checking for --with-next-framework... no
checking for --with-dyld... required for framework build
checking SO... .so
checking LDSHARED... ld
checking CCSHARED... 
checking LINKFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for t_open in -lnsl... no
checking for socket in -lsocket... no
checking for socket in -lnet... no
checking for --with-libs... no
checking for --with(out)-readline... not specified.
checking for --with-dec-threads... no
checking for --with-threads... no
checking for --with-thread... no
checking for --with-sgi-dl... no
checking for --with-dl-dld... no
checking for alarm... yes
checking for chown... yes
checking for clock... yes
checking for dlopen... yes
checking for execv... yes
checking for flock... yes
checking for fork... yes
checking for fsync... yes
checking for fdatasync... no
checking for ftime... no
checking for ftruncate... yes
checking for getpeername... yes
checking for getpgrp... yes
checking for getpid... yes
checking for getpwent... yes
checking for gettimeofday... yes
checking for getwd... yes
checking for kill... yes
checking for link... yes
checking for lstat... yes
checking for mkfifo... yes
checking for mktime... yes
checking for nice... yes
checking for pause... yes
checking for plock... no
checking for pthread_init... yes
checking for putenv... yes
checking for readlink... yes
checking for select... yes
checking for setgid... yes
checking for setlocale... yes
checking for setuid... yes
checking for setsid... yes
checking for setpgid... yes
checking for setpgrp... yes
checking for setvbuf... yes
checking for sigaction... yes
checking for siginterrupt... yes
checking for sigrelse... no
checking for strftime... yes
checking for strptime... no
checking for symlink... yes
checking for tcgetpgrp... yes
checking for tcsetpgrp... yes
checking for timegm... no
checking for times... yes
checking for truncate... yes
checking for uname... yes
checking for waitpid... yes
checking for fseek64... no
checking for fseeko... no
checking for fstatvfs... no
checking for ftell64... no
checking for ftello... no
checking for statvfs... no
checking for dup2... yes
checking for getcwd... yes
checking for strdup... yes
checking for strerror... yes
checking for memmove... yes
checking for getpgrp... (cached) yes
checking for setpgrp... (cached) yes
checking for gettimeofday... (cached) yes
checking whether time.h and sys/time.h may both be included... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for tm_zone in struct tm... yes
checking for time.h that defines altzone... no
checking whether sys/select.h and sys/time.h may both be included... yes
checking whether char is unsigned... no
checking for working const... yes
checking for working volatile... yes
checking for working signed char... yes
checking for prototypes... yes
checking for variable length prototypes and stdarg.h... yes
checking for bad exec* prototypes... no
checking for bad static forward... no
checking whether va_list is an array... no
checking for gethostbyname_r... no
checking for gethostbyname... yes
checking for __fpu_control in -lieee... no
checking for --with-fpectl... checking for --with-libm=STRING... default
LIBM="-
lm"
checking for --with-libc=STRING... default LIBC=""
checking for hypot... yes
checking for hypot... (cached) yes
checking for genuine getopt... yes
checking what malloc(0) returns... nonnull
updating cache ./config.cache
creating ./config.status
creating Makefile
creating Objects/Makefile
creating Parser/Makefile
creating Python/Makefile
creating Modules/Makefile.pre
creating Modules/Setup.thread
creating config.h
pcvendor:~/usr/local/src/Python-1.5.2 $ make
(cd Modules; make -f Makefile.pre Makefile)
cp ./Setup.in Setup
echo "# Edit this file for local setup changes" >Setup.local
rm -f ../libpython1.5.a
/bin/sh ./makesetup Setup.thread Setup.local Setup
making Makefile in subdirectory .
`Makefile' is up to date.
making Makefile in subdirectory Parser
`Makefile' is up to date.
making Makefile in subdirectory Objects
`Makefile' is up to date.
making Makefile in subdirectory Python
`Makefile' is up to date.
making Makefile in subdirectory Modules
`Makefile' is up to date.
(rm -f Modules/hassignal; cd Modules; make hassignal)
rm -f hassignal
for i in regexmodule.o regexpr.o  pcremodule.o pypcre.o  posixmodule.o 
signalmo
dule.o  arraymodule.o  cmathmodule.o  mathmodule.o  stropmodule.o 
structmodule.
o  timemodule.o  operator.o  fcntlmodule.o  pwdmodule.o  grpmodule.o 
selectmodu
le.o  socketmodule.o  errnomodule.o  md5module.o md5c.o  shamodule.o 
rotormodul
e.o  newmodule.o  binascii.o  parsermodule.o  cStringIO.o  cPickle.o config.o
ge
tpath.o main.o getbuildinfo.o; do  if test "$i" = "signalmodule.o"; then  echo
y
es >hassignal; break;  fi;  done
cd Parser ; make OPT="-g -O2" VERSION="1.5" 
prefix="/usr/home/knoggin/usr/local
/" exec_prefix="/usr/home/knoggin/usr/local/" all
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c pgenmain.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c acceler.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar1.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c listnode.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c node.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c parser.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c parsetok.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c tokenizer.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bitset.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c metagrammar.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c firstsets.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c pgen.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c printgrammar.c
gcc -D_HAVE_BSDI -g -O2 pgenmain.o acceler.o grammar1.o  listnode.o node.o
parse
r.o  parsetok.o tokenizer.o bitset.o  metagrammar.o firstsets.o grammar.o
pgen.o
 printgrammar.o -ldl -o pgen
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c myreadline.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c intrcheck.c
cd Objects ; make OPT="-g -O2" VERSION="1.5" 
prefix="/usr/home/knoggin/usr/local/" exec_prefix="/usr/home/knoggin/usr/local/"
all
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c abstract.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c cobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c complexobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c fileobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c floatobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frameobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c funcobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c intobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c listobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c longobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c dictobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c moduleobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c object.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c rangeobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c sliceobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c stringobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c tupleobject.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c typeobject.c
cd Python ; make OPT="-g -O2" VERSION="1.5" 
prefix="/usr/home/knoggin/usr/local/" exec_prefix="/usr/home/knoggin/usr/local/"
all
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bltinmodule.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ceval.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c compile.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c errors.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frozen.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frozenmain.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getargs.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getcompiler.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getcopyright.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getmtime.c
gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H
-DPLATFORM='"bsdos3"'  ./getplatform.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getversion.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c graminit.c
gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c import.c
gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c
./importdl.c:269: mach-o/dyld.h: No such file or directory
*** Error code 1

Stop.
*** Error code 1

Stop.



====================================================================
Audit trail:
Mon Aug 30 12:40:26 1999	guido	changed notes
Mon Aug 30 12:40:26 1999	guido	moved from incoming to irreproducible
Tue Oct 19 23:20:49 1999	guido	sent reply 1
Tue Oct 19 23:21:36 1999	guido	changed notes
Tue Oct 19 23:21:36 1999	guido	moved from irreproducible to open
Tue Oct 19 23:30:25 1999	guido	changed notes
Tue Oct 19 23:30:25 1999	guido	moved from open to platformbug

Follow-Ups:

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: does not compile under BSDI (PR#57)
Date: Tue Oct 19 23:20:49 1999

This same bug was reported by someone else for the same platform.

We arrived at the work-around of deleting the line

#define WITH_DYLD

from the config.h generated by the configure script.

If you are still experiencing problems building Python, please
try this.

--Guido van Rossum

-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] does not compile under BSDI (PR#57)
Date: Fri, 20 Aug 1999 07:57:10 -0400

> Full_Name: John Ital
> Version: py152
> OS: BSDI IServer
> 
> seems to think it is a NeXT arch or something
>
[...]
> gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c
> ./importdl.c:269: mach-o/dyld.h: No such file or directory
> *** Error code 1

Very strange.  I've never seen this before.  It appears that somehow
USE_DYLD is defined at that point, which can only happen if WITH_DYLD
is defined, which can only happen if you specify --with-next-framework
or --with-dyld on the configure command line, which you didn't.

Perhaps you have a buggy preprocessor that is confused by the tangle
of #ifdefs in importdl.c?

I don't know how to help you; I know Python has been built
successfully on bsdos3 before, so I'm guessing it's something in your
setup, not a Python bug.

If you need more help, please ask a newsgroup -- either
comp.lang.python or a BSD specific one.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
Work-around: if you delete
 #define WITH_DYLD
from config.h, the build succeeds.

-------------------------------------------------------

Date: 2000-Aug-03 09:00
By: twouters

Comment:
For the record, I cannot reproduce this on the BSDI 3.1 systems we still have lying around. It *might* have been specific to BSDI 3.0, which we no longer have (for various reasons, like y2k bugs ;) and I've heard similar (but not the same) reports about BSD/OS running under a 'virtual' machine. However, I've never seen or heard about those 'virtual' BSD/OSes, other than in that c.l.py posting.



-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 15:12
By: fdrake

Comment:
I've sent a message to the submitter asking if this can be reproduced with more recent Python versions.  Closed as "Works for Me" based on Thomas' comment.  This can be reopened based on further input from the original submitter.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110707&group_id=5470


From noreply@sourceforge.net  Fri Sep  8 23:57:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 15:57:55 -0700
Subject: [Python-bugs-list] [Bug #110833] linker options documentation (PR#195)
Message-ID: <200009082257.PAA17236@bush.i.sourceforge.net>

Bug #110833, was updated on 2000-Aug-01 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 5
Summary: linker options documentation (PR#195)

Details: Jitterbug-Id: 195
Submitted-By: John-Mark Gurney <gurney_j@efn.org>
Date: Sun, 30 Jan 2000 18:09:56 -0800
Version: None
OS: None

I have found out that I need to add -Xlinker -export-dynamic to the gcc
command to compile a program linked w/ the libpython.a library... if you
do not specify this option, all unreferenced symbols will be discarded...

please document this requirement in the documentation, and after that has
happened, close this bug report...

Thanks.

-- 
  John-Mark Gurney				Voice: +1 408 975 9651
  Cu Networking					  

  "The soul contains in itself the event that shall presently befall it.
  The event is only the actualizing of its thought." -- Ralph Waldo Emerson


====================================================================
Audit trail:
Mon Feb 07 12:37:05 2000	guido	changed notes
Mon Feb 07 12:37:05 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:13
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] please resolve 191.. (PR#195)
Date: Mon, 31 Jan 2000 12:25:49 -0500

> I have found out that I need to add -Xlinker -export-dynamic to the gcc
> command to compile a program linked w/ the libpython.a library... if you
> do not specify this option, all unreferenced symbols will be discarded...
> 
> please document this requirement in the documentation, and after that has
> happened, close this bug report...

I read your bug report 191 and I think it may be platform specific, or
a bug in how you link with Python, since I cannot reproduce this here
on Solaris.

Until we are clear on this we can't fix the documentation, sorry.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:13
By: none

Comment:
From: John-Mark Gurney <gurney_j@efn.org>
Subject: Re: [Python-bugs-list] please resolve 191.. (PR#195)
Date: Mon, 31 Jan 2000 11:40:12 -0800

Guido van Rossum scribbled this message on Jan 31:
> > I have found out that I need to add -Xlinker -export-dynamic to the gcc
> > command to compile a program linked w/ the libpython.a library... if you
> > do not specify this option, all unreferenced symbols will be discarded...
> > 
> > please document this requirement in the documentation, and after that has
> > happened, close this bug report...
> 
> I read your bug report 191 and I think it may be platform specific, or
> a bug in how you link with Python, since I cannot reproduce this here
> on Solaris.

I would try it under Solaris, but I don't have the time right now to
compile up the latest GNU ld on solaris, to make sure that it is compiler
specific...

> Until we are clear on this we can't fix the documentation, sorry.

I would think that you would want to document such a behavior considering
just how many people happen to use gcc...  I am using gcc 2.7.2.3 and GNU
ld 2.9.1, and considering the number of people that are using GNU ld 2.9.1,
I would assume you'd want to document it so that people like myself, don't
run into this problem...

the -Xlinker -export-dynamic happens to be a GNU ld specific solution,
but the bug that python doesn't force include all the symbols should be
documented so that people don't encounter the problem...

-- 
  John-Mark Gurney				Voice: +1 408 975 9651
  Cu Networking					  

  "The soul contains in itself the event that shall presently befall it.
  The event is only the actualizing of its thought." -- Ralph Waldo Emerson

-------------------------------------------------------

Date: 2000-Aug-01 14:13
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] please resolve 191.. (PR#195)
Date: Mon, 31 Jan 2000 15:35:35 -0500

> Guido van Rossum scribbled this message on Jan 31:
> > > I have found out that I need to add -Xlinker -export-dynamic to the gcc
> > > command to compile a program linked w/ the libpython.a library... if you
> > > do not specify this option, all unreferenced symbols will be discarded...
> > > 
> > > please document this requirement in the documentation, and after that has
> > > happened, close this bug report...
> > 
> > I read your bug report 191 and I think it may be platform specific, or
> > a bug in how you link with Python, since I cannot reproduce this here
> > on Solaris.
> 
> I would try it under Solaris, but I don't have the time right now to
> compile up the latest GNU ld on solaris, to make sure that it is compiler
> specific...
> 
> > Until we are clear on this we can't fix the documentation, sorry.
> 
> I would think that you would want to document such a behavior considering
> just how many people happen to use gcc...  I am using gcc 2.7.2.3 and GNU
> ld 2.9.1, and considering the number of people that are using GNU ld 2.9.1,
> I would assume you'd want to document it so that people like myself, don't
> run into this problem...
> 
> the -Xlinker -export-dynamic happens to be a GNU ld specific solution,
> but the bug that python doesn't force include all the symbols should be
> documented so that people don't encounter the problem...

This (that it's GNU ld specific) is information that you didn't
explain first.  I am probably not using GNU ld, which may explain why
I couldn't reproduce your problem.

If you want to save me the most time, please suggest the exact patch
for the documentation, using the latest version of the docs from the
CVS tree.  (python.org/download/cvs.html)

To save me at least some time, write a paragraph of text and give me
at least a hint on which section of which document it should be
inserted into, and we'll figure it out from there.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:13
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] please resolve 191.. (PR#195)
Date: Mon, 07 Feb 2000 12:55:20 -0500

> the -Xlinker -export-dynamic happens to be a GNU ld specific solution,
> but the bug that python doesn't force include all the symbols should be
> documented so that people don't encounter the problem...

There's a Solaris-specific patch (just checked in a few days ago) to
configure.in that takes care of this; maybe it can be made general?

No time to explain, see latest configure.in cvs log.
python.org/download/cvs.html

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:13
By: none

Comment:
Still waiting for a patch...
-------------------------------------------------------

Date: 2000-Sep-08 15:57
By: fdrake

Comment:
Add section to the Extending & Embedding manual discussing linking issues for embedded Python.  Checked in as Doc/ext/ext.tex revision 1.83.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110833&group_id=5470


From noreply@sourceforge.net  Sat Sep  9 05:18:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 21:18:15 -0700
Subject: [Python-bugs-list] [Bug #113934] string * int silently returns wrong answer for certain ints
Message-ID: <200009090418.VAA27990@bush.i.sourceforge.net>

Bug #113934, was updated on 2000-Sep-08 21:18
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: string * int silently returns wrong answer for certain ints

Details: Multiplying string * int sometimes delivers the wrong answer instead of raising an exception. For example, Python will return the wrong value when attempting to create a string exactly 2**32 bytes long:

Python 1.5.2 (#1, Feb  1 2000, 16:32:16)  [GCC egcs-2.91.66 19990314/Linux (egcs- on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> s='x'*65536
>>> len(s)
65536
>>> t=s*65536
>>> len (t)
0

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113934&group_id=5470


From noreply@sourceforge.net  Sat Sep  9 06:34:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 22:34:50 -0700
Subject: [Python-bugs-list] [Bug #113934] string * int silently returns wrong answer for certain ints
Message-ID: <200009090534.WAA30392@bush.i.sourceforge.net>

Bug #113934, was updated on 2000-Sep-08 21:18
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 8
Summary: string * int silently returns wrong answer for certain ints

Details: Multiplying string * int sometimes delivers the wrong answer instead of raising an exception. For example, Python will return the wrong value when attempting to create a string exactly 2**32 bytes long:

Python 1.5.2 (#1, Feb  1 2000, 16:32:16)  [GCC egcs-2.91.66 19990314/Linux (egcs- on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> s='x'*65536
>>> len(s)
65536
>>> t=s*65536
>>> len (t)
0

Follow-Ups:

Date: 2000-Sep-08 22:34
By: tim_one

Comment:
Assigned to me.  Boosted the priority because similar inputs can cause core dumps, and especially when mucking with Unicode strings instead of 8-bit guys.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113934&group_id=5470


From noreply@sourceforge.net  Sat Sep  9 07:13:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 23:13:01 -0700
Subject: [Python-bugs-list] [Bug #113828] getpythonregpath with null data in registry key
Message-ID: <200009090613.XAA31529@bush.i.sourceforge.net>

Bug #113828, was updated on 2000-Sep-07 13:46
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: getpythonregpath with null data in registry key

Details: 
File pc/getpathp.c
Function:getpythonregpath

ppPaths[index] can be null but this fragment is not null protected:

len = _tcslen(ppPaths[index]);
_tcsncpy(szCur, ppPaths[index], len);

Grzegorz Makarewicz

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113828&group_id=5470


From noreply@sourceforge.net  Sat Sep  9 07:14:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 23:14:26 -0700
Subject: [Python-bugs-list] [Bug #113934] string * int silently returns wrong answer for certain ints
Message-ID: <200009090614.XAA31551@bush.i.sourceforge.net>

Bug #113934, was updated on 2000-Sep-08 21:18
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 8
Summary: string * int silently returns wrong answer for certain ints

Details: Multiplying string * int sometimes delivers the wrong answer instead of raising an exception. For example, Python will return the wrong value when attempting to create a string exactly 2**32 bytes long:

Python 1.5.2 (#1, Feb  1 2000, 16:32:16)  [GCC egcs-2.91.66 19990314/Linux (egcs- on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> s='x'*65536
>>> len(s)
65536
>>> t=s*65536
>>> len (t)
0

Follow-Ups:

Date: 2000-Sep-08 22:34
By: tim_one

Comment:
Assigned to me.  Boosted the priority because similar inputs can cause core dumps, and especially when mucking with Unicode strings instead of 8-bit guys.
-------------------------------------------------------

Date: 2000-Sep-08 23:14
By: tim_one

Comment:
Fixed in CVS.  Checkin comment, for stringobject.c and unicodeobject.c:

Fix for bug 113934.  string*n and unicode*n did no overflow checking at all, either to see whether the # of chars fit in an int, or that the amount of memory needed fit in a size_t.  Checking these is expensive, but the alternative is silently wrong answers (as in the bug report) or core dumps (which were easy to provoke using Unicode strings).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113934&group_id=5470


From noreply@sourceforge.net  Sat Sep  9 07:16:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 23:16:51 -0700
Subject: [Python-bugs-list] [Bug #113862] 2.0b1 lib.pdf, problems with bookmark titles
Message-ID: <200009090616.XAA31595@bush.i.sourceforge.net>

Bug #113862, was updated on 2000-Sep-08 01:48
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: 2.0b1 lib.pdf, problems with bookmark titles

Details: In Acrobat Reader, 3.25 shows in the Bookmarks as "protect unhbox voidb@x kern.06envbox" etc.  It does show correctly as "__builtin__ -- Built-in functions" in the main window, and when printed.  3.26, same problem.  Other titles seem OK (haven't checked them all, though).



Follow-Ups:

Date: 2000-Sep-08 23:16
By: fdrake

Comment:
The bookmark entry for the copy_reg module has the same defect.  This is probably a result of the seriously painful hackery used to make the underscore be somewhat less special.

Must be fixed for 2.0 final.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113862&group_id=5470


From noreply@sourceforge.net  Sat Sep  9 07:17:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 23:17:58 -0700
Subject: [Python-bugs-list] [Bug #113894] os.listdir gives fails on Win32 platforms
Message-ID: <200009090617.XAA31688@bush.i.sourceforge.net>

Bug #113894, was updated on 2000-Sep-08 08:55
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: os.listdir gives fails on Win32 platforms

Details: On windows NT the os.listdir() function doesn't correctly handle paths containing a drive specification, but no other directory spec. It incorrectly references the root directory on the specified drive rather than the current directory.
For example these two calls should return the same thing (the actual output has been slightly trimmed):

>>> import os
>>> os.listdir('c:')
['3DCube', 'Acrobat3', 'ADOBEAPP', ...]
>>> os.listdir('c:.')
['Capture', 'Catalog', ...]

The same problem shows up in os.glob, for example os.glob('d:*.py') will expand to all .py files in the root of drive d rather than the current directory.

One possible fix is that in posixmodule.c, function posix_listdir, the lines:
	strcpy(namebuf, name);
	if (namebuf[len-1] != '/' && namebuf[len-1] != '\\')
		namebuf[len++] = '/';
	strcpy(namebuf + len, "*.*");
should read:
	strcpy(namebuf, name);
	if (namebuf[len-1] != '/' && namebuf[len-1] != '\\' && namebuf[len-1] != ':')
		namebuf[len++] = '/';
	strcpy(namebuf + len, "*.*");


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113894&group_id=5470


From noreply@sourceforge.net  Sat Sep  9 07:30:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 23:30:13 -0700
Subject: [Python-bugs-list] [Bug #113850] posixfile __del__ method is wrong
Message-ID: <200009090630.XAA05148@delerium.i.sourceforge.net>

Bug #113850, was updated on 2000-Sep-07 21:43
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: posixfile __del__ method is wrong

Details: The posixfile __del__ method attempts to close the
file (_file_) it contains.  However, if the open
method fails, then _file_ is never assigned.
The solution is to modify __del__ as follows:

def __del__(self):
  if hasattr(self, '_file_'):
    self._file_.close()

-Kevin Jacobs (jacobs@darwin.cwru.edu)


Follow-Ups:

Date: 2000-Sep-08 13:04
By: loewis

Comment:
Why does posixfile need an __del__ in the first place? Deleting the instance
should release the underlying file object, which will close it. If anybody else
keeps the file object referenced, perhaps it even should stay open?
-------------------------------------------------------

Date: 2000-Sep-08 23:30
By: fdrake

Comment:
Removed the __del__() method in posixfile.py revision 1.16.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113850&group_id=5470


From noreply@sourceforge.net  Sat Sep  9 07:31:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 8 Sep 2000 23:31:48 -0700
Subject: [Python-bugs-list] [Bug #113828] getpythonregpath with null data in registry key
Message-ID: <200009090631.XAA05246@delerium.i.sourceforge.net>

Bug #113828, was updated on 2000-Sep-07 13:46
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: getpythonregpath with null data in registry key

Details: 
File pc/getpathp.c
Function:getpythonregpath

ppPaths[index] can be null but this fragment is not null protected:

len = _tcslen(ppPaths[index]);
_tcsncpy(szCur, ppPaths[index], len);

Grzegorz Makarewicz

Follow-Ups:

Date: 2000-Sep-08 23:31
By: tim_one

Comment:
Assigned to MarkH.  Offhand it looks like a legit complaint to me, and that the

len = _tcslen(ppPaths[index]);
_tcsncpy(szCur, ppPaths[index], len);
szCur += len;
dataSize -= len;

block should be protected against a null ppPaths[index].
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113828&group_id=5470


From noreply@sourceforge.net  Sat Sep  9 21:20:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 9 Sep 2000 13:20:59 -0700
Subject: [Python-bugs-list] [Bug #113960] Problems with reverse() in the array module
Message-ID: <200009092020.NAA32059@delerium.i.sourceforge.net>

Bug #113960, was updated on 2000-Sep-09 13:20
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Problems with reverse() in the array module

Details: When I was using Python-2.0b1, reverse() for arrays was acting funny for me:

>>> import array
>>> bob = array.array('c', 'a string')
>>> bob.reverse()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: <array>.reverse requires exactly 0 arguments

But, I didn't pass it any arguments :-).  When I looked at the code I came up with the following fix:

*** arraymodule.c.orig	Fri Sep  1 19:29:26 2000
--- arraymodule.c	Sat Sep  9 16:04:16 2000
***************
*** 935,945 ****
  	register char *p, *q;
  	char tmp[sizeof(double)]; /* Assume that's the max item size */
  
! 	if (args != NULL) {
! 		PyErr_SetString(PyExc_TypeError,
! 		     "<array>.reverse requires exactly 0 arguments");
! 		return NULL;
! 	}
  
  	if (self->ob_size > 1) {
  		for (p = self->ob_item,
--- 935,942 ----
  	register char *p, *q;
  	char tmp[sizeof(double)]; /* Assume that's the max item size */
  
! 	if (!PyArg_ParseTuple(args, ":reverse"))
! 	    return NULL;
  
  	if (self->ob_size > 1) {
  		for (p = self->ob_item,

Reverse seems to work properly with this:

>>> import array
>>> bob = array.array('c', 'a string')
>>> bob.reverse()
>>> print bob
array('c', 'gnirts a')

and the error message for passing argument seems reasonable:

>>> bob.reverse('spam')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: reverse requires exactly 0 arguments; 1 given

I'm really not an expert on any of this, but I hope the report is useful. Thanks for listening.

Brad

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113960&group_id=5470


From noreply@sourceforge.net  Sun Sep 10 02:04:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 9 Sep 2000 18:04:54 -0700
Subject: [Python-bugs-list] [Bug #110826] WebBugRptBroken &amp; &quot;Python mymalloc.h; not C++ compatible&quot; (PR#136)
Message-ID: <200009100104.SAA08918@delerium.i.sourceforge.net>

Bug #110826, was updated on 2000-Aug-01 14:11
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 5
Summary: WebBugRptBroken &amp; &quot;Python mymalloc.h; not C++ compatible&quot; (PR#136)

Details: Jitterbug-Id: 136
Submitted-By: Randall Hopper <aa8vb@yahoo.com>
Date: Wed, 24 Nov 1999 09:51:10 -0500
Version: None
OS: None

Just tried to submit this via the web interface which has worked in the
past.  This time, I got:

    The system encountered a fatal error

    After command: 
    Received: 

    The last error code was: Connection refused 

This was a non-private bug report, as usual.

Anyway, here's the bug report:

==============================================================================

aa8vb@yahoo.com
Python mymalloc.h; not C++ compatible
Randall Hopper
1.5.2
IRIX 6.5
Private: NO

I hit a problem trying to compile wxPython on IRIX 6.5.  The issue is NULL
should be "0" when compiling for C++.  The IRIX headers define it this way.
The Python mymalloc.h header doesn't.  A work-around is to require clients
to include stdio.h before including any Python header files, but this is a
hack.

Here's a snip from a recent Python post I made with a proposed fix:

------------------------------------------------------------------------------

...After a bit of grepping, the culprit seems to be Python (1.5.2):

     /usr/local/include/python1.5/mymalloc.h:

         #ifndef NULL
         #define NULL ((ANY *)0)
         #endif

...

It appears to me that the right fix is for Python's mymalloc.h, if it must
define NULL (does it?), be updated to be more C++ friendly.  E.g.:

         #ifndef NULL
         #  ifdef __cplusplus
         #    define NULL 0
         #  else
         #    define NULL ((ANY *)0)
         #  endif
         #endif

I'm assuming there's some reason we can't just #include <stdio.h> from 
mymalloc.h (?)

------------------------------------------------------------------------------

Thanks,

Randall


====================================================================
Audit trail:
Fri Dec 03 10:32:05 1999	guido	sent reply 1
Fri Dec 03 10:32:19 1999	guido	changed notes
Fri Dec 03 10:32:20 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:11
By: none

Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible" (PR#136)
Date: Fri Dec  3 10:32:05 1999

> I hit a problem trying to compile wxPython on IRIX 6.5.  The issue is NULL
> should be "0" when compiling for C++.  The IRIX headers define it this way.
> The Python mymalloc.h header doesn't.  A work-around is to require clients
> to include stdio.h before including any Python header files, but this is a
> hack.

Why is wxPython using mymalloc.h directly?  It should use Python.h,
which *does* include stdio.h first.

-------------------------------------------------------

Date: 2000-Aug-01 14:11
By: none

Comment:
From: "Robin Dunn" <robin@alldunn.com>
Subject: Re: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible" (PR#136)
Date: Wed, 8 Dec 1999 12:03:08 -0800

> ----- Forwarded message from Guido van Rossum <bugs-py@python.org> -----
>
> Date: Fri, 3 Dec 1999 10:32:03 -0500 (EST)
> From: Guido van Rossum <bugs-py@python.org>
> Subject: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible"
(PR#136)
>
> > I hit a problem trying to compile wxPython on IRIX 6.5.  The issue is
NULL
> > should be "0" when compiling for C++.  The IRIX headers define it this
way.
> > The Python mymalloc.h header doesn't.  A work-around is to require
clients
> > to include stdio.h before including any Python header files, but this is
a
> > hack.
>
> Why is wxPython using mymalloc.h directly?  It should use Python.h,
> which *does* include stdio.h first.
>
>
> ----- End forwarded message -----
>

wxPython does use Python.h and if I remember correctly, moving it to be the
first #include (to ensure that none of the wx or my headers were screwing
things up) didn't help Randall at all.  He had to put an #include <stdio.h>
before it.

--
Robin Dunn
Software Craftsman
robin@AllDunn.com
http://AllDunn.com/robin/
http://AllDunn.com/wxPython/  Check it out!



-------------------------------------------------------

Date: 2000-Aug-01 14:11
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Re: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible" (PR#136)
Date: Wed, 08 Dec 1999 17:04:30 -0500

> > ----- Forwarded message from Guido van Rossum <bugs-py@python.org> -----
> >
> > Date: Fri, 3 Dec 1999 10:32:03 -0500 (EST)
> > From: Guido van Rossum <bugs-py@python.org>
> > Subject: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible"
> (PR#136)
> >
> > > I hit a problem trying to compile wxPython on IRIX 6.5.  The issue is
> NULL
> > > should be "0" when compiling for C++.  The IRIX headers define it this
> way.
> > > The Python mymalloc.h header doesn't.  A work-around is to require
> clients
> > > to include stdio.h before including any Python header files, but this is
> a
> > > hack.
> >
> > Why is wxPython using mymalloc.h directly?  It should use Python.h,
> > which *does* include stdio.h first.
> >
> >
> > ----- End forwarded message -----
> >
> 
> wxPython does use Python.h and if I remember correctly, moving it to be the
> first #include (to ensure that none of the wx or my headers were screwing
> things up) didn't help Randall at all.  He had to put an #include <stdio.h>
> before it.

Strange.  I don't have your source so there's no point arguing about
it here.  Python.h definitely includes <stdio.h> before including
"mymalloc.h".  At least in 1.5(.x), I haven't checked older versions.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:11
By: none

Comment:
Maybe, maybe not.

-------------------------------------------------------

Date: 2000-Aug-06 10:33
By: twouters

Comment:
Looks like a "won't fix" to me, unless there is a good reason not to include Python.h. If you start including other python header files, you better know damn well what you're doing, and include the necessary files beforehand, yourself. But that's just me.
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-09 18:04
By: tim_one

Comment:
The checkin comment, applied to 2.0b1:

Close SF bug 110826:  a complaint about the way Python #define'd NULL.
It's hard to sort out what the bug was, exactly.  So, Big Hammer:

1. Python shouldn't be in the business of #define'ing NULL, period.
2. Users of the Python C API shouldn't be in the business of not including Python.h, period.

Hence:

1. Removed all #define's of NULL in Python source code (pyport.h and object.h).
2. Since we're *relying* on stdio.h defining NULL, put an #error in Python.h after its #include of stdio.h if NULL isn't defined then.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110826&group_id=5470


From noreply@sourceforge.net  Sun Sep 10 02:08:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 9 Sep 2000 18:08:37 -0700
Subject: [Python-bugs-list] [Bug #113960] Problems with reverse() in the array module
Message-ID: <200009100108.SAA09073@delerium.i.sourceforge.net>

Bug #113960, was updated on 2000-Sep-09 13:20
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 8
Summary: Problems with reverse() in the array module

Details: When I was using Python-2.0b1, reverse() for arrays was acting funny for me:

>>> import array
>>> bob = array.array('c', 'a string')
>>> bob.reverse()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: <array>.reverse requires exactly 0 arguments

But, I didn't pass it any arguments :-).  When I looked at the code I came up with the following fix:

*** arraymodule.c.orig	Fri Sep  1 19:29:26 2000
--- arraymodule.c	Sat Sep  9 16:04:16 2000
***************
*** 935,945 ****
  	register char *p, *q;
  	char tmp[sizeof(double)]; /* Assume that's the max item size */
  
! 	if (args != NULL) {
! 		PyErr_SetString(PyExc_TypeError,
! 		     "<array>.reverse requires exactly 0 arguments");
! 		return NULL;
! 	}
  
  	if (self->ob_size > 1) {
  		for (p = self->ob_item,
--- 935,942 ----
  	register char *p, *q;
  	char tmp[sizeof(double)]; /* Assume that's the max item size */
  
! 	if (!PyArg_ParseTuple(args, ":reverse"))
! 	    return NULL;
  
  	if (self->ob_size > 1) {
  		for (p = self->ob_item,

Reverse seems to work properly with this:

>>> import array
>>> bob = array.array('c', 'a string')
>>> bob.reverse()
>>> print bob
array('c', 'gnirts a')

and the error message for passing argument seems reasonable:

>>> bob.reverse('spam')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: reverse requires exactly 0 arguments; 1 given

I'm really not an expert on any of this, but I hope the report is useful. Thanks for listening.

Brad

Follow-Ups:

Date: 2000-Sep-09 18:08
By: tim_one

Comment:
Thanks!  Boosted the priority and assigned to me:  this is plain embarrassing -- the code couldn't possibly work as intended.  I'll fix it and add a regression test to the std test suite so it never happens again.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113960&group_id=5470


From noreply@sourceforge.net  Sun Sep 10 10:16:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 10 Sep 2000 02:16:02 -0700
Subject: [Python-bugs-list] [Bug #113828] getpythonregpath with null data in registry key
Message-ID: <200009100916.CAA24320@delerium.i.sourceforge.net>

Bug #113828, was updated on 2000-Sep-07 13:46
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 6
Summary: getpythonregpath with null data in registry key

Details: 
File pc/getpathp.c
Function:getpythonregpath

ppPaths[index] can be null but this fragment is not null protected:

len = _tcslen(ppPaths[index]);
_tcsncpy(szCur, ppPaths[index], len);

Grzegorz Makarewicz

Follow-Ups:

Date: 2000-Sep-08 23:31
By: tim_one

Comment:
Assigned to MarkH.  Offhand it looks like a legit complaint to me, and that the

len = _tcslen(ppPaths[index]);
_tcsncpy(szCur, ppPaths[index], len);
szCur += len;
dataSize -= len;

block should be protected against a null ppPaths[index].
-------------------------------------------------------

Date: 2000-Sep-10 02:16
By: mhammond

Comment:
Fixed in rev 1.21 of getpathp.c
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113828&group_id=5470


From noreply@sourceforge.net  Mon Sep 11 06:43:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 10 Sep 2000 22:43:55 -0700
Subject: [Python-bugs-list] [Bug #114027] Compiling on alpha-osf1v4: libpthreads is called libpthread
Message-ID: <200009110543.WAA02641@delerium.i.sourceforge.net>

Bug #114027, was updated on 2000-Sep-10 22:43
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Compiling on alpha-osf1v4: libpthreads is called libpthread

Details: change -lpthreads into -lpthread

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114027&group_id=5470


From noreply@sourceforge.net  Mon Sep 11 09:24:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 11 Sep 2000 01:24:15 -0700
Subject: [Python-bugs-list] [Bug #114033] re incompatibility in sre
Message-ID: <200009110824.BAA08118@delerium.i.sourceforge.net>

Bug #114033, was updated on 2000-Sep-11 01:24
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: re incompatibility in sre

Details: [submitted by Adam Sampson]

Under Python 1.5.2, I had a script containing the following line:

m = re.match(r"[a-z0-9]*://[^/]+/.*\.([^.#\?/]*)([#\?]?.*)?", url)

Under 1.6, this fails with:

[...]
  File "/usr/local/lib/python1.6/sre.py", line 44, in match                                              
    return _compile(pattern, flags).match(string)                                                        
  File "/usr/local/lib/python1.6/sre.py", line 102, in _compile                                          
    raise error, v # invalid expression                                                                  
sre_constants.error: nothing to repeat

I can narrow it down to:

>>> m = re.match(r"(x?)?", url)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.6/sre.py", line 44, in match
    return _compile(pattern, flags).match(string)
  File "/usr/local/lib/python1.6/sre.py", line 102, in _compile
    raise error, v # invalid expression
sre_constants.error: nothing to repeat

whereas:

>>> m = re.match(r"(x?.)?", url)

works fine. Is this correct behaviour for SRE, or am I just being stupid?
"(x?)?" looks like a perfectly reasonable Perl-style regexp to me (and Perl
too)...


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114033&group_id=5470


From noreply@sourceforge.net  Tue Sep 12 21:53:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 13:53:53 -0700
Subject: [Python-bugs-list] [Bug #114287] InPlace API needs refcount info
Message-ID: <200009122053.NAA24079@delerium.i.sourceforge.net>

Bug #114287, was updated on 2000-Sep-12 13:53
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: InPlace API needs refcount info

Details: The Doc/api/refcounts.dat file needs to be updated to include the InPlace API calls.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114287&group_id=5470


From noreply@sourceforge.net  Tue Sep 12 22:38:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 14:38:01 -0700
Subject: [Python-bugs-list] [Bug #114290] search_for_prefix failure on relative path
Message-ID: <200009122138.OAA08833@bush.i.sourceforge.net>

Bug #114290, was updated on 2000-Sep-12 14:38
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: search_for_prefix failure on relative path

Details: The code in getpath.c fails in Step 3 (search for the libraries using the argv0 path) when python is invoked with a relative path.  The search code should be able to join the relative path with the current working directory and find the landmark file.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114290&group_id=5470


From noreply@sourceforge.net  Tue Sep 12 22:44:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 14:44:14 -0700
Subject: [Python-bugs-list] [Bug #114030] 2.0b1: Module index empty
Message-ID: <200009122144.OAA09037@bush.i.sourceforge.net>

Bug #114030, was updated on 2000-Sep-11 00:36
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b1: Module index empty

Details: in the html-2.0b1 that I just downloaded, the module index in the
library reference manual is empty.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114030&group_id=5470


From noreply@sourceforge.net  Tue Sep 12 22:45:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 14:45:21 -0700
Subject: [Python-bugs-list] [Bug #114235] error in getgid()?
Message-ID: <200009122145.OAA09082@bush.i.sourceforge.net>

Bug #114235, was updated on 2000-Sep-12 00:33
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: error in getgid()?

Details: I have been trying to get mailman (http://www.list.org/)running properly on my linux server (redhat 6.2) with some success.

Mailman has the ability to recognise virtual domains so that only those lists pertaining to the domain you are looking at is displayed.

There is one slight error.  When the mailman program runs it checks the gid of the process that called it to ensure some security.  This works fine when the domain is set to the server *real* FQDN, but *not* if it is a virtual domain.  If I set the email address to the virtual domain I get a gid of 65534 (maximum for the machine).  See https://sourceforge.net/bugs/?func=detailbug&bug_id=111347&group_id=103 for more details on this bug.

I logged the error with the mailman project here on SF, but they said it was probably a sendmail issue.  I have looked at the code and it makes a "getgid()" call to python - so following the chain back the next stop is with python.

I don't know much about the language, but is python trying to check for the gid of the process under the virtual domain and not the real one?  Or is this really a sendmail issue?

I would be happy to supply more information if required.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114235&group_id=5470


From noreply@sourceforge.net  Tue Sep 12 22:44:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 14:44:35 -0700
Subject: [Python-bugs-list] [Bug #114033] re incompatibility in sre
Message-ID: <200009122144.OAA09047@bush.i.sourceforge.net>

Bug #114033, was updated on 2000-Sep-11 01:24
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: re incompatibility in sre

Details: [submitted by Adam Sampson]

Under Python 1.5.2, I had a script containing the following line:

m = re.match(r"[a-z0-9]*://[^/]+/.*\.([^.#\?/]*)([#\?]?.*)?", url)

Under 1.6, this fails with:

[...]
  File "/usr/local/lib/python1.6/sre.py", line 44, in match                                              
    return _compile(pattern, flags).match(string)                                                        
  File "/usr/local/lib/python1.6/sre.py", line 102, in _compile                                          
    raise error, v # invalid expression                                                                  
sre_constants.error: nothing to repeat

I can narrow it down to:

>>> m = re.match(r"(x?)?", url)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.6/sre.py", line 44, in match
    return _compile(pattern, flags).match(string)
  File "/usr/local/lib/python1.6/sre.py", line 102, in _compile
    raise error, v # invalid expression
sre_constants.error: nothing to repeat

whereas:

>>> m = re.match(r"(x?.)?", url)

works fine. Is this correct behaviour for SRE, or am I just being stupid?
"(x?)?" looks like a perfectly reasonable Perl-style regexp to me (and Perl
too)...


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114033&group_id=5470


From noreply@sourceforge.net  Tue Sep 12 22:46:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 14:46:16 -0700
Subject: [Python-bugs-list] [Bug #114245] utime can not accept directory under NT
Message-ID: <200009122146.OAA09092@bush.i.sourceforge.net>

Bug #114245, was updated on 2000-Sep-12 06:36
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: utime can not accept directory under NT

Details: Whenever supply a directory to utime path parameter, exception raised.  The problem is MS C run time library utime function only works on files, but not directories.  To fix this bug, MS utime has to be replaced by some function that works with directory.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114245&group_id=5470


From noreply@sourceforge.net  Tue Sep 12 22:48:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 14:48:14 -0700
Subject: [Python-bugs-list] [Bug #114256] Python 2.0b1, Win2K - urllib failure
Message-ID: <200009122148.OAA09236@bush.i.sourceforge.net>

Bug #114256, was updated on 2000-Sep-12 09:16
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python 2.0b1, Win2K - urllib failure

Details: This might be related to bug #110692, since it seems to be related to proxies.

A program I have that works under older versions of Python now fails with this traceback:


Traceback (most recent call last):
  File "IGNRatings.py", line 289, in ?
    main(sys.argv[1:])
  File "IGNRatings.py", line 133, in main
    inStream = urllib.urlopen(url)
  File "E:\Python20\lib\urllib.py", line 61, in urlopen
    return _urlopener.open(url)
  File "E:\Python20\lib\urllib.py", line 163, in open
    return getattr(self, name)(url)
  File "E:\Python20\lib\urllib.py", line 259, in open_http
    h = httplib.HTTP(host)
  File "E:\Python20\lib\httplib.py", line 624, in __init__
    self._conn = self._connection_class(host, port)
  File "E:\Python20\lib\httplib.py", line 324, in __init__
    self._set_hostport(host, port)
  File "E:\Python20\lib\httplib.py", line 330, in _set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int():


My URL is nothing special:

    'http://dreamcast.ign.com/review_lists/a.html'


I have tracked the problem down a bit:

In urllib.py, line 147, the statement

    proxy = self.proxies[type]

assigns the string

    'http://http://proxy:8080'

to "proxy". My guess is that's not right. Anyway, the following line assigns

    type = 'http'
    proxy = '//http://proxy:8080'

and the next line assigns

    host = 'http:'
    selector = '//proxy:8080'

'http:' as a host name then goes on to cause trouble when an HTTPConnection is constructed.

Hope this info helps you track it down.

Bob Alexander
bobalex@home.com

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114256&group_id=5470


From noreply@sourceforge.net  Tue Sep 12 22:48:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 14:48:08 -0700
Subject: [Python-bugs-list] [Bug #114030] 2.0b1: Module index empty
Message-ID: <200009122148.OAA09233@bush.i.sourceforge.net>

Bug #114030, was updated on 2000-Sep-11 00:36
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: 2.0b1: Module index empty

Details: in the html-2.0b1 that I just downloaded, the module index in the
library reference manual is empty.

Follow-Ups:

Date: 2000-Sep-12 14:48
By: fdrake

Comment:
Already fixed in the 2.0b1.1 documentation packages I just posted on pythonlabs.com!

Announcement coming out shortly.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114030&group_id=5470


From noreply@sourceforge.net  Tue Sep 12 23:13:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 15:13:13 -0700
Subject: [Python-bugs-list] [Bug #113803] [2.0b1 NT4.0] printing non asci char causes idle to abort
Message-ID: <200009122213.PAA27125@delerium.i.sourceforge.net>

Bug #113803, was updated on 2000-Sep-07 08:33
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: [2.0b1 NT4.0] printing non asci char causes idle to abort

Details: try:

alef = u'\u05d0'
print alef.encode('utf-8')

any enter after the last statement will cause idle to abort

on 'bare' python this does not cause any problem.

[tebeka@lycosmail.com]

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-12 15:13
By: gvanrossum

Comment:
Crash confirmed in IDLE on Win98SE.
Prints (expected) garbage and doesn't crash in command line on Win98SE.
No crash in IDLE or command line on Linux.

Tim, can you take a look with the VC debugger?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113803&group_id=5470


From noreply@sourceforge.net  Tue Sep 12 23:23:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 15:23:28 -0700
Subject: [Python-bugs-list] [Bug #114293] Unexpected Evaluation of Expressions from Pickle
Message-ID: <200009122223.PAA10564@bush.i.sourceforge.net>

From noreply@sourceforge.net  Tue Sep 12 23:32:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 15:32:47 -0700
Subject: [Python-bugs-list] [Bug #114294] Module Index Links don't work.
Message-ID: <200009122232.PAA27839@delerium.i.sourceforge.net>

Bug #114294, was updated on 2000-Sep-12 15:32
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Module Index Links don't work.

Details: Thank you for getting the Module Index back so quickly but now I notice that none of the Module Index links work in the Ref Manual. I click but nothing happens.
...Bob

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114294&group_id=5470


From noreply@sourceforge.net  Tue Sep 12 23:23:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 15:23:28 -0700
Subject: [Python-bugs-list] [Bug #114293] Unexpected Evaluation of Expressions from Pickle
Message-ID: <200009122223.PAA10564@bush.i.sourceforge.net>

Bug #114293, was updated on 2000-Sep-12 15:23
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Unexpected Evaluation of Expressions from Pickle

Details: It is possible to evaluate an expression through an improperly formatted pickled string:

    >>> import pickle 
    >>> pickle.loads("S3+3\012p0\012.")
    6

The same expression in "cPickle" will raise an exception: 

    >>> import cPickle
    >>> cPickle.loads("S3+3\012p0\012.")
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ValueError: insecure string pickle

The reason this occurs is that the string is brought into existence through a call to "eval".  This is made somewhat safe by removing all the built-in functions, but it is still possible to cause problems with a pure evaluation.  I will submit a patch within a few minutes that makes sure that the first character is either a single- or double-quote.

Would it be possible for someone to slip a code object instead of an expression?  Since we don't have access to the "marshal" module from here, I don't know how it would be done, but I am very concerned about the security implications of using pickle.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114293&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 00:10:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 16:10:07 -0700
Subject: [Python-bugs-list] [Bug #114296] distutils documentation out of date
Message-ID: <200009122310.QAA12227@bush.i.sourceforge.net>

Bug #114296, was updated on 2000-Sep-12 15:55
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: distutils documentation out of date

Details: Chapter 3 describes how to build extension modules.  It says to use the keyword argument extensions with the setup function, e.g.

setup(extensions=[Extension("foo", ...)])

This causes an error at runtime because the argument "extensions" is unknown.  Apparently, ext_modules works...


Follow-Ups:

Date: 2000-Sep-12 16:10
By: none

Comment:
Fixed in CVS.  Will show up in the docs on the web site in a few days (after I make some more updates).

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114296&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 00:08:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 16:08:20 -0700
Subject: [Python-bugs-list] [Bug #114235] error in getgid()?
Message-ID: <200009122308.QAA29123@delerium.i.sourceforge.net>

Bug #114235, was updated on 2000-Sep-12 00:33
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: error in getgid()?

Details: I have been trying to get mailman (http://www.list.org/)running properly on my linux server (redhat 6.2) with some success.

Mailman has the ability to recognise virtual domains so that only those lists pertaining to the domain you are looking at is displayed.

There is one slight error.  When the mailman program runs it checks the gid of the process that called it to ensure some security.  This works fine when the domain is set to the server *real* FQDN, but *not* if it is a virtual domain.  If I set the email address to the virtual domain I get a gid of 65534 (maximum for the machine).  See https://sourceforge.net/bugs/?func=detailbug&bug_id=111347&group_id=103 for more details on this bug.

I logged the error with the mailman project here on SF, but they said it was probably a sendmail issue.  I have looked at the code and it makes a "getgid()" call to python - so following the chain back the next stop is with python.

I don't know much about the language, but is python trying to check for the gid of the process under the virtual domain and not the real one?  Or is this really a sendmail issue?

I would be happy to supply more information if required.

Follow-Ups:

Date: 2000-Sep-12 15:42
By: bwarsaw

Comment:
I'm not sure what you mean by "it makes a getgid() call to python".  The gid security test in Mailman is only done in the C wrapper, specifically in the check_caller() function in src/common.c in the Mailman distro.  Python don't enter into it, to paraphrase Mr. Praline. :)

I don't know anything about how sendmail handles virtual domains, but my guess is that for some reason, sendmail is invoking it's filter scripts with different gids depending on the virtual domain.  There's a very easy way to test this.

Download patch #101485 from SF.  This is actually a program which you should compile and place in a location accessible to sendmail (e.g. /etc/smrsh).  Then set sendmail up to filter to this program by including a line such as the following in your aliases file:

mytest: "/tmp/filter"

This will bounce the message back to you, but in the bounce message it will contain the real and effective group id's sendmail is invoking the program under.  See if they differ depending on the virtual domain you use.  If so, it must be a sendmail bug.
-------------------------------------------------------

Date: 2000-Sep-12 16:08
By: askegg

Comment:
Yep.  The check_caller() function makes the "getgid()" call;

check_caller(const char* ident, GID_T parentgid)
{
	GID_T mygid = getgid();
	if (parentgid != mygid) {
.....

The getgid() call is summarised here http://www.python.org/doc/2.0b1/lib/os-procinfo.html as "getgid () Return the current process' group id. Availability: Unix. "

I will download the patch you suggest and see what happens.

Let you know.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114235&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 00:13:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 16:13:58 -0700
Subject: [Python-bugs-list] [Bug #114296] distutils documentation out of date
Message-ID: <200009122313.QAA12415@bush.i.sourceforge.net>

Bug #114296, was updated on 2000-Sep-12 15:55
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: distutils documentation out of date

Details: Chapter 3 describes how to build extension modules.  It says to use the keyword argument extensions with the setup function, e.g.

setup(extensions=[Extension("foo", ...)])

This causes an error at runtime because the argument "extensions" is unknown.  Apparently, ext_modules works...


Follow-Ups:

Date: 2000-Sep-12 16:10
By: none

Comment:
Fixed in CVS.  Will show up in the docs on the web site in a few days (after I make some more updates).

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114296&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 00:15:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 16:15:38 -0700
Subject: [Python-bugs-list] [Bug #113106] distutils' msvccompiler.py has small C++ defects
Message-ID: <200009122315.QAA12439@bush.i.sourceforge.net>

Bug #113106, was updated on 2000-Aug-30 04:57
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: distutils' msvccompiler.py has small C++ defects

Details: At least in 1.6b1, the msvccompiler.py module of distutils
has a couple of lacks in C++ support, that show up strongly at least when building the "CXX" extension (I also submitted those to the CXX group, but there's little they can do about them, I think).

a) .cxx is not a recognized extension -- it should be listed together with .cc and .cpp, as it's quite common (and it's the one used by the CXX group, as it happens).
Falling-off-a-log-easy to fix.

b) the /GX switch is not given when building C++ sources, which causes (at the very least) warnings from the standard C++ library headers, erroneous handling of exceptions, etc.
Pretty easy to fix as each sourcefile is being separately identified as C++ or C source, just no use is being made of this yet to select the compilation options (I think /gx should be mandatory for C++ sources to give behavior closer to C++ standard, make C++ standard library usable, etc; /gr
for RTTI is a harder decision as it imposes some overhead).


Alex


Follow-Ups:

Date: 2000-Aug-30 10:34
By: gward

Comment:
OK, the .cxx extension was easy to add -- done and checked in.

I'm not sure how to deal with /GX, though: is it OK to include this option when compiling C code?  If so, it's a snap: just add it to the 'compile_options' attribute.  If not, it's a wee bit trickier.  Can you try compiling a C extension with /GX and see what happens?

Here's what Microsoft's online docs say:

"""
/GX   (Enable Exception Handling)

This option enables synchronous exception handling with the assumption that extern C functions never throw an exception. It is now equivalent to /EHsc.

For more information, see Exception Handling Topics (C++).
"""

That's at: http://msdn.microsoft.com/library/devprods/vs6/visualc/vccore/_core_.2f.gx.htm

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113106&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 00:52:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 16:52:59 -0700
Subject: [Python-bugs-list] [Bug #113785] SIGSEGV in PyDict_SetItem
Message-ID: <200009122352.QAA13822@bush.i.sourceforge.net>

Bug #113785, was updated on 2000-Sep-07 01:51
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Works For Me
Bug Group: 3rd Party
Priority: 5
Summary: SIGSEGV in PyDict_SetItem

Details: On a PC running FreeBSD 3.5
Python 1.5.2 (#1, Aug 23 2000, 10:14:09)  [GCC 2.95 19990728 (release)] on freebsd3
 I installed Python to run a filter that comes with inn 2.3.0 (usenet News)

Some time the fiter written in Python hangs with the following (from gdb)
Program received signal SIGSEGV, Segmentation fault.
0x810465b in PyDict_SetItem (op=0x83c6a80, key=0x83d4020, value=0x0)
    at dictobject.c:375
375             Py_INCREF(value);

I suspect that the Python filter may be 
#
# $Id: filter_innd.py,v 1.2 1999/09/23 14:24:23 kondou Exp $
#
# This is a sample filter for the Python innd hook.
#
# For details, see the file README.python_hook that came with INN.
#

import re
from string import *

# This looks weird, but creating and interning these strings should
# let us get faster access to header keys (which innd also interns) by
# losing some strcmps under the covers.
Approved = intern("Approved");           Control = intern("Control")
Date = intern("Date");                   Distribution = intern("Distribution")
Expires = intern("Expires");             From = intern("From")
Lines = intern("Lines");                 Message_ID = intern("Message-ID")
Newsgroups = intern("Newsgroups");       Path = intern("Path")
Reply_To = intern("Reply-To");           Sender = intern("Sender")
Subject = intern("Subject");             Supersedes = intern("Supersedes")
Bytes = intern("Bytes");                 Also_Control = intern("Also-Control")
References = intern("References");       Xref = intern("Xref")
Keywords = intern("Keywords");           X_Trace = intern("X-Trace")
NNTP_Posting_Host = intern("NNTP-Posting-Host")
Followup_To = intern("Followup-To");     Organization = intern("Organization")
Content_Type = intern("Content-Type");   Content_Base = intern("Content-Base")
Content_Disposition = intern("Content-Disposition")
X_Newsreader = intern("X-Newsreader");   X_Mailer = intern("X-Mailer")
X_Newsposter = intern("X-Newsposter")
X_Cancelled_By = intern("X-Cancelled-By")
X_Canceled_By = intern("X-Canceled-By"); Cancel_Key = intern("Cancel-Key")
__BODY__ = intern("__BODY__");           __LINES__ = intern("__LINES__")


class InndFilter:
    """Provide filtering callbacks to innd."""

    def __init__(self):
        """This runs every time the filter is loaded or reloaded.

        This is a good place to initialize variables and precompile
        regular expressions, or maybe reload stats from disk.
        """
        self.re_newrmgroup = re.compile('(?:new|rm)group\s')
        self.re_obsctl = re.compile('(?:sendsys|version|uuname)')
        # msgid  pattern from a once-common spambot.
        self.re_none44 = re.compile('none\d+\.yet>')
        # There is a mad newgrouper who likes to meow.
        self.re_meow = re.compile("^Meow\!", re.M)
        # One of my silly addresses.
        self.re_fluffymorph = re.compile("andruQ@myremarQ.coM", re.I)

    def filter_before_reload(self):
        """Runs just before the filter gets reloaded.

        You can use this method to save state information to be
        restored by the __init__() method or down in the main module.
        """
        syslog('notice', "filter_before_reload executing...")

    def filter_close(self):
        """Runs when innd exits.

        You can use this method to save state information to be
        restored by the __init__() method or down in the main module.
        """
        syslog('notice', "filter_close running, bye!")

    def filter_messageid(self, msgid):
        """Filter articles just by their message IDs.

        This method interacts with the IHAVE and CHECK NNTP commands.
        If you return a non-empty string here, the offered article
        will be refused before you ever have to waste any bandwidth
        looking at it.  This is not foolproof, so you should do your
        ID checks both here and in filter_art.  (TAKETHIS does not
        offer the ID for examination, and a TAKETHIS isn't always
        preceded by a CHECK.)
        """
        return ""               # deactivate the samples.
        
        if self.re_none44.search(msgid):
            return "But I don't like spam!"
        if msgid[0:8] == '<cancel.':
            return "I don't do cybercancels."

    def filter_art(self, art):
        """Decide whether to keep offered articles.

        art is a dictionary with a bunch of headers, the article's
        body, and innd's reckoning of the line count.  Itens not
        in the article will have a value of None.

        The available headers are the ones listed near the top of
        innd/art.c.  At this writing, they are:

            Approved, Control, Date, Distribution, Expires, From,
            Lines, Message-ID, Newsgroups, Path, Reply-To, Sender,
            Subject, Supersedes, Bytes, Also-Control, References,
            Xref, Keywords, X-Trace, NNTP-Posting-Host, Folowup-To,
            Organization, Content-Type, Content-Base,
            Content-Disposition, X-Newsreader, X-Mailer, X-Newsposter,
            X-Cancelled-By, X-Canceled-By and Cancel-Key.

        The body is the buffer in art['__BODY__'] and the INN-reckoned
        line count is held as an integer in art['__LINES__'].  (The
        Lines: header is often generated by the poster, and large
        differences can be a good indication of a corrupt article.)

        If you want to keep an article, return None or "".  If you
        want to reject, return a non-empty string.  The rejection
        string will appear in transfer and posting response banners,
        and local posters will see them if their messages are
        rejected.
        """
        return ""               # deactivate the samples.

        # catch bad IDs from articles fed with TAKETHIS but no CHECK.
        idcheck = self.filter_messageid(art[Message_ID])
        if idcheck:
            return idcheck

        # There are some control messages we don't want to process or
        # forward to other sites.
        try:
            if art[Control] is not None:
                if self.re_newrmgroup.match(art[Control]):
                    if self.re_meow.search(art[__BODY__]):
                        return "The fake tale meows again."
                    if art[Distribution] == buffer('mxyzptlk'):
                        return "Evil control message from the 10th dimension"
                if self.re_obsctl.match(art[Control]):
                    return "Obsolete control message"

            # If you don't know, you don't want to know.
            if self.re_fluffymorph.search(art[From]):
                return "No, you may NOT meow."
        except:
            syslog('n', str(sys.exc_info[1]))

    def filter_mode(self, oldmode, newmode, reason):
        """Capture server events and do something useful.

        When the admin throttles or pauses innd (and lets it go
        again), this method will be called.  oldmode is the state we
        just left, and newmode is where we are going.  reason is
        usually just a comment string.

        The possible values of newmode and oldmode are the four
        strings 'running', 'paused', 'throttled' and 'unknown'.
        Actually 'unknown' shouldn't happen, it's there in case
        feeping creatures invade innd.
        """
        syslog('notice', 'state change from %s to %s - %s'
               % (oldmode, newmode, reason))



"""
Okay, that's the end of our class definition.  What follows is the
stuff you need to do to get it all working inside innd.
"""

# This import must succeed, or your filter won't work.  I'll repeat
# that: You MUST import INN.
from INN import *


#   Some of the stuff below is gratuitous, just demonstrating how the
#   INN.syslog call works.  That first thingy tells the Unix syslogger
#   what severity to use; you can abbreviate down to one letter and
#   it's case insensitive.  Available levels are (in increasing levels
#   of seriousness) Debug, Info, Notice, Warning, Err, Crit, and
#   Alert.  If you provide any other string, it will be defaulted to
#   Notice.  You'll find the entries in the same log files innd itself
#   uses, with an 'innd: python:' prefix.
#
#   The native Python syslog module seems to clash with INN, so use
#   INN's.  Oh yeah -- you may notice that stdout and stderr have been
#   redirected to /dev/null -- if you want to print stuff, open your
#   own files.

try:
    import sys
except Exception, errmsg:
    syslog('Error', "import boo-boo: " + errmsg[0])


#     If you want to do something special when the server first starts
#     up, this is how to find out when it's time.

if 'spamfilter' not in dir():
    syslog ('n', "First load, so I can do initialization stuff.")
    #  You could unpickle a saved hash here, so that your hard-earned
    #  spam scores aren't lost whenver you shut down innd.
else:
    syslog ('NoTicE', "I'm just reloading, so skip the formalities.")


#  Finally, here is how we get our class on speaking terms with innd.
#  The hook is refreshed on every reload, so that you can change the
#  methods on a running server.  Don't forget to test your changes
#  before reloading!
spamfilter = InndFilter()
try:
    set_filter_hook(spamfilter)
    syslog('n', "spamfilter successfully hooked into INN")
except Exception, errmsg:
    syslog('e', "Cannot obtain INN hook for spamfilter: %s" % errmsg[0])



And the data would be something like:
        takethis <967664873.12710.1.nnrp-02.9e98fa8b@news.demon.co.uk>\r
        Path: news.nectec.or.th!news.loxinfo.co.th!news-out.cwix.com!newsfeed.\
        cwix.com!newsfeeds.belnet.be!news.belnet.be!newsgate.cistron.nl!bullse\
        ye.news.demon.net!demon!news.demon.co.uk!demon!inert.demon.co.uk!not-f\
        or-mail\r
        From: inert@inert.demon.co.uk\r
        Newsgroups: rec.music.industrial\r
        Subject: *** CLUB NOIR ***  31/8/00\r
        Date: Wed, 30 Aug 2000 19:47:53 GMT\r
        Organization: inertia\r
        Message-ID: <967664873.12710.1.nnrp-02.9e98fa8b@news.demon.co.uk>\r
        NNTP-Posting-Host: inert.demon.co.uk\r
        X-NNTP-Posting-Host: inert.demon.co.uk:158.152.250.139\r
        X-Trace: news.demon.co.uk 967664873 nnrp-02:12710 NO-IDENT inert.demon\
        .co.uk:158.152.250.139\r
        X-Complaints-To: abuse@demon.net\r
        X-Mailer: Mozilla 1.22 (Windows; I; 16bit)\r
        MIME-Version: 1.0\r
        Lines: 0\r
        Xref: news.nectec.or.th rec.music.industrial:137401\r
        \r
        .\r

So, for an easy solution, I can disable Python filtering and then inn will be working fine.
But even if the filter was not doing what it is supposed to do, Python should not SIGSEGV I presume.

Beside Python installed without problem and make test result is:
42 tests OK.
19 tests skipped: test_al test_audioop test_bsddb test_cd test_cl test_crypt test_dbm test_dl test_gdbm test_gl test_gzip test_imageop test_imgfile test_nis test_rgbimg test_sunaudiodev test_thread test_timing test_zlib

For more info: on@cs.ait.ac.th

Thank you,

Olivier

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-12 16:52
By: gvanrossum

Comment:
I'm closing this because I have not enough information, and I have no way to reproduce the problem. If you provide more information I'll gladly reopen it.

Some questions:
- How does inn invoke Python? Does it embed Python or does it run Python as a subprocess? Is there any INN specific extension C code?
- What's in the INN module?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113785&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 02:37:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 18:37:49 -0700
Subject: [Python-bugs-list] [Bug #114235] error in getgid()?
Message-ID: <200009130137.SAA03340@delerium.i.sourceforge.net>

Bug #114235, was updated on 2000-Sep-12 00:33
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: error in getgid()?

Details: I have been trying to get mailman (http://www.list.org/)running properly on my linux server (redhat 6.2) with some success.

Mailman has the ability to recognise virtual domains so that only those lists pertaining to the domain you are looking at is displayed.

There is one slight error.  When the mailman program runs it checks the gid of the process that called it to ensure some security.  This works fine when the domain is set to the server *real* FQDN, but *not* if it is a virtual domain.  If I set the email address to the virtual domain I get a gid of 65534 (maximum for the machine).  See https://sourceforge.net/bugs/?func=detailbug&bug_id=111347&group_id=103 for more details on this bug.

I logged the error with the mailman project here on SF, but they said it was probably a sendmail issue.  I have looked at the code and it makes a "getgid()" call to python - so following the chain back the next stop is with python.

I don't know much about the language, but is python trying to check for the gid of the process under the virtual domain and not the real one?  Or is this really a sendmail issue?

I would be happy to supply more information if required.

Follow-Ups:

Date: 2000-Sep-12 15:42
By: bwarsaw

Comment:
I'm not sure what you mean by "it makes a getgid() call to python".  The gid security test in Mailman is only done in the C wrapper, specifically in the check_caller() function in src/common.c in the Mailman distro.  Python don't enter into it, to paraphrase Mr. Praline. :)

I don't know anything about how sendmail handles virtual domains, but my guess is that for some reason, sendmail is invoking it's filter scripts with different gids depending on the virtual domain.  There's a very easy way to test this.

Download patch #101485 from SF.  This is actually a program which you should compile and place in a location accessible to sendmail (e.g. /etc/smrsh).  Then set sendmail up to filter to this program by including a line such as the following in your aliases file:

mytest: "/tmp/filter"

This will bounce the message back to you, but in the bounce message it will contain the real and effective group id's sendmail is invoking the program under.  See if they differ depending on the virtual domain you use.  If so, it must be a sendmail bug.
-------------------------------------------------------

Date: 2000-Sep-12 16:08
By: askegg

Comment:
Yep.  The check_caller() function makes the "getgid()" call;

check_caller(const char* ident, GID_T parentgid)
{
	GID_T mygid = getgid();
	if (parentgid != mygid) {
.....

The getgid() call is summarised here http://www.python.org/doc/2.0b1/lib/os-procinfo.html as "getgid () Return the current process' group id. Availability: Unix. "

I will download the patch you suggest and see what happens.

Let you know.

-------------------------------------------------------

Date: 2000-Sep-12 18:37
By: askegg

Comment:
This is weird.
I have done as you suggested and when mail is sent to test@real.domainname I get :

   ----- Transcript of session follows -----
real gid = 12, effective gid = 12
554 "| /tmp/id" ... unknown mailer error 1

Ok - cool.
However, when I send it to test@virtual.domainname I get nothing.  The maillog reports :

Sep 13 11:25:25 svr1 sendmail[32047]: LAA32045: to=<test@virtual.domainname>, delay=00:00:01, xdelay=00:00:00, mailer=virtual, relay=virtual.domainname, stat=Sent

So when sendmail tries to deliver the mail under the real domain it sees the error and returns the mail, but if it under a virtual domain it must assume everything is ok and ignores any errors that may occur (?).

Looks like this is a sendmail issue .....

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114235&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 02:40:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 18:40:54 -0700
Subject: [Python-bugs-list] [Bug #114235] error in getgid()?
Message-ID: <200009130140.SAA03444@delerium.i.sourceforge.net>

Bug #114235, was updated on 2000-Sep-12 00:33
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: error in getgid()?

Details: I have been trying to get mailman (http://www.list.org/)running properly on my linux server (redhat 6.2) with some success.

Mailman has the ability to recognise virtual domains so that only those lists pertaining to the domain you are looking at is displayed.

There is one slight error.  When the mailman program runs it checks the gid of the process that called it to ensure some security.  This works fine when the domain is set to the server *real* FQDN, but *not* if it is a virtual domain.  If I set the email address to the virtual domain I get a gid of 65534 (maximum for the machine).  See https://sourceforge.net/bugs/?func=detailbug&bug_id=111347&group_id=103 for more details on this bug.

I logged the error with the mailman project here on SF, but they said it was probably a sendmail issue.  I have looked at the code and it makes a "getgid()" call to python - so following the chain back the next stop is with python.

I don't know much about the language, but is python trying to check for the gid of the process under the virtual domain and not the real one?  Or is this really a sendmail issue?

I would be happy to supply more information if required.

Follow-Ups:

Date: 2000-Sep-12 15:42
By: bwarsaw

Comment:
I'm not sure what you mean by "it makes a getgid() call to python".  The gid security test in Mailman is only done in the C wrapper, specifically in the check_caller() function in src/common.c in the Mailman distro.  Python don't enter into it, to paraphrase Mr. Praline. :)

I don't know anything about how sendmail handles virtual domains, but my guess is that for some reason, sendmail is invoking it's filter scripts with different gids depending on the virtual domain.  There's a very easy way to test this.

Download patch #101485 from SF.  This is actually a program which you should compile and place in a location accessible to sendmail (e.g. /etc/smrsh).  Then set sendmail up to filter to this program by including a line such as the following in your aliases file:

mytest: "/tmp/filter"

This will bounce the message back to you, but in the bounce message it will contain the real and effective group id's sendmail is invoking the program under.  See if they differ depending on the virtual domain you use.  If so, it must be a sendmail bug.
-------------------------------------------------------

Date: 2000-Sep-12 16:08
By: askegg

Comment:
Yep.  The check_caller() function makes the "getgid()" call;

check_caller(const char* ident, GID_T parentgid)
{
	GID_T mygid = getgid();
	if (parentgid != mygid) {
.....

The getgid() call is summarised here http://www.python.org/doc/2.0b1/lib/os-procinfo.html as "getgid () Return the current process' group id. Availability: Unix. "

I will download the patch you suggest and see what happens.

Let you know.

-------------------------------------------------------

Date: 2000-Sep-12 18:37
By: askegg

Comment:
This is weird.
I have done as you suggested and when mail is sent to test@real.domainname I get :

   ----- Transcript of session follows -----
real gid = 12, effective gid = 12
554 "| /tmp/id" ... unknown mailer error 1

Ok - cool.
However, when I send it to test@virtual.domainname I get nothing.  The maillog reports :

Sep 13 11:25:25 svr1 sendmail[32047]: LAA32045: to=<test@virtual.domainname>, delay=00:00:01, xdelay=00:00:00, mailer=virtual, relay=virtual.domainname, stat=Sent

So when sendmail tries to deliver the mail under the real domain it sees the error and returns the mail, but if it under a virtual domain it must assume everything is ok and ignores any errors that may occur (?).

Looks like this is a sendmail issue .....

-------------------------------------------------------

Date: 2000-Sep-12 18:40
By: bwarsaw

Comment:
I think it's more likely that the virtual domain is not invoking the program correctly.  The program can do only one thing: print the message and fail (i.e. exit code 1).

I agree, it must be a sendmail issue, so I'm closing this as a bug report on Python.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114235&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 02:48:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 18:48:03 -0700
Subject: [Python-bugs-list] [Bug #114304] wm_resizable should return a tuple.
Message-ID: <200009130148.SAA03857@delerium.i.sourceforge.net>

Bug #114304, was updated on 2000-Sep-12 18:48
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: wm_resizable should return a tuple.

Details: wm_resizable returns two values - a 0/1 for width and 0/1 for height.  Currently, a string is returned with the 
values separated by a blank.  It would be more consistent
if a tuple were returned.

The code to do that follows:

def wm_resizable(self, width=None, height=None):
       return self._getints(
                        self.tk.call('wm', 'resizable',                                 self._w, width, height))


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114304&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 03:20:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 19:20:55 -0700
Subject: [Python-bugs-list] [Bug #114290] search_for_prefix failure on relative path
Message-ID: <200009130220.TAA05431@delerium.i.sourceforge.net>

Bug #114290, was updated on 2000-Sep-12 14:38
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: search_for_prefix failure on relative path

Details: The code in getpath.c fails in Step 3 (search for the libraries using the argv0 path) when python is invoked with a relative path.  The search code should be able to join the relative path with the current working directory and find the landmark file.


Follow-Ups:

Date: 2000-Sep-12 19:20
By: fdrake

Comment:
Barry, didn't you write most of the current code to locate the installation?  If not, assign it to whoever did.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114290&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 03:30:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 19:30:34 -0700
Subject: [Python-bugs-list] [Bug #114304] wm_resizable should return a tuple.
Message-ID: <200009130230.TAA19311@bush.i.sourceforge.net>

Bug #114304, was updated on 2000-Sep-12 18:48
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: Wont Fix
Bug Group: Feature Request
Priority: 5
Summary: wm_resizable should return a tuple.

Details: wm_resizable returns two values - a 0/1 for width and 0/1 for height.  Currently, a string is returned with the 
values separated by a blank.  It would be more consistent
if a tuple were returned.

The code to do that follows:

def wm_resizable(self, width=None, height=None):
       return self._getints(
                        self.tk.call('wm', 'resizable',                                 self._w, width, height))


Follow-Ups:

Date: 2000-Sep-12 19:30
By: fdrake

Comment:
It probably should return a tuple, but fixing this would break API compatibility; wm_resizable() has been there a while!

At some point, Tkinter needs to be thoroughly reviewed for methods that have issues similar to this and be modified to return the right thing.  This should result in a new module, not an API change in Tkinter.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114304&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 03:33:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 19:33:55 -0700
Subject: [Python-bugs-list] [Bug #114294] Module Index Links don't work.
Message-ID: <200009130233.TAA19472@bush.i.sourceforge.net>

Bug #114294, was updated on 2000-Sep-12 15:32
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Works For Me
Bug Group: Irreproducible
Priority: 5
Summary: Module Index Links don't work.

Details: Thank you for getting the Module Index back so quickly but now I notice that none of the Module Index links work in the Ref Manual. I click but nothing happens.
...Bob

Follow-Ups:

Date: 2000-Sep-12 19:33
By: fdrake

Comment:
You didn't state what browser you were using, or whether you were using the online version of a local copy.  They work for me; please confirm the behavior and send more information if you think we should re-open this bug report.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114294&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 03:45:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 19:45:01 -0700
Subject: [Python-bugs-list] [Bug #113803] [2.0b1 NT4.0] printing non asci char causes idle to abort
Message-ID: <200009130245.TAA06653@delerium.i.sourceforge.net>

Bug #113803, was updated on 2000-Sep-07 08:33
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: [2.0b1 NT4.0] printing non asci char causes idle to abort

Details: try:

alef = u'\u05d0'
print alef.encode('utf-8')

any enter after the last statement will cause idle to abort

on 'bare' python this does not cause any problem.

[tebeka@lycosmail.com]

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-12 15:13
By: gvanrossum

Comment:
Crash confirmed in IDLE on Win98SE.
Prints (expected) garbage and doesn't crash in command line on Win98SE.
No crash in IDLE or command line on Linux.

Tim, can you take a look with the VC debugger?

-------------------------------------------------------

Date: 2000-Sep-12 19:45
By: tim_one

Comment:
Changed group to platform-specific.

Note that this is a simpler test case w/ the same symptom:

print "\327\220"

Don't know why, do know that _tkinter.pyd and tk83.dll crap out w/ page faults at the end, assigned to Fredrik on the chance he's bumped into this before.  /F, bounce it back at me if it's unclear to you.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113803&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 05:59:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 21:59:56 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200009130459.VAA25091@bush.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 13:45
By: fdrake

Comment:
We need to know the output of "uname -s" and "uname -r" for this system.  (If "uname -r" reports an error, please try "uname -v".)

Are you willing to test a modified configure script on this platform?

What additional library is required for the mmap module?
-------------------------------------------------------

Date: 2000-Sep-12 21:59
By: fdrake

Comment:
Received the following response from Daniel Dittmar <ddittmar@users.sourceforge.net>:

> We need to know the output of "uname -s" and "uname -r" 
> for this system.  (If "uname -r" reports an error, please 
> try "uname -v".)

uname -s
ReliantUNIX-N

uname -r
5.45


> Are you willing to test a modified configure script on
> this platform?

sure.

> What additional library is required for the mmap module?

The man page states -lucb. This didn't work on my machine 
as the BSD compatibility layer is not active. I tell you 
more as soon as I know how to activate it.

***********

Another problem: to detect pthreads, the compiler must be 
called with -Kpthread. Otherwise, pthread.h goes into a 
branch where it tries to include a non existent header, 
fails, and configure reports 'no pthreads'.

Daniel

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 07:38:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Sep 2000 23:38:00 -0700
Subject: [Python-bugs-list] [Bug #113803] [2.0b1 NT4.0] printing non asci char causes idle to abort
Message-ID: <200009130638.XAA29576@bush.i.sourceforge.net>

Bug #113803, was updated on 2000-Sep-07 08:33
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: [2.0b1 NT4.0] printing non asci char causes idle to abort

Details: try:

alef = u'\u05d0'
print alef.encode('utf-8')

any enter after the last statement will cause idle to abort

on 'bare' python this does not cause any problem.

[tebeka@lycosmail.com]

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-12 15:13
By: gvanrossum

Comment:
Crash confirmed in IDLE on Win98SE.
Prints (expected) garbage and doesn't crash in command line on Win98SE.
No crash in IDLE or command line on Linux.

Tim, can you take a look with the VC debugger?

-------------------------------------------------------

Date: 2000-Sep-12 19:45
By: tim_one

Comment:
Changed group to platform-specific.

Note that this is a simpler test case w/ the same symptom:

print "\327\220"

Don't know why, do know that _tkinter.pyd and tk83.dll crap out w/ page faults at the end, assigned to Fredrik on the chance he's bumped into this before.  /F, bounce it back at me if it's unclear to you.
-------------------------------------------------------

Date: 2000-Sep-12 23:38
By: tim_one

Comment:
Bad news:  this doesn't always fail in the debugger (sometimes it just prints an alef glyph and nothing odd happens at all).

Better news:  it usually fails, and when it does it dies here (_tkinter.c):

static char *
AsString(PyObject *value, PyObject *tmp)
{
	if (PyString_Check(value))
		return PyString_AsString(value);
	else {
		PyObject *v = PyObject_Str(value);
		PyList_Append(tmp, v);
		Py_DECREF(v);
		return PyString_AsString(v);
	}
}

It's in the "else" branch, v is NULL, and the Py_DECREF expansion blows up with an access violation.  Py_ObjectStr certainly *can* return NULL, and I don't understand the intent of this code well enough to know why it believes that needn't be guarded against.

"value" at this point has type PyUnicode_Type.  For whatever reason, the debugger won't let me cast it to a PyUnicodeObject*.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113803&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 08:39:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 00:39:31 -0700
Subject: [Python-bugs-list] [Bug #114318] References to Python 1.5
Message-ID: <200009130739.AAA31711@bush.i.sourceforge.net>

Bug #114318, was updated on 2000-Sep-13 00:39
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: Not a Bug
Priority: 5
Summary: References to Python 1.5

Details: In the documentation, there are references to Python's library path that often use "/usr/local/lib/python1.5" instead of "/usr/local/lib/python2.0".  A quick "find" and "grep" shows the following pages:

    ./api/embedding.html
    ./api/includes.html
    ./dist/node13.html
    ./lib/module-pdb.html
    ./lib/module-pprint.html
    ./lib/module-site.html
    ./lib/profile-instant.html
    ./lib/typesmodules.html

The only one that might be a problem is "./lib/module-site.html", since it mentions Python 2.0b1.1 explicitly and states that its library is installed in "python1.5".

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114318&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 10:16:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 02:16:40 -0700
Subject: [Python-bugs-list] [Bug #114323] Pb PYTHON
Message-ID: <200009130916.CAA22338@delerium.i.sourceforge.net>

Bug #114323, was updated on 2000-Sep-13 02:16
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Pb PYTHON

Details: 

Find the encoutered problem when we are running python interactively with the following commands

python
>>> from Tkinter import *
>>> root=Tk()
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.5/lib-tk/Tkinter.py", line 886, in __init__
    self.tk = _tkinter.create(screenName, baseName, className)
TclError: Can't find a usable init.tcl in the following directories: 
    
We have compile python on SUN ULTRA 60 - Solaris 2.6 with GCC using the building and installing commndes 
found in the book Python and Tkinter
Please send me a mail as soon as possible






This probably means that Tcl wasn't installed properly.

>>> 


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114323&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 10:20:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 02:20:35 -0700
Subject: [Python-bugs-list] [Bug #114324] Minor build problems on HPUX for 2.0b1
Message-ID: <200009130920.CAA22410@delerium.i.sourceforge.net>

Bug #114324, was updated on 2000-Sep-13 02:20
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Minor build problems on HPUX for 2.0b1

Details: Build problems on HPUX10.20/HPUX11.00:

  - There seems to be no prototype for "fdatasync" in any include file
    although it has a man page and it is present in libc (so HAVE_FDATASYNC
    is set). As a result posixmodule.c fails to compile.
   
    Adding a prototype "extern int fdatasync(int);" to posixmodule.c solves 
    this problem, but it may not be portable.
    
  - Modules/mmapmodule.c is missing a "#include <limits.h>"
  
Build problems on HPUX10.20 only:

  - When configured with threading support (default), the cast to (long)
    on line 181 of Python/thread_pthread.h fails. The reason is that
    pthread_t is a struct type. The "configure" test that tries to find out
    the size of pthread_t failed because it tries to cast '0' to a pthread_t,
    so SIZEOF_PTHREAD_T remains undefined.
    
    I suggest changing this line in configure.in:
    
    AC_TRY_COMPILE([#include <pthread.h>], [pthread_t x; x = (pthread_t)0;], have_pthread_t=yes)
    
    to
    
    AC_TRY_COMPILE([#include <pthread.h>], [pthread_t x; x = *(pthread_t*)0;], have_pthread_t=yes)
    
My compiler settings:

   setenv CC 'c89 +DA1.1 +Onolimit -D_HPUX_SOURCE'

Regards,

Eddy

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114324&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 11:17:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 03:17:21 -0700
Subject: [Python-bugs-list] [Bug #110619] urllib.py fails with username/password proxies (PR#221)
Message-ID: <200009131017.DAA05085@bush.i.sourceforge.net>

Bug #110619, was updated on 2000-Jul-31 14:06
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: Later
Bug Group: Feature Request
Priority: 4
Summary: urllib.py fails with username/password proxies (PR#221)

Details: Jitterbug-Id: 221
Submitted-By: tarka@zip.com.au
Date: Tue, 29 Feb 2000 19:15:45 -0500 (EST)
Version: 1.5.2
OS: Irix


urllib.py fails to handle proxies with user and password information 
included in the proxy URL, e.g. http://ssmith:testpass@10.11.12.13:1234

The following example ...

	import os, urllib
	os.environ['http_proxy'] = "http://ssmith:testpass01@10.11.12.13:1234"
	f = urllib.urlopen('http://www.python.org')
	data = f.read()
	print data

fails with the following errors :

Traceback (innermost last):
  File "url.py", line 3, in ?
    f = urllib.urlopen('http://www.python.org')
  File "/var/share//lib/python1.5/urllib.py", line 59, in urlopen
    return _urlopener.open(url)
  File "/var/share//lib/python1.5/urllib.py", line 157, in open
    return getattr(self, name)(url)
  File "/var/share//lib/python1.5/urllib.py", line 253, in open_http
    h = httplib.HTTP(host)
  File "/var/share//lib/python1.5/httplib.py", line 51, in __init__
    if host: self.connect(host, port)
  File "/var/share//lib/python1.5/httplib.py", line 75, in connect
    raise socket.error, "nonnumeric port"
IOError: [Errno socket error] nonnumeric port






====================================================================
Audit trail:
Mon May 22 17:35:04 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-31 10:15
By: fdrake

Comment:
Will be documented as a limitation in the implementation, as suggested in bug #111725.  I'm converting this to a feature request that can be dealt with in a subsequent version of Python.
-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 03:17
By: gvanrossum

Comment:
Fred, please document this limitation, add this to the feature-requests PEP (to be created), and then close the bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110619&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 11:23:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 03:23:20 -0700
Subject: [Python-bugs-list] [Bug #110655] getpass.getpass on Windows (PR#349)
Message-ID: <200009131023.DAA05269@bush.i.sourceforge.net>

Bug #110655, was updated on 2000-Jul-31 14:10
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: getpass.getpass on Windows (PR#349)

Details: Jitterbug-Id: 349
Submitted-By: ctalley@caci.com
Date: Thu,  8 Jun 2000 15:52:19 -0400 (EDT)
Version: 1.5.2
OS: W95


When using this code, the third line is skipped.  That is, the prompt
appears, but the program doesn't pause to accept input data.  It goes
right to the fourth line and pauses there.  I end up with a null string
for "fromaddr".

username=raw_input('Enter FTP server account username: ')
password=getpass.getpass('Enter FTP server account password: ')
fromaddr=raw_input('Enter your e-mail address: ')
toaddr=raw_input('Enter e-mail address for notification: ')

When using this code, everything works (although echo of the
password isn't suppressed.)

username=raw_input('Enter FTP server account username: ')
password=raw_input('Enter FTP server account password: ')
fromaddr=raw_input('Enter your e-mail address: ')
toaddr=raw_input('Enter e-mail address for notification: ')

The difference between the two code segments is that the first uses
the getpass method on the second line and the second uses raw_input.
What I think is happening is that getpass is leaving some garbage
in a buffer somewhere which is seen by raw_input as data.  raw_input
happily accepts the data and goes to the next line.  I've devised
several workarounds including "flush_input_buffer=raw_input('')"
immediately following the call to getpass.  It's ugly, but it works.

Thanks,
Carl Talley



====================================================================
Audit trail:
Tue Jul 11 08:25:59 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 03:23
By: gvanrossum

Comment:
Confirmed with Python 2.0b1 on Win98SE.
The bug does not occur on Linux.
Tim, the getpass code for Windows is different than on Unix, so please have a look!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110655&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 11:26:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 03:26:55 -0700
Subject: [Python-bugs-list] [Bug #110666] PRIVATE: interned->ma_table never free'd (PR#361)
Message-ID: <200009131026.DAA05410@bush.i.sourceforge.net>

Bug #110666, was updated on 2000-Jul-31 14:12
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Wont Fix
Bug Group: None
Priority: 1
Summary: PRIVATE: interned->ma_table never free'd (PR#361)

Details: Jitterbug-Id: 361
Submitted-By: cfandrich@8cs.com
Date: Fri, 16 Jun 2000 20:08:33 -0400 (EDT)
Version: 1.5.2
OS: Windows


I'm embedding Python in an application.  For now, all I'm doing is initializing
and finalizing Python.

When I run my app I get a memory leak of 12288 bytes.  The memory is malloc'ed
by dictresize() which is called by PyDict_SetItem() which is called by
PyString_InternInPlace().

For now, I've added 
    PyDict_Clear(interned);
    interned = NULL;
to PyString_Fini().  So far it works fine, but I don't know if it's safe to do
in the grand scheme of things.

-Chris




====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "M.-A. Lemburg" <mal@lemburg.com>
Subject: Re: [Python-bugs-list] PRIVATE: interned->ma_table never free'd (PR#361)
Date: Sat, 17 Jun 2000 10:53:20 +0200

cfandrich@8cs.com wrote:
> 
> Full_Name: Christopher Fandrich
> Version: 1.5.2
> OS: Windows
> Submission from: (NULL) (208.41.174.4)
> 
> I'm embedding Python in an application.  For now, all I'm doing is initializing
> and finalizing Python.
> 
> When I run my app I get a memory leak of 12288 bytes.  The memory is malloc'ed
> by dictresize() which is called by PyDict_SetItem() which is called by
> PyString_InternInPlace().
> 
> For now, I've added
>     PyDict_Clear(interned);
>     interned = NULL;
> to PyString_Fini().  So far it works fine, but I don't know if it's safe to do
> in the grand scheme of things.

I would suggest adding code to dealloc the interned dict
iff it is empty after the sweeping action in PyString_Fini().
I have a feeling that this is not the case though, since interned
strings are used quite a lot in the core interpreter (e.g. in
classobject.c) and these are usually not recovered.

Perhaps we ought to add some code which takes care of cleaning
up all remaining garbage left over after the call to
call_ll_exitfuncs() in Py_Finalize(), e.g. force free'ing
of all interned strings and cached ints/floats and associated
free lists or dicts.

We'd need new APIs in string|float|intobject.c to implement this.

Thoughts ? Patches ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 03:26
By: gvanrossum

Comment:
You shouldn't worry about this memory leak. The interned dict is shared by all interpreters and it's not safe to clear it. If you repeatedly initialize and finalize Python, you shouldn't see the memory leak increase.

(What leak detection tool do you use anyway? Since the interned dict is still accessible through a global, it shouldn't be called a leak!)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110666&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 11:29:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 03:29:06 -0700
Subject: [Python-bugs-list] [Bug #110685] isdir bad behaviouring (PR#408)
Message-ID: <200009131029.DAA05456@bush.i.sourceforge.net>

Bug #110685, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Wont Fix
Bug Group: None
Priority: 5
Summary: isdir bad behaviouring (PR#408)

Details: Jitterbug-Id: 408
Submitted-By: thomas.mangin@free.fr
Date: Sun, 23 Jul 2000 08:39:25 -0400 (EDT)
Version: 1.5.2
OS: Linux


This report is not a "Bug" report but more a library "Misbehaviouring" report.
I am concern about os.path.isdir return code. (this can probably applied to
isfile)

The return code express a boolean value : the file is a directory or not.

But I notice that if you don't have read access into the directory where the
file is stored, the function always return 0.
Or the path can refer a directory, returning 0 simply isn't right.

I beleve an exception must be raised to inform the programmer about this access
right problem and must be silently ignored.




====================================================================
Audit trail:
Mon Jul 24 18:32:17 2000	jeremy	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 03:29
By: gvanrossum

Comment:
You are wrong. isdir() should never raise an exception. What good is it to know that it is a directory if you can't access it? If you want an exception, use os.stat().
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110685&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 11:30:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 03:30:46 -0700
Subject: [Python-bugs-list] [Bug #110690] Bug in os.environ for Windows (PR#50)
Message-ID: <200009131030.DAA05476@bush.i.sourceforge.net>

Bug #110690, was updated on 2000-Jul-31 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Bug in os.environ for Windows (PR#50)

Details: Jitterbug-Id: 50
Submitted-By: bobalex@uppercase.xerox.com
Date: Wed, 11 Aug 1999 19:19:16 -0400 (EDT)
Version: 1.5.2
OS: WinNT


os.environ for Windows appears to be a map-type object that converts its keys to
upper case. Retrieval using a mixed case key works in some cases, but some
overloaded "operators" don't seem to do the right thing unless I pass an
all-upper-case key. E.g.:

>>> os.environ["x"] = "y"               # Stores pair {"X": "y"}
>>> os.environ["x"]                     # Works, indicates an effort is made
'y'                                     #   to retrieve mixed case keys
>>> os.environ.get("x", "NOT FOUND")    # Doesn't see the key "x"
'NOT FOUND'
>>> os.environ.get("X", "NOT FOUND")    # Works with all-upper-case key
'y'
>>> del os.environ["x"]                 # Doesn't see the key "x"
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "E:\Program Files\Python\Lib\UserDict.py", line 16, in __delitem__
    def __delitem__(self, key): del self.data[key]
KeyError: x
>>> del os.environ["X"]                 # Works with all-upper-case key



====================================================================
Audit trail:
Mon Aug 30 12:33:44 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 10:34
By: fdrake

Comment:
Fixed at some point in the past.  Tested OK using 2.0b1 on Win2K.
-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 03:30
By: gvanrossum

Comment:
This was fixed by os.py version 1.31 in April 2000, by Fred Gansevles.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110690&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 11:36:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 03:36:06 -0700
Subject: [Python-bugs-list] [Bug #110694] PRIVATE: Threads and readline (PR#120)
Message-ID: <200009131036.DAA05660@bush.i.sourceforge.net>

Bug #110694, was updated on 2000-Jul-31 14:28
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Duplicate
Bug Group: Platform-specific
Priority: 5
Summary: PRIVATE: Threads and readline (PR#120)

Details: Jitterbug-Id: 120
Submitted-By: xfb52@dial.pipex.com
Date: Fri, 29 Oct 1999 14:33:55 -0400 (EDT)
Version: 1.5.2
OS: FreeBSD 3.2


When python is compiled with thread support and readline, ^C no longer
works properly (interpreter goes into an infinite loop).
(Tried with readline 2.0, 2.2 and 4.0).

The same system compiled without readline but with threads works fine,
and compiled without threads but with readline works fine.

The error seems to centre around the signal handler installed by
call_readline in Modules/readline.c which does not call signal_handler
in Modules/signalmodule.c (which is what happens without readline).

I have found an inadequate fix which works with readline-4.0 (but
not earlier realeases).  This makes ^C work but only after a RETURN
is pressed.  Whilst not perfect, it does at least allow readline
and threads.

Hopefully this may point someone who can better understand the signal
handling to find a better fix.

I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.

--Alex

*** Modules/readline.c  Fri Oct 29 19:31:13 1999
--- Modules/readline.c.ORIG     Fri Oct 29 19:14:27 1999
***************
*** 34,40 ****
  extern int rl_bind_key_in_map();
  extern int rl_initialize();
  extern int add_history();
- extern int rl_catch_signals;
  extern Function *rl_event_hook;
  #endif
  
--- 34,39 ----
***************
*** 233,239 ****
  static void
  setup_readline()
  {
-         rl_catch_signals=0;
        rl_readline_name = "python";
        /* Force rebind of TAB to insert-tab */
        rl_bind_key('\t', rl_insert);
--- 232,237 ----
***************
*** 277,283 ****
        int n;
        char *p;
        RETSIGTYPE (*old_inthandler)();
! /*    old_inthandler = signal(SIGINT, onintr); */
        if (setjmp(jbuf)) {
  #ifdef HAVE_SIGRELSE
                /* This seems necessary on SunOS 4.1 (Rasmus Hahn) */
--- 275,281 ----
        int n;
        char *p;
        RETSIGTYPE (*old_inthandler)();
!       old_inthandler = signal(SIGINT, onintr);
        if (setjmp(jbuf)) {
  #ifdef HAVE_SIGRELSE
                /* This seems necessary on SunOS 4.1 (Rasmus Hahn) */
***************
*** 288,294 ****
        }
        rl_event_hook = PyOS_InputHook;
        p = readline(prompt);
! /*    signal(SIGINT, old_inthandler); */
        if (p == NULL) {
                p = malloc(1);
                if (p != NULL)
--- 286,292 ----
        }
        rl_event_hook = PyOS_InputHook;
        p = readline(prompt);
!       signal(SIGINT, old_inthandler);
        if (p == NULL) {
                p = malloc(1);
                if (p != NULL)




====================================================================
Audit trail:
Tue Nov 02 20:44:47 1999	guido	changed notes
Tue Nov 02 20:44:47 1999	guido	moved from incoming to platformbug
Wed Nov 03 10:41:38 1999	guido	changed notes
Wed Nov 03 10:41:39 1999	guido	changed notes
Wed Nov 03 10:44:43 1999	guido	changed notes

Follow-Ups:

Date: 2000-Aug-01 14:02
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] PRIVATE: Threads and readline (PR#120)
Date: Mon, 01 Nov 1999 17:53:46 -0500

> When python is compiled with thread support and readline, ^C no longer
> works properly (interpreter goes into an infinite loop).
> (Tried with readline 2.0, 2.2 and 4.0).

Thanks for your bug report.  I see that you are using FreeBSD.  Could
it be a FreeBSD related problem?  I don't see the same thing on
Solaris or Red Hat Linux.

Also, can you describe exactly how you reproduce the problem?

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:02
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] PRIVATE: Threads and readline (PR#120)
Date: Wed, 03 Nov 1999 10:40:18 -0500

Resolution.

------- Forwarded Message

Date:    Wed, 03 Nov 1999 15:24:59 +0000
From:    Alex Zbyslaw <xfb52@dial.pipex.com>
To:      guido@cnri.reston.va.us
Subject: Re: [Python-bugs-list] PRIVATE: Threads and readline

I believe that you were right and that this is a FreeBSD bug.  I finally
traced  the problem back to the use of the setjmp/longjmp in
readline.c.  For whatever reason, this messes up on FreeBSD.

I'll post my final patches on comp.lang.python myself.  Please consider
the problem closed.

Thanks for following up.  I think I'll stick to FreeBSD.  I grew up on
BSD4.2/3 and system v still gives me the heebie jeebies :-)

All the best,

- --Alex

------- End of Forwarded Message


-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] PRIVATE: Threads and readline (PR#120)
Date: Wed, 03 Nov 1999 10:42:33 -0500


------- Forwarded Message

Date:    Tue, 02 Nov 1999 11:57:23 +0000
From:    Alex Zbyslaw <xfb52@dial.pipex.com>
To:      guido@cnri.reston.va.us
Subject: RE: Re: [Python-bugs-list] PRIVATE: Threads and readline

>> When python is compiled with thread support and readline, ^C no longer
>> works properly (interpreter goes into an infinite loop).
>> (Tried with readline 2.0, 2.2 and 4.0).

>Thanks for your bug report.  I see that you are using FreeBSD.  Could
>it be a FreeBSD related problem?  I don't see the same thing on
>Solaris or Red Hat Linux.
>
>Also, can you describe exactly how you reproduce the problem?
>
>--Guido van Rossum (home page: http://www.python.org/~guido/)

Thanks for your mail, Guido.  Yes, I suppose it could be a FreeBSD
problem, though I was originally put on to the readline connection by
some articles in comp.lang.python which mentioned extremely similar
symptoms under Debian Linux.  What those articles did not mention was
the thread connection which I guessed for myself.  See articles titled
"Control-C on Unix meisbehaviour?" on 18th Oct 1999.  People in that
thread reported similar problems on various systems, whilst others had
no problem on apparently identical systems.  No one mentioned if they
had thread support.

Creating the problem is, for me, simple.  I compile python 1.5.2 with
thread support enabled.  (Thread and signal tests are passed by make
test and a quickie thread program works as expected).  If I go into the
interpreter
	python
and type ^C, everything goes into an infinite loop.

If I recompile python without threads, but with readline, then go into
the interpreter then press ^C I get KeyboardInterrupt as expected.

If I recompile with threads but without readline, then again, I get
KeyboardInterrupt as expected.

In all three cases, pressing ^C while a program is running gets correct
behaviour.



>From what I can determine:
	The readline module was written so that it bypassed any signal handler
installed by the readline library.  It institutes its own handler in
readline.c (onintr) which catches the interrupt and returns NULL (which
somewhere back down the line is interpreted as KeyboardInterrupt).

	However, with threads enabled (but no readline) there seems to be a
different behaviour, where the interrupt is caught by the regular signal
handler (I forget the name but its in my bug report - in
signalmodule.c).  My guess was that with threads enabled this signal
handler was doing something important.  But with readline support turned
on, this handler was not being called which caused some problem occur. 
I did try adapting the code in readline.c to call this signal handler
itself, but that didn't seem to work (though I forget what happened).

What my patch does is to forget about the local signal handler 'onintr'
and, instead, stick with whatever the "default" signal handler is. 
readline_4.0 allows you to turn off any signal handling in the readline
library itself, so the "default" handler will be whatever python
installs (in signalmodule.c).

This then "works" in that pressing ^C does not generate an infinite
loop.  But the call_readline function in readline.c does not immediately
return NULL, so you have to press RETURN before the KeyboardInterrupt is
generated.  

I never did figure out a way to both call the default signal handler and
return a NULL from call_readline -- which I believe would cause
"correct" ^C behaviour.  My C is somewhat rusty as I spend my time in
Python (by choice) and Perl (by neccessity).


I'm not sure what else I can tell you about the problem, but if there is
any more data I could provide for you, please ask.



As another bizarre data point: when I run a threaded python interpreter
on a program which does not use threads, and pipe the output to less,
less gets very confused and fails to update about half the screen,
leaving it blank.  This happens after hitting SPACE a couple of times. 
All the data is there, and if I jump less to the end of input and then
go back through the the data, I can see it all normally. Same program
and unthreaded python and less works just fine.  If you have ANY idea
why adding thread support could affect a program further down a pipe I'd
love to know.


By the way, I have no objection to making my bug report and patch
public, as long as there is some way to remove my email address from
it.  I have had only one piece of spam in the last year and I'd like to
keep it that way :-) As the good cafe owner said "Spam's orf"!  Although
it's not perfect, the patch has made threaded python usable for me. If
there are other people out there in the same boat and it helped them,
that would be great.


- -- 
Phone: 0131 468 2422
Email: xfb52@dial.pipex.com

------- End of Forwarded Message


-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Jack Jansen <jack@oratrix.nl>
Subject: Re: [Python-bugs-list] PRIVATE: Threads and readline (PR#120)
Date: Wed, 03 Nov 1999 23:32:19 +0100

> As another bizarre data point: when I run a threaded python interpreter
> on a program which does not use threads, and pipe the output to less,
> less gets very confused and fails to update about half the screen,
> leaving it blank.  This happens after hitting SPACE a couple of times. 
> All the data is there, and if I jump less to the end of input and then
> go back through the the data, I can see it all normally. Same program
> and unthreaded python and less works just fine.  If you have ANY idea
> why adding thread support could affect a program further down a pipe I'd
> love to know.

As I like puzzles I spent some time thinking on this, and it must be
either (a) kernel bug, (b) a very strange stdio bug or (c) an incorrect 
observation. If your system supports memory-mapped I/O and stdio uses
it and it can somehow signal that a whole buffer is available while it 
isn't but only the tail end is available (because it uses an
overlapping memcopy which goes back-to-front, for instance) the reader 
in the pipe might wakeup too early and see null bytes. But if this was 
a bet I think I'd put my money on (c) (but absolutely no offense meant!).
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 

-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Alex Zbyslaw: RE: Re: [Python-bugs-list] PRIVATE: Threads and readline (PR#120)
Date: Mon, 08 Nov 1999 10:30:24 -0500


------- Forwarded Message

Date:    Sat, 06 Nov 1999 11:17:00 +0000
From:    Alex Zbyslaw <xfb52@dial.pipex.com>
To:      guido@cnri.reston.va.us
Subject: RE: Re: [Python-bugs-list] PRIVATE: Threads and readline

This is the message I posted today on comp.lang.python.

Btw, I forgot to mention that to compile for thread support on FreeBSD
3.2 (and I would think 3.3) you only need to specify "-pthread" on the
link line.  That automatically links in the threaded C libraries. 
Everything else from the standard configure would appear to be correct.

All the best,

- --Alex


Subject:  Re: Control-C on Unix misbehaviour?
Date:  Sat, 06 Nov 1999 11:08:05 +0000

Quinn Dunkan wrote:
>
> On Mon, 18 Oct 1999 15:47:52 +0200, flight@mathi.uni-heidelberg.de
> Here's a data point for Irix6:
> If you hit ^C at the >>> prompt with readline loaded (python 1.5), python
> stops responding.  Further ^Cs do nothing, in fact the only way I've found
> to get out is to kill from another shell or hit ^z kill %.

I had exactly the same problem on FreeBSD 3.2  but ONLY when I had
thread support enabled.

I have eventually tracked the problem down to a bad interaction (read
library/kernel bug) between threads/sigjmp and interrupted reads.

I have created two "fixes" which can be applied either to a) python or
b) python and readline which fix the problems differently.  The fixes
are pretty trivial and so far they work for me.  You can check them out
at http://www.xfb52.dial.pipex.com/patches/python.shtml

I don't know how they may affect people who have had ^C dumping them
into a shell.  No one else has mentioned whether they had thread support
enabled or not.

>From extensive poking around I am quite sure that this misbehaviour is
not a bug in either Python or readline.

Good luck,

- --Alex

------- End of Forwarded Message


-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
There is a problem with threads + readline + signals on FreeBSD.
Apparently readline is using longjmp and this messes things up.
(I told you longjmp was evil. :-)
-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 03:36
By: gvanrossum

Comment:
According to the comments, at least part of this is a FreeBSD specific kernel problem and solved for that platform. Th rest (signals, threads, readline) is a duplicate of bug #110611. Closing this one.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110694&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 11:42:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 03:42:30 -0700
Subject: [Python-bugs-list] [Bug #110599] bug (Incorrect signal processing) - Python 1.5.2 (PR#102)
Message-ID: <200009131042.DAA05966@bush.i.sourceforge.net>

Bug #110599, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: bug (Incorrect signal processing) - Python 1.5.2 (PR#102)

Details: Jitterbug-Id: 102
Submitted-By: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" <Vladimir.Benes@pvt.cz>
Date: Mon, 11 Oct 1999 13:00:07 +0200
Version: None
OS: None

Good afternoon,

    I have found a bug on Python 1.5.2. This bug doesn't occur on Python
1.5.1.

Python versions and OS:
- Python 1.5.1. at Debian GNU/Linux 2.0.36
- Python 1.5.2. at Debian GNU/Linux 2.2.9

Bug: Incorrect signal processing (Python 1.5.2).
    Process can assign procedure for signal processing. When process is
waiting at system call and this signal occur, then the signal assigned
procedure is otherwise correctly completed but then waiting at system call
is broken and process continues.

    Here is a simple program for demonstrate this bug:

#!/usr/bin/python
import signal
import sys

def signal_handle(signum, frame) :
  signal.signal(signal.SIGALRM, signal_handle)
  signal.alarm(2)
  print "signal"

signal_handle(0,0)
a=sys.stdin.readline()
print "Line examined..."
b=sys.stdin.readline()
print "Line examined..."
print a,b,"end"
# end of example

    Correct behaviour: Message "Line examined..." occurs only after pressing
ENTER by user.
    Bug: Message "Line examined..." occurs immediately after signal occured
and procedure signal_handle finished. Output then look thus (when no input
entered):

signal
signal
Line examined...
signal
Line examined...
  end

    This bug appears at any signal occur and whatever process waiting at
system call. Some system call even produces exception (e.g. waiting for data
or connection on socket).

    Bug is perhaps caused by wrong seting "siginterrupt" on module signal. I
haven't found any way how call in Python program "siginterrupt" for correct
behavior of signal processing.

        Good bye, V. Benes

****************************************************************************
    Ing. Vladimir Benes, pvt.net
    PVT, a.s., OZ Chomutov
    e-mail: vladimir.benes@pvt.cz, vladimir.benes@sms.paegas.cz
****************************************************************************



====================================================================
Audit trail:
Mon Oct 11 18:12:13 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:05
By: none

Comment:
From: Jeremy Hylton <jeremy@cnri.reston.va.us>
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102)
Date: Tue, 12 Oct 1999 12:04:42 -0400 (EDT)

>>>>> "VB" == Vladimir Benes <Vladimir.Benes@pvt.cz> writes:

  VB> Bug: Incorrect signal processing (Python 1.5.2).  Process can
  VB> assign procedure for signal processing. When process is waiting
  VB> at system call and this signal occur, then the signal assigned
  VB> procedure is otherwise correctly completed but then waiting at
  VB> system call is broken and process continues.

[example program]

I see the behavior you report for 1.5.2 on Solaris 2.6.

  VB>     This bug appears at any signal occur and whatever process
  VB> waiting at system call. Some system call even produces exception
  VB> (e.g. waiting for data or connection on socket).

These issues always occur in twos don't they.  There was a similar
question posted on comp.lang.python yesterday.  I'm not sure that the
behavior you're seeing is a bug; it is the behavior I would expect.
Slow system calls are interrupted, returning EINTR, when a signal
occurs. 

  VB>     Bug is perhaps caused by wrong seting "siginterrupt" on
  VB> module signal. I haven't found any way how call in Python
  VB> program "siginterrupt" for correct behavior of signal
  VB> processing.

Perhaps the signal module for Python should be extended to support
siginterrupt, but it sounds like it will only reduce the number of
system calls that can be interrupted.  The Solaris man page says:

    NOTES
         Use of these interfaces should be restricted to only  appli-
         cations  written  on BSD platforms.  Use of these interfaces
         with any of the system libraries or in multi-threaded appli-
         cations is unsupported.

It doesn't sound particularly safe.

Jeremy

-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" <Vladimir.Benes@pvt.cz>
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102)
Date: Wed, 13 Oct 1999 09:19:44 +0200

From: Jeremy Hylton <jeremy@cnri.reston.va.us>
To: Vladimir.Benes@pvt.cz <Vladimir.Benes@pvt.cz>
Cc: python-bugs-list@python.org <python-bugs-list@python.org>;
bugs-py@python.org <bugs-py@python.org>
Date: 12. 10. 1999 18:04
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python
1.5.2 (PR#102)


JH>I see the behavior you report for 1.5.2 on Solaris 2.6.


    You don't write whether this bug appeared there.

 JH> ......  I'm not sure that the
 JH> behavior you're seeing is a bug; it is the behavior I would expect.
 JH> Slow system calls are interrupted, returning EINTR, when a signal
 JH> occurs.


    I'am sure that this behavior is bug becouse:

1. I wrote the same program in C language (see below).
2. I ran this program at the same machine where the Python *)
    program works incorrectly.
3. Behavior of C program is correct (line scan is ended only when
    user press ENTER and this end is independed on signal).

=> The C program works correct and the same Python *) program fails at the
same platform. Base run of program should by independed on signal processing
except program terminating signals. It's independed at C program but
incorrect processed by Python *) programs.

*) only Python 1.5.2; Python 1.5.1 here works correctly

    Here is the mentioned program:

#include<stdio.h>
#include <unistd.h>
#include <signal.h>

void signal_handle(int signum) {
  signal(SIGALRM, signal_handle);
  alarm(2);
  printf("signal\n\r");
}

void main(void) {
  char a[100], b[100];

  signal_handle(0);
  scanf("%s",&a);
  printf("Line examined...\n\r");
  scanf("%s",&b);
  printf("Line examined...\n\r");
  printf("%s\t%s\tend\n\r", a, b);
}

 VB>     Bug is perhaps caused by wrong seting "siginterrupt" on
 VB> module signal. I haven't found any way how call in Python
 VB> program "siginterrupt" for correct behavior of signal
 VB> processing.


 JH> Perhaps the signal module for Python should be extended to support
 JH> siginterrupt, but it sounds like it will only reduce the number of
 JH> system calls that can be interrupted.  .......


    Sorry, I wrong formulated possible couse of bug. I will try to specify
my idea:
    It looks that there is any wrong calling "siginterupt" on signal module.
Python libraries doesn't allow me to try correct this bug by calling
"siginiterrupt" in my program before signal setting. But the best way is to
reapir bug on signal module.

    Good bye, V. Benes


-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102)
Date: Wed, 13 Oct 1999 08:57:25 -0400

>  JH> ......  I'm not sure that the
>  JH> behavior you're seeing is a bug; it is the behavior I would expect.
>  JH> Slow system calls are interrupted, returning EINTR, when a signal
>  JH> occurs.
> 
[Vladimir]
>     I'am sure that this behavior is bug becouse:

When I first thought about this, I agreed with Vladimir.  If you look
careful at his code, readline() is returning "" when the alarm goes
off; this can't be right, because it's not an end of file.  It should
either raise an exception (EINTR) or return one line of valid data.

On the other hand, whatever solution is chosen should be careful that
other signals raise exceptions; in particular you want SIGINT (^C) to
be translated to a KeyboardError exception.  Since the C code in
readline() can't tell which signal was trapped or whether the handler
raised an exception, it has two choices, both of which are bad:

- Raise an IOError exception, honoring the EINTR.  Unfortunately, in
the SIGINT/^C case, the handler will run after this exception is
raised, and it will raise KeyboardError.  The Python program will
*probably* see the KeyboardError exception, but it is not guaranteed
that the signal handler is run immediately.  (The Python-level signal
handler is run only after the Python virtual machine finishes the
current instruction, i.e. after the readline() completes.)

- Continue to read a line, ignoring the EINTR.  Unfortunately, this
would mean that the user has to type ^C followed by Return to
interrupt the program!

An alternative solution would be to arrange for the Python-level
interrupt handler to execute inside the readline() method, and to
restart the read only when it raises no exception; but this would
require a massive code rewrite (you'd want this behavior in any place
that does a blocking I/O operation).

Concluding, I think Vladimir is better off not to use signal handlers
in the way he is using them now.  Python's emulation of signal
semantics is sufficiently different from C that you can't rely on the
same behavior.  (And note that in C, signal handlers are usually
broken anyway; e.g. the code you write, which prints something inside
the signal handler, is broken on C too because you don't know the
state of stdout when the handler is invoked.)

I looked at what could be different between 1.5.1 and 1.5.2, and found 
that the call to siginterrupt() to disable restarting system calls was 
added after 1.5.1.  Given the alternatives, I think I like the 1.5.2
behavior better than the 1.5.1 behavior.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" <Vladimir.Benes@pvt.cz>
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102)
Date: Wed, 13 Oct 1999 16:34:39 +0200

>...
>Concluding, I think Vladimir is better off not to use signal handlers
>in the way he is using them now.  Python's emulation of signal
>semantics is sufficiently different from C that you can't rely on the
>same behavior.  (And note that in C, signal handlers are usually
>broken anyway; e.g. the code you write, which prints something inside
>the signal handler, is broken on C too because you don't know the
>state of stdout when the handler is invoked.)


    Well, meantioned programs were only very simple demos for demonstrate
incorrect signal processing. But exists a large range of meaningful programs
where is necessary both synchronous and asynchronous signal processing - and
signal can be triggered whenever.

    Example of C symbolic structure this programs:

....
int event_flag;
void trigger_signal(int signum) {
  // asynchonous signal processing
  event_flag = MY_EVENT; // only flag set
}
void initialize_signal(int sig) {
  event_flag = NO_EVENT; // initialize
  signal(sig, trigger_signal);
}
int main() {
  initialize_signal(SIGTERM);
  while (1) {
    my_func();
    // synchronous signal processing:
    if (event_flag==MY_EVENT) my_sync_trigger();
  }
}

    Signal can be raised whenever when function my_func runs => flag
event_flag is then set but my_func "does't know" his and continues at own
processing. Signal should not influence my_func becouse my_func "doesn't
know" both this signal and flag event_flag. Function event_flag can wait for
system call (read, write, connect, etc). Incoming signal should not finish
this waiting after trigger_signal function processing. So my_func is
independed on signal processing and "does'nt know" signals.

    Program tests the flag at any "safe" location(s). If this flag is set,
program run specific synchronous signal processing. It can be for example
safe program end or synchronous SIGALRM processing.

    Python programs can by compose similar this example.

>I looked at what could be different between 1.5.1 and 1.5.2, and found
>that the call to siginterrupt() to disable restarting system calls was
>added after 1.5.1.  Given the alternatives, I think I like the 1.5.2
>behavior better than the 1.5.1 behavior.


    But then old Python programs writen for Python 1.5.1 are not compatible
with Python 1.5.2. in this feature. I thing that better way is to let this
behavior equal as in Python 1.5.1. but allow programs to call either new
function "siginterrupt" at signal module (more flexible solution) or any
else new function at signal module to set behavior signal processing by Your
idea.

        Good bye, V. Benes


-------------------------------------------------------

Date: 2000-Aug-10 11:45
By: gvanrossum

Comment:
Sorry, I can't take this.  It's an issue though!  There are a bunch of signal related bugs in Linux...
-------------------------------------------------------

Date: 2000-Sep-13 03:42
By: gvanrossum

Comment:
Confirmed with python 2.0b1 on Linux.

Note that this is *not* the same bug as #110611 -- here, threads and readline don't matter (confirmed).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110599&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 11:45:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 03:45:16 -0700
Subject: [Python-bugs-list] [Bug #110703] select with dec-threads core dumps (PR#35)
Message-ID: <200009131045.DAA06009@bush.i.sourceforge.net>

Bug #110703, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Wont Fix
Bug Group: Platform-specific
Priority: 5
Summary: select with dec-threads core dumps (PR#35)

Details: Jitterbug-Id: 35
Submitted-By: ddula@alfomc.net
Date: Thu, 22 Jul 1999 17:01:04 -0400 (EDT)
Version: 1.5.2
OS: Digital Unix (OSF/1) 4.0E with latest patches


Select cores while waiting on a socket

spoo.alfomc.net> dbx  /usr/local/ddula/tar/Python-1.5.2/python core

dbx version 3.11.10
Type 'help' for help.
Core file created by program "python"
thread 0xb signal Segmentation fault at >*[nxm_thread_kill, 0x3ff805ab3b8]
retr31, (r26), 1
(dbx) t
>  0 nxm_thread_kill(0x14003bb40, 0x3ff807e31c8, 0x3ffc0085c98, 0x3ff805ab0a8,
0x14003bb40) [0x3ff805ab3b8]
   1 pthread_kill(0x1, 0x0, 0x0, 0x1400df980, 0x3ff00000000) [0x3ff80598b94]
   2 (unknown)() [0x3ff8058cb38]
   3 (unknown)() [0x3ff807e35ec]
   4 exc_unwind(0x1400dde78, 0x1400dc5a0, 0xabadabad00beed00, 0x0,
0x3ff807e3964) [0x3ff807e36d4]
   5 exc_raise_signal_exception(0x86, 0x0, 0x1200735b8, 0x1, 0x2)
[0x3ff807e3960]
   6 (unknown)() [0x3ff8059a248]
   7 select_select(args = (nil)) ["./selectmodule.c":221, 0x1200735b4]
   8 eval_code2(co = [bad address (0x14010d838)], globals = 0xfc50, locals =
(nil), args = [bad address (0x14010d840)], kws = [bad address (0x14010d848)],
kwcount = [bad address (0x14010d9a8)], defs = [bad address (0x14010d9b0)],
defcount = [bad address (0x14010d9b8)]) ["ceval.c":1654, 0x12003e57c]

Appears eval_code2 is getting passed bad addresses?

My code snipped 

<--SNIP-->
class TelnetProxy(SocketServer.StreamRequestHandler,SocketServer.BaseRequestHand
ler):
        def handle(self):
                o = socket(AF_INET,SOCK_STREAM)
                o.connect(OHOST,OPORT)
                while 1:
                        print o.fileno()
                        print self.rfile.fileno()
                        r,w,e = select.select([o,self.rfile],[],[],1) <---CORE
HERE
                        if o in r:

<--SNIP-->

Same problem under 1.5.1 as well.

The 1.5.2 is the latest source I downloaded Jul 20

This same code works fine on NT and LINUX I believe.

Dave Dula
ddula@alfomc.net


====================================================================
Audit trail:
Sat Jul 24 16:52:19 1999	guido	changed notes
Sat Jul 24 16:52:19 1999	guido	moved from incoming to open
Sat Jul 24 17:05:25 1999	guido	moved from open to platformbug

Follow-Ups:

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] select with dec-threads core dumps (PR#35)
Date: Thu, 22 Jul 1999 17:46:26 -0400

I seriously suspect that this is a bug in your C library, not in
Python.  Select is rock-solid on other platforms.  Do you feel
confident enough to try debugging this some more?  Otherwise, you have
no choice but to post a question to the newsgrup, maybe someone has
seen this before or is willing to help debugging it.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
From: David Dula <ddula@alfomc.net>
Subject: Re: [Python-bugs-list] select with dec-threads core dumps (PR#35)
Date: Thu, 22 Jul 1999 18:43:48 -0400

Guido van Rossum wrote:

> I seriously suspect that this is a bug in your C library, not in
> Python.  Select is rock-solid on other platforms.  Do you feel
> confident enough to try debugging this some more?  Otherwise, you have
> no choice but to post a question to the newsgrup, maybe someone has
> seen this before or is willing to help debugging it.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)

Well a little more debugging shows that this is certainly a threading
+ select problem
because a forking method works.  The forks will serve my purposes so I
have a work around.

Thanks
Dave Dula


-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
Digital Unix problem when combining threads with select?
-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 03:45
By: gvanrossum

Comment:
It's unlikely that we'll ever fix this, because of the uncommon platform, and the suspicion that the bug is in the platform. If you have more information pointing to a bug in Python, and if this is still not broken in Python 2.0, please send mail and we'll reopen the bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110703&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 11:46:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 03:46:11 -0700
Subject: [Python-bugs-list] [Bug #110710] Segmentation fault on range (PR#71)
Message-ID: <200009131046.DAA06021@bush.i.sourceforge.net>

Bug #110710, was updated on 2000-Jul-31 14:30
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 4
Summary: Segmentation fault on range (PR#71)

Details: Jitterbug-Id: 71
Submitted-By: mz@pdm.pvt.net
Date: Mon, 6 Sep 1999 06:45:45 -0400 (EDT)
Version: 1.5.2
OS: Debian GNU/Linux 2.1


When I start python and try to evaluate `range(1000000000)', I receive
segmentation fault:

  $ python
  Python 1.5.2 (#0, May  4 1999, 14:45:33)  [GCC 2.7.2.3] on linux2
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  >>> range(1000000000)
  Segmentation fault

This can also be reproduced with Python 1.5.1 from the Debian 2.1 i386
distribution.



====================================================================
Audit trail:
Tue Sep 07 11:13:29 1999	guido	changed notes
Tue Sep 07 11:13:29 1999	guido	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Aug-04 07:00
By: jhylton

Comment:
I can't reproduce this bug on 1.5.2 or current CVS.  In both cases, I get a MemoryError.

-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 03:46
By: gvanrossum

Comment:
Fixed in 2.0. This now gives a MemoryError exception.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110710&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 11:51:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 03:51:42 -0700
Subject: [Python-bugs-list] [Bug #110712] MALLOC_ZERO_RETURNS_NULL problem
Message-ID: <200009131051.DAA06329@bush.i.sourceforge.net>

Bug #110712, was updated on 2000-Jul-31 14:30
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Wont Fix
Bug Group: Platform-specific
Priority: 5
Summary: MALLOC_ZERO_RETURNS_NULL problem

Details: Jitterbug-Id: 86
Submitted-By: Sean Dunn <sdunn@digitalanvil.com>
Date: Fri, 24 Sep 1999 14:44:22 -0500
Version: None
OS: None

The use of

    #define MALLOC_ZERO_RETURNS_NULL 1

at the top of mymalloc.h worked fine...
By curiousity.. I just tried compiling the following:

/*testmalloc.c*/
#include <stdio.h>
main()
{
    int *fp;
    int *sp;

    fp = (int*)malloc(0);
    sp = (int*)malloc(sizeof(int));
    printf("fp: %x\nsp: %x\n", fp, sp);
}
/**/

First, I just compiled normally:

> cc -o testmalloc testmalloc.c
> ./testmalloc
fp: 10015010
sp: 10015020

Then I compiled with the -lmalloc flag (libmalloc is the SGI high performance
memory library - which seems to be the default used after running the
configure script)

> cc -o testmalloc testmalloc.c
> ./testmalloc
fp: 0
sp: 10015048

So...  It looks like without libmalloc, we're actually getting memory when we
"shouldn't" - but from reading your source code it seems like that's the way
it is usually made to work (weird).  When compiling with libmalloc, the
returned 0 is triggering the MemError flag.

At ceval.c:2467, should it even get to this point if the passed in kwargs ==
{}?  It does a PyDict_Size of it, which returns 0 (which seems correct) but kw
isn't NULL.  It seems like at this point that it should be..

Sean


Guido van Rossum wrote:

> >       The builtin function apply() seems to barf on empty dictionaries
> >       when passed as the keyword list.  See the following output:
>
> > >>> apply(func, (1,), {})
> > Traceback (innermost last):
> >   File "<stdin>", line 1, in ?
> > MemoryError
> > >>>
>
> > The variable 'kwargs' in this case is {}.  The actual exception is thrown
> > at line 2467 of Python/ceval.c:
> >
> >       if (kw != NULL) {
> >               int pos, i;
> >               nk = PyDict_Size(kw);
> >
> > /* 2467 */    k = PyMem_NEW(PyObject *, 2*nk);
> > /* nk, the PyDict_Size (the size of ma_used) is 0 */
> >
> >               if (k == NULL) {
> >                       PyErr_NoMemory();
> >                       Py_DECREF(arg);
> >                       return NULL;
> >               }
> >               pos = i = 0;
> >               while (PyDict_Next(kw, &pos, &k[i], &k[i+1]))
> >                       i += 2;
> >               nk = i/2;
> >               /* XXX This is broken if the caller deletes dict items! */
> >       }
>
> Thanks very much for your detailed analysis!  The cause is probably
> that somehow the configure script doesn't compute the correct value
> for MALLOC_ZERO_RETURNS_NULL.  I don't know why; the test seems simple
> enough.  (Maybe you inherited a config.cache file from a previous Irix
> version?)  To work around this in the build, if "make clobber" and
> rerunning configure don't do the trick, add
>
>     #define MALLOC_ZERO_RETURNS_NULL 1
>
> to the top of Include/mymalloc.h.
>
> Please let me know if rerunning configure makes the bug go away; this
> will decides the classification of your bug report.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)





====================================================================
Audit trail:
Fri Sep 24 16:15:04 1999	guido	changed notes
Fri Sep 24 16:15:04 1999	guido	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Sep-07 14:28
By: jhylton

Comment:
Please do triage
-------------------------------------------------------

Date: 2000-Sep-13 03:51
By: gvanrossum

Comment:
I don't understand why the configure script would use a different malloc library for its test of malloc(0) than what is used later to compile Python. Could it be that simply "make clobber" and running configure again would solve the problem?

I'm closing the bug report for now.
If this is still a problem with Python 2.0, please send email and I'll reopen it.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110712&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 11:53:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 03:53:52 -0700
Subject: [Python-bugs-list] [Bug #110821] On Windows, APIs passing FILE* break with Borland C (PR#121)
Message-ID: <200009131053.DAA06359@bush.i.sourceforge.net>

Bug #110821, was updated on 2000-Aug-01 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: On Windows, APIs passing FILE* break with Borland C (PR#121)

Details: Jitterbug-Id: 121
Submitted-By: "Brad Clements" <bkc@murkworks.com>
Date: Wed, 3 Nov 1999 15:53:01 -0500
Version: None
OS: None

The system encountered a fatal error 
After command: 
Received: 
The last error code was: Connection refused 

Web interface using {HYPERLINK "http://samba.anu.edu.au/jitterbug/"}Jitterbug 
{HYPERLINK "../python-bugs/"}Public interface 
{HYPERLINK "../python-bugs.private"}Private interface (requires password) 
{HYPERLINK "http://www.python.org/"}Python home page 

-----
Here's what I said for Python 1.5.2 on Win32 #0

PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
usable on WIN32 from non-VC applications because python15.dll is statically 
linked to the MS runtime DLL. Embedding applications that try to use these 
functions are passing in FILE * structures that do not match MS's runtime 
format. 

For example, I'm using Python in a Borland C++ Builder application. Although I 
can open a FILE *, when passed to python15.dll the FILE * is not usable.

The addition of two helper functions would solve this problem:

FILE * PyRun_OpenFile(char *file, char *mode) 
{
  return fopen(file,mode)
}

int PyRun_CloseFile(FILE *ptr)
{
  return fclose(ptr)
}

This way embedding apps could get python15.dll to open the file and it would 
work.

A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..


Brad Clements,                bkc@murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               ICQ: 14856937


====================================================================
Audit trail:
Fri Nov 05 10:31:10 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:10
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121)
Date: Wed, 03 Nov 1999 20:08:11 -0500

> I tried to post a bug, but got this error:
> 
> The system encountered a fatal error 

We were being slammed by a defective spider (or, if you're more
paranoid, by a hacker) so we temporarily turned off the webserver.  It
should be back on now.

> Here's what I said for Python 1.5.2 on Win32 #0
> 
> PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
> usable on WIN32 from non-VC applications because python15.dll is statically 
> linked to the MS runtime DLL. Embedding applications that try to use these 
> functions are passing in FILE * structures that do not match MS's runtime 
> format. 
> 
> For example, I'm using Python in a Borland C++ Builder application. Although I 
> can open a FILE *, when passed to python15.dll the FILE * is not usable.
> 
> The addition of two helper functions would solve this problem:
> 
> FILE * PyRun_OpenFile(char *file, char *mode) 
> {
>   return fopen(file,mode)
> }
> 
> int PyRun_CloseFile(FILE *ptr)
> {
>   return fclose(ptr)
> }
> 
> This way embedding apps could get python15.dll to open the file and it would 
> work.
> 
> A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..

This is an elegant solution.  I think I'll add it.

Could you mail me your suggestion again with the legal boilerplate
included?  See http://www.python.org/1.5/bugrelease.html for the text
and explanation.  Our lawyers require that I request this silliness...

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:10
By: none

Comment:
From: "Brad Clements" <bkc@murkworks.com>
Subject: Re: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121)
Date: Wed, 3 Nov 1999 20:22:21 -0500

Here it is again.

Also, I believe this will resolve  FAQ entry 8.10


> 8.10. Can't get Py_RunSimpleFile() to work.
> This is very sensitive to the compiler vendor, version and (perhaps) even
> options. If the FILE* structure in your embedding program isn't the same as
> is assumed by the Python interpreter it won't work. The Python 1.5.* DLLs
> (python15.dll) are all compiled with MS VC++ 5.0 and with
> multithreading-DLL options (/MD, I think). 
> 
> If you can't change compilers or flags, try using Py_RunSimpleString(). A
> trick to get it to run an arbitrary file is to construct a call to
> execfile() with the name of your file as argument. 
> 
> 
> 
> ---------------------------------------------------------------------------
> -----


> Here's what I said for Python 1.5.2 on Win32 #0
> 
> PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
> usable on WIN32 from non-VC applications because python15.dll is statically 
> linked to the MS runtime DLL. Embedding applications that try to use these 
> functions are passing in FILE * structures that do not match MS's runtime 
> format. 
> 
> For example, I'm using Python in a Borland C++ Builder application. Although I 
> can open a FILE *, when passed to python15.dll the FILE * is not usable.
> 
> The addition of two helper functions would solve this problem:
> 
> FILE * PyRun_OpenFile(char *file, char *mode) 
> {
>   return fopen(file,mode)
> }
> 
> int PyRun_CloseFile(FILE *ptr)
> {
>   return fclose(ptr)
> }
> 
> This way embedding apps could get python15.dll to open the file and it would 
> work.
> 
> A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..


I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



Brad Clements,                bkc@murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               ICQ: 14856937

-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-12 09:01
By: jhylton

Comment:
Guido -- In 1999, you said you would add this feature.  Did you?

-------------------------------------------------------

Date: 2000-Sep-13 03:53
By: gvanrossum

Comment:
This is a feature request.
Jeremy, how's that feature request PEP coming?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110821&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 11:57:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 03:57:08 -0700
Subject: [Python-bugs-list] [Bug #110831] readline on QNX (PR#192)
Message-ID: <200009131057.DAA06517@bush.i.sourceforge.net>

Bug #110831, was updated on 2000-Aug-01 14:12
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: readline on QNX (PR#192)

Details: Jitterbug-Id: 192
Submitted-By: davidv@elisra.com
Date: Thu, 27 Jan 2000 13:31:16 -0500 (EST)
Version: 1.52
OS: Qnx


This is not a bug.
I have compiled Python 1.52 with Watcom on QNX. The Linux readline doesn't
work good with QNX. This  simple patch for /Parser/myreadline.c
replaces readline with QNX input_line function.

------------------------------------------------------------
60,68d59
<
< #ifdef __QNX__
<   p = input_line( fp, buf, len );
<   if( p ) {
<    int n = strlen(p);
<    p[n] = '\n';
<    p[n+1] = 0;
<   }
< #else
70d60
< #endif
-------------------------------------------------------------


====================================================================
Audit trail:
Mon Feb 07 12:34:32 2000	guido	sent reply 1
Mon Feb 07 12:34:49 2000	guido	changed notes
Mon Feb 07 12:34:49 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:13
By: none

Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: readline on QNX (PR#192)
Date: Mon Feb  7 12:34:32 2000

> This is not a bug.
> I have compiled Python 1.52 with Watcom on QNX. The Linux readline doesn't
> work good with QNX. This  simple patch for /Parser/myreadline.c
> replaces readline with QNX input_line function.
> 
> ------------------------------------------------------------
> 60,68d59
> <
> < #ifdef __QNX__
> <   p = input_line( fp, buf, len );
> <   if( p ) {
> <    int n = strlen(p);
> <    p[n] = '\n';
> <    p[n+1] = 0;
> <   }
> < #else
> 70d60
> < #endif
> -------------------------------------------------------------

David, please see www.python.org/patches for instructions on how to send
patches.  The Bugs List is not the right place, sorry!

--Guido van Rossum

-------------------------------------------------------

Date: 2000-Aug-01 14:13
By: none

Comment:
Should go to patches@python.org.

-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 03:57
By: gvanrossum

Comment:
There is not enough context in the patch to do anything with it.
(PLEASE ALWAYS USE CONTEXT DIFFS OR UNIFIED DIFFS!)
If the submittor is still interested in supplying a working patch, and if this is still a problem with Python 2.0b1, please use the SF patch manager to submit a proper patch.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110831&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 11:59:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 03:59:08 -0700
Subject: [Python-bugs-list] [Bug #110842] dl.RTLD_GLOBAL missing (PR#313)
Message-ID: <200009131059.DAA06556@bush.i.sourceforge.net>

Bug #110842, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: dl.RTLD_GLOBAL missing (PR#313)

Details: Jitterbug-Id: 313
Submitted-By: loewis@informatik.hu-berlin.de
Date: Thu,  4 May 2000 09:54:13 -0400 (EDT)
Version: 1.5.2
OS: Solaris


The dl module does not support all flags to dlopen available on a specific
system; eg. dl.open("foo.so",dl.RTLD_GLOBAL) does not work.

On Solaris, the following constants are defined, in addition
RTLD_NOLOAD
RTLD_GLOBAL
RTLD_LOCAL
RTLD_PARENT
RTLD_GROUP
RTLD_WORLD
RTLD_NODELETE





====================================================================
Audit trail:
Mon May 22 17:25:17 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-11 09:43
By: loewis

Comment:
Fix is in patch 101472:
http://sourceforge.net/patch/?func=detailpatch&patch_id=101472&group_id=5470
-------------------------------------------------------

Date: 2000-Sep-13 03:59
By: gvanrossum

Comment:
Closed - we can do triage on the patch intead. (patch#101472)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110842&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 12:08:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 04:08:10 -0700
Subject: [Python-bugs-list] [Bug #110611] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Message-ID: <200009131108.EAA07100@bush.i.sourceforge.net>

Bug #110611, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Signal processing bug (Linux threads, readline, whatever else) (PR#196)

Details: Jitterbug-Id: 196
Submitted-By: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Date: Tue, 1 Feb 2000 14:43:09 +0100
Version: None
OS: None

--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi,

this must be the strangest bug report ever sent to bugs-py ;-).

I don't expect a resolution for this bug from you, I just wanted to make
sure this thing is recorded and the BTS. Perhaps somebody could give me a
hint where I could look for the misbehavior. Candidates seem to be glibc,
LinuxThreads, GNU readline, the Python readline module and the Python thread
support ;-)

In 1.5.2, there's a strange problem with signals on Linux systems. This has
been discussed before on the mailing list, probably it even has a relation
to Bug#102 ("incorrect signal processing"), but IMHO this reports adds a few
other aspects. Definitely it is a (platform-specific) problem in 1.5.2.


I have problems describing the bug, since the behavior seems to depend on so
many parameters. The most obvious incarnation of the problem is probably
this:

In the Python 1.5.2 interpreter included with Debian 2.2 ("potato"), if you
press Control-C on the command line (or send a SIGINT), the interpreter
exits to the shell:

  freefly;104> python
  Python 1.5.2 (#0, Sep 13 1999, 09:12:57)  [GCC 2.95.1 19990816 (release)]=
 on
      linux2=20
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  >>> [Ctrl-C]
  freefly;105>=20

Normally, you'd expect a KeyboardInterrupt exception here.



Now I tried and compiled different configurations of Python (each from a
pristine source tree) on this Debian system:

  (151+t+rl)   Python 1.5.1 (threads, readline)
  (152)        Python 1.5.2 (no threads, no readline) =20
  (152+rl)     Python 1.5.2 (no threads, readline)
  (152+t)      Python 1.5.2 (threads, no readline)
  (152+t+rl)   Python 1.5.2 (threads, readline)
  (152+pth+rl) Python 1.5.2 (GNU Pth threads, readline)

Thread support was realized with glibc 2.1.2's LinuxThreads, i.e. pthreads.
readline was GNU readline 2.1 (for the record, I also tried 4.1beta3, but
this made no difference).

When I refer to Debian 2.1 ("slink"), this is a system with glibc 2.0.7 and
the same GNU readline version 2.1.



The following tables show the output of some experiments with those
configurations. The [] brackets show the keys pressed. Note that a line like
"[Ctrl-C][Enter]" implies that the interpreter showed no visible reaction to
the first Ctrl-C! "----" lines mean that I started up a new clean session.


(1) This is what happens when you start up a new interpreter and press
    Ctrl-C once, twice and so on, while on the command line:

152,152+t             152+rl,152+pth+rl  152+t+rl        151+t+rl
=3D=3D=3D=3D=3D=3D=3D=3D=3D             =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D  =3D=3D=3D=3D=3D=3D=3D=3D        =3D=3D=3D=3D=3D=3D=3D=3D
------------------    ----------------   -------------   ----------------
>>> [Ctrl-C][Ctrl-C]  >>> [Ctrl-C]       >>> [Ctrl-C]    >>> [Ctrl-C][Ct...]
KeyboardInterrupt     KeyboardInterrupt  freefly:5>      ----------------
>>> [Ctrl-C]          >>> [Ctrl-C]       -------------
KeyboardInterrupt     KeyboardInterrupt
>>> [Ctrl-C]          >>> [Ctrl-C]
KeyboardInterrupt     KeyboardInterrupt
>>> [Ctrl-C]          >>> [Ctrl-C]
KeyboardInterrupt     KeyboardInterrupt
------------------    ----------------

                                         152+t+rl (on a Debian 2.1 system)
                                         =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
                                         ---------------------
                                         >>> [Ctrl-C]
                                         KeyboardInterrupt
                                         >>> [Ctrl-C][Ctr...]
                                         ---------------------

  -> 1.5.2 with readline but without LinuxThreads is right.
  -> For some reason, 1.5.2 without readline ignores the first SIGINT.
  -> 1.5.2 with both readline and LinuxThreads kill the interpreter.
  -> 1.5.1 seems to ignore all SIGINTs's. =20
  -> For 1.5.2 running glibc 2.0.7 (instead of 2.1.2) and readline, the
     interpreter doesn't get killed, but still after the first SIGINT all
     following SIGINTs are ignored.
    =20
  -> It's worth a note that with only one of readline or thread support, the
     package seems to behave more reasonable; have both enabled is bad.
    =20
  -> With threading support by means of GNU Pth (instead of the native libc6
     LinuxThreads), the package behaves more correctly, too!

    =20
(2) Now on those systems who seemed to ignore the first SIGINT, I pressed
    Enter after it:

152,152+t                           151+t+rl
=3D=3D=3D=3D=3D=3D=3D=3D=3D                           =3D=3D=3D=3D=3D=3D=3D=
=3D
---------------------               --------------------
>>> [Ctrl-C][Enter]                 >>> [Ctrl-C][Enter]
Traceback (innermost last):         Traceback (innermost last):
  File "<stdin>", line 0, in ?      File "<stdin>", line 0, in ?
KeyboardInterrupt                   KeyboardInterrupt
>>> [Ctrl-C]                        >>> [Ctrl-C][Enter]
KeyboardInterrupt                   Traceback (innermost last):
---------------------                 File "<stdin>", line 0, in ?
                                    KeyboardInterrupt
                                    >>>
                                    --------------------

				   =20
  -> Obviously, the interpreter *DID* record the SIGINT in the first place,
     it just didn't provoke any immediate action=20
  -> On 1.5.2 without readline, the second and all following SIGINTs are
     handled as one would expect.
  -> 1.5.1 with thread and readline shows this strange behavior not only for
     the first, but also for the second and any following SIGINT.


    =20
(3) On the glibc 2.0.7 system, I verified that indeed all subsequent SIGINTs
    are ignored. You're not able even to interrupt a loop, after the
    interpreter has received a SIGINT while he was on the command line:
    =20
152+t+rl (on a Debian 2.1 system)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
---------------------
>>> [Ctrl-C]
KeyboardInterrupt
>>> [Ctrl-C][Enter]
>>> [Ctrl-C][Enter]
{kein weiteres SIGINT
wird akzeptiert, auch im Laufen:}
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
=2E..
999
>>>
---------------------
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
Traceback (innermost last):
  File "<stdin>", line 1, in ?
KeyboardInterrupt
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
Traceback (innermost last):
  File "<stdin>", line 1, in ?
KeyboardInterrupt
>>> [Ctrl-C]
KeyboardInterrupt
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
=2E..
999
>>>
---------------------

  -> Note that it didn't hurt to break multiple times into a loop;
     only SIGINTs on the command line do mess up the interpreter!


    =20
    =20
(4) In the Debian 2.2 Python package, you have to be careful not to kill the
    interpreter; that's especially a problem when you try to break into a
    loop--if you hold down Ctrl-C for too long, the interpreter quits!
    =20
152+t+rl (Debian 2.2 package)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
---------------------
>>> [Ctrl-C]
freefly:5>
---------------------
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401

KeyboardInterrupt
>>>
---------------------
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C pressed down for a longer time]
400
401

freefly;19>=20
---------------------




(5) The Debian 2.2 package behaves more reasonable when the readline module
    has been moved out of the way:

152+t (Debian 2.2 package, readline module moved out of the way)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
---------------------
>>> [Ctrl-C][Ctrl-C]
KeyboardInterrupt
>>> ...                   (vgl. 152, 152+t)
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
40[Enter]
Traceback (innermost last):
  File "<stdin>", line 0, in ?
KeyboardInterrupt
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
KeyboardInterrupt
>>>


--FL5UXtIhxfXey3p5
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4luLt3eVfDf25G40RAQw9AKDhLyI7RDYt3G85Rxet2ZlK1b1nKwCg3zl/
tasWxAOGLUK3K3ucMBbhBag=
=PTOI
-----END PGP SIGNATURE-----

--FL5UXtIhxfXey3p5--


====================================================================
Audit trail:
Mon Feb 07 12:38:12 2000	guido	changed notes
Mon Feb 07 12:38:12 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:05
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Date: Wed, 2 Feb 2000 03:04:04 -0500

[flight@mathi.uni-heidelberg.de]

> this must be the strangest bug report ever sent to bugs-py ;-).

No, but I don't recall one that evidenced more hard & tedious work!  Wow.
Thank you.  Switch to Windows -- it's so much more reliable <wink>.

If you haven't already done so, may I suggest building Python from the
current CVS development source tree instead?

http://www.python.org/download/cvs.html

This may be a waste of effort, but I'd hate to see you pour more time
tracking down obscure bugs that may already have been fixed.  Contrarily, if
the current CVS version still displays the problems, more work devoted to
tracking them down is certain not to be a waste.



-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Date: Wed, 2 Feb 2000 14:25:07 +0100

Hi,

> If you haven't already done so, may I suggest building Python from the
> current CVS development source tree instead?

sorry, I forgot to mention that I tried that. Didnt't change the behavior
at all (I also saw that there were no big changes to the readline nor to
the threading code since 1.5.2).

    Gregor


-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Subject: Returned mail: User unknown
Date: Thu, 3 Feb 2000 11:46:44 +0100 (MET)

This is a MIME-encapsulated message

--LAA26536.949574804/relay.uni-heidelberg.de

The original message was received at Thu, 3 Feb 2000 11:46:41 +0100 (MET)
from mailserver.mathi.uni-heidelberg.de [129.206.26.32]

   ----- The following addresses had permanent fatal errors -----
<bugs-by@python.org>

   ----- Transcript of session follows -----
.. while talking to parrot.python.org.:
>>> RCPT To:<bugs-by@python.org>
<<< 550 <bugs-by@python.org>... User unknown
550 <bugs-by@python.org>... User unknown

--LAA26536.949574804/relay.uni-heidelberg.de
Content-Type: message/delivery-status

Reporting-MTA: dns; relay.uni-heidelberg.de
Received-From-MTA: DNS; mailserver.mathi.uni-heidelberg.de
Arrival-Date: Thu, 3 Feb 2000 11:46:41 +0100 (MET)

Final-Recipient: RFC822; bugs-by@python.org
Action: failed
Status: 5.1.1
Remote-MTA: DNS; parrot.python.org
Diagnostic-Code: SMTP; 550 <bugs-by@python.org>... User unknown
Last-Attempt-Date: Thu, 3 Feb 2000 11:46:44 +0100 (MET)

--LAA26536.949574804/relay.uni-heidelberg.de
Content-Type: message/rfc822

Return-Path: <flight@mathi.uni-heidelberg.de>
Received: from mailserver.mathi.uni-heidelberg.de (mailserver.mathi.uni-heidelberg.de [129.206.26.32])
	by relay.uni-heidelberg.de (8.9.3+Sun/8.9.3) with ESMTP id LAA26531
	for <bugs-by@python.org>; Thu, 3 Feb 2000 11:46:41 +0100 (MET)
Received: from testserv.mathi.uni-heidelberg.de (testserv.mathi.uni-heidelberg.de [129.206.26.30])
	by mailserver.mathi.uni-heidelberg.de (Postfix) with SMTP id CFF5512917
	for <bugs-by@python.org>; Thu,  3 Feb 2000 11:48:11 +0100 (CET)
Received: by testserv.mathi.uni-heidelberg.de (sSMTP sendmail emulation); Thu, 3 Feb 2000 11:48:12 +0100
Date: Thu, 3 Feb 2000 11:48:12 +0100
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
To: bugs-by@python.org
Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Message-ID: <20000203114812.B18567@mathi.uni-heidelberg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0pre3i

Fredric Lundh pointed me to Alex Zbyslaw's posting regarding this topic
(http://x44.deja.com/getdoc.xp?AN=545159177).

Indeed Alex' patch1 (http://www.xfb52.dial.pipex.com/patches/python.shtml)
for FreeBSD (disabling the interrupt handler chanege in the readline module)
works for Debian, too, i.e. if I stick with the default inthandler in the
readline module, SIGINT doesn't kill the interpreter anymore.

Still, the drawback of this change is that I have to press RETURN before
a SIGINT is spotted by Python (btw, this is the same behavior as with 1.5.1
on the system with the same configuration).

Still, IMHO this behavior is preferable.

    Gregor

--LAA26536.949574804/relay.uni-heidelberg.de--


-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Subject: Re: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Date: Fri, 11 Feb 2000 14:52:42 +0100


--dDRMvlgZJXvWKvBx
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Ok, one more data point:

On Fri, Feb 11, 2000 at 08:29:43AM -0500, Randall Hopper wrote:
> You know, I think you may have it.  On IRIX, I don't have Python built
> with threads.  However, on FreeBSD at home I'd guess that it is (I built =
it
> from ports).  My IRIX python has no problem with Ctrl-C while my FreeBSD
> version at home locks up with Ctrl-C.  I rebuilt my IRIX Python
> --with-thread, and now it hangs when Ctrl-C is hit.

And now, we're three: When using threads and readline, Ctrl-C hangs IRIX and
FreeBSD and kills Linux Python.

This doesn't sound like a kernel problem, more like a problem with readline
not being thread-safe I guess.

    Gregor
   =20

--dDRMvlgZJXvWKvBx
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4pBQq3eVfDf25G40RAUbSAJ41b+DgwHEmRUm0uQcJLjvZ3ROiSwCdH8Xq
jFH5J1TsLQBbQTPU5Xvv0Bo=
=0j16
-----END PGP SIGNATURE-----

--dDRMvlgZJXvWKvBx--

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110611&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 12:09:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 04:09:14 -0700
Subject: [Python-bugs-list] [Bug #110854] Re: Date problem unresolved [DIN 2646] (fwd) (PR#109)
Message-ID: <200009131109.EAA07120@bush.i.sourceforge.net>

Bug #110854, was updated on 2000-Aug-01 14:37
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Works For Me
Bug Group: Irreproducible
Priority: 3
Summary: Re: Date problem unresolved [DIN 2646] (fwd) (PR#109)

Details: Jitterbug-Id: 109
Submitted-By: Curt Finch <curt@journyx.com>
Date: Thu, 14 Oct 1999 14:58:08 -0500 (CDT)
Version: None
OS: None

anyone heard of any python time bugs?

__________________________________________________________________
Web-Based Project Management,                              Journyx
TimeSheet and Tracking Software       FREE           (800)755-9878
FREE at http://journyx.com/wts.html           curt@www.JOURNYX.com
------------------------------------------------------------------


---------- Forwarded message ----------
Date: Thu, 14 Oct 1999 14:09:35 -0500 (CDT)
From: John Maddalozzo <john@journyx.com>
To: "Stappert, Andreas" <andreas.stappert@key-work.de>
Cc: support@journyx.com
Subject: Re: Date problem unresolved [DIN 2646]


Andreas, 

I'm stumped. It seems there is a problem in the python time library.
I may have to post a message to a python news group if code inspection
doesn't turn anything up. 2646 is the problem report number. 
We'll dig around and see what we can find out.

Meanwhile, you might want to send me the output of the uname -a command
and any other information you have that might help. (Linux level, etc)

Regards, John


__________________________________________________________________
Web-Based Project Management and TimeSheet Software    JournyxTime
FREE at http://journyx.com/wts.html
John Maddalozzo  - john@JOURNYX.com  (512)834-8888 / (800)755-9878
------------------------------------------------------------------

On Thu, 14 Oct 1999, Stappert, Andreas wrote:

> Hi John,
> 
> Well, for some reason I always have the strangest thing happen to me :-)
> even though I try to conform to every standards I know of...
> 
> Here is what I get. Looks like it matches your machine (our server date is
> set a day off). Do you think it would help if we change the timezone to EST
> or something?
> 
> > date +%s
> 939838233
> timesheet:~>
> 
> The hardware is an (old) 486 (yes I know old ... that is just our
> testserver, once we are putting Journyx to real use, we are going to put a
> nicer machine underneath it). I don't know the mainboard type by heart.
> 
> Oh, I should probably also tell you this: At the beginning, the time was
> right but once we got some modifications done and rebootet the machine, it
> started acting this strange.
> 
> Regards,
> Andreas
> 
> -----Ursprungliche Nachricht-----
> Von: John Maddalozzo [mailto:john@journyx.com]
> Gesendet: Donnerstag, 14. Oktober 1999 20:05
> An: Stappert, Andreas
> Betreff: Re: AW: AW: Date problem unresolved
> 
> 
> 
> Very strange, Andreas.
> the time.time() result shows the number of seconds since the "epoch"
> (see http://python.org/doc/current/lib/module-time.html)
> Your number of seconds should be somewhere between
> 939916983.851	(the time on my computer when I wrote example note below)
> and
> 939923915.897   (the time on my computer I just now checked)
> 
> What does the command
> date +%s
> say?
> What hardware are you using?
> 
> __________________________________________________________________
> Web-Based Project Management and TimeSheet Software    JournyxTime
> FREE at http://journyx.com/wts.html
> John Maddalozzo  - john@JOURNYX.com  (512)834-8888 / (800)755-9878
> ------------------------------------------------------------------
> 
> On Thu, 14 Oct 1999, Stappert, Andreas wrote:
> 
> > Here you go (my mistake):
> >
> > timesheet:~/jtime/jtime/pi/bin> python
> > Python 1.5.2 (#1, Sep 27 1999, 17:01:09)  [GCC egcs-2.91.66 19990314/Linux
> > (egcs
> > - on linux2
> > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> > >>> import time
> > >>> import wtdate
> > >>> wtdate.today()
> > Thu 13 Jul 1995
> > >>> time.localtime(time.time())
> > (1995, 7, 13, 8, 38, 9, 3, 194, 1)
> > >>> time.time()
> > 805617494.587
> > >>> time.gmtime(time.time())
> > (1995, 7, 13, 6, 38, 54, 3, 194, 0)
> > >>> time.gzname
> > Traceback (innermost last):
> >   File "<stdin>", line 1, in ?
> > AttributeError: gzname
> > >>> time.timezone
> > -3600
> > >>> time.tzname
> > ('CET', 'CEST')
> > >>>
> >
> > -----Ursprungliche Nachricht-----
> > Von: John Maddalozzo [mailto:john@journyx.com]
> > Gesendet: Donnerstag, 14. Oktober 1999 19:09
> > An: Stappert, Andreas
> > Betreff: Re: AW: Date problem unresolved
> >
> >
> >
> > Hi Andreas,
> > Did you remember to source setup?
> > In pi/bin at the shell prompt do:
> > . ./setup
> > You need to do that first. To check that it has been sourced, do
> > echo $PYTHONPATH
> > that should return something like this:
> > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 753>. ./setup
> > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 754>echo $PYTHONPATH
> >
> //home/john_scratch/jtime/jtime/pi/apache/wtlib://home/john_scratch/jtime/jt
> >
> ime/pd/Linux/python/lib/python1.5/://home/john_scratch/jtime/jtime/pi/apache
> > /serverroot/cgi-bin
> >
> > Then it should be able to find wtdate.pyc in pi/apache/wtlib
> >
> > Regards, John
> >
> > On Thu, 14 Oct 1999, Stappert, Andreas wrote:
> >
> > > Hi John,
> > >
> > > I already get stuck when I try to import wtdate:
> > >
> > >  python
> > > Python 1.5.1 (#1, Mar 21 1999, 22:49:36)  [GCC egcs-2.91.66 19990314/Li
> on
> > > linux
> > > -i386
> > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> > > >>> import time
> > > >>> import wtdate
> > > Traceback (innermost last):
> > >   File "<stdin>", line 1, in ?
> > > ImportError: No module named wtdate
> > >
> > > -----Ursprungliche Nachricht-----
> > > Von: John Maddalozzo [mailto:john@journyx.com]
> > > Gesendet: Donnerstag, 14. Oktober 1999 18:05
> > > An: Stappert, Andreas
> > > Cc: support@journyx.com
> > > Betreff: Re: Date problem unresolved
> > >
> > >
> > >
> > > Andreas,
> > > This must be some problem with resolving the time zone.
> > > Please do the following and send me the output.
> > >
> > > What this is doing is invoking python and using its libraries to get
> > dates.
> > > I'm hoping that this will give us some idea of what is wrong.
> > > Regards, John
> > >
> > > cd <jtime install dir>/jtime/pi/bin
> > > . ./setup
> > > python
> > > import time
> > > import wtdate
> > > wtdate.today()
> > > time.localtime(time.time())
> > > time.time()
> > > time.gmtime(time.time())
> > > time.gzname
> > > time.timezone
> > >
> > > For example when I do it here I get...
> > >
> > > [rebobiz] /home/john_scratch/jtime/jtime/pi/bin 743>python
> > > Python 1.5.2 (#1, Oct  2 1999, 23:28:23)  [GCC egcs-2.91.66
> 19990314/Linux
> > > (egcs- on linux2
> > > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> > > >>> import time
> > > >>> import wtdate
> > > >>> wtdate.today()
> > > Thu 14 Oct 1999
> > > >>> time.localtime(time.time())
> > > (1999, 10, 14, 11, 2, 51, 3, 287, 1)
> > > >>> time.time()
> > > 939916983.851
> > > >>> time.gmtime(time.time())
> > > (1999, 10, 14, 16, 7, 10, 3, 287, 0)
> > > >>> time.tzname
> > > ('CST', 'CDT')
> > > >>> time.timezone
> > > 21600
> > >
> > >
> > >
> > > __________________________________________________________________
> > > Web-Based Project Management and TimeSheet Software    JournyxTime
> > > FREE at http://journyx.com/wts.html
> > > John Maddalozzo  - john@JOURNYX.com  (512)834-8888 / (800)755-9878
> > > ------------------------------------------------------------------
> > >
> > > 	On Thu, 14 Oct 1999, Stappert, Andreas wrote:
> > >
> > > > Hello there,
> > > > We are still having a major problem with the Journyx installation on
> our
> > > > Linux server:
> > > > The current date on the Linux machine is
> > > > 	Mit Okt 13 10:35:14 CEST 1999
> > > > but Journyx uses the below July 12, 1995 as current date. Is there any
> > way
> > > > to correct this problem?
> > > > We would like to go and find some more customers for Journyx but if we
> > can
> > > > not figure out how to correct this problem, we will not be able to
> > > > demonstrate it.
> > > > Thanks for your immediate attention
> > > > Andreas
> > > >
> > > > License Key Data
> > > > *	Dates
> > > > *	Install Date: Mon Okt 4 17:36:04 CEST 1999
> > > > *	Product Expiration Date: Never
> > > > *	Current Date: Wed 12 Jul 1995
> > > > *	Users
> > > > *	Licensed Number of Users: 10
> > > > *	Current Number of User Data Unavailable
> > > > *	Hosts
> > > > *	Licensed Host: 192
> > > > *	Current Host: 192
> > > > Operating System Information
> > > > *	Current: Linux 192.168.0.100 2.2.5-15de #1 Tue May 25 00:43:15 EDT
> > > > 1999 i486
> > > > *	Original: Linux karsrv01.key-work.de 2.2.5-15de #1 Tue May 25
> > > > 00:43:15 EDT 1999 i486 unknown
> > > > Credits
> > > > *	Docs: Sarah Griswold
> > > > *	Testing: Matt Neiman
> > > > *	Coding:
> > > > *	Chris Anderson
> > > > *	Curt Finch
> > > > *	John Maddalozzo
> > > > *	Andrew Reutter
> > > > *	Design and enhancement ideas: literally thousands of registered
> > > > users just like you. <http://journyx.com/featureq.html>
> > > >
> > > >
> > > >
> > > > -----------------------------------------------
> > > > Andreas Stappert
> > > > Key-Work Consulting GmbH
> > > >
> > > > Haid-und-Neu-Strasse 7 - 76131 Karlsruhe - Germany
> > > > +49 721 664936-0 - mailto:andreas.stappert@key-work.de
> > > >
> > > >
> > >
> >
> 
> 



====================================================================
Audit trail:
Mon Oct 18 17:53:07 1999	guido	changed notes
Mon Oct 18 17:53:07 1999	guido	changed notification
Mon Oct 18 17:53:08 1999	guido	moved from incoming to open
Tue Oct 19 00:42:35 1999	guido	changed notes
Tue Oct 19 00:42:37 1999	guido	moved from open to irreproducible

Follow-Ups:

Date: 2000-Aug-01 14:37
By: none

Comment:
Can't reproduce this here.
Your best bet is to look into the conversion of the time() value
to floating point -- maybe you are using a bogus floating point
emulation?

BTW, forwarding such a long thread of email without a clear summary of
the problem at the top makes it hard for me to read the bug report.

-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 04:09
By: gvanrossum

Comment:
Irreproducible.

If this is still a problem in Python 2.0(b1), please submit a new bug report with enough information to be able to reproduce the bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110854&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 12:11:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 04:11:09 -0700
Subject: [Python-bugs-list] [Bug #110860] IDLE class browser and decimal comma don't agree (PR#298)
Message-ID: <200009131111.EAA07170@bush.i.sourceforge.net>

Bug #110860, was updated on 2000-Aug-01 14:38
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Works For Me
Bug Group: Irreproducible
Priority: 5
Summary: IDLE class browser and decimal comma don't agree (PR#298)

Details: Jitterbug-Id: 298
Submitted-By: magnus@thinkware.se
Date: Tue, 18 Apr 2000 08:37:02 -0400 (EDT)
Version: 1.5.2
OS: NT 4


As soon as I open the class browser in IDLE (0.5) I get the traceback
below. Previously I had another strange bug that I suspect has to do
with Tcl/Tk and the fact that I have national settings with , (comma)
as decimal separator. With IDLE 0.4, >>> 5 / float(2) would result in
2,5 (not 2.5). It also wanted me to enter data like that. >>> 2.5 * 2
was rejected, and obviously >>> 2,5 * 2 was interpreted as (2, 5) * 2.
This was only a problem in the IDLE shell. Program files ran OK.

Considering "ValueError: invalid literal for float(): 0.0" below I
suspect the errors are related. (A hint is that the problem goes away
if I change the regional settings to decimal . in the control panel.)

>>> Exception in Tkinter callback
Traceback (innermost last):
  File "C:\Program\Python\Lib\lib-tk\Tkinter.py", line 764, in __call__
    return apply(self.func, args)
  File "C:\Program\Python\Tools\idle\EditorWindow.py", line 355, in
open_class_browser
    ClassBrowser.ClassBrowser(self.flist, base, [head])
  File "C:\Program\Python\Tools\idle\ClassBrowser.py", line 37, in __init__
    self.init(flist)
  File "C:\Program\Python\Tools\idle\ClassBrowser.py", line 59, in init
    node.expand()
  File "C:\Program\Python\Tools\idle\TreeWidget.py", line 133, in expand
    self.view()
  File "C:\Program\Python\Tools\idle\TreeWidget.py", line 144, in view
    visible_top = self.canvas.canvasy(0)
  File "C:\Program\Python\Lib\lib-tk\Tkinter.py", line 1200, in canvasy
    return getdouble(self.tk.call(
ValueError: invalid literal for float(): 0.0




====================================================================
Audit trail:
Mon May 22 17:17:16 2000	guido	changed notes
Mon May 22 17:17:16 2000	guido	moved from incoming to irreproducible

Follow-Ups:

Date: 2000-Aug-01 14:39
By: none

Comment:
Bizarrely, his locale affects Python number parsing.
Can't reproduce this.
-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 04:11
By: gvanrossum

Comment:
Irreproducible.

If this is still a problem in Python 2.0(b1), please submit a new bug report with as much information as possible about the platform, versions, etc.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110860&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 12:13:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 04:13:47 -0700
Subject: [Python-bugs-list] [Bug #112786] Build under Cygwin fails
Message-ID: <200009131113.EAA07310@bush.i.sourceforge.net>

Bug #112786, was updated on 2000-Aug-26 01:39
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Build under Cygwin fails

Details: Py1.6b1
========
1) socketmodule.c -- looks for netinet/tcp.h, which does not exist on cygwin.

2) gcc   python.o \
          ../libpython1.6.a    -lm  -o python
python.o: In function `main':
/usr/local/bin/Python-1.6b1/Modules/python.c:12: undefined reference to `Py_Main


Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 04:13
By: gvanrossum

Comment:
I don't have cygwin. Does anyone here have cygwin? I know Tim said the cygwin installer failed for him, so he doesn't have it. Is there someone outside the PythonLabs to whom we could assign this?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112786&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 12:21:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 04:21:25 -0700
Subject: [Python-bugs-list] [Bug #113145] config.h defines socklen_t, kills wxPython build
Message-ID: <200009131121.EAA07647@bush.i.sourceforge.net>

Bug #113145, was updated on 2000-Aug-30 12:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Wont Fix
Bug Group: None
Priority: 6
Summary: config.h defines socklen_t, kills wxPython build

Details: Building wxPython fails with 1.6  because config.h defines socklen_t; according to a comment, it checks sys/types.h. But /usr/include/bits/socket.h on Linux at least, tries to make a typedef with this name.



Follow-Ups:

Date: 2000-Sep-03 21:08
By: gvanrossum

Comment:
Could this be dependent on the Linux version? It seems my config.h had socklen_t defined on Red Hat 6.1, but it is undefined on Red Hat 6.2 (which would fix your problem if I understand it correctly).

What platform are you using?

-------------------------------------------------------

Date: 2000-Sep-03 22:10
By: dubois

Comment:
My system is 6.1 I think. (I didn't install it.) 
Here is uname -a:
Linux bruno.llnl.gov 2.2.12-20smp #1 SMP Mon Sep 27 10:34:45 EDT 1999 i686 unknown

-------------------------------------------------------

Date: 2000-Sep-13 04:21
By: gvanrossum

Comment:
Jeremy, you still have Red Hat 6.1, right?
Can you reproduce this? Run configure, and check config.h.
If it defines socklen_t, the bug is there.

It may be possible to fix the test for socklen_t by using AC_TRY_COMPILE() of a test program. This is done for example for uintptr_t. (The current test uses AC_CHECK_TYPE which only greps through CPP output.) A good way to learn more about autoconf. :-)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113145&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 12:22:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 04:22:56 -0700
Subject: [Python-bugs-list] [Bug #113328] Python 1.6b1 build failure on Solaris (with patch)
Message-ID: <200009131122.EAA07687@bush.i.sourceforge.net>

Bug #113328, was updated on 2000-Sep-01 04:18
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Duplicate
Bug Group: None
Priority: 5
Summary: Python 1.6b1 build failure on Solaris (with patch)

Details: Python 1.6b1 fails to build on Solaris due to Python's
config.h #define'ing socklen_t to be int.  socklen_t is a symbol many platforms' standard include files have a typedef for.

On Solaris, this results in the true typedef for socklen_t in sys/socket.h (one of the following):

typedef size_t          socklen_t;
typedef uint32_t        socklen_t;

being transformed into gibberish that will not compile.

Removing the offending socklen_t #define from config.h allows 1.6b1 to build on Solaris.

See also bugs 111319 and 113145.

Follow-Ups:

Date: 2000-Sep-01 08:07
By: VizNut

Comment:
Oops.  Ignore the "(with patch)" piece in the Summary.

-------------------------------------------------------

Date: 2000-Sep-13 04:22
By: gvanrossum

Comment:
This is the same problem as bug #113145.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113328&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 12:30:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 04:30:51 -0700
Subject: [Python-bugs-list] [Bug #114333] minidom fails to parse PI
Message-ID: <200009131130.EAA07964@bush.i.sourceforge.net>

Bug #114333, was updated on 2000-Sep-13 04:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: minidom fails to parse PI

Details: # Using Python2.0b1, minidom and expat:

s="""<?xml version='1.0'?><?pi-foobar?><test></test>"""
import xml.dom.minidom
p=xml.dom.minidom.parseString(s)

stack_trace="""
Traceback (most recent call last):
  File "test.py", line 6, in ?
    p=xml.dom.minidom.parseString(s)
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/minidom.py", line 45
2, in parseString
    return _doparse( pulldom.parseString, args, kwargs )
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/minidom.py", line 44
3, in _doparse
    events.expandNode( rootNode )
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/pulldom.py", line 14
2, in expandNode
    cur_node.parentNode.appendChild( cur_node )
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/minidom.py", line 40
0, in appendChild
    raise TypeError, "Two document elements disallowed"
TypeError: Two document elements disallowed
"""


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114333&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 12:37:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 04:37:35 -0700
Subject: [Python-bugs-list] [Bug #114333] minidom fails to parse PI
Message-ID: <200009131137.EAA08317@bush.i.sourceforge.net>

Bug #114333, was updated on 2000-Sep-13 04:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: minidom fails to parse PI

Details: # Using Python2.0b1, minidom and expat:

s="""<?xml version='1.0'?><?pi-foobar?><test></test>"""
import xml.dom.minidom
p=xml.dom.minidom.parseString(s)

stack_trace="""
Traceback (most recent call last):
  File "test.py", line 6, in ?
    p=xml.dom.minidom.parseString(s)
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/minidom.py", line 45
2, in parseString
    return _doparse( pulldom.parseString, args, kwargs )
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/minidom.py", line 44
3, in _doparse
    events.expandNode( rootNode )
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/pulldom.py", line 14
2, in expandNode
    cur_node.parentNode.appendChild( cur_node )
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/minidom.py", line 40
0, in appendChild
    raise TypeError, "Two document elements disallowed"
TypeError: Two document elements disallowed
"""


Follow-Ups:

Date: 2000-Sep-13 04:37
By: jrvosse

Comment:
See also the python xml-sig mail list:

http://www.python.org/pipermail/xml-sig/2000-September/004817.html
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114333&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 12:46:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 04:46:03 -0700
Subject: [Python-bugs-list] [Bug #114334] glob does not handle set coplementation ([^ ... ]) properly
Message-ID: <200009131146.EAA27654@delerium.i.sourceforge.net>

Bug #114334, was updated on 2000-Sep-13 04:46
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: glob does not handle set coplementation ([^ ... ]) properly

Details: The glob function in the glob module does not handle the set complementation correctly.

Example:

  glob('*[^C].cc')

should return all .cc file that do NOT have a 'C' before the dot. Instead it returns all files that DO
have a C before the dot.

Python:   v 1.5.2
Platform: HP-UX


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114334&group_id=5470


From jeremy@beopen.com  Wed Sep 13 12:58:55 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Wed, 13 Sep 2000 07:58:55 -0400 (EDT)
Subject: [Python-bugs-list] [Bug #110712] MALLOC_ZERO_RETURNS_NULL problem
In-Reply-To: <200009131051.DAA06329@bush.i.sourceforge.net>
References: <200009131051.DAA06329@bush.i.sourceforge.net>
Message-ID: <14783.27647.763061.792615@bitdiddle.concentric.net>

>>>>> "SF>" == noreply  <noreply@sourceforge.net> writes:

  SF>> Comment: I don't understand why the configure script would use
  SF>> a different malloc library for its test of malloc(0) than what
  SF>> is used later to compile Python. Could it be that simply "make
  SF>> clobber" and running configure again would solve the problem?

  SF>> I'm closing the bug report for now.  If this is still a problem
  SF>> with Python 2.0, please send email and I'll reopen it.

Guido,

Your last comment puzzles me.  How is anyone other than you and me
going to see the request to send email if it is still a problem?  The
bug is an old Jitterbug submission, which means that the original
submittor is not known by SF.

You need to send the original submittor an email yourself if you want
him to reply.  If you did send that email, the comment in the bug
report is misleading.  (It would be clearer to say: "I sent private
email to the submittor.  If he reports that it is still a problem with
2.0, I will reopen it.")

(You probably did not notice that it was a Jitterbug report.  But SF
doesn't always have an email address, even for new bugs.)

Jeremy


From noreply@sourceforge.net  Wed Sep 13 13:27:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 05:27:47 -0700
Subject: [Python-bugs-list] [Bug #114336] Python-2.0b1 build fails on OpenBSD 2.7
Message-ID: <200009131227.FAA29331@delerium.i.sourceforge.net>

Bug #114336, was updated on 2000-Sep-13 05:27
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python-2.0b1 build fails on OpenBSD 2.7

Details: I did './configure && make', the link failed due to it attempting to link the nonexistant library 'db'. I edited Modules/Setup.config.in and removed ' -ldb' and it compiled ok.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114336&group_id=5470


From skip@mojam.com (Skip Montanaro)  Wed Sep 13 18:08:12 2000
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Wed, 13 Sep 2000 12:08:12 -0500 (CDT)
Subject: [Python-bugs-list] [Bug #114336] Python-2.0b1 build fails on OpenBSD 2.7
In-Reply-To: <200009131227.FAA29331@delerium.i.sourceforge.net>
References: <200009131227.FAA29331@delerium.i.sourceforge.net>
Message-ID: <14783.46204.83567.811572@beluga.mojam.com>


    >> Details: I did './configure && make', the link failed due to it
    >> attempting to link the nonexistant library 'db'. I edited
    >> Modules/Setup.config.in and removed ' -ldb' and it compiled ok.

This was recently fixed (after the 2.0b1 release).  If you can check out a
fresh copy from the CVS repository, please try it and let me know if it
still gives you problems.

-- 
Skip Montanaro (skip@mojam.com)
http://www.mojam.com/
http://www.musi-cal.com/


From noreply@sourceforge.net  Wed Sep 13 18:16:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 10:16:18 -0700
Subject: [Python-bugs-list] [Bug #114323] Pb PYTHON
Message-ID: <200009131716.KAA08283@delerium.i.sourceforge.net>

Bug #114323, was updated on 2000-Sep-13 02:16
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: Works For Me
Bug Group: None
Priority: 5
Summary: Pb PYTHON

Details: 

Find the encoutered problem when we are running python interactively with the following commands

python
>>> from Tkinter import *
>>> root=Tk()
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.5/lib-tk/Tkinter.py", line 886, in __init__
    self.tk = _tkinter.create(screenName, baseName, className)
TclError: Can't find a usable init.tcl in the following directories: 
    
We have compile python on SUN ULTRA 60 - Solaris 2.6 with GCC using the building and installing commndes 
found in the book Python and Tkinter
Please send me a mail as soon as possible






This probably means that Tcl wasn't installed properly.

>>> 


Follow-Ups:

Date: 2000-Sep-13 10:16
By: loewis

Comment:
Most likely, the Tcl installation on this machine does not work. Unfortunately,
there is no indication as to how Tcl was installed, or what version of Tcl was installed. Neither did the submitter leave any contact information, so it will be
impossible to reproduce the problem or analyze it further.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114323&group_id=5470


From noreply@sourceforge.net  Wed Sep 13 18:43:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 10:43:51 -0700
Subject: [Python-bugs-list] [Bug #114359] snpplib
Message-ID: <200009131743.KAA23069@bush.i.sourceforge.net>

Bug #114359, was updated on 2000-Sep-13 10:43
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: snpplib

Details: I just implemented RFC 1861 -- SNPP for a company, and they are letting me release it Open Source. snpplib.py is based on smtplib.py (very similar protocols) and is in use in a fairly hefty production system at the moment. I know that the Perl folk have snpp support in their net library, so I wanted to offer up mine for the Python distribution. Sorry if this isn't the right forum for that. 
I've opened a SourceForce project for it called PySNPP, because I have a higher level implementation class as well, but I don't think it's quite as well suited for being in the distribution. 

The files should be up here on SourceForge by tomorrow. You are more than welcome to snag them if you like. 


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114359&group_id=5470


From jon+sourceforge@unequivocal.co.uk  Wed Sep 13 19:13:33 2000
From: jon+sourceforge@unequivocal.co.uk (Jon Ribbens)
Date: Wed, 13 Sep 2000 19:13:33 +0100
Subject: [Python-bugs-list] [Bug #114336] Python-2.0b1 build fails on OpenBSD 2.7
In-Reply-To: <14783.46204.83567.811572@beluga.mojam.com>; from skip@mojam.com on Wed, Sep 13, 2000 at 12:08:12PM -0500
References: <200009131227.FAA29331@delerium.i.sourceforge.net> <14783.46204.83567.811572@beluga.mojam.com>
Message-ID: <20000913191333.A16263@snowy.squish.net>

Skip Montanaro <skip@mojam.com> wrote:
> This was recently fixed (after the 2.0b1 release).  If you can check out a
> fresh copy from the CVS repository, please try it and let me know if it
> still gives you problems.

Compiles fine with latest CVS.

However, 'make test' says:

test_grp
pid 12669: Fatal error '_libc_private_storage_lock' at line 14 in file /usr/src/lib/libc_r/thread/thread_storage.c (errno = 2)
Abort (core dumped) 
*** Error code 134

Should I open a separate bug report for this? It might be an OpenBSD problem,
I'm not sure.


From noreply@sourceforge.net  Wed Sep 13 23:49:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Sep 2000 15:49:01 -0700
Subject: [Python-bugs-list] [Bug #114245] utime can not accept directory under NT
Message-ID: <200009132249.PAA02717@bush.i.sourceforge.net>

Bug #114245, was updated on 2000-Sep-12 06:36
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: utime can not accept directory under NT

Details: Whenever supply a directory to utime path parameter, exception raised.  The problem is MS C run time library utime function only works on files, but not directories.  To fix this bug, MS utime has to be replaced by some function that works with directory.

Follow-Ups:

Date: 2000-Sep-13 15:49
By: gangli59

Comment:
I submitted a patch that uses win32 api instead MSC run time library
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114245&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 09:51:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 01:51:06 -0700
Subject: [Python-bugs-list] [Bug #114336] Python-2.0b1 build fails on OpenBSD 2.7
Message-ID: <200009140851.BAA09807@delerium.i.sourceforge.net>

Bug #114336, was updated on 2000-Sep-13 05:27
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python-2.0b1 build fails on OpenBSD 2.7

Details: I did './configure && make', the link failed due to it attempting to link the nonexistant library 'db'. I edited Modules/Setup.config.in and removed ' -ldb' and it compiled ok.


Follow-Ups:

Date: 2000-Sep-14 01:51
By: jribbens

Comment:
Post-2.0b1 CVS version compiles OK.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114336&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 10:05:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 02:05:10 -0700
Subject: [Python-bugs-list] [Bug #110655] getpass.getpass on Windows (PR#349)
Message-ID: <200009140905.CAA10356@delerium.i.sourceforge.net>

Bug #110655, was updated on 2000-Jul-31 14:10
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Wont Fix
Bug Group: Platform-specific
Priority: 5
Summary: getpass.getpass on Windows (PR#349)

Details: Jitterbug-Id: 349
Submitted-By: ctalley@caci.com
Date: Thu,  8 Jun 2000 15:52:19 -0400 (EDT)
Version: 1.5.2
OS: W95


When using this code, the third line is skipped.  That is, the prompt
appears, but the program doesn't pause to accept input data.  It goes
right to the fourth line and pauses there.  I end up with a null string
for "fromaddr".

username=raw_input('Enter FTP server account username: ')
password=getpass.getpass('Enter FTP server account password: ')
fromaddr=raw_input('Enter your e-mail address: ')
toaddr=raw_input('Enter e-mail address for notification: ')

When using this code, everything works (although echo of the
password isn't suppressed.)

username=raw_input('Enter FTP server account username: ')
password=raw_input('Enter FTP server account password: ')
fromaddr=raw_input('Enter your e-mail address: ')
toaddr=raw_input('Enter e-mail address for notification: ')

The difference between the two code segments is that the first uses
the getpass method on the second line and the second uses raw_input.
What I think is happening is that getpass is leaving some garbage
in a buffer somewhere which is seen by raw_input as data.  raw_input
happily accepts the data and goes to the next line.  I've devised
several workarounds including "flush_input_buffer=raw_input('')"
immediately following the call to getpass.  It's ugly, but it works.

Thanks,
Carl Talley



====================================================================
Audit trail:
Tue Jul 11 08:25:59 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 03:23
By: gvanrossum

Comment:
Confirmed with Python 2.0b1 on Win98SE.
The bug does not occur on Linux.
Tim, the getpass code for Windows is different than on Unix, so please have a look!
-------------------------------------------------------

Date: 2000-Sep-14 02:05
By: tim_one

Comment:
Mark, I assigned this to you on the chance you know a better trick.  Note that I already closed it as "Won't Fix", so if you *don't* know a better trick you don't have to do anything here.


This can't be fixed on Windows.  As the MS docs say, "The console I/O routines are not compatible with stream I/O or low-level I/O library routines", and getpass uses the console I/O routines on Windows.  Mixing console I/O with C stdio is undefined, and C stdio doesn't provide a way to do non-echo'ing input itself.

About the best you can do is to define your own raw_input variant that uses console I/O too.  For example,

def phony_raw_input(prompt=""):
    from msvcrt import putch, getche
    for ch in prompt:
        putch(ch)
    s = ""
    while 1:
        c = getche()
        if c in "\r\n":
            break
        elif c == '\003':
            raise KeyboardInterrupt
        elif c == '\b':
            s = s[:-1]
        else:
            s = s + c
    putch('\r')
    putch('\n')
    return s

Use phony_raw_input instead of raw_input in your example and it will work as you hoped.  It may screw up the *next* read from stdin, though!  All of the keyboard buffer, MS-DOS buffer, and stdio buffers get mixed into this, and MS doesn't define or guarantee the way all those interact across Windows flavors.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110655&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 10:24:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 02:24:28 -0700
Subject: [Python-bugs-list] [Bug #114410] 'make tests' fails with thread error on OpenBSD 2.7
Message-ID: <200009140924.CAA11055@delerium.i.sourceforge.net>

Bug #114410, was updated on 2000-Sep-14 02:24
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 'make tests' fails with thread error on OpenBSD 2.7

Details: Using the latest CVS version of Python, the output from a pass of regrtest follows. It may be an OpenBSD problem, in which case if someone can explain it to me I will sendbug it to the OpenBSD people instead.

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
test_grammar
test_opcodes
test_operations
test_builtin
test_exceptions
test_types
test_MimeWriter
test_al
test test_al skipped --  No module named al
test_array
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test_binascii
test_binhex
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cgi
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test test_fcntl skipped --  No module named FCNTL
test_file
test_fork1
test_format
test_gc
gc: collectable <list 0x36e46c>
gc: collectable <dictionary 0x3d568c>
gc: collectable <list 0x36e46c>
gc: collectable <tuple 0x36e48c>
gc: collectable <class 0x3d570c>
gc: collectable <dictionary 0x3d56cc>
gc: collectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d574c>
gc: collectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d578c>
gc: collectable <instance method 0x25e34c>
gc: collectable <B instance at 0x36e4cc>
gc: collectable <dictionary 0x3d58cc>
gc: uncollectable <dictionary 0x3d584c>
gc: uncollectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d57cc>
gc: collectable <function 0x3d590c>
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test_gl
test test_gl skipped --  No module named gl
test_grp
pid 4207: Fatal error '_libc_private_storage_lock' at line 14 in file /usr/src/lib/libc_r/thread/thread_storage.c (errno = 2)
Abort (core dumped) 
*** Error code 134

Stop in /tmp/python/dist/src (line 212 of Makefile).


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114410&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 10:34:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 02:34:04 -0700
Subject: [Python-bugs-list] [Bug #114410] 'make tests' fails with thread error on OpenBSD 2.7
Message-ID: <200009140934.CAA11409@delerium.i.sourceforge.net>

Bug #114410, was updated on 2000-Sep-14 02:24
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 'make tests' fails with thread error on OpenBSD 2.7

Details: Using the latest CVS version of Python, the output from a pass of regrtest follows. It may be an OpenBSD problem, in which case if someone can explain it to me I will sendbug it to the OpenBSD people instead.

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
test_grammar
test_opcodes
test_operations
test_builtin
test_exceptions
test_types
test_MimeWriter
test_al
test test_al skipped --  No module named al
test_array
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test_binascii
test_binhex
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cgi
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test test_fcntl skipped --  No module named FCNTL
test_file
test_fork1
test_format
test_gc
gc: collectable <list 0x36e46c>
gc: collectable <dictionary 0x3d568c>
gc: collectable <list 0x36e46c>
gc: collectable <tuple 0x36e48c>
gc: collectable <class 0x3d570c>
gc: collectable <dictionary 0x3d56cc>
gc: collectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d574c>
gc: collectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d578c>
gc: collectable <instance method 0x25e34c>
gc: collectable <B instance at 0x36e4cc>
gc: collectable <dictionary 0x3d58cc>
gc: uncollectable <dictionary 0x3d584c>
gc: uncollectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d57cc>
gc: collectable <function 0x3d590c>
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test_gl
test test_gl skipped --  No module named gl
test_grp
pid 4207: Fatal error '_libc_private_storage_lock' at line 14 in file /usr/src/lib/libc_r/thread/thread_storage.c (errno = 2)
Abort (core dumped) 
*** Error code 134

Stop in /tmp/python/dist/src (line 212 of Makefile).


Follow-Ups:

Date: 2000-Sep-14 02:34
By: jribbens

Comment:
Oh, if you do './configure --without-threads' then the problem is avoided, of course. 'make tests' then gives:

74 tests OK.
26 tests skipped: test_al test_audioop test_cd test_cl test_crypt test_dbm test_dl test_fcntl test_fork1 test_gdbm test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev test_minidom test_nis test_pty test_pyexpat test_rgbimg test_sunaudiodev test_thread test_timing test_winreg test_winsound test_zlib

But presumably, since Python 2 has threads enabled by default, something else needs to be done ;-)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114410&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 13:10:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 05:10:18 -0700
Subject: [Python-bugs-list] [Bug #113693] freeze modulefinder broken
Message-ID: <200009141210.FAA17059@delerium.i.sourceforge.net>

Bug #113693, was updated on 2000-Sep-06 05:09
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: freeze modulefinder broken

Details: The following one-liner script can not be frozen:

import string

The traceback is included below. Line number are from revision 1.13 of modulefinder.py.

The problem appears to be related to recent changes to the import bytecodes

Traceback (most recent call last):
  File "d:\python\tools\freeze\freeze.py", line 457, in ?
    main()
  File "d:\python\tools\freeze\freeze.py", line 321, in main
    mf.import_hook(mod)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 281, in scan_code
    self.import_hook(name, m)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 281, in scan_code
    self.import_hook(name, m)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 303, in scan_code
    self.scan_code(c, m)
  File "d:\python\tools\freeze\modulefinder.py", line 281, in scan_code
    self.import_hook(name, m)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 289, in scan_code
    assert lastname is not None
AssertionError

Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 05:10
By: jackjansen

Comment:
The problem is that the code expects IMPORT_NAME immedeately followed by
a sequence of IMPORT_FROMs. That has changed now that IMPORT_FROM
puts the result on the stack.

A fix that appears to work for me is to set lastname to None only on POP_TOP
instructions. But I'll leave doing the actual fix to someone more knowledgeable than
me on the code that from x import y can generate.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113693&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 14:32:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 06:32:58 -0700
Subject: [Python-bugs-list] [Bug #114424] Tkinter/Canvas drawing causes interpreter to crash.
Message-ID: <200009141332.GAA01447@bush.i.sourceforge.net>

Bug #114424, was updated on 2000-Sep-14 06:32
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Tkinter/Canvas drawing causes interpreter to crash.

Details: 
 14 September 2000

 Please find my original query below with regard to Tkinter and Python2.0beta1.
 Also find the Python help desk response.

 I had not mentioned in my original query that I am running on a 
 Sun Ultra 10 with the Solaris 5.5.1 operating system. 

 Best,
 Michele

 ---------------------------------------------------------------------------
 ---------------------------------------------------------------------------


 13 September 2000

 HI Python Folks,

 I am trying to evaluate the new "flatten" functionality written for 
 Tkinter to determine if it generates a scientific plot with many data
 points in a reasonable time. I am using the Python2.0beta1.  I should
 admit to being a bit of a newbie with Python.

 For this test, I am using some very simple code that is from the "Python 
 and Tkinter Programming" book by John Grayson.  I will append the simple 
 program to the bottom of this note.  I will mention I did modify the 
 code in the following manner:
  
   1) scaled.append(x,y) to scaled.append((x,y)).
   2) commented out some stuff I did not care about
   3) added code to be able to generate as many data points as I want for
      testing

 If I run the very code attached to this note, I get:

enkidu> /usr/local/bin/python2.0 simpleplot2.py
Traceback (most recent call last):
  File "simpleplot2.py", line 39, in ?
    canvas.create_line(scaled, fill='royalblue')
  File "/usr/local/Python-2.0b1/lib/python2.0/lib-tk/Tkinter.py", line 1955, in create_line
    return self._create('line', args, kw)
  File "/usr/local/Python-2.0b1/lib/python2.0/lib-tk/Tkinter.py", line 1942, in _create
    (self._w, 'create', itemType)
TypeError: can only concatenate tuple (not "dictionary") to tuple
Bus error (core dumped)

 I changed the scaled.append((x,y)) to two lines where I append x and y
 separately; this got rid of the TypeError, but I still got the core dump.
 I have done many experiments where I can sometimes get the code to work in
 interactive mode, but if I decide to draw the line in color, I get a bus 
 error.  I can sometimes draw lines with only a few data points, but I
 bomb on lines with many points.

 I tell you all of this to find out if Tkinter has been tested for drawing
 lines and such on a canvas under Python2.0?  I am suspicious of either 
 memory problems or newbie problems.  I have tried some demos of Tkinter, as 
 well as some GUIs I have made using Tkinter which employ lots of widgets 
 (i.e., scrollbars, text, label, entry) and these seem to work just fine.
 I am not very experienced with drawing stuff on the canvas.

 I do not expect you to debug this code for me, but rather to tell me how
 well Tkinter has been tested under Python2.0.  I know you probably have 
 lots o'stuff to do.

 Best,
 Michele

 -------------------------------------------------------------------------
 Michele D. De La Pena                        email: delapena@stsci.edu
 Senior Scientific Programmer                 phone: 410-338-4713
 Space Telescope Science Institute            fax:   410-338-4767
 3700 San Martin Drive
 Baltimore, MD  21218

 "The nice thing about standards is there are so many to choose from."
 -------------------------------------------------------------------------


 ****************************************************************************

from Tkinter import *

root = Tk()
root.title('Simple Plot - Version 2')
canvas = Canvas(root, width=450, height=300, bg = 'white')
canvas.pack()
Button(root, text='Quit', command=root.quit).pack()

canvas.create_line(100,250,400,250, width=2)
canvas.create_line(100,250,100,50,  width=2)

for i in range(11):
    x = 100 + (i * 30)
    canvas.create_line(x,250,x,245, width=2)
    canvas.create_text(x,254, text='%d'% (10*i), anchor=N)

for i in range(6):
    y = 250 - (i * 40)
    canvas.create_line(100,y,105,y, width=2)
    canvas.create_text(96,y, text='%5.1f'% (50.*i), anchor=E)

scaled = []

# MDD Added this code to generate potentially lots of data points
for i in range(10):
    x, y = i, i
    x = x + 100
    y = 50 + y
    scaled.append((x,y))

"""  I am not interested in this.
scaled = []
for x,y in [(12, 56), (20, 94), (33, 98), (45, 120), (61, 180),
            (75, 160), (98, 223)]:
    scaled.append((100 + 3*x, 250 - (4*y)/5))
"""

canvas.create_line(scaled, fill='royalblue')

"""  I am not interested in this.
for x,y in scaled:
    canvas.create_oval(x-6,y-6,x+6,y+6, width=1,
                       outline='black', fill='SkyBlue2')
"""

root.mainloop()

 ---------------------------------------------------------------------------
 ---------------------------------------------------------------------------

From help@python.org  Thu Sep 14 09:38:40 2000
From: help@python.org (Martin von Loewis)
Date: Thu, 14 Sep 2000 10:38:40 +0200 (MET DST)
Subject: [Python-Help] forwarded message from Michele De La Pena
In-Reply-To: <200009132153.RAA20628@enkidu.stsci.edu> (delapena@stsci.edu)
References: <200009132153.RAA20628@enkidu.stsci.edu>
Message-ID: <200009140838.KAA28807@pandora.informatik.hu-berlin.de>

> I will check the items you suggest below, but I you have my help 
> message confused with someone else's message. 

My fault, I indeed confused your message with somebody elses. Looking
at your original message, I can certainly reproduce the problem you
are seeing. Tkinter has not been tested much for 2.0, except that IDLE
is based on it - but that does not involve Canvases.

It is not really your duty to find the cause of the problem, as it is
clearly a Python bug. Since we are in beta testing, it would be quite
important to fix it before 2.0 is released. So, if you are willing to
investigate and propose a patch, that would be much
appreciated. Otherwise, submitting a bug report at
http://sourceforge.net/projects/python would be important so that the
bug gets known to all contributors.

Regards,
Martin

P.S. I'm especially troubled by the fact that the interpreter crashes,
it should not crash under any circumstances, normally. A quick check
with gdb shows that it crashes in Solaris' libc.so, specifically in
the memory management. It appears that the heap got corrupted.

enkidu> 
2000 10:38:40 +0200 (MET DST)
Received: (from loewis@localhost)
        by pandora.informatik.hu-berlin.de (8.9.1/8.9.1/SOLARIS-INF-2.0c) id KAA



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114424&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 14:48:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 06:48:56 -0700
Subject: [Python-bugs-list] [Bug #114427] bug with urlencode method from urllib
Message-ID: <200009141348.GAA20765@delerium.i.sourceforge.net>

Bug #114427, was updated on 2000-Sep-14 06:48
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: bug with urlencode method from urllib

Details: result of encode ',' is ',' but not '%2C'

Example
>>> import urllib
>>> dico={'toto':','}
>>> a = urllib.urlencode(dico)
>>> a
'toto=,'

or I think that it must return 'toto=%2C'

Example :
>>> import urllib
>>> b = urllib.unquote_plus('%2C')
>>> print b
,

r_gesnot@hotmail.com



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114427&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 16:35:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 08:35:32 -0700
Subject: [Python-bugs-list] [Bug #114333] minidom fails to parse PI
Message-ID: <200009141535.IAA06391@bush.i.sourceforge.net>

Bug #114333, was updated on 2000-Sep-13 04:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: minidom fails to parse PI

Details: # Using Python2.0b1, minidom and expat:

s="""<?xml version='1.0'?><?pi-foobar?><test></test>"""
import xml.dom.minidom
p=xml.dom.minidom.parseString(s)

stack_trace="""
Traceback (most recent call last):
  File "test.py", line 6, in ?
    p=xml.dom.minidom.parseString(s)
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/minidom.py", line 45
2, in parseString
    return _doparse( pulldom.parseString, args, kwargs )
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/minidom.py", line 44
3, in _doparse
    events.expandNode( rootNode )
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/pulldom.py", line 14
2, in expandNode
    cur_node.parentNode.appendChild( cur_node )
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/minidom.py", line 40
0, in appendChild
    raise TypeError, "Two document elements disallowed"
TypeError: Two document elements disallowed
"""


Follow-Ups:

Date: 2000-Sep-13 04:37
By: jrvosse

Comment:
See also the python xml-sig mail list:

http://www.python.org/pipermail/xml-sig/2000-September/004817.html
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114333&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 16:44:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 08:44:41 -0700
Subject: [Python-bugs-list] [Bug #114439] define_macros ignored when building Extension
Message-ID: <200009141544.IAA06802@bush.i.sourceforge.net>

Bug #114439, was updated on 2000-Sep-14 08:44
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: define_macros ignored when building Extension

Details: I am working on a setup script for Tkinter, which requires a
-DWITH_APPINIT flag at compile time.  The docs suggest that I should
add the following definition to my Extension constructor call:
    define_macros=[('WITH_APPINIT', None),],

I did this, but it had no effect.  It looks like there is no where
that the define_macros attribute of the Extension object is actually
used.  

I assumed this is a bug and tried to figure out where the macros
definitions ought to be processed.  I'm not familiar with the code, so
I may have put it in the wrong place.  A patch is included below,
which allows _tkinter to build.

Jeremy

*** build_ext.py	Tue Sep 12 20:58:48 2000
--- /home/jeremy/src/python/dist/src/Lib/distutils/command/build_ext.py	Thu Sep  7 11:09:18 2000
***************
*** 401,407 ****
              # any sensible compiler will give precedence to later
              # command line args.  Hence we combine them in order:
              extra_args = ext.extra_compile_args or []
-             macros = ext.define_macros or []
  
              # XXX and if we support CFLAGS, why not CC (compiler
              # executable), CPPFLAGS (pre-processor options), and LDFLAGS
--- 401,406 ----
***************
*** 410,419 ****
  
              if os.environ.has_key('CFLAGS'):
                  extra_args.extend(string.split(os.environ['CFLAGS']))
! 
              objects = self.compiler.compile (sources,
                                               output_dir=self.build_temp,
!                                              macros=macros,
                                               include_dirs=ext.include_dirs,
                                               debug=self.debug,
                                               extra_postargs=extra_args)
--- 409,418 ----
  
              if os.environ.has_key('CFLAGS'):
                  extra_args.extend(string.split(os.environ['CFLAGS']))
!                 
              objects = self.compiler.compile (sources,
                                               output_dir=self.build_temp,
!                                              #macros=macros,
                                               include_dirs=ext.include_dirs,
                                               debug=self.debug,
                                               extra_postargs=extra_args)


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114439&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 17:44:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 09:44:15 -0700
Subject: [Python-bugs-list] [Bug #114427] bug with urlencode method from urllib
Message-ID: <200009141644.JAA09132@bush.i.sourceforge.net>

Bug #114427, was updated on 2000-Sep-14 06:48
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: bug with urlencode method from urllib

Details: result of encode ',' is ',' but not '%2C'

Example
>>> import urllib
>>> dico={'toto':','}
>>> a = urllib.urlencode(dico)
>>> a
'toto=,'

or I think that it must return 'toto=%2C'

Example :
>>> import urllib
>>> b = urllib.unquote_plus('%2C')
>>> print b
,

r_gesnot@hotmail.com



Follow-Ups:

Date: 2000-Sep-14 09:44
By: jhylton

Comment:
Comma is listed in the list of always safe characters, but it shouldn't be.  It is a reserved character in the query part of a URL.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114427&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 17:54:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 09:54:11 -0700
Subject: [Python-bugs-list] [Bug #114424] Tkinter/Canvas drawing causes interpreter to crash.
Message-ID: <200009141654.JAA28043@delerium.i.sourceforge.net>

Bug #114424, was updated on 2000-Sep-14 06:32
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 9
Summary: Tkinter/Canvas drawing causes interpreter to crash.

Details: 
 14 September 2000

 Please find my original query below with regard to Tkinter and Python2.0beta1.
 Also find the Python help desk response.

 I had not mentioned in my original query that I am running on a 
 Sun Ultra 10 with the Solaris 5.5.1 operating system. 

 Best,
 Michele

 ---------------------------------------------------------------------------
 ---------------------------------------------------------------------------


 13 September 2000

 HI Python Folks,

 I am trying to evaluate the new "flatten" functionality written for 
 Tkinter to determine if it generates a scientific plot with many data
 points in a reasonable time. I am using the Python2.0beta1.  I should
 admit to being a bit of a newbie with Python.

 For this test, I am using some very simple code that is from the "Python 
 and Tkinter Programming" book by John Grayson.  I will append the simple 
 program to the bottom of this note.  I will mention I did modify the 
 code in the following manner:
  
   1) scaled.append(x,y) to scaled.append((x,y)).
   2) commented out some stuff I did not care about
   3) added code to be able to generate as many data points as I want for
      testing

 If I run the very code attached to this note, I get:

enkidu> /usr/local/bin/python2.0 simpleplot2.py
Traceback (most recent call last):
  File "simpleplot2.py", line 39, in ?
    canvas.create_line(scaled, fill='royalblue')
  File "/usr/local/Python-2.0b1/lib/python2.0/lib-tk/Tkinter.py", line 1955, in create_line
    return self._create('line', args, kw)
  File "/usr/local/Python-2.0b1/lib/python2.0/lib-tk/Tkinter.py", line 1942, in _create
    (self._w, 'create', itemType)
TypeError: can only concatenate tuple (not "dictionary") to tuple
Bus error (core dumped)

 I changed the scaled.append((x,y)) to two lines where I append x and y
 separately; this got rid of the TypeError, but I still got the core dump.
 I have done many experiments where I can sometimes get the code to work in
 interactive mode, but if I decide to draw the line in color, I get a bus 
 error.  I can sometimes draw lines with only a few data points, but I
 bomb on lines with many points.

 I tell you all of this to find out if Tkinter has been tested for drawing
 lines and such on a canvas under Python2.0?  I am suspicious of either 
 memory problems or newbie problems.  I have tried some demos of Tkinter, as 
 well as some GUIs I have made using Tkinter which employ lots of widgets 
 (i.e., scrollbars, text, label, entry) and these seem to work just fine.
 I am not very experienced with drawing stuff on the canvas.

 I do not expect you to debug this code for me, but rather to tell me how
 well Tkinter has been tested under Python2.0.  I know you probably have 
 lots o'stuff to do.

 Best,
 Michele

 -------------------------------------------------------------------------
 Michele D. De La Pena                        email: delapena@stsci.edu
 Senior Scientific Programmer                 phone: 410-338-4713
 Space Telescope Science Institute            fax:   410-338-4767
 3700 San Martin Drive
 Baltimore, MD  21218

 "The nice thing about standards is there are so many to choose from."
 -------------------------------------------------------------------------


 ****************************************************************************

from Tkinter import *

root = Tk()
root.title('Simple Plot - Version 2')
canvas = Canvas(root, width=450, height=300, bg = 'white')
canvas.pack()
Button(root, text='Quit', command=root.quit).pack()

canvas.create_line(100,250,400,250, width=2)
canvas.create_line(100,250,100,50,  width=2)

for i in range(11):
    x = 100 + (i * 30)
    canvas.create_line(x,250,x,245, width=2)
    canvas.create_text(x,254, text='%d'% (10*i), anchor=N)

for i in range(6):
    y = 250 - (i * 40)
    canvas.create_line(100,y,105,y, width=2)
    canvas.create_text(96,y, text='%5.1f'% (50.*i), anchor=E)

scaled = []

# MDD Added this code to generate potentially lots of data points
for i in range(10):
    x, y = i, i
    x = x + 100
    y = 50 + y
    scaled.append((x,y))

"""  I am not interested in this.
scaled = []
for x,y in [(12, 56), (20, 94), (33, 98), (45, 120), (61, 180),
            (75, 160), (98, 223)]:
    scaled.append((100 + 3*x, 250 - (4*y)/5))
"""

canvas.create_line(scaled, fill='royalblue')

"""  I am not interested in this.
for x,y in scaled:
    canvas.create_oval(x-6,y-6,x+6,y+6, width=1,
                       outline='black', fill='SkyBlue2')
"""

root.mainloop()

 ---------------------------------------------------------------------------
 ---------------------------------------------------------------------------

From help@python.org  Thu Sep 14 09:38:40 2000
From: help@python.org (Martin von Loewis)
Date: Thu, 14 Sep 2000 10:38:40 +0200 (MET DST)
Subject: [Python-Help] forwarded message from Michele De La Pena
In-Reply-To: <200009132153.RAA20628@enkidu.stsci.edu> (delapena@stsci.edu)
References: <200009132153.RAA20628@enkidu.stsci.edu>
Message-ID: <200009140838.KAA28807@pandora.informatik.hu-berlin.de>

> I will check the items you suggest below, but I you have my help 
> message confused with someone else's message. 

My fault, I indeed confused your message with somebody elses. Looking
at your original message, I can certainly reproduce the problem you
are seeing. Tkinter has not been tested much for 2.0, except that IDLE
is based on it - but that does not involve Canvases.

It is not really your duty to find the cause of the problem, as it is
clearly a Python bug. Since we are in beta testing, it would be quite
important to fix it before 2.0 is released. So, if you are willing to
investigate and propose a patch, that would be much
appreciated. Otherwise, submitting a bug report at
http://sourceforge.net/projects/python would be important so that the
bug gets known to all contributors.

Regards,
Martin

P.S. I'm especially troubled by the fact that the interpreter crashes,
it should not crash under any circumstances, normally. A quick check
with gdb shows that it crashes in Solaris' libc.so, specifically in
the memory management. It appears that the heap got corrupted.

enkidu> 
2000 10:38:40 +0200 (MET DST)
Received: (from loewis@localhost)
        by pandora.informatik.hu-berlin.de (8.9.1/8.9.1/SOLARIS-INF-2.0c) id KAA



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114424&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 17:55:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 09:55:50 -0700
Subject: [Python-bugs-list] [Bug #114318] References to Python 1.5
Message-ID: <200009141655.JAA28101@delerium.i.sourceforge.net>

Bug #114318, was updated on 2000-Sep-13 00:39
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: Not a Bug
Priority: 5
Summary: References to Python 1.5

Details: In the documentation, there are references to Python's library path that often use "/usr/local/lib/python1.5" instead of "/usr/local/lib/python2.0".  A quick "find" and "grep" shows the following pages:

    ./api/embedding.html
    ./api/includes.html
    ./dist/node13.html
    ./lib/module-pdb.html
    ./lib/module-pprint.html
    ./lib/module-site.html
    ./lib/profile-instant.html
    ./lib/typesmodules.html

The only one that might be a problem is "./lib/module-site.html", since it mentions Python 2.0b1.1 explicitly and states that its library is installed in "python1.5".

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114318&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 17:55:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 09:55:04 -0700
Subject: [Python-bugs-list] [Bug #114359] snpplib
Message-ID: <200009141655.JAA28083@delerium.i.sourceforge.net>

Bug #114359, was updated on 2000-Sep-13 10:43
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Remind
Bug Group: Feature Request
Priority: 5
Summary: snpplib

Details: I just implemented RFC 1861 -- SNPP for a company, and they are letting me release it Open Source. snpplib.py is based on smtplib.py (very similar protocols) and is in use in a fairly hefty production system at the moment. I know that the Perl folk have snpp support in their net library, so I wanted to offer up mine for the Python distribution. Sorry if this isn't the right forum for that. 
I've opened a SourceForce project for it called PySNPP, because I have a higher level implementation class as well, but I don't think it's quite as well suited for being in the distribution. 

The files should be up here on SourceForge by tomorrow. You are more than welcome to snag them if you like. 


Follow-Ups:

Date: 2000-Sep-14 09:55
By: jhylton

Comment:
We are not adding new libraries to 2.0 at this time.  Will reconsider for 2.1.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114359&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 17:56:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 09:56:59 -0700
Subject: [Python-bugs-list] [Bug #114336] Python-2.0b1 build fails on OpenBSD 2.7
Message-ID: <200009141656.JAA28127@delerium.i.sourceforge.net>

Bug #114336, was updated on 2000-Sep-13 05:27
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python-2.0b1 build fails on OpenBSD 2.7

Details: I did './configure && make', the link failed due to it attempting to link the nonexistant library 'db'. I edited Modules/Setup.config.in and removed ' -ldb' and it compiled ok.


Follow-Ups:

Date: 2000-Sep-14 01:51
By: jribbens

Comment:
Post-2.0b1 CVS version compiles OK.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114336&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 17:59:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 09:59:42 -0700
Subject: [Python-bugs-list] [Bug #114427] bug with urlencode method from urllib
Message-ID: <200009141659.JAA28281@delerium.i.sourceforge.net>

Bug #114427, was updated on 2000-Sep-14 06:48
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: bug with urlencode method from urllib

Details: result of encode ',' is ',' but not '%2C'

Example
>>> import urllib
>>> dico={'toto':','}
>>> a = urllib.urlencode(dico)
>>> a
'toto=,'

or I think that it must return 'toto=%2C'

Example :
>>> import urllib
>>> b = urllib.unquote_plus('%2C')
>>> print b
,

r_gesnot@hotmail.com



Follow-Ups:

Date: 2000-Sep-14 09:44
By: jhylton

Comment:
Comma is listed in the list of always safe characters, but it shouldn't be.  It is a reserved character in the query part of a URL.

-------------------------------------------------------

Date: 2000-Sep-14 09:59
By: jhylton

Comment:
Fixed in revision 1.105 of urllib

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114427&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 18:07:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 10:07:18 -0700
Subject: [Python-bugs-list] [Bug #114334] glob does not handle set coplementation ([^ ... ]) properly
Message-ID: <200009141707.KAA10016@bush.i.sourceforge.net>

Bug #114334, was updated on 2000-Sep-13 04:46
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: glob does not handle set coplementation ([^ ... ]) properly

Details: The glob function in the glob module does not handle the set complementation correctly.

Example:

  glob('*[^C].cc')

should return all .cc file that do NOT have a 'C' before the dot. Instead it returns all files that DO
have a C before the dot.

Python:   v 1.5.2
Platform: HP-UX


Follow-Ups:

Date: 2000-Sep-14 10:07
By: fdrake

Comment:
This is not a bug.  Bash accepts either "!" or "^" as the set-complement character, but ash only accepts "!".   sh on FreeBSD also only accepts "!".  I think we can safely say that the acceptance of "^" in bash is non-standard behavior, so I'm declaring that this isn't a bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114334&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 18:10:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 10:10:02 -0700
Subject: [Python-bugs-list] [Bug #113779] test_gc coredump on Alpha
Message-ID: <200009141710.KAA10164@bush.i.sourceforge.net>

Bug #113779, was updated on 2000-Sep-06 21:44
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_gc coredump on Alpha

Details: Configured --with-cycle-gc --with-sigfpe

gc: collectable <list 0x12043d158>
gc: collectable <dictionary 0x12043d1d8>
gc: collectable <list 0x12043d158>
gc: collectable <tuple 0x12043d198>
gc: collectable <class 0x12043d218>
gc: collectable <dictionary 0x12043d278>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d2c8>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d328>
gc: collectable <instance method 0x12043d378>
gc: collectable <B instance at 0x12043d6b8>
gc: collectable <dictionary 0x12043d6f8>
gc: uncollectable <dictionary 0x12043d5f8>
gc: uncollectable <A instance at 0x12043d158>
Segmentation fault (core dumped)

gdb reports:

Core was generated by `./python -tt Lib/test/regrtest.py -l -v test_gc'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2.1...done.
Reading symbols from /lib/libutil.so.1.1...done.
Reading symbols from /lib/libm.so.6.1...done.
Reading symbols from /lib/libc.so.6.1...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
168             if (!PyList_Check(op)) {
(gdb) where
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
#1  0x120085fac in handle_finalizers (finalizers=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:312
#2  0x1200862d8 in collect (young=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:438
#3  0x120086704 in gc_collect (self=0x100000000, args=0x12043d158)
    at ./gcmodule.c:588
#4  0x120018ef0 in call_builtin (func=0x1, arg=0x12039e258, kw=0x0)
    at ceval.c:2628
#5  0x120018d30 in PyEval_CallObjectWithKeywords (func=0x1204377c0, 
    arg=0x12039e258, kw=0x0) at ceval.c:2596
#6  0x12001713c in eval_code2 (co=0x12043b890, globals=0x12043d158, 
    locals=0x120370488, args=0xffffffffffffffff, argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1929
#7  0x120016cc4 in eval_code2 (co=0x12043c400, globals=0x12043d158, 
    locals=0x120370488, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
...

(gdb) print op
$1 = (PyObject *) 0x100000000
(gdb) print newitem
$2 = (PyObject *) 0x12043d158



Follow-Ups:

Date: 2000-Sep-06 21:49
By: none

Comment:
Note that without -l to regrtest it does NOT dump core,
and completes correctly.

-------------------------------------------------------

Date: 2000-Sep-07 08:23
By: bwarsaw

Comment:
It could just be a bug in the debug printing of collected objects.  The -l switch for the regrtest simply adds a call to gc.set_debug(gc.DEBUG_LEAK) before the rest of the tests get going.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 01:02
By: none

Comment:
By the way, the original post was made by tomh@po.crl.go.jp,
who can test a fix.  However, he's out of town until 9/14.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113779&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 18:15:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 10:15:52 -0700
Subject: [Python-bugs-list] [Bug #114424] Tkinter/Canvas drawing causes interpreter to crash.
Message-ID: <200009141715.KAA28952@delerium.i.sourceforge.net>

Bug #114424, was updated on 2000-Sep-14 06:32
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 9
Summary: Tkinter/Canvas drawing causes interpreter to crash.

Details: 
 14 September 2000

 Please find my original query below with regard to Tkinter and Python2.0beta1.
 Also find the Python help desk response.

 I had not mentioned in my original query that I am running on a 
 Sun Ultra 10 with the Solaris 5.5.1 operating system. 

 Best,
 Michele

 ---------------------------------------------------------------------------
 ---------------------------------------------------------------------------


 13 September 2000

 HI Python Folks,

 I am trying to evaluate the new "flatten" functionality written for 
 Tkinter to determine if it generates a scientific plot with many data
 points in a reasonable time. I am using the Python2.0beta1.  I should
 admit to being a bit of a newbie with Python.

 For this test, I am using some very simple code that is from the "Python 
 and Tkinter Programming" book by John Grayson.  I will append the simple 
 program to the bottom of this note.  I will mention I did modify the 
 code in the following manner:
  
   1) scaled.append(x,y) to scaled.append((x,y)).
   2) commented out some stuff I did not care about
   3) added code to be able to generate as many data points as I want for
      testing

 If I run the very code attached to this note, I get:

enkidu> /usr/local/bin/python2.0 simpleplot2.py
Traceback (most recent call last):
  File "simpleplot2.py", line 39, in ?
    canvas.create_line(scaled, fill='royalblue')
  File "/usr/local/Python-2.0b1/lib/python2.0/lib-tk/Tkinter.py", line 1955, in create_line
    return self._create('line', args, kw)
  File "/usr/local/Python-2.0b1/lib/python2.0/lib-tk/Tkinter.py", line 1942, in _create
    (self._w, 'create', itemType)
TypeError: can only concatenate tuple (not "dictionary") to tuple
Bus error (core dumped)

 I changed the scaled.append((x,y)) to two lines where I append x and y
 separately; this got rid of the TypeError, but I still got the core dump.
 I have done many experiments where I can sometimes get the code to work in
 interactive mode, but if I decide to draw the line in color, I get a bus 
 error.  I can sometimes draw lines with only a few data points, but I
 bomb on lines with many points.

 I tell you all of this to find out if Tkinter has been tested for drawing
 lines and such on a canvas under Python2.0?  I am suspicious of either 
 memory problems or newbie problems.  I have tried some demos of Tkinter, as 
 well as some GUIs I have made using Tkinter which employ lots of widgets 
 (i.e., scrollbars, text, label, entry) and these seem to work just fine.
 I am not very experienced with drawing stuff on the canvas.

 I do not expect you to debug this code for me, but rather to tell me how
 well Tkinter has been tested under Python2.0.  I know you probably have 
 lots o'stuff to do.

 Best,
 Michele

 -------------------------------------------------------------------------
 Michele D. De La Pena                        email: delapena@stsci.edu
 Senior Scientific Programmer                 phone: 410-338-4713
 Space Telescope Science Institute            fax:   410-338-4767
 3700 San Martin Drive
 Baltimore, MD  21218

 "The nice thing about standards is there are so many to choose from."
 -------------------------------------------------------------------------


 ****************************************************************************

from Tkinter import *

root = Tk()
root.title('Simple Plot - Version 2')
canvas = Canvas(root, width=450, height=300, bg = 'white')
canvas.pack()
Button(root, text='Quit', command=root.quit).pack()

canvas.create_line(100,250,400,250, width=2)
canvas.create_line(100,250,100,50,  width=2)

for i in range(11):
    x = 100 + (i * 30)
    canvas.create_line(x,250,x,245, width=2)
    canvas.create_text(x,254, text='%d'% (10*i), anchor=N)

for i in range(6):
    y = 250 - (i * 40)
    canvas.create_line(100,y,105,y, width=2)
    canvas.create_text(96,y, text='%5.1f'% (50.*i), anchor=E)

scaled = []

# MDD Added this code to generate potentially lots of data points
for i in range(10):
    x, y = i, i
    x = x + 100
    y = 50 + y
    scaled.append((x,y))

"""  I am not interested in this.
scaled = []
for x,y in [(12, 56), (20, 94), (33, 98), (45, 120), (61, 180),
            (75, 160), (98, 223)]:
    scaled.append((100 + 3*x, 250 - (4*y)/5))
"""

canvas.create_line(scaled, fill='royalblue')

"""  I am not interested in this.
for x,y in scaled:
    canvas.create_oval(x-6,y-6,x+6,y+6, width=1,
                       outline='black', fill='SkyBlue2')
"""

root.mainloop()

 ---------------------------------------------------------------------------
 ---------------------------------------------------------------------------

From help@python.org  Thu Sep 14 09:38:40 2000
From: help@python.org (Martin von Loewis)
Date: Thu, 14 Sep 2000 10:38:40 +0200 (MET DST)
Subject: [Python-Help] forwarded message from Michele De La Pena
In-Reply-To: <200009132153.RAA20628@enkidu.stsci.edu> (delapena@stsci.edu)
References: <200009132153.RAA20628@enkidu.stsci.edu>
Message-ID: <200009140838.KAA28807@pandora.informatik.hu-berlin.de>

> I will check the items you suggest below, but I you have my help 
> message confused with someone else's message. 

My fault, I indeed confused your message with somebody elses. Looking
at your original message, I can certainly reproduce the problem you
are seeing. Tkinter has not been tested much for 2.0, except that IDLE
is based on it - but that does not involve Canvases.

It is not really your duty to find the cause of the problem, as it is
clearly a Python bug. Since we are in beta testing, it would be quite
important to fix it before 2.0 is released. So, if you are willing to
investigate and propose a patch, that would be much
appreciated. Otherwise, submitting a bug report at
http://sourceforge.net/projects/python would be important so that the
bug gets known to all contributors.

Regards,
Martin

P.S. I'm especially troubled by the fact that the interpreter crashes,
it should not crash under any circumstances, normally. A quick check
with gdb shows that it crashes in Solaris' libc.so, specifically in
the memory management. It appears that the heap got corrupted.

enkidu> 
2000 10:38:40 +0200 (MET DST)
Received: (from loewis@localhost)
        by pandora.informatik.hu-berlin.de (8.9.1/8.9.1/SOLARIS-INF-2.0c) id KAA



Follow-Ups:

Date: 2000-Sep-14 10:15
By: loewis

Comment:
This is fixed with patch 
http://sourceforge.net/patch/?func=detailpatch&patch_id=101509&group_id=5470
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114424&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 18:28:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 10:28:51 -0700
Subject: [Python-bugs-list] [Bug #114336] Python-2.0b1 build fails on OpenBSD 2.7
Message-ID: <200009141728.KAA29503@delerium.i.sourceforge.net>

Bug #114336, was updated on 2000-Sep-13 05:27
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: None
Bug Group: None
Priority: 5
Summary: Python-2.0b1 build fails on OpenBSD 2.7

Details: I did './configure && make', the link failed due to it attempting to link the nonexistant library 'db'. I edited Modules/Setup.config.in and removed ' -ldb' and it compiled ok.


Follow-Ups:

Date: 2000-Sep-14 01:51
By: jribbens

Comment:
Post-2.0b1 CVS version compiles OK.
-------------------------------------------------------

Date: 2000-Sep-14 10:28
By: montanaro

Comment:
fixed in the latest cvs version

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114336&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 18:51:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 10:51:05 -0700
Subject: [Python-bugs-list] [Bug #114293] Unexpected Evaluation of Expressions from Pickle
Message-ID: <200009141751.KAA11856@bush.i.sourceforge.net>

Bug #114293, was updated on 2000-Sep-12 15:23
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Unexpected Evaluation of Expressions from Pickle

Details: It is possible to evaluate an expression through an improperly formatted pickled string:

    >>> import pickle 
    >>> pickle.loads("S3+3\012p0\012.")
    6

The same expression in "cPickle" will raise an exception: 

    >>> import cPickle
    >>> cPickle.loads("S3+3\012p0\012.")
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ValueError: insecure string pickle

The reason this occurs is that the string is brought into existence through a call to "eval".  This is made somewhat safe by removing all the built-in functions, but it is still possible to cause problems with a pure evaluation.  I will submit a patch within a few minutes that makes sure that the first character is either a single- or double-quote.

Would it be possible for someone to slip a code object instead of an expression?  Since we don't have access to the "marshal" module from here, I don't know how it would be done, but I am very concerned about the security implications of using pickle.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114293&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 19:38:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 11:38:52 -0700
Subject: [Python-bugs-list] [Bug #113779] test_gc coredump on Alpha
Message-ID: <200009141838.LAA13889@bush.i.sourceforge.net>

Bug #113779, was updated on 2000-Sep-06 21:44
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_gc coredump on Alpha

Details: Configured --with-cycle-gc --with-sigfpe

gc: collectable <list 0x12043d158>
gc: collectable <dictionary 0x12043d1d8>
gc: collectable <list 0x12043d158>
gc: collectable <tuple 0x12043d198>
gc: collectable <class 0x12043d218>
gc: collectable <dictionary 0x12043d278>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d2c8>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d328>
gc: collectable <instance method 0x12043d378>
gc: collectable <B instance at 0x12043d6b8>
gc: collectable <dictionary 0x12043d6f8>
gc: uncollectable <dictionary 0x12043d5f8>
gc: uncollectable <A instance at 0x12043d158>
Segmentation fault (core dumped)

gdb reports:

Core was generated by `./python -tt Lib/test/regrtest.py -l -v test_gc'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2.1...done.
Reading symbols from /lib/libutil.so.1.1...done.
Reading symbols from /lib/libm.so.6.1...done.
Reading symbols from /lib/libc.so.6.1...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
168             if (!PyList_Check(op)) {
(gdb) where
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
#1  0x120085fac in handle_finalizers (finalizers=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:312
#2  0x1200862d8 in collect (young=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:438
#3  0x120086704 in gc_collect (self=0x100000000, args=0x12043d158)
    at ./gcmodule.c:588
#4  0x120018ef0 in call_builtin (func=0x1, arg=0x12039e258, kw=0x0)
    at ceval.c:2628
#5  0x120018d30 in PyEval_CallObjectWithKeywords (func=0x1204377c0, 
    arg=0x12039e258, kw=0x0) at ceval.c:2596
#6  0x12001713c in eval_code2 (co=0x12043b890, globals=0x12043d158, 
    locals=0x120370488, args=0xffffffffffffffff, argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1929
#7  0x120016cc4 in eval_code2 (co=0x12043c400, globals=0x12043d158, 
    locals=0x120370488, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
...

(gdb) print op
$1 = (PyObject *) 0x100000000
(gdb) print newitem
$2 = (PyObject *) 0x12043d158



Follow-Ups:

Date: 2000-Sep-06 21:49
By: none

Comment:
Note that without -l to regrtest it does NOT dump core,
and completes correctly.

-------------------------------------------------------

Date: 2000-Sep-07 08:23
By: bwarsaw

Comment:
It could just be a bug in the debug printing of collected objects.  The -l switch for the regrtest simply adds a call to gc.set_debug(gc.DEBUG_LEAK) before the rest of the tests get going.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 01:02
By: none

Comment:
By the way, the original post was made by tomh@po.crl.go.jp,
who can test a fix.  However, he's out of town until 9/14.

-------------------------------------------------------

Date: 2000-Sep-14 11:38
By: nascheme

Comment:
The output from "print *op" and "print *newitem" would have been useful.  The 0x100000000 pointer looks funny.  It is a really pointer or NULL or what?  If its not a real pointer then somehow the uncollectable garbage list was corrupted or was not initialized. 
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113779&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 21:18:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 13:18:22 -0700
Subject: [Python-bugs-list] [Bug #113800] optional{} produces incorrect HTML
Message-ID: <200009142018.NAA17835@bush.i.sourceforge.net>

Bug #113800, was updated on 2000-Sep-07 08:18
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 3
Summary: optional{} produces incorrect HTML

Details: This showed up in the Python 2.0 document: LaTeX2HTML
produces bad HTML with improperly nested tags, including a trailing <var> tag that leaves the rest of the document in italic on some browsers.  Sample document:

\documentclass{howto}
 
\title{What's New in Python 2.0}
\release{0.05}
\author{A.M. Kuchling and Moshe Zadka}
\authoraddress{\email{amk1@bigfoot.com}, \email{moshez@math.huji.ac.il} }
 
\begin{document}
 
\code{unicode(\var{string} \optional{, \var{encoding}}
\optional{, \var{errors}} ) } creates a Unicode string from an 8-bit
 
\end{document}  

The incorrect HTML output is:

<code>unicode(<var>string</var> </var><big>[</big><var>, <var>encoding</var></var><big>]</big><big>[</big><var>, <var>errors</var></var><big>]</big><var> ) </code> creates ...

Follow-Ups:

Date: 2000-Sep-08 01:49
By: aleax

Comment:
bug 113700 is a consequence of this, I think.

-------------------------------------------------------

Date: 2000-Sep-08 13:25
By: fdrake

Comment:
This is a limitation of the current support for the augmented markup we use with LaTeX2HTML.  The \optional mark is used in two contexts:

- inside parameter lists for function, method, and constructor signatures, where it does the right thing, and
- just anywhere something should be marked as optional.

The second case is where the problem is.  As far as I can tell, there's no way to determine the context to allow \optional to be implemented correctly in both cases.  If I find a way around this, I will fix it, but the priority is low since we intend to move to an XML-based approach at some point.

The difference in context is that, in a signature in the *desc environments, the VAR element is opened and closed by the handler for the *desc environment, but this is not the case elsewhere.  The VAR is closed and then re-opened around the brackets used to enclose the content of the \optional mark so that the brackets are not shown in an italic font.

Bug 113700 is indeed a direct consequence of this.
-------------------------------------------------------

Date: 2000-Sep-14 13:18
By: fdrake

Comment:
Fixed in Doc/perl/python.perl revision 1.84.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113800&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 21:19:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 13:19:24 -0700
Subject: [Python-bugs-list] [Bug #113812] Serious garbage collection problems with 2.0b1
Message-ID: <200009142019.NAA03334@delerium.i.sourceforge.net>

Bug #113812, was updated on 2000-Sep-07 10:10
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 8
Summary: Serious garbage collection problems with 2.0b1

Details: Since I've installed version 2.0b1, I ran into a few (serious) problems
with a non-trivial application (+80,000 lines of Python). It seems that
the are all related to the new garbage collection:

 - Suddenly, assertions fail because lists have become empty 
   while they shouldn't have. I looks like their elements have been
   garbage collected while they were still reachable.

 - Under other circumstances, I get coredumps which always 
   seem to happen in function "move_root_reachable" of gcmodule.c:
   the "traverse" function pointer seems to contain a bogus address.

 - When I run a Purified version of the interpreter, I can't reproduce
   either problem, but instead, the garbage collector seems to get
   stuck in an endless loop each time. This always happens in the
   same function "move_root_reachable". Purify doesn't produce any 
   relevant warning.

The code runs just fine with version 1.6 of the interpreter, or when I
disable the garbage collector.

Probably relevant is the fact that the objects (10,000's) in my application
are very heavily cross-linked (nearly all links are bi-directional), which 
probably puts a lot of stress on the garbage collector.

My platform: HP-UX 10.20 / c89 compiler


Follow-Ups:

Date: 2000-Sep-07 10:14
By: edg

Comment:
Just one more thing: when I turn on the gc debugging,
the interpreter also seems to get stuck in an endless loop.
-------------------------------------------------------

Date: 2000-Sep-07 14:41
By: jhylton

Comment:
If you set the GC threshold to 0, 
import gc
gc.set_threshold(0)

Do you get the same problem?  Not that I doubt there is some sort of gc problem, but I wonder if there is something going wrong in the accounting or in the collection.

How hard would it be for someone to try to reproduce this bug?  Obviously, it would be helpful to get a smaller test case that has the same behavior as your large program and also tickles the bug.

Do you have any C extension modules in your application or is it pure Python?
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 01:33
By: edg

Comment:
The code is 100% pure Python. 
When I set the threshold to 0, the problem doesn't occur.

The problem is probably very hard to reproduce by anyone else.
The slightest change in the input data for my application
can make the problem go away. Even running an optimized instead
of a debug version of the interpreter can make a difference.

I'm certainly going to try to strip it down, but that won't be 
easy (the same application, using other input data, running 
6 times as long, runs just fine).
-------------------------------------------------------

Date: 2000-Sep-11 07:48
By: edg

Comment:
After 2 full days of debugging, I think that I finally found the 
cause for the gc problems.

To keep a (very) long story short, what I found out was the following:

 - Crashes were due to objects that were destructed twice.
 
 - Endless loops were due to messed-up gc generation lists. The lists should
   always remain perfectly circular, but sometimes they ended up like this:

   list <-> ... <-> X <-> ... <-> ... -> X   

   No wonder that the gc code could easily get stuck; even turning on
   gc debugging caused the counting code to run in circles forever.
   
   The multiple-destruction problem is almost certainly caused by lists being
   messed up.
   
By turning on the debugging code in gc_list_remove and reducing the gc
threshold to a very small value, I could trigger the crash more
reliably, which allowed me to strip down my 80000 line application to this:

-----------------------------------------------------------------------------
#
# Note: to trigger a crash reliably, the debugging code in gc_list_remove
#       _must_ be turned on.
#
import gc
gc.set_threshold(1)

class Node:
   
   def __del__(self):
      dir(self)
 
a = Node()
del a # -> Crash
-----------------------------------------------------------------------------

You wonder: can it be that simple ? :-)

This is what happens when the Node instance `a' is destructed:

 1) The Node instance is removed from the gc lists.
 2) An instance method is created due to the call of the __del__ method.
    THAT METHOD CREATES A NEW REFERENCE TO THE INSTANCE !
 3) The code in the __del__ method triggers the allocation of new
    objects and because the gc threshold has been set very low, it also
    triggers a gc run. 
 4) During the gc run, the instance method is encountered and its reachable
    objects are visited.
 5) Since the instance is referenced by the method, the gc code tries to move
    the instance to another list, while it was no longer present in any list
    -> BINGO

Obviously, the reason why this problem was so hard to reproduce, is the fact
that most classes don't have a __del__ method, and the problem only occurs
when a gc run happens during the execution of a __del__ method.

It think the fix is as simple as this (I'm not too confident, but it 
seems to work):
------------------------------------------------------------------------------
*** Objects/classobject.c.orig	Mon Sep 11 15:55:03 2000
--- Objects/classobject.c	Mon Sep 11 16:12:26 2000
***************
*** 490,496 ****
  #ifdef Py_TRACE_REFS
  	extern long _Py_RefTotal;
  #endif
- 	PyObject_GC_Fini(inst);
  	/* Call the __del__ method if it exists.  First temporarily
  	   revive the object and save the current exception, if any. */
  #ifdef Py_TRACE_REFS
--- 490,495 ----
***************
*** 523,529 ****
  #ifdef COUNT_ALLOCS
  		inst->ob_type->tp_free--;
  #endif
- 		PyObject_GC_Init((PyObject *)inst);
  		return; /* __del__ added a reference; don't delete now */
  	}
  #ifdef Py_TRACE_REFS
--- 522,527 ----
***************
*** 537,542 ****
--- 535,541 ----
  #endif /* Py_TRACE_REFS */
  	Py_DECREF(inst->in_class);
  	Py_XDECREF(inst->in_dict);
+ 	PyObject_GC_Fini(inst);
  	inst = (PyInstanceObject *) PyObject_AS_GC(inst);
  	PyObject_DEL(inst);
  }
------------------------------------------------------------------------------

ie, delay the removal from the gc list till everything has stabilized.

I hope this helps.


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113812&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 21:34:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 13:34:21 -0700
Subject: [Python-bugs-list] [Bug #110692] urllib.URLopener does not work with proxies (PR#67)
Message-ID: <200009142034.NAA18511@bush.i.sourceforge.net>

Bug #110692, was updated on 2000-Jul-31 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: urllib.URLopener does not work with proxies (PR#67)

Details: Jitterbug-Id: 67
Submitted-By: andrew@fc.hp.com
Date: Thu, 26 Aug 1999 16:20:02 -0400 (EDT)
Version: 1.5.1
OS: 


When using urllib.URLopener(proxy) (instead of setting _PROXY env variables and

calling urllib.openurl(),
you get the following error message:

 File "./watchdog.py", line 118, in main
    url.open(urltocheck)
  File "/usr/lib/python1.5/urllib.py", line 158, in open
    return getattr(self, name)(url)
  File "/usr/lib/python1.5/urllib.py", line 258, in open_http
    return addinfourl(fp, headers, "http:" + url)
TypeError: illegal argument type for built-in operation 

When using explicti proxies, url is a tuple instead of a string.  You can't 
concatanate a tuple to a string, so the operation fails.

 



====================================================================
Audit trail:
Mon Aug 30 12:40:45 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-05 13:27
By: loewis

Comment:
This is likely incorrect usage of the module. The proxy argument must
be a dictionary mapping strings of protocol names to  strings of URLs.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 13:34
By: fdrake

Comment:
Assigned to Jeremy since he's more familiar with this module.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110692&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 21:30:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 13:30:58 -0700
Subject: [Python-bugs-list] [Bug #114318] References to Python 1.5
Message-ID: <200009142030.NAA18348@bush.i.sourceforge.net>

Bug #114318, was updated on 2000-Sep-13 00:39
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: Not a Bug
Priority: 5
Summary: References to Python 1.5

Details: In the documentation, there are references to Python's library path that often use "/usr/local/lib/python1.5" instead of "/usr/local/lib/python2.0".  A quick "find" and "grep" shows the following pages:

    ./api/embedding.html
    ./api/includes.html
    ./dist/node13.html
    ./lib/module-pdb.html
    ./lib/module-pprint.html
    ./lib/module-site.html
    ./lib/profile-instant.html
    ./lib/typesmodules.html

The only one that might be a problem is "./lib/module-site.html", since it mentions Python 2.0b1.1 explicitly and states that its library is installed in "python1.5".

Follow-Ups:

Date: 2000-Sep-14 13:30
By: fdrake

Comment:
The markup has been extended so that we have a mark for the "short" flavor of the version number.  I've modified the documents to use it where needed and possible.

Note that material in {verbatim} environments still don't use this, as macros are not expanded in that context.  To avoid changing those with each release, I'm going to leave those as they are; I don't think that will hurt, though it does seem less than ideal.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114318&group_id=5470


From noreply@sourceforge.net  Thu Sep 14 22:33:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 14:33:38 -0700
Subject: [Python-bugs-list] [Bug #114424] Tkinter/Canvas drawing causes interpreter to crash.
Message-ID: <200009142133.OAA20679@bush.i.sourceforge.net>

Bug #114424, was updated on 2000-Sep-14 06:32
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 9
Summary: Tkinter/Canvas drawing causes interpreter to crash.

Details: 
 14 September 2000

 Please find my original query below with regard to Tkinter and Python2.0beta1.
 Also find the Python help desk response.

 I had not mentioned in my original query that I am running on a 
 Sun Ultra 10 with the Solaris 5.5.1 operating system. 

 Best,
 Michele

 ---------------------------------------------------------------------------
 ---------------------------------------------------------------------------


 13 September 2000

 HI Python Folks,

 I am trying to evaluate the new "flatten" functionality written for 
 Tkinter to determine if it generates a scientific plot with many data
 points in a reasonable time. I am using the Python2.0beta1.  I should
 admit to being a bit of a newbie with Python.

 For this test, I am using some very simple code that is from the "Python 
 and Tkinter Programming" book by John Grayson.  I will append the simple 
 program to the bottom of this note.  I will mention I did modify the 
 code in the following manner:
  
   1) scaled.append(x,y) to scaled.append((x,y)).
   2) commented out some stuff I did not care about
   3) added code to be able to generate as many data points as I want for
      testing

 If I run the very code attached to this note, I get:

enkidu> /usr/local/bin/python2.0 simpleplot2.py
Traceback (most recent call last):
  File "simpleplot2.py", line 39, in ?
    canvas.create_line(scaled, fill='royalblue')
  File "/usr/local/Python-2.0b1/lib/python2.0/lib-tk/Tkinter.py", line 1955, in create_line
    return self._create('line', args, kw)
  File "/usr/local/Python-2.0b1/lib/python2.0/lib-tk/Tkinter.py", line 1942, in _create
    (self._w, 'create', itemType)
TypeError: can only concatenate tuple (not "dictionary") to tuple
Bus error (core dumped)

 I changed the scaled.append((x,y)) to two lines where I append x and y
 separately; this got rid of the TypeError, but I still got the core dump.
 I have done many experiments where I can sometimes get the code to work in
 interactive mode, but if I decide to draw the line in color, I get a bus 
 error.  I can sometimes draw lines with only a few data points, but I
 bomb on lines with many points.

 I tell you all of this to find out if Tkinter has been tested for drawing
 lines and such on a canvas under Python2.0?  I am suspicious of either 
 memory problems or newbie problems.  I have tried some demos of Tkinter, as 
 well as some GUIs I have made using Tkinter which employ lots of widgets 
 (i.e., scrollbars, text, label, entry) and these seem to work just fine.
 I am not very experienced with drawing stuff on the canvas.

 I do not expect you to debug this code for me, but rather to tell me how
 well Tkinter has been tested under Python2.0.  I know you probably have 
 lots o'stuff to do.

 Best,
 Michele

 -------------------------------------------------------------------------
 Michele D. De La Pena                        email: delapena@stsci.edu
 Senior Scientific Programmer                 phone: 410-338-4713
 Space Telescope Science Institute            fax:   410-338-4767
 3700 San Martin Drive
 Baltimore, MD  21218

 "The nice thing about standards is there are so many to choose from."
 -------------------------------------------------------------------------


 ****************************************************************************

from Tkinter import *

root = Tk()
root.title('Simple Plot - Version 2')
canvas = Canvas(root, width=450, height=300, bg = 'white')
canvas.pack()
Button(root, text='Quit', command=root.quit).pack()

canvas.create_line(100,250,400,250, width=2)
canvas.create_line(100,250,100,50,  width=2)

for i in range(11):
    x = 100 + (i * 30)
    canvas.create_line(x,250,x,245, width=2)
    canvas.create_text(x,254, text='%d'% (10*i), anchor=N)

for i in range(6):
    y = 250 - (i * 40)
    canvas.create_line(100,y,105,y, width=2)
    canvas.create_text(96,y, text='%5.1f'% (50.*i), anchor=E)

scaled = []

# MDD Added this code to generate potentially lots of data points
for i in range(10):
    x, y = i, i
    x = x + 100
    y = 50 + y
    scaled.append((x,y))

"""  I am not interested in this.
scaled = []
for x,y in [(12, 56), (20, 94), (33, 98), (45, 120), (61, 180),
            (75, 160), (98, 223)]:
    scaled.append((100 + 3*x, 250 - (4*y)/5))
"""

canvas.create_line(scaled, fill='royalblue')

"""  I am not interested in this.
for x,y in scaled:
    canvas.create_oval(x-6,y-6,x+6,y+6, width=1,
                       outline='black', fill='SkyBlue2')
"""

root.mainloop()

 ---------------------------------------------------------------------------
 ---------------------------------------------------------------------------

From help@python.org  Thu Sep 14 09:38:40 2000
From: help@python.org (Martin von Loewis)
Date: Thu, 14 Sep 2000 10:38:40 +0200 (MET DST)
Subject: [Python-Help] forwarded message from Michele De La Pena
In-Reply-To: <200009132153.RAA20628@enkidu.stsci.edu> (delapena@stsci.edu)
References: <200009132153.RAA20628@enkidu.stsci.edu>
Message-ID: <200009140838.KAA28807@pandora.informatik.hu-berlin.de>

> I will check the items you suggest below, but I you have my help 
> message confused with someone else's message. 

My fault, I indeed confused your message with somebody elses. Looking
at your original message, I can certainly reproduce the problem you
are seeing. Tkinter has not been tested much for 2.0, except that IDLE
is based on it - but that does not involve Canvases.

It is not really your duty to find the cause of the problem, as it is
clearly a Python bug. Since we are in beta testing, it would be quite
important to fix it before 2.0 is released. So, if you are willing to
investigate and propose a patch, that would be much
appreciated. Otherwise, submitting a bug report at
http://sourceforge.net/projects/python would be important so that the
bug gets known to all contributors.

Regards,
Martin

P.S. I'm especially troubled by the fact that the interpreter crashes,
it should not crash under any circumstances, normally. A quick check
with gdb shows that it crashes in Solaris' libc.so, specifically in
the memory management. It appears that the heap got corrupted.

enkidu> 
2000 10:38:40 +0200 (MET DST)
Received: (from loewis@localhost)
        by pandora.informatik.hu-berlin.de (8.9.1/8.9.1/SOLARIS-INF-2.0c) id KAA



Follow-Ups:

Date: 2000-Sep-14 10:15
By: loewis

Comment:
This is fixed with patch 
http://sourceforge.net/patch/?func=detailpatch&patch_id=101509&group_id=5470
-------------------------------------------------------

Date: 2000-Sep-14 14:33
By: effbot

Comment:
go ahead and check it in!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114424&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 05:16:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 21:16:27 -0700
Subject: [Python-bugs-list] [Bug #110619] urllib.py fails with username/password proxies (PR#221)
Message-ID: <200009150416.VAA02762@bush.i.sourceforge.net>

Bug #110619, was updated on 2000-Jul-31 14:06
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: Later
Bug Group: Feature Request
Priority: 3
Summary: urllib.py fails with username/password proxies (PR#221)

Details: Jitterbug-Id: 221
Submitted-By: tarka@zip.com.au
Date: Tue, 29 Feb 2000 19:15:45 -0500 (EST)
Version: 1.5.2
OS: Irix


urllib.py fails to handle proxies with user and password information 
included in the proxy URL, e.g. http://ssmith:testpass@10.11.12.13:1234

The following example ...

	import os, urllib
	os.environ['http_proxy'] = "http://ssmith:testpass01@10.11.12.13:1234"
	f = urllib.urlopen('http://www.python.org')
	data = f.read()
	print data

fails with the following errors :

Traceback (innermost last):
  File "url.py", line 3, in ?
    f = urllib.urlopen('http://www.python.org')
  File "/var/share//lib/python1.5/urllib.py", line 59, in urlopen
    return _urlopener.open(url)
  File "/var/share//lib/python1.5/urllib.py", line 157, in open
    return getattr(self, name)(url)
  File "/var/share//lib/python1.5/urllib.py", line 253, in open_http
    h = httplib.HTTP(host)
  File "/var/share//lib/python1.5/httplib.py", line 51, in __init__
    if host: self.connect(host, port)
  File "/var/share//lib/python1.5/httplib.py", line 75, in connect
    raise socket.error, "nonnumeric port"
IOError: [Errno socket error] nonnumeric port






====================================================================
Audit trail:
Mon May 22 17:35:04 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-31 10:15
By: fdrake

Comment:
Will be documented as a limitation in the implementation, as suggested in bug #111725.  I'm converting this to a feature request that can be dealt with in a subsequent version of Python.
-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 03:17
By: gvanrossum

Comment:
Fred, please document this limitation, add this to the feature-requests PEP (to be created), and then close the bug.
-------------------------------------------------------

Date: 2000-Sep-14 21:16
By: fdrake

Comment:
This limitation was already documented, but I've added a note that should be easier to find for people looking for limitations.  Also fixed typo from existing note.  This is checked in as Doc/lib/liburllib.tex revision 1.29.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110619&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 05:33:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 21:33:59 -0700
Subject: [Python-bugs-list] [Bug #110618] IDLE: Modifying argv prevents source of ~/.idle.py (PR#219)
Message-ID: <200009150433.VAA03322@bush.i.sourceforge.net>

Bug #110618, was updated on 2000-Jul-31 14:06
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 3
Summary: IDLE: Modifying argv prevents source of ~/.idle.py (PR#219)

Details: Jitterbug-Id: 219
Submitted-By: aa8vb@yahoo.com
Date: Mon, 28 Feb 2000 07:49:55 -0500 (EST)
Version: 1.5.2
OS: IRIX 6.5.6f


(Two problems leading up to allowing IDLE to read color settings from
~/.idle.py.
They're separate problems so I'll put each in separate bug reports.)

As Bernhard Herzog recently pointed out, Tkinter apps try to load
.<classname>.tcl, .<classname>.py, .<appname>.tcl and .<appname>.py out of a
user's home directory, if present.  <classname> defaults to "Tk" and <appname>
defaults to the base of argv[0] (e.g. "idle").

With these reasonable defaults, one would expect they could create a ~/.idle.py
which IDLE would read for configuration info.  However, Tkinter "won't" try
to read ~/.idle.py unless -e is specified.  This is because IDLE is
hacking up sys.argv for some reason when -e isn't specified, which results in
sys.argv[0] being empty, which prevents baseName from being set, which 
in turn causes Tkinter to look for these files:

   ~/.Tk.tcl ~/.Tk.py ~/..tcl ~/..py

instead of:

   ~/.Tk.tcl ~/.Tk.py ~/.idle.tcl ~/.idle.py

Seeing this, I verified that IDLE does indeed read ~/.idle.py when invoked
as "idle.py -e".

This appears to be a bug.  If so, please update IDLE so that argv[0] is
left unadulterated at least until Tkinter is initialized, so that it can
read ~/.<basename>.py for configuration.

Also, it might be worthwhile to set the className (argument to Tk()) to
"Idle" or "IDLE" so an IDLE configuration file can be created which will 
be executed independent of what the idle script itself is named.




====================================================================
Audit trail:
Tue Mar 07 14:38:27 2000	guido	changed notes
Tue Mar 07 14:38:27 2000	guido	changed notification
Tue Mar 07 14:38:27 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 21:33
By: fdrake

Comment:
This is fixed in Tools/idle/PyShell.py revision 1.30.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110618&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 06:23:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 22:23:53 -0700
Subject: [Python-bugs-list] [Bug #110607] Telnet close (PR#181)
Message-ID: <200009150523.WAA22568@delerium.i.sourceforge.net>

Bug #110607, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Telnet close (PR#181)

Details: Jitterbug-Id: 181
Submitted-By: cha@tandberg.no
Date: Wed, 12 Jan 2000 09:49:29 -0500 (EST)
Version: 1.5.2
OS: Windows NT4.0


The telnet.close() object does not close the telnet session.
Session will only be closed after a timeout on the remote side.

 



====================================================================
Audit trail:
Wed Jan 12 18:29:38 2000	guido	changed notes
Wed Jan 12 18:29:38 2000	guido	changed notification
Wed Jan 12 18:29:38 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-23 18:50
By: montanaro

Comment:
Replied to the submitter asking for a short script that fails.  I don't run Windows so I may not be able to track
this down.

-------------------------------------------------------

Date: 2000-Sep-04 07:54
By: montanaro

Comment:
Never did get any response from the submitter.  This was
apparently originally submitted back in January.  I'm simply going to bounce this back to Tim since he at least runs Windows...

-------------------------------------------------------

Date: 2000-Sep-14 22:23
By: tim_one

Comment:
Assigned to Guido, cause it looks like telnetlib.py may be his code, he also has Windows, and-- unlike me --may actually know of a machine he can telnet *to* (I've never used this stuff, & the BeOpen machines don't telnet for me).  The .close() method certainly appears to be closing the underlying socket.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110607&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 06:27:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 22:27:12 -0700
Subject: [Python-bugs-list] [Bug #110663] getpass() echo password input (PR#359)
Message-ID: <200009150527.WAA22712@delerium.i.sourceforge.net>

Bug #110663, was updated on 2000-Jul-31 14:11
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 2
Summary: getpass() echo password input (PR#359)

Details: Jitterbug-Id: 359
Submitted-By: harishbk@inf.com
Date: Fri, 16 Jun 2000 03:46:58 -0400 (EDT)
Version: 1.5.2
OS: OSF1 version 4.0f


code:

#! /usr/local/bin/python

import getpass
pas=getpass.getpass()

when it is run
password : harish

it is echoing password input. How can we avoid echoing it.




====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "M.-A. Lemburg" <mal@lemburg.com>
Subject: Re: [Python-bugs-list] getpass() echo password input (PR#359)
Date: Fri, 16 Jun 2000 10:03:55 +0200

harishbk@inf.com wrote:
> 
> Full_Name: harish
> Version: 1.5.2
> OS: OSF1 version 4.0f
> Submission from: (NULL) (202.54.39.82)
> 
> code:
> 
> #! /usr/local/bin/python
> 
> import getpass
> pas=getpass.getpass()
> 
> when it is run
> password : harish
> 
> it is echoing password input. How can we avoid echoing it.

You will need to compile Python with termios support enabled
to have getpass() turn off echoing. (Edit Modules/Setup and
rerun 'make install'.)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110663&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 06:29:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 22:29:22 -0700
Subject: [Python-bugs-list] [Bug #110617] IDLE and -t (PR#213)
Message-ID: <200009150529.WAA22759@delerium.i.sourceforge.net>

Bug #110617, was updated on 2000-Jul-31 14:06
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: IDLE and -t (PR#213)

Details: Jitterbug-Id: 213
Submitted-By: aa8vb@yahoo.com
Date: Fri, 25 Feb 2000 07:36:01 -0500 (EST)
Version: 1.5.2 (w/ IDLE 0.5)
OS: IRIX


Since no other X app I know of works this way, I think this is a bug.

If you set the title of the IDLE window:

     idle.py -t IDLE

the title is set correctly, but the icon name is not.
It is set to "*IDLE" rather than "IDLE".




====================================================================
Audit trail:
Tue Mar 07 14:41:55 2000	guido	changed notes
Tue Mar 07 14:41:55 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Fri, 25 Feb 2000 08:26:32 -0500

> Since no other X app I know of works this way, I think this is a bug.
> 
> If you set the title of the IDLE window:
> 
>      idle.py -t IDLE
> 
> the title is set correctly, but the icon name is not.
> It is set to "*IDLE" rather than "IDLE".

Not a bug -- IDLE adds * before (and after!) the window title and
icon name to indicate that the window is modified and unsaved.

Does this bother you in some way?

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Randall Hopper <aa8vb@yahoo.com>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Mon, 28 Feb 2000 07:25:31 -0500

Guido van Rossum:
 |> Since no other X app I know of works this way, I think this is a bug.
 |> 
 |> If you set the title of the IDLE window:
 |> 
 |>      idle.py -t IDLE
 |> 
 |> the title is set correctly, but the icon name is not.
 |> It is set to "*IDLE" rather than "IDLE".
 |
 |Not a bug -- IDLE adds * before (and after!) the window title and
 |icon name to indicate that the window is modified and unsaved.

The icon name doesn't follow this convention:

        if not self.get_saved():            
            title = "*%s*" % title
            icon = "*%s" % icon

The reason I took note of this inconsistency is that I was assigning a
window manager icon to IDLE based on the startup icon string.

 |Does this bother you in some way?

Well, no other X app I know of communicates unsaved status by putting '*'s
in the title and icon, but I don't have a big problem with it.  

I do think the icon should have a '*' both before "and after", as you
described though.  I'm guessing this was just a typo.

Thanks,

Randall

-- 
Randall Hopper
aa8vb@yahoo.com


-------------------------------------------------------

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Mon, 28 Feb 2000 08:16:48 -0500

>  |Not a bug -- IDLE adds * before (and after!) the window title and
>  |icon name to indicate that the window is modified and unsaved.
> 
> The icon name doesn't follow this convention:
> 
>         if not self.get_saved():            
>             title = "*%s*" % title
>             icon = "*%s" % icon
> 
> The reason I took note of this inconsistency is that I was assigning a
> window manager icon to IDLE based on the startup icon string.
> 
>  |Does this bother you in some way?
> 
> Well, no other X app I know of communicates unsaved status by putting '*'s
> in the title and icon, but I don't have a big problem with it.  

Hm, I have to admit that I have given up years ago on configuring X
apps through their app name.  Is that still a common practice?  I could
certainly change things around so that the title and icon are always "idle:
*file*" or "idle: file" depending on saved status.

> I do think the icon should have a '*' both before "and after", as you
> described though.  I'm guessing this was just a typo.

I think it was intentional, trying to save some space in the icon
label.  Not worth it, probably.

--Guido van Rossum (home page: http://www.python.org/~guido/)



-------------------------------------------------------

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Randall Hopper <aa8vb@yahoo.com>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Tue, 29 Feb 2000 14:26:37 -0500


--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii

Guido van Rossum:
 |Hm, I have to admit that I have given up years ago on configuring X
 |apps through their app name.  Is that still a common practice?  I could

Definitely.  Most all (all?) use WM_CLASS, and many use WM_NAME and
WM_ICONNAME as fallbacks.  This is useful if WM_CLASS isn't set to a useful
value (as in this case).

IDLE doesn't set a class name property on it's window, so the window name
and icon name are all the window manager has to go on when matching it up
with configuration settings.

However, I believe IDLE could set a class name easily by passing it to
Tkinter -- e.g.  root = Tk( className="IDLE" ).  See attached.

More info: the properties used by many window managers as a key into a
configuration database are: CLASS, NAME, and ICON_NAME.  For example,
running 'xprop' on my xterm window here:

   > xprop
   ...
   WM_CLASS(STRING) = "xterm-color", "XTerm"
   ...
   WM_ICON_NAME(STRING) = "Local"
   WM_NAME(STRING) = "Local"

So I can set window manager resources for this window using "XTerm",
"xterm-color", or "Local" -- with overrides in that order I believe.
So I can have a default icon for xterms, and then an override icon for
xterm windows with a certain title.

IDLE doesn't set CLASS so it's basically useless for this configuration
purpose.  On stock IDLE:

   WM_CLASS(STRING) = "270515832", "Toplevel"

 |certainly change things around so that the title and icon are always "idle:
 |*file*" or "idle: file" depending on saved status.

If IDLE could set WM_CLASS to a static (or cmd-line-specified) value on
it's shell windows, that'd be enough for me.  For now I'm using -t IDLE,
but that doesn't cover opening new windows inside of IDLE (opening files,
File->New Window, etc.)

A unique prefix on the WM_NAME (title string) would work too.

 |> I do think the icon should have a '*' both before "and after", as you
 |> described though.  I'm guessing this was just a typo.
 |
 |I think it was intentional, trying to save some space in the icon
 |label.  Not worth it, probably.

Thanks,

Randall


-- 
Randall Hopper
aa8vb@yahoo.com

--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="tk.py"

from Tkinter import *
root = Tk( className="Test" )
btn = Button( root )
btn.pack()
root.mainloop()

--oyUTqETQ0mS9luUI--


-------------------------------------------------------

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Wed, 01 Mar 2000 09:21:41 -0500

Randall,

Thanks for your enlightenment.  I looked at your example, and it
works; but I need more, because IDLE creates windows using Toplevel(),
not using Tk().  (Using Tk() would create a new Tcl interpreter for
each window, which wastes time and memory resources, and re-reads the
~/.<whatever>.py file each time.)

I've experimented with xprop a bit, and I'm not getting results I
like.  If I write root = Tk(className="foo"), WM_CLASS is "foo",
"Foo".  Them if I write top = Toplevel(root), WM_CLASS for that window
is "1234567", "Toplevel".  If I try top = Toplevel(root, name="bar"),
I get "bar", "Toplevel".  Shouldn't I be able to set the second
component of WM_CLASS somehow?

Got any ideas?

If you can send me a patch, that would be greatly appreciated!

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Randall Hopper <aa8vb@yahoo.com>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Mon, 6 Mar 2000 08:50:29 -0500


--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii

Guido van Rossum:
 |Thanks for your enlightenment.  I looked at your example, and it
 |works; but I need more, because IDLE creates windows using Toplevel(),
 |not using Tk().  (Using Tk() would create a new Tcl interpreter for
 |each window, which wastes time and memory resources, and re-reads the
 |~/.<whatever>.py file each time.)
 |
 |I've experimented with xprop a bit, and I'm not getting results I
 |like.  If I write root = Tk(className="foo"), WM_CLASS is "foo",
 |"Foo".  Them if I write top = Toplevel(root), WM_CLASS for that window
 |is "1234567", "Toplevel".  If I try top = Toplevel(root, name="bar"),
 |I get "bar", "Toplevel".  Shouldn't I be able to set the second
 |component of WM_CLASS somehow?
 |
 |Got any ideas?

Sorry about that last message.  This issue is very closely related to the
resource loading issue on idle-dev, but not the same.  Once the small
change below is in-place (to solve this problem), the platform-independent
Tkinter methods for resource loading can be used to solve the idle-dev
problem, if desired.

Research indicates that the Tk-ism for setting Toplevel classes is:

      "toplevel .mytop -class classname"

So the Tkinter syntax is:

      top1   = Toplevel( root, class_=classname )

The attached test app demonstrates this.  I verified that I am able to set
X resources for these windows using the class name "Idle".

-- 
Randall Hopper
aa8vb@yahoo.com

--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="tk_class.py"

from Tkinter import *

CLASSNAME = "Idle"

root = Tk( className=CLASSNAME )
root.wm_withdraw()

# A toplevel with a WM_CLASS
top1   = Toplevel( root, class_=CLASSNAME )
label1 = Label( top1, text="Toplevel 1" )
label1.pack()

# Another one
top2   = Toplevel( root, class_=CLASSNAME )
label2 = Label( top2, text="Toplevel 2" )
label2.pack()

root.mainloop()

--MGYHOYXEY6WxJCY8--


-------------------------------------------------------

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Mon, 06 Mar 2000 09:11:30 -0500

> Sorry about that last message.  This issue is very closely related to the
> resource loading issue on idle-dev, but not the same.  Once the small
> change below is in-place (to solve this problem), the platform-independent
> Tkinter methods for resource loading can be used to solve the idle-dev
> problem, if desired.

See my response in idle-dev :-)

Of course the Tk options can still be used for changing things that
the config file or prefs dialog doesn't support.

> Research indicates that the Tk-ism for setting Toplevel classes is:
> 
>       "toplevel .mytop -class classname"
> 
> So the Tkinter syntax is:
> 
>       top1   = Toplevel( root, class_=classname )
> 
> The attached test app demonstrates this.  I verified that I am able to set
> X resources for these windows using the class name "Idle".

OK, I'll try to support this!

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 22:29
By: tim_one

Comment:
Assigned to Guido for obvious reasons.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110617&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 06:33:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 22:33:25 -0700
Subject: [Python-bugs-list] [Bug #110598] Fwd: Debian Bug#46993: py_compile.compile() won't compile files with CR+LF line endings (PR#101)
Message-ID: <200009150533.WAA22895@delerium.i.sourceforge.net>

Bug #110598, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Fwd: Debian Bug#46993: py_compile.compile() won't compile files with CR+LF line endings (PR#101)

Details: Jitterbug-Id: 101
Submitted-By: flight@mathi.uni-heidelberg.de
Date: Mon, 11 Oct 1999 15:10:37 +0200
Version: 1.5.2
OS: Debian GNU/Linux potato

[This was recorded as Debian bug#46993, cf.
http://www.debian.org/Bugs/db/46/46993.html]

Package: python-base
Version: 1.5.2-6
Severity: normal

On Unix systems, py_compile.compile() (and therefore compileall.py) won't
compile files with DOS/Windows lineendings (CR+LF). Commands like "import"
or "exec" will work, though.

The problem seems to be that py_compile.compile read()'s the whole file at
once and passes it as a string to __builtin__.compile(), while "import"
calls __builtin__.compile() for a file, so that __builtin__.compile seems to
do some magic while reading the file.

For a quick testcase:

  import __builtin__
  f=open("test.py","w")
  f.write('print "Hello"\015\012')
  f.close()
  f=open("test.py")
  c=f.read()
  f.close()
  __builtin__.compile(c,"test.py","exec")

results in:

  Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 9, in x
  File "<string>", line 1
    print "Hello"
                 ^
  SyntaxError: invalid syntax

while "import test" works fine and results in test.pyc.

Certainly the file.read() in py_compile.compile() isn't good enough for this
case.

    Gregor


====================================================================
Audit trail:
Mon Oct 11 18:12:13 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-30 23:28
By: mhammond

Comment:
Sorry, but I dont feel able to resolve this in time for 2.0 beta or final, so giving back to Jeremy to punt back off.  If post 2.0 is OK, give it on back!
-------------------------------------------------------

Date: 2000-Sep-05 14:42
By: loewis

Comment:
Fixed in 101425, see
http://sourceforge.net/patch/?func=detailpatch&patch_id=101425&group_id=5470
-------------------------------------------------------

Date: 2000-Sep-14 22:33
By: tim_one

Comment:
Assigned back to Martin.  I see that the patch in question has been Accepted, so please change this bug to Fixed and Closed after you commit the patch and Close it.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110598&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 06:44:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 22:44:22 -0700
Subject: [Python-bugs-list] [Bug #110647] Segmentation violation on very long lists (PR#334)
Message-ID: <200009150544.WAA05594@bush.i.sourceforge.net>

Bug #110647, was updated on 2000-Jul-31 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 3
Summary: Segmentation violation on very long lists (PR#334)

Details: Jitterbug-Id: 334
Submitted-By: haase@media.mit.edu
Date: Sat, 20 May 2000 20:08:00 -0400 (EDT)
Version: Both Python 1.5.2 and 1.6a2
OS: SUSE Linux


Loading a .py file which attempts to define a very long list causes
a segmentation violation.  An example file can be found at
ftp:/pub/haase/todo.py, but I expect that most any long file defining a long
list (20K elements) would do.

Thanks,

Ken Haase






====================================================================
Audit trail:
Mon May 22 17:08:11 2000	guido	changed notes
Mon May 22 17:08:11 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:10
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] Segmentation violation on very long lists (PR#334)
Date: Sun, 21 May 2000 12:12:22 -0700

> Loading a .py file which attempts to define a very long list causes
> a segmentation violation.  An example file can be found at
> ftp:/pub/haase/todo.py, but I expect that most any long file defining a long
> list (20K elements) would do.

Thanks -- this is a known problem, it probably has to do with bytecode
field overflow (offsets are signed shorts).

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-01 15:54
By: jhylton

Comment:
Currently raises SyntaxError.  A better fix is in progress.
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 22:44
By: tim_one

Comment:
Marked as closed and fixed, but without running your test case (the FTP address you gave doesn't make sense -- at least not on *my* machine <wink>).

I generated a 50,000-element list with this program instead:

f = open("k.py", "w")
print >> f, "biglist = ["
for i in range(50000): print >> f, i, ","
print >> f, "]"
print >> f, "print len(biglist)"
f.close()

and Python 2.0b1 compiles and executes the resulting k.py without incident.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110647&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 06:50:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 22:50:58 -0700
Subject: [Python-bugs-list] [Bug #110706] gcc error msg, 1.5.2, Slackware + threads (PR#44)
Message-ID: <200009150550.WAA05856@bush.i.sourceforge.net>

Bug #110706, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: gcc error msg, 1.5.2, Slackware + threads (PR#44)

Details: Jitterbug-Id: 44
Submitted-By: rene@kronos.szabinet.hu
Date: Sun, 1 Aug 1999 16:39:42 -0400 (EDT)
Version: 1.5.2
OS: Linux


Compile error with Python-1.5.2 on
Linux Slackware 4.0, kernel 2.2.10-ac8, gcc 2.7.2.3, make 3.76.1

./configure --prefix=/usr/local --with-threads && make
...
./socketmodule.c: In function `setipaddr':
./socketmodule.c:392: warning: passing arg 5 of `gethostbyname_r' from
incompatible pointer type
./socketmodule.c:392: too many arguments to function `gethostbyname_r'
./socketmodule.c:392: warning: assignment makes integer from pointer without a
cast
./socketmodule.c: In function `PySocket_gethostbyname_ex':
./socketmodule.c:1471: warning: passing arg 5 of `gethostbyname_r' from
incompatible pointer type
./socketmodule.c:1471: too many arguments to function `gethostbyname_r'
./socketmodule.c:1471: warning: assignment makes integer from pointer without a
cast
./socketmodule.c: In function `PySocket_gethostbyaddr':
./socketmodule.c:1534: warning: passing arg 7 of `gethostbyaddr_r' from
incompatible pointer type
./socketmodule.c:1534: too many arguments to function `gethostbyaddr_r'
./socketmodule.c:1534: warning: assignment makes integer from pointer without a
cast
make[1]: *** [socketmodule.o] Error 1
make: *** [Modules] Error 2



====================================================================
Audit trail:
Wed Aug 04 12:12:39 1999	guido	moved from incoming to platformbug
Mon Aug 30 12:37:34 1999	guido	changed notes
Mon Oct 25 15:15:46 1999	guido	changed notes

Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 22:50
By: tim_one

Comment:
Assigned to Fred for the heck of it.  Changed the "Summary" msg as the original "Compiler error" gave me an entirely wrong impression.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110706&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 06:52:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 22:52:54 -0700
Subject: [Python-bugs-list] [Bug #110849] Fwd: Debian Bug#42318: urllib.py has problems with malformed proxy env. variables (PR#59)
Message-ID: <200009150552.WAA05892@bush.i.sourceforge.net>

Bug #110849, was updated on 2000-Aug-01 14:16
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Fwd: Debian Bug#42318: urllib.py has problems with malformed proxy env. variables (PR#59)

Details: Jitterbug-Id: 59
Submitted-By: flight@debian.org
Date: Fri, 20 Aug 1999 13:40:04 -0400 (EDT)
Version: 1.5.2
OS: Debian potato


Summary: Python's urllib expects a fully qualified URL in HTTP_PROXY (like
"http://proxy:8080/"). Many applications allow short forms in HTTP_PROXY
(like "proxy:8080"). If HTTP_PROXY is set to a short form, urllib.py will
fail with an uncomprehensible error message.


Long form:

Francesco Potorti` <F.Potorti@cnuce.cnr.it> says (in the Debian bug report
http://www.debian.org/Bugs/db/42/42318.html):

  "when setting a proxy variable that is not parsed by urllib, urllib does
   not print a comprehensible error message."

An example:


Short form HTTP_PROXY:

  master% HTTP_PROXY="proxy.cnr.it:8081" \
    python -c 'import urllib; print
urllib.urlretrieve("http://www.olemiss.edu/")'
  Traceback (innermost last):
    File "<string>", line 1, in ?
    File "/usr/lib/python1.5/urllib.py", line 69, in urlretrieve
      return _urlopener.retrieve(url)
    File "/usr/lib/python1.5/urllib.py", line 186, in retrieve
      fp = self.open(url)
    File "/usr/lib/python1.5/urllib.py", line 154, in open
      return self.open_unknown(fullurl)
    File "/usr/lib/python1.5/urllib.py", line 168, in open_unknown
      raise IOError, ('url error', 'unknown url type', type)
  IOError: ('url error', 'unknown url type', 'http')


Fully qualified URL in HTTP_PROXY:

  master% HTTP_PROXY="http://proxy.cnr.it:8081" \
    python -c 'import urllib; print
urllib.urlretrieve("http://www.olemiss.edu/")'
  ('/tmp/@15884.1', <mimetools.Message instance at 80adb08>)



====================================================================
Audit trail:
Mon Aug 30 12:35:03 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 22:52
By: tim_one

Comment:
Assigned to Barry because I think of him as being the Potato Man.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110849&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 06:54:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 22:54:33 -0700
Subject: [Python-bugs-list] [Bug #110660] IDLE-0.5  ctrl-F5 (PR#355)
Message-ID: <200009150554.WAA05994@bush.i.sourceforge.net>

Bug #110660, was updated on 2000-Jul-31 14:11
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: IDLE-0.5  ctrl-F5 (PR#355)

Details: Jitterbug-Id: 355
Submitted-By: gpk@bell-labs.com
Date: Tue, 13 Jun 2000 11:30:14 -0400 (EDT)
Version: yesterday's CVS
OS: Solaris 2.6


If you type ctrl-f5 to run a script twice in sucession,
IDLE will incorrectly pop up a window saying
"Not Saved.  Please Save First."

If you save (even though you haven't changed anything,
and even though there are no asterisks around the window
title), then ctrl-f5 will work again.

This *doesn't* happen if you run the script twice in
succession from the menu.



====================================================================
Audit trail:
Tue Jul 11 08:26:00 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] IDLE-0.5  ctrl-F5 (PR#355)
Date: Tue, 13 Jun 2000 11:55:09 -0400

Pretty mysterious!  Doesn't happen under IDLE 0.5 for me.  Running under
Windows, but darned hard to see why that would matter.  Can anyone else try
this under Solaris 2.6?  May have something to do with the specific script
you're running, Greg; e.g., does it happen if the script file contains just

print "Hi!"

?

> -----Original Message-----
> From: python-bugs-list-admin@python.org
> [mailto:python-bugs-list-admin@python.org]On Behalf Of gpk@bell-labs.com
> Sent: Tuesday, June 13, 2000 11:30 AM
> To: python-bugs-list@python.org
> Cc: bugs-py@python.org
> Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355)
>
>
> Full_Name: Greg Kochanski
> Version: yesterday's CVS
> OS: Solaris 2.6
> Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130)
>
>
> If you type ctrl-f5 to run a script twice in sucession,
> IDLE will incorrectly pop up a window saying
> "Not Saved.  Please Save First."
>
> If you save (even though you haven't changed anything,
> and even though there are no asterisks around the window
> title), then ctrl-f5 will work again.
>
> This *doesn't* happen if you run the script twice in
> succession from the menu.
>
>
>
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list
>




-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355)
Date: Tue, 20 Jun 2000 16:42:57 -0500

I think I understand this.  It's happened to me too.  Pressing ^F5
changes the focus to the PyShell window.  Pressing ^F5 again then
indeed complains about that window being unsaved.

--Guido van Rossum (home page: http://www.python.org/~guido/)

[Tim]
> Pretty mysterious!  Doesn't happen under IDLE 0.5 for me.  Running under
> Windows, but darned hard to see why that would matter.  Can anyone else try
> this under Solaris 2.6?  May have something to do with the specific script
> you're running, Greg; e.g., does it happen if the script file contains just
> 
> print "Hi!"
> 
> ?
> 
> > -----Original Message-----
> > From: python-bugs-list-admin@python.org
> > [mailto:python-bugs-list-admin@python.org]On Behalf Of gpk@bell-labs.com
> > Sent: Tuesday, June 13, 2000 11:30 AM
> > To: python-bugs-list@python.org
> > Cc: bugs-py@python.org
> > Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355)
> >
> >
> > Full_Name: Greg Kochanski
> > Version: yesterday's CVS
> > OS: Solaris 2.6
> > Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130)
> >
> >
> > If you type ctrl-f5 to run a script twice in sucession,
> > IDLE will incorrectly pop up a window saying
> > "Not Saved.  Please Save First."
> >
> > If you save (even though you haven't changed anything,
> > and even though there are no asterisks around the window
> > title), then ctrl-f5 will work again.
> >
> > This *doesn't* happen if you run the script twice in
> > succession from the menu.
> >
> >
> >
> > _______________________________________________
> > Python-bugs-list maillist  -  Python-bugs-list@python.org
> > http://www.python.org/mailman/listinfo/python-bugs-list
> >
> 
> 
> 
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Greg Kochanski <gpk@bell-labs.com>
Subject: Re: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355)
Date: Tue, 20 Jun 2000 17:25:37 -0400

Guido van Rossum wrote:
> 
> I think I understand this.  It's happened to me too.  Pressing ^F5
> changes the focus to the PyShell window.  Pressing ^F5 again then
> indeed complains about that window being unsaved.
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

Ah. Sure enough.   Perhaps the best thing to do
is just to have the little error message explain
which window is unsaved.  Include the title
of the unsaved window in the error box, maybe.

I'd be happy to send a patch, but the paperwork
would be terrible...


-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355)
Date: Tue, 20 Jun 2000 18:10:35 -0500

> > I think I understand this.  It's happened to me too.  Pressing ^F5
> > changes the focus to the PyShell window.  Pressing ^F5 again then
> > indeed complains about that window being unsaved.
> > 
> > --Guido van Rossum (home page: http://www.python.org/~guido/)
> 
> Ah. Sure enough.   Perhaps the best thing to do
> is just to have the little error message explain
> which window is unsaved.  Include the title
> of the unsaved window in the error box, maybe.
> 
> I'd be happy to send a patch, but the paperwork
> would be terrible...

No need for paperwork, just the disclaimer text.

But I think the better patch would be to make PyShell a special case
and make it rerun the last window that had the focus.

--Guido van Rossum (home page: http://www.python.org/~guido/)



-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 22:54
By: tim_one

Comment:
Assigned to Guido.  Guido, know whether he ever mailed you a patch?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110660&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 06:58:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 22:58:45 -0700
Subject: [Python-bugs-list] [Bug #110857] it don't make (PR#269)
Message-ID: <200009150558.WAA06041@bush.i.sourceforge.net>

Bug #110857, was updated on 2000-Aug-01 14:38
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Irreproducible
Priority: 3
Summary: it don't make (PR#269)

Details: Jitterbug-Id: 269
Submitted-By: mitch.harris@usa.net
Date: Mon,  3 Apr 2000 13:29:25 -0400 (EDT)
Version: 1.6
OS: sun 5.6


First time I tried to install Python. 


/usr2/t_mitchh/python/Python-1.6a1>version
Machine hardware:   sun4u
OS version:         5.6
Processor type:     sparc
Hardware:           SUNW,Ultra-1

The following components are installed on your system:


Sun Visual WorkShop C++ 3.0
        Sun WorkShop Compiler C 4.2 
        Sun WorkShop Compiler C++ 4.2 
        Sun WorkShop Tools.h++ 7.0 
        Sun WorkShop Tools.h++ 6.0.4 
        Sun WorkShop Visual 2.0 
        Sun WorkShop IPE 4.0 
        Sun WorkShop CodeManager 2.0 
        Sun WorkShop Distributed Make 2.0 
        Sun WorkShop FileMerge 3.0 
        Sun WorkShop FreezePoint 2.0 
        Sun WorkShop Maketool 2.0 
        Sun WorkShop VersionTool 2.0 
        Sun WorkShop Dbx 4.0 
        Sun WorkShop Performance Analyzer 4.0 
        Sun WorkShop LoopTool 2.1 
        Sun WorkShop LockLint 2.1 
        Sun WorkShop Thread Analyzer 1.2 
        Sun WorkShop XEmacs 20.00 

/usr2/t_mitchh/python/Python-1.6a1>./configure
creating cache ./config.cache
checking MACHDEP... sunos5
checking for --without-gcc... no
checking for --with-cxx=<compiler>... no
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking LINKCC... $(PURIFY) $(CC)
checking LDLIBRARY... 
checking for ranlib... ranlib
checking for ar... ar
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking for minix/config.h... no
checking whether gcc accepts -OPT:Olimit=0... no
checking whether gcc accepts -Olimit 1500... no
checking for C preprocessor type... ansi
checking for ANSI C header files... yes
checking for dlfcn.h... yes
checking for fcntl.h... yes
checking for limits.h... yes
checking for locale.h... yes
checking for ncurses.h... no
checking for pthread.h... yes
checking for signal.h... yes
checking for stdarg.h... yes
checking for stddef.h... yes
checking for stdlib.h... yes
checking for thread.h... yes
checking for unistd.h... yes
checking for utime.h... yes
checking for sys/audioio.h... yes
checking for sys/file.h... no
checking for sys/lock.h... yes
checking for sys/param.h... no
checking for sys/select.h... yes
checking for sys/time.h... yes
checking for sys/times.h... yes
checking for sys/un.h... yes
checking for sys/utsname.h... yes
checking for sys/wait.h... yes
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking for clock_t in time.h... yes
checking for mode_t... yes
checking for off_t... yes
checking for pid_t... yes
checking return type of signal handlers... void
checking for size_t... yes
checking for uid_t in sys/types.h... yes
checking size of int... 4
checking size of long... 4
checking size of void *... 4
checking size of char... 1
checking size of short... 2
checking size of float... 4
checking size of double... 8
checking for long long support... yes
checking size of long long... 8
checking size of off_t... 4
checking whether to enable large file support... no
checking for --with-next-framework... no
checking for --with-dyld... no
checking SO... .so
checking LDSHARED... ld -G
checking CCSHARED... 
checking LINKFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for t_open in -lnsl... yes
checking for socket in -lsocket... yes
checking for socket in -lnet... no
checking for --with-libs... no
checking for --with(out)-readline... not specified.
checking for --with-dec-threads... no
checking for --with-threads... no
checking for --with-thread... no
checking for --with-sgi-dl... no
checking for --with-dl-dld... no
checking for dlopen... yes
checking DYNLOADFILE... dynload_shlib.o
checking for alarm... yes
checking for chown... yes
checking for clock... yes
checking for confstr... yes
checking for ctermid... yes
checking for ctermid_r... yes
checking for dlopen... (cached) yes
checking for execv... yes
checking for flock... no
checking for fork... yes
checking for fsync... yes
checking for fdatasync... no
checking for fpathconf... yes
checking for ftime... yes
checking for ftruncate... yes
checking for getgroups... yes
checking for getlogin... yes
checking for getpeername... yes
checking for getpgrp... yes
checking for getpid... yes
checking for getpwent... yes
checking for gettimeofday... yes
checking for getwd... yes
checking for kill... yes
checking for link... yes
checking for lstat... yes
checking for mkfifo... yes
checking for mktime... yes
checking for nice... yes
checking for pathconf... yes
checking for pause... yes
checking for plock... yes
checking for pthread_init... no
checking for putenv... yes
checking for readlink... yes
checking for select... yes
checking for setgid... yes
checking for setlocale... yes
checking for setuid... yes
checking for setsid... yes
checking for setpgid... yes
checking for setpgrp... yes
checking for setvbuf... yes
checking for sigaction... yes
checking for siginterrupt... yes
checking for sigrelse... yes
checking for strftime... yes
checking for strptime... yes
checking for symlink... yes
checking for sysconf... yes
checking for tcgetpgrp... yes
checking for tcsetpgrp... yes
checking for tempnam... yes
checking for timegm... no
checking for times... yes
checking for tmpfile... yes
checking for tmpnam... yes
checking for tmpnam_r... yes
checking for truncate... yes
checking for uname... yes
checking for waitpid... yes
checking for fseek64... no
checking for fseeko... yes
checking for fstatvfs... yes
checking for ftell64... no
checking for ftello... yes
checking for statvfs... yes
checking for dup2... yes
checking for getcwd... yes
checking for strdup... yes
checking for strerror... yes
checking for memmove... yes
checking for getpgrp... (cached) yes
checking for setpgrp... (cached) yes
checking for gettimeofday... (cached) yes
checking whether time.h and sys/time.h may both be included... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for tm_zone in struct tm... no
checking for tzname... yes
checking for time.h that defines altzone... yes
checking whether sys/select.h and sys/time.h may both be included... yes
checking whether char is unsigned... no
checking for working const... yes
checking for inline... inline
checking for working volatile... yes
checking for working signed char... yes
checking for prototypes... yes
checking for variable length prototypes and stdarg.h... yes
checking for bad exec* prototypes... no
checking for bad static forward... no
checking whether va_list is an array... no
checking for gethostbyname_r... yes
checking gethostbyname_r with 6 args... no
checking gethostbyname_r with 5 args... no
checking gethostbyname_r with 3 args... no
checking for __fpu_control in -lieee... no
checking for --with-fpectl... no
checking for --with-libm=STRING... default LIBM="-lm"
checking for --with-libc=STRING... default LIBC=""
checking for hypot... yes
checking for hypot... (cached) yes
checking for genuine getopt... yes
checking what malloc(0) returns... nonnull
checking for wchar.h... yes
checking for usable wchar_t... no
checking whether byte ordering is bigendian... yes
checking for --with-wctype-functions... no
updating cache ./config.cache
creating ./config.status
creating Makefile
creating Objects/Makefile
creating Parser/Makefile
creating Python/Makefile
creating Modules/Makefile.pre
creating Modules/Setup.thread
creating config.h


/usr2/t_mitchh/python/Python-1.6a1/Modules>make
gcc  -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c
In file included from ./posixmodule.c:3194:
/usr/include/sys/statvfs.h:38: parse error before `fsblkcnt_t'
/usr/include/sys/statvfs.h:38: warning: no semicolon at end of struct or union
/usr/include/sys/statvfs.h:39: warning: data definition has no type or storage
class
/usr/include/sys/statvfs.h:40: parse error before `f_bavail'
/usr/include/sys/statvfs.h:40: warning: data definition has no type or storage
class
/usr/include/sys/statvfs.h:41: parse error before `f_files'
/usr/include/sys/statvfs.h:41: warning: data definition has no type or storage
class
/usr/include/sys/statvfs.h:42: parse error before `f_ffree'
/usr/include/sys/statvfs.h:42: warning: data definition has no type or storage
class
/usr/include/sys/statvfs.h:43: parse error before `f_favail'
/usr/include/sys/statvfs.h:43: warning: data definition has no type or storage
class
/usr/include/sys/statvfs.h:51: parse error before `}'
/usr/include/sys/statvfs.h:51: warning: data definition has no type or storage
class
./posixmodule.c: In function `posix_fstatvfs':
./posixmodule.c:3207: storage size of `st' isn't known
./posixmodule.c: In function `posix_statvfs':
./posixmodule.c:3259: storage size of `st' isn't known
make: *** [posixmodule.o] Error 1

I tried this 

#if defined(HAVE_FSTATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
#if defined(HAVE_STATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
#ifdef HAVE_FSTATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
#ifdef HAVE_STATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

and got this

/prj/qed2/local//lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.1/include/sys/param.h:187:
warning: `NBBY' r
/usr/include/sys/select.h:45: warning: this is the location of the previous
definition
In file included from /usr/include/sys/stream.h:26,
                 from /usr/include/netinet/in.h:38,
                 from /usr/include/netdb.h:96,
                 from ./socketmodule.c:163:
/usr/include/sys/model.h:32: #error "No DATAMODEL_NATIVE specified"
make[1]: *** [socketmodule.o] Error 1
make[1]: Leaving directory `/usr2/t_mitchh/python/Python-1.6a1/Modules'
make: *** [Modules] Error 2



====================================================================
Audit trail:
Mon May 22 17:44:30 2000	guido	changed notes
Mon May 22 17:44:30 2000	guido	moved from incoming to irreproducible

Follow-Ups:

Date: 2000-Aug-01 14:38
By: none

Comment:
Sun's compiler sucks?
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 22:58
By: tim_one

Comment:
Changed Category to Build, and assigned to Jeremy at random.  I don't know why the Group is set to Irreproducible.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110857&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 07:03:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 23:03:34 -0700
Subject: [Python-bugs-list] [Bug #113693] freeze modulefinder broken
Message-ID: <200009150603.XAA06205@bush.i.sourceforge.net>

Bug #113693, was updated on 2000-Sep-06 05:09
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: freeze modulefinder broken

Details: The following one-liner script can not be frozen:

import string

The traceback is included below. Line number are from revision 1.13 of modulefinder.py.

The problem appears to be related to recent changes to the import bytecodes

Traceback (most recent call last):
  File "d:\python\tools\freeze\freeze.py", line 457, in ?
    main()
  File "d:\python\tools\freeze\freeze.py", line 321, in main
    mf.import_hook(mod)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 281, in scan_code
    self.import_hook(name, m)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 281, in scan_code
    self.import_hook(name, m)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 303, in scan_code
    self.scan_code(c, m)
  File "d:\python\tools\freeze\modulefinder.py", line 281, in scan_code
    self.import_hook(name, m)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 289, in scan_code
    assert lastname is not None
AssertionError

Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 05:10
By: jackjansen

Comment:
The problem is that the code expects IMPORT_NAME immedeately followed by
a sequence of IMPORT_FROMs. That has changed now that IMPORT_FROM
puts the result on the stack.

A fix that appears to work for me is to set lastname to None only on POP_TOP
instructions. But I'll leave doing the actual fix to someone more knowledgeable than
me on the code that from x import y can generate.
-------------------------------------------------------

Date: 2000-Sep-14 23:03
By: tim_one

Comment:
Changed to Category "demos and tools" and assigned to Guido because I bet he'd simply enjoy fixing this one (think of it as a chance to work on Python, Guido!).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113693&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 07:08:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 23:08:38 -0700
Subject: [Python-bugs-list] [Bug #113773] Python 2.0b1 selectmodule compile error under Redhat 5.2
Message-ID: <200009150608.XAA06355@bush.i.sourceforge.net>

Bug #113773, was updated on 2000-Sep-06 18:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: Python 2.0b1 selectmodule compile error under Redhat 5.2

Details: Environment: Redhat 5.2 running the gcc compiler that comes with the
distribution (gcc 2.7.2.3).

'make' failed when compiling selectmodule.c ('./configure' ran ok)because
the following constants were undefined:

POLLRDNORM, POLLRDBAND, POLLWRBAND

The /usr/include/sys/poll.h file does not contain these constants.
Under Redhat 6.2 the constants are defined in the /usr/include/bits/poll.h
file (which is not present in the Redhat 5.2 distribution).

I used the Redhat 6.2 poll.h file and the selectmodule compiled (under
Redhat 5.2) but got the following error when running 
'make test' (it looks like it might be related to the compile problem):

test test_poll crashed -- select.error: (9, 'Bad file descriptor')

1 test failed: test_poll



Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 23:08
By: tim_one

Comment:
Boosted the priority and assigned to Fred.  Don't know what you can do about an older Redhat build problem, and it's not clear that the test failure isn't simply due to mixing files across OS releases.  I'm inclined to blame it on the OS.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113773&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 07:09:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 23:09:32 -0700
Subject: [Python-bugs-list] [Bug #113773] Python 2.0b1 selectmodule compile error under Redhat 5.2
Message-ID: <200009150609.XAA06454@bush.i.sourceforge.net>

Bug #113773, was updated on 2000-Sep-06 18:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: Python 2.0b1 selectmodule compile error under Redhat 5.2

Details: Environment: Redhat 5.2 running the gcc compiler that comes with the
distribution (gcc 2.7.2.3).

'make' failed when compiling selectmodule.c ('./configure' ran ok)because
the following constants were undefined:

POLLRDNORM, POLLRDBAND, POLLWRBAND

The /usr/include/sys/poll.h file does not contain these constants.
Under Redhat 6.2 the constants are defined in the /usr/include/bits/poll.h
file (which is not present in the Redhat 5.2 distribution).

I used the Redhat 6.2 poll.h file and the selectmodule compiled (under
Redhat 5.2) but got the following error when running 
'make test' (it looks like it might be related to the compile problem):

test test_poll crashed -- select.error: (9, 'Bad file descriptor')

1 test failed: test_poll



Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 23:08
By: tim_one

Comment:
Boosted the priority and assigned to Fred.  Don't know what you can do about an older Redhat build problem, and it's not clear that the test failure isn't simply due to mixing files across OS releases.  I'm inclined to blame it on the OS.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113773&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 07:13:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 23:13:56 -0700
Subject: [Python-bugs-list] [Bug #113795] IDLE 0.6 with Python 2.0b1 doesn't handle chinese characters
Message-ID: <200009150613.XAA06522@bush.i.sourceforge.net>

Bug #113795, was updated on 2000-Sep-07 06:49
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: IDLE 0.6 with Python 2.0b1 doesn't handle chinese characters

Details: I just switched from 1.5.2 to 2.0b1 on W2K/Simplified Chinese version. I used to be able to input chinese characters directly into IDLE, and access violations did happen quite often. Now with 2.0b1, I can't even input chinese characters into the IDLE window anymore:IDLE automatically changed chinese characters into illegible stuff; it's the same when I copy from a text editor and paste into the IDLE window. I guess it's related to the induction of unicode support in 2.0, but is there a workaround I should know, or I should switch back to 1.5.2, or it's a bug worth fixing?

Thanks.


Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 23:13
By: tim_one

Comment:
Assigned to Fredrik, because Swedes have an uncanny intuition about how IDLE and Tk work in the presence of characters I can't get at <0.9 wink>.  Boosted the priority because it sounds like a legit practical problem.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113795&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 07:25:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 23:25:07 -0700
Subject: [Python-bugs-list] [Bug #114245] utime can not accept directory under NT
Message-ID: <200009150625.XAA06898@bush.i.sourceforge.net>

Bug #114245, was updated on 2000-Sep-12 06:36
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: utime can not accept directory under NT

Details: Whenever supply a directory to utime path parameter, exception raised.  The problem is MS C run time library utime function only works on files, but not directories.  To fix this bug, MS utime has to be replaced by some function that works with directory.

Follow-Ups:

Date: 2000-Sep-13 15:49
By: gangli59

Comment:
I submitted a patch that uses win32 api instead MSC run time library
-------------------------------------------------------

Date: 2000-Sep-14 23:25
By: tim_one

Comment:
Changed to Category "Modules".
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114245&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 07:43:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 23:43:25 -0700
Subject: [Python-bugs-list] [Bug #113812] Serious garbage collection problems with 2.0b1
Message-ID: <200009150643.XAA25206@delerium.i.sourceforge.net>

Bug #113812, was updated on 2000-Sep-07 10:10
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 8
Summary: Serious garbage collection problems with 2.0b1

Details: Since I've installed version 2.0b1, I ran into a few (serious) problems
with a non-trivial application (+80,000 lines of Python). It seems that
the are all related to the new garbage collection:

 - Suddenly, assertions fail because lists have become empty 
   while they shouldn't have. I looks like their elements have been
   garbage collected while they were still reachable.

 - Under other circumstances, I get coredumps which always 
   seem to happen in function "move_root_reachable" of gcmodule.c:
   the "traverse" function pointer seems to contain a bogus address.

 - When I run a Purified version of the interpreter, I can't reproduce
   either problem, but instead, the garbage collector seems to get
   stuck in an endless loop each time. This always happens in the
   same function "move_root_reachable". Purify doesn't produce any 
   relevant warning.

The code runs just fine with version 1.6 of the interpreter, or when I
disable the garbage collector.

Probably relevant is the fact that the objects (10,000's) in my application
are very heavily cross-linked (nearly all links are bi-directional), which 
probably puts a lot of stress on the garbage collector.

My platform: HP-UX 10.20 / c89 compiler


Follow-Ups:

Date: 2000-Sep-07 10:14
By: edg

Comment:
Just one more thing: when I turn on the gc debugging,
the interpreter also seems to get stuck in an endless loop.
-------------------------------------------------------

Date: 2000-Sep-07 14:41
By: jhylton

Comment:
If you set the GC threshold to 0, 
import gc
gc.set_threshold(0)

Do you get the same problem?  Not that I doubt there is some sort of gc problem, but I wonder if there is something going wrong in the accounting or in the collection.

How hard would it be for someone to try to reproduce this bug?  Obviously, it would be helpful to get a smaller test case that has the same behavior as your large program and also tickles the bug.

Do you have any C extension modules in your application or is it pure Python?
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 01:33
By: edg

Comment:
The code is 100% pure Python. 
When I set the threshold to 0, the problem doesn't occur.

The problem is probably very hard to reproduce by anyone else.
The slightest change in the input data for my application
can make the problem go away. Even running an optimized instead
of a debug version of the interpreter can make a difference.

I'm certainly going to try to strip it down, but that won't be 
easy (the same application, using other input data, running 
6 times as long, runs just fine).
-------------------------------------------------------

Date: 2000-Sep-11 07:48
By: edg

Comment:
After 2 full days of debugging, I think that I finally found the 
cause for the gc problems.

To keep a (very) long story short, what I found out was the following:

 - Crashes were due to objects that were destructed twice.
 
 - Endless loops were due to messed-up gc generation lists. The lists should
   always remain perfectly circular, but sometimes they ended up like this:

   list <-> ... <-> X <-> ... <-> ... -> X   

   No wonder that the gc code could easily get stuck; even turning on
   gc debugging caused the counting code to run in circles forever.
   
   The multiple-destruction problem is almost certainly caused by lists being
   messed up.
   
By turning on the debugging code in gc_list_remove and reducing the gc
threshold to a very small value, I could trigger the crash more
reliably, which allowed me to strip down my 80000 line application to this:

-----------------------------------------------------------------------------
#
# Note: to trigger a crash reliably, the debugging code in gc_list_remove
#       _must_ be turned on.
#
import gc
gc.set_threshold(1)

class Node:
   
   def __del__(self):
      dir(self)
 
a = Node()
del a # -> Crash
-----------------------------------------------------------------------------

You wonder: can it be that simple ? :-)

This is what happens when the Node instance `a' is destructed:

 1) The Node instance is removed from the gc lists.
 2) An instance method is created due to the call of the __del__ method.
    THAT METHOD CREATES A NEW REFERENCE TO THE INSTANCE !
 3) The code in the __del__ method triggers the allocation of new
    objects and because the gc threshold has been set very low, it also
    triggers a gc run. 
 4) During the gc run, the instance method is encountered and its reachable
    objects are visited.
 5) Since the instance is referenced by the method, the gc code tries to move
    the instance to another list, while it was no longer present in any list
    -> BINGO

Obviously, the reason why this problem was so hard to reproduce, is the fact
that most classes don't have a __del__ method, and the problem only occurs
when a gc run happens during the execution of a __del__ method.

It think the fix is as simple as this (I'm not too confident, but it 
seems to work):
------------------------------------------------------------------------------
*** Objects/classobject.c.orig	Mon Sep 11 15:55:03 2000
--- Objects/classobject.c	Mon Sep 11 16:12:26 2000
***************
*** 490,496 ****
  #ifdef Py_TRACE_REFS
  	extern long _Py_RefTotal;
  #endif
- 	PyObject_GC_Fini(inst);
  	/* Call the __del__ method if it exists.  First temporarily
  	   revive the object and save the current exception, if any. */
  #ifdef Py_TRACE_REFS
--- 490,495 ----
***************
*** 523,529 ****
  #ifdef COUNT_ALLOCS
  		inst->ob_type->tp_free--;
  #endif
- 		PyObject_GC_Init((PyObject *)inst);
  		return; /* __del__ added a reference; don't delete now */
  	}
  #ifdef Py_TRACE_REFS
--- 522,527 ----
***************
*** 537,542 ****
--- 535,541 ----
  #endif /* Py_TRACE_REFS */
  	Py_DECREF(inst->in_class);
  	Py_XDECREF(inst->in_dict);
+ 	PyObject_GC_Fini(inst);
  	inst = (PyInstanceObject *) PyObject_AS_GC(inst);
  	PyObject_DEL(inst);
  }
------------------------------------------------------------------------------

ie, delay the removal from the gc list till everything has stabilized.

I hope this helps.


-------------------------------------------------------

Date: 2000-Sep-14 23:43
By: nascheme

Comment:
Your analysis looks correct.  Great work.  I think there is a small problem with your fix however.  You should call PyObject_GC_Fini() before the DECREFs on in_class and in_dict.  If, for some reason, decrementing the reference counts of these object causes a garbage collection then the instance could still be on the gc lists and have an invalid in_class or in_dict pointer.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113812&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 07:59:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Sep 2000 23:59:16 -0700
Subject: [Python-bugs-list] [Bug #110598] Fwd: Debian Bug#46993: py_compile.compile() won't compile files with CR+LF line endings (PR#101)
Message-ID: <200009150659.XAA25685@delerium.i.sourceforge.net>

Bug #110598, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Fwd: Debian Bug#46993: py_compile.compile() won't compile files with CR+LF line endings (PR#101)

Details: Jitterbug-Id: 101
Submitted-By: flight@mathi.uni-heidelberg.de
Date: Mon, 11 Oct 1999 15:10:37 +0200
Version: 1.5.2
OS: Debian GNU/Linux potato

[This was recorded as Debian bug#46993, cf.
http://www.debian.org/Bugs/db/46/46993.html]

Package: python-base
Version: 1.5.2-6
Severity: normal

On Unix systems, py_compile.compile() (and therefore compileall.py) won't
compile files with DOS/Windows lineendings (CR+LF). Commands like "import"
or "exec" will work, though.

The problem seems to be that py_compile.compile read()'s the whole file at
once and passes it as a string to __builtin__.compile(), while "import"
calls __builtin__.compile() for a file, so that __builtin__.compile seems to
do some magic while reading the file.

For a quick testcase:

  import __builtin__
  f=open("test.py","w")
  f.write('print "Hello"\015\012')
  f.close()
  f=open("test.py")
  c=f.read()
  f.close()
  __builtin__.compile(c,"test.py","exec")

results in:

  Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 9, in x
  File "<string>", line 1
    print "Hello"
                 ^
  SyntaxError: invalid syntax

while "import test" works fine and results in test.pyc.

Certainly the file.read() in py_compile.compile() isn't good enough for this
case.

    Gregor


====================================================================
Audit trail:
Mon Oct 11 18:12:13 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-30 23:28
By: mhammond

Comment:
Sorry, but I dont feel able to resolve this in time for 2.0 beta or final, so giving back to Jeremy to punt back off.  If post 2.0 is OK, give it on back!
-------------------------------------------------------

Date: 2000-Sep-05 14:42
By: loewis

Comment:
Fixed in 101425, see
http://sourceforge.net/patch/?func=detailpatch&patch_id=101425&group_id=5470
-------------------------------------------------------

Date: 2000-Sep-14 22:33
By: tim_one

Comment:
Assigned back to Martin.  I see that the patch in question has been Accepted, so please change this bug to Fixed and Closed after you commit the patch and Close it.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110598&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 08:03:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 00:03:28 -0700
Subject: [Python-bugs-list] [Bug #113894] os.listdir(driveletter + ":") flawed on Win32
Message-ID: <200009150703.AAA08086@bush.i.sourceforge.net>

Bug #113894, was updated on 2000-Sep-08 08:55
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: Fixed
Bug Group: Platform-specific
Priority: 7
Summary: os.listdir(driveletter + ":") flawed on Win32

Details: On windows NT the os.listdir() function doesn't correctly handle paths containing a drive specification, but no other directory spec. It incorrectly references the root directory on the specified drive rather than the current directory.
For example these two calls should return the same thing (the actual output has been slightly trimmed):

>>> import os
>>> os.listdir('c:')
['3DCube', 'Acrobat3', 'ADOBEAPP', ...]
>>> os.listdir('c:.')
['Capture', 'Catalog', ...]

The same problem shows up in os.glob, for example os.glob('d:*.py') will expand to all .py files in the root of drive d rather than the current directory.

One possible fix is that in posixmodule.c, function posix_listdir, the lines:
	strcpy(namebuf, name);
	if (namebuf[len-1] != '/' && namebuf[len-1] != '\\')
		namebuf[len++] = '/';
	strcpy(namebuf + len, "*.*");
should read:
	strcpy(namebuf, name);
	if (namebuf[len-1] != '/' && namebuf[len-1] != '\\' && namebuf[len-1] != ':')
		namebuf[len++] = '/';
	strcpy(namebuf + len, "*.*");


Follow-Ups:

Date: 2000-Sep-12 06:19
By: gangli59

Comment:
The bug show in glob.glob('d:*.py') is due to os.path.join joins 'd:', '*.py' to 'd:\\*.py' instead of 'd:*.py'
-------------------------------------------------------

Date: 2000-Sep-15 00:03
By: tim_one

Comment:
Changed Summary to be clearer.
I've made & tested the change as suggested (thanks!).
SourceForge CVS isn't working at the moment for me, though, so haven't yet checked it in.  Marked Fixed, but not yet Closed.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113894&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 08:09:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 00:09:09 -0700
Subject: [Python-bugs-list] [Bug #114424] Tkinter/Canvas drawing causes interpreter to crash.
Message-ID: <200009150709.AAA26050@delerium.i.sourceforge.net>

Bug #114424, was updated on 2000-Sep-14 06:32
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 9
Summary: Tkinter/Canvas drawing causes interpreter to crash.

Details: 
 14 September 2000

 Please find my original query below with regard to Tkinter and Python2.0beta1.
 Also find the Python help desk response.

 I had not mentioned in my original query that I am running on a 
 Sun Ultra 10 with the Solaris 5.5.1 operating system. 

 Best,
 Michele

 ---------------------------------------------------------------------------
 ---------------------------------------------------------------------------


 13 September 2000

 HI Python Folks,

 I am trying to evaluate the new "flatten" functionality written for 
 Tkinter to determine if it generates a scientific plot with many data
 points in a reasonable time. I am using the Python2.0beta1.  I should
 admit to being a bit of a newbie with Python.

 For this test, I am using some very simple code that is from the "Python 
 and Tkinter Programming" book by John Grayson.  I will append the simple 
 program to the bottom of this note.  I will mention I did modify the 
 code in the following manner:
  
   1) scaled.append(x,y) to scaled.append((x,y)).
   2) commented out some stuff I did not care about
   3) added code to be able to generate as many data points as I want for
      testing

 If I run the very code attached to this note, I get:

enkidu> /usr/local/bin/python2.0 simpleplot2.py
Traceback (most recent call last):
  File "simpleplot2.py", line 39, in ?
    canvas.create_line(scaled, fill='royalblue')
  File "/usr/local/Python-2.0b1/lib/python2.0/lib-tk/Tkinter.py", line 1955, in create_line
    return self._create('line', args, kw)
  File "/usr/local/Python-2.0b1/lib/python2.0/lib-tk/Tkinter.py", line 1942, in _create
    (self._w, 'create', itemType)
TypeError: can only concatenate tuple (not "dictionary") to tuple
Bus error (core dumped)

 I changed the scaled.append((x,y)) to two lines where I append x and y
 separately; this got rid of the TypeError, but I still got the core dump.
 I have done many experiments where I can sometimes get the code to work in
 interactive mode, but if I decide to draw the line in color, I get a bus 
 error.  I can sometimes draw lines with only a few data points, but I
 bomb on lines with many points.

 I tell you all of this to find out if Tkinter has been tested for drawing
 lines and such on a canvas under Python2.0?  I am suspicious of either 
 memory problems or newbie problems.  I have tried some demos of Tkinter, as 
 well as some GUIs I have made using Tkinter which employ lots of widgets 
 (i.e., scrollbars, text, label, entry) and these seem to work just fine.
 I am not very experienced with drawing stuff on the canvas.

 I do not expect you to debug this code for me, but rather to tell me how
 well Tkinter has been tested under Python2.0.  I know you probably have 
 lots o'stuff to do.

 Best,
 Michele

 -------------------------------------------------------------------------
 Michele D. De La Pena                        email: delapena@stsci.edu
 Senior Scientific Programmer                 phone: 410-338-4713
 Space Telescope Science Institute            fax:   410-338-4767
 3700 San Martin Drive
 Baltimore, MD  21218

 "The nice thing about standards is there are so many to choose from."
 -------------------------------------------------------------------------


 ****************************************************************************

from Tkinter import *

root = Tk()
root.title('Simple Plot - Version 2')
canvas = Canvas(root, width=450, height=300, bg = 'white')
canvas.pack()
Button(root, text='Quit', command=root.quit).pack()

canvas.create_line(100,250,400,250, width=2)
canvas.create_line(100,250,100,50,  width=2)

for i in range(11):
    x = 100 + (i * 30)
    canvas.create_line(x,250,x,245, width=2)
    canvas.create_text(x,254, text='%d'% (10*i), anchor=N)

for i in range(6):
    y = 250 - (i * 40)
    canvas.create_line(100,y,105,y, width=2)
    canvas.create_text(96,y, text='%5.1f'% (50.*i), anchor=E)

scaled = []

# MDD Added this code to generate potentially lots of data points
for i in range(10):
    x, y = i, i
    x = x + 100
    y = 50 + y
    scaled.append((x,y))

"""  I am not interested in this.
scaled = []
for x,y in [(12, 56), (20, 94), (33, 98), (45, 120), (61, 180),
            (75, 160), (98, 223)]:
    scaled.append((100 + 3*x, 250 - (4*y)/5))
"""

canvas.create_line(scaled, fill='royalblue')

"""  I am not interested in this.
for x,y in scaled:
    canvas.create_oval(x-6,y-6,x+6,y+6, width=1,
                       outline='black', fill='SkyBlue2')
"""

root.mainloop()

 ---------------------------------------------------------------------------
 ---------------------------------------------------------------------------

From help@python.org  Thu Sep 14 09:38:40 2000
From: help@python.org (Martin von Loewis)
Date: Thu, 14 Sep 2000 10:38:40 +0200 (MET DST)
Subject: [Python-Help] forwarded message from Michele De La Pena
In-Reply-To: <200009132153.RAA20628@enkidu.stsci.edu> (delapena@stsci.edu)
References: <200009132153.RAA20628@enkidu.stsci.edu>
Message-ID: <200009140838.KAA28807@pandora.informatik.hu-berlin.de>

> I will check the items you suggest below, but I you have my help 
> message confused with someone else's message. 

My fault, I indeed confused your message with somebody elses. Looking
at your original message, I can certainly reproduce the problem you
are seeing. Tkinter has not been tested much for 2.0, except that IDLE
is based on it - but that does not involve Canvases.

It is not really your duty to find the cause of the problem, as it is
clearly a Python bug. Since we are in beta testing, it would be quite
important to fix it before 2.0 is released. So, if you are willing to
investigate and propose a patch, that would be much
appreciated. Otherwise, submitting a bug report at
http://sourceforge.net/projects/python would be important so that the
bug gets known to all contributors.

Regards,
Martin

P.S. I'm especially troubled by the fact that the interpreter crashes,
it should not crash under any circumstances, normally. A quick check
with gdb shows that it crashes in Solaris' libc.so, specifically in
the memory management. It appears that the heap got corrupted.

enkidu> 
2000 10:38:40 +0200 (MET DST)
Received: (from loewis@localhost)
        by pandora.informatik.hu-berlin.de (8.9.1/8.9.1/SOLARIS-INF-2.0c) id KAA



Follow-Ups:

Date: 2000-Sep-14 10:15
By: loewis

Comment:
This is fixed with patch 
http://sourceforge.net/patch/?func=detailpatch&patch_id=101509&group_id=5470
-------------------------------------------------------

Date: 2000-Sep-14 14:33
By: effbot

Comment:
go ahead and check it in!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114424&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 08:31:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 00:31:53 -0700
Subject: [Python-bugs-list] [Bug #114490] crash on empty module registry key
Message-ID: <200009150731.AAA26878@delerium.i.sourceforge.net>

Bug #114490, was updated on 2000-Sep-15 00:31
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: crash on empty module registry key

Details: Having an empty module path key under the PythonPath Registry key lets Python die on startup.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114490&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 08:40:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 00:40:26 -0700
Subject: [Python-bugs-list] [Bug #114490] crash on empty module registry key
Message-ID: <200009150740.AAA27172@delerium.i.sourceforge.net>

Bug #114490, was updated on 2000-Sep-15 00:31
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: crash on empty module registry key

Details: Having an empty module path key under the PythonPath Registry key lets Python die on startup.

Follow-Ups:

Date: 2000-Sep-15 00:40
By: tim_one

Comment:
Assigned to MarkH and boosted priority.

BobJuner, you didn't say which version of Python you're using.  If you can, please try it with a current snapshot from CVS:  MarkH very recently fixed something similar, and possibly similar enough to be identical.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114490&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 08:44:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 00:44:31 -0700
Subject: [Python-bugs-list] [Bug #113894] os.listdir(driveletter + ":") flawed on Win32
Message-ID: <200009150744.AAA27251@delerium.i.sourceforge.net>

Bug #113894, was updated on 2000-Sep-08 08:55
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 7
Summary: os.listdir(driveletter + ":") flawed on Win32

Details: On windows NT the os.listdir() function doesn't correctly handle paths containing a drive specification, but no other directory spec. It incorrectly references the root directory on the specified drive rather than the current directory.
For example these two calls should return the same thing (the actual output has been slightly trimmed):

>>> import os
>>> os.listdir('c:')
['3DCube', 'Acrobat3', 'ADOBEAPP', ...]
>>> os.listdir('c:.')
['Capture', 'Catalog', ...]

The same problem shows up in os.glob, for example os.glob('d:*.py') will expand to all .py files in the root of drive d rather than the current directory.

One possible fix is that in posixmodule.c, function posix_listdir, the lines:
	strcpy(namebuf, name);
	if (namebuf[len-1] != '/' && namebuf[len-1] != '\\')
		namebuf[len++] = '/';
	strcpy(namebuf + len, "*.*");
should read:
	strcpy(namebuf, name);
	if (namebuf[len-1] != '/' && namebuf[len-1] != '\\' && namebuf[len-1] != ':')
		namebuf[len++] = '/';
	strcpy(namebuf + len, "*.*");


Follow-Ups:

Date: 2000-Sep-12 06:19
By: gangli59

Comment:
The bug show in glob.glob('d:*.py') is due to os.path.join joins 'd:', '*.py' to 'd:\\*.py' instead of 'd:*.py'
-------------------------------------------------------

Date: 2000-Sep-15 00:03
By: tim_one

Comment:
Changed Summary to be clearer.
I've made & tested the change as suggested (thanks!).
SourceForge CVS isn't working at the moment for me, though, so haven't yet checked it in.  Marked Fixed, but not yet Closed.
-------------------------------------------------------

Date: 2000-Sep-15 00:44
By: tim_one

Comment:
Checked in changes to posixmodule.c, and Closed.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113894&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 09:14:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 01:14:30 -0700
Subject: [Python-bugs-list] [Bug #110845] struct.pack not being very picky (PR#52)
Message-ID: <200009150814.BAA28269@delerium.i.sourceforge.net>

Bug #110845, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 5
Summary: struct.pack not being very picky (PR#52)

Details: Jitterbug-Id: 52
Submitted-By: da@ski.org
Date: Sun, 15 Aug 1999 17:52:20 -0400 (EDT)
Version: 1.5.2
OS: NT4SP3


>>> from struct import *
>>> struct.pack('B', -12)
'\364'

I expected a ValueError, the way:

>>> struct.pack('c', 123)
Traceback (innermost last):
  File "<stdin>", line 1, in ?
struct.error: char format require string of length 1

works.




====================================================================
Audit trail:
Mon Aug 30 12:33:11 1999	guido	moved from incoming to request

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110845&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 10:34:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 02:34:11 -0700
Subject: [Python-bugs-list] [Bug #110650] python with-threads core-dumps (PR#342)
Message-ID: <200009150934.CAA13098@bush.i.sourceforge.net>

Bug #110650, was updated on 2000-Jul-31 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: python with-threads core-dumps (PR#342)

Details: Jitterbug-Id: 342
Submitted-By: michael.exner@mrz.uni-magdeburg.de
Date: Wed, 31 May 2000 09:43:38 -0400 (EDT)
Version: 1.5.2
OS: hpux-11.00


When I compile python with threads python core-dumps:
$ ./python
pthread_mutex_init: Invalid argument
Memory fault(coredump)
without thread-support everything works fine
I tried this with hpux-ansi-c and with gcc (2.95.2) but got the same result




====================================================================
Audit trail:
Tue Jul 11 08:25:57 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-28 20:43
By: tim_one

Comment:
Note that the only call to pthread_mutex_init Python makes is in function PyThread_allocate_lock in file phread_pthread.h.  If Python compiled at all, it's extremely unlikely that the first argument is in error.  It's very likely that the second argument is in error, though:  there were many imcompatible revisions of the pthreads std, and pthread_mutexattr_default is a macro conditionally defined near the top of the file.  If this OS actually support pthreads, you have to figure out which *version* of pthreads it defines and arrange for config to define the *correct* one of the

PY_PTHREAD_D4
PY_PTHREAD_D7
PY_PTHREAD_STD
PY_PTHREAD_D6

symbols for your platform.  Else disable threads entirely.
-------------------------------------------------------

Date: 2000-Aug-29 07:34
By: memaul

Comment:
Goto link below for instructions and patches for building
python 152 with threads on hpux 10.20

http://memaul.tripod.com/index.html
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-15 02:34
By: harripasanen

Comment:
I can verify that the bug exists not only in 1.5.2 but also in 1.6.

gcc 2.95.2
HPUX 11.00

I'll see if tim_one's suggestions help.

Regards,

Harri Pasanen
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110650&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 12:55:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 04:55:42 -0700
Subject: [Python-bugs-list] [Bug #110650] python with-threads core-dumps (PR#342)
Message-ID: <200009151155.EAA18275@bush.i.sourceforge.net>

Bug #110650, was updated on 2000-Jul-31 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: python with-threads core-dumps (PR#342)

Details: Jitterbug-Id: 342
Submitted-By: michael.exner@mrz.uni-magdeburg.de
Date: Wed, 31 May 2000 09:43:38 -0400 (EDT)
Version: 1.5.2
OS: hpux-11.00


When I compile python with threads python core-dumps:
$ ./python
pthread_mutex_init: Invalid argument
Memory fault(coredump)
without thread-support everything works fine
I tried this with hpux-ansi-c and with gcc (2.95.2) but got the same result




====================================================================
Audit trail:
Tue Jul 11 08:25:57 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-28 20:43
By: tim_one

Comment:
Note that the only call to pthread_mutex_init Python makes is in function PyThread_allocate_lock in file phread_pthread.h.  If Python compiled at all, it's extremely unlikely that the first argument is in error.  It's very likely that the second argument is in error, though:  there were many imcompatible revisions of the pthreads std, and pthread_mutexattr_default is a macro conditionally defined near the top of the file.  If this OS actually support pthreads, you have to figure out which *version* of pthreads it defines and arrange for config to define the *correct* one of the

PY_PTHREAD_D4
PY_PTHREAD_D7
PY_PTHREAD_STD
PY_PTHREAD_D6

symbols for your platform.  Else disable threads entirely.
-------------------------------------------------------

Date: 2000-Aug-29 07:34
By: memaul

Comment:
Goto link below for instructions and patches for building
python 152 with threads on hpux 10.20

http://memaul.tripod.com/index.html
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-15 02:34
By: harripasanen

Comment:
I can verify that the bug exists not only in 1.5.2 but also in 1.6.

gcc 2.95.2
HPUX 11.00

I'll see if tim_one's suggestions help.

Regards,

Harri Pasanen
-------------------------------------------------------

Date: 2000-Sep-15 04:55
By: harripasanen

Comment:
The problems seems to be that configure gets the libraries wrong on HP-UX 11.0.   It links with -lcma, when it should link with -lpthread.

So a quick and dirty solution is to relink the python by hand, replacing -lcma with -lpthread.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110650&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 14:28:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 06:28:25 -0700
Subject: [Python-bugs-list] [Bug #110856] Page fault in module KERNEL32.DLL (PR#186)
Message-ID: <200009151328.GAA21530@bush.i.sourceforge.net>

Bug #110856, was updated on 2000-Aug-01 14:37
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Invalid
Bug Group: Irreproducible
Priority: 5
Summary: Page fault in module KERNEL32.DLL (PR#186)

Details: Jitterbug-Id: 186
Submitted-By: hauser@eos.ncsu.edu
Date: Fri, 21 Jan 2000 08:36:26 -0500 (EST)
Version: 1.5.2
OS: windows 95


I am new to Python and am having a problem on Windows 95 any time I use the
Tkinter module. An example follows:

>>>from Tkinter import *
>>>t = Button(None, {'text': 'Test', Pack: {}})
>>>q = Button(None, {'text': 'Quit', 'command': t.quit, Pack: {}})
>>>t.mainloop()

The window comes up and seems to work. Clicking on the 'Quit' button returns to
the Python screen.  Then:
>>>Ctrl-D    ->message comes up that illegal operation has been perforned:

Page fault in KERNEL32.DLL at 016f:6ff79ff3, computer hangs and has to be hard 
booted.
Everything else seems to work, the idle program comes up and everything is OK 
until I try to exit and the same problem happens.  If I don't use Tkinter I
don't have the problem and any time with Tkinter I make a window and exit from 
the window, and try to exit Python the same error appears.
I have found several references to Page faults in KERNEL32 in the Bug reports 
but have not seen any solutions.  Any help would be appreciated.  Thanks.




====================================================================
Audit trail:
Mon Jan 24 14:47:52 2000	guido	sent reply 1
Mon Jan 24 14:48:23 2000	guido	changed notes
Mon Jan 24 14:48:23 2000	guido	moved from incoming to irreproducible

Follow-Ups:

Date: 2000-Aug-01 14:38
By: none

Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: Page fault in module KERNEL32.DLL (PR#186)
Date: Mon Jan 24 14:47:52 2000

John,

I am afraid I can't reproduce your problem, and I've never heard
of this type of behavior before.

My best guess is that some other Windows app that you have installed
is causing this behavior; this is basically impossible to debug.

I suggest that you post your problem description to comp.lang.python;
maybe someone there has a clever idea.  If you find a solution, please
reply to this message, leaving the subject intact.

In the mean time, I;ll keep your bug report in the "irreproducuble"
category.

Thanks,

--Guido van Rossum

-------------------------------------------------------

Date: 2000-Aug-01 14:38
By: none

Comment:
From: "Dr. John R. Hauser" <hauser@eos.ncsu.edu>
Subject: Re: Page fault in module KERNEL32.DLL (PR#186)
Date: Thu, 27 Jan 2000 15:34:33 -0500

Guido,

Thanks very much for your help.  With your suggestion I have traced the
problem to a file CSINJECT.exe which was being loaded on startup.  This is
a file associated with the Norton Clean Sweep utility.  After removing it
from my startup file, everything works fine.  I guess it was loaded when I
installed Norton Utilities and I have no idea what it does.  

Thanks again for you thoughts.

John Hauser


At 02:47 PM 1/24/2000 -0500, you wrote:
>John,
>
>I am afraid I can't reproduce your problem, and I've never heard
>of this type of behavior before.
>
>My best guess is that some other Windows app that you have installed
>is causing this behavior; this is basically impossible to debug.
>
>I suggest that you post your problem description to comp.lang.python;
>maybe someone there has a clever idea.  If you find a solution, please
>reply to this message, leaving the subject intact.
>
>In the mean time, I;ll keep your bug report in the "irreproducuble"
>category.
>
>Thanks,
>
>--Guido van Rossum
>
>
>


-------------------------------------------------------

Date: 2000-Aug-01 14:38
By: none

Comment:
Could be caused by another Windows app?
-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-15 06:28
By: jhylton

Comment:
see final comment from submittor
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110856&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 16:02:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 08:02:56 -0700
Subject: [Python-bugs-list] [Bug #113812] Serious garbage collection problems with 2.0b1
Message-ID: <200009151502.IAA10719@delerium.i.sourceforge.net>

Bug #113812, was updated on 2000-Sep-07 10:10
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 8
Summary: Serious garbage collection problems with 2.0b1

Details: Since I've installed version 2.0b1, I ran into a few (serious) problems
with a non-trivial application (+80,000 lines of Python). It seems that
the are all related to the new garbage collection:

 - Suddenly, assertions fail because lists have become empty 
   while they shouldn't have. I looks like their elements have been
   garbage collected while they were still reachable.

 - Under other circumstances, I get coredumps which always 
   seem to happen in function "move_root_reachable" of gcmodule.c:
   the "traverse" function pointer seems to contain a bogus address.

 - When I run a Purified version of the interpreter, I can't reproduce
   either problem, but instead, the garbage collector seems to get
   stuck in an endless loop each time. This always happens in the
   same function "move_root_reachable". Purify doesn't produce any 
   relevant warning.

The code runs just fine with version 1.6 of the interpreter, or when I
disable the garbage collector.

Probably relevant is the fact that the objects (10,000's) in my application
are very heavily cross-linked (nearly all links are bi-directional), which 
probably puts a lot of stress on the garbage collector.

My platform: HP-UX 10.20 / c89 compiler


Follow-Ups:

Date: 2000-Sep-07 10:14
By: edg

Comment:
Just one more thing: when I turn on the gc debugging,
the interpreter also seems to get stuck in an endless loop.
-------------------------------------------------------

Date: 2000-Sep-07 14:41
By: jhylton

Comment:
If you set the GC threshold to 0, 
import gc
gc.set_threshold(0)

Do you get the same problem?  Not that I doubt there is some sort of gc problem, but I wonder if there is something going wrong in the accounting or in the collection.

How hard would it be for someone to try to reproduce this bug?  Obviously, it would be helpful to get a smaller test case that has the same behavior as your large program and also tickles the bug.

Do you have any C extension modules in your application or is it pure Python?
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 01:33
By: edg

Comment:
The code is 100% pure Python. 
When I set the threshold to 0, the problem doesn't occur.

The problem is probably very hard to reproduce by anyone else.
The slightest change in the input data for my application
can make the problem go away. Even running an optimized instead
of a debug version of the interpreter can make a difference.

I'm certainly going to try to strip it down, but that won't be 
easy (the same application, using other input data, running 
6 times as long, runs just fine).
-------------------------------------------------------

Date: 2000-Sep-11 07:48
By: edg

Comment:
After 2 full days of debugging, I think that I finally found the 
cause for the gc problems.

To keep a (very) long story short, what I found out was the following:

 - Crashes were due to objects that were destructed twice.
 
 - Endless loops were due to messed-up gc generation lists. The lists should
   always remain perfectly circular, but sometimes they ended up like this:

   list <-> ... <-> X <-> ... <-> ... -> X   

   No wonder that the gc code could easily get stuck; even turning on
   gc debugging caused the counting code to run in circles forever.
   
   The multiple-destruction problem is almost certainly caused by lists being
   messed up.
   
By turning on the debugging code in gc_list_remove and reducing the gc
threshold to a very small value, I could trigger the crash more
reliably, which allowed me to strip down my 80000 line application to this:

-----------------------------------------------------------------------------
#
# Note: to trigger a crash reliably, the debugging code in gc_list_remove
#       _must_ be turned on.
#
import gc
gc.set_threshold(1)

class Node:
   
   def __del__(self):
      dir(self)
 
a = Node()
del a # -> Crash
-----------------------------------------------------------------------------

You wonder: can it be that simple ? :-)

This is what happens when the Node instance `a' is destructed:

 1) The Node instance is removed from the gc lists.
 2) An instance method is created due to the call of the __del__ method.
    THAT METHOD CREATES A NEW REFERENCE TO THE INSTANCE !
 3) The code in the __del__ method triggers the allocation of new
    objects and because the gc threshold has been set very low, it also
    triggers a gc run. 
 4) During the gc run, the instance method is encountered and its reachable
    objects are visited.
 5) Since the instance is referenced by the method, the gc code tries to move
    the instance to another list, while it was no longer present in any list
    -> BINGO

Obviously, the reason why this problem was so hard to reproduce, is the fact
that most classes don't have a __del__ method, and the problem only occurs
when a gc run happens during the execution of a __del__ method.

It think the fix is as simple as this (I'm not too confident, but it 
seems to work):
------------------------------------------------------------------------------
*** Objects/classobject.c.orig	Mon Sep 11 15:55:03 2000
--- Objects/classobject.c	Mon Sep 11 16:12:26 2000
***************
*** 490,496 ****
  #ifdef Py_TRACE_REFS
  	extern long _Py_RefTotal;
  #endif
- 	PyObject_GC_Fini(inst);
  	/* Call the __del__ method if it exists.  First temporarily
  	   revive the object and save the current exception, if any. */
  #ifdef Py_TRACE_REFS
--- 490,495 ----
***************
*** 523,529 ****
  #ifdef COUNT_ALLOCS
  		inst->ob_type->tp_free--;
  #endif
- 		PyObject_GC_Init((PyObject *)inst);
  		return; /* __del__ added a reference; don't delete now */
  	}
  #ifdef Py_TRACE_REFS
--- 522,527 ----
***************
*** 537,542 ****
--- 535,541 ----
  #endif /* Py_TRACE_REFS */
  	Py_DECREF(inst->in_class);
  	Py_XDECREF(inst->in_dict);
+ 	PyObject_GC_Fini(inst);
  	inst = (PyInstanceObject *) PyObject_AS_GC(inst);
  	PyObject_DEL(inst);
  }
------------------------------------------------------------------------------

ie, delay the removal from the gc list till everything has stabilized.

I hope this helps.


-------------------------------------------------------

Date: 2000-Sep-14 23:43
By: nascheme

Comment:
Your analysis looks correct.  Great work.  I think there is a small problem with your fix however.  You should call PyObject_GC_Fini() before the DECREFs on in_class and in_dict.  If, for some reason, decrementing the reference counts of these object causes a garbage collection then the instance could still be on the gc lists and have an invalid in_class or in_dict pointer.
-------------------------------------------------------

Date: 2000-Sep-15 08:02
By: nascheme

Comment:
I've posted a patch.  Should I mark this bug as fixed or does whoever checks in the patch make that change?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113812&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 16:10:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 08:10:39 -0700
Subject: [Python-bugs-list] [Bug #110607] Telnet close (PR#181)
Message-ID: <200009151510.IAA11106@delerium.i.sourceforge.net>

Bug #110607, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Works For Me
Bug Group: Irreproducible
Priority: 5
Summary: Telnet close (PR#181)

Details: Jitterbug-Id: 181
Submitted-By: cha@tandberg.no
Date: Wed, 12 Jan 2000 09:49:29 -0500 (EST)
Version: 1.5.2
OS: Windows NT4.0


The telnet.close() object does not close the telnet session.
Session will only be closed after a timeout on the remote side.

 



====================================================================
Audit trail:
Wed Jan 12 18:29:38 2000	guido	changed notes
Wed Jan 12 18:29:38 2000	guido	changed notification
Wed Jan 12 18:29:38 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-23 18:50
By: montanaro

Comment:
Replied to the submitter asking for a short script that fails.  I don't run Windows so I may not be able to track
this down.

-------------------------------------------------------

Date: 2000-Sep-04 07:54
By: montanaro

Comment:
Never did get any response from the submitter.  This was
apparently originally submitted back in January.  I'm simply going to bounce this back to Tim since he at least runs Windows...

-------------------------------------------------------

Date: 2000-Sep-14 22:23
By: tim_one

Comment:
Assigned to Guido, cause it looks like telnetlib.py may be his code, he also has Windows, and-- unlike me --may actually know of a machine he can telnet *to* (I've never used this stuff, & the BeOpen machines don't telnet for me).  The .close() method certainly appears to be closing the underlying socket.

-------------------------------------------------------

Date: 2000-Sep-15 08:10
By: gvanrossum

Comment:
Best I can tell, the connection is correctly closed by the close() method.
I telnetted into a Unix machine from a Win98 SE machine (I have no NT here) and checked with netstat that the connection existed. Then I called the close() method. Then netstat showed the connection as closed for about 1 second and then no longer had it.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110607&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 16:15:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 08:15:10 -0700
Subject: [Python-bugs-list] [Bug #114293] Unexpected Evaluation of Expressions from Pickle
Message-ID: <200009151515.IAA26254@bush.i.sourceforge.net>

Bug #114293, was updated on 2000-Sep-12 15:23
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Unexpected Evaluation of Expressions from Pickle

Details: It is possible to evaluate an expression through an improperly formatted pickled string:

    >>> import pickle 
    >>> pickle.loads("S3+3\012p0\012.")
    6

The same expression in "cPickle" will raise an exception: 

    >>> import cPickle
    >>> cPickle.loads("S3+3\012p0\012.")
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ValueError: insecure string pickle

The reason this occurs is that the string is brought into existence through a call to "eval".  This is made somewhat safe by removing all the built-in functions, but it is still possible to cause problems with a pure evaluation.  I will submit a patch within a few minutes that makes sure that the first character is either a single- or double-quote.

Would it be possible for someone to slip a code object instead of an expression?  Since we don't have access to the "marshal" module from here, I don't know how it would be done, but I am very concerned about the security implications of using pickle.

Follow-Ups:

Date: 2000-Sep-15 08:15
By: jhylton

Comment:
fixed in rev. 1.39
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114293&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 16:34:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 08:34:26 -0700
Subject: [Python-bugs-list] [Bug #110617] IDLE and -t (PR#213)
Message-ID: <200009151534.IAA11954@delerium.i.sourceforge.net>

Bug #110617, was updated on 2000-Jul-31 14:06
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 3
Summary: IDLE and -t (PR#213)

Details: Jitterbug-Id: 213
Submitted-By: aa8vb@yahoo.com
Date: Fri, 25 Feb 2000 07:36:01 -0500 (EST)
Version: 1.5.2 (w/ IDLE 0.5)
OS: IRIX


Since no other X app I know of works this way, I think this is a bug.

If you set the title of the IDLE window:

     idle.py -t IDLE

the title is set correctly, but the icon name is not.
It is set to "*IDLE" rather than "IDLE".




====================================================================
Audit trail:
Tue Mar 07 14:41:55 2000	guido	changed notes
Tue Mar 07 14:41:55 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Fri, 25 Feb 2000 08:26:32 -0500

> Since no other X app I know of works this way, I think this is a bug.
> 
> If you set the title of the IDLE window:
> 
>      idle.py -t IDLE
> 
> the title is set correctly, but the icon name is not.
> It is set to "*IDLE" rather than "IDLE".

Not a bug -- IDLE adds * before (and after!) the window title and
icon name to indicate that the window is modified and unsaved.

Does this bother you in some way?

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Randall Hopper <aa8vb@yahoo.com>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Mon, 28 Feb 2000 07:25:31 -0500

Guido van Rossum:
 |> Since no other X app I know of works this way, I think this is a bug.
 |> 
 |> If you set the title of the IDLE window:
 |> 
 |>      idle.py -t IDLE
 |> 
 |> the title is set correctly, but the icon name is not.
 |> It is set to "*IDLE" rather than "IDLE".
 |
 |Not a bug -- IDLE adds * before (and after!) the window title and
 |icon name to indicate that the window is modified and unsaved.

The icon name doesn't follow this convention:

        if not self.get_saved():            
            title = "*%s*" % title
            icon = "*%s" % icon

The reason I took note of this inconsistency is that I was assigning a
window manager icon to IDLE based on the startup icon string.

 |Does this bother you in some way?

Well, no other X app I know of communicates unsaved status by putting '*'s
in the title and icon, but I don't have a big problem with it.  

I do think the icon should have a '*' both before "and after", as you
described though.  I'm guessing this was just a typo.

Thanks,

Randall

-- 
Randall Hopper
aa8vb@yahoo.com


-------------------------------------------------------

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Mon, 28 Feb 2000 08:16:48 -0500

>  |Not a bug -- IDLE adds * before (and after!) the window title and
>  |icon name to indicate that the window is modified and unsaved.
> 
> The icon name doesn't follow this convention:
> 
>         if not self.get_saved():            
>             title = "*%s*" % title
>             icon = "*%s" % icon
> 
> The reason I took note of this inconsistency is that I was assigning a
> window manager icon to IDLE based on the startup icon string.
> 
>  |Does this bother you in some way?
> 
> Well, no other X app I know of communicates unsaved status by putting '*'s
> in the title and icon, but I don't have a big problem with it.  

Hm, I have to admit that I have given up years ago on configuring X
apps through their app name.  Is that still a common practice?  I could
certainly change things around so that the title and icon are always "idle:
*file*" or "idle: file" depending on saved status.

> I do think the icon should have a '*' both before "and after", as you
> described though.  I'm guessing this was just a typo.

I think it was intentional, trying to save some space in the icon
label.  Not worth it, probably.

--Guido van Rossum (home page: http://www.python.org/~guido/)



-------------------------------------------------------

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Randall Hopper <aa8vb@yahoo.com>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Tue, 29 Feb 2000 14:26:37 -0500


--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii

Guido van Rossum:
 |Hm, I have to admit that I have given up years ago on configuring X
 |apps through their app name.  Is that still a common practice?  I could

Definitely.  Most all (all?) use WM_CLASS, and many use WM_NAME and
WM_ICONNAME as fallbacks.  This is useful if WM_CLASS isn't set to a useful
value (as in this case).

IDLE doesn't set a class name property on it's window, so the window name
and icon name are all the window manager has to go on when matching it up
with configuration settings.

However, I believe IDLE could set a class name easily by passing it to
Tkinter -- e.g.  root = Tk( className="IDLE" ).  See attached.

More info: the properties used by many window managers as a key into a
configuration database are: CLASS, NAME, and ICON_NAME.  For example,
running 'xprop' on my xterm window here:

   > xprop
   ...
   WM_CLASS(STRING) = "xterm-color", "XTerm"
   ...
   WM_ICON_NAME(STRING) = "Local"
   WM_NAME(STRING) = "Local"

So I can set window manager resources for this window using "XTerm",
"xterm-color", or "Local" -- with overrides in that order I believe.
So I can have a default icon for xterms, and then an override icon for
xterm windows with a certain title.

IDLE doesn't set CLASS so it's basically useless for this configuration
purpose.  On stock IDLE:

   WM_CLASS(STRING) = "270515832", "Toplevel"

 |certainly change things around so that the title and icon are always "idle:
 |*file*" or "idle: file" depending on saved status.

If IDLE could set WM_CLASS to a static (or cmd-line-specified) value on
it's shell windows, that'd be enough for me.  For now I'm using -t IDLE,
but that doesn't cover opening new windows inside of IDLE (opening files,
File->New Window, etc.)

A unique prefix on the WM_NAME (title string) would work too.

 |> I do think the icon should have a '*' both before "and after", as you
 |> described though.  I'm guessing this was just a typo.
 |
 |I think it was intentional, trying to save some space in the icon
 |label.  Not worth it, probably.

Thanks,

Randall


-- 
Randall Hopper
aa8vb@yahoo.com

--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="tk.py"

from Tkinter import *
root = Tk( className="Test" )
btn = Button( root )
btn.pack()
root.mainloop()

--oyUTqETQ0mS9luUI--


-------------------------------------------------------

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Wed, 01 Mar 2000 09:21:41 -0500

Randall,

Thanks for your enlightenment.  I looked at your example, and it
works; but I need more, because IDLE creates windows using Toplevel(),
not using Tk().  (Using Tk() would create a new Tcl interpreter for
each window, which wastes time and memory resources, and re-reads the
~/.<whatever>.py file each time.)

I've experimented with xprop a bit, and I'm not getting results I
like.  If I write root = Tk(className="foo"), WM_CLASS is "foo",
"Foo".  Them if I write top = Toplevel(root), WM_CLASS for that window
is "1234567", "Toplevel".  If I try top = Toplevel(root, name="bar"),
I get "bar", "Toplevel".  Shouldn't I be able to set the second
component of WM_CLASS somehow?

Got any ideas?

If you can send me a patch, that would be greatly appreciated!

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Randall Hopper <aa8vb@yahoo.com>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Mon, 6 Mar 2000 08:50:29 -0500


--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii

Guido van Rossum:
 |Thanks for your enlightenment.  I looked at your example, and it
 |works; but I need more, because IDLE creates windows using Toplevel(),
 |not using Tk().  (Using Tk() would create a new Tcl interpreter for
 |each window, which wastes time and memory resources, and re-reads the
 |~/.<whatever>.py file each time.)
 |
 |I've experimented with xprop a bit, and I'm not getting results I
 |like.  If I write root = Tk(className="foo"), WM_CLASS is "foo",
 |"Foo".  Them if I write top = Toplevel(root), WM_CLASS for that window
 |is "1234567", "Toplevel".  If I try top = Toplevel(root, name="bar"),
 |I get "bar", "Toplevel".  Shouldn't I be able to set the second
 |component of WM_CLASS somehow?
 |
 |Got any ideas?

Sorry about that last message.  This issue is very closely related to the
resource loading issue on idle-dev, but not the same.  Once the small
change below is in-place (to solve this problem), the platform-independent
Tkinter methods for resource loading can be used to solve the idle-dev
problem, if desired.

Research indicates that the Tk-ism for setting Toplevel classes is:

      "toplevel .mytop -class classname"

So the Tkinter syntax is:

      top1   = Toplevel( root, class_=classname )

The attached test app demonstrates this.  I verified that I am able to set
X resources for these windows using the class name "Idle".

-- 
Randall Hopper
aa8vb@yahoo.com

--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="tk_class.py"

from Tkinter import *

CLASSNAME = "Idle"

root = Tk( className=CLASSNAME )
root.wm_withdraw()

# A toplevel with a WM_CLASS
top1   = Toplevel( root, class_=CLASSNAME )
label1 = Label( top1, text="Toplevel 1" )
label1.pack()

# Another one
top2   = Toplevel( root, class_=CLASSNAME )
label2 = Label( top2, text="Toplevel 2" )
label2.pack()

root.mainloop()

--MGYHOYXEY6WxJCY8--


-------------------------------------------------------

Date: 2000-Jul-31 14:06
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] IDLE and -t (PR#213)
Date: Mon, 06 Mar 2000 09:11:30 -0500

> Sorry about that last message.  This issue is very closely related to the
> resource loading issue on idle-dev, but not the same.  Once the small
> change below is in-place (to solve this problem), the platform-independent
> Tkinter methods for resource loading can be used to solve the idle-dev
> problem, if desired.

See my response in idle-dev :-)

Of course the Tk options can still be used for changing things that
the config file or prefs dialog doesn't support.

> Research indicates that the Tk-ism for setting Toplevel classes is:
> 
>       "toplevel .mytop -class classname"
> 
> So the Tkinter syntax is:
> 
>       top1   = Toplevel( root, class_=classname )
> 
> The attached test app demonstrates this.  I verified that I am able to set
> X resources for these windows using the class name "Idle".

OK, I'll try to support this!

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 22:29
By: tim_one

Comment:
Assigned to Guido for obvious reasons.
-------------------------------------------------------

Date: 2000-Sep-15 08:34
By: gvanrossum

Comment:
The original complaint (about the icon being set to *IDLE) was taken care of by explanation. The remaining issue of the proper className is taken care of by using Tk(className="Idle") in PyShell.py -- Fred just checked this in.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110617&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 16:46:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 08:46:26 -0700
Subject: [Python-bugs-list] [Bug #110660] IDLE-0.5  ctrl-F5 (PR#355)
Message-ID: <200009151546.IAA12489@delerium.i.sourceforge.net>

Bug #110660, was updated on 2000-Jul-31 14:11
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 3
Summary: IDLE-0.5  ctrl-F5 (PR#355)

Details: Jitterbug-Id: 355
Submitted-By: gpk@bell-labs.com
Date: Tue, 13 Jun 2000 11:30:14 -0400 (EDT)
Version: yesterday's CVS
OS: Solaris 2.6


If you type ctrl-f5 to run a script twice in sucession,
IDLE will incorrectly pop up a window saying
"Not Saved.  Please Save First."

If you save (even though you haven't changed anything,
and even though there are no asterisks around the window
title), then ctrl-f5 will work again.

This *doesn't* happen if you run the script twice in
succession from the menu.



====================================================================
Audit trail:
Tue Jul 11 08:26:00 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] IDLE-0.5  ctrl-F5 (PR#355)
Date: Tue, 13 Jun 2000 11:55:09 -0400

Pretty mysterious!  Doesn't happen under IDLE 0.5 for me.  Running under
Windows, but darned hard to see why that would matter.  Can anyone else try
this under Solaris 2.6?  May have something to do with the specific script
you're running, Greg; e.g., does it happen if the script file contains just

print "Hi!"

?

> -----Original Message-----
> From: python-bugs-list-admin@python.org
> [mailto:python-bugs-list-admin@python.org]On Behalf Of gpk@bell-labs.com
> Sent: Tuesday, June 13, 2000 11:30 AM
> To: python-bugs-list@python.org
> Cc: bugs-py@python.org
> Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355)
>
>
> Full_Name: Greg Kochanski
> Version: yesterday's CVS
> OS: Solaris 2.6
> Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130)
>
>
> If you type ctrl-f5 to run a script twice in sucession,
> IDLE will incorrectly pop up a window saying
> "Not Saved.  Please Save First."
>
> If you save (even though you haven't changed anything,
> and even though there are no asterisks around the window
> title), then ctrl-f5 will work again.
>
> This *doesn't* happen if you run the script twice in
> succession from the menu.
>
>
>
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list
>




-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355)
Date: Tue, 20 Jun 2000 16:42:57 -0500

I think I understand this.  It's happened to me too.  Pressing ^F5
changes the focus to the PyShell window.  Pressing ^F5 again then
indeed complains about that window being unsaved.

--Guido van Rossum (home page: http://www.python.org/~guido/)

[Tim]
> Pretty mysterious!  Doesn't happen under IDLE 0.5 for me.  Running under
> Windows, but darned hard to see why that would matter.  Can anyone else try
> this under Solaris 2.6?  May have something to do with the specific script
> you're running, Greg; e.g., does it happen if the script file contains just
> 
> print "Hi!"
> 
> ?
> 
> > -----Original Message-----
> > From: python-bugs-list-admin@python.org
> > [mailto:python-bugs-list-admin@python.org]On Behalf Of gpk@bell-labs.com
> > Sent: Tuesday, June 13, 2000 11:30 AM
> > To: python-bugs-list@python.org
> > Cc: bugs-py@python.org
> > Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355)
> >
> >
> > Full_Name: Greg Kochanski
> > Version: yesterday's CVS
> > OS: Solaris 2.6
> > Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130)
> >
> >
> > If you type ctrl-f5 to run a script twice in sucession,
> > IDLE will incorrectly pop up a window saying
> > "Not Saved.  Please Save First."
> >
> > If you save (even though you haven't changed anything,
> > and even though there are no asterisks around the window
> > title), then ctrl-f5 will work again.
> >
> > This *doesn't* happen if you run the script twice in
> > succession from the menu.
> >
> >
> >
> > _______________________________________________
> > Python-bugs-list maillist  -  Python-bugs-list@python.org
> > http://www.python.org/mailman/listinfo/python-bugs-list
> >
> 
> 
> 
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Greg Kochanski <gpk@bell-labs.com>
Subject: Re: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355)
Date: Tue, 20 Jun 2000 17:25:37 -0400

Guido van Rossum wrote:
> 
> I think I understand this.  It's happened to me too.  Pressing ^F5
> changes the focus to the PyShell window.  Pressing ^F5 again then
> indeed complains about that window being unsaved.
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)

Ah. Sure enough.   Perhaps the best thing to do
is just to have the little error message explain
which window is unsaved.  Include the title
of the unsaved window in the error box, maybe.

I'd be happy to send a patch, but the paperwork
would be terrible...


-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355)
Date: Tue, 20 Jun 2000 18:10:35 -0500

> > I think I understand this.  It's happened to me too.  Pressing ^F5
> > changes the focus to the PyShell window.  Pressing ^F5 again then
> > indeed complains about that window being unsaved.
> > 
> > --Guido van Rossum (home page: http://www.python.org/~guido/)
> 
> Ah. Sure enough.   Perhaps the best thing to do
> is just to have the little error message explain
> which window is unsaved.  Include the title
> of the unsaved window in the error box, maybe.
> 
> I'd be happy to send a patch, but the paperwork
> would be terrible...

No need for paperwork, just the disclaimer text.

But I think the better patch would be to make PyShell a special case
and make it rerun the last window that had the focus.

--Guido van Rossum (home page: http://www.python.org/~guido/)



-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 22:54
By: tim_one

Comment:
Assigned to Guido.  Guido, know whether he ever mailed you a patch?
-------------------------------------------------------

Date: 2000-Sep-15 08:46
By: gvanrossum

Comment:
I added the filename to the error message as proposed.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110660&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 17:38:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 09:38:24 -0700
Subject: [Python-bugs-list] [Bug #113693] freeze modulefinder broken
Message-ID: <200009151638.JAA29298@bush.i.sourceforge.net>

Bug #113693, was updated on 2000-Sep-06 05:09
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: freeze modulefinder broken

Details: The following one-liner script can not be frozen:

import string

The traceback is included below. Line number are from revision 1.13 of modulefinder.py.

The problem appears to be related to recent changes to the import bytecodes

Traceback (most recent call last):
  File "d:\python\tools\freeze\freeze.py", line 457, in ?
    main()
  File "d:\python\tools\freeze\freeze.py", line 321, in main
    mf.import_hook(mod)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 281, in scan_code
    self.import_hook(name, m)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 281, in scan_code
    self.import_hook(name, m)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 303, in scan_code
    self.scan_code(c, m)
  File "d:\python\tools\freeze\modulefinder.py", line 281, in scan_code
    self.import_hook(name, m)
  File "d:\python\tools\freeze\modulefinder.py", line 106, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "d:\python\tools\freeze\modulefinder.py", line 147, in find_head_package
    q = self.import_module(head, qname, parent)
  File "d:\python\tools\freeze\modulefinder.py", line 233, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "d:\python\tools\freeze\modulefinder.py", line 261, in load_module
    self.scan_code(co, m)
  File "d:\python\tools\freeze\modulefinder.py", line 289, in scan_code
    assert lastname is not None
AssertionError

Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 05:10
By: jackjansen

Comment:
The problem is that the code expects IMPORT_NAME immedeately followed by
a sequence of IMPORT_FROMs. That has changed now that IMPORT_FROM
puts the result on the stack.

A fix that appears to work for me is to set lastname to None only on POP_TOP
instructions. But I'll leave doing the actual fix to someone more knowledgeable than
me on the code that from x import y can generate.
-------------------------------------------------------

Date: 2000-Sep-14 23:03
By: tim_one

Comment:
Changed to Category "demos and tools" and assigned to Guido because I bet he'd simply enjoy fixing this one (think of it as a chance to work on Python, Guido!).
-------------------------------------------------------

Date: 2000-Sep-15 09:38
By: gvanrossum

Comment:
Fixed. See checkin of modulefinder.py.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113693&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 17:55:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 09:55:09 -0700
Subject: [Python-bugs-list] [Bug #113812] Serious garbage collection problems with 2.0b1
Message-ID: <200009151655.JAA15087@delerium.i.sourceforge.net>

Bug #113812, was updated on 2000-Sep-07 10:10
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 8
Summary: Serious garbage collection problems with 2.0b1

Details: Since I've installed version 2.0b1, I ran into a few (serious) problems
with a non-trivial application (+80,000 lines of Python). It seems that
the are all related to the new garbage collection:

 - Suddenly, assertions fail because lists have become empty 
   while they shouldn't have. I looks like their elements have been
   garbage collected while they were still reachable.

 - Under other circumstances, I get coredumps which always 
   seem to happen in function "move_root_reachable" of gcmodule.c:
   the "traverse" function pointer seems to contain a bogus address.

 - When I run a Purified version of the interpreter, I can't reproduce
   either problem, but instead, the garbage collector seems to get
   stuck in an endless loop each time. This always happens in the
   same function "move_root_reachable". Purify doesn't produce any 
   relevant warning.

The code runs just fine with version 1.6 of the interpreter, or when I
disable the garbage collector.

Probably relevant is the fact that the objects (10,000's) in my application
are very heavily cross-linked (nearly all links are bi-directional), which 
probably puts a lot of stress on the garbage collector.

My platform: HP-UX 10.20 / c89 compiler


Follow-Ups:

Date: 2000-Sep-07 10:14
By: edg

Comment:
Just one more thing: when I turn on the gc debugging,
the interpreter also seems to get stuck in an endless loop.
-------------------------------------------------------

Date: 2000-Sep-07 14:41
By: jhylton

Comment:
If you set the GC threshold to 0, 
import gc
gc.set_threshold(0)

Do you get the same problem?  Not that I doubt there is some sort of gc problem, but I wonder if there is something going wrong in the accounting or in the collection.

How hard would it be for someone to try to reproduce this bug?  Obviously, it would be helpful to get a smaller test case that has the same behavior as your large program and also tickles the bug.

Do you have any C extension modules in your application or is it pure Python?
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 01:33
By: edg

Comment:
The code is 100% pure Python. 
When I set the threshold to 0, the problem doesn't occur.

The problem is probably very hard to reproduce by anyone else.
The slightest change in the input data for my application
can make the problem go away. Even running an optimized instead
of a debug version of the interpreter can make a difference.

I'm certainly going to try to strip it down, but that won't be 
easy (the same application, using other input data, running 
6 times as long, runs just fine).
-------------------------------------------------------

Date: 2000-Sep-11 07:48
By: edg

Comment:
After 2 full days of debugging, I think that I finally found the 
cause for the gc problems.

To keep a (very) long story short, what I found out was the following:

 - Crashes were due to objects that were destructed twice.
 
 - Endless loops were due to messed-up gc generation lists. The lists should
   always remain perfectly circular, but sometimes they ended up like this:

   list <-> ... <-> X <-> ... <-> ... -> X   

   No wonder that the gc code could easily get stuck; even turning on
   gc debugging caused the counting code to run in circles forever.
   
   The multiple-destruction problem is almost certainly caused by lists being
   messed up.
   
By turning on the debugging code in gc_list_remove and reducing the gc
threshold to a very small value, I could trigger the crash more
reliably, which allowed me to strip down my 80000 line application to this:

-----------------------------------------------------------------------------
#
# Note: to trigger a crash reliably, the debugging code in gc_list_remove
#       _must_ be turned on.
#
import gc
gc.set_threshold(1)

class Node:
   
   def __del__(self):
      dir(self)
 
a = Node()
del a # -> Crash
-----------------------------------------------------------------------------

You wonder: can it be that simple ? :-)

This is what happens when the Node instance `a' is destructed:

 1) The Node instance is removed from the gc lists.
 2) An instance method is created due to the call of the __del__ method.
    THAT METHOD CREATES A NEW REFERENCE TO THE INSTANCE !
 3) The code in the __del__ method triggers the allocation of new
    objects and because the gc threshold has been set very low, it also
    triggers a gc run. 
 4) During the gc run, the instance method is encountered and its reachable
    objects are visited.
 5) Since the instance is referenced by the method, the gc code tries to move
    the instance to another list, while it was no longer present in any list
    -> BINGO

Obviously, the reason why this problem was so hard to reproduce, is the fact
that most classes don't have a __del__ method, and the problem only occurs
when a gc run happens during the execution of a __del__ method.

It think the fix is as simple as this (I'm not too confident, but it 
seems to work):
------------------------------------------------------------------------------
*** Objects/classobject.c.orig	Mon Sep 11 15:55:03 2000
--- Objects/classobject.c	Mon Sep 11 16:12:26 2000
***************
*** 490,496 ****
  #ifdef Py_TRACE_REFS
  	extern long _Py_RefTotal;
  #endif
- 	PyObject_GC_Fini(inst);
  	/* Call the __del__ method if it exists.  First temporarily
  	   revive the object and save the current exception, if any. */
  #ifdef Py_TRACE_REFS
--- 490,495 ----
***************
*** 523,529 ****
  #ifdef COUNT_ALLOCS
  		inst->ob_type->tp_free--;
  #endif
- 		PyObject_GC_Init((PyObject *)inst);
  		return; /* __del__ added a reference; don't delete now */
  	}
  #ifdef Py_TRACE_REFS
--- 522,527 ----
***************
*** 537,542 ****
--- 535,541 ----
  #endif /* Py_TRACE_REFS */
  	Py_DECREF(inst->in_class);
  	Py_XDECREF(inst->in_dict);
+ 	PyObject_GC_Fini(inst);
  	inst = (PyInstanceObject *) PyObject_AS_GC(inst);
  	PyObject_DEL(inst);
  }
------------------------------------------------------------------------------

ie, delay the removal from the gc list till everything has stabilized.

I hope this helps.


-------------------------------------------------------

Date: 2000-Sep-14 23:43
By: nascheme

Comment:
Your analysis looks correct.  Great work.  I think there is a small problem with your fix however.  You should call PyObject_GC_Fini() before the DECREFs on in_class and in_dict.  If, for some reason, decrementing the reference counts of these object causes a garbage collection then the instance could still be on the gc lists and have an invalid in_class or in_dict pointer.
-------------------------------------------------------

Date: 2000-Sep-15 08:02
By: nascheme

Comment:
I've posted a patch.  Should I mark this bug as fixed or does whoever checks in the patch make that change?
-------------------------------------------------------

Date: 2000-Sep-15 09:55
By: tim_one

Comment:
Neil, you're by far "the expert" here, so there's no need to produce a patch unless you *want* someone else to review it first.  Else just commit your changes directly.

As to what to do about this bug, I see that it's assigned to you, so you're responsible for changing the Resolution to Fixed and the Status to Closed when those become true.  Just like in the Patch Manager, whoever is assigned to a thing is responsible for taking the next step -- or assigning it to someone else if they can't or won't (or even just really don't want to, or can't make time to) take the next step.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113812&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 18:04:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 10:04:46 -0700
Subject: [Python-bugs-list] [Bug #110650] [HP-UX] python with-threads core-dumps (PR#342)
Message-ID: <200009151704.KAA15481@delerium.i.sourceforge.net>

Bug #110650, was updated on 2000-Jul-31 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: [HP-UX] python with-threads core-dumps (PR#342)

Details: Jitterbug-Id: 342
Submitted-By: michael.exner@mrz.uni-magdeburg.de
Date: Wed, 31 May 2000 09:43:38 -0400 (EDT)
Version: 1.5.2
OS: hpux-11.00


When I compile python with threads python core-dumps:
$ ./python
pthread_mutex_init: Invalid argument
Memory fault(coredump)
without thread-support everything works fine
I tried this with hpux-ansi-c and with gcc (2.95.2) but got the same result




====================================================================
Audit trail:
Tue Jul 11 08:25:57 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-28 20:43
By: tim_one

Comment:
Note that the only call to pthread_mutex_init Python makes is in function PyThread_allocate_lock in file phread_pthread.h.  If Python compiled at all, it's extremely unlikely that the first argument is in error.  It's very likely that the second argument is in error, though:  there were many imcompatible revisions of the pthreads std, and pthread_mutexattr_default is a macro conditionally defined near the top of the file.  If this OS actually support pthreads, you have to figure out which *version* of pthreads it defines and arrange for config to define the *correct* one of the

PY_PTHREAD_D4
PY_PTHREAD_D7
PY_PTHREAD_STD
PY_PTHREAD_D6

symbols for your platform.  Else disable threads entirely.
-------------------------------------------------------

Date: 2000-Aug-29 07:34
By: memaul

Comment:
Goto link below for instructions and patches for building
python 152 with threads on hpux 10.20

http://memaul.tripod.com/index.html
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-15 02:34
By: harripasanen

Comment:
I can verify that the bug exists not only in 1.5.2 but also in 1.6.

gcc 2.95.2
HPUX 11.00

I'll see if tim_one's suggestions help.

Regards,

Harri Pasanen
-------------------------------------------------------

Date: 2000-Sep-15 04:55
By: harripasanen

Comment:
The problems seems to be that configure gets the libraries wrong on HP-UX 11.0.   It links with -lcma, when it should link with -lpthread.

So a quick and dirty solution is to relink the python by hand, replacing -lcma with -lpthread.

-------------------------------------------------------

Date: 2000-Sep-15 10:04
By: fdrake

Comment:
Noted that this is HP-UX specific in summary.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110650&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 18:11:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 10:11:41 -0700
Subject: [Python-bugs-list] [Bug #110706] gcc error msg, 1.5.2, Slackware + threads (PR#44)
Message-ID: <200009151711.KAA15796@delerium.i.sourceforge.net>

Bug #110706, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: Remind
Bug Group: Platform-specific
Priority: 5
Summary: gcc error msg, 1.5.2, Slackware + threads (PR#44)

Details: Jitterbug-Id: 44
Submitted-By: rene@kronos.szabinet.hu
Date: Sun, 1 Aug 1999 16:39:42 -0400 (EDT)
Version: 1.5.2
OS: Linux


Compile error with Python-1.5.2 on
Linux Slackware 4.0, kernel 2.2.10-ac8, gcc 2.7.2.3, make 3.76.1

./configure --prefix=/usr/local --with-threads && make
...
./socketmodule.c: In function `setipaddr':
./socketmodule.c:392: warning: passing arg 5 of `gethostbyname_r' from
incompatible pointer type
./socketmodule.c:392: too many arguments to function `gethostbyname_r'
./socketmodule.c:392: warning: assignment makes integer from pointer without a
cast
./socketmodule.c: In function `PySocket_gethostbyname_ex':
./socketmodule.c:1471: warning: passing arg 5 of `gethostbyname_r' from
incompatible pointer type
./socketmodule.c:1471: too many arguments to function `gethostbyname_r'
./socketmodule.c:1471: warning: assignment makes integer from pointer without a
cast
./socketmodule.c: In function `PySocket_gethostbyaddr':
./socketmodule.c:1534: warning: passing arg 7 of `gethostbyaddr_r' from
incompatible pointer type
./socketmodule.c:1534: too many arguments to function `gethostbyaddr_r'
./socketmodule.c:1534: warning: assignment makes integer from pointer without a
cast
make[1]: *** [socketmodule.o] Error 1
make: *** [Modules] Error 2



====================================================================
Audit trail:
Wed Aug 04 12:12:39 1999	guido	moved from incoming to platformbug
Mon Aug 30 12:37:34 1999	guido	changed notes
Mon Oct 25 15:15:46 1999	guido	changed notes

Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 22:50
By: tim_one

Comment:
Assigned to Fred for the heck of it.  Changed the "Summary" msg as the original "Compiler error" gave me an entirely wrong impression.
-------------------------------------------------------

Date: 2000-Sep-15 10:11
By: fdrake

Comment:
Sent a message to the submitter asking if this is still a problem with more recent Python releases; this sounds very much like a bug that's been squashed, but I don't have a Slackware Linux installation available for testing.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110706&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 18:17:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 10:17:11 -0700
Subject: [Python-bugs-list] [Bug #114333] minidom fails to parse PI
Message-ID: <200009151717.KAA16017@delerium.i.sourceforge.net>

Bug #114333, was updated on 2000-Sep-13 04:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: minidom fails to parse PI

Details: # Using Python2.0b1, minidom and expat:

s="""<?xml version='1.0'?><?pi-foobar?><test></test>"""
import xml.dom.minidom
p=xml.dom.minidom.parseString(s)

stack_trace="""
Traceback (most recent call last):
  File "test.py", line 6, in ?
    p=xml.dom.minidom.parseString(s)
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/minidom.py", line 45
2, in parseString
    return _doparse( pulldom.parseString, args, kwargs )
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/minidom.py", line 44
3, in _doparse
    events.expandNode( rootNode )
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/pulldom.py", line 14
2, in expandNode
    cur_node.parentNode.appendChild( cur_node )
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/minidom.py", line 40
0, in appendChild
    raise TypeError, "Two document elements disallowed"
TypeError: Two document elements disallowed
"""


Follow-Ups:

Date: 2000-Sep-13 04:37
By: jrvosse

Comment:
See also the python xml-sig mail list:

http://www.python.org/pipermail/xml-sig/2000-September/004817.html
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114333&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 18:18:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 10:18:00 -0700
Subject: [Python-bugs-list] [Bug #114333] minidom fails to parse PI
Message-ID: <200009151718.KAA16035@delerium.i.sourceforge.net>

Bug #114333, was updated on 2000-Sep-13 04:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: minidom fails to parse PI

Details: # Using Python2.0b1, minidom and expat:

s="""<?xml version='1.0'?><?pi-foobar?><test></test>"""
import xml.dom.minidom
p=xml.dom.minidom.parseString(s)

stack_trace="""
Traceback (most recent call last):
  File "test.py", line 6, in ?
    p=xml.dom.minidom.parseString(s)
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/minidom.py", line 45
2, in parseString
    return _doparse( pulldom.parseString, args, kwargs )
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/minidom.py", line 44
3, in _doparse
    events.expandNode( rootNode )
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/pulldom.py", line 14
2, in expandNode
    cur_node.parentNode.appendChild( cur_node )
  File "/hosts/multimedia/ins2/linux2/lib/python2.0/xml/dom/minidom.py", line 40
0, in appendChild
    raise TypeError, "Two document elements disallowed"
TypeError: Two document elements disallowed
"""


Follow-Ups:

Date: 2000-Sep-13 04:37
By: jrvosse

Comment:
See also the python xml-sig mail list:

http://www.python.org/pipermail/xml-sig/2000-September/004817.html
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114333&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 18:21:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 10:21:45 -0700
Subject: [Python-bugs-list] [Bug #114532] cgi + <TextArea>.. + xml-data
Message-ID: <200009151721.KAA16244@delerium.i.sourceforge.net>

Bug #114532, was updated on 2000-Sep-15 10:21
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: cgi + <TextArea>.. + xml-data

Details: Hi!

I'm working under linux (mandrake 7.1) using python for my cgi scripts. There I've a formular containing a "textarea". If entering xml- or html-data into this textarea and submitting it the cgi-script doesn't get that xml-data. With non-xml-data everything works fine.

BTW: It's the same with an "input"-field.

ciao
Volker


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114532&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 18:26:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 10:26:42 -0700
Subject: [Python-bugs-list] [Bug #110619] urllib.py fails with username/password proxies (PR#221)
Message-ID: <200009151726.KAA16423@delerium.i.sourceforge.net>

Bug #110619, was updated on 2000-Jul-31 14:06
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 3
Summary: urllib.py fails with username/password proxies (PR#221)

Details: Jitterbug-Id: 221
Submitted-By: tarka@zip.com.au
Date: Tue, 29 Feb 2000 19:15:45 -0500 (EST)
Version: 1.5.2
OS: Irix


urllib.py fails to handle proxies with user and password information 
included in the proxy URL, e.g. http://ssmith:testpass@10.11.12.13:1234

The following example ...

	import os, urllib
	os.environ['http_proxy'] = "http://ssmith:testpass01@10.11.12.13:1234"
	f = urllib.urlopen('http://www.python.org')
	data = f.read()
	print data

fails with the following errors :

Traceback (innermost last):
  File "url.py", line 3, in ?
    f = urllib.urlopen('http://www.python.org')
  File "/var/share//lib/python1.5/urllib.py", line 59, in urlopen
    return _urlopener.open(url)
  File "/var/share//lib/python1.5/urllib.py", line 157, in open
    return getattr(self, name)(url)
  File "/var/share//lib/python1.5/urllib.py", line 253, in open_http
    h = httplib.HTTP(host)
  File "/var/share//lib/python1.5/httplib.py", line 51, in __init__
    if host: self.connect(host, port)
  File "/var/share//lib/python1.5/httplib.py", line 75, in connect
    raise socket.error, "nonnumeric port"
IOError: [Errno socket error] nonnumeric port






====================================================================
Audit trail:
Mon May 22 17:35:04 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-31 10:15
By: fdrake

Comment:
Will be documented as a limitation in the implementation, as suggested in bug #111725.  I'm converting this to a feature request that can be dealt with in a subsequent version of Python.
-------------------------------------------------------

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 03:17
By: gvanrossum

Comment:
Fred, please document this limitation, add this to the feature-requests PEP (to be created), and then close the bug.
-------------------------------------------------------

Date: 2000-Sep-14 21:16
By: fdrake

Comment:
This limitation was already documented, but I've added a note that should be easier to find for people looking for limitations.  Also fixed typo from existing note.  This is checked in as Doc/lib/liburllib.tex revision 1.29.
-------------------------------------------------------

Date: 2000-Sep-15 10:26
By: fdrake

Comment:
Moved request to Feature Requests PEP & submitted to the PEP Editor.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110619&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 18:57:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 10:57:55 -0700
Subject: [Python-bugs-list] [Bug #114532] cgi + <TextArea>.. + xml-data
Message-ID: <200009151757.KAA32241@bush.i.sourceforge.net>

Bug #114532, was updated on 2000-Sep-15 10:21
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: cgi + <TextArea>.. + xml-data

Details: Hi!

I'm working under linux (mandrake 7.1) using python for my cgi scripts. There I've a formular containing a "textarea". If entering xml- or html-data into this textarea and submitting it the cgi-script doesn't get that xml-data. With non-xml-data everything works fine.

BTW: It's the same with an "input"-field.

ciao
Volker


Follow-Ups:

Date: 2000-Sep-15 10:57
By: gvanrossum

Comment:
Volker,

We cannot help you with this bug unless you provide us with an example we can try ourselves.  We need at least:

1) a simple but complete script that shows the bug (try to pare it down from the script you are using to somehing that demonstrates just the problem)

2) the HTML of the form (ditto)

3) the text you are entering into the form

We also need:

- the Python version
- the browser name and version
- the server name and version

That said, I suspect that the problem is in your script, but without looking at it, I can't tell!

--Guido
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114532&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 19:05:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 11:05:30 -0700
Subject: [Python-bugs-list] [Bug #110706] gcc error msg, 1.5.2, Slackware + threads (PR#44)
Message-ID: <200009151805.LAA17961@delerium.i.sourceforge.net>

Bug #110706, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: Remind
Bug Group: Platform-specific
Priority: 5
Summary: gcc error msg, 1.5.2, Slackware + threads (PR#44)

Details: Jitterbug-Id: 44
Submitted-By: rene@kronos.szabinet.hu
Date: Sun, 1 Aug 1999 16:39:42 -0400 (EDT)
Version: 1.5.2
OS: Linux


Compile error with Python-1.5.2 on
Linux Slackware 4.0, kernel 2.2.10-ac8, gcc 2.7.2.3, make 3.76.1

./configure --prefix=/usr/local --with-threads && make
...
./socketmodule.c: In function `setipaddr':
./socketmodule.c:392: warning: passing arg 5 of `gethostbyname_r' from
incompatible pointer type
./socketmodule.c:392: too many arguments to function `gethostbyname_r'
./socketmodule.c:392: warning: assignment makes integer from pointer without a
cast
./socketmodule.c: In function `PySocket_gethostbyname_ex':
./socketmodule.c:1471: warning: passing arg 5 of `gethostbyname_r' from
incompatible pointer type
./socketmodule.c:1471: too many arguments to function `gethostbyname_r'
./socketmodule.c:1471: warning: assignment makes integer from pointer without a
cast
./socketmodule.c: In function `PySocket_gethostbyaddr':
./socketmodule.c:1534: warning: passing arg 7 of `gethostbyaddr_r' from
incompatible pointer type
./socketmodule.c:1534: too many arguments to function `gethostbyaddr_r'
./socketmodule.c:1534: warning: assignment makes integer from pointer without a
cast
make[1]: *** [socketmodule.o] Error 1
make: *** [Modules] Error 2



====================================================================
Audit trail:
Wed Aug 04 12:12:39 1999	guido	moved from incoming to platformbug
Mon Aug 30 12:37:34 1999	guido	changed notes
Mon Oct 25 15:15:46 1999	guido	changed notes

Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 22:50
By: tim_one

Comment:
Assigned to Fred for the heck of it.  Changed the "Summary" msg as the original "Compiler error" gave me an entirely wrong impression.
-------------------------------------------------------

Date: 2000-Sep-15 10:11
By: fdrake

Comment:
Sent a message to the submitter asking if this is still a problem with more recent Python releases; this sounds very much like a bug that's been squashed, but I don't have a Slackware Linux installation available for testing.
-------------------------------------------------------

Date: 2000-Sep-15 11:05
By: fdrake

Comment:
I cannot reproduce this with Slackware 7.0 (kernel 2.2.14 SMP; the version installed on the SourceForge compile farm).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110706&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 19:06:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 11:06:13 -0700
Subject: [Python-bugs-list] [Bug #110675] Pth: test_fork1 fails, test_thread slow (PR#383)
Message-ID: <200009151806.LAA17978@delerium.i.sourceforge.net>

Bug #110675, was updated on 2000-Jul-31 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Wont Fix
Bug Group: 3rd Party
Priority: 1
Summary: Pth: test_fork1 fails, test_thread slow (PR#383)

Details: Jitterbug-Id: 383
Submitted-By: gregor@hoffleit.de
Date: Tue,  4 Jul 2000 12:07:06 -0400 (EDT)
Version: CVS version (06/04/00)
OS: Debian potato (i386)


When I use the current CVS version of Python to build on a Debian potato
system with GNU Pth 1.2.3 installed, test_fork1 fails with an error (see
below),
and test_thread takes significantly longer to complete than when I build the 
same sources with native LinuxThreads.


When running test.regrtest.main(), this happens:

  clapton:3> LD_LIBRARY_PATH=`pwd` ./python 
  Python 2.0b1 (#0, Jul  4 2000, 17:06:15)  [GCC 2.95.2 20000220 (Debian
GNU/Linux)] on linux2
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
  >>> from test import regrtest
  >>> regrtest.main()
  test_grammar
  test_opcodes
...
  test_extcall
  test_fcntl
  test_fork1
  test test_fork1 crashed -- exceptions.AssertionError : 
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 30, in f
      alive[id] = os.getpid()
  AttributeError: 'None' object has no attribute 'getpid'
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 32, in f    time.sleep(SHORTSLEEP)
  TypeError: illegal argument type for built-in operation
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 30, in f
      alive[id] = os.getpid()
  AttributeError: 'None' object has no attribute 'getpid'
  Unhandled exception in thread:
  Traceback (most recent call last):
    File "./Lib/test/test_fork1.py", line 30, in f
      alive[id] = os.getpid()
  AttributeError: 'None' object has no attribute 'getpid'
  test_format
  test_gc
...


When running test.test_fork1(), I get this:

  clapton:3> LD_LIBRARY_PATH=`pwd` ./python 
  Python 2.0b1 (#0, Jul  4 2000, 17:06:15)  [GCC 2.95.2 20000220 (Debian
GNU/Linux)] on linux2
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
  >>> from test import test_fork1
  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    File "./Lib/test/test_fork1.py", line 68, in ?
      main()
    File "./Lib/test/test_fork1.py", line 44, in main
      assert a == range(NUM_THREADS)
  AssertionError
  >>>


test_thread takes very long to complete (5 min compared to 40 sec with 
LinuxThreads); when you look at the following log, you'll see that it tends
to calls the threads serially !?

clapton:3> LD_LIBRARY_PATH=`pwd` ./python 
Python 2.0b1 (#0, Jul  4 2000, 17:06:15)  [GCC 2.95.2 20000220 (Debian
GNU/Linux)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
Copyright 1995-2000 Corporation for National Research Initiatives (CNRI)
>>> from test import test_thread
creating task 1
creating task 2
creating task 3
task 1 will run for 2.1 sec
task 1 done
creating task 4
task 2 will run for 3.2 sec
creating task 5
task 2 done
creating task task 3 will run for 9.1 6
sec
task 3 done
creating task 7
task 4 will run for 2.5 sec
task 4 done
creating task 8
task 5 will run for 0.9 sec
task 5 done
creating task 9
task 6 will run for 7.4 sec
task 6 done
creating task 10
waiting for all tasks to complete
task 7 will run for 5.3 sec
task 7 done
task 8 will run for 2.6 sec
task 8 done
task 9 will run for 2.7 sec
task 9 done
task 10 will run for 0.9 sec
task 10 done
all tasks done

*** Barrier Test ***
task 0 will run for 0.0 sec
task 0 entering barrier 0
task 1 will run for 6.2 sec
task 1 entering barrier 0
task 7 will run for 7.0 sec
task 7 entering barrier 0
task 3 will run for 5.9 sec
task 3 entering barrier 0
task 4 will run for 4.5 sec
task 4 entering barrier 0
task 5 will run for 9.2 sec
task 5 entering barrier 0
task 6 will run for 1.4 sec
task 6 entering barrier 0
task 2 will run for 6.0 sec
task 2 entering barrier 0
task 8 will run for 2.4 sec
task 8 entering barrier 0
task 9 will run for 9.6 sec
task 9 entering barrier 0
task 9 leaving barrier 0
task 0 leaving barrier 0
task task 1 leaving barrier 0
0 will run for 0.0 sec
task 0 entering barrier 1
task 7 leaving barrier 0
task 9 will run for 0.8 sec
task 9 entering barrier task 3 leaving barrier 0
1
task 1 task 4 leaving barrier 0
will run for 6.1 sec
task 5 leaving barrier 0
task 1 entering barrier 1
task 6 leaving barrier 0
task 7 will run for 7.9 sec
task 2 leaving barrier 0
task 7 entering barrier 1
task 3 task 8 leaving barrier 0
will run for 7.8 sec
task 3 entering barrier 1
task 4 will run for 5.7 sec
task 4 entering barrier 1
task 5 will run for 2.0 sec
task 5 entering barrier 1
task 6 will run for 0.5 sec
task 6 entering barrier 1
task 2 will run for 7.4 sec
task 2 entering barrier 1
task 8 will run for 1.0 sec
task 8 entering barrier 1
task 8 leaving barrier 1
task 7 leaving barrier 1
task 9 leaving barrier 1
task 1 leaving barrier 1
task 8 will run for 6.9 sec
task 0 leaving barrier 1
task 8 entering barrier 2
task 0 will run for task 4 leaving barrier 1 0.0 sec

task 7 will run for 4.3 sec task 0 entering barrier
2
task 3 leaving barrier 1
task 7 entering barrier 2
task 5 leaving barrier 1
task 6 leaving barrier 1 task 9 will run for
8.2 sec
task task 2 leaving barrier 9 entering barrier 2
1
task 5 will run for 8.9 sec
task 5 entering barrier 2
task 2 will run for 8.3 sec
task 2 entering barrier 2
task 3 will run for 4.5 sec
task 3 entering barrier 2
task 1 will run for 7.0 sec
task 1 entering barrier 2
task 6 will run for 1.9 sec
task 6 entering barrier 2
task 4 will run for 0.2 sec
task 4 entering barrier 2
task 4 leaving barrier 2
task 8 leaving barrier 2
task 9 leaving barrier 2
task 7 leaving barrier 2
task 5 leaving barrier 2
task 0 leaving barrier 2
task 2 leaving barrier 2
task 3 leaving barrier 2
task 1 leaving barrier 2
task 6 leaving barrier 2
all tasks done



while this is the log of the same test with Python 1.5.2 and LinuxThreads:

clapton:3> python
Python 1.5.2 (#0, Apr  3 2000, 14:46:48)  [GCC 2.95.2 20000313 (Debian
GNU/Linux)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from test import test_thread
creating task 1
creating task 2
creating task 3
creating task 4
creating task 5
creating task 6
creating task 7
creating task 8
creating task 9
creating task 10
waiting for all tasks to complete
task 1 will run for 8.9 sec
task 2 will run for 8.3 sec
task 3 will run for 9.1 sec
task 5 will run for 6.0 sec
task 4 will run for 7.5 sec
task 6 will run for 4.7 sec
task 7 will run for 4.2 sec
task 8 will run for 7.0 sec
task 9 will run for 8.7 sec
task 10 will run for 9.5 sec
task 7 done
task 6 done
task 5 done
task 8 done
task 4 done
task 2 done
task 9 done
task 1 done
task 3 done
task 10 done
all tasks done

*** Barrier Test ***
task 0 will run for 0.0 sec
task 1 will run for 2.8 sec
task 0 entering barrier 0
task 2 will run for 5.3 sec
task 3 will run for 9.2 sec
task 5 will run for 8.0 sec
task 4 will run for 8.9 sec
task 6 will run for 5.0 sec
task 7 will run for 1.3 sec
task 8 will run for 5.6 sec
task 9 will run for 4.7 sec
task 7 entering barrier 0
task 1 entering barrier 0
task 9 entering barrier 0
task 6 entering barrier 0
task 2 entering barrier 0
task 8 entering barrier 0
task 5 entering barrier 0
task 4 entering barrier 0
task 3 entering barrier 0
task 3 leaving barrier 0
task 3 will run for 0.1 sec
task 0 leaving barrier 0
task 0 will run for 0.0 sec
task 7 leaving barrier 0
task 7 will run for 6.6 sec
task 1 leaving barrier 0
task 1 will run for 1.0 sec
task 9 leaving barrier 0
task 9 will run for 8.2 sec
task 6 leaving barrier 0
task 6 will run for 1.0 sec
task 2 leaving barrier 0
task 2 will run for 9.2 sec
task 8 leaving barrier 0
task 8 will run for 4.4 sec
task 5 leaving barrier 0
task 5 will run for 9.6 sec
task 4 leaving barrier 0
task 4 will run for 1.7 sec
task 0 entering barrier 1
task 3 entering barrier 1
task 1 entering barrier 1
task 6 entering barrier 1
task 4 entering barrier 1
task 8 entering barrier 1
task 7 entering barrier 1
task 9 entering barrier 1
task 2 entering barrier 1
task 5 entering barrier 1
task 5 leaving barrier 1
task 5 will run for 6.6 sec
task 0 leaving barrier 1
task 0 will run for 0.0 sec
task 3 leaving barrier 1
task 3 will run for 8.5 sec
task 1 leaving barrier 1
task 1 will run for 0.1 sec
task 6 leaving barrier 1
task 6 will run for 4.7 sec
task 4 leaving barrier 1
task 4 will run for 4.7 sec
task 8 leaving barrier 1
task 8 will run for 1.7 sec
task 7 leaving barrier 1
task 7 will run for 1.8 sec
task 9 leaving barrier 1
task 9 will run for 2.8 sec
task 2 leaving barrier 1
task 2 will run for 3.3 sec
task 0 entering barrier 2
task 1 entering barrier 2
task 8 entering barrier 2
task 7 entering barrier 2
task 9 entering barrier 2
task 2 entering barrier 2
task 6 entering barrier 2
task 4 entering barrier 2
task 5 entering barrier 2
task 3 entering barrier 2
task 3 leaving barrier 2
task 0 leaving barrier 2
task 1 leaving barrier 2
task 8 leaving barrier 2
task 7 leaving barrier 2
task 9 leaving barrier 2
task 2 leaving barrier 2
task 6 leaving barrier 2
task 4 leaving barrier 2
task 5 leaving barrier 2
all tasks done
>>> 





====================================================================
Audit trail:
Tue Jul 11 08:24:22 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-23 10:31
By: jhylton

Comment:
Another report of test_fork1 problems.  Plan to resolve before 2.0b1.

-------------------------------------------------------

Date: 2000-Aug-23 10:36
By: tim_one

Comment:
Jeremy, my chances of helping someone with a problem specific to "Debian potato system with GNU Pth 1.2.3" are nil.  Assigned back to you since you seem to believe it's feasible <wink>.
-------------------------------------------------------

Date: 2000-Aug-31 14:53
By: jhylton

Comment:
Haven't heard back from the submittor.  This sounds like a problem with a buggy GNU Pth package; not a Python bug.

-------------------------------------------------------

Date: 2000-Sep-01 14:15
By: none

Comment:
I submitted the original pth support. pth has what I would consider a bug in that signals do not interrupt sleep(), usleep(), or select(), the latter being what Python uses to sleep. I'm going to look at this some more myself as soon as I can get the current CVS to configure with pth. -- andy@dustman.net
-------------------------------------------------------

Date: 2000-Sep-01 14:22
By: none

Comment:
Another thing which may be a factor in this case: Since pth threads are user-space and so all run in the same process, the test used in signalmodule.c:125 doesn't work, i.e.

        if (getpid() == main_pid) {

It probably needs to be something more like this:

        if (PyThread_get_thread_ident() != main_thread) {

I submitted a patch to fix this around the time of the CNRI split, so it probably got lost.

-- andy@dustman.net
-------------------------------------------------------

Date: 2000-Sep-06 17:08
By: adustman

Comment:
I submitted patch 101437 which should fix this.
-------------------------------------------------------

Date: 2000-Sep-15 11:06
By: jhylton

Comment:
The only substance left in this bug report is Andy Dustman's note about a different bug.  He's already submitted a patch for it, so we'll use that to track the problem.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110675&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 19:11:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 11:11:19 -0700
Subject: [Python-bugs-list] [Bug #110696] strptime error (PR#149)
Message-ID: <200009151811.LAA18209@delerium.i.sourceforge.net>

Bug #110696, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Works For Me
Bug Group: Platform-specific
Priority: 3
Summary: strptime error (PR#149)

Details: Jitterbug-Id: 149
Submitted-By: python.org@netfinances.com
Date: Sat, 4 Dec 1999 22:03:43 -0500 (EST)
Version: 1.5.2
OS: RedHat Linux 6.0


strptime throws a ValueError exception when I feed it the hour 02, and a minute
value 
equal to 40 or greater the following session illustrates:

1017:26:fred@firestorm:~/public_html >python
Python 1.5.2 (#2, Dec  3 1999, 23:56:19)  [GCC egcs-2.91.66 19990314/Linux
(egcs- on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from time import strptime
>>> t = strptime('0230','%H%M')
>>> t
(1900, 1, 0, 23, 0, 0, 6, 1, 0)
>>> t = strptime('0240','%H%M')
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: format mismatch
>>> t = strptime('0140','%H%M')
>>> t = strptime('0340','%H%M')
>>> t = strptime('0345','%H%M')
>>> t = strptime('0339','%H%M')
>>> t = strptime('0240','%H%M')
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: format mismatch
>>> t = strptime('0245','%H%M')
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: format mismatch
>>> t = strptime('0250','%H%M')
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: format mismatch
>>> t = strptime('0259','%H%M')
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: format mismatch
>>> 



====================================================================
Audit trail:
Tue Dec 14 17:22:29 1999	guido	sent reply 1
Tue Dec 14 17:22:48 1999	guido	resent 149.reply.1
Tue Dec 14 17:24:30 1999	guido	sent reply 2
Tue Dec 14 17:24:51 1999	guido	changed notes
Tue Dec 14 17:24:51 1999	guido	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: strptime error (PR#149)
Date: Tue Dec 14 17:22:29 1999


-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: strptime error (PR#149)
Date: Tue Dec 14 17:24:30 1999

> strptime throws a ValueError exception when I feed it the hour 02, and a
minute
> value 
> equal to 40 or greater the following session illustrates:

Very strange.  I can't reproduce this; I presume your platform's strptime()
has a problem.

--Guido van Rossum

-------------------------------------------------------

Date: 2000-Aug-01 14:03
By: none

Comment:
Must be the strptime() implementation in his C library.

-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-15 11:11
By: jhylton

Comment:
a problem with the platform's strptime

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110696&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 19:42:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 11:42:47 -0700
Subject: [Python-bugs-list] [Bug #111403] 1.6b1 dumps core dereferencing a NULL tstate
Message-ID: <200009151842.LAA19382@delerium.i.sourceforge.net>

Bug #111403, was updated on 2000-Aug-08 11:26
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: 1.6b1 dumps core dereferencing a NULL tstate

Details: 
  This is from an embeded python.  I've not yet been
able to reproduce this with a small example.  But
perhaps this stacktrace will be of some help.  The
problem seems to be that eval_code2() calls PyThreadState_GET() and gets a NULL pointer back.
This pointer is dereferenced in PyFrame_New() later
on which causes the core dump.  The documentation
seems to say that PyThreadState_GET() should never
return NULL.  So, there must be a bug in there
somewhere.  Here is the stack trace:

#0  0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, 
    locals=0x0) at frameobject.c:120
120             PyFrameObject *back = tstate->frame;
(gdb) bt
#0  0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, 
    locals=0x0) at frameobject.c:120
#1  0x866b022 in eval_code2 (co=0x90fff70, globals=0x9284378, locals=0x0, 
    args=0x8eb362c, argcount=5, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
    owner=0x925d2e8) at ceval.c:397
#2  0x866e4ee in call_function (func=0x911aca0, arg=0x95ea3b0, kw=0x0)
    at ceval.c:2521
#3  0x866e09d in PyEval_CallObjectWithKeywords (func=0x95f7a60, arg=0x95ea3b0, 
    kw=0x0) at ceval.c:2359
#4  0x863f6cf in PyObject_CallObject (o=0x95f7a60, a=0x95ea3b0)
    at abstract.c:1370
#5  0x83e56ed in DrawingArea::process (this=0x95f5f48, event=@0xbfffeb80)
    at DrawingArea.C:971
#6  0x83e5b3d in DrawingArea::dspCB (this=0x95e0b68) at DrawingArea.C:1027
#7  0x832050f in TkFDWatcher::callback (data=0x95e2048) at TkFDWatcher.C:169
#8  0x8752612 in FileHandlerEventProc (evPtr=0x935a4d8, flags=-1)
    at ./tclUnixNotfy.c:405
#9  0x8741d10 in Tcl_ServiceEvent (flags=-1) at ./../generic/tclNotify.c:444
#10 0x8741fae in Tcl_DoOneEvent (flags=2) at ./../generic/tclNotify.c:747
#11 0x86a8757 in Tkapp_MainLoop (self=0x8f6a178, args=0x8eb6af0)
    at ./_tkinter.c:1794
#12 0x866e19e in call_builtin (func=0x8f7b7f0, arg=0x8eb6af0, kw=0x0)
    at ceval.c:2396
#13 0x866e0ab in PyEval_CallObjectWithKeywords (func=0x8f7b7f0, arg=0x8eb6af0, 
    kw=0x0) at ceval.c:2361
#14 0x866d0cb in eval_code2 (co=0x8fb2d18, globals=0x903b9f8, locals=0x0, 
    args=0x8f277b4, argcount=0, kws=0x8f277b4, kwcount=0, defs=0x90447c4, 
    defcount=1, owner=0x0) at ceval.c:1680
#15 0x866cdda in eval_code2 (co=0x8f28b10, globals=0x8f294d0, locals=0x0, 
    args=0x8f27600, argcount=1, kws=0x8f27604, kwcount=0, defs=0x0, 
    defcount=0, owner=0x92c6238) at ceval.c:1579
#16 0x866cdda in eval_code2 (co=0x8f5b300, globals=0x8f294d0, locals=0x0, 
    args=0x8eb8600, argcount=0, kws=0x8eb8600, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1579
#17 0x866cdda in eval_code2 (co=0x8f27ae0, globals=0x8eb0038, 
    locals=0x8eb0038, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1579
#18 0x866afc8 in PyEval_EvalCode (co=0x8f27ae0, globals=0x8eb0038, 
    locals=0x8eb0038) at ceval.c:290
#19 0x867d7c7 in run_node (n=0x8f1d0e0, filename=0x89fcacf "<string>", 
    globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:885
#20 0x867d777 in run_err_node (n=0x8f1d0e0, filename=0x89fcacf "<string>", 
    globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:870
#21 0x867d719 in PyRun_String (str=0x8f1ca68 "import GFE; GFE.main()\n", 
    start=257, globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:847
#22 0x867ce4e in PyRun_SimpleString (
    command=0x8f1ca68 "import GFE; GFE.main()\n") at pythonrun.c:589
#23 0x8681c51 in Py_Main (argc=4, argv=0xbffff204) at main.c:248
#24 0x80d90e1 in main (argc=4, argv=0xbffff204) at main.C:30

Mike Romberg (romberg@fsl.noaa.gov)


Follow-Ups:

Date: 2000-Aug-10 10:23
By: none

Comment:
Followup:  This only happens when python is built
--with-threads.  There appears to be no problem when
threads are not enabled.  It should be noted that our
embeded application uses no threads of any kind (python or
pthreads from C++).  But it may be the case that our code
(C++) is not doing the right thing.

  It should be noted that our application works fine
with python-1.5.2 compiled --with-threads.

-------------------------------------------------------

Date: 2000-Aug-25 07:37
By: jhylton

Comment:
Mike -- Can you provide any more information about this bug?

-------------------------------------------------------

Date: 2000-Aug-25 09:59
By: romberg

Comment:
  My guess (and this is just a guess) is that this may have something
to do with the interaction of python threads and Tkinter.  Since most of
our embeded (and non threaded) python application works fine except
for one specific area, maybe that is thre problem with python 1.6.  Let me
attempt to explain what is going on since it may take some work to
produce a small test case to reproduce the problem.

  Our application uses Tkinter for most of the UI.  We do open a second
connection to the X server using Xlib.  This connection is used to
render complex images into windows.  Tkinter's canvas is just not fast
enough.  I am getting X events from these Xlib created windows via
the Tcl/Tk FileEventHandler (as seen on the stack trace).  I am using the
Tcl/Tk C API to register for these events.

  The case which seems to cause the crash in python comes when I get
a ButtonDown event on my second (non Tkinter) Display.  This event
is delivered from Tcl/Tk to some of our C++ code.  Now for the interesting
bit which I suspect might cause the problem.

  Our C++ code then releases the grab and calls into the python interpreter
for it to post a popup menu (using Tkinter).  This is seen on the stack
as the most recent PyObject_CallObject().  This code attempts to post
the Tkinter popuip menu but dies trying.

  This works fine under python-1.5.2 when it is built --with-thread and
without.  It works fine with python-1.6b2 as long as python is built
without threads.  But when it is built with threads I get this crash.  Is it possible that the Tkinter layer is doing something different threadwise
when python is built --with-threads?
-------------------------------------------------------

Date: 2000-Aug-28 11:28
By: none

Comment:
Another followup.  I've compiled python-1.6b1 on HP-UX-10.20 and
linked the whole thing with purify.  Purify does not show any errors
and everything runs fine when python is built --without-thread.  I was
unable to get python to build on HP-UX --with-thread.  I suspect that
this might have something to do with the DCE threads HPUX uses.

  But in any case.  The extra code linked into our embeded interpreter, is
not doing anything funny with pointers (as far as purify could find).

Mike (romberg@fsl.noaa.gov)

-------------------------------------------------------

Date: 2000-Aug-30 10:46
By: gvanrossum

Comment:
Looks like just another example of HP-UX build problems. (esp. w. threads?)
-------------------------------------------------------

Date: 2000-Aug-30 10:56
By: none

Comment:
  Yea.  I'm not really interested in the HP platform for use with
threads (they are a mess).  I was just using it because that is the
only platform I have access to which can run purify.

  The real problem is under linux (redhat-6.2) when threads are
enabled.  I just wanted to make sure that there were not any funny
memory problems caused by the python extensions we have
added to our embeded python.

  Purify (on HPUX-10.20) seems to give a clean bill of health.  So, I'm
guessing that whattever is causing the core dump under linux is
specific to the thread support in python.

-------------------------------------------------------

Date: 2000-Sep-15 11:42
By: jhylton

Comment:
Another question for you Mike: Have you tried your application on RH 6.2 with 2.0b1?  Does the problem still exist there?  If it is limited to the HP UX platform, which you say you're not actually interested in, I'm going to close this bug report; other people are working on HPUX threading issues.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=111403&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 19:50:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 11:50:58 -0700
Subject: [Python-bugs-list] [Bug #111710] socket.send() can do partial writes on some systems.
Message-ID: <200009151850.LAA19718@delerium.i.sourceforge.net>

Bug #111710, was updated on 2000-Aug-11 13:25
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: socket.send() can do partial writes on some systems.

Details: 0811 15:57 chronis:~% uname -a
FreeBSD chronis.pobox.com 4.0-STABLE FreeBSD 4.0-STABLE #0: Tue Mar 21 01:05:14 EST 2000     root@chronis.pobox.com:/usr/src/sys/compile/MYBSD  i386
0811 15:57 chronis:~% 


0811 15:57 chronis:~% cat scratch/sendtstsrv.py     
import socket         
                      
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind("chronis.pobox.com", 8010) 

while 1:
    s.listen(1)
    conn, addr = s.accept()
    print "connected from", addr
    while 1:
        data = conn.recv(1024)
        if not data: break
    print "done"
    conn.close()

0811 15:58 chronis:~% python scratch/sendtstsrv.py &
[2] 76562

0811 15:58 chronis:~% cat scratch/sendtst.py 
#!/usr/bin/env python

s = "0" * 10000000



import socket
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect("chronis.pobox.com", 8010)
sent = sock.send(s)
if sent != len(s):
    print "sent %d/%d chars" % (sent, len(s))
else:
    print "sent all chars"

0811 15:58 chronis:~% python !$
python scratch/sendtst.py
connected from ('208.210.124.49', 1258)
sent 17520/10000000 chars
done
0811 15:58 chronis:~%            


NOTE: there is nothing in any man page for send() under linux (RH 6.1), Solaris (SunOS 5.5.1), OSF1 V4.0, or FreeBSD{3,4} that states that send() must not perform a
partial write, though of those systems, it only seems
to reproducibly do partial writes under FreeBSD4.0 Stable.

Additionally, W.Richard Stevens' Unix Network Programming Vol 1, second edition states that """
A read or write on a stream socket might input or output fewer bytes than requested, but this is not an error condition.""" (page 77).  Later, Stevens says of send() and recv() "These two functions are similar to the standard read and write functions, but one additional argument is required". (page 354).

scott

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-15 11:50
By: jhylton

Comment:
scott-- Is there a bug here?  It seems clear that the send system call is not required to send all the bytes you asked it to send.  It returns the number of bytes it did send.  If you want to make sure all your data is sent, you can wrap send in a while loop that calls send until all the data is consumed.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=111710&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 19:56:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 11:56:10 -0700
Subject: [Python-bugs-list] [Bug #110835] Find out size of primitive object (PR#214)
Message-ID: <200009151856.LAA19914@delerium.i.sourceforge.net>

Bug #110835, was updated on 2000-Aug-01 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 5
Summary: Find out size of primitive object (PR#214)

Details: Jitterbug-Id: 214
Submitted-By: loewis@informatik.hu-berlin.de
Date: Fri, 25 Feb 2000 14:28:33 -0500 (EST)
Version: 1.5.2
OS: Solaris


This is a feature request made on python-help. If you want to estimate
how much memory your application uses, you currently have to count the bytes
manually. If there was a builtin function (say, sys.sizeof), counting would
be much easier. It would be documented as

sizeof(object) -> integer
Return the number of bytes that an object uses internally. This only counts
the number of bytes used by the object itself, not those of any of its 
attributes.

Ie. sys.sizeof(0) would give 12 on my system, the size of a dictionary would
count the dictentries, but the size of an instanceobject would not count the
the size of the __dict__ attribute.



====================================================================
Audit trail:
Tue Mar 07 14:42:18 2000	guido	changed notes
Tue Mar 07 14:42:18 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:14
By: none

Comment:
Interesting idea.
Is this what we need?
-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 05:14
By: lemburg

Comment:
See mxTools at http://starship.python.net/~lemburg/ for an example of how
to implement a sizeof() function.

The problem with this approach is that it only counts the size of the
object struct itself and doesn't account for any external storage
which may have been allocated by the object (e.g. Unicode objects
and dictionaries use such external resources).
-------------------------------------------------------

Date: 2000-Sep-15 11:56
By: jhylton

Comment:
entere in pep 42

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110835&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 19:57:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 11:57:35 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200009151857.LAA02105@bush.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 13:45
By: fdrake

Comment:
We need to know the output of "uname -s" and "uname -r" for this system.  (If "uname -r" reports an error, please try "uname -v".)

Are you willing to test a modified configure script on this platform?

What additional library is required for the mmap module?
-------------------------------------------------------

Date: 2000-Sep-12 21:59
By: fdrake

Comment:
Received the following response from Daniel Dittmar <ddittmar@users.sourceforge.net>:

> We need to know the output of "uname -s" and "uname -r" 
> for this system.  (If "uname -r" reports an error, please 
> try "uname -v".)

uname -s
ReliantUNIX-N

uname -r
5.45


> Are you willing to test a modified configure script on
> this platform?

sure.

> What additional library is required for the mmap module?

The man page states -lucb. This didn't work on my machine 
as the BSD compatibility layer is not active. I tell you 
more as soon as I know how to activate it.

***********

Another problem: to detect pthreads, the compiler must be 
called with -Kpthread. Otherwise, pthread.h goes into a 
branch where it tries to include a non existent header, 
fails, and configure reports 'no pthreads'.

Daniel

-------------------------------------------------------

Date: 2000-Sep-15 11:57
By: fdrake

Comment:
For the mmap issue, I've added a comment to Modules/Setup.in to let installers know that -lucb may be needed.  In revision 1.110.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 20:13:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 12:13:19 -0700
Subject: [Python-bugs-list] [Bug #110692] urllib.URLopener does not work with proxies (PR#67)
Message-ID: <200009151913.MAA20518@delerium.i.sourceforge.net>

Bug #110692, was updated on 2000-Jul-31 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: None
Bug Group: None
Priority: 5
Summary: urllib.URLopener does not work with proxies (PR#67)

Details: Jitterbug-Id: 67
Submitted-By: andrew@fc.hp.com
Date: Thu, 26 Aug 1999 16:20:02 -0400 (EDT)
Version: 1.5.1
OS: 


When using urllib.URLopener(proxy) (instead of setting _PROXY env variables and

calling urllib.openurl(),
you get the following error message:

 File "./watchdog.py", line 118, in main
    url.open(urltocheck)
  File "/usr/lib/python1.5/urllib.py", line 158, in open
    return getattr(self, name)(url)
  File "/usr/lib/python1.5/urllib.py", line 258, in open_http
    return addinfourl(fp, headers, "http:" + url)
TypeError: illegal argument type for built-in operation 

When using explicti proxies, url is a tuple instead of a string.  You can't 
concatanate a tuple to a string, so the operation fails.

 



====================================================================
Audit trail:
Mon Aug 30 12:40:45 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-05 13:27
By: loewis

Comment:
This is likely incorrect usage of the module. The proxy argument must
be a dictionary mapping strings of protocol names to  strings of URLs.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 13:34
By: fdrake

Comment:
Assigned to Jeremy since he's more familiar with this module.
-------------------------------------------------------

Date: 2000-Sep-15 12:13
By: jhylton

Comment:
This report doesn't make any sense.  The method that raises the exception open_http explicitly checks for a url that is a tuple and sets the local var url to be the second element of the tuple.  I suspect Martin is right; the submittor used the module incorrectly.  Will check by email, but am closing this anyway.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110692&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 20:14:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 12:14:28 -0700
Subject: [Python-bugs-list] [Bug #110625] trouble building under Solaris 7 (PR#260)
Message-ID: <200009151914.MAA20541@delerium.i.sourceforge.net>

Bug #110625, was updated on 2000-Jul-31 14:08
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: trouble building under Solaris 7 (PR#260)

Details: Jitterbug-Id: 260
Submitted-By: lipman@helix.nih.gov
Date: Fri, 31 Mar 2000 18:03:56 -0500 (EST)
Version: 1.5.2
OS: Solaris 7 106541-08


When I built Python on my machine:

SunOS 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-5_10

Python's internal symbols (for instance PySequence_Length) were not
included in the dynamic symbol table of the python executable.  This
prevented the Numerical-15.2 extensions from importing properly.  My
machine has both the Sun linker (in /usr/ccs/bin) and the GNU linker
installed.  I use the GNU linker, which is first in the $PATH under
which Python was built.

A workaround for this problem is to change the following line in
Modules/Makefile.pre from

LDFLAGS=

to

LDFLAGS= -export-dynamic

This will only work for the GNU linker.



====================================================================
Audit trail:
Mon May 22 17:39:59 2000	guido	changed notes
Mon May 22 17:39:59 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-06 14:25
By: twouters

Comment:
This might be fixed by newer autoconf ?
-------------------------------------------------------

Date: 2000-Aug-30 05:39
By: akuchling

Comment:
Reassigning to Jeremy, since I lack the time.
-------------------------------------------------------

Date: 2000-Sep-05 13:41
By: loewis

Comment:
I believe this is fixed in Python 2. I had the same problem in 1.5.2, as
GNU ld suddenly started printing its -V output to stderr instead of
stdout. Then, 

$CC -Xlinker -V 2>/dev/null | grep BFD >/dev/null

of 1.5.2 would not consider the linker as GNU ld. In 2.0,  the line is

$CC -Xlinker -V 2>&1 | grep BFD >/dev/null

so stderr is grepped as well and the bug is fixed.
-------------------------------------------------------

Date: 2000-Sep-15 12:14
By: jhylton

Comment:
I will believe Martin about this bug being fixed.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110625&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 20:15:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 12:15:41 -0700
Subject: [Python-bugs-list] [Bug #112289] NetBSD1.4.2 build issue
Message-ID: <200009151915.MAA20671@delerium.i.sourceforge.net>

Bug #112289, was updated on 2000-Aug-18 19:50
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: NetBSD1.4.2 build issue

Details: the recent fileobjects.c work done for large files (tmick) appears
broken when compiled against NetBSD1.4.2.

During the final link, you get the following output:

gcc   python.o  ../libpython2.0.a   -lutil -lm  -o python
fileobject.c:280: Undefined symbol `_TELL64' referenced from text segment

Follow-Ups:

Date: 2000-Aug-18 19:55
By: none

Comment:
NOTE:  I didn't include the configure output.  If that
would be helpful, go ahead and indicate that in this
tracking system.

If tmick (or whoever) would like me to contact them directly,
I would happily do so.
-------------------------------------------------------

Date: 2000-Aug-31 08:45
By: tmick

Comment:
Sent to python-dev:

1. Who reported this bug? He talked about providing more information and I
would like to speak with him. I cannot find his email address.
2. Does anybody have a NetBSD1.4.2 (or close) machine that I can get shell
access to? Do you know if they have such a machine at SourceForge that users
can get shell access to? Or failing that can someone with such a machine give
me the full ./configure and make output and maybe run this command:
   find /usr/include -name "*" -type f | xargs -l grep -nH _TELL64
and give me the output.


-------------------------------------------------------

Date: 2000-Aug-31 08:47
By: tmick

Comment:
I got no reponse and I have no NetBSD machine on which to reproduce so, as Jeremy suggested, if I wouldn't get it by this evening then assign back to him.

Other questions:
- How old/recent is version 1.4.2 of NetBSD?
- Where is _TELL64 coming from? Not from Python code.

-------------------------------------------------------

Date: 2000-Sep-06 08:43
By: tmick

Comment:
Thanks to Brad (knotwell@NOSPAM f5 NOSPAM.com) who reported the bug I got shell access on his NetBSD 1.4.2 box to play a little bit. I found the problem but I don&#039;t have the Right (tm) fix. Here is what I found:

The _TELL64 compilation failure is for the #define TELL64 usage in fileobject.c for a 64-bit capable tell() system function. Currently this is only defined and used for Win64. The funny thing is that to get to the code section using TELL64 the NetBSD box had to (1) pass the configure test for HAVE_LARGEFILE_SUPPORT, (2) have sizeof(fpos_t) >= 8, and (3) *not* have fseeko (as required by the Single Unix Specification) or fseek64 defined.

As far as I can tell NetBSD *should* define fseeko() and ftello() if it wants to say that it supports largefiles. I *think* that you can manage it via fsetpos() and fgetpos(), which is what I did for largefile support on Win64 (although on Win64 I still relied on a 64-bit capable tell() function -- hence TELL64).  I don&#039;t have the time right now to get and verify a working fsetpos/fgetpos solution.

A quick fix is to ifdef out HAVE_LARGEFILE_SUPPORT for NetBSD 1.4.2 but I don&#039;t know the proper #define&#039;s for that. It is also ugly.

-------------------------------------------------------

Date: 2000-Sep-15 12:15
By: jhylton

Comment:
Trent -- will you have time to work on this between now and 2.0b2?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 20:17:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 12:17:47 -0700
Subject: [Python-bugs-list] [Bug #113037] auotconf/build problems on HP-UX
Message-ID: <200009151917.MAA20699@delerium.i.sourceforge.net>

Bug #113037, was updated on 2000-Aug-29 06:57
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Wont Fix
Bug Group: Irreproducible
Priority: 6
Summary: auotconf/build problems on HP-UX

Details: From: Mike Romberg <romberg@fsl.noaa.gov>
To: jeremy@beopen.com
Subject: Fwd: [Bug #111319] Autoconfig breakdown with gnu libc-2.1.3 (noreply@sourceforge.net)
Date: Mon, 28 Aug 2000 11:49:48 -0600 (MDT)

>>>>> " " == Jeremy Hylton <jeremy@beopen.com> writes:

     > Mike, I can't reproduce the bug you report.  Can you check
     > against the current CVS and see if it still has the problem?
     > It may be that the bug has been fixed since you reported it.

  Here is a followup.  Using the CVS tree from last friday, this is
what I get:

  1 - Default install seems to enable threads and cycle-gc.  This has
      core dumps.

  2 - --without-thread.  Dumps core as well.

  3 - --without-cycle-gc --without-thread.  This has some kind of
      problem with the importer.  It breaks with 'from foo import *'.

  4 - I attempted to build this CVS version on HP-UX so that I might
      run purify with it.  The CVS version did not build on HP-UX.
      The build fails with a 'no rule to make dynload-hpux' (or
      something really close).  I removed this object file from the
      Makefile.  But the build failed later on with undeclared
      functions.  I'm still going to try using purify with
      python-1.6b1 (which did compile on HP-UX).

  So, I tried getting a new CVS version this morning.  This core dumps
right off the bat (compiled with --without-cycle-gc --without-thread).

#0  do_mkvalue (p_format=0xbfffe710, p_va=0xbfffe714) at modsupport.c:353
#1  0x869f0c0 in do_mktuple (p_format=0xbfffe710, p_va=0xbfffe714, endchar=41, 
    n=4) at modsupport.c:223
#2  0x869f189 in do_mkvalue (p_format=0xbfffe710, p_va=0xbfffe714)
    at modsupport.c:247
#3  0x869f430 in Py_VaBuildValue (format=0x8a1d8a2 "(OOOO)", va=0xbfffe744)
    at modsupport.c:415
#4  0x869f3c6 in Py_BuildValue (format=0x8a1d8a2 "(OOOO)") at modsupport.c:390
#5  0x868f1f7 in eval_code2 (co=0x8f4c1b8, globals=0x8f4c288, 
    locals=0x8f4c288, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1630
#6  0x868d3b8 in PyEval_EvalCode (co=0x8f4c1b8, globals=0x8f4c288, 
    locals=0x8f4c288) at ceval.c:313
#7  0x869aaaf in PyImport_ExecCodeModuleEx (name=0xbfffe914 "site", 
    co=0x8f4c1b8, pathname=0x8a203ea "<frozen>") at import.c:497
#8  0x869bb82 in PyImport_ImportFrozenModule (name=0xbfffe914 "site")
    at import.c:1387
#9  0x869b869 in load_module (name=0xbfffeda4 "site", fp=0x0, 
    buf=0xbfffe914 "site", type=7) at import.c:1232
#10 0x869c44c in import_submodule (mod=0x8bfe48c, subname=0xbfffeda4 "site", 
    fullname=0xbfffeda4 "site") at import.c:1727
#11 0x869c00d in load_next (mod=0x8bfe48c, altmod=0x8bfe48c, 
    p_name=0xbffff1b0, buf=0xbfffeda4 "site", p_buflen=0xbfffeda0)
    at import.c:1583
#12 0x869bc83 in import_module_ex (name=0x0, globals=0x0, locals=0x0, 
    fromlist=0x0) at import.c:1434
#13 0x869bdbc in PyImport_ImportModuleEx (name=0x8a216c3 "site", globals=0x0, 
    locals=0x0, fromlist=0x0) at import.c:1475
#14 0x869bc20 in PyImport_ImportModule (name=0x8a216c3 "site") at import.c:1408
#15 0x86a014b in initsite () at pythonrun.c:429
#16 0x869fdca in Py_Initialize () at pythonrun.c:166
#17 0x80dbf4c in main (argc=1, argv=0xbffff2d4) at main.C:22



Follow-Ups:

Date: 2000-Aug-29 09:12
By: jhylton

Comment:
More details from comp.lang.python:

From: Philipp Jocham <philipp.jocham@salomon.at>
Subject: Re: need help with build on HP-UX
Newsgroups: comp.lang.python
Date: Tue, 29 Aug 2000 11:23:25 GMT
Message-ID: <N2Nq5.235$HH4.3438@nreader1.kpnqwest.net>

Python-1.6b1 on HP-UX 11.00 build with gcc-2.8.1

% ./configure --with-threads
[...]
checking for --with-thread... yes
checking for mach/cthreads.h... no
checking for pth_init in -lpth... no
checking for pthread_create in -lpthread... no
checking for pthread_detach... no
checking for kernel/OS.h... no
checking for pthread_create in -lpthreads... no
checking for pthread_create in -lc_r... no
checking for __d6_pthread_create in -lthread... no
checking for pthread_create in -lcma... yes
[...]
% make
% make test

yields

[...]
        PYTHONPATH= ./python -tt ./Lib/test/regrtest.py 
pthread_mutex_init: Invalid argument
sh: 5019 Memory fault(coredump)
*** Error exit code 139 (ignored)
	
I've experienced a similar problem with python-1.5.2
see
http://sourceforge.net/bugs/?group_id=5470&func=detailbug&bug_id=110665

The problem is the same. The function pthread_create is a macro
in sys/pthread.h and pointing to __pthread_create_system. Finally
pthread_create is detected in /usr/lib/libcma.a, which doesn't have
a compatible pthread_mutex_init function.

Hacking the Makefiles (after running configure) by changing
the LIBS= lines from
	LIBS=           -lnet -lnsl -ldld  -lcma
to
	LIBS=           -lnet -lnsl -ldld  -lpthread -lcl

links the object-files against the pthread library. 
This solution has worked for 1.5.2 and runs at least all tests
correctly for 1.6b1

A solution might be to add a test for 
	__pthread_create_system in /usr/lib/libpthread.a 
in the configure.in script.

-------------------------------------------------------

Date: 2000-Aug-29 09:15
By: jhylton

Comment:
Another suggestion from comp.lang.python

From: Michael Maul <mmaul@nortelnetworks.com>
Subject: Re: need help with build on HP-UX
Newsgroups: comp.lang.python
Date: Tue, 29 Aug 2000 10:33:05 -0400
Message-ID: <39ABC9A0.C584B210@nortelnetworks.com>

Goto link below for instructions and patches for building
python 152 with threads on hpux 10.20 with DCE threads

http://memaul.tripod.com/index.html



-------------------------------------------------------

Date: 2000-Aug-30 02:21
By: lemburg

Comment:
> #8  0x869bb82 in PyImport_ImportFrozenModule (name=0xbfffe914 "site")
>     at import.c:1387

Why does Python try to import site as frozen module ? Could
it be that you have frozen site.py using a pre-2.0 Python
version and that this causes the core dump ?

-------------------------------------------------------

Date: 2000-Sep-15 12:17
By: jhylton

Comment:
No response from original submittor (not me) on this bug.  In another bug report, he mentioned that he wasn't really interested in HPUX, which suggest he won't get back to it.  Other patches/bugs address build and thread issues on HPUX.  All in all, this bug report doesn't seem to be worth keeping.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113037&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 20:21:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 12:21:27 -0700
Subject: [Python-bugs-list] [Bug #110821] On Windows, APIs passing FILE* break with Borland C (PR#121)
Message-ID: <200009151921.MAA20875@delerium.i.sourceforge.net>

Bug #110821, was updated on 2000-Aug-01 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 5
Summary: On Windows, APIs passing FILE* break with Borland C (PR#121)

Details: Jitterbug-Id: 121
Submitted-By: "Brad Clements" <bkc@murkworks.com>
Date: Wed, 3 Nov 1999 15:53:01 -0500
Version: None
OS: None

The system encountered a fatal error 
After command: 
Received: 
The last error code was: Connection refused 

Web interface using {HYPERLINK "http://samba.anu.edu.au/jitterbug/"}Jitterbug 
{HYPERLINK "../python-bugs/"}Public interface 
{HYPERLINK "../python-bugs.private"}Private interface (requires password) 
{HYPERLINK "http://www.python.org/"}Python home page 

-----
Here's what I said for Python 1.5.2 on Win32 #0

PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
usable on WIN32 from non-VC applications because python15.dll is statically 
linked to the MS runtime DLL. Embedding applications that try to use these 
functions are passing in FILE * structures that do not match MS's runtime 
format. 

For example, I'm using Python in a Borland C++ Builder application. Although I 
can open a FILE *, when passed to python15.dll the FILE * is not usable.

The addition of two helper functions would solve this problem:

FILE * PyRun_OpenFile(char *file, char *mode) 
{
  return fopen(file,mode)
}

int PyRun_CloseFile(FILE *ptr)
{
  return fclose(ptr)
}

This way embedding apps could get python15.dll to open the file and it would 
work.

A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..


Brad Clements,                bkc@murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               ICQ: 14856937


====================================================================
Audit trail:
Fri Nov 05 10:31:10 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:10
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121)
Date: Wed, 03 Nov 1999 20:08:11 -0500

> I tried to post a bug, but got this error:
> 
> The system encountered a fatal error 

We were being slammed by a defective spider (or, if you're more
paranoid, by a hacker) so we temporarily turned off the webserver.  It
should be back on now.

> Here's what I said for Python 1.5.2 on Win32 #0
> 
> PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
> usable on WIN32 from non-VC applications because python15.dll is statically 
> linked to the MS runtime DLL. Embedding applications that try to use these 
> functions are passing in FILE * structures that do not match MS's runtime 
> format. 
> 
> For example, I'm using Python in a Borland C++ Builder application. Although I 
> can open a FILE *, when passed to python15.dll the FILE * is not usable.
> 
> The addition of two helper functions would solve this problem:
> 
> FILE * PyRun_OpenFile(char *file, char *mode) 
> {
>   return fopen(file,mode)
> }
> 
> int PyRun_CloseFile(FILE *ptr)
> {
>   return fclose(ptr)
> }
> 
> This way embedding apps could get python15.dll to open the file and it would 
> work.
> 
> A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..

This is an elegant solution.  I think I'll add it.

Could you mail me your suggestion again with the legal boilerplate
included?  See http://www.python.org/1.5/bugrelease.html for the text
and explanation.  Our lawyers require that I request this silliness...

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:10
By: none

Comment:
From: "Brad Clements" <bkc@murkworks.com>
Subject: Re: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121)
Date: Wed, 3 Nov 1999 20:22:21 -0500

Here it is again.

Also, I believe this will resolve  FAQ entry 8.10


> 8.10. Can't get Py_RunSimpleFile() to work.
> This is very sensitive to the compiler vendor, version and (perhaps) even
> options. If the FILE* structure in your embedding program isn't the same as
> is assumed by the Python interpreter it won't work. The Python 1.5.* DLLs
> (python15.dll) are all compiled with MS VC++ 5.0 and with
> multithreading-DLL options (/MD, I think). 
> 
> If you can't change compilers or flags, try using Py_RunSimpleString(). A
> trick to get it to run an arbitrary file is to construct a call to
> execfile() with the name of your file as argument. 
> 
> 
> 
> ---------------------------------------------------------------------------
> -----


> Here's what I said for Python 1.5.2 on Win32 #0
> 
> PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
> usable on WIN32 from non-VC applications because python15.dll is statically 
> linked to the MS runtime DLL. Embedding applications that try to use these 
> functions are passing in FILE * structures that do not match MS's runtime 
> format. 
> 
> For example, I'm using Python in a Borland C++ Builder application. Although I 
> can open a FILE *, when passed to python15.dll the FILE * is not usable.
> 
> The addition of two helper functions would solve this problem:
> 
> FILE * PyRun_OpenFile(char *file, char *mode) 
> {
>   return fopen(file,mode)
> }
> 
> int PyRun_CloseFile(FILE *ptr)
> {
>   return fclose(ptr)
> }
> 
> This way embedding apps could get python15.dll to open the file and it would 
> work.
> 
> A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..


I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



Brad Clements,                bkc@murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               ICQ: 14856937

-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-12 09:01
By: jhylton

Comment:
Guido -- In 1999, you said you would add this feature.  Did you?

-------------------------------------------------------

Date: 2000-Sep-13 03:53
By: gvanrossum

Comment:
This is a feature request.
Jeremy, how's that feature request PEP coming?
-------------------------------------------------------

Date: 2000-Sep-15 12:21
By: jhylton

Comment:
added to pep 42

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110821&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 20:25:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 12:25:39 -0700
Subject: [Python-bugs-list] [Bug #110848] Fwd: Debian Bug#40891: urllib.urlopen/urlretrieve doesn't support passive FTP (PR#58)
Message-ID: <200009151925.MAA21045@delerium.i.sourceforge.net>

Bug #110848, was updated on 2000-Aug-01 14:16
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 5
Summary: Fwd: Debian Bug#40891: urllib.urlopen/urlretrieve doesn't support passive FTP (PR#58)

Details: Jitterbug-Id: 58
Submitted-By: flight@debian.org
Date: Fri, 20 Aug 1999 13:26:17 -0400 (EDT)
Version: 1.5.2
OS: Debian potato


[Forwarded from the Debian bug tracking system]

Sender: Chris Lawrence <quango@watervalley.net>
Package: python-base
Version: 1.5.2-4
Severity: normal
File: /usr/lib/python1.5/urllib.py

urllib doesn't support passive FTP, even though the underlying ftplib
module does.  I dunno what the right approach is (perhaps a urllib
module global variable).  I know some tools (I'm aware of at least
ncftp and wget) autodetect whether PASV is supported by FTP servers;
perhaps that intelligence could be added to ftplib.

(Also: the FTP class's set_pasv() method isn't documented in my
version of python-docs; I haven't checked the new 1.5.2 docs yet
however.)

At the moment, I'm using this ugly hack to get around it:

# Really ugly hack; don't try this at home:
def ftpwrapper_init(self):
    import ftplib
    self.busy = 0
    self.ftp = ftplib.FTP()
    self.ftp.set_pasv(1)
    self.ftp.connect(self.host, self.port)
    self.ftp.login(self.user, self.passwd)
    for dir in self.dirs:
        self.ftp.cwd(dir)

urllib.ftpwrapper.init = ftpwrapper_init
# End really ugly hack



====================================================================
Audit trail:
Mon Aug 30 12:35:03 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:16
By: none

Comment:
From: "Fred L. Drake, Jr." <fdrake@acm.org>
Subject: Re: [Python-bugs-list] Fwd: Debian Bug#40891: urllib.urlopen/urlretrieve doesn't support passive FTP (PR#58)
Date: Mon, 23 Aug 1999 10:03:44 -0400 (EDT)


flight@debian.org writes:
 > Sender: Chris Lawrence <quango@watervalley.net>
 > Package: python-base
 > Version: 1.5.2-4
 > Severity: normal
 > File: /usr/lib/python1.5/urllib.py
...
 > (Also: the FTP class's set_pasv() method isn't documented in my
 > version of python-docs; I haven't checked the new 1.5.2 docs yet

  set_pasv() is documented in the documentation release 1.5.2p1.


  -Fred

--
Fred L. Drake, Jr.	     <fdrake@acm.org>
Corporation for National Research Initiatives

-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-15 12:25
By: jhylton

Comment:
added to pep 42
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110848&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 20:45:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 12:45:57 -0700
Subject: [Python-bugs-list] [Bug #111403] 1.6b1 dumps core dereferencing a NULL tstate
Message-ID: <200009151945.MAA21811@delerium.i.sourceforge.net>

Bug #111403, was updated on 2000-Aug-08 11:26
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: 1.6b1 dumps core dereferencing a NULL tstate

Details: 
  This is from an embeded python.  I've not yet been
able to reproduce this with a small example.  But
perhaps this stacktrace will be of some help.  The
problem seems to be that eval_code2() calls PyThreadState_GET() and gets a NULL pointer back.
This pointer is dereferenced in PyFrame_New() later
on which causes the core dump.  The documentation
seems to say that PyThreadState_GET() should never
return NULL.  So, there must be a bug in there
somewhere.  Here is the stack trace:

#0  0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, 
    locals=0x0) at frameobject.c:120
120             PyFrameObject *back = tstate->frame;
(gdb) bt
#0  0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, 
    locals=0x0) at frameobject.c:120
#1  0x866b022 in eval_code2 (co=0x90fff70, globals=0x9284378, locals=0x0, 
    args=0x8eb362c, argcount=5, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
    owner=0x925d2e8) at ceval.c:397
#2  0x866e4ee in call_function (func=0x911aca0, arg=0x95ea3b0, kw=0x0)
    at ceval.c:2521
#3  0x866e09d in PyEval_CallObjectWithKeywords (func=0x95f7a60, arg=0x95ea3b0, 
    kw=0x0) at ceval.c:2359
#4  0x863f6cf in PyObject_CallObject (o=0x95f7a60, a=0x95ea3b0)
    at abstract.c:1370
#5  0x83e56ed in DrawingArea::process (this=0x95f5f48, event=@0xbfffeb80)
    at DrawingArea.C:971
#6  0x83e5b3d in DrawingArea::dspCB (this=0x95e0b68) at DrawingArea.C:1027
#7  0x832050f in TkFDWatcher::callback (data=0x95e2048) at TkFDWatcher.C:169
#8  0x8752612 in FileHandlerEventProc (evPtr=0x935a4d8, flags=-1)
    at ./tclUnixNotfy.c:405
#9  0x8741d10 in Tcl_ServiceEvent (flags=-1) at ./../generic/tclNotify.c:444
#10 0x8741fae in Tcl_DoOneEvent (flags=2) at ./../generic/tclNotify.c:747
#11 0x86a8757 in Tkapp_MainLoop (self=0x8f6a178, args=0x8eb6af0)
    at ./_tkinter.c:1794
#12 0x866e19e in call_builtin (func=0x8f7b7f0, arg=0x8eb6af0, kw=0x0)
    at ceval.c:2396
#13 0x866e0ab in PyEval_CallObjectWithKeywords (func=0x8f7b7f0, arg=0x8eb6af0, 
    kw=0x0) at ceval.c:2361
#14 0x866d0cb in eval_code2 (co=0x8fb2d18, globals=0x903b9f8, locals=0x0, 
    args=0x8f277b4, argcount=0, kws=0x8f277b4, kwcount=0, defs=0x90447c4, 
    defcount=1, owner=0x0) at ceval.c:1680
#15 0x866cdda in eval_code2 (co=0x8f28b10, globals=0x8f294d0, locals=0x0, 
    args=0x8f27600, argcount=1, kws=0x8f27604, kwcount=0, defs=0x0, 
    defcount=0, owner=0x92c6238) at ceval.c:1579
#16 0x866cdda in eval_code2 (co=0x8f5b300, globals=0x8f294d0, locals=0x0, 
    args=0x8eb8600, argcount=0, kws=0x8eb8600, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1579
#17 0x866cdda in eval_code2 (co=0x8f27ae0, globals=0x8eb0038, 
    locals=0x8eb0038, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1579
#18 0x866afc8 in PyEval_EvalCode (co=0x8f27ae0, globals=0x8eb0038, 
    locals=0x8eb0038) at ceval.c:290
#19 0x867d7c7 in run_node (n=0x8f1d0e0, filename=0x89fcacf "<string>", 
    globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:885
#20 0x867d777 in run_err_node (n=0x8f1d0e0, filename=0x89fcacf "<string>", 
    globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:870
#21 0x867d719 in PyRun_String (str=0x8f1ca68 "import GFE; GFE.main()\n", 
    start=257, globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:847
#22 0x867ce4e in PyRun_SimpleString (
    command=0x8f1ca68 "import GFE; GFE.main()\n") at pythonrun.c:589
#23 0x8681c51 in Py_Main (argc=4, argv=0xbffff204) at main.c:248
#24 0x80d90e1 in main (argc=4, argv=0xbffff204) at main.C:30

Mike Romberg (romberg@fsl.noaa.gov)


Follow-Ups:

Date: 2000-Aug-10 10:23
By: none

Comment:
Followup:  This only happens when python is built
--with-threads.  There appears to be no problem when
threads are not enabled.  It should be noted that our
embeded application uses no threads of any kind (python or
pthreads from C++).  But it may be the case that our code
(C++) is not doing the right thing.

  It should be noted that our application works fine
with python-1.5.2 compiled --with-threads.

-------------------------------------------------------

Date: 2000-Aug-25 07:37
By: jhylton

Comment:
Mike -- Can you provide any more information about this bug?

-------------------------------------------------------

Date: 2000-Aug-25 09:59
By: romberg

Comment:
  My guess (and this is just a guess) is that this may have something
to do with the interaction of python threads and Tkinter.  Since most of
our embeded (and non threaded) python application works fine except
for one specific area, maybe that is thre problem with python 1.6.  Let me
attempt to explain what is going on since it may take some work to
produce a small test case to reproduce the problem.

  Our application uses Tkinter for most of the UI.  We do open a second
connection to the X server using Xlib.  This connection is used to
render complex images into windows.  Tkinter's canvas is just not fast
enough.  I am getting X events from these Xlib created windows via
the Tcl/Tk FileEventHandler (as seen on the stack trace).  I am using the
Tcl/Tk C API to register for these events.

  The case which seems to cause the crash in python comes when I get
a ButtonDown event on my second (non Tkinter) Display.  This event
is delivered from Tcl/Tk to some of our C++ code.  Now for the interesting
bit which I suspect might cause the problem.

  Our C++ code then releases the grab and calls into the python interpreter
for it to post a popup menu (using Tkinter).  This is seen on the stack
as the most recent PyObject_CallObject().  This code attempts to post
the Tkinter popuip menu but dies trying.

  This works fine under python-1.5.2 when it is built --with-thread and
without.  It works fine with python-1.6b2 as long as python is built
without threads.  But when it is built with threads I get this crash.  Is it possible that the Tkinter layer is doing something different threadwise
when python is built --with-threads?
-------------------------------------------------------

Date: 2000-Aug-28 11:28
By: none

Comment:
Another followup.  I've compiled python-1.6b1 on HP-UX-10.20 and
linked the whole thing with purify.  Purify does not show any errors
and everything runs fine when python is built --without-thread.  I was
unable to get python to build on HP-UX --with-thread.  I suspect that
this might have something to do with the DCE threads HPUX uses.

  But in any case.  The extra code linked into our embeded interpreter, is
not doing anything funny with pointers (as far as purify could find).

Mike (romberg@fsl.noaa.gov)

-------------------------------------------------------

Date: 2000-Aug-30 10:46
By: gvanrossum

Comment:
Looks like just another example of HP-UX build problems. (esp. w. threads?)
-------------------------------------------------------

Date: 2000-Aug-30 10:56
By: none

Comment:
  Yea.  I'm not really interested in the HP platform for use with
threads (they are a mess).  I was just using it because that is the
only platform I have access to which can run purify.

  The real problem is under linux (redhat-6.2) when threads are
enabled.  I just wanted to make sure that there were not any funny
memory problems caused by the python extensions we have
added to our embeded python.

  Purify (on HPUX-10.20) seems to give a clean bill of health.  So, I'm
guessing that whattever is causing the core dump under linux is
specific to the thread support in python.

-------------------------------------------------------

Date: 2000-Sep-15 11:42
By: jhylton

Comment:
Another question for you Mike: Have you tried your application on RH 6.2 with 2.0b1?  Does the problem still exist there?  If it is limited to the HP UX platform, which you say you're not actually interested in, I'm going to close this bug report; other people are working on HPUX threading issues.

-------------------------------------------------------

Date: 2000-Sep-15 12:45
By: romberg

Comment:
  Yes.  I've tried things with both 1.6 (final) and 2.0b1 on RH6.2.  For
both versions of python, things work fine as long as --without-thread is
used to build python.  The HPUX issue is not really important to me.
I only tried building things on it to use Purify (to verify that there were
no memory related problems with the code).  I understand that the threads
on HPUX-10.20 are a real mess.  I don't really care much about getting
python threads working on HPUX.

  But I would like to use them on linux (so we can use things like Zope).
So, at this time the symptoms are still that things work fine using
python-1.5.2 (with and without threads).  But, die when threads are
enabled.   None of our code is using any kind of threads (pthreads or
python threads).  I'm not using any part of the python C API which
deals with threads (maybe I should now be doing so?).  So,  the only
thing I can think of is that there is now some kind of thread thing going
on in _tkinter which was not in python-1.5.2.  Since the core dump
seems to happen after our C++ code is woken up from a Tcl filehandler and then calls back into python.  This is just a guess :).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=111403&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 20:52:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 12:52:35 -0700
Subject: [Python-bugs-list] [Bug #111481] os.stat() doesn't return st_rdev
Message-ID: <200009151952.MAA22010@delerium.i.sourceforge.net>

Bug #111481, was updated on 2000-Aug-09 06:38
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 4
Summary: os.stat() doesn't return st_rdev

Details: The call os.stat() returns the fields st_mode, st_ino,
st_nlink, st_uid, st_gid, st_size, st_atime, st_mtime
st_ctime from "struct stat".
To be able to explore device nodes on a linux system
the field st_rdev needed as the major and minor device number is stored in this field.
It would be nice if it could be added as an extra element
in the tuple returned by os.stat, os.lstat etc.


Follow-Ups:

Date: 2000-Aug-29 21:51
By: fdrake

Comment:
We could add an additional element to the end with the st_rdev value, but I'm not convinced that's really the right approach; some other platform that defines another field could get that added at the end of the return tuple, and the the 11th position would have incompatible values.

The "right" solution may be to create a new function (nstat?) that returns either a dictionary or other object that has entries for all the fields (using None for fields a platform doesn't provide values for).
-------------------------------------------------------

Date: 2000-Sep-15 12:52
By: fdrake

Comment:
Added as a feature request to PEP 42.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=111481&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 20:56:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 12:56:23 -0700
Subject: [Python-bugs-list] [Bug #110841] idle dosnt recompile modules changed externally (PR#308)
Message-ID: <200009151956.MAA22156@delerium.i.sourceforge.net>

Bug #110841, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 3
Summary: idle dosnt recompile modules changed externally (PR#308)

Details: Jitterbug-Id: 308
Submitted-By: jnc@ecs.soton.ac.uk
Date: Fri, 28 Apr 2000 13:41:55 -0400 (EDT)
Version: 1.5.2
OS: windows 98


Consider two scripts

showbug.py
=====

import bug1

bug1.bug()
=====
and bug1.py
=====
def bug():
    print 'Bug 5'
=====

both in the same directory.

load showbug.py into idle (0.5) and runit with F5,

the bug function prints Bug 5

Now change bug1.py outside or even with idle, save it. 
dates on disk now show bug1.py is newer than bug1.pyc

rerun showbug.py pressing F5 or ctrl-F5

it still prints Bug 5.

I dont think this behaviour is what is required.Certainly it cost me most
of the afternoon tracking down non-existant problems in my code.

John Carter



====================================================================
Audit trail:
Mon May 22 17:23:04 2000	guido	changed notes
Mon May 22 17:23:04 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:15
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] idle dosnt recompile modules changed externally (PR#308)
Date: Fri, 28 Apr 2000 14:45:30 -0400

> Consider two scripts
> 
> showbug.py
> =====
> 
> import bug1
> 
> bug1.bug()
> =====
> and bug1.py
> =====
> def bug():
>     print 'Bug 5'
> =====
> 
> both in the same directory.
> 
> load showbug.py into idle (0.5) and runit with F5,
> 
> the bug function prints Bug 5
> 
> Now change bug1.py outside or even with idle, save it. 
> dates on disk now show bug1.py is newer than bug1.pyc
> 
> rerun showbug.py pressing F5 or ctrl-F5
> 
> it still prints Bug 5.
> 
> I dont think this behaviour is what is required.Certainly it cost me most
> of the afternoon tracking down non-existant problems in my code.

I appreciate the bug report.  The current definitions of running a
script and importing a module all conspire to get this behavior.
We're working on a major change where IDLE executes your script in a
separate process that is created from scratch each time you use
[ctrl-]F5, and then it will go away.

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-01 14:15
By: none

Comment:
This is all explainable, but I agree it's bad for the user.
We'll fix it by running scripts in a new process.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-15 12:56
By: fdrake

Comment:
Moved to PEP 42 as a feature request to be considered for a future (post 2.0) version.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110841&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 21:01:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 13:01:52 -0700
Subject: [Python-bugs-list] [Bug #112317] os.rename transparent handling of cross-filesystem issues
Message-ID: <200009152001.NAA22372@delerium.i.sourceforge.net>

Bug #112317, was updated on 2000-Aug-19 10:09
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 3
Summary: os.rename transparent handling of cross-filesystem issues

Details: On some systems (specifically, Linux), the rename system call will throw
an EXDEV error if rename is used across filesystems.  It would be convenient for the user if os.rename were extended to handle this transparently (like most mv commands do).

The benefits of this. . .getting rid of code like the following:

try:
    os.rename('ff','/tmp/ff')
except:
    open('/tmp/ff','w').write(open('ff','r').read())
    os.unlink('ff')

Actually, the real benefit is that code (written by morons like myself) using os.rename will continue to work even after the administrator moves the target directory to another filesystem.

I took a quick look at posixmodule.c.  A quick hack changes posix_2str's
signature to the following:

PyObject *args
char *format
int (*func)(const char*, const char *)
int (*special_handler)(const char *, const char *)

and the inner function to:

if (res != 0)
    if ((! special_handler) || (*special_handler)(path1,path2))
         return posix_error()

Of course, then a smart copy routine (includes an unlink step).  The most unclear thing at this point is what to do with the errno.  Would a failure in
the errorhandler report the original errno or its own errno???

Personally, a more general solution would allow the user (python-level) to optionally pass in *their own* error handling function/method.




Follow-Ups:

Date: 2000-Aug-25 07:44
By: jhylton

Comment:
revisit this after 2.0

-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-15 13:01
By: fdrake

Comment:
Moved to PEP 42 as a feature request for a post-2.0 version of Python.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112317&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 21:07:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 13:07:40 -0700
Subject: [Python-bugs-list] [Bug #110661] cgi parsing of query strings (PR#356)
Message-ID: <200009152007.NAA06710@bush.i.sourceforge.net>

Bug #110661, was updated on 2000-Jul-31 14:11
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 3
Summary: cgi parsing of query strings (PR#356)

Details: Jitterbug-Id: 356
Submitted-By: mredar@yahoo.com
Date: Tue, 13 Jun 2000 16:05:59 -0400 (EDT)
Version: 1.5.2
OS: linux


I am currently starting to use the cgi module for python. In general it's quite
nice, I love
the builtin "test" function--very handy.

I do have a quibble with the handling of query strings by the parser. In the
HTML 4 specification, appendix B
 it is stated:

B.2.2 Ampersands in URI attribute values

            The URI that is constructed when a form is submitted may be used as
an anchor-style link (e.g., the href attribute for the A element).
Unfortunately, the use of
            the "&" character to separate form fields interacts with its use in
SGML attribute values to delimit character entity references. For example, to
use the URI
            "http://host/?x=1&y=2" as a linking URI, it must be written <A
href="http://host/?x=1&#38;y=2"> or <A href="http://host/?x=1&amp;y=2">.

            We recommend that HTTP server implementors, and in particular, CGI
implementors support the use of ";" in place of "&" to save authors the trouble
of escaping
            "&" characters in this manner.

The recommended handling of ';' as field delimiters is not implemented in this
module.

Do you have any plans to implement this feature?
My current company is going to use
the ';' separator and it works with other cgi packages (perl & java servlets).
I'd 
love to use python, but this is a stumbling block.

Thanks,

Mark



====================================================================
Audit trail:
Tue Jul 11 08:26:00 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-15 13:07
By: jhylton

Comment:
fixed in rev 1.51 of cgi.py

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110661&group_id=5470


From jeremy@beopen.com  Fri Sep 15 21:18:11 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 15 Sep 2000 16:18:11 -0400 (EDT)
Subject: [Python-bugs-list] Re: [Bug #111403] 1.6b1 dumps core dereferencing a NULL tstate
In-Reply-To: <200009151945.MAA21811@delerium.i.sourceforge.net>
References: <200009151945.MAA21811@delerium.i.sourceforge.net>
Message-ID: <14786.33795.312170.314806@bitdiddle.concentric.net>

  MR> Date: 2000-Sep-15 12:45 By: romberg

  MR> Comment:
  MR>   Yes.  I've tried things with both 1.6 (final) and 2.0b1 on
  MR>   RH6.2.  For
  MR> both versions of python, things work fine as long as
  MR> --without-thread is used to build python.  The HPUX issue is not
  MR> really important to me.  I only tried building things on it to
  MR> use Purify (to verify that there were no memory related problems
  MR> with the code).  I understand that the threads on HPUX-10.20 are
  MR> a real mess.  I don't really care much about getting python
  MR> threads working on HPUX.

  MR>   But I would like to use them on linux (so we can use things
  MR>   like Zope).
  MR> So, at this time the symptoms are still that things work fine
  MR> using python-1.5.2 (with and without threads).  But, die when
  MR> threads are enabled.  None of our code is using any kind of
  MR> threads (pthreads or python threads).  I'm not using any part of
  MR> the python C API which deals with threads (maybe I should now be
  MR> doing so?).  So, the only thing I can think of is that there is
  MR> now some kind of thread thing going on in _tkinter which was not
  MR> in python-1.5.2.  Since the core dump seems to happen after our
  MR> C++ code is woken up from a Tcl filehandler and then calls back
  MR> into python.  This is just a guess :).

Ok.  There is a real bug to report here, but this particular bug
report -- about threads and HPUX -- is not what the real problem is.

Can you open a new bug report that explains what the real problem is?
It seems that you have some application that embeds Python and uses
Tcl that is crashing when Python 2.0b1 is compiled with threads.  Can
you fill in enough details to let someone else help?

Thanks,
Jeremy



From noreply@sourceforge.net  Fri Sep 15 21:11:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 13:11:21 -0700
Subject: [Python-bugs-list] [Bug #113773] Python 2.0b1 selectmodule compile error under Redhat 5.2
Message-ID: <200009152011.NAA22720@delerium.i.sourceforge.net>

Bug #113773, was updated on 2000-Sep-06 18:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: Python 2.0b1 selectmodule compile error under Redhat 5.2

Details: Environment: Redhat 5.2 running the gcc compiler that comes with the
distribution (gcc 2.7.2.3).

'make' failed when compiling selectmodule.c ('./configure' ran ok)because
the following constants were undefined:

POLLRDNORM, POLLRDBAND, POLLWRBAND

The /usr/include/sys/poll.h file does not contain these constants.
Under Redhat 6.2 the constants are defined in the /usr/include/bits/poll.h
file (which is not present in the Redhat 5.2 distribution).

I used the Redhat 6.2 poll.h file and the selectmodule compiled (under
Redhat 5.2) but got the following error when running 
'make test' (it looks like it might be related to the compile problem):

test test_poll crashed -- select.error: (9, 'Bad file descriptor')

1 test failed: test_poll



Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 23:08
By: tim_one

Comment:
Boosted the priority and assigned to Fred.  Don't know what you can do about an older Redhat build problem, and it's not clear that the test failure isn't simply due to mixing files across OS releases.  I'm inclined to blame it on the OS.
-------------------------------------------------------

Date: 2000-Sep-15 13:11
By: fdrake

Comment:
I've asked SourceForge if there are ways to use older versions of operating systems on their compile farm.  Until then, we'll need a volunteer with a RH5.2 system to help with this.

Stuart:  Are you willing to test a patch if I mail it to you?  Thanks.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113773&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 21:14:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 13:14:42 -0700
Subject: [Python-bugs-list] [Bug #113812] Serious garbage collection problems with 2.0b1
Message-ID: <200009152014.NAA06975@bush.i.sourceforge.net>

Bug #113812, was updated on 2000-Sep-07 10:10
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 8
Summary: Serious garbage collection problems with 2.0b1

Details: Since I've installed version 2.0b1, I ran into a few (serious) problems
with a non-trivial application (+80,000 lines of Python). It seems that
the are all related to the new garbage collection:

 - Suddenly, assertions fail because lists have become empty 
   while they shouldn't have. I looks like their elements have been
   garbage collected while they were still reachable.

 - Under other circumstances, I get coredumps which always 
   seem to happen in function "move_root_reachable" of gcmodule.c:
   the "traverse" function pointer seems to contain a bogus address.

 - When I run a Purified version of the interpreter, I can't reproduce
   either problem, but instead, the garbage collector seems to get
   stuck in an endless loop each time. This always happens in the
   same function "move_root_reachable". Purify doesn't produce any 
   relevant warning.

The code runs just fine with version 1.6 of the interpreter, or when I
disable the garbage collector.

Probably relevant is the fact that the objects (10,000's) in my application
are very heavily cross-linked (nearly all links are bi-directional), which 
probably puts a lot of stress on the garbage collector.

My platform: HP-UX 10.20 / c89 compiler


Follow-Ups:

Date: 2000-Sep-07 10:14
By: edg

Comment:
Just one more thing: when I turn on the gc debugging,
the interpreter also seems to get stuck in an endless loop.
-------------------------------------------------------

Date: 2000-Sep-07 14:41
By: jhylton

Comment:
If you set the GC threshold to 0, 
import gc
gc.set_threshold(0)

Do you get the same problem?  Not that I doubt there is some sort of gc problem, but I wonder if there is something going wrong in the accounting or in the collection.

How hard would it be for someone to try to reproduce this bug?  Obviously, it would be helpful to get a smaller test case that has the same behavior as your large program and also tickles the bug.

Do you have any C extension modules in your application or is it pure Python?
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 01:33
By: edg

Comment:
The code is 100% pure Python. 
When I set the threshold to 0, the problem doesn't occur.

The problem is probably very hard to reproduce by anyone else.
The slightest change in the input data for my application
can make the problem go away. Even running an optimized instead
of a debug version of the interpreter can make a difference.

I'm certainly going to try to strip it down, but that won't be 
easy (the same application, using other input data, running 
6 times as long, runs just fine).
-------------------------------------------------------

Date: 2000-Sep-11 07:48
By: edg

Comment:
After 2 full days of debugging, I think that I finally found the 
cause for the gc problems.

To keep a (very) long story short, what I found out was the following:

 - Crashes were due to objects that were destructed twice.
 
 - Endless loops were due to messed-up gc generation lists. The lists should
   always remain perfectly circular, but sometimes they ended up like this:

   list <-> ... <-> X <-> ... <-> ... -> X   

   No wonder that the gc code could easily get stuck; even turning on
   gc debugging caused the counting code to run in circles forever.
   
   The multiple-destruction problem is almost certainly caused by lists being
   messed up.
   
By turning on the debugging code in gc_list_remove and reducing the gc
threshold to a very small value, I could trigger the crash more
reliably, which allowed me to strip down my 80000 line application to this:

-----------------------------------------------------------------------------
#
# Note: to trigger a crash reliably, the debugging code in gc_list_remove
#       _must_ be turned on.
#
import gc
gc.set_threshold(1)

class Node:
   
   def __del__(self):
      dir(self)
 
a = Node()
del a # -> Crash
-----------------------------------------------------------------------------

You wonder: can it be that simple ? :-)

This is what happens when the Node instance `a' is destructed:

 1) The Node instance is removed from the gc lists.
 2) An instance method is created due to the call of the __del__ method.
    THAT METHOD CREATES A NEW REFERENCE TO THE INSTANCE !
 3) The code in the __del__ method triggers the allocation of new
    objects and because the gc threshold has been set very low, it also
    triggers a gc run. 
 4) During the gc run, the instance method is encountered and its reachable
    objects are visited.
 5) Since the instance is referenced by the method, the gc code tries to move
    the instance to another list, while it was no longer present in any list
    -> BINGO

Obviously, the reason why this problem was so hard to reproduce, is the fact
that most classes don't have a __del__ method, and the problem only occurs
when a gc run happens during the execution of a __del__ method.

It think the fix is as simple as this (I'm not too confident, but it 
seems to work):
------------------------------------------------------------------------------
*** Objects/classobject.c.orig	Mon Sep 11 15:55:03 2000
--- Objects/classobject.c	Mon Sep 11 16:12:26 2000
***************
*** 490,496 ****
  #ifdef Py_TRACE_REFS
  	extern long _Py_RefTotal;
  #endif
- 	PyObject_GC_Fini(inst);
  	/* Call the __del__ method if it exists.  First temporarily
  	   revive the object and save the current exception, if any. */
  #ifdef Py_TRACE_REFS
--- 490,495 ----
***************
*** 523,529 ****
  #ifdef COUNT_ALLOCS
  		inst->ob_type->tp_free--;
  #endif
- 		PyObject_GC_Init((PyObject *)inst);
  		return; /* __del__ added a reference; don't delete now */
  	}
  #ifdef Py_TRACE_REFS
--- 522,527 ----
***************
*** 537,542 ****
--- 535,541 ----
  #endif /* Py_TRACE_REFS */
  	Py_DECREF(inst->in_class);
  	Py_XDECREF(inst->in_dict);
+ 	PyObject_GC_Fini(inst);
  	inst = (PyInstanceObject *) PyObject_AS_GC(inst);
  	PyObject_DEL(inst);
  }
------------------------------------------------------------------------------

ie, delay the removal from the gc list till everything has stabilized.

I hope this helps.


-------------------------------------------------------

Date: 2000-Sep-14 23:43
By: nascheme

Comment:
Your analysis looks correct.  Great work.  I think there is a small problem with your fix however.  You should call PyObject_GC_Fini() before the DECREFs on in_class and in_dict.  If, for some reason, decrementing the reference counts of these object causes a garbage collection then the instance could still be on the gc lists and have an invalid in_class or in_dict pointer.
-------------------------------------------------------

Date: 2000-Sep-15 08:02
By: nascheme

Comment:
I've posted a patch.  Should I mark this bug as fixed or does whoever checks in the patch make that change?
-------------------------------------------------------

Date: 2000-Sep-15 09:55
By: tim_one

Comment:
Neil, you're by far "the expert" here, so there's no need to produce a patch unless you *want* someone else to review it first.  Else just commit your changes directly.

As to what to do about this bug, I see that it's assigned to you, so you're responsible for changing the Resolution to Fixed and the Status to Closed when those become true.  Just like in the Patch Manager, whoever is assigned to a thing is responsible for taking the next step -- or assigning it to someone else if they can't or won't (or even just really don't want to, or can't make time to) take the next step.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113812&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 21:21:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 13:21:18 -0700
Subject: [Python-bugs-list] [Bug #111403] 1.6b1 dumps core dereferencing a NULL tstate
Message-ID: <200009152021.NAA07299@bush.i.sourceforge.net>

Bug #111403, was updated on 2000-Aug-08 11:26
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: 1.6b1 dumps core dereferencing a NULL tstate

Details: 
  This is from an embeded python.  I've not yet been
able to reproduce this with a small example.  But
perhaps this stacktrace will be of some help.  The
problem seems to be that eval_code2() calls PyThreadState_GET() and gets a NULL pointer back.
This pointer is dereferenced in PyFrame_New() later
on which causes the core dump.  The documentation
seems to say that PyThreadState_GET() should never
return NULL.  So, there must be a bug in there
somewhere.  Here is the stack trace:

#0  0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, 
    locals=0x0) at frameobject.c:120
120             PyFrameObject *back = tstate->frame;
(gdb) bt
#0  0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, 
    locals=0x0) at frameobject.c:120
#1  0x866b022 in eval_code2 (co=0x90fff70, globals=0x9284378, locals=0x0, 
    args=0x8eb362c, argcount=5, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
    owner=0x925d2e8) at ceval.c:397
#2  0x866e4ee in call_function (func=0x911aca0, arg=0x95ea3b0, kw=0x0)
    at ceval.c:2521
#3  0x866e09d in PyEval_CallObjectWithKeywords (func=0x95f7a60, arg=0x95ea3b0, 
    kw=0x0) at ceval.c:2359
#4  0x863f6cf in PyObject_CallObject (o=0x95f7a60, a=0x95ea3b0)
    at abstract.c:1370
#5  0x83e56ed in DrawingArea::process (this=0x95f5f48, event=@0xbfffeb80)
    at DrawingArea.C:971
#6  0x83e5b3d in DrawingArea::dspCB (this=0x95e0b68) at DrawingArea.C:1027
#7  0x832050f in TkFDWatcher::callback (data=0x95e2048) at TkFDWatcher.C:169
#8  0x8752612 in FileHandlerEventProc (evPtr=0x935a4d8, flags=-1)
    at ./tclUnixNotfy.c:405
#9  0x8741d10 in Tcl_ServiceEvent (flags=-1) at ./../generic/tclNotify.c:444
#10 0x8741fae in Tcl_DoOneEvent (flags=2) at ./../generic/tclNotify.c:747
#11 0x86a8757 in Tkapp_MainLoop (self=0x8f6a178, args=0x8eb6af0)
    at ./_tkinter.c:1794
#12 0x866e19e in call_builtin (func=0x8f7b7f0, arg=0x8eb6af0, kw=0x0)
    at ceval.c:2396
#13 0x866e0ab in PyEval_CallObjectWithKeywords (func=0x8f7b7f0, arg=0x8eb6af0, 
    kw=0x0) at ceval.c:2361
#14 0x866d0cb in eval_code2 (co=0x8fb2d18, globals=0x903b9f8, locals=0x0, 
    args=0x8f277b4, argcount=0, kws=0x8f277b4, kwcount=0, defs=0x90447c4, 
    defcount=1, owner=0x0) at ceval.c:1680
#15 0x866cdda in eval_code2 (co=0x8f28b10, globals=0x8f294d0, locals=0x0, 
    args=0x8f27600, argcount=1, kws=0x8f27604, kwcount=0, defs=0x0, 
    defcount=0, owner=0x92c6238) at ceval.c:1579
#16 0x866cdda in eval_code2 (co=0x8f5b300, globals=0x8f294d0, locals=0x0, 
    args=0x8eb8600, argcount=0, kws=0x8eb8600, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1579
#17 0x866cdda in eval_code2 (co=0x8f27ae0, globals=0x8eb0038, 
    locals=0x8eb0038, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1579
#18 0x866afc8 in PyEval_EvalCode (co=0x8f27ae0, globals=0x8eb0038, 
    locals=0x8eb0038) at ceval.c:290
#19 0x867d7c7 in run_node (n=0x8f1d0e0, filename=0x89fcacf "<string>", 
    globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:885
#20 0x867d777 in run_err_node (n=0x8f1d0e0, filename=0x89fcacf "<string>", 
    globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:870
#21 0x867d719 in PyRun_String (str=0x8f1ca68 "import GFE; GFE.main()\n", 
    start=257, globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:847
#22 0x867ce4e in PyRun_SimpleString (
    command=0x8f1ca68 "import GFE; GFE.main()\n") at pythonrun.c:589
#23 0x8681c51 in Py_Main (argc=4, argv=0xbffff204) at main.c:248
#24 0x80d90e1 in main (argc=4, argv=0xbffff204) at main.C:30

Mike Romberg (romberg@fsl.noaa.gov)


Follow-Ups:

Date: 2000-Aug-10 10:23
By: none

Comment:
Followup:  This only happens when python is built
--with-threads.  There appears to be no problem when
threads are not enabled.  It should be noted that our
embeded application uses no threads of any kind (python or
pthreads from C++).  But it may be the case that our code
(C++) is not doing the right thing.

  It should be noted that our application works fine
with python-1.5.2 compiled --with-threads.

-------------------------------------------------------

Date: 2000-Aug-25 07:37
By: jhylton

Comment:
Mike -- Can you provide any more information about this bug?

-------------------------------------------------------

Date: 2000-Aug-25 09:59
By: romberg

Comment:
  My guess (and this is just a guess) is that this may have something
to do with the interaction of python threads and Tkinter.  Since most of
our embeded (and non threaded) python application works fine except
for one specific area, maybe that is thre problem with python 1.6.  Let me
attempt to explain what is going on since it may take some work to
produce a small test case to reproduce the problem.

  Our application uses Tkinter for most of the UI.  We do open a second
connection to the X server using Xlib.  This connection is used to
render complex images into windows.  Tkinter's canvas is just not fast
enough.  I am getting X events from these Xlib created windows via
the Tcl/Tk FileEventHandler (as seen on the stack trace).  I am using the
Tcl/Tk C API to register for these events.

  The case which seems to cause the crash in python comes when I get
a ButtonDown event on my second (non Tkinter) Display.  This event
is delivered from Tcl/Tk to some of our C++ code.  Now for the interesting
bit which I suspect might cause the problem.

  Our C++ code then releases the grab and calls into the python interpreter
for it to post a popup menu (using Tkinter).  This is seen on the stack
as the most recent PyObject_CallObject().  This code attempts to post
the Tkinter popuip menu but dies trying.

  This works fine under python-1.5.2 when it is built --with-thread and
without.  It works fine with python-1.6b2 as long as python is built
without threads.  But when it is built with threads I get this crash.  Is it possible that the Tkinter layer is doing something different threadwise
when python is built --with-threads?
-------------------------------------------------------

Date: 2000-Aug-28 11:28
By: none

Comment:
Another followup.  I've compiled python-1.6b1 on HP-UX-10.20 and
linked the whole thing with purify.  Purify does not show any errors
and everything runs fine when python is built --without-thread.  I was
unable to get python to build on HP-UX --with-thread.  I suspect that
this might have something to do with the DCE threads HPUX uses.

  But in any case.  The extra code linked into our embeded interpreter, is
not doing anything funny with pointers (as far as purify could find).

Mike (romberg@fsl.noaa.gov)

-------------------------------------------------------

Date: 2000-Aug-30 10:46
By: gvanrossum

Comment:
Looks like just another example of HP-UX build problems. (esp. w. threads?)
-------------------------------------------------------

Date: 2000-Aug-30 10:56
By: none

Comment:
  Yea.  I'm not really interested in the HP platform for use with
threads (they are a mess).  I was just using it because that is the
only platform I have access to which can run purify.

  The real problem is under linux (redhat-6.2) when threads are
enabled.  I just wanted to make sure that there were not any funny
memory problems caused by the python extensions we have
added to our embeded python.

  Purify (on HPUX-10.20) seems to give a clean bill of health.  So, I'm
guessing that whattever is causing the core dump under linux is
specific to the thread support in python.

-------------------------------------------------------

Date: 2000-Sep-15 11:42
By: jhylton

Comment:
Another question for you Mike: Have you tried your application on RH 6.2 with 2.0b1?  Does the problem still exist there?  If it is limited to the HP UX platform, which you say you're not actually interested in, I'm going to close this bug report; other people are working on HPUX threading issues.

-------------------------------------------------------

Date: 2000-Sep-15 12:45
By: romberg

Comment:
  Yes.  I've tried things with both 1.6 (final) and 2.0b1 on RH6.2.  For
both versions of python, things work fine as long as --without-thread is
used to build python.  The HPUX issue is not really important to me.
I only tried building things on it to use Purify (to verify that there were
no memory related problems with the code).  I understand that the threads
on HPUX-10.20 are a real mess.  I don't really care much about getting
python threads working on HPUX.

  But I would like to use them on linux (so we can use things like Zope).
So, at this time the symptoms are still that things work fine using
python-1.5.2 (with and without threads).  But, die when threads are
enabled.   None of our code is using any kind of threads (pthreads or
python threads).  I'm not using any part of the python C API which
deals with threads (maybe I should now be doing so?).  So,  the only
thing I can think of is that there is now some kind of thread thing going
on in _tkinter which was not in python-1.5.2.  Since the core dump
seems to happen after our C++ code is woken up from a Tcl filehandler and then calls back into python.  This is just a guess :).
-------------------------------------------------------

Date: 2000-Sep-15 13:21
By: romberg

Comment:
  This bug is about the crash on linux with the threads enabled.  The
stack trace comes from a linux system.  2.0b1 crashes with a very
similar looking stack.  I probably made a mistake in bringing up the
trouble I was having with the HPUX threads in the discussion of this
linux bug..  If you would like, I could start another bug report.  But
it would be more or less the same as this one.  The stack trace after
the crash is identical.

  I am willing to do some poking around to help figure out what is
going on here.  It would probably be helpful to have some more
details about what is going on after the point my code calls PyObject_CallObject().  I could put in some PyObject_Print()s or
something if that would help.  I just don't know enough about how
the python internals are supposed to work to know what to do next.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=111403&group_id=5470


From noreply@sourceforge.net  Fri Sep 15 21:37:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 13:37:54 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200009152037.NAA23631@delerium.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 13:45
By: fdrake

Comment:
We need to know the output of "uname -s" and "uname -r" for this system.  (If "uname -r" reports an error, please try "uname -v".)

Are you willing to test a modified configure script on this platform?

What additional library is required for the mmap module?
-------------------------------------------------------

Date: 2000-Sep-12 21:59
By: fdrake

Comment:
Received the following response from Daniel Dittmar <ddittmar@users.sourceforge.net>:

> We need to know the output of "uname -s" and "uname -r" 
> for this system.  (If "uname -r" reports an error, please 
> try "uname -v".)

uname -s
ReliantUNIX-N

uname -r
5.45


> Are you willing to test a modified configure script on
> this platform?

sure.

> What additional library is required for the mmap module?

The man page states -lucb. This didn't work on my machine 
as the BSD compatibility layer is not active. I tell you 
more as soon as I know how to activate it.

***********

Another problem: to detect pthreads, the compiler must be 
called with -Kpthread. Otherwise, pthread.h goes into a 
branch where it tries to include a non existent header, 
fails, and configure reports 'no pthreads'.

Daniel

-------------------------------------------------------

Date: 2000-Sep-15 11:57
By: fdrake

Comment:
For the mmap issue, I've added a comment to Modules/Setup.in to let installers know that -lucb may be needed.  In revision 1.110.
-------------------------------------------------------

Date: 2000-Sep-15 13:37
By: fdrake

Comment:
I'm sending a modified version of  the configure script to Daniel Dittmar to test for the first two points in this bug report.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470


From jeremy@beopen.com  Fri Sep 15 21:49:51 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 15 Sep 2000 16:49:51 -0400 (EDT)
Subject: [Python-bugs-list] Re: [Bug #111403] 1.6b1 dumps core dereferencing a NULL tstate
In-Reply-To: <200009152021.NAA07299@bush.i.sourceforge.net>
References: <200009152021.NAA07299@bush.i.sourceforge.net>
Message-ID: <14786.35695.898758.725591@bitdiddle.concentric.net>

  MR>   This bug is about the crash on linux with the threads enabled.
  MR>   The
  MR> stack trace comes from a linux system.  2.0b1 crashes with a
  MR> very similar looking stack.  I probably made a mistake in
  MR> bringing up the trouble I was having with the HPUX threads in
  MR> the discussion of this linux bug..  If you would like, I could
  MR> start another bug report.

It would be helpful to start a new bug report.  The HPUX stuff makes
it confusing to read.  One question I have from the original stack
trace-- is this an app that embeds Python or its it just an extension
module?  The stak trace looks like it is just doing a normal Python
startup via Py_Main.

I'm not at all familiar with Tkinter, so I'll assign the new bug to
someone who is.  I wonder if the problem is that your C++ code is
being called via a callback -- and then you call back into Python
without acquiring the interpreter lock.  I think this would be
consistent with a NULL thread state.

Jeremy






From jeremy@beopen.com  Fri Sep 15 21:55:46 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 15 Sep 2000 16:55:46 -0400 (EDT)
Subject: [Python-bugs-list] [Bug #113812] Serious garbage collection problems with 2.0b1
In-Reply-To: <200009152014.NAA06975@bush.i.sourceforge.net>
References: <200009152014.NAA06975@bush.i.sourceforge.net>
Message-ID: <14786.36050.904650.444337@bitdiddle.concentric.net>

One more thing on this bug, Neil.  It is good practice to add a test
to the gc test suite that would have caught the reported bug.  It
looks like the bug report history contains just such a test case, so
it should be a no brainer.

Jeremy


From noreply@sourceforge.net  Fri Sep 15 22:14:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 14:14:05 -0700
Subject: [Python-bugs-list] [Bug #110819] test suite incomplete (PR#1)
Message-ID: <200009152114.OAA25015@delerium.i.sourceforge.net>

Bug #110819, was updated on 2000-Aug-01 14:09
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 1
Summary: test suite incomplete (PR#1)

Details: Jitterbug-Id: 1
Submitted-By: guido@python.org
Date: Mon, 3 May 1999 17:31:27 -0400 (EDT)
Version: any
OS: any


Subject says it all.  Not everything is tested.


====================================================================
Audit trail:
Mon May 03 18:01:53 1999	guido	sent reply 1
Mon Jul 12 15:33:07 1999	guido	moved from incoming to request
Mon Jul 12 19:09:04 1999	guido	changed notes

Follow-Ups:

Date: 2000-Aug-01 14:10
By: none

Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: test suite incomplete (PR#1)
Date: Mon May  3 18:01:53 1999

I know, I know...

-------------------------------------------------------

Date: 2000-Aug-01 14:10
By: none

Comment:
Of course, it's not likely that this will ever by completely resolved... :-)
-------------------------------------------------------

Date: 2000-Aug-01 17:45
By: jhylton

Comment:
Thought you'd like to have this one assigned to you, Skip <wink>.
-------------------------------------------------------

Date: 2000-Aug-05 06:03
By: montanaro

Comment:
as if i didn't have enough to do... ;-)
maybe this is a good excuse to look at pyUnit.  More tests
might get written with a more easily used testing framework.

-------------------------------------------------------

Date: 2000-Sep-15 14:14
By: montanaro

Comment:
added this to pep-0042

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110819&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 00:22:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 16:22:04 -0700
Subject: [Python-bugs-list] [Bug #114553] copy.deepcopy() barfs if it hits class/function/method
Message-ID: <200009152322.QAA29885@delerium.i.sourceforge.net>

Bug #114553, was updated on 2000-Sep-15 16:22
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: copy.deepcopy() barfs if it hits class/function/method

Details: The 'copy.deepcopy()' function blows up if it stumbles across class, function, or method objects as it recurses into objects.  This is (at least partly) because of an inconsistency between the dispatch table used for plain-vanilla 'copy()' and for 'deepcopy()': the 'copy()' dispatch table has an entry for ClassType, but the 'deepcopy()' dispatch table does not.

Also, neither dispatch table has entries for FunctionType or MethodType.  This isn't a big deal for 'copy()', since it's unlikely that you'd do 'copy(my_func)', but it's inconsistent since you can do 'copy(my_class)' -- and the class object my_class is *not* copied, it's treated atomically, like strings or ints.  For consistency, functions and methods should probably be treated the same as class objects.

Here's a script that demonstrates the problem:

from copy import copy, deepcopy

def f(): pass
class K: pass

# can copy a list that contains a function, since we don't
# dive into the list
l = [1, 2, f]
try: copy(l)
except: print "error copying list with function"
else: print "ok copying list with function"

# but we can't copy the function
try: copy(f)
except: print "error copying function"
else: print "ok copying function"

# also can't deep copy a list with a function because deepcopy() dives in
try: deepcopy(l)
except: print "error deep-copying list with function"
else: print "ok deep-copying list with function"

# nor can we deepcopy the function alone
try: deepcopy(f)
except: print "error deep-copying function"
else: print "ok deep-copying function"

# can copy list with class object
l = ["foo", K]
try: copy(l)
except: print "error copying list with class object"
else: print "ok copying list with class object"

# but can't deepcopy it
try: deepcopy(l)
except: print "error deep-copying list with class object"
else: print "ok deep-copying list with class object"

(Hmm, I don't see a test script for the 'copy' module -- perhaps this would be a good start.)

This gives the same output for me with Python 1.5.2, 1.6, and 2.0b1 (all on Linux):

ok copying list with function
error copying function
error deep-copying list with function
error deep-copying function
ok copying list with class object
error deep-copying list with class object

And here's a patch that makes everything come out OK:

--- copy.py.orig        Fri Sep 15 19:19:05 2000
+++ copy.py.hacked      Fri Sep 15 19:20:20 2000
@@ -92,6 +92,8 @@
 d[types.TypeType] = _copy_atomic
 d[types.XRangeType] = _copy_atomic
 d[types.ClassType] = _copy_atomic
+d[types.FunctionType] = _copy_atomic
+d[types.MethodType] = _copy_atomic
 
 def _copy_list(x):
        return x[:]
@@ -165,6 +167,9 @@
 d[types.CodeType] = _deepcopy_atomic
 d[types.TypeType] = _deepcopy_atomic
 d[types.XRangeType] = _deepcopy_atomic
+d[types.ClassType] = _deepcopy_atomic
+d[types.FunctionType] = _deepcopy_atomic
+d[types.MethodType] = _deepcopy_atomic
 
 def _deepcopy_list(x, memo):
        y = []


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114553&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 00:22:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 16:22:30 -0700
Subject: [Python-bugs-list] [Bug #110612] anydbm can't handle dumbdbm (PR#200)
Message-ID: <200009152322.QAA29894@delerium.i.sourceforge.net>

Bug #110612, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: anydbm can't handle dumbdbm (PR#200)

Details: Jitterbug-Id: 200
Submitted-By: aa8vb@yahoo.com
Date: Wed, 9 Feb 2000 13:05:57 -0500 (EST)
Version: 1.5.2
OS: IRIX 6.5


Basically, anydbm won't open dumbdbm files that anydbm created.

   >>> import anydbm
   >>> db = anydbm.open( "database", "c" )
   >>> db[ "1" ] = "one"
   >>> db.close()
   >>> db = anydbm.open( "database", "r" )
   Traceback (innermost last):
     File "<stdin>", line 1, in ?
     File "/home/rhh/software/python-1.5.2/lib/python1.5/anydbm.py", line 80,
in
 open
       raise error, "need 'c' or 'n' flag to open new db"
   anydbm.error: need 'c' or 'n' flag to open new db

More details can be found in the c.l.python thread "anydbm - a simple
question".

I searched for a matching bug and didn't find one in the database.  Also,
I verified my whichdb.py matches what's currently in CVS, so I don't think
this has been fixed yet.

Thanks,

Randall


====================================================================
Audit trail:
Wed Feb 23 21:40:05 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 02:24
By: moshez

Comment:
It was a simple glitch in whichdb -- it didn't recognize the
dumbdbm format. Fixed it.

-------------------------------------------------------

Date: 2000-Sep-15 16:22
By: none

Comment:
I think this bug has appeared again. I get the exact same error with Python 1.6, but it works with 1.5.2.


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110612&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 01:15:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 17:15:09 -0700
Subject: [Python-bugs-list] [Bug #110612] anydbm can't handle dumbdbm (PR#200)
Message-ID: <200009160015.RAA31691@delerium.i.sourceforge.net>

Bug #110612, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: anydbm can't handle dumbdbm (PR#200)

Details: Jitterbug-Id: 200
Submitted-By: aa8vb@yahoo.com
Date: Wed, 9 Feb 2000 13:05:57 -0500 (EST)
Version: 1.5.2
OS: IRIX 6.5


Basically, anydbm won't open dumbdbm files that anydbm created.

   >>> import anydbm
   >>> db = anydbm.open( "database", "c" )
   >>> db[ "1" ] = "one"
   >>> db.close()
   >>> db = anydbm.open( "database", "r" )
   Traceback (innermost last):
     File "<stdin>", line 1, in ?
     File "/home/rhh/software/python-1.5.2/lib/python1.5/anydbm.py", line 80,
in
 open
       raise error, "need 'c' or 'n' flag to open new db"
   anydbm.error: need 'c' or 'n' flag to open new db

More details can be found in the c.l.python thread "anydbm - a simple
question".

I searched for a matching bug and didn't find one in the database.  Also,
I verified my whichdb.py matches what's currently in CVS, so I don't think
this has been fixed yet.

Thanks,

Randall


====================================================================
Audit trail:
Wed Feb 23 21:40:05 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 02:24
By: moshez

Comment:
It was a simple glitch in whichdb -- it didn't recognize the
dumbdbm format. Fixed it.

-------------------------------------------------------

Date: 2000-Sep-15 16:22
By: none

Comment:
I think this bug has appeared again. I get the exact same error with Python 1.6, but it works with 1.5.2.


-------------------------------------------------------

Date: 2000-Sep-15 17:15
By: gvanrossum

Comment:
Reopened and assigned to Jeremy since a comment claims it's reappeared in 1.6.  Can you check 2.0?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110612&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 02:01:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 18:01:04 -0700
Subject: [Python-bugs-list] [Bug #110599] bug (Incorrect signal processing) - Python 1.5.2 (PR#102)
Message-ID: <200009160101.SAA00896@delerium.i.sourceforge.net>

Bug #110599, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: bug (Incorrect signal processing) - Python 1.5.2 (PR#102)

Details: Jitterbug-Id: 102
Submitted-By: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" <Vladimir.Benes@pvt.cz>
Date: Mon, 11 Oct 1999 13:00:07 +0200
Version: None
OS: None

Good afternoon,

    I have found a bug on Python 1.5.2. This bug doesn't occur on Python
1.5.1.

Python versions and OS:
- Python 1.5.1. at Debian GNU/Linux 2.0.36
- Python 1.5.2. at Debian GNU/Linux 2.2.9

Bug: Incorrect signal processing (Python 1.5.2).
    Process can assign procedure for signal processing. When process is
waiting at system call and this signal occur, then the signal assigned
procedure is otherwise correctly completed but then waiting at system call
is broken and process continues.

    Here is a simple program for demonstrate this bug:

#!/usr/bin/python
import signal
import sys

def signal_handle(signum, frame) :
  signal.signal(signal.SIGALRM, signal_handle)
  signal.alarm(2)
  print "signal"

signal_handle(0,0)
a=sys.stdin.readline()
print "Line examined..."
b=sys.stdin.readline()
print "Line examined..."
print a,b,"end"
# end of example

    Correct behaviour: Message "Line examined..." occurs only after pressing
ENTER by user.
    Bug: Message "Line examined..." occurs immediately after signal occured
and procedure signal_handle finished. Output then look thus (when no input
entered):

signal
signal
Line examined...
signal
Line examined...
  end

    This bug appears at any signal occur and whatever process waiting at
system call. Some system call even produces exception (e.g. waiting for data
or connection on socket).

    Bug is perhaps caused by wrong seting "siginterrupt" on module signal. I
haven't found any way how call in Python program "siginterrupt" for correct
behavior of signal processing.

        Good bye, V. Benes

****************************************************************************
    Ing. Vladimir Benes, pvt.net
    PVT, a.s., OZ Chomutov
    e-mail: vladimir.benes@pvt.cz, vladimir.benes@sms.paegas.cz
****************************************************************************



====================================================================
Audit trail:
Mon Oct 11 18:12:13 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:05
By: none

Comment:
From: Jeremy Hylton <jeremy@cnri.reston.va.us>
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102)
Date: Tue, 12 Oct 1999 12:04:42 -0400 (EDT)

>>>>> "VB" == Vladimir Benes <Vladimir.Benes@pvt.cz> writes:

  VB> Bug: Incorrect signal processing (Python 1.5.2).  Process can
  VB> assign procedure for signal processing. When process is waiting
  VB> at system call and this signal occur, then the signal assigned
  VB> procedure is otherwise correctly completed but then waiting at
  VB> system call is broken and process continues.

[example program]

I see the behavior you report for 1.5.2 on Solaris 2.6.

  VB>     This bug appears at any signal occur and whatever process
  VB> waiting at system call. Some system call even produces exception
  VB> (e.g. waiting for data or connection on socket).

These issues always occur in twos don't they.  There was a similar
question posted on comp.lang.python yesterday.  I'm not sure that the
behavior you're seeing is a bug; it is the behavior I would expect.
Slow system calls are interrupted, returning EINTR, when a signal
occurs. 

  VB>     Bug is perhaps caused by wrong seting "siginterrupt" on
  VB> module signal. I haven't found any way how call in Python
  VB> program "siginterrupt" for correct behavior of signal
  VB> processing.

Perhaps the signal module for Python should be extended to support
siginterrupt, but it sounds like it will only reduce the number of
system calls that can be interrupted.  The Solaris man page says:

    NOTES
         Use of these interfaces should be restricted to only  appli-
         cations  written  on BSD platforms.  Use of these interfaces
         with any of the system libraries or in multi-threaded appli-
         cations is unsupported.

It doesn't sound particularly safe.

Jeremy

-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" <Vladimir.Benes@pvt.cz>
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102)
Date: Wed, 13 Oct 1999 09:19:44 +0200

From: Jeremy Hylton <jeremy@cnri.reston.va.us>
To: Vladimir.Benes@pvt.cz <Vladimir.Benes@pvt.cz>
Cc: python-bugs-list@python.org <python-bugs-list@python.org>;
bugs-py@python.org <bugs-py@python.org>
Date: 12. 10. 1999 18:04
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python
1.5.2 (PR#102)


JH>I see the behavior you report for 1.5.2 on Solaris 2.6.


    You don't write whether this bug appeared there.

 JH> ......  I'm not sure that the
 JH> behavior you're seeing is a bug; it is the behavior I would expect.
 JH> Slow system calls are interrupted, returning EINTR, when a signal
 JH> occurs.


    I'am sure that this behavior is bug becouse:

1. I wrote the same program in C language (see below).
2. I ran this program at the same machine where the Python *)
    program works incorrectly.
3. Behavior of C program is correct (line scan is ended only when
    user press ENTER and this end is independed on signal).

=> The C program works correct and the same Python *) program fails at the
same platform. Base run of program should by independed on signal processing
except program terminating signals. It's independed at C program but
incorrect processed by Python *) programs.

*) only Python 1.5.2; Python 1.5.1 here works correctly

    Here is the mentioned program:

#include<stdio.h>
#include <unistd.h>
#include <signal.h>

void signal_handle(int signum) {
  signal(SIGALRM, signal_handle);
  alarm(2);
  printf("signal\n\r");
}

void main(void) {
  char a[100], b[100];

  signal_handle(0);
  scanf("%s",&a);
  printf("Line examined...\n\r");
  scanf("%s",&b);
  printf("Line examined...\n\r");
  printf("%s\t%s\tend\n\r", a, b);
}

 VB>     Bug is perhaps caused by wrong seting "siginterrupt" on
 VB> module signal. I haven't found any way how call in Python
 VB> program "siginterrupt" for correct behavior of signal
 VB> processing.


 JH> Perhaps the signal module for Python should be extended to support
 JH> siginterrupt, but it sounds like it will only reduce the number of
 JH> system calls that can be interrupted.  .......


    Sorry, I wrong formulated possible couse of bug. I will try to specify
my idea:
    It looks that there is any wrong calling "siginterupt" on signal module.
Python libraries doesn't allow me to try correct this bug by calling
"siginiterrupt" in my program before signal setting. But the best way is to
reapir bug on signal module.

    Good bye, V. Benes


-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102)
Date: Wed, 13 Oct 1999 08:57:25 -0400

>  JH> ......  I'm not sure that the
>  JH> behavior you're seeing is a bug; it is the behavior I would expect.
>  JH> Slow system calls are interrupted, returning EINTR, when a signal
>  JH> occurs.
> 
[Vladimir]
>     I'am sure that this behavior is bug becouse:

When I first thought about this, I agreed with Vladimir.  If you look
careful at his code, readline() is returning "" when the alarm goes
off; this can't be right, because it's not an end of file.  It should
either raise an exception (EINTR) or return one line of valid data.

On the other hand, whatever solution is chosen should be careful that
other signals raise exceptions; in particular you want SIGINT (^C) to
be translated to a KeyboardError exception.  Since the C code in
readline() can't tell which signal was trapped or whether the handler
raised an exception, it has two choices, both of which are bad:

- Raise an IOError exception, honoring the EINTR.  Unfortunately, in
the SIGINT/^C case, the handler will run after this exception is
raised, and it will raise KeyboardError.  The Python program will
*probably* see the KeyboardError exception, but it is not guaranteed
that the signal handler is run immediately.  (The Python-level signal
handler is run only after the Python virtual machine finishes the
current instruction, i.e. after the readline() completes.)

- Continue to read a line, ignoring the EINTR.  Unfortunately, this
would mean that the user has to type ^C followed by Return to
interrupt the program!

An alternative solution would be to arrange for the Python-level
interrupt handler to execute inside the readline() method, and to
restart the read only when it raises no exception; but this would
require a massive code rewrite (you'd want this behavior in any place
that does a blocking I/O operation).

Concluding, I think Vladimir is better off not to use signal handlers
in the way he is using them now.  Python's emulation of signal
semantics is sufficiently different from C that you can't rely on the
same behavior.  (And note that in C, signal handlers are usually
broken anyway; e.g. the code you write, which prints something inside
the signal handler, is broken on C too because you don't know the
state of stdout when the handler is invoked.)

I looked at what could be different between 1.5.1 and 1.5.2, and found 
that the call to siginterrupt() to disable restarting system calls was 
added after 1.5.1.  Given the alternatives, I think I like the 1.5.2
behavior better than the 1.5.1 behavior.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" <Vladimir.Benes@pvt.cz>
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102)
Date: Wed, 13 Oct 1999 16:34:39 +0200

>...
>Concluding, I think Vladimir is better off not to use signal handlers
>in the way he is using them now.  Python's emulation of signal
>semantics is sufficiently different from C that you can't rely on the
>same behavior.  (And note that in C, signal handlers are usually
>broken anyway; e.g. the code you write, which prints something inside
>the signal handler, is broken on C too because you don't know the
>state of stdout when the handler is invoked.)


    Well, meantioned programs were only very simple demos for demonstrate
incorrect signal processing. But exists a large range of meaningful programs
where is necessary both synchronous and asynchronous signal processing - and
signal can be triggered whenever.

    Example of C symbolic structure this programs:

....
int event_flag;
void trigger_signal(int signum) {
  // asynchonous signal processing
  event_flag = MY_EVENT; // only flag set
}
void initialize_signal(int sig) {
  event_flag = NO_EVENT; // initialize
  signal(sig, trigger_signal);
}
int main() {
  initialize_signal(SIGTERM);
  while (1) {
    my_func();
    // synchronous signal processing:
    if (event_flag==MY_EVENT) my_sync_trigger();
  }
}

    Signal can be raised whenever when function my_func runs => flag
event_flag is then set but my_func "does't know" his and continues at own
processing. Signal should not influence my_func becouse my_func "doesn't
know" both this signal and flag event_flag. Function event_flag can wait for
system call (read, write, connect, etc). Incoming signal should not finish
this waiting after trigger_signal function processing. So my_func is
independed on signal processing and "does'nt know" signals.

    Program tests the flag at any "safe" location(s). If this flag is set,
program run specific synchronous signal processing. It can be for example
safe program end or synchronous SIGALRM processing.

    Python programs can by compose similar this example.

>I looked at what could be different between 1.5.1 and 1.5.2, and found
>that the call to siginterrupt() to disable restarting system calls was
>added after 1.5.1.  Given the alternatives, I think I like the 1.5.2
>behavior better than the 1.5.1 behavior.


    But then old Python programs writen for Python 1.5.1 are not compatible
with Python 1.5.2. in this feature. I thing that better way is to let this
behavior equal as in Python 1.5.1. but allow programs to call either new
function "siginterrupt" at signal module (more flexible solution) or any
else new function at signal module to set behavior signal processing by Your
idea.

        Good bye, V. Benes


-------------------------------------------------------

Date: 2000-Aug-10 11:45
By: gvanrossum

Comment:
Sorry, I can't take this.  It's an issue though!  There are a bunch of signal related bugs in Linux...
-------------------------------------------------------

Date: 2000-Sep-13 03:42
By: gvanrossum

Comment:
Confirmed with python 2.0b1 on Linux.

Note that this is *not* the same bug as #110611 -- here, threads and readline don't matter (confirmed).
-------------------------------------------------------

Date: 2000-Sep-15 18:01
By: gvanrossum

Comment:
Something should be done, but it's not easy.
I've added this to PEP 42 as a feature request.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110599&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 02:59:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 18:59:41 -0700
Subject: [Python-bugs-list] [Bug #114557] Nuke hard tabs from the std library
Message-ID: <200009160159.SAA02849@delerium.i.sourceforge.net>

Bug #114557, was updated on 2000-Sep-15 18:59
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Nuke hard tabs from the std library

Details: It was agreed for 2.0b1 that all std libraries modules would use 4-space indents and no hard tabs.  This didn't happen, due to a misunderstanding.  Repair that after 2.0final is released (would be sooner, except about 250 files are affected, and that much fiddling carries some risk).

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114557&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 03:01:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 19:01:12 -0700
Subject: [Python-bugs-list] [Bug #114557] Nuke hard tabs from the std library
Message-ID: <200009160201.TAA02965@delerium.i.sourceforge.net>

Bug #114557, was updated on 2000-Sep-15 18:59
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: Later
Bug Group: Feature Request
Priority: 5
Summary: Nuke hard tabs from the std library

Details: It was agreed for 2.0b1 that all std libraries modules would use 4-space indents and no hard tabs.  This didn't happen, due to a misunderstanding.  Repair that after 2.0final is released (would be sooner, except about 250 files are affected, and that much fiddling carries some risk).

Follow-Ups:

Date: 2000-Sep-15 19:01
By: tim_one

Comment:
Moved to PEP42.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114557&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 03:07:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 19:07:59 -0700
Subject: [Python-bugs-list] [Bug #110683] can't compile with SSL support on WinNT (PR#403)
Message-ID: <200009160207.TAA03172@delerium.i.sourceforge.net>

Bug #110683, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 4
Summary: can't compile with SSL support on WinNT (PR#403)

Details: Jitterbug-Id: 403
Submitted-By: falk.lehmann@gmx.net
Date: Mon, 17 Jul 2000 21:59:56 -0400 (EDT)
Version: 1.6a2
OS: WinNT 4.0


I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00.
The compiler stops with some warnings and an error message:
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2081) : error C2099: initializer
is not a constant

K:\Projects\Python-1.6a2\Modules\socketmodule.c(1947) : warning C4047:
'function' : 'int ' differs in levels of indirection from 'void *'
K:\Projects\Python-1.6a2\Modules\socketmodule.c(1947) : warning C4024: 'memset'
: different types for formal and actual parameter 2
K:\Projects\Python-1.6a2\Modules\socketmodule.c(1948) : warning C4047:
'function' : 'int ' differs in levels of indirection from 'void *'
K:\Projects\Python-1.6a2\Modules\socketmodule.c(1948) : warning C4024: 'memset'
: different types for formal and actual parameter 2
K:\Projects\Python-1.6a2\Modules\socketmodule.c(1933) : warning C4101: 'str' :
unreferenced local variable
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2083) : warning C4047:
'initializing' : 'int ' differs in levels of indirection from 'char [4]'
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2084) : warning C4047:
'initializing' : 'char *' differs in levels of indirection from 'unsigned int '
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2087) : warning C4047:
'initializing' : 'int ' differs in levels of indirection from 'void (__cdecl
*)(struct _object *)'
K:\Projects\Python-1.6a2\Modules\socketmodule.c(2089) : warning C4047:
'initializing' : 'int (__cdecl *)(struct _object *,struct _iobuf *,int )'
differs in levels of indirection from 'struct _object *(__cdecl *)(struct
_object *,char *)'

Thanks in advance for fixing (at least the error).

Falk



====================================================================
Audit trail:
Tue Jul 25 07:25:55 2000	guido	changed notes
Tue Jul 25 07:25:55 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Guido van Rossum <guido@beopen.com>
Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403)
Date: Mon, 24 Jul 2000 11:35:24 -0500

> I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00.

Please try the current CVS tree (on its way to 2.0); we have no
problems compiling this on VC 6.0.

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-01 14:02
By: none

Comment:
From: Falk Lehmann <Falk.Lehmann@gmx.net>
Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403)
Date: Mon, 24 Jul 2000 13:46:45 -0500

[magical fwd by GvR]

Guido,
sorry, but forgot to write, that I switched on the USE_SSL macro.
And then the _socket module does not compile.

Falk

> > I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00.
> 
> Please try the current CVS tree (on its way to 2.0); we have no
> problems compiling this on VC 6.0.
> 
> --Guido van Rossum (home page: http://dinsdale.python.org/~guido/)
> 


-------------------------------------------------------

Date: 2000-Aug-01 14:02
By: none

Comment:
From: Guido van Rossum <guido@beopen.com>
Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403)
Date: Mon, 24 Jul 2000 14:00:20 -0500

> sorry, but forgot to write, that I switched on the USE_SSL macro.
> And then the _socket module does not compile.

It appears that the Python SSL code hasn't been ported to Windows.
We'll add this to our TODO list, but it's low priority...  Perhaps you
could give it a shot yourself?  See www.python.org/patches/ for how to
contribute.

--Guido van Rossum (home page: http://dinsdale.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-01 14:02
By: none

Comment:
Windows compile fails when using openSSL.
-------------------------------------------------------

Date: 2000-Aug-23 10:35
By: jhylton

Comment:
This is a bug.  Standard extensions modules should compile, even on obscure platforms like Windows NT.  Need a Windows user with time to install OpenSSL to fix this.

-------------------------------------------------------

Date: 2000-Aug-30 12:01
By: gvanrossum

Comment:
Let's not worry about this for 2.0. While the OpenSSL support is part of the socket module, we don't have the resources right now to port that support to Windows.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 15:08
By: fdrake

Comment:
As we've discussed, this is not an issue for 2.0.  Assigned to Tim for resurrection when appropriate since this is Windows-specific. 
-------------------------------------------------------

Date: 2000-Sep-15 19:07
By: tim_one

Comment:
Moved to PEP42, awaiting a volunteer can do this.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110683&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 03:10:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 19:10:15 -0700
Subject: [Python-bugs-list] [Bug #110599] bug (Incorrect signal processing) - Python 1.5.2 (PR#102)
Message-ID: <200009160210.TAA19366@bush.i.sourceforge.net>

Bug #110599, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 5
Summary: bug (Incorrect signal processing) - Python 1.5.2 (PR#102)

Details: Jitterbug-Id: 102
Submitted-By: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" <Vladimir.Benes@pvt.cz>
Date: Mon, 11 Oct 1999 13:00:07 +0200
Version: None
OS: None

Good afternoon,

    I have found a bug on Python 1.5.2. This bug doesn't occur on Python
1.5.1.

Python versions and OS:
- Python 1.5.1. at Debian GNU/Linux 2.0.36
- Python 1.5.2. at Debian GNU/Linux 2.2.9

Bug: Incorrect signal processing (Python 1.5.2).
    Process can assign procedure for signal processing. When process is
waiting at system call and this signal occur, then the signal assigned
procedure is otherwise correctly completed but then waiting at system call
is broken and process continues.

    Here is a simple program for demonstrate this bug:

#!/usr/bin/python
import signal
import sys

def signal_handle(signum, frame) :
  signal.signal(signal.SIGALRM, signal_handle)
  signal.alarm(2)
  print "signal"

signal_handle(0,0)
a=sys.stdin.readline()
print "Line examined..."
b=sys.stdin.readline()
print "Line examined..."
print a,b,"end"
# end of example

    Correct behaviour: Message "Line examined..." occurs only after pressing
ENTER by user.
    Bug: Message "Line examined..." occurs immediately after signal occured
and procedure signal_handle finished. Output then look thus (when no input
entered):

signal
signal
Line examined...
signal
Line examined...
  end

    This bug appears at any signal occur and whatever process waiting at
system call. Some system call even produces exception (e.g. waiting for data
or connection on socket).

    Bug is perhaps caused by wrong seting "siginterrupt" on module signal. I
haven't found any way how call in Python program "siginterrupt" for correct
behavior of signal processing.

        Good bye, V. Benes

****************************************************************************
    Ing. Vladimir Benes, pvt.net
    PVT, a.s., OZ Chomutov
    e-mail: vladimir.benes@pvt.cz, vladimir.benes@sms.paegas.cz
****************************************************************************



====================================================================
Audit trail:
Mon Oct 11 18:12:13 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:05
By: none

Comment:
From: Jeremy Hylton <jeremy@cnri.reston.va.us>
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102)
Date: Tue, 12 Oct 1999 12:04:42 -0400 (EDT)

>>>>> "VB" == Vladimir Benes <Vladimir.Benes@pvt.cz> writes:

  VB> Bug: Incorrect signal processing (Python 1.5.2).  Process can
  VB> assign procedure for signal processing. When process is waiting
  VB> at system call and this signal occur, then the signal assigned
  VB> procedure is otherwise correctly completed but then waiting at
  VB> system call is broken and process continues.

[example program]

I see the behavior you report for 1.5.2 on Solaris 2.6.

  VB>     This bug appears at any signal occur and whatever process
  VB> waiting at system call. Some system call even produces exception
  VB> (e.g. waiting for data or connection on socket).

These issues always occur in twos don't they.  There was a similar
question posted on comp.lang.python yesterday.  I'm not sure that the
behavior you're seeing is a bug; it is the behavior I would expect.
Slow system calls are interrupted, returning EINTR, when a signal
occurs. 

  VB>     Bug is perhaps caused by wrong seting "siginterrupt" on
  VB> module signal. I haven't found any way how call in Python
  VB> program "siginterrupt" for correct behavior of signal
  VB> processing.

Perhaps the signal module for Python should be extended to support
siginterrupt, but it sounds like it will only reduce the number of
system calls that can be interrupted.  The Solaris man page says:

    NOTES
         Use of these interfaces should be restricted to only  appli-
         cations  written  on BSD platforms.  Use of these interfaces
         with any of the system libraries or in multi-threaded appli-
         cations is unsupported.

It doesn't sound particularly safe.

Jeremy

-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" <Vladimir.Benes@pvt.cz>
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102)
Date: Wed, 13 Oct 1999 09:19:44 +0200

From: Jeremy Hylton <jeremy@cnri.reston.va.us>
To: Vladimir.Benes@pvt.cz <Vladimir.Benes@pvt.cz>
Cc: python-bugs-list@python.org <python-bugs-list@python.org>;
bugs-py@python.org <bugs-py@python.org>
Date: 12. 10. 1999 18:04
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python
1.5.2 (PR#102)


JH>I see the behavior you report for 1.5.2 on Solaris 2.6.


    You don't write whether this bug appeared there.

 JH> ......  I'm not sure that the
 JH> behavior you're seeing is a bug; it is the behavior I would expect.
 JH> Slow system calls are interrupted, returning EINTR, when a signal
 JH> occurs.


    I'am sure that this behavior is bug becouse:

1. I wrote the same program in C language (see below).
2. I ran this program at the same machine where the Python *)
    program works incorrectly.
3. Behavior of C program is correct (line scan is ended only when
    user press ENTER and this end is independed on signal).

=> The C program works correct and the same Python *) program fails at the
same platform. Base run of program should by independed on signal processing
except program terminating signals. It's independed at C program but
incorrect processed by Python *) programs.

*) only Python 1.5.2; Python 1.5.1 here works correctly

    Here is the mentioned program:

#include<stdio.h>
#include <unistd.h>
#include <signal.h>

void signal_handle(int signum) {
  signal(SIGALRM, signal_handle);
  alarm(2);
  printf("signal\n\r");
}

void main(void) {
  char a[100], b[100];

  signal_handle(0);
  scanf("%s",&a);
  printf("Line examined...\n\r");
  scanf("%s",&b);
  printf("Line examined...\n\r");
  printf("%s\t%s\tend\n\r", a, b);
}

 VB>     Bug is perhaps caused by wrong seting "siginterrupt" on
 VB> module signal. I haven't found any way how call in Python
 VB> program "siginterrupt" for correct behavior of signal
 VB> processing.


 JH> Perhaps the signal module for Python should be extended to support
 JH> siginterrupt, but it sounds like it will only reduce the number of
 JH> system calls that can be interrupted.  .......


    Sorry, I wrong formulated possible couse of bug. I will try to specify
my idea:
    It looks that there is any wrong calling "siginterupt" on signal module.
Python libraries doesn't allow me to try correct this bug by calling
"siginiterrupt" in my program before signal setting. But the best way is to
reapir bug on signal module.

    Good bye, V. Benes


-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102)
Date: Wed, 13 Oct 1999 08:57:25 -0400

>  JH> ......  I'm not sure that the
>  JH> behavior you're seeing is a bug; it is the behavior I would expect.
>  JH> Slow system calls are interrupted, returning EINTR, when a signal
>  JH> occurs.
> 
[Vladimir]
>     I'am sure that this behavior is bug becouse:

When I first thought about this, I agreed with Vladimir.  If you look
careful at his code, readline() is returning "" when the alarm goes
off; this can't be right, because it's not an end of file.  It should
either raise an exception (EINTR) or return one line of valid data.

On the other hand, whatever solution is chosen should be careful that
other signals raise exceptions; in particular you want SIGINT (^C) to
be translated to a KeyboardError exception.  Since the C code in
readline() can't tell which signal was trapped or whether the handler
raised an exception, it has two choices, both of which are bad:

- Raise an IOError exception, honoring the EINTR.  Unfortunately, in
the SIGINT/^C case, the handler will run after this exception is
raised, and it will raise KeyboardError.  The Python program will
*probably* see the KeyboardError exception, but it is not guaranteed
that the signal handler is run immediately.  (The Python-level signal
handler is run only after the Python virtual machine finishes the
current instruction, i.e. after the readline() completes.)

- Continue to read a line, ignoring the EINTR.  Unfortunately, this
would mean that the user has to type ^C followed by Return to
interrupt the program!

An alternative solution would be to arrange for the Python-level
interrupt handler to execute inside the readline() method, and to
restart the read only when it raises no exception; but this would
require a massive code rewrite (you'd want this behavior in any place
that does a blocking I/O operation).

Concluding, I think Vladimir is better off not to use signal handlers
in the way he is using them now.  Python's emulation of signal
semantics is sufficiently different from C that you can't rely on the
same behavior.  (And note that in C, signal handlers are usually
broken anyway; e.g. the code you write, which prints something inside
the signal handler, is broken on C too because you don't know the
state of stdout when the handler is invoked.)

I looked at what could be different between 1.5.1 and 1.5.2, and found 
that the call to siginterrupt() to disable restarting system calls was 
added after 1.5.1.  Given the alternatives, I think I like the 1.5.2
behavior better than the 1.5.1 behavior.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" <Vladimir.Benes@pvt.cz>
Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102)
Date: Wed, 13 Oct 1999 16:34:39 +0200

>...
>Concluding, I think Vladimir is better off not to use signal handlers
>in the way he is using them now.  Python's emulation of signal
>semantics is sufficiently different from C that you can't rely on the
>same behavior.  (And note that in C, signal handlers are usually
>broken anyway; e.g. the code you write, which prints something inside
>the signal handler, is broken on C too because you don't know the
>state of stdout when the handler is invoked.)


    Well, meantioned programs were only very simple demos for demonstrate
incorrect signal processing. But exists a large range of meaningful programs
where is necessary both synchronous and asynchronous signal processing - and
signal can be triggered whenever.

    Example of C symbolic structure this programs:

....
int event_flag;
void trigger_signal(int signum) {
  // asynchonous signal processing
  event_flag = MY_EVENT; // only flag set
}
void initialize_signal(int sig) {
  event_flag = NO_EVENT; // initialize
  signal(sig, trigger_signal);
}
int main() {
  initialize_signal(SIGTERM);
  while (1) {
    my_func();
    // synchronous signal processing:
    if (event_flag==MY_EVENT) my_sync_trigger();
  }
}

    Signal can be raised whenever when function my_func runs => flag
event_flag is then set but my_func "does't know" his and continues at own
processing. Signal should not influence my_func becouse my_func "doesn't
know" both this signal and flag event_flag. Function event_flag can wait for
system call (read, write, connect, etc). Incoming signal should not finish
this waiting after trigger_signal function processing. So my_func is
independed on signal processing and "does'nt know" signals.

    Program tests the flag at any "safe" location(s). If this flag is set,
program run specific synchronous signal processing. It can be for example
safe program end or synchronous SIGALRM processing.

    Python programs can by compose similar this example.

>I looked at what could be different between 1.5.1 and 1.5.2, and found
>that the call to siginterrupt() to disable restarting system calls was
>added after 1.5.1.  Given the alternatives, I think I like the 1.5.2
>behavior better than the 1.5.1 behavior.


    But then old Python programs writen for Python 1.5.1 are not compatible
with Python 1.5.2. in this feature. I thing that better way is to let this
behavior equal as in Python 1.5.1. but allow programs to call either new
function "siginterrupt" at signal module (more flexible solution) or any
else new function at signal module to set behavior signal processing by Your
idea.

        Good bye, V. Benes


-------------------------------------------------------

Date: 2000-Aug-10 11:45
By: gvanrossum

Comment:
Sorry, I can't take this.  It's an issue though!  There are a bunch of signal related bugs in Linux...
-------------------------------------------------------

Date: 2000-Sep-13 03:42
By: gvanrossum

Comment:
Confirmed with python 2.0b1 on Linux.

Note that this is *not* the same bug as #110611 -- here, threads and readline don't matter (confirmed).
-------------------------------------------------------

Date: 2000-Sep-15 18:01
By: gvanrossum

Comment:
Something should be done, but it's not easy.
I've added this to PEP 42 as a feature request.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110599&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 03:12:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 19:12:39 -0700
Subject: [Python-bugs-list] [Bug #112244] time.strptime() not present in Python 1.5.2 for MSWin
Message-ID: <200009160212.TAA03333@delerium.i.sourceforge.net>

Bug #112244, was updated on 2000-Aug-18 06:54
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 3
Summary: time.strptime() not present in Python 1.5.2 for MSWin

Details: Using Python 1.5.2 for MSWin, any attempt to use the time.strptime() function from the time module results in the error:
AttributeError: strptime

This error does not occur for the Unix version of Python 1.5.2.


Follow-Ups:

Date: 2000-Aug-18 10:38
By: tim_one

Comment:
Changed to group Feature Request.
strptime is available from Python only on those platforms where this (non-standard) C function happens to be available from the platform C library.  Windows is not one of those.  Not all Unix versions have it either.  The docs already say that.  The only way it will become available is if someone contributes an implementation.

-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-15 19:12
By: tim_one

Comment:
Moved to PEP42, awaiting a volunteer.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112244&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 03:17:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 19:17:29 -0700
Subject: [Python-bugs-list] [Bug #114245] utime can not accept directory under NT
Message-ID: <200009160217.TAA03510@delerium.i.sourceforge.net>

Bug #114245, was updated on 2000-Sep-12 06:36
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 5
Summary: utime can not accept directory under NT

Details: Whenever supply a directory to utime path parameter, exception raised.  The problem is MS C run time library utime function only works on files, but not directories.  To fix this bug, MS utime has to be replaced by some function that works with directory.

Follow-Ups:

Date: 2000-Sep-13 15:49
By: gangli59

Comment:
I submitted a patch that uses win32 api instead MSC run time library
-------------------------------------------------------

Date: 2000-Sep-14 23:25
By: tim_one

Comment:
Changed to Category "Modules".
-------------------------------------------------------

Date: 2000-Sep-15 19:17
By: tim_one

Comment:
Moved to PEP42, as extending the functionality of the platform utime is a new feature rather than a bug.  This is a borderline case, so my intent here is not to reject it out-of-hand for the next 2.0 beta, but to classify it as correctly as possible.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114245&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 03:18:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 19:18:41 -0700
Subject: [Python-bugs-list] [Bug #114557] Nuke hard tabs from the std library
Message-ID: <200009160218.TAA03525@delerium.i.sourceforge.net>

Bug #114557, was updated on 2000-Sep-15 18:59
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 5
Summary: Nuke hard tabs from the std library

Details: It was agreed for 2.0b1 that all std libraries modules would use 4-space indents and no hard tabs.  This didn't happen, due to a misunderstanding.  Repair that after 2.0final is released (would be sooner, except about 250 files are affected, and that much fiddling carries some risk).

Follow-Ups:

Date: 2000-Sep-15 19:01
By: tim_one

Comment:
Moved to PEP42.
-------------------------------------------------------

Date: 2000-Sep-15 19:18
By: tim_one

Comment:
Forgot to close it.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114557&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 03:22:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 19:22:22 -0700
Subject: [Python-bugs-list] [Bug #110839] CGIHTTPServer (PR#239)
Message-ID: <200009160222.TAA03659@delerium.i.sourceforge.net>

Bug #110839, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 3
Summary: CGIHTTPServer (PR#239)

Details: Jitterbug-Id: 239
Submitted-By: Michael_Frericks@informatik-kooperation.de
Date: Fri, 17 Mar 2000 11:27:23 -0500 (EST)
Version: 1.5.2
OS: WinNT 4.0


The module CGIHTTPServer does not run on WinNT since 

a) the function executable() seems to return a false value, if you omit the call
of executable() you come to
b) the function nobody_uid() imports the module pwd available only for unix
c) other unix-functions as fork... are used to create a process with the user
nobody



====================================================================
Audit trail:
Mon Apr 03 18:39:48 2000	guido	changed notes
Mon Apr 03 18:39:48 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:15
By: none

Comment:
This module still needs to be ported to Windows...
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-15 19:22
By: tim_one

Comment:
Moved to PEP42; awaiting a volunteer.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110839&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 03:24:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 19:24:59 -0700
Subject: [Python-bugs-list] [Bug #111403] 1.6b1 dumps core dereferencing a NULL tstate
Message-ID: <200009160224.TAA03711@delerium.i.sourceforge.net>

Bug #111403, was updated on 2000-Aug-08 11:26
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Wont Fix
Bug Group: Platform-specific
Priority: 6
Summary: 1.6b1 dumps core dereferencing a NULL tstate

Details: 
  This is from an embeded python.  I've not yet been
able to reproduce this with a small example.  But
perhaps this stacktrace will be of some help.  The
problem seems to be that eval_code2() calls PyThreadState_GET() and gets a NULL pointer back.
This pointer is dereferenced in PyFrame_New() later
on which causes the core dump.  The documentation
seems to say that PyThreadState_GET() should never
return NULL.  So, there must be a bug in there
somewhere.  Here is the stack trace:

#0  0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, 
    locals=0x0) at frameobject.c:120
120             PyFrameObject *back = tstate->frame;
(gdb) bt
#0  0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, 
    locals=0x0) at frameobject.c:120
#1  0x866b022 in eval_code2 (co=0x90fff70, globals=0x9284378, locals=0x0, 
    args=0x8eb362c, argcount=5, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
    owner=0x925d2e8) at ceval.c:397
#2  0x866e4ee in call_function (func=0x911aca0, arg=0x95ea3b0, kw=0x0)
    at ceval.c:2521
#3  0x866e09d in PyEval_CallObjectWithKeywords (func=0x95f7a60, arg=0x95ea3b0, 
    kw=0x0) at ceval.c:2359
#4  0x863f6cf in PyObject_CallObject (o=0x95f7a60, a=0x95ea3b0)
    at abstract.c:1370
#5  0x83e56ed in DrawingArea::process (this=0x95f5f48, event=@0xbfffeb80)
    at DrawingArea.C:971
#6  0x83e5b3d in DrawingArea::dspCB (this=0x95e0b68) at DrawingArea.C:1027
#7  0x832050f in TkFDWatcher::callback (data=0x95e2048) at TkFDWatcher.C:169
#8  0x8752612 in FileHandlerEventProc (evPtr=0x935a4d8, flags=-1)
    at ./tclUnixNotfy.c:405
#9  0x8741d10 in Tcl_ServiceEvent (flags=-1) at ./../generic/tclNotify.c:444
#10 0x8741fae in Tcl_DoOneEvent (flags=2) at ./../generic/tclNotify.c:747
#11 0x86a8757 in Tkapp_MainLoop (self=0x8f6a178, args=0x8eb6af0)
    at ./_tkinter.c:1794
#12 0x866e19e in call_builtin (func=0x8f7b7f0, arg=0x8eb6af0, kw=0x0)
    at ceval.c:2396
#13 0x866e0ab in PyEval_CallObjectWithKeywords (func=0x8f7b7f0, arg=0x8eb6af0, 
    kw=0x0) at ceval.c:2361
#14 0x866d0cb in eval_code2 (co=0x8fb2d18, globals=0x903b9f8, locals=0x0, 
    args=0x8f277b4, argcount=0, kws=0x8f277b4, kwcount=0, defs=0x90447c4, 
    defcount=1, owner=0x0) at ceval.c:1680
#15 0x866cdda in eval_code2 (co=0x8f28b10, globals=0x8f294d0, locals=0x0, 
    args=0x8f27600, argcount=1, kws=0x8f27604, kwcount=0, defs=0x0, 
    defcount=0, owner=0x92c6238) at ceval.c:1579
#16 0x866cdda in eval_code2 (co=0x8f5b300, globals=0x8f294d0, locals=0x0, 
    args=0x8eb8600, argcount=0, kws=0x8eb8600, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1579
#17 0x866cdda in eval_code2 (co=0x8f27ae0, globals=0x8eb0038, 
    locals=0x8eb0038, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1579
#18 0x866afc8 in PyEval_EvalCode (co=0x8f27ae0, globals=0x8eb0038, 
    locals=0x8eb0038) at ceval.c:290
#19 0x867d7c7 in run_node (n=0x8f1d0e0, filename=0x89fcacf "<string>", 
    globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:885
#20 0x867d777 in run_err_node (n=0x8f1d0e0, filename=0x89fcacf "<string>", 
    globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:870
#21 0x867d719 in PyRun_String (str=0x8f1ca68 "import GFE; GFE.main()\n", 
    start=257, globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:847
#22 0x867ce4e in PyRun_SimpleString (
    command=0x8f1ca68 "import GFE; GFE.main()\n") at pythonrun.c:589
#23 0x8681c51 in Py_Main (argc=4, argv=0xbffff204) at main.c:248
#24 0x80d90e1 in main (argc=4, argv=0xbffff204) at main.C:30

Mike Romberg (romberg@fsl.noaa.gov)


Follow-Ups:

Date: 2000-Aug-10 10:23
By: none

Comment:
Followup:  This only happens when python is built
--with-threads.  There appears to be no problem when
threads are not enabled.  It should be noted that our
embeded application uses no threads of any kind (python or
pthreads from C++).  But it may be the case that our code
(C++) is not doing the right thing.

  It should be noted that our application works fine
with python-1.5.2 compiled --with-threads.

-------------------------------------------------------

Date: 2000-Aug-25 07:37
By: jhylton

Comment:
Mike -- Can you provide any more information about this bug?

-------------------------------------------------------

Date: 2000-Aug-25 09:59
By: romberg

Comment:
  My guess (and this is just a guess) is that this may have something
to do with the interaction of python threads and Tkinter.  Since most of
our embeded (and non threaded) python application works fine except
for one specific area, maybe that is thre problem with python 1.6.  Let me
attempt to explain what is going on since it may take some work to
produce a small test case to reproduce the problem.

  Our application uses Tkinter for most of the UI.  We do open a second
connection to the X server using Xlib.  This connection is used to
render complex images into windows.  Tkinter's canvas is just not fast
enough.  I am getting X events from these Xlib created windows via
the Tcl/Tk FileEventHandler (as seen on the stack trace).  I am using the
Tcl/Tk C API to register for these events.

  The case which seems to cause the crash in python comes when I get
a ButtonDown event on my second (non Tkinter) Display.  This event
is delivered from Tcl/Tk to some of our C++ code.  Now for the interesting
bit which I suspect might cause the problem.

  Our C++ code then releases the grab and calls into the python interpreter
for it to post a popup menu (using Tkinter).  This is seen on the stack
as the most recent PyObject_CallObject().  This code attempts to post
the Tkinter popuip menu but dies trying.

  This works fine under python-1.5.2 when it is built --with-thread and
without.  It works fine with python-1.6b2 as long as python is built
without threads.  But when it is built with threads I get this crash.  Is it possible that the Tkinter layer is doing something different threadwise
when python is built --with-threads?
-------------------------------------------------------

Date: 2000-Aug-28 11:28
By: none

Comment:
Another followup.  I've compiled python-1.6b1 on HP-UX-10.20 and
linked the whole thing with purify.  Purify does not show any errors
and everything runs fine when python is built --without-thread.  I was
unable to get python to build on HP-UX --with-thread.  I suspect that
this might have something to do with the DCE threads HPUX uses.

  But in any case.  The extra code linked into our embeded interpreter, is
not doing anything funny with pointers (as far as purify could find).

Mike (romberg@fsl.noaa.gov)

-------------------------------------------------------

Date: 2000-Aug-30 10:46
By: gvanrossum

Comment:
Looks like just another example of HP-UX build problems. (esp. w. threads?)
-------------------------------------------------------

Date: 2000-Aug-30 10:56
By: none

Comment:
  Yea.  I'm not really interested in the HP platform for use with
threads (they are a mess).  I was just using it because that is the
only platform I have access to which can run purify.

  The real problem is under linux (redhat-6.2) when threads are
enabled.  I just wanted to make sure that there were not any funny
memory problems caused by the python extensions we have
added to our embeded python.

  Purify (on HPUX-10.20) seems to give a clean bill of health.  So, I'm
guessing that whattever is causing the core dump under linux is
specific to the thread support in python.

-------------------------------------------------------

Date: 2000-Sep-15 11:42
By: jhylton

Comment:
Another question for you Mike: Have you tried your application on RH 6.2 with 2.0b1?  Does the problem still exist there?  If it is limited to the HP UX platform, which you say you're not actually interested in, I'm going to close this bug report; other people are working on HPUX threading issues.

-------------------------------------------------------

Date: 2000-Sep-15 12:45
By: romberg

Comment:
  Yes.  I've tried things with both 1.6 (final) and 2.0b1 on RH6.2.  For
both versions of python, things work fine as long as --without-thread is
used to build python.  The HPUX issue is not really important to me.
I only tried building things on it to use Purify (to verify that there were
no memory related problems with the code).  I understand that the threads
on HPUX-10.20 are a real mess.  I don't really care much about getting
python threads working on HPUX.

  But I would like to use them on linux (so we can use things like Zope).
So, at this time the symptoms are still that things work fine using
python-1.5.2 (with and without threads).  But, die when threads are
enabled.   None of our code is using any kind of threads (pthreads or
python threads).  I'm not using any part of the python C API which
deals with threads (maybe I should now be doing so?).  So,  the only
thing I can think of is that there is now some kind of thread thing going
on in _tkinter which was not in python-1.5.2.  Since the core dump
seems to happen after our C++ code is woken up from a Tcl filehandler and then calls back into python.  This is just a guess :).
-------------------------------------------------------

Date: 2000-Sep-15 13:21
By: romberg

Comment:
  This bug is about the crash on linux with the threads enabled.  The
stack trace comes from a linux system.  2.0b1 crashes with a very
similar looking stack.  I probably made a mistake in bringing up the
trouble I was having with the HPUX threads in the discussion of this
linux bug..  If you would like, I could start another bug report.  But
it would be more or less the same as this one.  The stack trace after
the crash is identical.

  I am willing to do some poking around to help figure out what is
going on here.  It would probably be helpful to have some more
details about what is going on after the point my code calls PyObject_CallObject().  I could put in some PyObject_Print()s or
something if that would help.  I just don't know enough about how
the python internals are supposed to work to know what to do next.

-------------------------------------------------------

Date: 2000-Sep-15 19:24
By: jhylton

Comment:
waiting for new non-HPUX bug report
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=111403&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 03:39:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 19:39:57 -0700
Subject: [Python-bugs-list] [Bug #110839] CGIHTTPServer (PR#239)
Message-ID: <200009160239.TAA20352@bush.i.sourceforge.net>

Bug #110839, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 3
Summary: CGIHTTPServer (PR#239)

Details: Jitterbug-Id: 239
Submitted-By: Michael_Frericks@informatik-kooperation.de
Date: Fri, 17 Mar 2000 11:27:23 -0500 (EST)
Version: 1.5.2
OS: WinNT 4.0


The module CGIHTTPServer does not run on WinNT since 

a) the function executable() seems to return a false value, if you omit the call
of executable() you come to
b) the function nobody_uid() imports the module pwd available only for unix
c) other unix-functions as fork... are used to create a process with the user
nobody



====================================================================
Audit trail:
Mon Apr 03 18:39:48 2000	guido	changed notes
Mon Apr 03 18:39:48 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:15
By: none

Comment:
This module still needs to be ported to Windows...
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-15 19:22
By: tim_one

Comment:
Moved to PEP42; awaiting a volunteer.
-------------------------------------------------------

Date: 2000-Sep-15 19:39
By: gvanrossum

Comment:
I might volunteer.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110839&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 03:47:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 19:47:25 -0700
Subject: [Python-bugs-list] [Bug #110611] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Message-ID: <200009160247.TAA04558@delerium.i.sourceforge.net>

Bug #110611, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Signal processing bug (Linux threads, readline, whatever else) (PR#196)

Details: Jitterbug-Id: 196
Submitted-By: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Date: Tue, 1 Feb 2000 14:43:09 +0100
Version: None
OS: None

--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi,

this must be the strangest bug report ever sent to bugs-py ;-).

I don't expect a resolution for this bug from you, I just wanted to make
sure this thing is recorded and the BTS. Perhaps somebody could give me a
hint where I could look for the misbehavior. Candidates seem to be glibc,
LinuxThreads, GNU readline, the Python readline module and the Python thread
support ;-)

In 1.5.2, there's a strange problem with signals on Linux systems. This has
been discussed before on the mailing list, probably it even has a relation
to Bug#102 ("incorrect signal processing"), but IMHO this reports adds a few
other aspects. Definitely it is a (platform-specific) problem in 1.5.2.


I have problems describing the bug, since the behavior seems to depend on so
many parameters. The most obvious incarnation of the problem is probably
this:

In the Python 1.5.2 interpreter included with Debian 2.2 ("potato"), if you
press Control-C on the command line (or send a SIGINT), the interpreter
exits to the shell:

  freefly;104> python
  Python 1.5.2 (#0, Sep 13 1999, 09:12:57)  [GCC 2.95.1 19990816 (release)]=
 on
      linux2=20
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  >>> [Ctrl-C]
  freefly;105>=20

Normally, you'd expect a KeyboardInterrupt exception here.



Now I tried and compiled different configurations of Python (each from a
pristine source tree) on this Debian system:

  (151+t+rl)   Python 1.5.1 (threads, readline)
  (152)        Python 1.5.2 (no threads, no readline) =20
  (152+rl)     Python 1.5.2 (no threads, readline)
  (152+t)      Python 1.5.2 (threads, no readline)
  (152+t+rl)   Python 1.5.2 (threads, readline)
  (152+pth+rl) Python 1.5.2 (GNU Pth threads, readline)

Thread support was realized with glibc 2.1.2's LinuxThreads, i.e. pthreads.
readline was GNU readline 2.1 (for the record, I also tried 4.1beta3, but
this made no difference).

When I refer to Debian 2.1 ("slink"), this is a system with glibc 2.0.7 and
the same GNU readline version 2.1.



The following tables show the output of some experiments with those
configurations. The [] brackets show the keys pressed. Note that a line like
"[Ctrl-C][Enter]" implies that the interpreter showed no visible reaction to
the first Ctrl-C! "----" lines mean that I started up a new clean session.


(1) This is what happens when you start up a new interpreter and press
    Ctrl-C once, twice and so on, while on the command line:

152,152+t             152+rl,152+pth+rl  152+t+rl        151+t+rl
=3D=3D=3D=3D=3D=3D=3D=3D=3D             =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D  =3D=3D=3D=3D=3D=3D=3D=3D        =3D=3D=3D=3D=3D=3D=3D=3D
------------------    ----------------   -------------   ----------------
>>> [Ctrl-C][Ctrl-C]  >>> [Ctrl-C]       >>> [Ctrl-C]    >>> [Ctrl-C][Ct...]
KeyboardInterrupt     KeyboardInterrupt  freefly:5>      ----------------
>>> [Ctrl-C]          >>> [Ctrl-C]       -------------
KeyboardInterrupt     KeyboardInterrupt
>>> [Ctrl-C]          >>> [Ctrl-C]
KeyboardInterrupt     KeyboardInterrupt
>>> [Ctrl-C]          >>> [Ctrl-C]
KeyboardInterrupt     KeyboardInterrupt
------------------    ----------------

                                         152+t+rl (on a Debian 2.1 system)
                                         =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
                                         ---------------------
                                         >>> [Ctrl-C]
                                         KeyboardInterrupt
                                         >>> [Ctrl-C][Ctr...]
                                         ---------------------

  -> 1.5.2 with readline but without LinuxThreads is right.
  -> For some reason, 1.5.2 without readline ignores the first SIGINT.
  -> 1.5.2 with both readline and LinuxThreads kill the interpreter.
  -> 1.5.1 seems to ignore all SIGINTs's. =20
  -> For 1.5.2 running glibc 2.0.7 (instead of 2.1.2) and readline, the
     interpreter doesn't get killed, but still after the first SIGINT all
     following SIGINTs are ignored.
    =20
  -> It's worth a note that with only one of readline or thread support, the
     package seems to behave more reasonable; have both enabled is bad.
    =20
  -> With threading support by means of GNU Pth (instead of the native libc6
     LinuxThreads), the package behaves more correctly, too!

    =20
(2) Now on those systems who seemed to ignore the first SIGINT, I pressed
    Enter after it:

152,152+t                           151+t+rl
=3D=3D=3D=3D=3D=3D=3D=3D=3D                           =3D=3D=3D=3D=3D=3D=3D=
=3D
---------------------               --------------------
>>> [Ctrl-C][Enter]                 >>> [Ctrl-C][Enter]
Traceback (innermost last):         Traceback (innermost last):
  File "<stdin>", line 0, in ?      File "<stdin>", line 0, in ?
KeyboardInterrupt                   KeyboardInterrupt
>>> [Ctrl-C]                        >>> [Ctrl-C][Enter]
KeyboardInterrupt                   Traceback (innermost last):
---------------------                 File "<stdin>", line 0, in ?
                                    KeyboardInterrupt
                                    >>>
                                    --------------------

				   =20
  -> Obviously, the interpreter *DID* record the SIGINT in the first place,
     it just didn't provoke any immediate action=20
  -> On 1.5.2 without readline, the second and all following SIGINTs are
     handled as one would expect.
  -> 1.5.1 with thread and readline shows this strange behavior not only for
     the first, but also for the second and any following SIGINT.


    =20
(3) On the glibc 2.0.7 system, I verified that indeed all subsequent SIGINTs
    are ignored. You're not able even to interrupt a loop, after the
    interpreter has received a SIGINT while he was on the command line:
    =20
152+t+rl (on a Debian 2.1 system)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
---------------------
>>> [Ctrl-C]
KeyboardInterrupt
>>> [Ctrl-C][Enter]
>>> [Ctrl-C][Enter]
{kein weiteres SIGINT
wird akzeptiert, auch im Laufen:}
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
=2E..
999
>>>
---------------------
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
Traceback (innermost last):
  File "<stdin>", line 1, in ?
KeyboardInterrupt
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
Traceback (innermost last):
  File "<stdin>", line 1, in ?
KeyboardInterrupt
>>> [Ctrl-C]
KeyboardInterrupt
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
=2E..
999
>>>
---------------------

  -> Note that it didn't hurt to break multiple times into a loop;
     only SIGINTs on the command line do mess up the interpreter!


    =20
    =20
(4) In the Debian 2.2 Python package, you have to be careful not to kill the
    interpreter; that's especially a problem when you try to break into a
    loop--if you hold down Ctrl-C for too long, the interpreter quits!
    =20
152+t+rl (Debian 2.2 package)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
---------------------
>>> [Ctrl-C]
freefly:5>
---------------------
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401

KeyboardInterrupt
>>>
---------------------
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C pressed down for a longer time]
400
401

freefly;19>=20
---------------------




(5) The Debian 2.2 package behaves more reasonable when the readline module
    has been moved out of the way:

152+t (Debian 2.2 package, readline module moved out of the way)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
---------------------
>>> [Ctrl-C][Ctrl-C]
KeyboardInterrupt
>>> ...                   (vgl. 152, 152+t)
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
40[Enter]
Traceback (innermost last):
  File "<stdin>", line 0, in ?
KeyboardInterrupt
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
KeyboardInterrupt
>>>


--FL5UXtIhxfXey3p5
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4luLt3eVfDf25G40RAQw9AKDhLyI7RDYt3G85Rxet2ZlK1b1nKwCg3zl/
tasWxAOGLUK3K3ucMBbhBag=
=PTOI
-----END PGP SIGNATURE-----

--FL5UXtIhxfXey3p5--


====================================================================
Audit trail:
Mon Feb 07 12:38:12 2000	guido	changed notes
Mon Feb 07 12:38:12 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:05
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Date: Wed, 2 Feb 2000 03:04:04 -0500

[flight@mathi.uni-heidelberg.de]

> this must be the strangest bug report ever sent to bugs-py ;-).

No, but I don't recall one that evidenced more hard & tedious work!  Wow.
Thank you.  Switch to Windows -- it's so much more reliable <wink>.

If you haven't already done so, may I suggest building Python from the
current CVS development source tree instead?

http://www.python.org/download/cvs.html

This may be a waste of effort, but I'd hate to see you pour more time
tracking down obscure bugs that may already have been fixed.  Contrarily, if
the current CVS version still displays the problems, more work devoted to
tracking them down is certain not to be a waste.



-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Date: Wed, 2 Feb 2000 14:25:07 +0100

Hi,

> If you haven't already done so, may I suggest building Python from the
> current CVS development source tree instead?

sorry, I forgot to mention that I tried that. Didnt't change the behavior
at all (I also saw that there were no big changes to the readline nor to
the threading code since 1.5.2).

    Gregor


-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Subject: Returned mail: User unknown
Date: Thu, 3 Feb 2000 11:46:44 +0100 (MET)

This is a MIME-encapsulated message

--LAA26536.949574804/relay.uni-heidelberg.de

The original message was received at Thu, 3 Feb 2000 11:46:41 +0100 (MET)
from mailserver.mathi.uni-heidelberg.de [129.206.26.32]

   ----- The following addresses had permanent fatal errors -----
<bugs-by@python.org>

   ----- Transcript of session follows -----
.. while talking to parrot.python.org.:
>>> RCPT To:<bugs-by@python.org>
<<< 550 <bugs-by@python.org>... User unknown
550 <bugs-by@python.org>... User unknown

--LAA26536.949574804/relay.uni-heidelberg.de
Content-Type: message/delivery-status

Reporting-MTA: dns; relay.uni-heidelberg.de
Received-From-MTA: DNS; mailserver.mathi.uni-heidelberg.de
Arrival-Date: Thu, 3 Feb 2000 11:46:41 +0100 (MET)

Final-Recipient: RFC822; bugs-by@python.org
Action: failed
Status: 5.1.1
Remote-MTA: DNS; parrot.python.org
Diagnostic-Code: SMTP; 550 <bugs-by@python.org>... User unknown
Last-Attempt-Date: Thu, 3 Feb 2000 11:46:44 +0100 (MET)

--LAA26536.949574804/relay.uni-heidelberg.de
Content-Type: message/rfc822

Return-Path: <flight@mathi.uni-heidelberg.de>
Received: from mailserver.mathi.uni-heidelberg.de (mailserver.mathi.uni-heidelberg.de [129.206.26.32])
	by relay.uni-heidelberg.de (8.9.3+Sun/8.9.3) with ESMTP id LAA26531
	for <bugs-by@python.org>; Thu, 3 Feb 2000 11:46:41 +0100 (MET)
Received: from testserv.mathi.uni-heidelberg.de (testserv.mathi.uni-heidelberg.de [129.206.26.30])
	by mailserver.mathi.uni-heidelberg.de (Postfix) with SMTP id CFF5512917
	for <bugs-by@python.org>; Thu,  3 Feb 2000 11:48:11 +0100 (CET)
Received: by testserv.mathi.uni-heidelberg.de (sSMTP sendmail emulation); Thu, 3 Feb 2000 11:48:12 +0100
Date: Thu, 3 Feb 2000 11:48:12 +0100
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
To: bugs-by@python.org
Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Message-ID: <20000203114812.B18567@mathi.uni-heidelberg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0pre3i

Fredric Lundh pointed me to Alex Zbyslaw's posting regarding this topic
(http://x44.deja.com/getdoc.xp?AN=545159177).

Indeed Alex' patch1 (http://www.xfb52.dial.pipex.com/patches/python.shtml)
for FreeBSD (disabling the interrupt handler chanege in the readline module)
works for Debian, too, i.e. if I stick with the default inthandler in the
readline module, SIGINT doesn't kill the interpreter anymore.

Still, the drawback of this change is that I have to press RETURN before
a SIGINT is spotted by Python (btw, this is the same behavior as with 1.5.1
on the system with the same configuration).

Still, IMHO this behavior is preferable.

    Gregor

--LAA26536.949574804/relay.uni-heidelberg.de--


-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Subject: Re: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Date: Fri, 11 Feb 2000 14:52:42 +0100


--dDRMvlgZJXvWKvBx
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Ok, one more data point:

On Fri, Feb 11, 2000 at 08:29:43AM -0500, Randall Hopper wrote:
> You know, I think you may have it.  On IRIX, I don't have Python built
> with threads.  However, on FreeBSD at home I'd guess that it is (I built =
it
> from ports).  My IRIX python has no problem with Ctrl-C while my FreeBSD
> version at home locks up with Ctrl-C.  I rebuilt my IRIX Python
> --with-thread, and now it hangs when Ctrl-C is hit.

And now, we're three: When using threads and readline, Ctrl-C hangs IRIX and
FreeBSD and kills Linux Python.

This doesn't sound like a kernel problem, more like a problem with readline
not being thread-safe I guess.

    Gregor
   =20

--dDRMvlgZJXvWKvBx
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4pBQq3eVfDf25G40RAUbSAJ41b+DgwHEmRUm0uQcJLjvZ3ROiSwCdH8Xq
jFH5J1TsLQBbQTPU5Xvv0Bo=
=0j16
-----END PGP SIGNATURE-----

--dDRMvlgZJXvWKvBx--

-------------------------------------------------------

Date: 2000-Sep-15 19:47
By: gvanrossum

Comment:
Some progress notes:

There are several bugs here.

1. The combination readline + threads causes ^C to just exit or die.
I've found that this can be fixed with readline 4.x by setting the global variable rl_catch_signals to 0 in setup_readline(). But my Red Hat 6. 2 system still comes with readline 2.2. How can I detect the readline version? And what to do for readline 2.2?

2. Without the readline module, the first ^C requires [Enter] before it is seen.
I haven't researched this yet, but will.

3. Debian 2.1 ignores the second and all subsequent ^Cs.
I won't look into this; apparently it's fixed in Debian 2.2.

4. Similar problems on IRIX.
I'll presume this is the same as (1).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110611&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 03:49:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 19:49:17 -0700
Subject: [Python-bugs-list] [Bug #110839] CGIHTTPServer (PR#239)
Message-ID: <200009160249.TAA04594@delerium.i.sourceforge.net>

Bug #110839, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: Later
Bug Group: Feature Request
Priority: 3
Summary: CGIHTTPServer (PR#239)

Details: Jitterbug-Id: 239
Submitted-By: Michael_Frericks@informatik-kooperation.de
Date: Fri, 17 Mar 2000 11:27:23 -0500 (EST)
Version: 1.5.2
OS: WinNT 4.0


The module CGIHTTPServer does not run on WinNT since 

a) the function executable() seems to return a false value, if you omit the call
of executable() you come to
b) the function nobody_uid() imports the module pwd available only for unix
c) other unix-functions as fork... are used to create a process with the user
nobody



====================================================================
Audit trail:
Mon Apr 03 18:39:48 2000	guido	changed notes
Mon Apr 03 18:39:48 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:15
By: none

Comment:
This module still needs to be ported to Windows...
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-15 19:22
By: tim_one

Comment:
Moved to PEP42; awaiting a volunteer.
-------------------------------------------------------

Date: 2000-Sep-15 19:39
By: gvanrossum

Comment:
I might volunteer.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110839&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 03:50:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 19:50:55 -0700
Subject: [Python-bugs-list] [Bug #113773] Python 2.0b1 selectmodule compile error under Redhat 5.2
Message-ID: <200009160250.TAA20676@bush.i.sourceforge.net>

Bug #113773, was updated on 2000-Sep-06 18:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: Python 2.0b1 selectmodule compile error under Redhat 5.2

Details: Environment: Redhat 5.2 running the gcc compiler that comes with the
distribution (gcc 2.7.2.3).

'make' failed when compiling selectmodule.c ('./configure' ran ok)because
the following constants were undefined:

POLLRDNORM, POLLRDBAND, POLLWRBAND

The /usr/include/sys/poll.h file does not contain these constants.
Under Redhat 6.2 the constants are defined in the /usr/include/bits/poll.h
file (which is not present in the Redhat 5.2 distribution).

I used the Redhat 6.2 poll.h file and the selectmodule compiled (under
Redhat 5.2) but got the following error when running 
'make test' (it looks like it might be related to the compile problem):

test test_poll crashed -- select.error: (9, 'Bad file descriptor')

1 test failed: test_poll



Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 23:08
By: tim_one

Comment:
Boosted the priority and assigned to Fred.  Don't know what you can do about an older Redhat build problem, and it's not clear that the test failure isn't simply due to mixing files across OS releases.  I'm inclined to blame it on the OS.
-------------------------------------------------------

Date: 2000-Sep-15 13:11
By: fdrake

Comment:
I've asked SourceForge if there are ways to use older versions of operating systems on their compile farm.  Until then, we'll need a volunteer with a RH5.2 system to help with this.

Stuart:  Are you willing to test a patch if I mail it to you?  Thanks.
-------------------------------------------------------

Date: 2000-Sep-15 19:50
By: fdrake

Comment:
SourceForge will try and provide a RH5.2 installation for us; now that's service!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113773&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 04:57:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 20:57:29 -0700
Subject: [Python-bugs-list] [Bug #114553] copy.deepcopy() barfs if it hits class/function/method
Message-ID: <200009160357.UAA22798@bush.i.sourceforge.net>

Bug #114553, was updated on 2000-Sep-15 16:22
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: copy.deepcopy() barfs if it hits class/function/method

Details: The 'copy.deepcopy()' function blows up if it stumbles across class, function, or method objects as it recurses into objects.  This is (at least partly) because of an inconsistency between the dispatch table used for plain-vanilla 'copy()' and for 'deepcopy()': the 'copy()' dispatch table has an entry for ClassType, but the 'deepcopy()' dispatch table does not.

Also, neither dispatch table has entries for FunctionType or MethodType.  This isn't a big deal for 'copy()', since it's unlikely that you'd do 'copy(my_func)', but it's inconsistent since you can do 'copy(my_class)' -- and the class object my_class is *not* copied, it's treated atomically, like strings or ints.  For consistency, functions and methods should probably be treated the same as class objects.

Here's a script that demonstrates the problem:

from copy import copy, deepcopy

def f(): pass
class K: pass

# can copy a list that contains a function, since we don't
# dive into the list
l = [1, 2, f]
try: copy(l)
except: print "error copying list with function"
else: print "ok copying list with function"

# but we can't copy the function
try: copy(f)
except: print "error copying function"
else: print "ok copying function"

# also can't deep copy a list with a function because deepcopy() dives in
try: deepcopy(l)
except: print "error deep-copying list with function"
else: print "ok deep-copying list with function"

# nor can we deepcopy the function alone
try: deepcopy(f)
except: print "error deep-copying function"
else: print "ok deep-copying function"

# can copy list with class object
l = ["foo", K]
try: copy(l)
except: print "error copying list with class object"
else: print "ok copying list with class object"

# but can't deepcopy it
try: deepcopy(l)
except: print "error deep-copying list with class object"
else: print "ok deep-copying list with class object"

(Hmm, I don't see a test script for the 'copy' module -- perhaps this would be a good start.)

This gives the same output for me with Python 1.5.2, 1.6, and 2.0b1 (all on Linux):

ok copying list with function
error copying function
error deep-copying list with function
error deep-copying function
ok copying list with class object
error deep-copying list with class object

And here's a patch that makes everything come out OK:

--- copy.py.orig        Fri Sep 15 19:19:05 2000
+++ copy.py.hacked      Fri Sep 15 19:20:20 2000
@@ -92,6 +92,8 @@
 d[types.TypeType] = _copy_atomic
 d[types.XRangeType] = _copy_atomic
 d[types.ClassType] = _copy_atomic
+d[types.FunctionType] = _copy_atomic
+d[types.MethodType] = _copy_atomic
 
 def _copy_list(x):
        return x[:]
@@ -165,6 +167,9 @@
 d[types.CodeType] = _deepcopy_atomic
 d[types.TypeType] = _deepcopy_atomic
 d[types.XRangeType] = _deepcopy_atomic
+d[types.ClassType] = _deepcopy_atomic
+d[types.FunctionType] = _deepcopy_atomic
+d[types.MethodType] = _deepcopy_atomic
 
 def _deepcopy_list(x, memo):
        y = []


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114553&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 06:13:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Sep 2000 22:13:59 -0700
Subject: [Python-bugs-list] [Bug #114566] Bad link to some information at unicode.org
Message-ID: <200009160513.WAA09054@delerium.i.sourceforge.net>

Bug #114566, was updated on 2000-Sep-15 22:13
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Bad link to some information at unicode.org

Details: In Doc/lib/libunicodedata.tex, the URL ftp://ftp.unicode.org/Public/UNIDATA/UnicodeData.html is stale.  Please find a live link to the appropriate information and update the documentation.

Thanks.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114566&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 08:16:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 00:16:01 -0700
Subject: [Python-bugs-list] [Bug #110857] it don't make (PR#269)
Message-ID: <200009160716.AAA28846@bush.i.sourceforge.net>

Bug #110857, was updated on 2000-Aug-01 14:38
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 3
Summary: it don't make (PR#269)

Details: Jitterbug-Id: 269
Submitted-By: mitch.harris@usa.net
Date: Mon,  3 Apr 2000 13:29:25 -0400 (EDT)
Version: 1.6
OS: sun 5.6


First time I tried to install Python. 


/usr2/t_mitchh/python/Python-1.6a1>version
Machine hardware:   sun4u
OS version:         5.6
Processor type:     sparc
Hardware:           SUNW,Ultra-1

The following components are installed on your system:


Sun Visual WorkShop C++ 3.0
        Sun WorkShop Compiler C 4.2 
        Sun WorkShop Compiler C++ 4.2 
        Sun WorkShop Tools.h++ 7.0 
        Sun WorkShop Tools.h++ 6.0.4 
        Sun WorkShop Visual 2.0 
        Sun WorkShop IPE 4.0 
        Sun WorkShop CodeManager 2.0 
        Sun WorkShop Distributed Make 2.0 
        Sun WorkShop FileMerge 3.0 
        Sun WorkShop FreezePoint 2.0 
        Sun WorkShop Maketool 2.0 
        Sun WorkShop VersionTool 2.0 
        Sun WorkShop Dbx 4.0 
        Sun WorkShop Performance Analyzer 4.0 
        Sun WorkShop LoopTool 2.1 
        Sun WorkShop LockLint 2.1 
        Sun WorkShop Thread Analyzer 1.2 
        Sun WorkShop XEmacs 20.00 

/usr2/t_mitchh/python/Python-1.6a1>./configure
creating cache ./config.cache
checking MACHDEP... sunos5
checking for --without-gcc... no
checking for --with-cxx=<compiler>... no
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking LINKCC... $(PURIFY) $(CC)
checking LDLIBRARY... 
checking for ranlib... ranlib
checking for ar... ar
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking for minix/config.h... no
checking whether gcc accepts -OPT:Olimit=0... no
checking whether gcc accepts -Olimit 1500... no
checking for C preprocessor type... ansi
checking for ANSI C header files... yes
checking for dlfcn.h... yes
checking for fcntl.h... yes
checking for limits.h... yes
checking for locale.h... yes
checking for ncurses.h... no
checking for pthread.h... yes
checking for signal.h... yes
checking for stdarg.h... yes
checking for stddef.h... yes
checking for stdlib.h... yes
checking for thread.h... yes
checking for unistd.h... yes
checking for utime.h... yes
checking for sys/audioio.h... yes
checking for sys/file.h... no
checking for sys/lock.h... yes
checking for sys/param.h... no
checking for sys/select.h... yes
checking for sys/time.h... yes
checking for sys/times.h... yes
checking for sys/un.h... yes
checking for sys/utsname.h... yes
checking for sys/wait.h... yes
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking for clock_t in time.h... yes
checking for mode_t... yes
checking for off_t... yes
checking for pid_t... yes
checking return type of signal handlers... void
checking for size_t... yes
checking for uid_t in sys/types.h... yes
checking size of int... 4
checking size of long... 4
checking size of void *... 4
checking size of char... 1
checking size of short... 2
checking size of float... 4
checking size of double... 8
checking for long long support... yes
checking size of long long... 8
checking size of off_t... 4
checking whether to enable large file support... no
checking for --with-next-framework... no
checking for --with-dyld... no
checking SO... .so
checking LDSHARED... ld -G
checking CCSHARED... 
checking LINKFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for t_open in -lnsl... yes
checking for socket in -lsocket... yes
checking for socket in -lnet... no
checking for --with-libs... no
checking for --with(out)-readline... not specified.
checking for --with-dec-threads... no
checking for --with-threads... no
checking for --with-thread... no
checking for --with-sgi-dl... no
checking for --with-dl-dld... no
checking for dlopen... yes
checking DYNLOADFILE... dynload_shlib.o
checking for alarm... yes
checking for chown... yes
checking for clock... yes
checking for confstr... yes
checking for ctermid... yes
checking for ctermid_r... yes
checking for dlopen... (cached) yes
checking for execv... yes
checking for flock... no
checking for fork... yes
checking for fsync... yes
checking for fdatasync... no
checking for fpathconf... yes
checking for ftime... yes
checking for ftruncate... yes
checking for getgroups... yes
checking for getlogin... yes
checking for getpeername... yes
checking for getpgrp... yes
checking for getpid... yes
checking for getpwent... yes
checking for gettimeofday... yes
checking for getwd... yes
checking for kill... yes
checking for link... yes
checking for lstat... yes
checking for mkfifo... yes
checking for mktime... yes
checking for nice... yes
checking for pathconf... yes
checking for pause... yes
checking for plock... yes
checking for pthread_init... no
checking for putenv... yes
checking for readlink... yes
checking for select... yes
checking for setgid... yes
checking for setlocale... yes
checking for setuid... yes
checking for setsid... yes
checking for setpgid... yes
checking for setpgrp... yes
checking for setvbuf... yes
checking for sigaction... yes
checking for siginterrupt... yes
checking for sigrelse... yes
checking for strftime... yes
checking for strptime... yes
checking for symlink... yes
checking for sysconf... yes
checking for tcgetpgrp... yes
checking for tcsetpgrp... yes
checking for tempnam... yes
checking for timegm... no
checking for times... yes
checking for tmpfile... yes
checking for tmpnam... yes
checking for tmpnam_r... yes
checking for truncate... yes
checking for uname... yes
checking for waitpid... yes
checking for fseek64... no
checking for fseeko... yes
checking for fstatvfs... yes
checking for ftell64... no
checking for ftello... yes
checking for statvfs... yes
checking for dup2... yes
checking for getcwd... yes
checking for strdup... yes
checking for strerror... yes
checking for memmove... yes
checking for getpgrp... (cached) yes
checking for setpgrp... (cached) yes
checking for gettimeofday... (cached) yes
checking whether time.h and sys/time.h may both be included... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for tm_zone in struct tm... no
checking for tzname... yes
checking for time.h that defines altzone... yes
checking whether sys/select.h and sys/time.h may both be included... yes
checking whether char is unsigned... no
checking for working const... yes
checking for inline... inline
checking for working volatile... yes
checking for working signed char... yes
checking for prototypes... yes
checking for variable length prototypes and stdarg.h... yes
checking for bad exec* prototypes... no
checking for bad static forward... no
checking whether va_list is an array... no
checking for gethostbyname_r... yes
checking gethostbyname_r with 6 args... no
checking gethostbyname_r with 5 args... no
checking gethostbyname_r with 3 args... no
checking for __fpu_control in -lieee... no
checking for --with-fpectl... no
checking for --with-libm=STRING... default LIBM="-lm"
checking for --with-libc=STRING... default LIBC=""
checking for hypot... yes
checking for hypot... (cached) yes
checking for genuine getopt... yes
checking what malloc(0) returns... nonnull
checking for wchar.h... yes
checking for usable wchar_t... no
checking whether byte ordering is bigendian... yes
checking for --with-wctype-functions... no
updating cache ./config.cache
creating ./config.status
creating Makefile
creating Objects/Makefile
creating Parser/Makefile
creating Python/Makefile
creating Modules/Makefile.pre
creating Modules/Setup.thread
creating config.h


/usr2/t_mitchh/python/Python-1.6a1/Modules>make
gcc  -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c
In file included from ./posixmodule.c:3194:
/usr/include/sys/statvfs.h:38: parse error before `fsblkcnt_t'
/usr/include/sys/statvfs.h:38: warning: no semicolon at end of struct or union
/usr/include/sys/statvfs.h:39: warning: data definition has no type or storage
class
/usr/include/sys/statvfs.h:40: parse error before `f_bavail'
/usr/include/sys/statvfs.h:40: warning: data definition has no type or storage
class
/usr/include/sys/statvfs.h:41: parse error before `f_files'
/usr/include/sys/statvfs.h:41: warning: data definition has no type or storage
class
/usr/include/sys/statvfs.h:42: parse error before `f_ffree'
/usr/include/sys/statvfs.h:42: warning: data definition has no type or storage
class
/usr/include/sys/statvfs.h:43: parse error before `f_favail'
/usr/include/sys/statvfs.h:43: warning: data definition has no type or storage
class
/usr/include/sys/statvfs.h:51: parse error before `}'
/usr/include/sys/statvfs.h:51: warning: data definition has no type or storage
class
./posixmodule.c: In function `posix_fstatvfs':
./posixmodule.c:3207: storage size of `st' isn't known
./posixmodule.c: In function `posix_statvfs':
./posixmodule.c:3259: storage size of `st' isn't known
make: *** [posixmodule.o] Error 1

I tried this 

#if defined(HAVE_FSTATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
#if defined(HAVE_STATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
#ifdef HAVE_FSTATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
#ifdef HAVE_STATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

and got this

/prj/qed2/local//lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.1/include/sys/param.h:187:
warning: `NBBY' r
/usr/include/sys/select.h:45: warning: this is the location of the previous
definition
In file included from /usr/include/sys/stream.h:26,
                 from /usr/include/netinet/in.h:38,
                 from /usr/include/netdb.h:96,
                 from ./socketmodule.c:163:
/usr/include/sys/model.h:32: #error "No DATAMODEL_NATIVE specified"
make[1]: *** [socketmodule.o] Error 1
make[1]: Leaving directory `/usr2/t_mitchh/python/Python-1.6a1/Modules'
make: *** [Modules] Error 2



====================================================================
Audit trail:
Mon May 22 17:44:30 2000	guido	changed notes
Mon May 22 17:44:30 2000	guido	moved from incoming to irreproducible

Follow-Ups:

Date: 2000-Aug-01 14:38
By: none

Comment:
Sun's compiler sucks?
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 22:58
By: tim_one

Comment:
Changed Category to Build, and assigned to Jeremy at random.  I don't know why the Group is set to Irreproducible.
-------------------------------------------------------

Date: 2000-Sep-16 00:16
By: loewis

Comment:
This is an operator error. He is using a gcc build for sparc-sun-solaris2.5 on OS version: 5.6. As a result, gcc still has the fixincluded 2.5 headers (at least those that needed fixing), which don't mix well with the 2.6 headers taken from /usr/include.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110857&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 09:51:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 01:51:03 -0700
Subject: [Python-bugs-list] [Bug #114566] Bad link to some information at unicode.org
Message-ID: <200009160851.BAA15566@delerium.i.sourceforge.net>

Bug #114566, was updated on 2000-Sep-15 22:13
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Bad link to some information at unicode.org

Details: In Doc/lib/libunicodedata.tex, the URL ftp://ftp.unicode.org/Public/UNIDATA/UnicodeData.html is stale.  Please find a live link to the appropriate information and update the documentation.

Thanks.

Follow-Ups:

Date: 2000-Sep-16 01:51
By: tim_one

Comment:
"""Unicode, Inc. is currently having problems with the anonymous FTP site. Access will be restored as soon as possible. To address this problem, we have mirrored all the files. They are all available via http.  The mirrored http files will remain available even after anonymous FTP access is restored.  To access a file using a browser, replace ftp://ftp by http://www in the name, for example http://www.unicode.org/Public/"""

In this case,

http://www.unicode.org/Public/UNIDATA/UnicodeData.html 

works for me.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114566&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 09:56:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 01:56:19 -0700
Subject: [Python-bugs-list] [Bug #112786] Build under Cygwin fails
Message-ID: <200009160856.BAA15732@delerium.i.sourceforge.net>

Bug #112786, was updated on 2000-Aug-26 01:39
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Build under Cygwin fails

Details: Py1.6b1
========
1) socketmodule.c -- looks for netinet/tcp.h, which does not exist on cygwin.

2) gcc   python.o \
          ../libpython1.6.a    -lm  -o python
python.o: In function `main':
/usr/local/bin/Python-1.6b1/Modules/python.c:12: undefined reference to `Py_Main


Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 04:13
By: gvanrossum

Comment:
I don't have cygwin. Does anyone here have cygwin? I know Tim said the cygwin installer failed for him, so he doesn't have it. Is there someone outside the PythonLabs to whom we could assign this?
-------------------------------------------------------

Date: 2000-Sep-16 01:56
By: tim_one

Comment:
A fellow named Norman mailto:nhv@yahoo.com posted to c.l.py with some evidence of real Cygwin knowledge, so I emailed him a link to this bug and asked whether he'd help out.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112786&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 14:47:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 06:47:42 -0700
Subject: [Python-bugs-list] [Bug #114566] Bad link to some information at unicode.org
Message-ID: <200009161347.GAA25236@delerium.i.sourceforge.net>

Bug #114566, was updated on 2000-Sep-15 22:13
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Bad link to some information at unicode.org

Details: In Doc/lib/libunicodedata.tex, the URL ftp://ftp.unicode.org/Public/UNIDATA/UnicodeData.html is stale.  Please find a live link to the appropriate information and update the documentation.

Thanks.

Follow-Ups:

Date: 2000-Sep-16 01:51
By: tim_one

Comment:
"""Unicode, Inc. is currently having problems with the anonymous FTP site. Access will be restored as soon as possible. To address this problem, we have mirrored all the files. They are all available via http.  The mirrored http files will remain available even after anonymous FTP access is restored.  To access a file using a browser, replace ftp://ftp by http://www in the name, for example http://www.unicode.org/Public/"""

In this case,

http://www.unicode.org/Public/UNIDATA/UnicodeData.html 

works for me.
-------------------------------------------------------

Date: 2000-Sep-16 06:47
By: fdrake

Comment:
New URL checked in at Doc/lib/libunicodedata.tex revision 1.2.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114566&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 14:57:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 06:57:48 -0700
Subject: [Python-bugs-list] [Bug #110609] Operator breakage with long int operands (PR#187)
Message-ID: <200009161357.GAA25577@delerium.i.sourceforge.net>

Bug #110609, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Operator breakage with long int operands (PR#187)

Details: Jitterbug-Id: 187
Submitted-By: aa8vb@yahoo.com
Date: Mon, 24 Jan 2000 11:19:11 -0500 (EST)
Version: 1.5.2
OS: IRIX 6.5


This came up a few weeks ago, and bit again in the dumbdbm module last week.
In the dumbdbm module in 1.5.2:

     '\0'*(npos-pos)

(npos-pos) on some OSs will be a long int.  However, the '*' operator won't 
handle a long int.  I can't think of a reason why 'a'*10L should be invalid,
for example.

At issue a few weeks ago was long ints and the '%' operator.  For example:

    >>> str( 0x80000000L )
    '2147483648L'
    >>> "%ld" % 0x80000000L
    OverflowError: long int too long to convert

    >>> hex( 0x80000000L )
    '0x80000000L'
    >>> "%lX" % 0x80000000L
    OverflowError: long int too long to convert

Couldn't % use hex() and str() under the hood, for instance?



====================================================================
Audit trail:
Mon Jan 24 14:28:42 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-16 06:57
By: loewis

Comment:
I believe the first issue is resolved in 2.0b1; '\0' * 10L does work.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110609&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 17:43:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 09:43:47 -0700
Subject: [Python-bugs-list] [Bug #110611] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Message-ID: <200009161643.JAA31479@delerium.i.sourceforge.net>

Bug #110611, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: Signal processing bug (Linux threads, readline, whatever else) (PR#196)

Details: Jitterbug-Id: 196
Submitted-By: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Date: Tue, 1 Feb 2000 14:43:09 +0100
Version: None
OS: None

--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi,

this must be the strangest bug report ever sent to bugs-py ;-).

I don't expect a resolution for this bug from you, I just wanted to make
sure this thing is recorded and the BTS. Perhaps somebody could give me a
hint where I could look for the misbehavior. Candidates seem to be glibc,
LinuxThreads, GNU readline, the Python readline module and the Python thread
support ;-)

In 1.5.2, there's a strange problem with signals on Linux systems. This has
been discussed before on the mailing list, probably it even has a relation
to Bug#102 ("incorrect signal processing"), but IMHO this reports adds a few
other aspects. Definitely it is a (platform-specific) problem in 1.5.2.


I have problems describing the bug, since the behavior seems to depend on so
many parameters. The most obvious incarnation of the problem is probably
this:

In the Python 1.5.2 interpreter included with Debian 2.2 ("potato"), if you
press Control-C on the command line (or send a SIGINT), the interpreter
exits to the shell:

  freefly;104> python
  Python 1.5.2 (#0, Sep 13 1999, 09:12:57)  [GCC 2.95.1 19990816 (release)]=
 on
      linux2=20
  Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
  >>> [Ctrl-C]
  freefly;105>=20

Normally, you'd expect a KeyboardInterrupt exception here.



Now I tried and compiled different configurations of Python (each from a
pristine source tree) on this Debian system:

  (151+t+rl)   Python 1.5.1 (threads, readline)
  (152)        Python 1.5.2 (no threads, no readline) =20
  (152+rl)     Python 1.5.2 (no threads, readline)
  (152+t)      Python 1.5.2 (threads, no readline)
  (152+t+rl)   Python 1.5.2 (threads, readline)
  (152+pth+rl) Python 1.5.2 (GNU Pth threads, readline)

Thread support was realized with glibc 2.1.2's LinuxThreads, i.e. pthreads.
readline was GNU readline 2.1 (for the record, I also tried 4.1beta3, but
this made no difference).

When I refer to Debian 2.1 ("slink"), this is a system with glibc 2.0.7 and
the same GNU readline version 2.1.



The following tables show the output of some experiments with those
configurations. The [] brackets show the keys pressed. Note that a line like
"[Ctrl-C][Enter]" implies that the interpreter showed no visible reaction to
the first Ctrl-C! "----" lines mean that I started up a new clean session.


(1) This is what happens when you start up a new interpreter and press
    Ctrl-C once, twice and so on, while on the command line:

152,152+t             152+rl,152+pth+rl  152+t+rl        151+t+rl
=3D=3D=3D=3D=3D=3D=3D=3D=3D             =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D  =3D=3D=3D=3D=3D=3D=3D=3D        =3D=3D=3D=3D=3D=3D=3D=3D
------------------    ----------------   -------------   ----------------
>>> [Ctrl-C][Ctrl-C]  >>> [Ctrl-C]       >>> [Ctrl-C]    >>> [Ctrl-C][Ct...]
KeyboardInterrupt     KeyboardInterrupt  freefly:5>      ----------------
>>> [Ctrl-C]          >>> [Ctrl-C]       -------------
KeyboardInterrupt     KeyboardInterrupt
>>> [Ctrl-C]          >>> [Ctrl-C]
KeyboardInterrupt     KeyboardInterrupt
>>> [Ctrl-C]          >>> [Ctrl-C]
KeyboardInterrupt     KeyboardInterrupt
------------------    ----------------

                                         152+t+rl (on a Debian 2.1 system)
                                         =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
                                         ---------------------
                                         >>> [Ctrl-C]
                                         KeyboardInterrupt
                                         >>> [Ctrl-C][Ctr...]
                                         ---------------------

  -> 1.5.2 with readline but without LinuxThreads is right.
  -> For some reason, 1.5.2 without readline ignores the first SIGINT.
  -> 1.5.2 with both readline and LinuxThreads kill the interpreter.
  -> 1.5.1 seems to ignore all SIGINTs's. =20
  -> For 1.5.2 running glibc 2.0.7 (instead of 2.1.2) and readline, the
     interpreter doesn't get killed, but still after the first SIGINT all
     following SIGINTs are ignored.
    =20
  -> It's worth a note that with only one of readline or thread support, the
     package seems to behave more reasonable; have both enabled is bad.
    =20
  -> With threading support by means of GNU Pth (instead of the native libc6
     LinuxThreads), the package behaves more correctly, too!

    =20
(2) Now on those systems who seemed to ignore the first SIGINT, I pressed
    Enter after it:

152,152+t                           151+t+rl
=3D=3D=3D=3D=3D=3D=3D=3D=3D                           =3D=3D=3D=3D=3D=3D=3D=
=3D
---------------------               --------------------
>>> [Ctrl-C][Enter]                 >>> [Ctrl-C][Enter]
Traceback (innermost last):         Traceback (innermost last):
  File "<stdin>", line 0, in ?      File "<stdin>", line 0, in ?
KeyboardInterrupt                   KeyboardInterrupt
>>> [Ctrl-C]                        >>> [Ctrl-C][Enter]
KeyboardInterrupt                   Traceback (innermost last):
---------------------                 File "<stdin>", line 0, in ?
                                    KeyboardInterrupt
                                    >>>
                                    --------------------

				   =20
  -> Obviously, the interpreter *DID* record the SIGINT in the first place,
     it just didn't provoke any immediate action=20
  -> On 1.5.2 without readline, the second and all following SIGINTs are
     handled as one would expect.
  -> 1.5.1 with thread and readline shows this strange behavior not only for
     the first, but also for the second and any following SIGINT.


    =20
(3) On the glibc 2.0.7 system, I verified that indeed all subsequent SIGINTs
    are ignored. You're not able even to interrupt a loop, after the
    interpreter has received a SIGINT while he was on the command line:
    =20
152+t+rl (on a Debian 2.1 system)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
---------------------
>>> [Ctrl-C]
KeyboardInterrupt
>>> [Ctrl-C][Enter]
>>> [Ctrl-C][Enter]
{kein weiteres SIGINT
wird akzeptiert, auch im Laufen:}
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
=2E..
999
>>>
---------------------
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
Traceback (innermost last):
  File "<stdin>", line 1, in ?
KeyboardInterrupt
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
Traceback (innermost last):
  File "<stdin>", line 1, in ?
KeyboardInterrupt
>>> [Ctrl-C]
KeyboardInterrupt
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
=2E..
999
>>>
---------------------

  -> Note that it didn't hurt to break multiple times into a loop;
     only SIGINTs on the command line do mess up the interpreter!


    =20
    =20
(4) In the Debian 2.2 Python package, you have to be careful not to kill the
    interpreter; that's especially a problem when you try to break into a
    loop--if you hold down Ctrl-C for too long, the interpreter quits!
    =20
152+t+rl (Debian 2.2 package)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
---------------------
>>> [Ctrl-C]
freefly:5>
---------------------
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401

KeyboardInterrupt
>>>
---------------------
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C pressed down for a longer time]
400
401

freefly;19>=20
---------------------




(5) The Debian 2.2 package behaves more reasonable when the readline module
    has been moved out of the way:

152+t (Debian 2.2 package, readline module moved out of the way)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
---------------------
>>> [Ctrl-C][Ctrl-C]
KeyboardInterrupt
>>> ...                   (vgl. 152, 152+t)
---------------------
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
40[Enter]
Traceback (innermost last):
  File "<stdin>", line 0, in ?
KeyboardInterrupt
>>> for i in xrange(1000): print i
=2E..
1
2
=2E..
[Ctrl-C]
400
401
KeyboardInterrupt
>>>


--FL5UXtIhxfXey3p5
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4luLt3eVfDf25G40RAQw9AKDhLyI7RDYt3G85Rxet2ZlK1b1nKwCg3zl/
tasWxAOGLUK3K3ucMBbhBag=
=PTOI
-----END PGP SIGNATURE-----

--FL5UXtIhxfXey3p5--


====================================================================
Audit trail:
Mon Feb 07 12:38:12 2000	guido	changed notes
Mon Feb 07 12:38:12 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:05
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Date: Wed, 2 Feb 2000 03:04:04 -0500

[flight@mathi.uni-heidelberg.de]

> this must be the strangest bug report ever sent to bugs-py ;-).

No, but I don't recall one that evidenced more hard & tedious work!  Wow.
Thank you.  Switch to Windows -- it's so much more reliable <wink>.

If you haven't already done so, may I suggest building Python from the
current CVS development source tree instead?

http://www.python.org/download/cvs.html

This may be a waste of effort, but I'd hate to see you pour more time
tracking down obscure bugs that may already have been fixed.  Contrarily, if
the current CVS version still displays the problems, more work devoted to
tracking them down is certain not to be a waste.



-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Date: Wed, 2 Feb 2000 14:25:07 +0100

Hi,

> If you haven't already done so, may I suggest building Python from the
> current CVS development source tree instead?

sorry, I forgot to mention that I tried that. Didnt't change the behavior
at all (I also saw that there were no big changes to the readline nor to
the threading code since 1.5.2).

    Gregor


-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Subject: Returned mail: User unknown
Date: Thu, 3 Feb 2000 11:46:44 +0100 (MET)

This is a MIME-encapsulated message

--LAA26536.949574804/relay.uni-heidelberg.de

The original message was received at Thu, 3 Feb 2000 11:46:41 +0100 (MET)
from mailserver.mathi.uni-heidelberg.de [129.206.26.32]

   ----- The following addresses had permanent fatal errors -----
<bugs-by@python.org>

   ----- Transcript of session follows -----
.. while talking to parrot.python.org.:
>>> RCPT To:<bugs-by@python.org>
<<< 550 <bugs-by@python.org>... User unknown
550 <bugs-by@python.org>... User unknown

--LAA26536.949574804/relay.uni-heidelberg.de
Content-Type: message/delivery-status

Reporting-MTA: dns; relay.uni-heidelberg.de
Received-From-MTA: DNS; mailserver.mathi.uni-heidelberg.de
Arrival-Date: Thu, 3 Feb 2000 11:46:41 +0100 (MET)

Final-Recipient: RFC822; bugs-by@python.org
Action: failed
Status: 5.1.1
Remote-MTA: DNS; parrot.python.org
Diagnostic-Code: SMTP; 550 <bugs-by@python.org>... User unknown
Last-Attempt-Date: Thu, 3 Feb 2000 11:46:44 +0100 (MET)

--LAA26536.949574804/relay.uni-heidelberg.de
Content-Type: message/rfc822

Return-Path: <flight@mathi.uni-heidelberg.de>
Received: from mailserver.mathi.uni-heidelberg.de (mailserver.mathi.uni-heidelberg.de [129.206.26.32])
	by relay.uni-heidelberg.de (8.9.3+Sun/8.9.3) with ESMTP id LAA26531
	for <bugs-by@python.org>; Thu, 3 Feb 2000 11:46:41 +0100 (MET)
Received: from testserv.mathi.uni-heidelberg.de (testserv.mathi.uni-heidelberg.de [129.206.26.30])
	by mailserver.mathi.uni-heidelberg.de (Postfix) with SMTP id CFF5512917
	for <bugs-by@python.org>; Thu,  3 Feb 2000 11:48:11 +0100 (CET)
Received: by testserv.mathi.uni-heidelberg.de (sSMTP sendmail emulation); Thu, 3 Feb 2000 11:48:12 +0100
Date: Thu, 3 Feb 2000 11:48:12 +0100
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
To: bugs-by@python.org
Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Message-ID: <20000203114812.B18567@mathi.uni-heidelberg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0pre3i

Fredric Lundh pointed me to Alex Zbyslaw's posting regarding this topic
(http://x44.deja.com/getdoc.xp?AN=545159177).

Indeed Alex' patch1 (http://www.xfb52.dial.pipex.com/patches/python.shtml)
for FreeBSD (disabling the interrupt handler chanege in the readline module)
works for Debian, too, i.e. if I stick with the default inthandler in the
readline module, SIGINT doesn't kill the interpreter anymore.

Still, the drawback of this change is that I have to press RETURN before
a SIGINT is spotted by Python (btw, this is the same behavior as with 1.5.1
on the system with the same configuration).

Still, IMHO this behavior is preferable.

    Gregor

--LAA26536.949574804/relay.uni-heidelberg.de--


-------------------------------------------------------

Date: 2000-Jul-31 14:05
By: none

Comment:
From: Gregor Hoffleit <flight@mathi.uni-heidelberg.de>
Subject: Re: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196)
Date: Fri, 11 Feb 2000 14:52:42 +0100


--dDRMvlgZJXvWKvBx
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Ok, one more data point:

On Fri, Feb 11, 2000 at 08:29:43AM -0500, Randall Hopper wrote:
> You know, I think you may have it.  On IRIX, I don't have Python built
> with threads.  However, on FreeBSD at home I'd guess that it is (I built =
it
> from ports).  My IRIX python has no problem with Ctrl-C while my FreeBSD
> version at home locks up with Ctrl-C.  I rebuilt my IRIX Python
> --with-thread, and now it hangs when Ctrl-C is hit.

And now, we're three: When using threads and readline, Ctrl-C hangs IRIX and
FreeBSD and kills Linux Python.

This doesn't sound like a kernel problem, more like a problem with readline
not being thread-safe I guess.

    Gregor
   =20

--dDRMvlgZJXvWKvBx
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4pBQq3eVfDf25G40RAUbSAJ41b+DgwHEmRUm0uQcJLjvZ3ROiSwCdH8Xq
jFH5J1TsLQBbQTPU5Xvv0Bo=
=0j16
-----END PGP SIGNATURE-----

--dDRMvlgZJXvWKvBx--

-------------------------------------------------------

Date: 2000-Sep-15 19:47
By: gvanrossum

Comment:
Some progress notes:

There are several bugs here.

1. The combination readline + threads causes ^C to just exit or die.
I've found that this can be fixed with readline 4.x by setting the global variable rl_catch_signals to 0 in setup_readline(). But my Red Hat 6. 2 system still comes with readline 2.2. How can I detect the readline version? And what to do for readline 2.2?

2. Without the readline module, the first ^C requires [Enter] before it is seen.
I haven't researched this yet, but will.

3. Debian 2.1 ignores the second and all subsequent ^Cs.
I won't look into this; apparently it's fixed in Debian 2.2.

4. Similar problems on IRIX.
I'll presume this is the same as (1).
-------------------------------------------------------

Date: 2000-Sep-16 09:43
By: gvanrossum

Comment:
Whew! It looks like BOTH bugs (1) and (2) from my previous comment were caused by mixing of signal() and sigaction(). It appears that if signal() is used to set a handler, sigaction() doesn't report it as the old handler, and vice versa. Possibly this bug is more severe when threads are used.

Bugs (1) and (2) are both fixed now -- I've introduced new APIs PyOS_setsig() and PyOS_getsig() that use sigaction() if it exists and signal() otherwise, and changed the readline and signal modules to use this.

I won't look into the other problems -- if there are still problems with signals, please submit a new bug report.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110611&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 17:59:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 09:59:17 -0700
Subject: [Python-bugs-list] [Bug #114027] Compiling on alpha-osf1v4: libpthreads is called libpthread
Message-ID: <200009161659.JAA15552@bush.i.sourceforge.net>

Bug #114027, was updated on 2000-Sep-10 22:43
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: Compiling on alpha-osf1v4: libpthreads is called libpthread

Details: change -lpthreads into -lpthread

Follow-Ups:

Date: 2000-Sep-16 09:59
By: gvanrossum

Comment:
I don't have enough information to resolve this problem.
What Python version were you using?

Did you use the configure script? It should automtically select -lpthreads or -lpthread depending on which one is present. Did this fail for you? Please check the config.log file to find out more about this.

Since I don't have an Alpha OSF1v1 system, I can't debug this for you!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114027&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 18:01:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 10:01:07 -0700
Subject: [Python-bugs-list] [Bug #114324] Minor build problems on HPUX for 2.0b1
Message-ID: <200009161701.KAA15588@bush.i.sourceforge.net>

Bug #114324, was updated on 2000-Sep-13 02:20
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: Minor build problems on HPUX for 2.0b1

Details: Build problems on HPUX10.20/HPUX11.00:

  - There seems to be no prototype for "fdatasync" in any include file
    although it has a man page and it is present in libc (so HAVE_FDATASYNC
    is set). As a result posixmodule.c fails to compile.
   
    Adding a prototype "extern int fdatasync(int);" to posixmodule.c solves 
    this problem, but it may not be portable.
    
  - Modules/mmapmodule.c is missing a "#include <limits.h>"
  
Build problems on HPUX10.20 only:

  - When configured with threading support (default), the cast to (long)
    on line 181 of Python/thread_pthread.h fails. The reason is that
    pthread_t is a struct type. The "configure" test that tries to find out
    the size of pthread_t failed because it tries to cast '0' to a pthread_t,
    so SIZEOF_PTHREAD_T remains undefined.
    
    I suggest changing this line in configure.in:
    
    AC_TRY_COMPILE([#include <pthread.h>], [pthread_t x; x = (pthread_t)0;], have_pthread_t=yes)
    
    to
    
    AC_TRY_COMPILE([#include <pthread.h>], [pthread_t x; x = *(pthread_t*)0;], have_pthread_t=yes)
    
My compiler settings:

   setenv CC 'c89 +DA1.1 +Onolimit -D_HPUX_SOURCE'

Regards,

Eddy

Follow-Ups:

Date: 2000-Sep-16 10:01
By: gvanrossum

Comment:
Randomly assigned to Jeremy for further investigation.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114324&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 18:04:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 10:04:55 -0700
Subject: [Python-bugs-list] [Bug #114410] 'make tests' fails with thread error on OpenBSD 2.7
Message-ID: <200009161704.KAA15740@bush.i.sourceforge.net>

Bug #114410, was updated on 2000-Sep-14 02:24
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: 'make tests' fails with thread error on OpenBSD 2.7

Details: Using the latest CVS version of Python, the output from a pass of regrtest follows. It may be an OpenBSD problem, in which case if someone can explain it to me I will sendbug it to the OpenBSD people instead.

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
test_grammar
test_opcodes
test_operations
test_builtin
test_exceptions
test_types
test_MimeWriter
test_al
test test_al skipped --  No module named al
test_array
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test_binascii
test_binhex
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cgi
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test test_fcntl skipped --  No module named FCNTL
test_file
test_fork1
test_format
test_gc
gc: collectable <list 0x36e46c>
gc: collectable <dictionary 0x3d568c>
gc: collectable <list 0x36e46c>
gc: collectable <tuple 0x36e48c>
gc: collectable <class 0x3d570c>
gc: collectable <dictionary 0x3d56cc>
gc: collectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d574c>
gc: collectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d578c>
gc: collectable <instance method 0x25e34c>
gc: collectable <B instance at 0x36e4cc>
gc: collectable <dictionary 0x3d58cc>
gc: uncollectable <dictionary 0x3d584c>
gc: uncollectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d57cc>
gc: collectable <function 0x3d590c>
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test_gl
test test_gl skipped --  No module named gl
test_grp
pid 4207: Fatal error '_libc_private_storage_lock' at line 14 in file /usr/src/lib/libc_r/thread/thread_storage.c (errno = 2)
Abort (core dumped) 
*** Error code 134

Stop in /tmp/python/dist/src (line 212 of Makefile).


Follow-Ups:

Date: 2000-Sep-14 02:34
By: jribbens

Comment:
Oh, if you do './configure --without-threads' then the problem is avoided, of course. 'make tests' then gives:

74 tests OK.
26 tests skipped: test_al test_audioop test_cd test_cl test_crypt test_dbm test_dl test_fcntl test_fork1 test_gdbm test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev test_minidom test_nis test_pty test_pyexpat test_rgbimg test_sunaudiodev test_thread test_timing test_winreg test_winsound test_zlib

But presumably, since Python 2 has threads enabled by default, something else needs to be done ;-)
-------------------------------------------------------

Date: 2000-Sep-16 10:04
By: gvanrossum

Comment:
I don't have an OpenBSD system to debug this myself. I have access to FreeBSD 4.1 which does not have this problem. Perhaps you can try to debug this some more yourself?

If it's decided that this is a bug in OpenBSD (are you using the latest version?), please let us know so we can close this bug report.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114410&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 18:05:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 10:05:12 -0700
Subject: [Python-bugs-list] [Bug #114410] 'make tests' fails with thread error on OpenBSD 2.7
Message-ID: <200009161705.KAA15746@bush.i.sourceforge.net>

Bug #114410, was updated on 2000-Sep-14 02:24
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: 'make tests' fails with thread error on OpenBSD 2.7

Details: Using the latest CVS version of Python, the output from a pass of regrtest follows. It may be an OpenBSD problem, in which case if someone can explain it to me I will sendbug it to the OpenBSD people instead.

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
test_grammar
test_opcodes
test_operations
test_builtin
test_exceptions
test_types
test_MimeWriter
test_al
test test_al skipped --  No module named al
test_array
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test_binascii
test_binhex
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cgi
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test test_fcntl skipped --  No module named FCNTL
test_file
test_fork1
test_format
test_gc
gc: collectable <list 0x36e46c>
gc: collectable <dictionary 0x3d568c>
gc: collectable <list 0x36e46c>
gc: collectable <tuple 0x36e48c>
gc: collectable <class 0x3d570c>
gc: collectable <dictionary 0x3d56cc>
gc: collectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d574c>
gc: collectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d578c>
gc: collectable <instance method 0x25e34c>
gc: collectable <B instance at 0x36e4cc>
gc: collectable <dictionary 0x3d58cc>
gc: uncollectable <dictionary 0x3d584c>
gc: uncollectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d57cc>
gc: collectable <function 0x3d590c>
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test_gl
test test_gl skipped --  No module named gl
test_grp
pid 4207: Fatal error '_libc_private_storage_lock' at line 14 in file /usr/src/lib/libc_r/thread/thread_storage.c (errno = 2)
Abort (core dumped) 
*** Error code 134

Stop in /tmp/python/dist/src (line 212 of Makefile).


Follow-Ups:

Date: 2000-Sep-14 02:34
By: jribbens

Comment:
Oh, if you do './configure --without-threads' then the problem is avoided, of course. 'make tests' then gives:

74 tests OK.
26 tests skipped: test_al test_audioop test_cd test_cl test_crypt test_dbm test_dl test_fcntl test_fork1 test_gdbm test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev test_minidom test_nis test_pty test_pyexpat test_rgbimg test_sunaudiodev test_thread test_timing test_winreg test_winsound test_zlib

But presumably, since Python 2 has threads enabled by default, something else needs to be done ;-)
-------------------------------------------------------

Date: 2000-Sep-16 10:04
By: gvanrossum

Comment:
I don't have an OpenBSD system to debug this myself. I have access to FreeBSD 4.1 which does not have this problem. Perhaps you can try to debug this some more yourself?

If it's decided that this is a bug in OpenBSD (are you using the latest version?), please let us know so we can close this bug report.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114410&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 18:07:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 10:07:12 -0700
Subject: [Python-bugs-list] [Bug #114532] cgi + <TextArea>.. + xml-data
Message-ID: <200009161707.KAA15780@bush.i.sourceforge.net>

Bug #114532, was updated on 2000-Sep-15 10:21
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: cgi + <TextArea>.. + xml-data

Details: Hi!

I'm working under linux (mandrake 7.1) using python for my cgi scripts. There I've a formular containing a "textarea". If entering xml- or html-data into this textarea and submitting it the cgi-script doesn't get that xml-data. With non-xml-data everything works fine.

BTW: It's the same with an "input"-field.

ciao
Volker


Follow-Ups:

Date: 2000-Sep-15 10:57
By: gvanrossum

Comment:
Volker,

We cannot help you with this bug unless you provide us with an example we can try ourselves.  We need at least:

1) a simple but complete script that shows the bug (try to pare it down from the script you are using to somehing that demonstrates just the problem)

2) the HTML of the form (ditto)

3) the text you are entering into the form

We also need:

- the Python version
- the browser name and version
- the server name and version

That said, I suspect that the problem is in your script, but without looking at it, I can't tell!

--Guido
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114532&group_id=5470


From noreply@sourceforge.net  Sat Sep 16 18:07:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 10:07:39 -0700
Subject: [Python-bugs-list] [Bug #114532] cgi + <TextArea>.. + xml-data
Message-ID: <200009161707.KAA15787@bush.i.sourceforge.net>

Bug #114532, was updated on 2000-Sep-15 10:21
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Summary: cgi + <TextArea>.. + xml-data

Details: Hi!

I'm working under linux (mandrake 7.1) using python for my cgi scripts. There I've a formular containing a "textarea". If entering xml- or html-data into this textarea and submitting it the cgi-script doesn't get that xml-data. With non-xml-data everything works fine.

BTW: It's the same with an "input"-field.

ciao
Volker


Follow-Ups:

Date: 2000-Sep-15 10:57
By: gvanrossum

Comment:
Volker,

We cannot help you with this bug unless you provide us with an example we can try ourselves.  We need at least:

1) a simple but complete script that shows the bug (try to pare it down from the script you are using to somehing that demonstrates just the problem)

2) the HTML of the form (ditto)

3) the text you are entering into the form

We also need:

- the Python version
- the browser name and version
- the server name and version

That said, I suspect that the problem is in your script, but without looking at it, I can't tell!

--Guido
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114532&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 21:24:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 13:24:07 -0700
Subject: [Python-bugs-list] [Bug #114598] Blue Screen crash, popen, Win98, Norton Antivirus 2000
Message-ID: <200009162024.NAA23066@bush.i.sourceforge.net>

Bug #114598, was updated on 2000-Sep-16 13:24
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 7
Summary: Blue Screen crash, popen, Win98, Norton Antivirus 2000

Details: On Windows 98, all of the os.popen*() functions cause a hard "blue screen" crash requiring a reboot, when Nortin Antivirus 2000 is installed and enabled. (Not with Norton Antivirus version 5, not on Windows 2000.)

While this is probably a bug in Norton Antivirus 2000, and we're already warning for this on the download page, that's not enough (we've seen at least one report in the newsgroup), and it would be good if we could somehow prevent it. Even a call to Py_FatalError is better than the blue screen, and raising os.error would be a *lot* better.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114598&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 22:56:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 14:56:17 -0700
Subject: [Python-bugs-list] [Bug #110656] IDLE goto file/line (PR#352)
Message-ID: <200009162156.OAA10260@delerium.i.sourceforge.net>

Bug #110656, was updated on 2000-Jul-31 14:11
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: IDLE goto file/line (PR#352)

Details: Jitterbug-Id: 352
Submitted-By: gpk@bell-labs.com
Date: Fri,  9 Jun 2000 22:45:05 -0400 (EDT)
Version: 1.6  CVS today
OS: Solaris 2.6


When using IDLE's shell window   Debug->Go to file/line,
you have to be overly careful what you select.
Specifically, if you select a region that contains a newline,
IDLE won't be able to find a file and line number.

For example, if you select
  v-- from there
   File "/export/h1/gpk/schoolweb.local/schoolweb/parse.py", line 199, in
__str__
  
  ^-- to there  (i.e. 2 characters in, on the following line),
you will get the following error message: "No special line: X the line you
point
to doesn't look like a file name followed by a line number."

That is unfortunate, as it's really convenient to make a quick flick
down from one line to the next, to select a complete line.



By the way, the error box requires you to click "OK".
That's a bug.   It isn't OK.
It's a crime against the King's English, committed by the minions
of Bill Gates.  You should not be following their lead.



====================================================================
Audit trail:
Tue Jul 11 08:25:59 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 14:56
By: bwarsaw

Comment:
Guido is the IDLE god.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110656&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 22:57:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 14:57:50 -0700
Subject: [Python-bugs-list] [Bug #110676] fd.readlines() hangs (via popen3) (PR#385)
Message-ID: <200009162157.OAA10288@delerium.i.sourceforge.net>

Bug #110676, was updated on 2000-Jul-31 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: fd.readlines() hangs (via popen3) (PR#385)

Details: Jitterbug-Id: 385
Submitted-By: aron@gweep.net
Date: Tue,  4 Jul 2000 19:07:55 -0400 (EDT)
Version: 1.5.2
OS: Red Hat Linux 6.1 (2.1.12-20)


The following scripts cause a hang at the denoted line. To execute
this code, copy the first bit to master.py and the second to slave.py
(both should be in the same directory). Then, "cd" to that directory
and "python master.py".

Manually killing the program is necessary.

This script has also been tested on a Solaris 5.7 box and worked.

---master.py---
import popen2

r,w,e = popen2.popen3 ( 'python slave.py' )
r.readlines() # Hangs here
e.readlines()
r.close()
e.close()
w.close()

---end---

---slave.py---
import sys

e = sys.stderr.write
w = sys.stdout.write

e(400*'this is a test\n')
w(400*'this is another test\n')
---end---



====================================================================
Audit trail:
Tue Jul 11 08:24:23 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110676&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 23:00:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 15:00:52 -0700
Subject: [Python-bugs-list] [Bug #110686] cStringIO lacks the readlines method (PR#409)
Message-ID: <200009162200.PAA10459@delerium.i.sourceforge.net>

Bug #110686, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: None
Bug Group: Feature Request
Priority: 4
Summary: cStringIO lacks the readlines method (PR#409)

Details: Jitterbug-Id: 409
Submitted-By: pierre@saiph.com
Date: Sun, 23 Jul 2000 13:41:59 -0400 (EDT)
Version: 1.5.2
OS: sparc solaris


cStringIO is supposed to be the C version of  For some reason,
it does not provide the readlines method.
The obvious turnaround is to use StringIO instead: no hurry to fix,
at least on my side.



====================================================================
Audit trail:
Mon Jul 24 18:41:02 2000	jeremy	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-05 13:11
By: loewis

Comment:
Fixed in Patch #101423,
http://sourceforge.net/patch/?func=detailpatch&patch_id=101423&group_id=5470
-------------------------------------------------------

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 15:00
By: bwarsaw

Comment:
Added to PEP 42
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110686&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 23:04:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 15:04:26 -0700
Subject: [Python-bugs-list] [Bug #110704] IDLE (PR#400)
Message-ID: <200009162204.PAA10601@delerium.i.sourceforge.net>

Bug #110704, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: IDLE (PR#400)

Details: Jitterbug-Id: 400
Submitted-By: crislipm@earthlink.net
Date: Sun, 16 Jul 2000 20:40:24 -0400 (EDT)
Version: 1.5.2
OS: Linuxppc, Suse dist


more for curiosity/FYI

Using 1.5.2 (the version that came with the suse linuxppc) and IDLE 0.5 on an
ibook (version 2).

IDLE causes the keyboard to stop working (I am not certain which, if any action,
causes this, but it is reproducable) and the problem continues when I warm boot
back to the MAC OS.  Have to do a cold boot to get keyboard to respond again.




====================================================================
Audit trail:
Mon Jul 24 18:30:07 2000	jeremy	changed notes
Mon Jul 24 18:30:07 2000	jeremy	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 15:04
By: bwarsaw

Comment:
Reassigned to Guido for disposal.  Maybe Jack should take a look?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110704&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 23:02:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 15:02:54 -0700
Subject: [Python-bugs-list] [Bug #110695] complexobject.c optimization error on SGI (PR#144)
Message-ID: <200009162202.PAA10497@delerium.i.sourceforge.net>

Bug #110695, was updated on 2000-Jul-31 14:28
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: complexobject.c optimization error on SGI (PR#144)

Details: Jitterbug-Id: 144
Submitted-By: robert.harrison@pnl.gov
Date: Fri, 3 Dec 1999 01:35:19 -0500 (EST)
Version: 1.5.2
OS: IRIX64 6.5


On an SGI (IRIX64 6.5, MIPSpro Compilers: Version 7.3.1m, -n32)
Python-1.5.2/Objects/complexobject.c does not compile correctly 
with optimization.  The problem shows up as a bus error in
PyComplex_ImagAsDouble when importing Numeric Python.  All works fine 
when this one file is compiled with -O0 (-O1 and higher fail).
I assume that this is probably just a compiler error.




====================================================================
Audit trail:
Fri Dec 03 10:39:28 1999	guido	changed notes
Fri Dec 03 10:39:28 1999	guido	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 15:02
By: bwarsaw

Comment:
Assigning to Fred, but we really need somebody with the specified OS to do platform specific testing.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110695&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 23:07:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 15:07:38 -0700
Subject: [Python-bugs-list] [Bug #110834] urlparse and HTTP parameters (PR#205)
Message-ID: <200009162207.PAA10666@delerium.i.sourceforge.net>

Bug #110834, was updated on 2000-Aug-01 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: Later
Bug Group: Feature Request
Priority: 3
Summary: urlparse and HTTP parameters (PR#205)

Details: Jitterbug-Id: 205
Submitted-By: mnot@akamai.com
Date: Tue, 15 Feb 2000 17:09:44 -0500 (EST)
Version: 1.5.2
OS: All


Python parses urls into the following data structure:
  (scheme, netloc, path, params, query, fragment)
and references RFC1808. 1808 has been updated by RFC2396, which allows
on each path segment, not just the last. This would imply a data structure
either like this:
  (scheme, netloc, path, query, fragment)
or this:
  (scheme, netloc, [(segment, parameters)...], query, fragment)

Rather than updating urlparse.py (and introducing incompatibility), it may be
nice to introduce a new class (say, uriparse.py) that implements 2396. If
there's enough interest, I may give it a go...


====================================================================
Audit trail:
Wed Feb 23 21:39:30 2000	guido	sent reply 1
Wed Feb 23 21:39:42 2000	guido	changed notes
Wed Feb 23 21:39:42 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:13
By: none

Comment:
From: Guido van Rossum <bugs-py@python.org>
Subject: Re: urlparse and HTTP parameters (PR#205)
Date: Wed Feb 23 21:39:30 2000

Go for it!

--Guido van Rossum

-------------------------------------------------------

Date: 2000-Aug-01 14:13
By: none

Comment:
Go for it!
-------------------------------------------------------

Date: 2000-Aug-16 19:02
By: fdrake

Comment:
An excellent idea; it can be incorporated in the existing urlparse module using new names.  This won't be done for Python 2.0 at any rate, however.
-------------------------------------------------------

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 15:07
By: bwarsaw

Comment:
Jeremy seems like the best person to decide about this.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110834&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 23:06:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 15:06:40 -0700
Subject: [Python-bugs-list] [Bug #110820] Jonathan Craft: Possible to-do addition (PR#116)
Message-ID: <200009162206.PAA10645@delerium.i.sourceforge.net>

Bug #110820, was updated on 2000-Aug-01 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Closed
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Jonathan Craft: Possible to-do addition (PR#116)

Details: Jitterbug-Id: 116
Submitted-By: Guido van Rossum <guido@CNRI.Reston.VA.US>
Date: Mon, 25 Oct 1999 10:38:58 -0400
Version: None
OS: None

A worthy to-do item.

------- Forwarded Message

Date:    Sat, 23 Oct 1999 08:24:32 -0000
From:    Jonathan Craft <jcchina@bigfoot.com>
To:      guido@python.org
Subject: Possible to-do addition

Hi Guido,

  Is there a visual interface builder (as in VBasic, Hypercard, Icon)
  for Tkinter? I haven't been able to find any information on it (I'm
  new to Python). If not, that would be a good to-do.


 Jonathan Craft                         mailto:jcchina@bigfoot.com



------- End of Forwarded Message



====================================================================
Audit trail:
Mon Oct 25 15:13:11 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-06 10:03
By: twouters

Comment:
I believe several people are working on something like this (or at least said they were... they might have quit in despair :-) I'm not sure if this belongs on the Python buglist, though.

-------------------------------------------------------

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 15:06
By: bwarsaw

Comment:
Added to PEP 42
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110820&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 23:10:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 15:10:16 -0700
Subject: [Python-bugs-list] [Bug #110844] Annoyance in ftpmirror.py script (PR#48)
Message-ID: <200009162210.PAA10817@delerium.i.sourceforge.net>

Bug #110844, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 5
Summary: Annoyance in ftpmirror.py script (PR#48)

Details: Jitterbug-Id: 48
Submitted-By: mok@imsb.au.dk
Date: Mon, 9 Aug 1999 10:27:00 -0400 (EDT)
Version: 1.5.2
OS: Linux Linux 2.0.36


The script ftpmirror.py contains some useful (for me) routines, but the file 
cannot be imported unless the following (trivial) patch is applied

395c395,396
< main()
---
> if __name__ == "__main__":
>       main()




====================================================================
Audit trail:
Tue Aug 10 17:46:08 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 15:10
By: bwarsaw

Comment:
Accepted and fixed.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110844&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 23:10:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 15:10:43 -0700
Subject: [Python-bugs-list] [Bug #110695] complexobject.c optimization error on SGI (PR#144)
Message-ID: <200009162210.PAA10823@delerium.i.sourceforge.net>

Bug #110695, was updated on 2000-Jul-31 14:28
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: Remind
Bug Group: Platform-specific
Priority: 5
Summary: complexobject.c optimization error on SGI (PR#144)

Details: Jitterbug-Id: 144
Submitted-By: robert.harrison@pnl.gov
Date: Fri, 3 Dec 1999 01:35:19 -0500 (EST)
Version: 1.5.2
OS: IRIX64 6.5


On an SGI (IRIX64 6.5, MIPSpro Compilers: Version 7.3.1m, -n32)
Python-1.5.2/Objects/complexobject.c does not compile correctly 
with optimization.  The problem shows up as a bus error in
PyComplex_ImagAsDouble when importing Numeric Python.  All works fine 
when this one file is compiled with -O0 (-O1 and higher fail).
I assume that this is probably just a compiler error.




====================================================================
Audit trail:
Fri Dec 03 10:39:28 1999	guido	changed notes
Fri Dec 03 10:39:28 1999	guido	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 15:02
By: bwarsaw

Comment:
Assigning to Fred, but we really need somebody with the specified OS to do platform specific testing.
-------------------------------------------------------

Date: 2000-Sep-16 15:10
By: fdrake

Comment:
Sent a message to the original submitter asking if this is still a problem, and indicated that we don't have access to any SGI IRIX systems on which to perform testing.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110695&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 23:10:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 15:10:47 -0700
Subject: [Python-bugs-list] [Bug #110849] Fwd: Debian Bug#42318: urllib.py has problems with malformed proxy env. variables (PR#59)
Message-ID: <200009162210.PAA10829@delerium.i.sourceforge.net>

Bug #110849, was updated on 2000-Aug-01 14:16
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Fwd: Debian Bug#42318: urllib.py has problems with malformed proxy env. variables (PR#59)

Details: Jitterbug-Id: 59
Submitted-By: flight@debian.org
Date: Fri, 20 Aug 1999 13:40:04 -0400 (EDT)
Version: 1.5.2
OS: Debian potato


Summary: Python's urllib expects a fully qualified URL in HTTP_PROXY (like
"http://proxy:8080/"). Many applications allow short forms in HTTP_PROXY
(like "proxy:8080"). If HTTP_PROXY is set to a short form, urllib.py will
fail with an uncomprehensible error message.


Long form:

Francesco Potorti` <F.Potorti@cnuce.cnr.it> says (in the Debian bug report
http://www.debian.org/Bugs/db/42/42318.html):

  "when setting a proxy variable that is not parsed by urllib, urllib does
   not print a comprehensible error message."

An example:


Short form HTTP_PROXY:

  master% HTTP_PROXY="proxy.cnr.it:8081" \
    python -c 'import urllib; print
urllib.urlretrieve("http://www.olemiss.edu/")'
  Traceback (innermost last):
    File "<string>", line 1, in ?
    File "/usr/lib/python1.5/urllib.py", line 69, in urlretrieve
      return _urlopener.retrieve(url)
    File "/usr/lib/python1.5/urllib.py", line 186, in retrieve
      fp = self.open(url)
    File "/usr/lib/python1.5/urllib.py", line 154, in open
      return self.open_unknown(fullurl)
    File "/usr/lib/python1.5/urllib.py", line 168, in open_unknown
      raise IOError, ('url error', 'unknown url type', type)
  IOError: ('url error', 'unknown url type', 'http')


Fully qualified URL in HTTP_PROXY:

  master% HTTP_PROXY="http://proxy.cnr.it:8081" \
    python -c 'import urllib; print
urllib.urlretrieve("http://www.olemiss.edu/")'
  ('/tmp/@15884.1', <mimetools.Message instance at 80adb08>)



====================================================================
Audit trail:
Mon Aug 30 12:35:03 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 22:52
By: tim_one

Comment:
Assigned to Barry because I think of him as being the Potato Man.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110849&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 23:16:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 15:16:23 -0700
Subject: [Python-bugs-list] [Bug #110627] Floating point numbers (PR#277)
Message-ID: <200009162216.PAA11026@delerium.i.sourceforge.net>

Bug #110627, was updated on 2000-Jul-31 14:08
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 3
Summary: Floating point numbers (PR#277)

Details: Jitterbug-Id: 277
Submitted-By: gellsmore@yahoo.com
Date: Wed,  5 Apr 2000 17:00:09 -0400 (EDT)
Version: Python CE 1.0b1
OS: Windows CE H/PC 3.01 pro


Floating point answer objects not returned correctly

>>>3.1
g

All floats return g but will work in scenario below where floats form part of
the expression but not the answer object

>>>int(3.1/2)
1

this works.



====================================================================
Audit trail:
Mon May 22 17:49:40 2000	guido	changed notes
Mon May 22 17:49:40 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-03 05:50
By: twouters

Comment:
Hm, Python CE 1.0b1 ? I'm not sure if that's an old version of Python ported to the CE, or a recent version of Python ported to the CE with a new version number. In any case, I dont believe the CE port is being maintained by the core Python group, so I don't think we can do much about it.

-------------------------------------------------------

Date: 2000-Sep-07 15:02
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 14:50
By: bwarsaw

Comment:
This works fine for me on Linux w/ Python 2.0b1.  I don't have Windows CE available to test if it's a platform bug.
-------------------------------------------------------

Date: 2000-Sep-16 15:16
By: tim_one

Comment:
Reassigned to Mark Hammond, as I believe he did the CE port.  There's no problem here in the Python core, so nothing we can do about it.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110627&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 23:13:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 15:13:34 -0700
Subject: [Python-bugs-list] [Bug #110855] test_array.py fails (PR#143)
Message-ID: <200009162213.PAA10963@delerium.i.sourceforge.net>

Bug #110855, was updated on 2000-Aug-01 14:37
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Works For Me
Bug Group: Irreproducible
Priority: 1
Summary: test_array.py fails (PR#143)

Details: Jitterbug-Id: 143
Submitted-By: ellement@sdd.hp.com
Date: Thu, 2 Dec 1999 14:04:38 -0500 (EST)
Version: 1.5.2
OS: HP-UX 10.20


After building python, 'make test' fails when test_array is run:

> python Lib/test/test_array.py
Traceback (innermost last):
  File "Lib/test/test_array.py", line 85, in ?
    main()
  File "Lib/test/test_array.py", line 10, in main
    testtype('c', 'c')
  File "Lib/test/test_array.py", line 21, in testtype
    a.append(example)
AttributeError: '' object has no attribute 'append'
Memory fault(coredump)


How do I go about debugging this?


====================================================================
Audit trail:
Fri Dec 03 10:38:53 1999	guido	changed notes
Fri Dec 03 10:38:53 1999	guido	moved from incoming to irreproducible

Follow-Ups:

Date: 2000-Aug-01 14:37
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] test_array.py fails (PR#143)
Date: Thu, 02 Dec 1999 14:07:32 -0500

> Full_Name: David Ellement
> Version: 1.5.2
> OS: HP-UX 10.20
> Submission from: sanrel1.sdd.hp.com (192.6.114.30)
> 
> 
> After building python, 'make test' fails when test_array is run:
> 
> > python Lib/test/test_array.py
> Traceback (innermost last):
>   File "Lib/test/test_array.py", line 85, in ?
>     main()
>   File "Lib/test/test_array.py", line 10, in main
>     testtype('c', 'c')
>   File "Lib/test/test_array.py", line 21, in testtype
>     a.append(example)
> AttributeError: '' object has no attribute 'append'
> Memory fault(coredump)
> 
> 
> How do I go about debugging this?

Seems like a pretty serious problem in your build.  Use a debugger
(e.g. gdb).  The bugs list is not the forum to discuss this, since the
bug is likely in your installation and not in Python.  Try
comp.lang.python for help.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:37
By: none

Comment:
Build problems?
-------------------------------------------------------

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 15:13
By: bwarsaw

Comment:
Confirmed that this bug is not reproducible.  It's either a platform bug or has gone away with Python 2.0.  I believe it's fine to close this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110855&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 23:19:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 15:19:21 -0700
Subject: [Python-bugs-list] [Bug #113721] urllib handles proxy badly
Message-ID: <200009162219.PAA11156@delerium.i.sourceforge.net>

Bug #113721, was updated on 2000-Sep-06 09:30
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: urllib handles proxy badly

Details: The following gives "host not found" when a proxy server is in use:

    import urllib
    w=urllib.urlopen("http://www.pythonlabs.com")

The host name is changed to "http=PROXYSERVER" and fails

This works under Python 1.5.2, but fails under Python 2.0b1

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113721&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 23:19:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 15:19:58 -0700
Subject: [Python-bugs-list] [Bug #113788] NT 2.0b1 Doc/modindex.html is almost empty
Message-ID: <200009162219.PAA11171@delerium.i.sourceforge.net>

Bug #113788, was updated on 2000-Sep-07 03:29
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: NT 2.0b1 Doc/modindex.html is almost empty

Details: Doc/modindex.html in the 2.0b1 release on NT is empty. 
There is only the header and footer but no module list.

Can't login to sourceforge so:
tebeka@lycosmail.com


Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 15:19
By: bwarsaw

Comment:
I believe Fred has fixed this, but I'm reassigning to him for final disposal.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113788&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 23:18:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 15:18:45 -0700
Subject: [Python-bugs-list] [Bug #110924] support Unicode for Python source code
Message-ID: <200009162218.PAA11147@delerium.i.sourceforge.net>

Bug #110924, was updated on 2000-Aug-02 08:17
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 1
Summary: support Unicode for Python source code

Details: exec u"print 42"
doesn't work.

Follow-Ups:

Date: 2000-Aug-09 02:35
By: effbot

Comment:
python doesn't support 16-bit source code -- so what exactly do you want exec to do?
-------------------------------------------------------

Date: 2000-Aug-17 05:17
By: none

Comment:
That's exactly my point. Python should support Unicode
everywhere, in __str__ and __repr__, exec and eval, in open(), as a format for the source code (which would result in all variable names to be Unicode)...

Currenly working with Unicode (e.g. for XML) is a mess, because it's supported nowhere.

exec "a='ü'" seems to work and seems to treat the string as iso-8859-1 (or not at all)

-------------------------------------------------------

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 05:21
By: lemburg

Comment:
I don't think that the situation is that bad. You can't program
Python in Unicode, but this doesn't stop you from using it
in your Python programs.

Note that __str__ and __repr__ do support Unicode (it gets converted
to an 8-bit string using the default encoding).

There's currently not much need to have exec or eval() automatically
apply any conversion... you can always use str() around the argument
to make it support both 8-bit strings and Unicode.

-------------------------------------------------------

Date: 2000-Sep-16 15:18
By: bwarsaw

Comment:
Reassigning to Guido for final disposal, but I believe this should be marked either as "not a bug" or added to PEP 42.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110924&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 23:25:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 15:25:12 -0700
Subject: [Python-bugs-list] [Bug #113463] Inconsistent handling of arg -/-- by getopt.getopt() ?
Message-ID: <200009162225.PAA11354@delerium.i.sourceforge.net>

Bug #113463, was updated on 2000-Sep-02 19:44
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Inconsistent handling of arg -/-- by getopt.getopt() ?

Details: Problem with function getopt of module getopt.py of Python 1.5.1?

Case 1:

>>> import getopt, string
>>> args = string.split('-a -b b_val - some more stuff -c')
>>> optlist, trailing_args = getopt.getopt(args, 'ab:c')
>>> optlist
[('-a', ''), ('-b', 'b_val')]
>>> trailing_args
['-', 'some', 'more', 'stuff', '-c']

Case 2:

>>> import getopt, string
>>> args = string.split('-a -b b_val -- some more stuff -c')
>>> optlist, trailing_args = getopt.getopt(args, 'ab:c')
>>> optlist
[('-a', ''), ('-b', 'b_val')]
>>> trailing_args
['some', 'more', 'stuff', '-c']

The differences are: 
In case 1, I have "-" in the args list and I get it as the first element of the trailing_args output list; In case 2, I have "--" in the args list and I get nothing about it in the trailing_args output list.

This happens because in line 7 of the function getopt (reproduced below) the "--" element of args is discarded.

~~~~~~~~~
Function getopt:

def getopt(args, shortopts, longopts = []):
    list = []
    longopts = longopts[:]
    longopts.sort()
    while args and args[0][:1] == '-' and args[0] != '-':
        if args[0] == '--':
            args = args[1:]
            break
        if args[0][:2] == '--':
            list, args = do_longs(list, args[0][2:], longopts, args[1:])
        else:
            list, args = do_shorts(list, args[0][1:], shortopts, args[1:])

    return list, args


Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-10 20:05
By: sebrosa

Comment:
Well, maybe its not a bug, just a feature. The only strange thing is that getopt returns the same output with input args

args = string.split('-a -b b_val -- some more stuff -c') 

and with input args

args = string.split('-a -b b_val some more stuff -c') 

which means that getopt does not give the program using it a chance to recognize whether args include "--" or not.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113463&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 23:32:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 15:32:34 -0700
Subject: [Python-bugs-list] [Bug #113960] Problems with reverse() in the array module
Message-ID: <200009162232.PAA27424@bush.i.sourceforge.net>

Bug #113960, was updated on 2000-Sep-09 13:20
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 8
Summary: Problems with reverse() in the array module

Details: When I was using Python-2.0b1, reverse() for arrays was acting funny for me:

>>> import array
>>> bob = array.array('c', 'a string')
>>> bob.reverse()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: <array>.reverse requires exactly 0 arguments

But, I didn't pass it any arguments :-).  When I looked at the code I came up with the following fix:

*** arraymodule.c.orig	Fri Sep  1 19:29:26 2000
--- arraymodule.c	Sat Sep  9 16:04:16 2000
***************
*** 935,945 ****
  	register char *p, *q;
  	char tmp[sizeof(double)]; /* Assume that's the max item size */
  
! 	if (args != NULL) {
! 		PyErr_SetString(PyExc_TypeError,
! 		     "<array>.reverse requires exactly 0 arguments");
! 		return NULL;
! 	}
  
  	if (self->ob_size > 1) {
  		for (p = self->ob_item,
--- 935,942 ----
  	register char *p, *q;
  	char tmp[sizeof(double)]; /* Assume that's the max item size */
  
! 	if (!PyArg_ParseTuple(args, ":reverse"))
! 	    return NULL;
  
  	if (self->ob_size > 1) {
  		for (p = self->ob_item,

Reverse seems to work properly with this:

>>> import array
>>> bob = array.array('c', 'a string')
>>> bob.reverse()
>>> print bob
array('c', 'gnirts a')

and the error message for passing argument seems reasonable:

>>> bob.reverse('spam')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: reverse requires exactly 0 arguments; 1 given

I'm really not an expert on any of this, but I hope the report is useful. Thanks for listening.

Brad

Follow-Ups:

Date: 2000-Sep-09 18:08
By: tim_one

Comment:
Thanks!  Boosted the priority and assigned to me:  this is plain embarrassing -- the code couldn't possibly work as intended.  I'll fix it and add a regression test to the std test suite so it never happens again.
-------------------------------------------------------

Date: 2000-Sep-16 15:32
By: tim_one

Comment:
Fixed and closed; checkin comment:

arraymodule:  Fix SF bug 113960.
    reverse() didn't work at all due to bad arg check.
    Fixed that.
    Added Brad Chapman to ACKS file, as the proud new owner of two implicitly copyrighted lines of Python source code <wink>.
    Repaired buffer_info's total lack of arg-checking.
    Replaced memmove by memcpy in reverse() guts, as memmove is often slower and the memory areas are guaranteed disjoint.
    Replaced poke-and-hope unchecked decl of tmp buffer size by assert-checked larger tmp buffer.
    Got rid of inconsistent spaces before open paren in docstrings.
    Added reverse() sanity tests to test_array.py.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113960&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 23:34:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 15:34:42 -0700
Subject: [Python-bugs-list] [Bug #110627] Floating point numbers (PR#277)
Message-ID: <200009162234.PAA11704@delerium.i.sourceforge.net>

Bug #110627, was updated on 2000-Jul-31 14:08
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Wont Fix
Bug Group: 3rd Party
Priority: 3
Summary: Floating point numbers (PR#277)

Details: Jitterbug-Id: 277
Submitted-By: gellsmore@yahoo.com
Date: Wed,  5 Apr 2000 17:00:09 -0400 (EDT)
Version: Python CE 1.0b1
OS: Windows CE H/PC 3.01 pro


Floating point answer objects not returned correctly

>>>3.1
g

All floats return g but will work in scenario below where floats form part of
the expression but not the answer object

>>>int(3.1/2)
1

this works.



====================================================================
Audit trail:
Mon May 22 17:49:40 2000	guido	changed notes
Mon May 22 17:49:40 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-03 05:50
By: twouters

Comment:
Hm, Python CE 1.0b1 ? I'm not sure if that's an old version of Python ported to the CE, or a recent version of Python ported to the CE with a new version number. In any case, I dont believe the CE port is being maintained by the core Python group, so I don't think we can do much about it.

-------------------------------------------------------

Date: 2000-Sep-07 15:02
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 14:50
By: bwarsaw

Comment:
This works fine for me on Linux w/ Python 2.0b1.  I don't have Windows CE available to test if it's a platform bug.
-------------------------------------------------------

Date: 2000-Sep-16 15:16
By: tim_one

Comment:
Reassigned to Mark Hammond, as I believe he did the CE port.  There's no problem here in the Python core, so nothing we can do about it.
-------------------------------------------------------

Date: 2000-Sep-16 15:34
By: mhammond

Comment:
The CE port is not maintained by the core Python group - indeed, as far as I know, it is not being maintained by anyone.  Marking as "Wont Fix", but I will forward the bug report to the python-ce mailing list.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110627&group_id=5470

From noreply@sourceforge.net  Sat Sep 16 23:40:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 15:40:48 -0700
Subject: [Python-bugs-list] [Bug #114490] crash on empty module registry key
Message-ID: <200009162240.PAA11888@delerium.i.sourceforge.net>

Bug #114490, was updated on 2000-Sep-15 00:31
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: crash on empty module registry key

Details: Having an empty module path key under the PythonPath Registry key lets Python die on startup.

Follow-Ups:

Date: 2000-Sep-15 00:40
By: tim_one

Comment:
Assigned to MarkH and boosted priority.

BobJuner, you didn't say which version of Python you're using.  If you can, please try it with a current snapshot from CVS:  MarkH very recently fixed something similar, and possibly similar enough to be identical.

-------------------------------------------------------

Date: 2000-Sep-16 14:29
By: BobJuner

Comment:
This occured to me using 2.0b1. I'll try a CVS snapshot during the next days.
-------------------------------------------------------

Date: 2000-Sep-16 15:40
By: mhammond

Comment:
Almost certainly a dupe of 113828 - as you have not produced a test case I can not be 100% sure this is the same bug, but am pretty close to that sure :-)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114490&group_id=5470

From noreply@sourceforge.net  Sun Sep 17 00:12:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 16:12:36 -0700
Subject: [Python-bugs-list] [Bug #113793] getopt.c compile fails on Solaris 2.6/gcc 2.95.2
Message-ID: <200009162312.QAA28751@bush.i.sourceforge.net>

Bug #113793, was updated on 2000-Sep-07 06:09
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: getopt.c compile fails on Solaris 2.6/gcc 2.95.2

Details: I configured python with the following options:
/ldatae/Misc/python/Python-1.6/configure  --program-prefix=g --target=sparc-su
n-solaris2.6 --prefix=/projects/gnu/sparc-sun-solaris2.6 --exec-prefix=/projects
/gnu/sparc-sun-solaris2.6 --with-gnu-gettext --with-rx --with-curses=/projects/g
nu/sparc-sun-solaris2.6/lib --with-shared --with-profile --enable-nls --x-includ
es=/usr/openwin/include --x-libraries=/usr/openwin/lib --with-wctype-functions -
-with-x-toolkit=motif --with-x --with-threads
After compiling for a while, the build stops with this error:

gcc -g -O2 -I/ldatae/Misc/python/Python-1.6/Python/../Include -I.. -DHAVE_CONFIG
_H   -c -o getopt.o getopt.c
getopt.c: In function `getopt':
getopt.c:51: argument `argv' doesn't match prototype
/usr/include/stdio.h:329: prototype declaration
getopt.c:51: argument `optstring' doesn't match prototype
/usr/include/stdio.h:329: prototype declaration
make[1]: *** [getopt.o] Error 1
make[1]: Leaving directory `/ldatae/Misc/python/Python-1.6/Python'
make: *** [Python] Error 


I can supply more details if someone emails me at lvirden@cas.org .

Thank you.

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 16:12
By: bwarsaw

Comment:
getopt.c doesn't seem to get compiled on Solaris 2.6 in Python 2.0.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113793&group_id=5470

From noreply@sourceforge.net  Sun Sep 17 00:41:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 16:41:39 -0700
Subject: [Python-bugs-list] [Bug #110609] Operator breakage with long int operands (PR#187)
Message-ID: <200009162341.QAA13974@delerium.i.sourceforge.net>

Bug #110609, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Operator breakage with long int operands (PR#187)

Details: Jitterbug-Id: 187
Submitted-By: aa8vb@yahoo.com
Date: Mon, 24 Jan 2000 11:19:11 -0500 (EST)
Version: 1.5.2
OS: IRIX 6.5


This came up a few weeks ago, and bit again in the dumbdbm module last week.
In the dumbdbm module in 1.5.2:

     '\0'*(npos-pos)

(npos-pos) on some OSs will be a long int.  However, the '*' operator won't 
handle a long int.  I can't think of a reason why 'a'*10L should be invalid,
for example.

At issue a few weeks ago was long ints and the '%' operator.  For example:

    >>> str( 0x80000000L )
    '2147483648L'
    >>> "%ld" % 0x80000000L
    OverflowError: long int too long to convert

    >>> hex( 0x80000000L )
    '0x80000000L'
    >>> "%lX" % 0x80000000L
    OverflowError: long int too long to convert

Couldn't % use hex() and str() under the hood, for instance?



====================================================================
Audit trail:
Mon Jan 24 14:28:42 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-16 06:57
By: loewis

Comment:
I believe the first issue is resolved in 2.0b1; '\0' * 10L does work.
-------------------------------------------------------

Date: 2000-Sep-16 16:41
By: loewis

Comment:
A patch for the formatting problem in in

http://sourceforge.net/patch/?func=detailpatch&patch_id=101544&group_id=5470
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110609&group_id=5470

From noreply@sourceforge.net  Sun Sep 17 01:43:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 17:43:58 -0700
Subject: [Python-bugs-list] [Bug #114439] define_macros ignored when building Extension
Message-ID: <200009170043.RAA31786@bush.i.sourceforge.net>

Bug #114439, was updated on 2000-Sep-14 08:44
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: define_macros ignored when building Extension

Details: I am working on a setup script for Tkinter, which requires a
-DWITH_APPINIT flag at compile time.  The docs suggest that I should
add the following definition to my Extension constructor call:
    define_macros=[('WITH_APPINIT', None),],

I did this, but it had no effect.  It looks like there is no where
that the define_macros attribute of the Extension object is actually
used.  

I assumed this is a bug and tried to figure out where the macros
definitions ought to be processed.  I'm not familiar with the code, so
I may have put it in the wrong place.  A patch is included below,
which allows _tkinter to build.

Jeremy

*** build_ext.py	Tue Sep 12 20:58:48 2000
--- /home/jeremy/src/python/dist/src/Lib/distutils/command/build_ext.py	Thu Sep  7 11:09:18 2000
***************
*** 401,407 ****
              # any sensible compiler will give precedence to later
              # command line args.  Hence we combine them in order:
              extra_args = ext.extra_compile_args or []
-             macros = ext.define_macros or []
  
              # XXX and if we support CFLAGS, why not CC (compiler
              # executable), CPPFLAGS (pre-processor options), and LDFLAGS
--- 401,406 ----
***************
*** 410,419 ****
  
              if os.environ.has_key('CFLAGS'):
                  extra_args.extend(string.split(os.environ['CFLAGS']))
! 
              objects = self.compiler.compile (sources,
                                               output_dir=self.build_temp,
!                                              macros=macros,
                                               include_dirs=ext.include_dirs,
                                               debug=self.debug,
                                               extra_postargs=extra_args)
--- 409,418 ----
  
              if os.environ.has_key('CFLAGS'):
                  extra_args.extend(string.split(os.environ['CFLAGS']))
!                 
              objects = self.compiler.compile (sources,
                                               output_dir=self.build_temp,
!                                              #macros=macros,
                                               include_dirs=ext.include_dirs,
                                               debug=self.debug,
                                               extra_postargs=extra_args)


Follow-Ups:

Date: 2000-Sep-16 17:43
By: gward

Comment:
Jeremy's patch was just fine.  I tweaked it a bit to handle ext.undef_macros, too.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114439&group_id=5470

From noreply@sourceforge.net  Sun Sep 17 03:33:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 19:33:39 -0700
Subject: [Python-bugs-list] [Bug #113463] Inconsistent handling of arg -/-- by getopt.getopt() ?
Message-ID: <200009170233.TAA19530@delerium.i.sourceforge.net>

Bug #113463, was updated on 2000-Sep-02 19:44
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: Inconsistent handling of arg -/-- by getopt.getopt() ?

Details: Problem with function getopt of module getopt.py of Python 1.5.1?

Case 1:

>>> import getopt, string
>>> args = string.split('-a -b b_val - some more stuff -c')
>>> optlist, trailing_args = getopt.getopt(args, 'ab:c')
>>> optlist
[('-a', ''), ('-b', 'b_val')]
>>> trailing_args
['-', 'some', 'more', 'stuff', '-c']

Case 2:

>>> import getopt, string
>>> args = string.split('-a -b b_val -- some more stuff -c')
>>> optlist, trailing_args = getopt.getopt(args, 'ab:c')
>>> optlist
[('-a', ''), ('-b', 'b_val')]
>>> trailing_args
['some', 'more', 'stuff', '-c']

The differences are: 
In case 1, I have "-" in the args list and I get it as the first element of the trailing_args output list; In case 2, I have "--" in the args list and I get nothing about it in the trailing_args output list.

This happens because in line 7 of the function getopt (reproduced below) the "--" element of args is discarded.

~~~~~~~~~
Function getopt:

def getopt(args, shortopts, longopts = []):
    list = []
    longopts = longopts[:]
    longopts.sort()
    while args and args[0][:1] == '-' and args[0] != '-':
        if args[0] == '--':
            args = args[1:]
            break
        if args[0][:2] == '--':
            list, args = do_longs(list, args[0][2:], longopts, args[1:])
        else:
            list, args = do_shorts(list, args[0][1:], shortopts, args[1:])

    return list, args


Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-10 20:05
By: sebrosa

Comment:
Well, maybe its not a bug, just a feature. The only strange thing is that getopt returns the same output with input args

args = string.split('-a -b b_val -- some more stuff -c') 

and with input args

args = string.split('-a -b b_val some more stuff -c') 

which means that getopt does not give the program using it a chance to recognize whether args include "--" or not.

-------------------------------------------------------

Date: 2000-Sep-16 19:33
By: gvanrossum

Comment:
This is not a bug but a feature. Read the docs. Python
s getopt() function mimics the C getopt() function as closely as possible, and this is a (useful!) feature there. (It's useful because a '--' can be used to end the option list, in case a non-option argument has to start with a '-'.)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113463&group_id=5470

From noreply@sourceforge.net  Sun Sep 17 03:44:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 19:44:21 -0700
Subject: [Python-bugs-list] [Bug #113793] getopt.c compile fails on Solaris 2.6/gcc 2.95.2
Message-ID: <200009170244.TAA03432@bush.i.sourceforge.net>

Bug #113793, was updated on 2000-Sep-07 06:09
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Wont Fix
Bug Group: Platform-specific
Priority: 6
Summary: getopt.c compile fails on Solaris 2.6/gcc 2.95.2

Details: I configured python with the following options:
/ldatae/Misc/python/Python-1.6/configure  --program-prefix=g --target=sparc-su
n-solaris2.6 --prefix=/projects/gnu/sparc-sun-solaris2.6 --exec-prefix=/projects
/gnu/sparc-sun-solaris2.6 --with-gnu-gettext --with-rx --with-curses=/projects/g
nu/sparc-sun-solaris2.6/lib --with-shared --with-profile --enable-nls --x-includ
es=/usr/openwin/include --x-libraries=/usr/openwin/lib --with-wctype-functions -
-with-x-toolkit=motif --with-x --with-threads
After compiling for a while, the build stops with this error:

gcc -g -O2 -I/ldatae/Misc/python/Python-1.6/Python/../Include -I.. -DHAVE_CONFIG
_H   -c -o getopt.o getopt.c
getopt.c: In function `getopt':
getopt.c:51: argument `argv' doesn't match prototype
/usr/include/stdio.h:329: prototype declaration
getopt.c:51: argument `optstring' doesn't match prototype
/usr/include/stdio.h:329: prototype declaration
make[1]: *** [getopt.o] Error 1
make[1]: Leaving directory `/ldatae/Misc/python/Python-1.6/Python'
make: *** [Python] Error 


I can supply more details if someone emails me at lvirden@cas.org .

Thank you.

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 16:12
By: bwarsaw

Comment:
getopt.c doesn't seem to get compiled on Solaris 2.6 in Python 2.0.
-------------------------------------------------------

Date: 2000-Sep-16 19:44
By: gvanrossum

Comment:
Hm...  The getopt.c source is only meant as a fallback when there's no getopt() in the C library.

Could it be that you have the dreaded GNU getopt installed? That is evil, because it eats options anywhere in the command line instead of stopping at the first non-option argument.  (It is evil because it means you can't pass options to your Python scripts.)

Also, apparently your <stdio.h> or <string.h> exports a prototype for getopt() that doesn't match the one in getopt.c. There's not much we can do about this, because getopt() prototypes are variable across platforms. A correct ANSI C compiler doesn't export a getopt() prototype at all from a standard header file!!!

So, I can't do much about this, and I'll close the bug report.  If you have a patch that fixes it for you without breaking ot for others, I'll use that of course.
Getting the getopt prototype correct cross-platform is nearly impossible
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113793&group_id=5470

From noreply@sourceforge.net  Sun Sep 17 03:51:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 19:51:20 -0700
Subject: [Python-bugs-list] [Bug #110924] support Unicode for Python source code
Message-ID: <200009170251.TAA03632@bush.i.sourceforge.net>

Bug #110924, was updated on 2000-Aug-02 08:17
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 1
Summary: support Unicode for Python source code

Details: exec u"print 42"
doesn't work.

Follow-Ups:

Date: 2000-Aug-09 02:35
By: effbot

Comment:
python doesn't support 16-bit source code -- so what exactly do you want exec to do?
-------------------------------------------------------

Date: 2000-Aug-17 05:17
By: none

Comment:
That's exactly my point. Python should support Unicode
everywhere, in __str__ and __repr__, exec and eval, in open(), as a format for the source code (which would result in all variable names to be Unicode)...

Currenly working with Unicode (e.g. for XML) is a mess, because it's supported nowhere.

exec "a='ü'" seems to work and seems to treat the string as iso-8859-1 (or not at all)

-------------------------------------------------------

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 05:21
By: lemburg

Comment:
I don't think that the situation is that bad. You can't program
Python in Unicode, but this doesn't stop you from using it
in your Python programs.

Note that __str__ and __repr__ do support Unicode (it gets converted
to an 8-bit string using the default encoding).

There's currently not much need to have exec or eval() automatically
apply any conversion... you can always use str() around the argument
to make it support both 8-bit strings and Unicode.

-------------------------------------------------------

Date: 2000-Sep-16 15:18
By: bwarsaw

Comment:
Reassigning to Guido for final disposal, but I believe this should be marked either as "not a bug" or added to PEP 42.
-------------------------------------------------------

Date: 2000-Sep-16 19:51
By: gvanrossum

Comment:
There's an Accepted patch for this by Marc-Andre Lemburg.
Assigned to Marc-Andre so he can close the bug when he applies the patch.

(Marc-Andre: if you don't have time to apply the patch, let me know and I'll take care of it.)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110924&group_id=5470

From noreply@sourceforge.net  Sun Sep 17 04:29:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 20:29:41 -0700
Subject: [Python-bugs-list] [Bug #112786] Build under Cygwin fails
Message-ID: <200009170329.UAA04898@bush.i.sourceforge.net>

Bug #112786, was updated on 2000-Aug-26 01:39
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Build under Cygwin fails

Details: Py1.6b1
========
1) socketmodule.c -- looks for netinet/tcp.h, which does not exist on cygwin.

2) gcc   python.o \
          ../libpython1.6.a    -lm  -o python
python.o: In function `main':
/usr/local/bin/Python-1.6b1/Modules/python.c:12: undefined reference to `Py_Main


Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 04:13
By: gvanrossum

Comment:
I don't have cygwin. Does anyone here have cygwin? I know Tim said the cygwin installer failed for him, so he doesn't have it. Is there someone outside the PythonLabs to whom we could assign this?
-------------------------------------------------------

Date: 2000-Sep-16 01:56
By: tim_one

Comment:
A fellow named Norman mailto:nhv@yahoo.com posted to c.l.py with some evidence of real Cygwin knowledge, so I emailed him a link to this bug and asked whether he'd help out.
-------------------------------------------------------

Date: 2000-Sep-16 20:29
By: nhv

Comment:
Hi I am that fellow Norman

FYI I have been doing bi-weekly builds of the Python CVS source with the 'current' Cygwin distribution for about a year.

I sent Tim my small set of diffs

Basically threading with Cygwin Python is still broken
and dll building with Cygwin has some problems but other then that everything including tkinter works for me with very minor changes.

FWIW We are succesfully embedding Python in PrettyPoly
http://prettypoly.sourceforge.net and I am using Cygwin
as my development enviroment for this

If helpful I can mail someone my diffs and the results of make test after each of my CVS sessions or apon request

Also FWIW I build Cygwin from source and have access to the Cygwin development team

I will help in anyway I can to make Python compile with Cygwin 'out of the box'  


Norman Vine nhv@yahoo.com

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112786&group_id=5470

From noreply@sourceforge.net  Sun Sep 17 04:35:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Sep 2000 20:35:31 -0700
Subject: [Python-bugs-list] [Bug #113788] NT 2.0b1 Doc/modindex.html is almost empty
Message-ID: <200009170335.UAA05077@bush.i.sourceforge.net>

Bug #113788, was updated on 2000-Sep-07 03:29
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: NT 2.0b1 Doc/modindex.html is almost empty

Details: Doc/modindex.html in the 2.0b1 release on NT is empty. 
There is only the header and footer but no module list.

Can't login to sourceforge so:
tebeka@lycosmail.com


Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 15:19
By: bwarsaw

Comment:
I believe Fred has fixed this, but I'm reassigning to him for final disposal.
-------------------------------------------------------

Date: 2000-Sep-16 20:35
By: fdrake

Comment:
Fixed in documentation release 2.0b1.1 available at pythonlabs.com.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113788&group_id=5470

From noreply@sourceforge.net  Sun Sep 17 12:03:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Sep 2000 04:03:20 -0700
Subject: [Python-bugs-list] [Bug #113760] 2.0b1: _xmlplus does not allow site xml to override Lib/xml
Message-ID: <200009171103.EAA18826@bush.i.sourceforge.net>

Bug #113760, was updated on 2000-Sep-06 16:53
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: 2.0b1: _xmlplus does not allow site xml to override Lib/xml

Details: _xmlplus is represented as a means of overriding the new standard lib xml package with a user-supplied xml package, such as the one from XML-SIG ("There's a special feature whereby a user-installed package named _xmlplus overrides the standard xmlpackage; this is intended to give the XML SIG a hook to distribute backwards-compatible updates to the standard xml package." - quote from News on BeOpen site). While this has _some_ effect, it does not work as described. Under 2.0b1, code using the xml package from the XML-SIG (installed in site-packages) will only work if the new standard xml package in lib is renamed or removed. If used with the new standard xml package, imports such as
from xml.sax import saxexts
fail. If the _xmlplus hook is used (by renaming site-packages/xml to site-packages/_xmlplus or using a symlink), the imports succeed, but later the code fails with a message stating that no parsers can be found. 

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 16:12
By: mfavas

Comment:
Martin v. Loewis has justed posted a link on xml-sig to a patch for the "no parsers can be found" problem. I've applied the patch (by hand - "patch" failed) and all seems OK. Custom, tricky ways of finding/doing imports abound... Wasn't there some talk of tidying-up imports and import hooks? (MvL's patch is at http://sourceforge.net/patch/?func=detailpatch&patch_id=101444&group_id=6473 )
- Mark
-------------------------------------------------------

Date: 2000-Sep-07 16:17
By: mfavas

Comment:
Martin v. Loewis has justed posted a link on xml-sig to a patch for the "no parsers can be found" problem. I've applied the patch (by hand - "patch" failed) and all seems OK. Custom, tricky ways of finding/doing imports abound... Wasn't there some talk of tidying-up imports and import hooks? (MvL's patch is at http://sourceforge.net/patch/?func=detailpatch&patch_id=101444&group_id=6473 )
- Mark
-------------------------------------------------------

Date: 2000-Sep-17 04:03
By: loewis

Comment:
The patch to fix this problem is now in the PyXML CVS tree.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113760&group_id=5470

From noreply@sourceforge.net  Sun Sep 17 12:24:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Sep 2000 04:24:40 -0700
Subject: [Python-bugs-list] [Bug #110612] anydbm can't handle dumbdbm (PR#200)
Message-ID: <200009171124.EAA06358@delerium.i.sourceforge.net>

Bug #110612, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: anydbm can't handle dumbdbm (PR#200)

Details: Jitterbug-Id: 200
Submitted-By: aa8vb@yahoo.com
Date: Wed, 9 Feb 2000 13:05:57 -0500 (EST)
Version: 1.5.2
OS: IRIX 6.5


Basically, anydbm won't open dumbdbm files that anydbm created.

   >>> import anydbm
   >>> db = anydbm.open( "database", "c" )
   >>> db[ "1" ] = "one"
   >>> db.close()
   >>> db = anydbm.open( "database", "r" )
   Traceback (innermost last):
     File "<stdin>", line 1, in ?
     File "/home/rhh/software/python-1.5.2/lib/python1.5/anydbm.py", line 80,
in
 open
       raise error, "need 'c' or 'n' flag to open new db"
   anydbm.error: need 'c' or 'n' flag to open new db

More details can be found in the c.l.python thread "anydbm - a simple
question".

I searched for a matching bug and didn't find one in the database.  Also,
I verified my whichdb.py matches what's currently in CVS, so I don't think
this has been fixed yet.

Thanks,

Randall


====================================================================
Audit trail:
Wed Feb 23 21:40:05 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 02:24
By: moshez

Comment:
It was a simple glitch in whichdb -- it didn't recognize the
dumbdbm format. Fixed it.

-------------------------------------------------------

Date: 2000-Sep-15 16:22
By: none

Comment:
I think this bug has appeared again. I get the exact same error with Python 1.6, but it works with 1.5.2.


-------------------------------------------------------

Date: 2000-Sep-15 17:15
By: gvanrossum

Comment:
Reopened and assigned to Jeremy since a comment claims it's reappeared in 1.6.  Can you check 2.0?
-------------------------------------------------------

Date: 2000-Sep-17 04:24
By: loewis

Comment:
The following script works for me, in 2.0b1

>>> import dumbdbm
>>> dumbdbm.open("/tmp/hhh","c")
<dumbdbm._Database instance at 0x829eaac>
>>> s=_
>>> s['a']='b'
>>> s.close()
>>> import whichdb
>>> whichdb.whichdb("/tmp/hhh")
'dumbdbm'
>>> import anydbm
>>> s=anydbm.open("/tmp/hhh")
>>> s

So it works for me, on i586-pc-linux-gnu.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110612&group_id=5470

From noreply@sourceforge.net  Sun Sep 17 12:48:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Sep 2000 04:48:00 -0700
Subject: [Python-bugs-list] [Bug #110662] rfc822 (PR#358)
Message-ID: <200009171148.EAA07088@delerium.i.sourceforge.net>

Bug #110662, was updated on 2000-Jul-31 14:11
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: rfc822 (PR#358)

Details: Jitterbug-Id: 358
Submitted-By: jbearce@copeland.com
Date: Thu, 15 Jun 2000 19:37:00 -0400 (EDT)
Version: 1.5.2
OS: RedHat Linux 6.2


For very long headers returned from a web server rfc822.readheaders does not
correctly build the header.

The following patch fixes it in my situation but I don't know if I broke
anything else:

Example Header:

Location: https://www.website.com:443/tengah/Dpc/vContent.jhtml?page_type=3&PLANID=4&CONTENTPAGEID=0&TengahSession=312442259237-529/2748412123003458168/-1407548368/4/7002/7002/7004/7004

This ends up as

https://www.website.com:443/tengah/Dpc/vContent.jhtml?page_type=3&PLA

and the rest of the header (along with any headers following this one) get
returned as part of the message.

--- /usr/lib/python1.5/rfc822.py.orig   Thu Jun 15 19:35:42 2000
+++ /usr/lib/python1.5/rfc822.py        Thu Jun 15 19:36:00 2000
@@ -125,6 +125,7 @@
         self.status = ''
         headerseen = ""
         firstline = 1
+        lastheader = ''
         startofline = unread = tell = None
         if hasattr(self.fp, 'unread'):
             unread = self.fp.unread
@@ -150,16 +151,22 @@
                 continue
             elif self.iscomment(line):
                 # It's a comment.  Ignore it.
+               lastheader = ''
                 continue
             elif self.islast(line):
                 # Note! No pushback here!  The delimiter line gets eaten.
+               lastheader = ''
                 break
             headerseen = self.isheader(line)
             if headerseen:
                 # It's a legal header line, save it.
                 list.append(line)
                 self.dict[headerseen] = string.strip(line[len(headerseen)+2:])
+               lastheader = headerseen
                 continue
+            elif lastheader:
+               list.append(line)
+               self.dict[lastheader] = self.dict[lastheader] +
string.strip(line)
             else:
                 # It's not a header line; throw it back and stop here.
                 if not self.dict:



====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-17 04:48
By: loewis

Comment:
I can't reproduce the problem. In 2.0b1, 

>>> s="Location: https://www.website.com:443/tengah/Dpc/vContent.jhtml?page_type=3&PLANID=4&CONTENTPAGEID=0&TengahSession=312442259237-529/2748412123003458168/-1407548368/4/7002/7002/7004/7004\r\n\r\n"
>>> t=rfc822.Message(cStringIO.StringIO(s))
>>> t['location']
'https://www.website.com:443/tengah/Dpc/vContent.jhtml?page_type=3&PLANID=4&CONTENTPAGEID=0&TengahSession=312442259237-529/2748412123003458168/-1407548368/4/7002/7002/7004/7004'

works fine for me. If the line break between Location: and the URL in the original report was intentional, rfc822.Message is right in rejecting the header: Continuation lines must start with white space.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110662&group_id=5470

From noreply@sourceforge.net  Sun Sep 17 13:21:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Sep 2000 05:21:12 -0700
Subject: [Python-bugs-list] [Bug #114553] copy.deepcopy() barfs if it hits class/function/method
Message-ID: <200009171221.FAA08156@delerium.i.sourceforge.net>

Bug #114553, was updated on 2000-Sep-15 16:22
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 5
Summary: copy.deepcopy() barfs if it hits class/function/method

Details: The 'copy.deepcopy()' function blows up if it stumbles across class, function, or method objects as it recurses into objects.  This is (at least partly) because of an inconsistency between the dispatch table used for plain-vanilla 'copy()' and for 'deepcopy()': the 'copy()' dispatch table has an entry for ClassType, but the 'deepcopy()' dispatch table does not.

Also, neither dispatch table has entries for FunctionType or MethodType.  This isn't a big deal for 'copy()', since it's unlikely that you'd do 'copy(my_func)', but it's inconsistent since you can do 'copy(my_class)' -- and the class object my_class is *not* copied, it's treated atomically, like strings or ints.  For consistency, functions and methods should probably be treated the same as class objects.

Here's a script that demonstrates the problem:

from copy import copy, deepcopy

def f(): pass
class K: pass

# can copy a list that contains a function, since we don't
# dive into the list
l = [1, 2, f]
try: copy(l)
except: print "error copying list with function"
else: print "ok copying list with function"

# but we can't copy the function
try: copy(f)
except: print "error copying function"
else: print "ok copying function"

# also can't deep copy a list with a function because deepcopy() dives in
try: deepcopy(l)
except: print "error deep-copying list with function"
else: print "ok deep-copying list with function"

# nor can we deepcopy the function alone
try: deepcopy(f)
except: print "error deep-copying function"
else: print "ok deep-copying function"

# can copy list with class object
l = ["foo", K]
try: copy(l)
except: print "error copying list with class object"
else: print "ok copying list with class object"

# but can't deepcopy it
try: deepcopy(l)
except: print "error deep-copying list with class object"
else: print "ok deep-copying list with class object"

(Hmm, I don't see a test script for the 'copy' module -- perhaps this would be a good start.)

This gives the same output for me with Python 1.5.2, 1.6, and 2.0b1 (all on Linux):

ok copying list with function
error copying function
error deep-copying list with function
error deep-copying function
ok copying list with class object
error deep-copying list with class object

And here's a patch that makes everything come out OK:

--- copy.py.orig        Fri Sep 15 19:19:05 2000
+++ copy.py.hacked      Fri Sep 15 19:20:20 2000
@@ -92,6 +92,8 @@
 d[types.TypeType] = _copy_atomic
 d[types.XRangeType] = _copy_atomic
 d[types.ClassType] = _copy_atomic
+d[types.FunctionType] = _copy_atomic
+d[types.MethodType] = _copy_atomic
 
 def _copy_list(x):
        return x[:]
@@ -165,6 +167,9 @@
 d[types.CodeType] = _deepcopy_atomic
 d[types.TypeType] = _deepcopy_atomic
 d[types.XRangeType] = _deepcopy_atomic
+d[types.ClassType] = _deepcopy_atomic
+d[types.FunctionType] = _deepcopy_atomic
+d[types.MethodType] = _deepcopy_atomic
 
 def _deepcopy_list(x, memo):
        y = []


Follow-Ups:

Date: 2000-Sep-17 05:21
By: tim_one

Comment:
Changed to Feature Request and added to PEP 42.

The docs (both the library ref and the comments at the top of copy.py) say that objects of class, method and function type are not handled by the module, so the docs match the code, and anything beyond that is a new-feature request.  Well, almost -- it's a bug that shallow copies *do* "work" for class type now (since the docs say it doesn't), but I'm not going to take that away now.

If/when copy/deepcopy are so extended, more is needed than the suggested patch:  after

y = deepcopy(x)

it should be the case that no mutations of x are visible via y, so _deepcopy_atomic is inadequate for anything with a writable attribute.  For example, after deepcopy'ing a class object, changing the __bases__ attr of the original should have no effect on the deepcopied clone.

So correct deepcopy implementations for these things probably need to use the "new" module.  I suspect the copy module punted on these types to begin with in part because "new" wasn't built by default in the past.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114553&group_id=5470

From noreply@sourceforge.net  Sun Sep 17 13:41:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Sep 2000 05:41:47 -0700
Subject: [Python-bugs-list] [Bug #112786] Build under Cygwin fails
Message-ID: <200009171241.FAA24304@bush.i.sourceforge.net>

Bug #112786, was updated on 2000-Aug-26 01:39
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Build under Cygwin fails

Details: Py1.6b1
========
1) socketmodule.c -- looks for netinet/tcp.h, which does not exist on cygwin.

2) gcc   python.o \
          ../libpython1.6.a    -lm  -o python
python.o: In function `main':
/usr/local/bin/Python-1.6b1/Modules/python.c:12: undefined reference to `Py_Main


Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-13 04:13
By: gvanrossum

Comment:
I don't have cygwin. Does anyone here have cygwin? I know Tim said the cygwin installer failed for him, so he doesn't have it. Is there someone outside the PythonLabs to whom we could assign this?
-------------------------------------------------------

Date: 2000-Sep-16 01:56
By: tim_one

Comment:
A fellow named Norman mailto:nhv@yahoo.com posted to c.l.py with some evidence of real Cygwin knowledge, so I emailed him a link to this bug and asked whether he'd help out.
-------------------------------------------------------

Date: 2000-Sep-16 20:29
By: nhv

Comment:
Hi I am that fellow Norman

FYI I have been doing bi-weekly builds of the Python CVS source with the 'current' Cygwin distribution for about a year.

I sent Tim my small set of diffs

Basically threading with Cygwin Python is still broken
and dll building with Cygwin has some problems but other then that everything including tkinter works for me with very minor changes.

FWIW We are succesfully embedding Python in PrettyPoly
http://prettypoly.sourceforge.net and I am using Cygwin
as my development enviroment for this

If helpful I can mail someone my diffs and the results of make test after each of my CVS sessions or apon request

Also FWIW I build Cygwin from source and have access to the Cygwin development team

I will help in anyway I can to make Python compile with Cygwin 'out of the box'  


Norman Vine nhv@yahoo.com

-------------------------------------------------------

Date: 2000-Sep-17 05:41
By: tim_one

Comment:
Here's the body of email from Norman:

I will certainly help in anyway that I can :-)

Below is a diff of my PY_SRC and the Python CVS at SourceForge

specifically

1) socketmodule.c -- looks for netinet/tcp.h, which does not exist on cygwin.

Cygwin does not have netinet / tcp.h
There has been some discussion about including a dummy tcp.h
into the distribution but I am noy sure that this is a standard header ?
see
http://sources.redhat.com/ml/cygwin/2000-09/msg00011.html

2) gcc python.o \
../libpython1.6.a -lm -o python
python.o: In function `main':
/usr/local/bin/Python-1.6b1/Modules/python.c:12: undefined reference to
`Py_Main

Before rerunning make after a failed build it is occasionally necessary to from top_level python_src directory it is necessary to do
% rm *.a *.o *.exe
I believe that this will solve this problem

I am working with the 2.0 srource tree though and I notice that this is reported against the 1.6 tree


IMHO the two main 'issues'  with Python and Cygwin remaining
are threads and dll support.

I am working on the dll stuff and am aware of Distutils

The thread stuff is beyond me and I could use some help.

I will gladly be a Cygwin 'tester' for Python.

and can forward Cygwin specific Python questions that
I can not answer directly to the appropriate Cygwin list(s)

Cheers

Norman


Index: _tkinter.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/_tkinter.c,v
retrieving revision 1.111
diff -r1.111 _tkinter.c
0a1
>
60,62c61,63
< #if !defined(MS_WINDOWS)
< #define HAVE_CREATEFILEHANDLER
< #endif
---
> //#if !(defined(MS_WINDOWS) || defined(__CYGWIN__))
> //#define HAVE_CREATEFILEHANDLER
> //#endif
64a66
> #undef HAVE_CREATEFILEHANDLER
71c73
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
Index: main.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v
retrieving revision 1.44
diff -r1.44 main.c
11c11
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
187c187
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
209c209
< #ifdef MS_WINDOWS
---
> #if defined(MS_WINDOWS) || defined(__CYGWIN__)
Index: socketmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v
retrieving revision 1.127
diff -r1.127 socketmodule.c
125c125
< #ifndef __BEOS__
---
> #if !defined(__BEOS__) && !defined(__CYGWIN__)

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112786&group_id=5470

From noreply@sourceforge.net  Sun Sep 17 15:40:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Sep 2000 07:40:43 -0700
Subject: [Python-bugs-list] [Bug #110688] Reuben Sumner: Py_REF_DEBUG (PR#43)
Message-ID: <200009171440.HAA28350@bush.i.sourceforge.net>

Bug #110688, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 3
Summary: Reuben Sumner: Py_REF_DEBUG (PR#43)

Details: Jitterbug-Id: 43
Submitted-By: Guido van Rossum <guido@CNRI.Reston.VA.US>
Date: Fri, 30 Jul 1999 13:52:16 -0400
Version: None
OS: None

------- Forwarded Message

Date:    Tue, 20 Jul 1999 10:53:34 +0300
From:    Reuben Sumner <rasumner@iname.com>
To:      guido@python.org
Subject: Py_REF_COUNT

I posted a message through DejaNews which didn't seem to propogate (at
least it didn't reach here).

Try the following in a Python with Py_REF_DEBUG but without Py_TRACE_REFS

class C:
	def __init__(self): pass

while 1:
	c=C()

Stop it after a while and look at the reference count printed!  Python
is not actually using all that memory though.  With Py_TRACE_REFS things
are ok.  I can't figure it out.  The class instance dealloc routine is rather
hairy.

With Py_TRACE_REFS some code of mine is doing some really bizarre things
but I would rather deal with one thing at a time.

Python version is 1.5.2 (tried on at least two platforms, both using gcc)

Many thanks,

Reuben

------- End of Forwarded Message



====================================================================
Audit trail:
Wed Aug 04 12:12:39 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-28 11:52
By: jhylton

Comment:
This report is a bit too vague to be useful.  I've queried the original poster to see if he is still having problems.

-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-17 07:40
By: tim_one

Comment:
Fixed and closed.  Checkin comment:

Fix for SF bug 110688:  Instance deallocation neglected to account for that Py_INCREF boosts global _Py_RefTotal when Py_REF_DEBUG is defined by Py_TRACE_REFS isn't.

There are, IMO, way too many preprocessor gimmicks in use for refcount debugging (at least 3 distinct true/false symbols, but not all 8 combos are supported by the code, etc etc), and no coherent documentation of this stuff -- 'twas too painful to track this one down.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110688&group_id=5470

From noreply@sourceforge.net  Sun Sep 17 16:04:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Sep 2000 08:04:54 -0700
Subject: [Python-bugs-list] [Bug #114630] Add fpectl functionality patch for FreeBSD
Message-ID: <200009171504.IAA13645@delerium.i.sourceforge.net>

Bug #114630, was updated on 2000-Sep-17 08:04
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Add fpectl functionality patch for FreeBSD

Details: I'd have expected an "attach file" function on the bug page.  Not seeing one, I pasted the patch into the bug window.

--- Python-1.5.2/Modules/ORIG/fpectlmodule.c    Thu Dec 10 11:49:27 1998
+++ Python-1.5.2/Modules/fpectlmodule.c Sun Sep 17 10:44:17 2000
@@ -68,6 +68,10 @@
 #include "Python.h"
 #include <signal.h>
 
+#if defined(__FreeBSD__)
+#  include <ieeefp.h>
+#endif
+
 #ifndef WANT_SIGFPE_HANDLER
 /* Define locally if they are not defined in Python.  This gives only
  * the limited control to induce a core dump in case of an exception.
@@ -178,6 +182,12 @@
 #endif
     signal(SIGFPE, handler);
 
+/*-- FreeBSD ----------------------------------------------------------------*/
+#elif defined(__FreeBSD__)
+    fpresetsticky( fpgetsticky() );
+    fpsetmask( FP_X_INV | FP_X_DZ | FP_X_OFL );
+    signal( SIGFPE, handler );
+
 /*-- Linux ----------------------------------------------------------------*/
 #elif defined(linux)
 #ifdef __GLIBC__
@@ -212,7 +222,12 @@
 
 static PyObject *turnoff_sigfpe(PyObject *self,PyObject *args)
 {
+#ifdef __FreeBSD__
+    fpresetsticky( fpgetsticky() );
+    fpsetmask( 0 );
+#else
     fputs("Operation not implemented\n", stderr);
+#endif
     Py_INCREF (Py_None);
     return Py_None;
 }


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114630&group_id=5470

From noreply@sourceforge.net  Sun Sep 17 19:36:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Sep 2000 11:36:25 -0700
Subject: [Python-bugs-list] [Bug #110706] gcc error msg, 1.5.2, Slackware + threads (PR#44)
Message-ID: <200009171836.LAA04438@bush.i.sourceforge.net>

Bug #110706, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: Remind
Bug Group: Platform-specific
Priority: 4
Summary: gcc error msg, 1.5.2, Slackware + threads (PR#44)

Details: Jitterbug-Id: 44
Submitted-By: rene@kronos.szabinet.hu
Date: Sun, 1 Aug 1999 16:39:42 -0400 (EDT)
Version: 1.5.2
OS: Linux


Compile error with Python-1.5.2 on
Linux Slackware 4.0, kernel 2.2.10-ac8, gcc 2.7.2.3, make 3.76.1

./configure --prefix=/usr/local --with-threads && make
...
./socketmodule.c: In function `setipaddr':
./socketmodule.c:392: warning: passing arg 5 of `gethostbyname_r' from
incompatible pointer type
./socketmodule.c:392: too many arguments to function `gethostbyname_r'
./socketmodule.c:392: warning: assignment makes integer from pointer without a
cast
./socketmodule.c: In function `PySocket_gethostbyname_ex':
./socketmodule.c:1471: warning: passing arg 5 of `gethostbyname_r' from
incompatible pointer type
./socketmodule.c:1471: too many arguments to function `gethostbyname_r'
./socketmodule.c:1471: warning: assignment makes integer from pointer without a
cast
./socketmodule.c: In function `PySocket_gethostbyaddr':
./socketmodule.c:1534: warning: passing arg 7 of `gethostbyaddr_r' from
incompatible pointer type
./socketmodule.c:1534: too many arguments to function `gethostbyaddr_r'
./socketmodule.c:1534: warning: assignment makes integer from pointer without a
cast
make[1]: *** [socketmodule.o] Error 1
make: *** [Modules] Error 2



====================================================================
Audit trail:
Wed Aug 04 12:12:39 1999	guido	moved from incoming to platformbug
Mon Aug 30 12:37:34 1999	guido	changed notes
Mon Oct 25 15:15:46 1999	guido	changed notes

Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 22:50
By: tim_one

Comment:
Assigned to Fred for the heck of it.  Changed the "Summary" msg as the original "Compiler error" gave me an entirely wrong impression.
-------------------------------------------------------

Date: 2000-Sep-15 10:11
By: fdrake

Comment:
Sent a message to the submitter asking if this is still a problem with more recent Python releases; this sounds very much like a bug that's been squashed, but I don't have a Slackware Linux installation available for testing.
-------------------------------------------------------

Date: 2000-Sep-15 11:05
By: fdrake

Comment:
I cannot reproduce this with Slackware 7.0 (kernel 2.2.14 SMP; the version installed on the SourceForge compile farm).
-------------------------------------------------------

Date: 2000-Sep-17 11:36
By: fdrake

Comment:
Lowering priority since I can't reproduce this on the current version of Slackware (as installed on the SF compile farm).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110706&group_id=5470

From noreply@sourceforge.net  Mon Sep 18 01:38:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Sep 2000 17:38:55 -0700
Subject: [Python-bugs-list] [Bug #114660] sre hangs with "collapse whitespace" RE
Message-ID: <200009180038.RAA01653@delerium.i.sourceforge.net>

Bug #114660, was updated on 2000-Sep-17 17:38
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sre hangs with "collapse whitespace" RE

Details: In Python 1.5.2, 1.6, and 2.0b1 using "pre", the following regex substitution works fine:

>>> s = "hello      there     how are you?"
>>> re.sub (r'(\S)\s+(\S)', r'\1 \2', s)
'hello there how are you?'

But in 2.0b1 using the standard "re" module, Python goes into an apparently infinite loop.  (CPU is pegged, memory doesn't increase at all.)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114660&group_id=5470

From noreply@sourceforge.net  Mon Sep 18 01:47:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Sep 2000 17:47:50 -0700
Subject: [Python-bugs-list] [Bug #114660] sre hangs with "collapse whitespace" RE
Message-ID: <200009180047.RAA01967@delerium.i.sourceforge.net>

Bug #114660, was updated on 2000-Sep-17 17:38
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sre hangs with "collapse whitespace" RE

Details: In Python 1.5.2, 1.6, and 2.0b1 using "pre", the following regex substitution works fine:

>>> s = "hello      there     how are you?"
>>> re.sub (r'(\S)\s+(\S)', r'\1 \2', s)
'hello there how are you?'

But in 2.0b1 using the standard "re" module, Python goes into an apparently infinite loop.  (CPU is pegged, memory doesn't increase at all.)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114660&group_id=5470

From noreply@sourceforge.net  Mon Sep 18 02:18:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Sep 2000 18:18:51 -0700
Subject: [Python-bugs-list] [Bug #114660] sre hangs with "collapse whitespace" RE
Message-ID: <200009180118.SAA02997@delerium.i.sourceforge.net>

Bug #114660, was updated on 2000-Sep-17 17:38
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sre hangs with "collapse whitespace" RE

Details: In Python 1.5.2, 1.6, and 2.0b1 using "pre", the following regex substitution works fine:

>>> s = "hello      there     how are you?"
>>> re.sub (r'(\S)\s+(\S)', r'\1 \2', s)
'hello there how are you?'

But in 2.0b1 using the standard "re" module, Python goes into an apparently infinite loop.  (CPU is pegged, memory doesn't increase at all.)

Follow-Ups:

Date: 2000-Sep-17 18:18
By: tim_one

Comment:
It's in an infinite loop trying to parse the \1 in the replacement pattern (parse_sre.py, function parse_template).  It recognizes that "1" is a valid group name, but apparently doesn't recognize that "1 " (i.e., the digit one followed by a blank) is not a valid group name), in turn perhaps because int("1 ") returns 1.

I can fix it by adding the clause

s.next not in DIGITS or

after the existing

if (not s.next or

on line 637 and then this gets the result you expect, but I'll defer to /F on whether that's the right way to fix this.

I hope you (Greg) aren't actually using this regexp to normalize whitespace!  split followed by join is the usual way to do that, and this regexp-based way looks wrong (e.g., if somewhere in the middle there's a single letter followed by mounds of whitespace on each side:  the space following the letter won't get collapsed).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114660&group_id=5470

From noreply@sourceforge.net  Mon Sep 18 03:04:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Sep 2000 19:04:47 -0700
Subject: [Python-bugs-list] [Bug #114660] sre hangs with "collapse whitespace" RE
Message-ID: <200009180204.TAA20242@bush.i.sourceforge.net>

Bug #114660, was updated on 2000-Sep-17 17:38
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sre hangs with "collapse whitespace" RE

Details: In Python 1.5.2, 1.6, and 2.0b1 using "pre", the following regex substitution works fine:

>>> s = "hello      there     how are you?"
>>> re.sub (r'(\S)\s+(\S)', r'\1 \2', s)
'hello there how are you?'

But in 2.0b1 using the standard "re" module, Python goes into an apparently infinite loop.  (CPU is pegged, memory doesn't increase at all.)

Follow-Ups:

Date: 2000-Sep-17 18:18
By: tim_one

Comment:
It's in an infinite loop trying to parse the \1 in the replacement pattern (parse_sre.py, function parse_template).  It recognizes that "1" is a valid group name, but apparently doesn't recognize that "1 " (i.e., the digit one followed by a blank) is not a valid group name), in turn perhaps because int("1 ") returns 1.

I can fix it by adding the clause

s.next not in DIGITS or

after the existing

if (not s.next or

on line 637 and then this gets the result you expect, but I'll defer to /F on whether that's the right way to fix this.

I hope you (Greg) aren't actually using this regexp to normalize whitespace!  split followed by join is the usual way to do that, and this regexp-based way looks wrong (e.g., if somewhere in the middle there's a single letter followed by mounds of whitespace on each side:  the space following the letter won't get collapsed).
-------------------------------------------------------

Date: 2000-Sep-17 19:04
By: gward

Comment:
Not related to the bug, but since Tim brought it up: I once used that regex to normalize whitespace; I must have written that line of code when I was still a recovering Perl programmer.  Unfortunately, that particular line of code lived on in distutils/text_file.py until this past weekend, so someone stumbled across it using Distutils 0.9.2 under Python 2.0b1.  The regex is gone in the current Distutils CVS, so this won't be an issue once 0.9.3 is out.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114660&group_id=5470

From noreply@sourceforge.net  Mon Sep 18 04:54:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Sep 2000 20:54:43 -0700
Subject: [Python-bugs-list] [Bug #112289] NetBSD1.4.2 build issue
Message-ID: <200009180354.UAA23987@bush.i.sourceforge.net>

Bug #112289, was updated on 2000-Aug-18 19:50
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: NetBSD1.4.2 build issue

Details: the recent fileobjects.c work done for large files (tmick) appears
broken when compiled against NetBSD1.4.2.

During the final link, you get the following output:

gcc   python.o  ../libpython2.0.a   -lutil -lm  -o python
fileobject.c:280: Undefined symbol `_TELL64' referenced from text segment

Follow-Ups:

Date: 2000-Aug-18 19:55
By: none

Comment:
NOTE:  I didn't include the configure output.  If that
would be helpful, go ahead and indicate that in this
tracking system.

If tmick (or whoever) would like me to contact them directly,
I would happily do so.
-------------------------------------------------------

Date: 2000-Aug-31 08:45
By: tmick

Comment:
Sent to python-dev:

1. Who reported this bug? He talked about providing more information and I
would like to speak with him. I cannot find his email address.
2. Does anybody have a NetBSD1.4.2 (or close) machine that I can get shell
access to? Do you know if they have such a machine at SourceForge that users
can get shell access to? Or failing that can someone with such a machine give
me the full ./configure and make output and maybe run this command:
   find /usr/include -name "*" -type f | xargs -l grep -nH _TELL64
and give me the output.


-------------------------------------------------------

Date: 2000-Aug-31 08:47
By: tmick

Comment:
I got no reponse and I have no NetBSD machine on which to reproduce so, as Jeremy suggested, if I wouldn't get it by this evening then assign back to him.

Other questions:
- How old/recent is version 1.4.2 of NetBSD?
- Where is _TELL64 coming from? Not from Python code.

-------------------------------------------------------

Date: 2000-Sep-06 08:43
By: tmick

Comment:
Thanks to Brad (knotwell@NOSPAM f5 NOSPAM.com) who reported the bug I got shell access on his NetBSD 1.4.2 box to play a little bit. I found the problem but I don&#039;t have the Right (tm) fix. Here is what I found:

The _TELL64 compilation failure is for the #define TELL64 usage in fileobject.c for a 64-bit capable tell() system function. Currently this is only defined and used for Win64. The funny thing is that to get to the code section using TELL64 the NetBSD box had to (1) pass the configure test for HAVE_LARGEFILE_SUPPORT, (2) have sizeof(fpos_t) >= 8, and (3) *not* have fseeko (as required by the Single Unix Specification) or fseek64 defined.

As far as I can tell NetBSD *should* define fseeko() and ftello() if it wants to say that it supports largefiles. I *think* that you can manage it via fsetpos() and fgetpos(), which is what I did for largefile support on Win64 (although on Win64 I still relied on a 64-bit capable tell() function -- hence TELL64).  I don&#039;t have the time right now to get and verify a working fsetpos/fgetpos solution.

A quick fix is to ifdef out HAVE_LARGEFILE_SUPPORT for NetBSD 1.4.2 but I don&#039;t know the proper #define&#039;s for that. It is also ugly.

-------------------------------------------------------

Date: 2000-Sep-15 12:15
By: jhylton

Comment:
Trent -- will you have time to work on this between now and 2.0b2?

-------------------------------------------------------

Date: 2000-Sep-17 20:54
By: tsarna

Comment:
See patch #101558. Probably will need to add other BSDs to the #elif. Many 44BSDs provided 64bit off_t long before they provided f*o() or f*64().


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470

From noreply@sourceforge.net  Mon Sep 18 16:01:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 08:01:08 -0700
Subject: [Python-bugs-list] [Bug #114027] Compiling on alpha-osf1v4: libpthreads is called libpthread
Message-ID: <200009181501.IAA15583@bush.i.sourceforge.net>

Bug #114027, was updated on 2000-Sep-10 22:43
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: Compiling on alpha-osf1v4: libpthreads is called libpthread

Details: change -lpthreads into -lpthread

Follow-Ups:

Date: 2000-Sep-16 09:59
By: gvanrossum

Comment:
I don't have enough information to resolve this problem.
What Python version were you using?

Did you use the configure script? It should automtically select -lpthreads or -lpthread depending on which one is present. Did this fail for you? Please check the config.log file to find out more about this.

Since I don't have an Alpha OSF1v1 system, I can't debug this for you!
-------------------------------------------------------

Date: 2000-Sep-18 08:01
By: janw

Comment:
Python-2.0b1, with configure. And it looks like configure doesn't get this right.

I asked a colleague to look a bit more into this. He found the following:
1) You can use either pthreads? or decthreads. If you call configure with decthreads it compiles and runs fine, but the manpage says that decthreads are only there for backwards compatibility.
2) In the pthreads? case there are different possibilities:
- You can include the phtread.h file or not.
- You can call pthread_create with arguments or not.
- You can link with -lpthread or with -lpthreads
The manpage for pthread(2) suggests to use the compiler option -pthread, which boils down to cc -D_REENTRANT and ld -lpthread -lexc (modulo other options).
It looks like configure tries with a testfile without including pthread.h, thusly -lpthreads gets used. The sources *do* include pthread.h, but then you have to link against -lpthread.
Suggested fix: Change configure test file so that pthread.h gets included and call pthread_create(0,0,0,0) (eg. give four dummy arguments).
This works for OSF1, but we did not test if it breaks anything on other platforms.

Hope you can understand the description.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114027&group_id=5470

From noreply@sourceforge.net  Mon Sep 18 17:25:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 09:25:35 -0700
Subject: [Python-bugs-list] [Bug #113829] hasattr() doesn't accept Unicode strings
Message-ID: <200009181625.JAA02825@delerium.i.sourceforge.net>

Bug #113829, was updated on 2000-Sep-07 14:28
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: hasattr() doesn't accept Unicode strings  

Details: hasattr(), getattr(), and doubtless other built-in functions don't accept Unicode strings at all:
>>> import sys
>>> hasattr(sys, u'abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: hasattr, argument 2: expected string, unicode found

Questions raised by GvR:
There are probably a bunch of things that need to be changed before
this works though; getattr() c.s. require a string, then call
PyObject_GetAttr() which also checks for a string unless the object
supports tp_getattro -- but that's only true for classes and
instances.
 
Also, should we convert the string to 8-bit, or should we allow
Unicode attribute names?
 
It seems there's no easy fix -- better address this after 2.0 is
released.                                                                       

Follow-Ups:

Date: 2000-Sep-08 08:26
By: lemburg

Comment:
Just for the record and to take the discussion to SF,
here's my reply on the topic in the python-dev thread 
"hasattr() and Unicode strings".

> Also, should we convert the string to 8-bit, or should we allow
> Unicode attribute names?

Attribute names will have to be 8-bit strings (at least in 2.0).

The reason here is that attributes are normally Python identifiers
which are plain ASCII and stored as 8-bit strings in the namespace
dictionaries, i.e. there's no way to add Unicode attribute names
other than by assigning directly to __dict__.

Note that keyword lookups already automatically convert Unicode
lookup strings to 8-bit using the default encoding. The same should
happen here, IMHO.
 
> It seems there's no easy fix -- better address this after 2.0 is
> released.

Why wait for 2.1 ?

What remains is to decide where to apply the change: in hasattr()
et al. or in PyObject_GetAttr() directly. I'd opt for the latter due to
its wider range of application.

-------------------------------------------------------

Date: 2000-Sep-18 09:25
By: lemburg

Comment:
All three APIs get/set/hasattr() 
(and the underlying C APIs PyObject_Get/SetAttr())
now accept Unicode attribute names.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113829&group_id=5470

From noreply@sourceforge.net  Mon Sep 18 17:36:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 09:36:01 -0700
Subject: [Python-bugs-list] [Bug #113829] hasattr() doesn't accept Unicode strings
Message-ID: <200009181636.JAA03251@delerium.i.sourceforge.net>

Bug #113829, was updated on 2000-Sep-07 14:28
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: hasattr() doesn't accept Unicode strings  

Details: hasattr(), getattr(), and doubtless other built-in functions don't accept Unicode strings at all:
>>> import sys
>>> hasattr(sys, u'abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: hasattr, argument 2: expected string, unicode found

Questions raised by GvR:
There are probably a bunch of things that need to be changed before
this works though; getattr() c.s. require a string, then call
PyObject_GetAttr() which also checks for a string unless the object
supports tp_getattro -- but that's only true for classes and
instances.
 
Also, should we convert the string to 8-bit, or should we allow
Unicode attribute names?
 
It seems there's no easy fix -- better address this after 2.0 is
released.                                                                       

Follow-Ups:

Date: 2000-Sep-08 08:26
By: lemburg

Comment:
Just for the record and to take the discussion to SF,
here's my reply on the topic in the python-dev thread 
"hasattr() and Unicode strings".

> Also, should we convert the string to 8-bit, or should we allow
> Unicode attribute names?

Attribute names will have to be 8-bit strings (at least in 2.0).

The reason here is that attributes are normally Python identifiers
which are plain ASCII and stored as 8-bit strings in the namespace
dictionaries, i.e. there's no way to add Unicode attribute names
other than by assigning directly to __dict__.

Note that keyword lookups already automatically convert Unicode
lookup strings to 8-bit using the default encoding. The same should
happen here, IMHO.
 
> It seems there's no easy fix -- better address this after 2.0 is
> released.

Why wait for 2.1 ?

What remains is to decide where to apply the change: in hasattr()
et al. or in PyObject_GetAttr() directly. I'd opt for the latter due to
its wider range of application.

-------------------------------------------------------

Date: 2000-Sep-18 09:25
By: lemburg

Comment:
All three APIs get/set/hasattr() 
(and the underlying C APIs PyObject_Get/SetAttr())
now accept Unicode attribute names.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113829&group_id=5470

From noreply@sourceforge.net  Mon Sep 18 22:42:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 14:42:00 -0700
Subject: [Python-bugs-list] [Bug #114746] dis module is not up todate in 2.0b1-#4
Message-ID: <200009182142.OAA31852@bush.i.sourceforge.net>

Bug #114746, was updated on 2000-Sep-18 14:42
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: dis module is not up todate in 2.0b1-#4

Details: While updating freeze I got an index error for an op
that was outside of the dis.opname list.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114746&group_id=5470

From noreply@sourceforge.net  Mon Sep 18 22:49:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 14:49:19 -0700
Subject: [Python-bugs-list] [Bug #114747] Freeze does not work
Message-ID: <200009182149.OAA16264@delerium.i.sourceforge.net>

Bug #114747, was updated on 2000-Sep-18 14:49
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Freeze does not work

Details: Freeze tool needs changes as follows to make it work with 2.0b1.

In modulefinder.py

24,25d23
< STORE_NAME = dis.opname.index('STORE_NAME')
< STORE_FAST = dis.opname.index('STORE_FAST')
268d265
< 	self.msgin(5,'scan_code: start')
280,283d276
< 	    if op < len(dis.opname):
< 		    self.msg(5, 'scan_code: op=%d(%s)' %(op,dis.opname[op]) )
< 	    else:
< 		    self.msg(5, 'scan_code: op=%d(%s)' %(op,'Unknown') )
294,303d286
< 	    elif op == STORE_NAME:
< 		if oparg < len(co.co_names):
< 			self.msg( 5, 'scan_code: STORE_NAME name=%s' % co.co_names[oparg] )
< 		else:
< 			self.msg( 5, 'scan_code: STORE_NAME op=%d' % oparg )
< 	    elif op == STORE_FAST:
< 		if oparg < len(co.co_names):
< 			self.msg( 5, 'scan_code: STORE_FAST name=%s' % co.co_names[oparg] )
< 		else:
< 			self.msg( 5, 'scan_code: STORE_FAST op=%d' % oparg )
321,322d303
< 
< 	self.msgout( 5, 'scan_code: end' )



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114747&group_id=5470

From noreply@sourceforge.net  Mon Sep 18 23:01:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 15:01:27 -0700
Subject: [Python-bugs-list] [Bug #114747] Freeze does not work
Message-ID: <200009182201.PAA32531@bush.i.sourceforge.net>

Bug #114747, was updated on 2000-Sep-18 14:49
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Duplicate
Bug Group: None
Priority: 5
Summary: Freeze does not work

Details: Freeze tool needs changes as follows to make it work with 2.0b1.

In modulefinder.py

24,25d23
< STORE_NAME = dis.opname.index('STORE_NAME')
< STORE_FAST = dis.opname.index('STORE_FAST')
268d265
< 	self.msgin(5,'scan_code: start')
280,283d276
< 	    if op < len(dis.opname):
< 		    self.msg(5, 'scan_code: op=%d(%s)' %(op,dis.opname[op]) )
< 	    else:
< 		    self.msg(5, 'scan_code: op=%d(%s)' %(op,'Unknown') )
294,303d286
< 	    elif op == STORE_NAME:
< 		if oparg < len(co.co_names):
< 			self.msg( 5, 'scan_code: STORE_NAME name=%s' % co.co_names[oparg] )
< 		else:
< 			self.msg( 5, 'scan_code: STORE_NAME op=%d' % oparg )
< 	    elif op == STORE_FAST:
< 		if oparg < len(co.co_names):
< 			self.msg( 5, 'scan_code: STORE_FAST name=%s' % co.co_names[oparg] )
< 		else:
< 			self.msg( 5, 'scan_code: STORE_FAST op=%d' % oparg )
321,322d303
< 
< 	self.msgout( 5, 'scan_code: end' )



Follow-Ups:

Date: 2000-Sep-18 15:01
By: gvanrossum

Comment:
Duplicate of bug #113693.
This has been fixed in the CVS tree already.

BTW, please use the patch manager for patches, and please use context diffs!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114747&group_id=5470

From noreply@sourceforge.net  Mon Sep 18 23:04:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 15:04:45 -0700
Subject: [Python-bugs-list] [Bug #114746] dis module is not up todate in 2.0b1-#4
Message-ID: <200009182204.PAA32672@bush.i.sourceforge.net>

Bug #114746, was updated on 2000-Sep-18 14:42
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: Works For Me
Bug Group: None
Priority: 5
Summary: dis module is not up todate in 2.0b1-#4

Details: While updating freeze I got an index error for an op
that was outside of the dis.opname list.


Follow-Ups:

Date: 2000-Sep-18 15:04
By: gvanrossum

Comment:
Please supply an example -- I don't have a problem using dis.py.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114746&group_id=5470

From noreply@sourceforge.net  Mon Sep 18 23:05:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 15:05:54 -0700
Subject: [Python-bugs-list] [Bug #114749] HTML docs problems
Message-ID: <200009182205.PAA16878@delerium.i.sourceforge.net>

Bug #114749, was updated on 2000-Sep-18 15:05
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: HTML docs problems

Details: The module index is empty.
In the library the contents is empty.

The tag <tex2html_anchor_invisible_mark> appears in lots of the .html files.

The encode() method is not documented for strings.

No docs on unicode strings in lib ref like the strings module.

Please mark links that leave the local machine. For example the link to "Python How-To Guides".


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114749&group_id=5470

From noreply@sourceforge.net  Mon Sep 18 23:09:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 15:09:05 -0700
Subject: [Python-bugs-list] [Bug #114749] HTML docs problems
Message-ID: <200009182209.PAA00401@bush.i.sourceforge.net>

Bug #114749, was updated on 2000-Sep-18 15:05
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: HTML docs problems

Details: The module index is empty.
In the library the contents is empty.

The tag <tex2html_anchor_invisible_mark> appears in lots of the .html files.

The encode() method is not documented for strings.

No docs on unicode strings in lib ref like the strings module.

Please mark links that leave the local machine. For example the link to "Python How-To Guides".


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114749&group_id=5470

From noreply@sourceforge.net  Mon Sep 18 23:37:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 15:37:01 -0700
Subject: [Python-bugs-list] [Bug #110704] IDLE (PR#400)
Message-ID: <200009182237.PAA18047@delerium.i.sourceforge.net>

Bug #110704, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Closed
Resolution: Wont Fix
Bug Group: Platform-specific
Priority: 3
Summary: IDLE (PR#400)

Details: Jitterbug-Id: 400
Submitted-By: crislipm@earthlink.net
Date: Sun, 16 Jul 2000 20:40:24 -0400 (EDT)
Version: 1.5.2
OS: Linuxppc, Suse dist


more for curiosity/FYI

Using 1.5.2 (the version that came with the suse linuxppc) and IDLE 0.5 on an
ibook (version 2).

IDLE causes the keyboard to stop working (I am not certain which, if any action,
causes this, but it is reproducable) and the problem continues when I warm boot
back to the MAC OS.  Have to do a cold boot to get keyboard to respond again.




====================================================================
Audit trail:
Mon Jul 24 18:30:07 2000	jeremy	changed notes
Mon Jul 24 18:30:07 2000	jeremy	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 15:04
By: bwarsaw

Comment:
Reassigned to Guido for disposal.  Maybe Jack should take a look?
-------------------------------------------------------

Date: 2000-Sep-18 15:37
By: gvanrossum

Comment:
Alas, Tkinter on a Mac is terribly unstable. There's not much I can do about that. Too bad! I wish it weren't so.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110704&group_id=5470

From noreply@sourceforge.net  Mon Sep 18 23:46:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 15:46:37 -0700
Subject: [Python-bugs-list] [Bug #114754] marshal_loads can return NULL without setting Error
Message-ID: <200009182246.PAA18416@delerium.i.sourceforge.net>

Bug #114754, was updated on 2000-Sep-18 15:46
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: marshal_loads can return NULL without setting Error

Details: I'm getting a NULL result from marshal_loads without it
setting an error. (This is in 1.5.2 and 2.0b1.)  I'm pretty 
sure the input being fed to marshal.loads is bad, but it 
still should still doing the error handling dance correctly, 
yes?  Here's a simple example:

    >>> import marshal
    >>> x = marshal.loads('006@mediaone.net.weekly.529454')
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    SystemError: NULL result without error in call_object

It looks like r_object returns NULL if type == '0' and then 
marshal_loads simply returns it without checking the value 
returned by r_object.  If this is a "feature" and not a
bug, there should at least be a comment in the TYPE_NULL
branch of the switch statement indicating why it's not an
error to return NULL without setting an exception.

(P.S.  Is there any search facility within the SF bug manager or are you stuck having to wade through all bugs to
find out if yours has already been reported?)


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114754&group_id=5470

From guido@beopen.com  Tue Sep 19 00:54:18 2000
From: guido@beopen.com (Guido van Rossum)
Date: Mon, 18 Sep 2000 18:54:18 -0500
Subject: [Python-bugs-list] Re: Bug search
In-Reply-To: Your message of "Mon, 18 Sep 2000 15:46:37 MST."
 <200009182246.PAA18416@delerium.i.sourceforge.net>
References: <200009182246.PAA18416@delerium.i.sourceforge.net>
Message-ID: <200009182354.SAA03224@cj20424-a.reston1.va.home.com>

> (P.S.  Is there any search facility within the SF bug manager or are you stuck having to wade through all bugs to
> find out if yours has already been reported?)

Yes, but SF hides it very well: the left sidebar has a search box,
which changes functionality when you are in a Bugs section. :-(

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

From noreply@sourceforge.net  Mon Sep 18 23:57:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 15:57:59 -0700
Subject: [Python-bugs-list] [Bug #114754] marshal_loads can return NULL without setting Error
Message-ID: <200009182257.PAA18952@delerium.i.sourceforge.net>

Bug #114754, was updated on 2000-Sep-18 15:46
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: marshal_loads can return NULL without setting Error

Details: I'm getting a NULL result from marshal_loads without it
setting an error. (This is in 1.5.2 and 2.0b1.)  I'm pretty 
sure the input being fed to marshal.loads is bad, but it 
still should still doing the error handling dance correctly, 
yes?  Here's a simple example:

    >>> import marshal
    >>> x = marshal.loads('006@mediaone.net.weekly.529454')
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    SystemError: NULL result without error in call_object

It looks like r_object returns NULL if type == '0' and then 
marshal_loads simply returns it without checking the value 
returned by r_object.  If this is a "feature" and not a
bug, there should at least be a comment in the TYPE_NULL
branch of the switch statement indicating why it's not an
error to return NULL without setting an exception.

(P.S.  Is there any search facility within the SF bug manager or are you stuck having to wade through all bugs to
find out if yours has already been reported?)


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114754&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 00:12:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 16:12:05 -0700
Subject: [Python-bugs-list] [Bug #110861] time.sleep() and threading (PR#307)
Message-ID: <200009182312.QAA19409@delerium.i.sourceforge.net>

Bug #110861, was updated on 2000-Aug-01 14:39
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Works For Me
Bug Group: Irreproducible
Priority: 5
Summary: time.sleep() and threading (PR#307)

Details: Jitterbug-Id: 307
Submitted-By: gpk@bell-labs.com
Date: Fri, 28 Apr 2000 11:28:19 -0400 (EDT)
Version: 1.5.2
OS: Solaris 2.6 sparc


python .../test/test_thread.py shows that time.sleep()
does not relinquish the processor.
As one thread goes to sleep, another thread ought
to start processing.   That doesn't happen.

Python was configured with --with-thread
and compiler flags -mt and -D_REENTRANT.
See line from config.status: s%@CC@%cc -mt -D_REENTRANT%g

EXAMPLE:

hce* python test_thread.py
creating task 1
creating task 2
creating task 3
creating task 4
creating task 5
creating task 6
creating task 7
creating task 8
creating task 9
creating task 10
waiting for all tasks to complete
task 1 will run for 9.9 sec		# goes to sleep here...
task 1 done				# 9.9 seconds later...
task 5 will run for 4.1 sec		# This should have started when task 1 slept.
task 5 done
task 7 will run for 9.9 sec
task 7 done
task 4 will run for 9.2 sec
task 4 done
task task 6 will run for 7.7 sec




====================================================================
Audit trail:
Mon May 22 17:23:26 2000	guido	changed notes
Mon May 22 17:23:26 2000	guido	moved from incoming to irreproducible

Follow-Ups:

Date: 2000-Aug-01 14:39
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] time.sleep() and threading (PR#307)
Date: Wed, 03 May 2000 11:58:20 -0400

> python .../test/test_thread.py shows that time.sleep()
> does not relinquish the processor.
> As one thread goes to sleep, another thread ought
> to start processing.   That doesn't happen.
> 
> Python was configured with --with-thread
> and compiler flags -mt and -D_REENTRANT.
> See line from config.status: s%@CC@%cc -mt -D_REENTRANT%g
> 
> EXAMPLE:
> 
> hce* python test_thread.py
> creating task 1
> creating task 2
> creating task 3
> creating task 4
> creating task 5
> creating task 6
> creating task 7
> creating task 8
> creating task 9
> creating task 10
> waiting for all tasks to complete
> task 1 will run for 9.9 sec		# goes to sleep here...
> task 1 done				# 9.9 seconds later...
> task 5 will run for 4.1 sec		# This should have started when task 1 slept.
> task 5 done
> task 7 will run for 9.9 sec
> task 7 done
> task 4 will run for 9.2 sec
> task 4 done
> task task 6 will run for 7.7 sec

Hm...  It works correctly for me on Solaris 7 compiled with gcc, using
either Solaris threads or Posix threads.

I wonder if this could have something to do with the compiler you are
using?  (Are you using the SunPro compiler?)

There's not much I can do about this right now, sorry.

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-01 14:39
By: none

Comment:
And wqent away when he upgraded to Py 1.6.
-------------------------------------------------------

Date: 2000-Aug-25 10:47
By: jhylton

Comment:
Can you test this with Sun's compiler?

-------------------------------------------------------

Date: 2000-Aug-30 10:13
By: gward

Comment:
I built the latest CVS Python 2.0 source on Solaris 2.6 with both GCC and the Sun Workshop compiler (4.2).  The test seems to be correct, ie. I don't get any long delays while task 1 is sleeping before subsequent tasks start up.

Haven't tried any earlier Python release.  Does anyone care, or should we call this one "Fixed in 2.0"?

-------------------------------------------------------

Date: 2000-Sep-18 16:12
By: gward

Comment:
Since I was unable to reproduce this bug with Python 2.0, and no one has commented on it since I made that finding, I'm closing this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110861&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 00:50:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 16:50:28 -0700
Subject: [Python-bugs-list] [Bug #114756] test_linuxaudiodev uses wrong format
Message-ID: <200009182350.QAA04173@bush.i.sourceforge.net>

Bug #114756, was updated on 2000-Sep-18 16:50
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: test_linuxaudiodev uses wrong format

Details: test_linuxaudiodev sounds *horrible*.  This has come up several times on python-dev, but nobody seems to have a fix that works -- or at least nothing has been checked in, so I'm contributing this bug report to the collective memory.

Here's how the bug manifests on my machine (a Dell Dimension with built-in sound hardware [Yamaha YMF-724F], using ALSA 0.5.8a drivers in a 2.2.14 kernel):

$ ./python Lib/test/test_linuxaudiodev.py
plays the entire sample without complaint, but it sounds *horrible* -- apparently because it's treating an .au file incorrectly.

See also my python-dev post of 29 June 2000: http://www.python.org/pipermail/python-dev/2000-June/011808.html

Ping suggested setting AUDIODEV=/dev/audio before running the script, and Michael Hudson contributed an alternate version of the test script which writes to /dev/audio (same idea, no environment variable needed).  Either of these fixes has the same result:

$ ./python Lib/test/test_linuxaudiodev-hudson.py
Traceback (most recent call last):
  File "Lib/test/test_linuxaudiodev-hudson.py", line 62, in ?
    test()
  File "Lib/test/test_linuxaudiodev-hudson.py", line 60, in test
    play_au_file(findfile('audiotest.au'))
  File "Lib/test/test_linuxaudiodev-hudson.py", line 55, in play_au_file
    dsp.write(data)
linuxaudiodev.error: (11, 'Resource temporarily unavailable')

The traceback appears immediately, but the script keeps running while the sample plays -- well, about half of it.  The sample is cut off midway through, and my shell prompt returns.

Finally, Ping posted another variation on the test script (http://www.python.org/pipermail/python-dev/2000-June/011834.html) which does not work at all for me:
$ ./python Lib/test/test_linuxaudiodev-ping.py
Traceback (most recent call last):
  File "Lib/test/test_linuxaudiodev-ping.py", line 37, in ?
    test()
  File "Lib/test/test_linuxaudiodev-ping.py", line 35, in test
    play_au_file(findfile('audiotest.au'))
  File "Lib/test/test_linuxaudiodev-ping.py", line 26, in play_au_file
    raise "audio format not supported by linuxaudiodev"
audio format not supported by linuxaudiodev

No sound at all from this one.

Charles Waldman <cgw@fnal.gov> also took a look at linuxaudiodev.c and didn't like what he found: http://www.python.org/pipermail/python-dev/2000-August/015746.html; Charles has said he's working on a rewrite of this module.



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114756&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 00:52:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 16:52:13 -0700
Subject: [Python-bugs-list] [Bug #114756] test_linuxaudiodev uses wrong format
Message-ID: <200009182352.QAA04296@bush.i.sourceforge.net>

Bug #114756, was updated on 2000-Sep-18 16:50
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: test_linuxaudiodev uses wrong format

Details: test_linuxaudiodev sounds *horrible*.  This has come up several times on python-dev, but nobody seems to have a fix that works -- or at least nothing has been checked in, so I'm contributing this bug report to the collective memory.

Here's how the bug manifests on my machine (a Dell Dimension with built-in sound hardware [Yamaha YMF-724F], using ALSA 0.5.8a drivers in a 2.2.14 kernel):

$ ./python Lib/test/test_linuxaudiodev.py
plays the entire sample without complaint, but it sounds *horrible* -- apparently because it's treating an .au file incorrectly.

See also my python-dev post of 29 June 2000: http://www.python.org/pipermail/python-dev/2000-June/011808.html

Ping suggested setting AUDIODEV=/dev/audio before running the script, and Michael Hudson contributed an alternate version of the test script which writes to /dev/audio (same idea, no environment variable needed).  Either of these fixes has the same result:

$ ./python Lib/test/test_linuxaudiodev-hudson.py
Traceback (most recent call last):
  File "Lib/test/test_linuxaudiodev-hudson.py", line 62, in ?
    test()
  File "Lib/test/test_linuxaudiodev-hudson.py", line 60, in test
    play_au_file(findfile('audiotest.au'))
  File "Lib/test/test_linuxaudiodev-hudson.py", line 55, in play_au_file
    dsp.write(data)
linuxaudiodev.error: (11, 'Resource temporarily unavailable')

The traceback appears immediately, but the script keeps running while the sample plays -- well, about half of it.  The sample is cut off midway through, and my shell prompt returns.

Finally, Ping posted another variation on the test script (http://www.python.org/pipermail/python-dev/2000-June/011834.html) which does not work at all for me:
$ ./python Lib/test/test_linuxaudiodev-ping.py
Traceback (most recent call last):
  File "Lib/test/test_linuxaudiodev-ping.py", line 37, in ?
    test()
  File "Lib/test/test_linuxaudiodev-ping.py", line 35, in test
    play_au_file(findfile('audiotest.au'))
  File "Lib/test/test_linuxaudiodev-ping.py", line 26, in play_au_file
    raise "audio format not supported by linuxaudiodev"
audio format not supported by linuxaudiodev

No sound at all from this one.

Charles Waldman <cgw@fnal.gov> also took a look at linuxaudiodev.c and didn't like what he found: http://www.python.org/pipermail/python-dev/2000-August/015746.html; Charles has said he's working on a rewrite of this module.



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114756&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 00:53:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 16:53:37 -0700
Subject: [Python-bugs-list] [Bug #110687] mailbox module's maildir class broken? (PR#414)
Message-ID: <200009182353.QAA04326@bush.i.sourceforge.net>

Bug #110687, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: mailbox module's maildir class broken? (PR#414)

Details: Jitterbug-Id: 414
Submitted-By: arb@anand.org
Date: Wed, 26 Jul 2000 12:23:32 -0400 (EDT)
Version: 1.5.2
OS: i386-Redhat-linux 6.2


I'm using the "mailbox" module that comes with python. I'm trying to use the
maildir class in there, but I think it's not following the maildir protocol
properly. The maildir protocol specifies that in a Maildir, a message file
can have any name that is unique, as long as it doesn't begin with a period.
However, the maildir class looks for valid message filenames, by checking to
see if the filename has more than 1 period in it, ie. consists of 3 or more
sections separated by periods. Typically, this is the sort of name one finds
in a Maildir, because the Maildir protocol page describes one simple way of
creating a unique filename, ie. by using the timestamp, pid of the writer, and
the hostname. However, when I insert messages into a maildir which don't follow
that system of generating unique filenames,  the maildir class
of the module doesn't see them. Additioanlly, it _does_ see message files which
begin with a period, eg. .12345678.1234.hostname. This is also a violation of
the
maildir protocol. I believe that a maildir reader should simply look at all
files in a maildir, no matter what the name, except for those that begin with a
period.



====================================================================
Audit trail:
Wed Jul 26 18:15:33 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:02
By: none

Comment:
From: Guido van Rossum <guido@beopen.com>
Subject: Re: [Python-bugs-list] mailbox module's maildir class broken? (PR#414)
Date: Wed, 26 Jul 2000 17:31:29 -0500

> I'm using the "mailbox" module that comes with python. I'm trying to
> use the maildir class in there, but I think it's not following the
> maildir protocol properly. The maildir protocol specifies that in a
> Maildir, a message file can have any name that is unique, as long as
> it doesn't begin with a period.  However, the maildir class looks
> for valid message filenames, by checking to see if the filename has
> more than 1 period in it, ie. consists of 3 or more sections
> separated by periods. Typically, this is the sort of name one finds
> in a Maildir, because the Maildir protocol page describes one simple
> way of creating a unique filename, ie. by using the timestamp, pid
> of the writer, and the hostname. However, when I insert messages
> into a maildir which don't follow that system of generating unique
> filenames, the maildir class of the module doesn't see
> them. Additioanlly, it _does_ see message files which begin with a
> period, eg. .12345678.1234.hostname. This is also a violation of the
> maildir protocol. I believe that a maildir reader should simply look
> at all files in a maildir, no matter what the name, except for those
> that begin with a period.

You're probably right.  I've never used that code, and according to
the logs it was contributed to Mike Meyer (no email known).  Perhaps
you would be willing to create a patch?  See
http://www.python.org/patches/ for submission guidelines.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)


-------------------------------------------------------

Date: 2000-Aug-05 11:45
By: twouters

Comment:
This bug is still present. Fred is/was working on the 'mailbox' module, but I do not know whether he'll fix this, too. If not, I'll do it, it's not that big a chance.
-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110687&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 00:52:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 16:52:56 -0700
Subject: [Python-bugs-list] [Bug #110838] Inverse hyperbolic functions in cmath module (PR#231)
Message-ID: <200009182352.QAA04311@bush.i.sourceforge.net>

Bug #110838, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 1
Summary: Inverse hyperbolic functions in cmath module (PR#231)

Details: Jitterbug-Id: 231
Submitted-By: nadavh@envision.co.il
Date: Fri, 10 Mar 2000 18:35:07 -0500 (EST)
Version: 1.52
OS: NT 4.0 SP4


1.  The function cmath.acosh provides the negative branch with low 
precision. For example:

>>> cmath.acosh(cmath.cosh(10.0))
(-10.0000000135+0j)

Proposed solution --- use the following formula which is precise and
avoids singularities with complex arguments:

def acosh(x):
   return 2.0*log(sqrt(x+1.0) + sqrt(x-1.0)) - log(2.0)

2.  The function cmath.sinh does not handle moderately large 
arguments. For example:

>>> cmath.asinh(cmath.sinh(20.0))
(1.#INF+0j)

Proposed solution:

Use the textbook formula:
def asinh(x):
   return log(x+sqrt(x*x+1.0))

This calculation is more limited then the acosh calculation, but
still works fine.



====================================================================
Audit trail:
Mon Apr 03 18:38:28 2000	guido	changed notes
Mon Apr 03 18:38:28 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:15
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231)
Date: Fri, 10 Mar 2000 18:44:01 -0500

> Full_Name: Nadav Horesh
> Version: 1.52
> OS: NT 4.0 SP4
> Submission from: (NULL) (212.25.119.223)
> 
> 
> 1.  The function cmath.acosh provides the negative branch with low 
> precision. For example:
> 
> >>> cmath.acosh(cmath.cosh(10.0))
> (-10.0000000135+0j)
> 
> Proposed solution --- use the following formula which is precise and
> avoids singularities with complex arguments:
> 
> def acosh(x):
>    return 2.0*log(sqrt(x+1.0) + sqrt(x-1.0)) - log(2.0)
> 
> 2.  The function cmath.sinh does not handle moderately large 
> arguments. For example:
> 
> >>> cmath.asinh(cmath.sinh(20.0))
> (1.#INF+0j)
> 
> Proposed solution:
> 
> Use the textbook formula:
> def asinh(x):
>    return log(x+sqrt(x*x+1.0))
> 
> This calculation is more limited then the acosh calculation, but
> still works fine.

We're just using the VC++ C library.  I suggest you send your bug
report to Microsoft.

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-01 14:15
By: none

Comment:
From: "David Ascher" <DavidA@ActiveState.com>
Subject: RE: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231)
Date: Fri, 10 Mar 2000 16:47:23 -0800

> We're just using the VC++ C library.  I suggest you send your bug
> report to Microsoft.

FWIW: the Perl folks are more and more (it seems to me) redoing things
themselves if the C library tends to be broken or slow.  I'm not suggesting
that it's a good decision, just commenting.

--david



-------------------------------------------------------

Date: 2000-Aug-01 14:15
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231)
Date: Fri, 10 Mar 2000 22:05:07 -0500

[Nadav Horesh, suggests different algorithms in cmath, for some complex
 inverse hyperbolics]

[Guido, misfires]
> We're just using the VC++ C library.

C doesn't define any functions on complex numbers -- cmathmodule.c
implements these all on its own.  I can't make time to look at this now, but
complaining to Microsoft about this will do Nadav even less good than when
it *is* their problem <wink>.




-------------------------------------------------------

Date: 2000-Aug-01 14:15
By: none

Comment:
From: "David Ascher" <DavidA@ActiveState.com>
Subject: RE: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231)
Date: Fri, 10 Mar 2000 21:49:27 -0800

> [Nadav Horesh, suggests different algorithms in cmath, for some complex
>  inverse hyperbolics]
>
> [Guido, misfires]
> > We're just using the VC++ C library.
>
> C doesn't define any functions on complex numbers -- cmathmodule.c
> implements these all on its own.  I can't make time to look at
> this now, but
> complaining to Microsoft about this will do Nadav even less good than when
> it *is* their problem <wink>.

As an aside, if anyone ever wants to trim the number of builtin C modules, I
found that it was much easier to write cmath.py than to write cmath.java
(for JPython).  The same cmath.py should work fine in CPython.  I can dig it
up, but I can't swear that I used the most numerically stable algorithms.
It did give the same numbers as CPython's cmath on a test set.

-david



-------------------------------------------------------

Date: 2000-Aug-01 14:15
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] Inverse hyperbolic functions in cmath module (PR#231)
Date: Sat, 11 Mar 2000 13:47:25 -0500

[Tim]
> C doesn't define any functions on complex numbers -- cmathmodule.c
> implements these all on its own.

[David Ascher]
> As an aside, if anyone ever wants to trim the number of builtin C
> modules, I found that it was much easier to write cmath.py than to
> write cmath.java (for JPython).  The same cmath.py should work fine
> in CPython.

Yes, I don't see anything in cmathmodule.c that *needs* to be coded in C; &
coding would be much clearer in Python, using infix notation for the basic
complex binary ops.  Two possible reasons for leaving it in C:

1. Lower internal call overheads (i.e., speed).

2. Improving quality -- complex libraries are very difficult to get right
   in all cases if they're made IEEE-754 aware, and doing so requires
fiddling
   with the processor-level 754 control & status features.  But there's no
   portable way to do that now, and won't be until the next iteration of C.

> I can dig it up, but I can't swear that I used the most numerically stable
> algorithms.

I can:  you didn't <wink>.  Doesn't matter, though!  cmathmodule.c is naive
too, and achieving good accuracy across the whole domain is a major
undertaking.  That gives the best reason to write it in Python:

3. There's a long way to go to make this "industrial strength", so the
   current cmath is really just a prototype.  Everyone knows prototyping
   is much easier in Python.  QED <wink>.

> It did give the same numbers as CPython's cmath on a test set.

So ship it <wink>.




-------------------------------------------------------

Date: 2000-Aug-01 14:15
By: none

Comment:
Might be a good idea.
Waiting for patches.

-------------------------------------------------------

Date: 2000-Aug-01 17:38
By: jhylton

Comment:
I think this bug should be left open, but perhaps a new bug should be created for the general feature request "re-write cmath in python." It's up to you, Tim.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110838&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 00:54:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 16:54:03 -0700
Subject: [Python-bugs-list] [Bug #111802] anydbm cannot verify shelve database type
Message-ID: <200009182354.QAA04347@bush.i.sourceforge.net>

Bug #111802, was updated on 2000-Aug-13 10:05
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Trash
Priority: 5
Summary: anydbm cannot verify shelve database type

Details: 	When opening an existing "shelve" database file.  An exception is raised from anydbm saying "the database type could not be determined".  

Follow-Ups:

Date: 2000-Aug-24 06:18
By: moshez

Comment:
This sounds like the bug I fixed in whichdb (it couldn't recognize Python's dumbdbm). Assigned to me so I can deal with it (i.e., verify that it does happen on old Python, and doesn't happen to the CVS version). 
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=111802&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 00:54:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 16:54:47 -0700
Subject: [Python-bugs-list] [Bug #114532] cgi + <TextArea>.. + xml-data
Message-ID: <200009182354.QAA04354@bush.i.sourceforge.net>

Bug #114532, was updated on 2000-Sep-15 10:21
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Summary: cgi + <TextArea>.. + xml-data

Details: Hi!

I'm working under linux (mandrake 7.1) using python for my cgi scripts. There I've a formular containing a "textarea". If entering xml- or html-data into this textarea and submitting it the cgi-script doesn't get that xml-data. With non-xml-data everything works fine.

BTW: It's the same with an "input"-field.

ciao
Volker


Follow-Ups:

Date: 2000-Sep-15 10:57
By: gvanrossum

Comment:
Volker,

We cannot help you with this bug unless you provide us with an example we can try ourselves.  We need at least:

1) a simple but complete script that shows the bug (try to pare it down from the script you are using to somehing that demonstrates just the problem)

2) the HTML of the form (ditto)

3) the text you are entering into the form

We also need:

- the Python version
- the browser name and version
- the server name and version

That said, I suspect that the problem is in your script, but without looking at it, I can't tell!

--Guido
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114532&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 01:19:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 17:19:38 -0700
Subject: [Python-bugs-list] [Bug #114758] sys.prefix can be wrong with multiple Python installations
Message-ID: <200009190019.RAA21956@delerium.i.sourceforge.net>

Bug #114758, was updated on 2000-Sep-18 17:19
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sys.prefix can be wrong with multiple Python installations

Details: When installations of the same Python version are present on the same machine, sys.prefix (and exec_prefix) can be computed incorrectly for some of them under certain circumstances.  Specifically, if all the following are true:
  * Python A was installed with prefix != exec-prefix
  * Python B's interpreter binary precede's Python A's
    binary in PATH

Then Python A computes sys.prefix wrong: it gets Python B's prefix.

Specific example: I have 2.0cvs installed with
  --prefix=/usr/local/python 
  --exec-prefix=/usr/local/python.linux-i86
with a symlink /usr/local/bin/python2.0cvs pointing to /usr/local/python.linux-i86/bin/python2.0.

I also have the BeOpen Python 2.0b1 RPM installed, so /usr/local/bin/python is the BeOpen build.

Whether I run the CVS version as "/usr/local/bin/python2.0cvs" or as "/usr/local/python.linux-i86/bin/python", it gets sys.prefix wrong:

$ /usr/local/bin/python2.0cvs -c "import sys ; print sys.prefix ; print sys.exec_prefix"
/usr/local/bin/..
/usr/local/bin/../python.linux-i86

$ /usr/local/python.linux-i86/bin/python -c "import sys ; print sys.prefix ; print sys.exec_prefix"       
/usr/local
/usr/local/python.linux-i86

Hmm, it does get exec_prefix right.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114758&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 01:35:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 17:35:37 -0700
Subject: [Python-bugs-list] [Bug #114758] sys.prefix can be wrong with multiple Python installations
Message-ID: <200009190035.RAA05730@bush.i.sourceforge.net>

Bug #114758, was updated on 2000-Sep-18 17:19
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sys.prefix can be wrong with multiple Python installations

Details: When installations of the same Python version are present on the same machine, sys.prefix (and exec_prefix) can be computed incorrectly for some of them under certain circumstances.  Specifically, if all the following are true:
  * Python A was installed with prefix != exec-prefix
  * Python B's interpreter binary precede's Python A's
    binary in PATH

Then Python A computes sys.prefix wrong: it gets Python B's prefix.

Specific example: I have 2.0cvs installed with
  --prefix=/usr/local/python 
  --exec-prefix=/usr/local/python.linux-i86
with a symlink /usr/local/bin/python2.0cvs pointing to /usr/local/python.linux-i86/bin/python2.0.

I also have the BeOpen Python 2.0b1 RPM installed, so /usr/local/bin/python is the BeOpen build.

Whether I run the CVS version as "/usr/local/bin/python2.0cvs" or as "/usr/local/python.linux-i86/bin/python", it gets sys.prefix wrong:

$ /usr/local/bin/python2.0cvs -c "import sys ; print sys.prefix ; print sys.exec_prefix"
/usr/local/bin/..
/usr/local/bin/../python.linux-i86

$ /usr/local/python.linux-i86/bin/python -c "import sys ; print sys.prefix ; print sys.exec_prefix"       
/usr/local
/usr/local/python.linux-i86

Hmm, it does get exec_prefix right.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114758&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 02:30:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 18:30:49 -0700
Subject: [Python-bugs-list] [Bug #114754] marshal_loads can return NULL without setting Error
Message-ID: <200009190130.SAA07825@bush.i.sourceforge.net>

Bug #114754, was updated on 2000-Sep-18 15:46
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 7
Summary: marshal_loads can return NULL without setting Error

Details: I'm getting a NULL result from marshal_loads without it
setting an error. (This is in 1.5.2 and 2.0b1.)  I'm pretty 
sure the input being fed to marshal.loads is bad, but it 
still should still doing the error handling dance correctly, 
yes?  Here's a simple example:

    >>> import marshal
    >>> x = marshal.loads('006@mediaone.net.weekly.529454')
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    SystemError: NULL result without error in call_object

It looks like r_object returns NULL if type == '0' and then 
marshal_loads simply returns it without checking the value 
returned by r_object.  If this is a "feature" and not a
bug, there should at least be a comment in the TYPE_NULL
branch of the switch statement indicating why it's not an
error to return NULL without setting an exception.

(P.S.  Is there any search facility within the SF bug manager or are you stuck having to wade through all bugs to
find out if yours has already been reported?)


Follow-Ups:

Date: 2000-Sep-18 18:30
By: gvanrossum

Comment:
Marshal is not very careful in validating its input -- it was written for speedy reading of .pyc files only. I agree that this should be fixed. Since a spurious '0' input character probably isn't the only bad input that it might choke on (it could even dump core!) I'm not going to fix this, but I'll add a feature request to PEP 42: better checking for bad input to marshal.load*().
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114754&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 02:35:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 18:35:47 -0700
Subject: [Python-bugs-list] [Bug #110635] test_signal hangs when running as part of testall (PR#288)
Message-ID: <200009190135.SAA08000@bush.i.sourceforge.net>

Bug #110635, was updated on 2000-Jul-31 14:09
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: test_signal hangs when running as part of testall (PR#288)

Details: Jitterbug-Id: 288
Submitted-By: kessler@ccdc.cam.ac.uk
Date: Tue, 11 Apr 2000 06:58:39 -0400 (EDT)
Version: 1.6a2
OS: Irix6.3


Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal
works fine (?) if you run it on its own:

>>> import test.test_signal
starting pause() loop...
call pause()...
+ kill -5 7487 
+ sleep 2 
handlerA (5, <frame object at 100cf928>)
pause() returned
call pause()...
+ kill -2 7487 
+ sleep 2 
handlerB (2, <frame object at 100cf928>)
HandlerBCalled exception caught
call pause()...
+ kill -3 7487 
KeyboardInterrupt (assume the alarm() went off)

however, as part of the test suite, this test hangs:

>>> import test.testall
[...]
test_signal
test_signal
+ sleep 2 
starting pause() loop...
call pause()...
+ kill -5 7454 
+ sleep 2 
+ kill -2 7454 
+ sleep 2 
+ kill -3 7454 





====================================================================
Audit trail:
Tue Jul 11 08:29:16 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:09
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] test_signal hangs when running as part of testall (PR#288)
Date: Tue, 11 Apr 2000 11:27:20 -0400

> Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal
> works fine (?) if you run it on its own:
> 
> >>> import test.test_signal
> starting pause() loop...
> call pause()...
> + kill -5 7487 
> + sleep 2 
> handlerA (5, <frame object at 100cf928>)
> pause() returned
> call pause()...
> + kill -2 7487 
> + sleep 2 
> handlerB (2, <frame object at 100cf928>)
> HandlerBCalled exception caught
> call pause()...
> + kill -3 7487 
> KeyboardInterrupt (assume the alarm() went off)
> 
> however, as part of the test suite, this test hangs:
> 
> >>> import test.testall
> [...]
> test_signal
> test_signal
> + sleep 2 
> starting pause() loop...
> call pause()...
> + kill -5 7454 
> + sleep 2 
> + kill -2 7454 
> + sleep 2 
> + kill -3 7454 

Yes, I've seen this too.  Unfortunately, I don't have a clue, and I
don't have the time to delve into it...  I bet there's a compile time
#define that might do it.  It may have something to do with threads...

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-02 04:05
By: twouters

Comment:
Unsure if this is still an actual problem, but I've seen similar behaviour of test_signal on BSDI 4.0 and 4.0.1 systems, when Python was compiled with threads. The problem appeared to be the BSDI thread library, which had (among other things) problems with pause() in threaded code.

I haven't tried to enable threading on 4.0.x for a while, since new systems are 4.1, and 4.1 works properly with threads.

Does disabling threads fix the problem ? (Or perhaps *en*abling them, if they weren't ?)


-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 15:02
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-18 18:35
By: jhylton

Comment:
I've got no hope of fixing an IRIX bug.  At least you've used IRIX <0.2 wink>

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110635&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 02:46:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 18:46:06 -0700
Subject: [Python-bugs-list] [Bug #110656] IDLE goto file/line (PR#352)
Message-ID: <200009190146.SAA08363@bush.i.sourceforge.net>

Bug #110656, was updated on 2000-Jul-31 14:11
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Closed
Resolution: Works For Me
Bug Group: None
Priority: 3
Summary: IDLE goto file/line (PR#352)

Details: Jitterbug-Id: 352
Submitted-By: gpk@bell-labs.com
Date: Fri,  9 Jun 2000 22:45:05 -0400 (EDT)
Version: 1.6  CVS today
OS: Solaris 2.6


When using IDLE's shell window   Debug->Go to file/line,
you have to be overly careful what you select.
Specifically, if you select a region that contains a newline,
IDLE won't be able to find a file and line number.

For example, if you select
  v-- from there
   File "/export/h1/gpk/schoolweb.local/schoolweb/parse.py", line 199, in
__str__
  
  ^-- to there  (i.e. 2 characters in, on the following line),
you will get the following error message: "No special line: X the line you
point
to doesn't look like a file name followed by a line number."

That is unfortunate, as it's really convenient to make a quick flick
down from one line to the next, to select a complete line.



By the way, the error box requires you to click "OK".
That's a bug.   It isn't OK.
It's a crime against the King's English, committed by the minions
of Bill Gates.  You should not be following their lead.



====================================================================
Audit trail:
Tue Jul 11 08:25:59 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 14:56
By: bwarsaw

Comment:
Guido is the IDLE god.
-------------------------------------------------------

Date: 2000-Sep-18 18:46
By: gvanrossum

Comment:
I can't reproduce this. It works fine for me, no matter where I start or end the selection. I remember that I fixed something in this area, but that was back in March -- and you say that you are using the CVS tree.

I have no idea what you are talking about in your comment about "OK". :-)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110656&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 02:47:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 18:47:02 -0700
Subject: [Python-bugs-list] [Bug #114532] cgi + <TextArea>.. + xml-data
Message-ID: <200009190147.SAA08382@bush.i.sourceforge.net>

Bug #114532, was updated on 2000-Sep-15 10:21
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 1
Summary: cgi + <TextArea>.. + xml-data

Details: Hi!

I'm working under linux (mandrake 7.1) using python for my cgi scripts. There I've a formular containing a "textarea". If entering xml- or html-data into this textarea and submitting it the cgi-script doesn't get that xml-data. With non-xml-data everything works fine.

BTW: It's the same with an "input"-field.

ciao
Volker


Follow-Ups:

Date: 2000-Sep-15 10:57
By: gvanrossum

Comment:
Volker,

We cannot help you with this bug unless you provide us with an example we can try ourselves.  We need at least:

1) a simple but complete script that shows the bug (try to pare it down from the script you are using to somehing that demonstrates just the problem)

2) the HTML of the form (ditto)

3) the text you are entering into the form

We also need:

- the Python version
- the browser name and version
- the server name and version

That said, I suspect that the problem is in your script, but without looking at it, I can't tell!

--Guido
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114532&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 02:48:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 18:48:20 -0700
Subject: [Python-bugs-list] [Bug #114410] 'make tests' fails with thread error on OpenBSD 2.7
Message-ID: <200009190148.SAA08510@bush.i.sourceforge.net>

Bug #114410, was updated on 2000-Sep-14 02:24
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: 'make tests' fails with thread error on OpenBSD 2.7

Details: Using the latest CVS version of Python, the output from a pass of regrtest follows. It may be an OpenBSD problem, in which case if someone can explain it to me I will sendbug it to the OpenBSD people instead.

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
test_grammar
test_opcodes
test_operations
test_builtin
test_exceptions
test_types
test_MimeWriter
test_al
test test_al skipped --  No module named al
test_array
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test_binascii
test_binhex
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cgi
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test test_fcntl skipped --  No module named FCNTL
test_file
test_fork1
test_format
test_gc
gc: collectable <list 0x36e46c>
gc: collectable <dictionary 0x3d568c>
gc: collectable <list 0x36e46c>
gc: collectable <tuple 0x36e48c>
gc: collectable <class 0x3d570c>
gc: collectable <dictionary 0x3d56cc>
gc: collectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d574c>
gc: collectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d578c>
gc: collectable <instance method 0x25e34c>
gc: collectable <B instance at 0x36e4cc>
gc: collectable <dictionary 0x3d58cc>
gc: uncollectable <dictionary 0x3d584c>
gc: uncollectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d57cc>
gc: collectable <function 0x3d590c>
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test_gl
test test_gl skipped --  No module named gl
test_grp
pid 4207: Fatal error '_libc_private_storage_lock' at line 14 in file /usr/src/lib/libc_r/thread/thread_storage.c (errno = 2)
Abort (core dumped) 
*** Error code 134

Stop in /tmp/python/dist/src (line 212 of Makefile).


Follow-Ups:

Date: 2000-Sep-14 02:34
By: jribbens

Comment:
Oh, if you do './configure --without-threads' then the problem is avoided, of course. 'make tests' then gives:

74 tests OK.
26 tests skipped: test_al test_audioop test_cd test_cl test_crypt test_dbm test_dl test_fcntl test_fork1 test_gdbm test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev test_minidom test_nis test_pty test_pyexpat test_rgbimg test_sunaudiodev test_thread test_timing test_winreg test_winsound test_zlib

But presumably, since Python 2 has threads enabled by default, something else needs to be done ;-)
-------------------------------------------------------

Date: 2000-Sep-16 10:04
By: gvanrossum

Comment:
I don't have an OpenBSD system to debug this myself. I have access to FreeBSD 4.1 which does not have this problem. Perhaps you can try to debug this some more yourself?

If it's decided that this is a bug in OpenBSD (are you using the latest version?), please let us know so we can close this bug report.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114410&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 02:48:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 18:48:43 -0700
Subject: [Python-bugs-list] [Bug #114746] dis module is not up todate in 2.0b1-#4
Message-ID: <200009190148.SAA08518@bush.i.sourceforge.net>

Bug #114746, was updated on 2000-Sep-18 14:42
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: Works For Me
Bug Group: None
Priority: 1
Summary: dis module is not up todate in 2.0b1-#4

Details: While updating freeze I got an index error for an op
that was outside of the dis.opname list.


Follow-Ups:

Date: 2000-Sep-18 15:04
By: gvanrossum

Comment:
Please supply an example -- I don't have a problem using dis.py.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114746&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 02:50:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 18:50:16 -0700
Subject: [Python-bugs-list] [Bug #110635] test_signal hangs when running as part of testall (PR#288)
Message-ID: <200009190150.SAA08573@bush.i.sourceforge.net>

Bug #110635, was updated on 2000-Jul-31 14:09
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: test_signal hangs when running as part of testall (PR#288)

Details: Jitterbug-Id: 288
Submitted-By: kessler@ccdc.cam.ac.uk
Date: Tue, 11 Apr 2000 06:58:39 -0400 (EDT)
Version: 1.6a2
OS: Irix6.3


Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal
works fine (?) if you run it on its own:

>>> import test.test_signal
starting pause() loop...
call pause()...
+ kill -5 7487 
+ sleep 2 
handlerA (5, <frame object at 100cf928>)
pause() returned
call pause()...
+ kill -2 7487 
+ sleep 2 
handlerB (2, <frame object at 100cf928>)
HandlerBCalled exception caught
call pause()...
+ kill -3 7487 
KeyboardInterrupt (assume the alarm() went off)

however, as part of the test suite, this test hangs:

>>> import test.testall
[...]
test_signal
test_signal
+ sleep 2 
starting pause() loop...
call pause()...
+ kill -5 7454 
+ sleep 2 
+ kill -2 7454 
+ sleep 2 
+ kill -3 7454 





====================================================================
Audit trail:
Tue Jul 11 08:29:16 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:09
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] test_signal hangs when running as part of testall (PR#288)
Date: Tue, 11 Apr 2000 11:27:20 -0400

> Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal
> works fine (?) if you run it on its own:
> 
> >>> import test.test_signal
> starting pause() loop...
> call pause()...
> + kill -5 7487 
> + sleep 2 
> handlerA (5, <frame object at 100cf928>)
> pause() returned
> call pause()...
> + kill -2 7487 
> + sleep 2 
> handlerB (2, <frame object at 100cf928>)
> HandlerBCalled exception caught
> call pause()...
> + kill -3 7487 
> KeyboardInterrupt (assume the alarm() went off)
> 
> however, as part of the test suite, this test hangs:
> 
> >>> import test.testall
> [...]
> test_signal
> test_signal
> + sleep 2 
> starting pause() loop...
> call pause()...
> + kill -5 7454 
> + sleep 2 
> + kill -2 7454 
> + sleep 2 
> + kill -3 7454 

Yes, I've seen this too.  Unfortunately, I don't have a clue, and I
don't have the time to delve into it...  I bet there's a compile time
#define that might do it.  It may have something to do with threads...

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-02 04:05
By: twouters

Comment:
Unsure if this is still an actual problem, but I've seen similar behaviour of test_signal on BSDI 4.0 and 4.0.1 systems, when Python was compiled with threads. The problem appeared to be the BSDI thread library, which had (among other things) problems with pause() in threaded code.

I haven't tried to enable threading on 4.0.x for a while, since new systems are 4.1, and 4.1 works properly with threads.

Does disabling threads fix the problem ? (Or perhaps *en*abling them, if they weren't ?)


-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 15:02
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-18 18:35
By: jhylton

Comment:
I've got no hope of fixing an IRIX bug.  At least you've used IRIX <0.2 wink>

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110635&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 02:51:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 18:51:10 -0700
Subject: [Python-bugs-list] [Bug #110635] test_signal hangs when running as part of testall (PR#288)
Message-ID: <200009190151.SAA08596@bush.i.sourceforge.net>

Bug #110635, was updated on 2000-Jul-31 14:09
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: test_signal hangs when running as part of testall (PR#288)

Details: Jitterbug-Id: 288
Submitted-By: kessler@ccdc.cam.ac.uk
Date: Tue, 11 Apr 2000 06:58:39 -0400 (EDT)
Version: 1.6a2
OS: Irix6.3


Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal
works fine (?) if you run it on its own:

>>> import test.test_signal
starting pause() loop...
call pause()...
+ kill -5 7487 
+ sleep 2 
handlerA (5, <frame object at 100cf928>)
pause() returned
call pause()...
+ kill -2 7487 
+ sleep 2 
handlerB (2, <frame object at 100cf928>)
HandlerBCalled exception caught
call pause()...
+ kill -3 7487 
KeyboardInterrupt (assume the alarm() went off)

however, as part of the test suite, this test hangs:

>>> import test.testall
[...]
test_signal
test_signal
+ sleep 2 
starting pause() loop...
call pause()...
+ kill -5 7454 
+ sleep 2 
+ kill -2 7454 
+ sleep 2 
+ kill -3 7454 





====================================================================
Audit trail:
Tue Jul 11 08:29:16 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:09
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] test_signal hangs when running as part of testall (PR#288)
Date: Tue, 11 Apr 2000 11:27:20 -0400

> Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal
> works fine (?) if you run it on its own:
> 
> >>> import test.test_signal
> starting pause() loop...
> call pause()...
> + kill -5 7487 
> + sleep 2 
> handlerA (5, <frame object at 100cf928>)
> pause() returned
> call pause()...
> + kill -2 7487 
> + sleep 2 
> handlerB (2, <frame object at 100cf928>)
> HandlerBCalled exception caught
> call pause()...
> + kill -3 7487 
> KeyboardInterrupt (assume the alarm() went off)
> 
> however, as part of the test suite, this test hangs:
> 
> >>> import test.testall
> [...]
> test_signal
> test_signal
> + sleep 2 
> starting pause() loop...
> call pause()...
> + kill -5 7454 
> + sleep 2 
> + kill -2 7454 
> + sleep 2 
> + kill -3 7454 

Yes, I've seen this too.  Unfortunately, I don't have a clue, and I
don't have the time to delve into it...  I bet there's a compile time
#define that might do it.  It may have something to do with threads...

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-02 04:05
By: twouters

Comment:
Unsure if this is still an actual problem, but I've seen similar behaviour of test_signal on BSDI 4.0 and 4.0.1 systems, when Python was compiled with threads. The problem appeared to be the BSDI thread library, which had (among other things) problems with pause() in threaded code.

I haven't tried to enable threading on 4.0.x for a while, since new systems are 4.1, and 4.1 works properly with threads.

Does disabling threads fix the problem ? (Or perhaps *en*abling them, if they weren't ?)


-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 15:02
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-18 18:35
By: jhylton

Comment:
I've got no hope of fixing an IRIX bug.  At least you've used IRIX <0.2 wink>

-------------------------------------------------------

Date: 2000-Sep-18 18:51
By: gvanrossum

Comment:
I've got no hope either. I'll write the submittor. I've lowered the priority to 1 -- meaning I won't lose sleep over this.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110635&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 02:55:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 18:55:47 -0700
Subject: [Python-bugs-list] [Bug #110635] test_signal hangs when running as part of testall (PR#288)
Message-ID: <200009190155.SAA08771@bush.i.sourceforge.net>

Bug #110635, was updated on 2000-Jul-31 14:09
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: test_signal hangs when running as part of testall (PR#288)

Details: Jitterbug-Id: 288
Submitted-By: kessler@ccdc.cam.ac.uk
Date: Tue, 11 Apr 2000 06:58:39 -0400 (EDT)
Version: 1.6a2
OS: Irix6.3


Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal
works fine (?) if you run it on its own:

>>> import test.test_signal
starting pause() loop...
call pause()...
+ kill -5 7487 
+ sleep 2 
handlerA (5, <frame object at 100cf928>)
pause() returned
call pause()...
+ kill -2 7487 
+ sleep 2 
handlerB (2, <frame object at 100cf928>)
HandlerBCalled exception caught
call pause()...
+ kill -3 7487 
KeyboardInterrupt (assume the alarm() went off)

however, as part of the test suite, this test hangs:

>>> import test.testall
[...]
test_signal
test_signal
+ sleep 2 
starting pause() loop...
call pause()...
+ kill -5 7454 
+ sleep 2 
+ kill -2 7454 
+ sleep 2 
+ kill -3 7454 





====================================================================
Audit trail:
Tue Jul 11 08:29:16 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:09
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] test_signal hangs when running as part of testall (PR#288)
Date: Tue, 11 Apr 2000 11:27:20 -0400

> Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal
> works fine (?) if you run it on its own:
> 
> >>> import test.test_signal
> starting pause() loop...
> call pause()...
> + kill -5 7487 
> + sleep 2 
> handlerA (5, <frame object at 100cf928>)
> pause() returned
> call pause()...
> + kill -2 7487 
> + sleep 2 
> handlerB (2, <frame object at 100cf928>)
> HandlerBCalled exception caught
> call pause()...
> + kill -3 7487 
> KeyboardInterrupt (assume the alarm() went off)
> 
> however, as part of the test suite, this test hangs:
> 
> >>> import test.testall
> [...]
> test_signal
> test_signal
> + sleep 2 
> starting pause() loop...
> call pause()...
> + kill -5 7454 
> + sleep 2 
> + kill -2 7454 
> + sleep 2 
> + kill -3 7454 

Yes, I've seen this too.  Unfortunately, I don't have a clue, and I
don't have the time to delve into it...  I bet there's a compile time
#define that might do it.  It may have something to do with threads...

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-02 04:05
By: twouters

Comment:
Unsure if this is still an actual problem, but I've seen similar behaviour of test_signal on BSDI 4.0 and 4.0.1 systems, when Python was compiled with threads. The problem appeared to be the BSDI thread library, which had (among other things) problems with pause() in threaded code.

I haven't tried to enable threading on 4.0.x for a while, since new systems are 4.1, and 4.1 works properly with threads.

Does disabling threads fix the problem ? (Or perhaps *en*abling them, if they weren't ?)


-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 15:02
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-18 18:35
By: jhylton

Comment:
I've got no hope of fixing an IRIX bug.  At least you've used IRIX <0.2 wink>

-------------------------------------------------------

Date: 2000-Sep-18 18:51
By: gvanrossum

Comment:
I've got no hope either. I'll write the submittor. I've lowered the priority to 1 -- meaning I won't lose sleep over this.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110635&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 03:15:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 19:15:52 -0700
Subject: [Python-bugs-list] [Bug #114758] sys.prefix can be wrong with multiple Python installations
Message-ID: <200009190215.TAA09561@bush.i.sourceforge.net>

Bug #114758, was updated on 2000-Sep-18 17:19
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Wont Fix
Bug Group: None
Priority: 5
Summary: sys.prefix can be wrong with multiple Python installations

Details: When installations of the same Python version are present on the same machine, sys.prefix (and exec_prefix) can be computed incorrectly for some of them under certain circumstances.  Specifically, if all the following are true:
  * Python A was installed with prefix != exec-prefix
  * Python B's interpreter binary precede's Python A's
    binary in PATH

Then Python A computes sys.prefix wrong: it gets Python B's prefix.

Specific example: I have 2.0cvs installed with
  --prefix=/usr/local/python 
  --exec-prefix=/usr/local/python.linux-i86
with a symlink /usr/local/bin/python2.0cvs pointing to /usr/local/python.linux-i86/bin/python2.0.

I also have the BeOpen Python 2.0b1 RPM installed, so /usr/local/bin/python is the BeOpen build.

Whether I run the CVS version as "/usr/local/bin/python2.0cvs" or as "/usr/local/python.linux-i86/bin/python", it gets sys.prefix wrong:

$ /usr/local/bin/python2.0cvs -c "import sys ; print sys.prefix ; print sys.exec_prefix"
/usr/local/bin/..
/usr/local/bin/../python.linux-i86

$ /usr/local/python.linux-i86/bin/python -c "import sys ; print sys.prefix ; print sys.exec_prefix"       
/usr/local
/usr/local/python.linux-i86

Hmm, it does get exec_prefix right.

Follow-Ups:

Date: 2000-Sep-18 19:15
By: gvanrossum

Comment:
This is because of some (CNRI depot-inspired!) assumptions for finding the prefix landmark when prefix!=exec_prefix. I don't think it's worth fixing.

Interpreter A is first looking for its prefix landmark (os.py) relative to its binary's location by stripping off more and more trailing directories. It thus probes the sequence (I think):

1. /usr/local/python.linux-i86/bin/lib/python2.0/os.py
2. /usr/local/python.linux-i86/lib/python2.0/os.py
3. /usr/local/lib/python2.0/os.py

And lo and behold, that's interpreter B's landmark!

I can't change the search algorithm to use the compiled-in default prefix *before* probing the path: the path probe is intended to detect that Python was installed in a different directory than its default prefix!

An easy solution for you is to make sure that prefix is a parent dir of exec_prefix.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114758&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 04:38:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 20:38:39 -0700
Subject: [Python-bugs-list] [Bug #114749] HTML docs problems
Message-ID: <200009190338.UAA29476@delerium.i.sourceforge.net>

Bug #114749, was updated on 2000-Sep-18 15:05
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: HTML docs problems

Details: The module index is empty.
In the library the contents is empty.

The tag <tex2html_anchor_invisible_mark> appears in lots of the .html files.

The encode() method is not documented for strings.

No docs on unicode strings in lib ref like the strings module.

Please mark links that leave the local machine. For example the link to "Python How-To Guides".


Follow-Ups:

Date: 2000-Sep-18 20:38
By: fdrake

Comment:
The "".encode() method is documented in the latest documentation package.  The Module Index and Contents pages are corrected as well.

What docs were you looking for on Unicode strings that was missing?  Please be sure to use the latest version of the documentation on www.pythonlabs.com; python.org is out of date.

I'll look into the other matters; things can clearly be improved.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114749&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 05:02:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 21:02:01 -0700
Subject: [Python-bugs-list] [Bug #110839] CGIHTTPServer (PR#239)
Message-ID: <200009190402.VAA13405@bush.i.sourceforge.net>

Bug #110839, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 3
Summary: CGIHTTPServer (PR#239)

Details: Jitterbug-Id: 239
Submitted-By: Michael_Frericks@informatik-kooperation.de
Date: Fri, 17 Mar 2000 11:27:23 -0500 (EST)
Version: 1.5.2
OS: WinNT 4.0


The module CGIHTTPServer does not run on WinNT since 

a) the function executable() seems to return a false value, if you omit the call
of executable() you come to
b) the function nobody_uid() imports the module pwd available only for unix
c) other unix-functions as fork... are used to create a process with the user
nobody



====================================================================
Audit trail:
Mon Apr 03 18:39:48 2000	guido	changed notes
Mon Apr 03 18:39:48 2000	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-01 14:15
By: none

Comment:
This module still needs to be ported to Windows...
-------------------------------------------------------

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-15 19:22
By: tim_one

Comment:
Moved to PEP42; awaiting a volunteer.
-------------------------------------------------------

Date: 2000-Sep-15 19:39
By: gvanrossum

Comment:
I might volunteer.
-------------------------------------------------------

Date: 2000-Sep-18 21:02
By: gvanrossum

Comment:
This is fixed. The module now works on Unix, Windows, and (I hope) Macintosh.

Warning: this module is not secure -- don't use it unless you are inside a firewall!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110839&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 05:13:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 21:13:32 -0700
Subject: [Python-bugs-list] [Bug #114756] test_linuxaudiodev uses wrong format
Message-ID: <200009190413.VAA13871@bush.i.sourceforge.net>

Bug #114756, was updated on 2000-Sep-18 16:50
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_linuxaudiodev uses wrong format

Details: test_linuxaudiodev sounds *horrible*.  This has come up several times on python-dev, but nobody seems to have a fix that works -- or at least nothing has been checked in, so I'm contributing this bug report to the collective memory.

Here's how the bug manifests on my machine (a Dell Dimension with built-in sound hardware [Yamaha YMF-724F], using ALSA 0.5.8a drivers in a 2.2.14 kernel):

$ ./python Lib/test/test_linuxaudiodev.py
plays the entire sample without complaint, but it sounds *horrible* -- apparently because it's treating an .au file incorrectly.

See also my python-dev post of 29 June 2000: http://www.python.org/pipermail/python-dev/2000-June/011808.html

Ping suggested setting AUDIODEV=/dev/audio before running the script, and Michael Hudson contributed an alternate version of the test script which writes to /dev/audio (same idea, no environment variable needed).  Either of these fixes has the same result:

$ ./python Lib/test/test_linuxaudiodev-hudson.py
Traceback (most recent call last):
  File "Lib/test/test_linuxaudiodev-hudson.py", line 62, in ?
    test()
  File "Lib/test/test_linuxaudiodev-hudson.py", line 60, in test
    play_au_file(findfile('audiotest.au'))
  File "Lib/test/test_linuxaudiodev-hudson.py", line 55, in play_au_file
    dsp.write(data)
linuxaudiodev.error: (11, 'Resource temporarily unavailable')

The traceback appears immediately, but the script keeps running while the sample plays -- well, about half of it.  The sample is cut off midway through, and my shell prompt returns.

Finally, Ping posted another variation on the test script (http://www.python.org/pipermail/python-dev/2000-June/011834.html) which does not work at all for me:
$ ./python Lib/test/test_linuxaudiodev-ping.py
Traceback (most recent call last):
  File "Lib/test/test_linuxaudiodev-ping.py", line 37, in ?
    test()
  File "Lib/test/test_linuxaudiodev-ping.py", line 35, in test
    play_au_file(findfile('audiotest.au'))
  File "Lib/test/test_linuxaudiodev-ping.py", line 26, in play_au_file
    raise "audio format not supported by linuxaudiodev"
audio format not supported by linuxaudiodev

No sound at all from this one.

Charles Waldman <cgw@fnal.gov> also took a look at linuxaudiodev.c and didn't like what he found: http://www.python.org/pipermail/python-dev/2000-August/015746.html; Charles has said he's working on a rewrite of this module.



Follow-Ups:

Date: 2000-Sep-18 21:13
By: gvanrossum

Comment:
You do have a sound card, don't you, Jeremy?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114756&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 05:15:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 21:15:18 -0700
Subject: [Python-bugs-list] [Bug #114630] Add fpectl functionality patch for FreeBSD
Message-ID: <200009190415.VAA13927@bush.i.sourceforge.net>

Bug #114630, was updated on 2000-Sep-17 08:04
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Invalid
Bug Group: Platform-specific
Priority: 5
Summary: Add fpectl functionality patch for FreeBSD

Details: I'd have expected an "attach file" function on the bug page.  Not seeing one, I pasted the patch into the bug window.

--- Python-1.5.2/Modules/ORIG/fpectlmodule.c    Thu Dec 10 11:49:27 1998
+++ Python-1.5.2/Modules/fpectlmodule.c Sun Sep 17 10:44:17 2000
@@ -68,6 +68,10 @@
 #include "Python.h"
 #include <signal.h>
 
+#if defined(__FreeBSD__)
+#  include <ieeefp.h>
+#endif
+
 #ifndef WANT_SIGFPE_HANDLER
 /* Define locally if they are not defined in Python.  This gives only
  * the limited control to induce a core dump in case of an exception.
@@ -178,6 +182,12 @@
 #endif
     signal(SIGFPE, handler);
 
+/*-- FreeBSD ----------------------------------------------------------------*/
+#elif defined(__FreeBSD__)
+    fpresetsticky( fpgetsticky() );
+    fpsetmask( FP_X_INV | FP_X_DZ | FP_X_OFL );
+    signal( SIGFPE, handler );
+
 /*-- Linux ----------------------------------------------------------------*/
 #elif defined(linux)
 #ifdef __GLIBC__
@@ -212,7 +222,12 @@
 
 static PyObject *turnoff_sigfpe(PyObject *self,PyObject *args)
 {
+#ifdef __FreeBSD__
+    fpresetsticky( fpgetsticky() );
+    fpsetmask( 0 );
+#else
     fputs("Operation not implemented\n", stderr);
+#endif
     Py_INCREF (Py_None);
     return Py_None;
 }


Follow-Ups:

Date: 2000-Sep-18 21:15
By: gvanrossum

Comment:
Please use the patch manager to send in patches. Extracting the patch from the HTML is too painful.

http://sourceforge.net/patch/?func=addpatch&group_id=5470

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114630&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 05:38:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 21:38:48 -0700
Subject: [Python-bugs-list] [Bug #114775] test_minidom failing on Windows
Message-ID: <200009190438.VAA14796@bush.i.sourceforge.net>

Bug #114775, was updated on 2000-Sep-18 21:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 1
Summary: test_minidom failing on Windows

Details: Was working until very recently:

C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py test_minidom

test_minidom
test test_minidom failed -- Writing: ' ', expected: '>'
1 test failed: test_minidom

C:\Code\python\dist\src\PCbuild>


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114775&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 05:43:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 21:43:11 -0700
Subject: [Python-bugs-list] [Bug #114775] test_minidom failing on Windows
Message-ID: <200009190443.VAA14964@bush.i.sourceforge.net>

Bug #114775, was updated on 2000-Sep-18 21:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: test_minidom failing on Windows

Details: Was working until very recently:

C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py test_minidom

test_minidom
test test_minidom failed -- Writing: ' ', expected: '>'
1 test failed: test_minidom

C:\Code\python\dist\src\PCbuild>


Follow-Ups:

Date: 2000-Sep-18 21:43
By: tim_one

Comment:
Boosted at priority, as must work for release.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114775&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 05:58:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 21:58:24 -0700
Subject: [Python-bugs-list] [Bug #114775] test_minidom failing on Windows
Message-ID: <200009190458.VAA32198@delerium.i.sourceforge.net>

Bug #114775, was updated on 2000-Sep-18 21:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: test_minidom failing on Windows

Details: Was working until very recently:

C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py test_minidom

test_minidom
test test_minidom failed -- Writing: ' ', expected: '>'
1 test failed: test_minidom

C:\Code\python\dist\src\PCbuild>


Follow-Ups:

Date: 2000-Sep-18 21:43
By: tim_one

Comment:
Boosted at priority, as must work for release.
-------------------------------------------------------

Date: 2000-Sep-18 21:58
By: fdrake

Comment:
I get this on Linux-Mandrake 7.1:

test_minidom
test test_minidom failed -- Writing: ' ', expected: '\012'
1 test failed: test_minidom

Note that the test output contains reprs of instance objects using the <foo.MyClass instance at xxxx> form, and this is about as non-portable as it gets.  Just running the test script directly (not via regrtest.py) does not produce any failures.

The test needs to be modified to produce portable output, with non-portable output reserved for verbose mode.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114775&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 07:38:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Sep 2000 23:38:36 -0700
Subject: [Python-bugs-list] [Bug #110679] profile.py: self-profiling bug (PR#394)
Message-ID: <200009190638.XAA18790@bush.i.sourceforge.net>

Bug #110679, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Wont Fix
Bug Group: None
Priority: 5
Summary: profile.py: self-profiling bug (PR#394)

Details: Jitterbug-Id: 394
Submitted-By: akuchlin@mems-exchange.org
Date: Fri,  7 Jul 2000 09:03:04 -0400 (EDT)
Version: 2.0cvs
OS: 


Reported by jtravis@cse.unl.edu (Jon Travis) in comp.lang.python:

There is a small bug while running some of
the profiling code from within the profiler.  
Specifically:

import profile
x = profile.Profile()
x.run("x.dump_stats('/tmp/foo')")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "./Lib/profile.py", line 347, in run
    return self.runctx(cmd, dict, dict)
  File "./Lib/profile.py", line 353, in runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "./Lib/profile.py", line 322, in dump_stats
    self.create_stats()
  File "./Lib/profile.py", line 327, in create_stats
    self.simulate_cmd_complete()
  File "./Lib/profile.py", line 312, in simulate_cmd_complete
    self.t = self.get_time() - t
  File "./Lib/profile.py", line 191, in trace_dispatch_i
    if self.dispatch[event](frame,t):
  File "./Lib/profile.py", line 248, in trace_dispatch_return
    pt, ptt, pct, pfn, pframe, pcur = rcur
TypeError: unpack non-sequence

I have a small 2 liner fix, but I doubt it is correct,
merely a band-aid, so I won't post it.

-- Jon






====================================================================
Audit trail:
Tue Jul 11 08:24:32 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-18 23:38
By: tim_one

Comment:
Closed with "WontFix".

For speed, the profiler maintains a stack of frame summary info in self.cur (as a nested 6-tuple), intended to parallel the actual call stack.  One of the first things dump_stats does is to call simulate_cmd_complete, which unwinds the shadow stack in self.cur, under the (reasonable!) assumption that the command being profiled is finished.  But when you try to profile dump_stats itself, the cmd being profiled (i.e., dump_stats) is *not* finished at that time, and simulate_cmd_complete drains away the shadow stack info for dump_stats and create_stats and simulate_cmd_complete while they're still active.

When those functions *actually* return, then, the shadow stack is empty (i.e. self.cur is None), and attempting to unwind it some more goes boom.

The only rational response is "so don't do that".  The *old* profiler probably could have tolerated this abuse, as it stored info in the actual frames' local dicts, so there was nothing to get out of synch.  The shadow frame gimmick made it run much faster, but also created the possibility for perversely introspective profiling to get the shadow stack out of synch with the true stack.

If you simply must profile Profile's dump_stats itself (or simulate_cmd_complete, or create_stats), write a subclass of Profile that keeps track of the runtime stack in some other, more paranoid way.  I don't see a way to do that without giving up speed, and speed in the std Profile class is a priority.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110679&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 09:50:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 01:50:08 -0700
Subject: [Python-bugs-list] [Bug #114780] Rare hangs in w9xpopen.exe
Message-ID: <200009190850.BAA23769@bush.i.sourceforge.net>

Bug #114780, was updated on 2000-Sep-19 01:50
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: Rare hangs in w9xpopen.exe

Details: Every two or three days, when I'm running the std test suite on my Win98SE box, test_popen2 just hangs.  wintop shows that w9xpopen.exe is alive, but not consuming any cycles.  test_popen2.py is waiting on a .read().

No other clues.  It *may* be the case that I'm establishing a modem connection near the time test_popen2 starts to run.  I'll try to provoke that.

Assigned to MarkH simply to share the misery <wink>.  Mark, I don't expect you to "fix this", but I don't expect me to either -- it's just something we should both be aware of.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114780&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 10:21:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 02:21:22 -0700
Subject: [Python-bugs-list] [Bug #114598] Blue Screen crash, popen, Win98, Norton Antivirus 2000
Message-ID: <200009190921.CAA08914@delerium.i.sourceforge.net>

Bug #114598, was updated on 2000-Sep-16 13:24
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 7
Summary: Blue Screen crash, popen, Win98, Norton Antivirus 2000

Details: On Windows 98, all of the os.popen*() functions cause a hard "blue screen" crash requiring a reboot, when Nortin Antivirus 2000 is installed and enabled. (Not with Norton Antivirus version 5, not on Windows 2000.)

While this is probably a bug in Norton Antivirus 2000, and we're already warning for this on the download page, that's not enough (we've seen at least one report in the newsgroup), and it would be good if we could somehow prevent it. Even a call to Py_FatalError is better than the blue screen, and raising os.error would be a *lot* better.

Follow-Ups:

Date: 2000-Sep-16 14:26
By: tim_one

Comment:
I don't know how to stop this.  Pissed away an hour trying to get help on the Symantec site, and eventually found a support board to which I posted this msg:

Product: Norton AntiVirus 2000 6.0 for Windows 95/98/NT
Supported operating system: Windows 98
Action: Run Another Program
Error Message: 
Summary: Blue screen crash

I develop the Windows version of the core Python language. Several reports of blue-screen death on Win98 have been traced to NAV2000.  Here's the exact msg from one such:

An exception 0E has occurred at 0028:C02AD9D0 in VxD IFSMGR(04) + 000050E4. This was called from 0028:C000B511 in VxD VMM(01) + 0000A511. It may be possible to continue normally.

This occurs whenever a user executes a member of the popen family of functions from within Python; for example, this Python program:

import os
p = os.popen("dir")

popen is a std C library function, poorly implemented by Microsoft, but not *that* poorly <wink>.

You can get our latest installer here:

http://www.pythonlabs.com/tech/python2.0/download.html

As the warning there says:

-----------------
Incompatibility warning: Norton Antivirus 2000 can cause blue screen crashes on Windows 98 when a function in the os.popen*() family is invoked. To prevent this problem, disable Norton Antivirus when using Python. (Confirmed on Windows 98 Second Edition with Norton Antivirus version 6.10.20. The same Norton Antivirus version doesn't have this
problem on Windows 2000. Norton Antivirus version 5 on Windows 98SE doesn't have this problem either.) 
-----------------

ActiveState is seeing the same problem with their derivative work ActivePython, as is PythonWare with their derivative work PythonWorks. So this affects a lot of people. A recent change to the implementation of a popular library module has made it acutely visible recently (didn't use to use popen, but does now).

A workaround would be nice. More importantly, how can I *detect* whether an affected version of NAV is in use, so that we can shut down Python gracefully with an appropriate message before executing any of the popen functions that throw NAV into blue-screen territory? We try to be a very user-friendly language, and we'll do anything to prevent a crash. Alas, right now I don't know how to stop it.

-------------------------------------------------------

Date: 2000-Sep-19 02:21
By: tim_one

Comment:
1. Sent Guido a small self-contained C program in the hope that it's enough to provoke the problem by itself.  Reassigned this bug to Guido since he has to tell me what happens with that next (then assign back to me).

2. That's because Symantec is being no help at all.  They suggest upgrading to NAV 2001(!).  If I can post a tiny C program, maybe it will embarrass then into doing something.  You can follow this soap opera at:

http://servicenews.symantec.com/cgi-bin/displayArticle.cgi?group=symantec.support.win9x.nortonantivirus2000.general&article=57765

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114598&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 13:02:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 05:02:17 -0700
Subject: [Python-bugs-list] [Bug #110861] time.sleep() and threading (PR#307)
Message-ID: <200009191202.FAA14809@delerium.i.sourceforge.net>

Bug #110861, was updated on 2000-Aug-01 14:39
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: Irreproducible
Priority: 5
Summary: time.sleep() and threading (PR#307)

Details: Jitterbug-Id: 307
Submitted-By: gpk@bell-labs.com
Date: Fri, 28 Apr 2000 11:28:19 -0400 (EDT)
Version: 1.5.2
OS: Solaris 2.6 sparc


python .../test/test_thread.py shows that time.sleep()
does not relinquish the processor.
As one thread goes to sleep, another thread ought
to start processing.   That doesn't happen.

Python was configured with --with-thread
and compiler flags -mt and -D_REENTRANT.
See line from config.status: s%@CC@%cc -mt -D_REENTRANT%g

EXAMPLE:

hce* python test_thread.py
creating task 1
creating task 2
creating task 3
creating task 4
creating task 5
creating task 6
creating task 7
creating task 8
creating task 9
creating task 10
waiting for all tasks to complete
task 1 will run for 9.9 sec		# goes to sleep here...
task 1 done				# 9.9 seconds later...
task 5 will run for 4.1 sec		# This should have started when task 1 slept.
task 5 done
task 7 will run for 9.9 sec
task 7 done
task 4 will run for 9.2 sec
task 4 done
task task 6 will run for 7.7 sec




====================================================================
Audit trail:
Mon May 22 17:23:26 2000	guido	changed notes
Mon May 22 17:23:26 2000	guido	moved from incoming to irreproducible

Follow-Ups:

Date: 2000-Aug-01 14:39
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] time.sleep() and threading (PR#307)
Date: Wed, 03 May 2000 11:58:20 -0400

> python .../test/test_thread.py shows that time.sleep()
> does not relinquish the processor.
> As one thread goes to sleep, another thread ought
> to start processing.   That doesn't happen.
> 
> Python was configured with --with-thread
> and compiler flags -mt and -D_REENTRANT.
> See line from config.status: s%@CC@%cc -mt -D_REENTRANT%g
> 
> EXAMPLE:
> 
> hce* python test_thread.py
> creating task 1
> creating task 2
> creating task 3
> creating task 4
> creating task 5
> creating task 6
> creating task 7
> creating task 8
> creating task 9
> creating task 10
> waiting for all tasks to complete
> task 1 will run for 9.9 sec		# goes to sleep here...
> task 1 done				# 9.9 seconds later...
> task 5 will run for 4.1 sec		# This should have started when task 1 slept.
> task 5 done
> task 7 will run for 9.9 sec
> task 7 done
> task 4 will run for 9.2 sec
> task 4 done
> task task 6 will run for 7.7 sec

Hm...  It works correctly for me on Solaris 7 compiled with gcc, using
either Solaris threads or Posix threads.

I wonder if this could have something to do with the compiler you are
using?  (Are you using the SunPro compiler?)

There's not much I can do about this right now, sorry.

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-01 14:39
By: none

Comment:
And wqent away when he upgraded to Py 1.6.
-------------------------------------------------------

Date: 2000-Aug-25 10:47
By: jhylton

Comment:
Can you test this with Sun's compiler?

-------------------------------------------------------

Date: 2000-Aug-30 10:13
By: gward

Comment:
I built the latest CVS Python 2.0 source on Solaris 2.6 with both GCC and the Sun Workshop compiler (4.2).  The test seems to be correct, ie. I don't get any long delays while task 1 is sleeping before subsequent tasks start up.

Haven't tried any earlier Python release.  Does anyone care, or should we call this one "Fixed in 2.0"?

-------------------------------------------------------

Date: 2000-Sep-18 16:12
By: gward

Comment:
Since I was unable to reproduce this bug with Python 2.0, and no one has commented on it since I made that finding, I'm closing this bug.
-------------------------------------------------------

Date: 2000-Sep-19 05:02
By: gward

Comment:
The original reporter of the bug (Greg Kochanski <gpk@bell-labs.com>) confirms:

> I've checked.  It has been fine since 1.6a1 or 1.6a2.

So I'm leaving it closed and changing the resolution to "Fixed".
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110861&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 13:27:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 05:27:07 -0700
Subject: [Python-bugs-list] [Bug #114792] Document how to report bugs against python
Message-ID: <200009191227.FAA31815@bush.i.sourceforge.net>

Bug #114792, was updated on 2000-Sep-19 05:27
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Document how to report bugs against python

Details: 
Why don't you tell people how to report bugs in python on the web site
or the documentation?
 
I'd expect this info in the docs and on the web site for python.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114792&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 13:45:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 05:45:09 -0700
Subject: [Python-bugs-list] [Bug #110635] test_signal hangs when running as part of testall (PR#288)
Message-ID: <200009191245.FAA32548@bush.i.sourceforge.net>

Bug #110635, was updated on 2000-Jul-31 14:09
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: test_signal hangs when running as part of testall (PR#288)

Details: Jitterbug-Id: 288
Submitted-By: kessler@ccdc.cam.ac.uk
Date: Tue, 11 Apr 2000 06:58:39 -0400 (EDT)
Version: 1.6a2
OS: Irix6.3


Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal
works fine (?) if you run it on its own:

>>> import test.test_signal
starting pause() loop...
call pause()...
+ kill -5 7487 
+ sleep 2 
handlerA (5, <frame object at 100cf928>)
pause() returned
call pause()...
+ kill -2 7487 
+ sleep 2 
handlerB (2, <frame object at 100cf928>)
HandlerBCalled exception caught
call pause()...
+ kill -3 7487 
KeyboardInterrupt (assume the alarm() went off)

however, as part of the test suite, this test hangs:

>>> import test.testall
[...]
test_signal
test_signal
+ sleep 2 
starting pause() loop...
call pause()...
+ kill -5 7454 
+ sleep 2 
+ kill -2 7454 
+ sleep 2 
+ kill -3 7454 





====================================================================
Audit trail:
Tue Jul 11 08:29:16 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:09
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] test_signal hangs when running as part of testall (PR#288)
Date: Tue, 11 Apr 2000 11:27:20 -0400

> Under Irix6.3 (python compiled in -n32 mode with MipsPro 7.2.1), test_signal
> works fine (?) if you run it on its own:
> 
> >>> import test.test_signal
> starting pause() loop...
> call pause()...
> + kill -5 7487 
> + sleep 2 
> handlerA (5, <frame object at 100cf928>)
> pause() returned
> call pause()...
> + kill -2 7487 
> + sleep 2 
> handlerB (2, <frame object at 100cf928>)
> HandlerBCalled exception caught
> call pause()...
> + kill -3 7487 
> KeyboardInterrupt (assume the alarm() went off)
> 
> however, as part of the test suite, this test hangs:
> 
> >>> import test.testall
> [...]
> test_signal
> test_signal
> + sleep 2 
> starting pause() loop...
> call pause()...
> + kill -5 7454 
> + sleep 2 
> + kill -2 7454 
> + sleep 2 
> + kill -3 7454 

Yes, I've seen this too.  Unfortunately, I don't have a clue, and I
don't have the time to delve into it...  I bet there's a compile time
#define that might do it.  It may have something to do with threads...

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-02 04:05
By: twouters

Comment:
Unsure if this is still an actual problem, but I've seen similar behaviour of test_signal on BSDI 4.0 and 4.0.1 systems, when Python was compiled with threads. The problem appeared to be the BSDI thread library, which had (among other things) problems with pause() in threaded code.

I haven't tried to enable threading on 4.0.x for a while, since new systems are 4.1, and 4.1 works properly with threads.

Does disabling threads fix the problem ? (Or perhaps *en*abling them, if they weren't ?)


-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 15:02
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-18 18:35
By: jhylton

Comment:
I've got no hope of fixing an IRIX bug.  At least you've used IRIX <0.2 wink>

-------------------------------------------------------

Date: 2000-Sep-18 18:51
By: gvanrossum

Comment:
I've got no hope either. I'll write the submittor. I've lowered the priority to 1 -- meaning I won't lose sleep over this.
-------------------------------------------------------

Date: 2000-Sep-19 05:45
By: gvanrossum

Comment:
Original submittor lost access to SGI hardware. Closing since there's not much we can do about this.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110635&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 13:51:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 05:51:18 -0700
Subject: [Python-bugs-list] [Bug #114780] Rare hangs in w9xpopen.exe
Message-ID: <200009191251.FAA00306@bush.i.sourceforge.net>

Bug #114780, was updated on 2000-Sep-19 01:50
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: Rare hangs in w9xpopen.exe

Details: Every two or three days, when I'm running the std test suite on my Win98SE box, test_popen2 just hangs.  wintop shows that w9xpopen.exe is alive, but not consuming any cycles.  test_popen2.py is waiting on a .read().

No other clues.  It *may* be the case that I'm establishing a modem connection near the time test_popen2 starts to run.  I'll try to provoke that.

Assigned to MarkH simply to share the misery <wink>.  Mark, I don't expect you to "fix this", but I don't expect me to either -- it's just something we should both be aware of.


Follow-Ups:

Date: 2000-Sep-19 05:51
By: gvanrossum

Comment:
Tim, do you remember the problem I had with using popen() from IDLE? I had code that essentially did os.popen("start "+url).close(). This worked fine in a DOS box but hung inexplicably for 30 seconds before returning and starting the browser when used in IDLE. The problem went away (the call returned immediately and the browser was started within 2-3 seconds) when I saved the pipe object in an instance variable. We never fixed this, but I tracked it down to probably something having to do with the need to pump events. Mark will understand. I don't doubt that popen2, popen3, popen4 all share this problem. (Check webbrowser.py, class WindowsDefault, for the current solution.)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114780&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 14:21:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 06:21:33 -0700
Subject: [Python-bugs-list] [Bug #114792] Document how to report bugs against python
Message-ID: <200009191321.GAA17859@delerium.i.sourceforge.net>

Bug #114792, was updated on 2000-Sep-19 05:27
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Document how to report bugs against python

Details: 
Why don't you tell people how to report bugs in python on the web site
or the documentation?
 
I'd expect this info in the docs and on the web site for python.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114792&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 14:41:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 06:41:36 -0700
Subject: [Python-bugs-list] [Bug #110686] cStringIO lacks the readlines method (PR#409)
Message-ID: <200009191341.GAA18630@delerium.i.sourceforge.net>

Bug #110686, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 4
Summary: cStringIO lacks the readlines method (PR#409)

Details: Jitterbug-Id: 409
Submitted-By: pierre@saiph.com
Date: Sun, 23 Jul 2000 13:41:59 -0400 (EDT)
Version: 1.5.2
OS: sparc solaris


cStringIO is supposed to be the C version of  For some reason,
it does not provide the readlines method.
The obvious turnaround is to use StringIO instead: no hurry to fix,
at least on my side.



====================================================================
Audit trail:
Mon Jul 24 18:41:02 2000	jeremy	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-05 13:11
By: loewis

Comment:
Fixed in Patch #101423,
http://sourceforge.net/patch/?func=detailpatch&patch_id=101423&group_id=5470
-------------------------------------------------------

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 15:00
By: bwarsaw

Comment:
Added to PEP 42
-------------------------------------------------------

Date: 2000-Sep-19 06:41
By: loewis

Comment:
Fixed in cStringIO.c 2.26
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110686&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 15:05:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 07:05:47 -0700
Subject: [Python-bugs-list] [Bug #114775] test_minidom failing on Windows
Message-ID: <200009191405.HAA03251@bush.i.sourceforge.net>

Bug #114775, was updated on 2000-Sep-18 21:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 9
Summary: test_minidom failing on Windows

Details: Was working until very recently:

C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py test_minidom

test_minidom
test test_minidom failed -- Writing: ' ', expected: '>'
1 test failed: test_minidom

C:\Code\python\dist\src\PCbuild>


Follow-Ups:

Date: 2000-Sep-18 21:43
By: tim_one

Comment:
Boosted at priority, as must work for release.
-------------------------------------------------------

Date: 2000-Sep-18 21:58
By: fdrake

Comment:
I get this on Linux-Mandrake 7.1:

test_minidom
test test_minidom failed -- Writing: ' ', expected: '\012'
1 test failed: test_minidom

Note that the test output contains reprs of instance objects using the <foo.MyClass instance at xxxx> form, and this is about as non-portable as it gets.  Just running the test script directly (not via regrtest.py) does not produce any failures.

The test needs to be modified to produce portable output, with non-portable output reserved for verbose mode.
-------------------------------------------------------

Date: 2000-Sep-19 07:05
By: jhylton

Comment:
fails on Linux, too

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114775&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 17:06:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 09:06:10 -0700
Subject: [Python-bugs-list] [Bug #114598] Blue Screen crash, popen, Win98, Norton Antivirus 2000
Message-ID: <200009191606.JAA07981@bush.i.sourceforge.net>

Bug #114598, was updated on 2000-Sep-16 13:24
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 7
Summary: Blue Screen crash, popen, Win98, Norton Antivirus 2000

Details: On Windows 98, all of the os.popen*() functions cause a hard "blue screen" crash requiring a reboot, when Nortin Antivirus 2000 is installed and enabled. (Not with Norton Antivirus version 5, not on Windows 2000.)

While this is probably a bug in Norton Antivirus 2000, and we're already warning for this on the download page, that's not enough (we've seen at least one report in the newsgroup), and it would be good if we could somehow prevent it. Even a call to Py_FatalError is better than the blue screen, and raising os.error would be a *lot* better.

Follow-Ups:

Date: 2000-Sep-16 14:26
By: tim_one

Comment:
I don't know how to stop this.  Pissed away an hour trying to get help on the Symantec site, and eventually found a support board to which I posted this msg:

Product: Norton AntiVirus 2000 6.0 for Windows 95/98/NT
Supported operating system: Windows 98
Action: Run Another Program
Error Message: 
Summary: Blue screen crash

I develop the Windows version of the core Python language. Several reports of blue-screen death on Win98 have been traced to NAV2000.  Here's the exact msg from one such:

An exception 0E has occurred at 0028:C02AD9D0 in VxD IFSMGR(04) + 000050E4. This was called from 0028:C000B511 in VxD VMM(01) + 0000A511. It may be possible to continue normally.

This occurs whenever a user executes a member of the popen family of functions from within Python; for example, this Python program:

import os
p = os.popen("dir")

popen is a std C library function, poorly implemented by Microsoft, but not *that* poorly <wink>.

You can get our latest installer here:

http://www.pythonlabs.com/tech/python2.0/download.html

As the warning there says:

-----------------
Incompatibility warning: Norton Antivirus 2000 can cause blue screen crashes on Windows 98 when a function in the os.popen*() family is invoked. To prevent this problem, disable Norton Antivirus when using Python. (Confirmed on Windows 98 Second Edition with Norton Antivirus version 6.10.20. The same Norton Antivirus version doesn't have this
problem on Windows 2000. Norton Antivirus version 5 on Windows 98SE doesn't have this problem either.) 
-----------------

ActiveState is seeing the same problem with their derivative work ActivePython, as is PythonWare with their derivative work PythonWorks. So this affects a lot of people. A recent change to the implementation of a popular library module has made it acutely visible recently (didn't use to use popen, but does now).

A workaround would be nice. More importantly, how can I *detect* whether an affected version of NAV is in use, so that we can shut down Python gracefully with an appropriate message before executing any of the popen functions that throw NAV into blue-screen territory? We try to be a very user-friendly language, and we'll do anything to prevent a crash. Alas, right now I don't know how to stop it.

-------------------------------------------------------

Date: 2000-Sep-19 02:21
By: tim_one

Comment:
1. Sent Guido a small self-contained C program in the hope that it's enough to provoke the problem by itself.  Reassigned this bug to Guido since he has to tell me what happens with that next (then assign back to me).

2. That's because Symantec is being no help at all.  They suggest upgrading to NAV 2001(!).  If I can post a tiny C program, maybe it will embarrass then into doing something.  You can follow this soap opera at:

http://servicenews.symantec.com/cgi-bin/displayArticle.cgi?group=symantec.support.win9x.nortonantivirus2000.general&article=57765

-------------------------------------------------------

Date: 2000-Sep-19 09:06
By: gvanrossum

Comment:
Tim's little C program crashes in the same way as Python when NAV2000 is enabled. back to Tim...
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114598&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 17:23:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 09:23:20 -0700
Subject: [Python-bugs-list] [Bug #114775] test_minidom failing on Windows
Message-ID: <200009191623.JAA24843@delerium.i.sourceforge.net>

Bug #114775, was updated on 2000-Sep-18 21:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 9
Summary: test_minidom failing on Windows

Details: Was working until very recently:

C:\Code\python\dist\src\PCbuild>python ../lib/test/regrtest.py test_minidom

test_minidom
test test_minidom failed -- Writing: ' ', expected: '>'
1 test failed: test_minidom

C:\Code\python\dist\src\PCbuild>


Follow-Ups:

Date: 2000-Sep-18 21:43
By: tim_one

Comment:
Boosted at priority, as must work for release.
-------------------------------------------------------

Date: 2000-Sep-18 21:58
By: fdrake

Comment:
I get this on Linux-Mandrake 7.1:

test_minidom
test test_minidom failed -- Writing: ' ', expected: '\012'
1 test failed: test_minidom

Note that the test output contains reprs of instance objects using the <foo.MyClass instance at xxxx> form, and this is about as non-portable as it gets.  Just running the test script directly (not via regrtest.py) does not produce any failures.

The test needs to be modified to produce portable output, with non-portable output reserved for verbose mode.
-------------------------------------------------------

Date: 2000-Sep-19 07:05
By: jhylton

Comment:
fails on Linux, too

-------------------------------------------------------

Date: 2000-Sep-19 09:23
By: loewis

Comment:
Fixed with version 1.4 of test_minidom.py and output/test_minidom
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114775&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 17:52:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 09:52:56 -0700
Subject: [Python-bugs-list] [Bug #110648] performance-problem decoding quoted-printable (PR#340)
Message-ID: <200009191652.JAA26052@delerium.i.sourceforge.net>

Bug #110648, was updated on 2000-Jul-31 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Summary: performance-problem decoding quoted-printable (PR#340)

Details: Jitterbug-Id: 340
Submitted-By: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= <ragnark@vestdata.no>
Date: Fri, 26 May 2000 16:51:51 +0200
Version: None
OS: None

--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi

Problem on python 1.5.1 on linux 2.2.14aa6.

Decoding quoted-printable files using mimetools.decode is really slow.
The really strange thing is, that it appers to work a lot faster on
smaller files!

I put together a little test-program that reads blocks from a file, and
decodes them individually. (The output will not be 100% correct. The
point was just to test the performance). 

Results show the time it took to decode a 300k file with the diferent
block-sizes:
1k:	6.28 s
3k:	6.59 s
10k:	8.57 s
30k:	30.45 s
100k:	127.82 s
300k:	221.67 s

I looked in quopri.decode for clues about the problem, but could not
find any. Is there something _very_ wrong with my reasoning, or is
something wrong here?



-- 
Ragnar Kjørstad

--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="test.py"

#!/usr/bin/python
from mimetools import decode
from StringIO import StringIO
from sys import stdout, argv
from string import atoi
bsize=atoi(argv[1])
output=StringIO()
f=open("mail-test")
s=f.read(bsize)
while s:
	input=StringIO(s)
	decode(input, output, 'quoted-printable')
	s=f.read(bsize)
	stdout.write('.')
	stdout.flush()
stdout.write('done\n')

--7JfCtLOvnd9MIVvH--



====================================================================
Audit trail:
Tue Jul 11 08:25:57 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-19 09:52
By: loewis

Comment:
I can't reproduce the problem. On  sparc-sun-solaris2.6, Python 1.5.2 needs the same time for a 330k file, regardless of the block size.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110648&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 18:19:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 10:19:52 -0700
Subject: [Python-bugs-list] [Bug #110671] Tk-based widgets misbehave with dead keys (PR#376)
Message-ID: <200009191719.KAA27192@delerium.i.sourceforge.net>

Bug #110671, was updated on 2000-Jul-31 14:12
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 5
Summary: Tk-based widgets misbehave with dead keys (PR#376)

Details: Jitterbug-Id: 376
Submitted-By: fstajano@uk.research.att.com
Date: Thu, 29 Jun 2000 12:49:44 -0400 (EDT)
Version: 1.6a2
OS: Windows 98 and 2000


This is a problem of the underlying widget set and not of Idle itself, but Idle
is where I encountered it (I normally use Emacs), and since Python 1.6 is the
unicode version I suppose it's worth looking into anyway (what good is it to
have international chars if you can't input them ;-)).

If, on Windows, you use a keyboard layout with dead keys, such as "United States
- International", then Idle does not respond properly to dead keys. In
particular, double-quote comes out as single-quote; single-quote comes out as
space; and accented characters come out as non-accented.

The lack of support for the accented chars is a minor nuisance, but the problems
with quotes are a major one -- Idle is almost unusable under these
circumstances. Not as bad as Pythonwin, though, which just crashes.

[As you will know, the US-I keyboard defines things like single-quote and
double-quote as dead keys so that one can produce accents and umlauts
respectively by following the dead key with the appropriate vowel. To produce a
double-quote on its own, you have to press double-quote followed by space.]



====================================================================
Audit trail:
Tue Jul 11 08:24:21 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-28 00:37
By: effbot

Comment:
This is supposed to be fixed in Tk 8.3 and later; from the 8.3.0 changes document:

2000-02-08 (bug fix) fixed incorrect handling of CapsLock on Win9* and the use of dead keys on international keyboards (spjuth)

(haven't verified it yet, since 1.6's Tkinter causes my Win95 box to crash, no matter what Tk version I'm using)
-------------------------------------------------------

Date: 2000-Sep-19 10:19
By: loewis

Comment:
I can confirm that the problem occurs with 1.6a2 but is fixed in 2.0b1; likely due to the more recent Tk version.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110671&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 18:29:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 10:29:21 -0700
Subject: [Python-bugs-list] [Bug #110706] gcc error msg, 1.5.2, Slackware + threads (PR#44)
Message-ID: <200009191729.KAA27559@delerium.i.sourceforge.net>

Bug #110706, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Works For Me
Bug Group: Platform-specific
Priority: 4
Summary: gcc error msg, 1.5.2, Slackware + threads (PR#44)

Details: Jitterbug-Id: 44
Submitted-By: rene@kronos.szabinet.hu
Date: Sun, 1 Aug 1999 16:39:42 -0400 (EDT)
Version: 1.5.2
OS: Linux


Compile error with Python-1.5.2 on
Linux Slackware 4.0, kernel 2.2.10-ac8, gcc 2.7.2.3, make 3.76.1

./configure --prefix=/usr/local --with-threads && make
...
./socketmodule.c: In function `setipaddr':
./socketmodule.c:392: warning: passing arg 5 of `gethostbyname_r' from
incompatible pointer type
./socketmodule.c:392: too many arguments to function `gethostbyname_r'
./socketmodule.c:392: warning: assignment makes integer from pointer without a
cast
./socketmodule.c: In function `PySocket_gethostbyname_ex':
./socketmodule.c:1471: warning: passing arg 5 of `gethostbyname_r' from
incompatible pointer type
./socketmodule.c:1471: too many arguments to function `gethostbyname_r'
./socketmodule.c:1471: warning: assignment makes integer from pointer without a
cast
./socketmodule.c: In function `PySocket_gethostbyaddr':
./socketmodule.c:1534: warning: passing arg 7 of `gethostbyaddr_r' from
incompatible pointer type
./socketmodule.c:1534: too many arguments to function `gethostbyaddr_r'
./socketmodule.c:1534: warning: assignment makes integer from pointer without a
cast
make[1]: *** [socketmodule.o] Error 1
make: *** [Modules] Error 2



====================================================================
Audit trail:
Wed Aug 04 12:12:39 1999	guido	moved from incoming to platformbug
Mon Aug 30 12:37:34 1999	guido	changed notes
Mon Oct 25 15:15:46 1999	guido	changed notes

Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 22:50
By: tim_one

Comment:
Assigned to Fred for the heck of it.  Changed the "Summary" msg as the original "Compiler error" gave me an entirely wrong impression.
-------------------------------------------------------

Date: 2000-Sep-15 10:11
By: fdrake

Comment:
Sent a message to the submitter asking if this is still a problem with more recent Python releases; this sounds very much like a bug that's been squashed, but I don't have a Slackware Linux installation available for testing.
-------------------------------------------------------

Date: 2000-Sep-15 11:05
By: fdrake

Comment:
I cannot reproduce this with Slackware 7.0 (kernel 2.2.14 SMP; the version installed on the SourceForge compile farm).
-------------------------------------------------------

Date: 2000-Sep-17 11:36
By: fdrake

Comment:
Lowering priority since I can't reproduce this on the current version of Slackware (as installed on the SF compile farm).
-------------------------------------------------------

Date: 2000-Sep-19 10:29
By: fdrake

Comment:
Was not able to reach the submitter; mail eventually bounced back.
Closing this as "Works for Me" since I can't get any further information required to verify that this bug still exists.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110706&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 19:11:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 11:11:20 -0700
Subject: [Python-bugs-list] [Bug #110648] performance-problem decoding quoted-printable (PR#340)
Message-ID: <200009191811.LAA29176@delerium.i.sourceforge.net>

Bug #110648, was updated on 2000-Jul-31 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Summary: performance-problem decoding quoted-printable (PR#340)

Details: Jitterbug-Id: 340
Submitted-By: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= <ragnark@vestdata.no>
Date: Fri, 26 May 2000 16:51:51 +0200
Version: None
OS: None

--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi

Problem on python 1.5.1 on linux 2.2.14aa6.

Decoding quoted-printable files using mimetools.decode is really slow.
The really strange thing is, that it appers to work a lot faster on
smaller files!

I put together a little test-program that reads blocks from a file, and
decodes them individually. (The output will not be 100% correct. The
point was just to test the performance). 

Results show the time it took to decode a 300k file with the diferent
block-sizes:
1k:	6.28 s
3k:	6.59 s
10k:	8.57 s
30k:	30.45 s
100k:	127.82 s
300k:	221.67 s

I looked in quopri.decode for clues about the problem, but could not
find any. Is there something _very_ wrong with my reasoning, or is
something wrong here?



-- 
Ragnar Kjørstad

--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="test.py"

#!/usr/bin/python
from mimetools import decode
from StringIO import StringIO
from sys import stdout, argv
from string import atoi
bsize=atoi(argv[1])
output=StringIO()
f=open("mail-test")
s=f.read(bsize)
while s:
	input=StringIO(s)
	decode(input, output, 'quoted-printable')
	s=f.read(bsize)
	stdout.write('.')
	stdout.flush()
stdout.write('done\n')

--7JfCtLOvnd9MIVvH--



====================================================================
Audit trail:
Tue Jul 11 08:25:57 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-19 09:52
By: loewis

Comment:
I can't reproduce the problem. On  sparc-sun-solaris2.6, Python 1.5.2 needs the same time for a 330k file, regardless of the block size.
-------------------------------------------------------

Date: 2000-Sep-19 11:11
By: gvanrossum

Comment:
Can't reproduce it either. Note he's using Python 1.5.1. Maybe it was a buffering problem in StringIO there - quopri.py is using readline(). Barry, if you don't have another idea, just close it as Invalid.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110648&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 20:34:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 12:34:30 -0700
Subject: [Python-bugs-list] [Bug #114821] 2.0b1 IDLE "replace" dead broken
Message-ID: <200009191934.MAA32614@delerium.i.sourceforge.net>

Bug #114821, was updated on 2000-Sep-19 12:34
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: 2.0b1 IDLE "replace" dead broken

Details: Assigned to Guido since he wrote this code.  Looks shallow, so bounce it back to me if you're swamped.  Simply try using Edit -> Replace ...  This is typical:

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\PYTHON20\lib\lib-tk\Tkinter.py", line 1284, in __call__
    return apply(self.func, args)
  File "C:\Python20\Tools\idle\ReplaceDialog.py", line 58, in replace_it
    self.do_replace()
  File "C:\Python20\Tools\idle\ReplaceDialog.py", line 145, in do_replace
    new = re.pcre_expand(m, self.replvar.get())
AttributeError: pcre_expand


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114821&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 21:46:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 13:46:04 -0700
Subject: [Python-bugs-list] [Bug #114830] Writing of Unicode data not portable
Message-ID: <200009192046.NAA19017@bush.i.sourceforge.net>

Bug #114830, was updated on 2000-Sep-19 13:46
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Writing of Unicode data not portable

Details: In 2.0b1, writing a Unicode object to a socket has an outcome that depends on the endianness of the processor. This is highly undesirable,
and not documented either in the reference manuals. It also break backwards compatibility in hard-to-analyse ways, as the other end of the socket may react strangely when confronted with Python's internal representation of a Unicode object.

Since determination of an encoding must be an application decision, it seems best if attempts to write Unicode objects to sockets produce an exception. To some degree, the same criticism applies to binary files.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114830&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 21:52:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 13:52:04 -0700
Subject: [Python-bugs-list] [Bug #114821] 2.0b1 IDLE "replace" dead broken
Message-ID: <200009192052.NAA03203@delerium.i.sourceforge.net>

Bug #114821, was updated on 2000-Sep-19 12:34
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: 2.0b1 IDLE "replace" dead broken

Details: Assigned to Guido since he wrote this code.  Looks shallow, so bounce it back to me if you're swamped.  Simply try using Edit -> Replace ...  This is typical:

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\PYTHON20\lib\lib-tk\Tkinter.py", line 1284, in __call__
    return apply(self.func, args)
  File "C:\Python20\Tools\idle\ReplaceDialog.py", line 58, in replace_it
    self.do_replace()
  File "C:\Python20\Tools\idle\ReplaceDialog.py", line 145, in do_replace
    new = re.pcre_expand(m, self.replvar.get())
AttributeError: pcre_expand


Follow-Ups:

Date: 2000-Sep-19 13:52
By: gvanrossum

Comment:
Fixed by checkin 1.4 to ReplaceDialog.py.

Note that there's a missing API in the re module: expand a template when you have already found a match.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114821&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 21:59:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 13:59:54 -0700
Subject: [Python-bugs-list] [Bug #114830] Writing of Unicode data not portable
Message-ID: <200009192059.NAA03567@delerium.i.sourceforge.net>

Bug #114830, was updated on 2000-Sep-19 13:46
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: Writing of Unicode data not portable

Details: In 2.0b1, writing a Unicode object to a socket has an outcome that depends on the endianness of the processor. This is highly undesirable,
and not documented either in the reference manuals. It also break backwards compatibility in hard-to-analyse ways, as the other end of the socket may react strangely when confronted with Python's internal representation of a Unicode object.

Since determination of an encoding must be an application decision, it seems best if attempts to write Unicode objects to sockets produce an exception. To some degree, the same criticism applies to binary files.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114830&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 22:07:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 14:07:45 -0700
Subject: [Python-bugs-list] [Bug #113890] eval() fails with unicode string
Message-ID: <200009192107.OAA19810@bush.i.sourceforge.net>

Bug #113890, was updated on 2000-Sep-08 08:22
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: eval() fails with unicode string

Details: Python 2.0b1 (#3, Sep  6 2000, 12:34:06) 
[GCC 2.95.2 19991024 (release)] on sunos5
Type "copyright", "credits" or "license" for more information.
>>> eval("1+2)
  File "<stdin>", line 1
    eval("1+2)
             ^
SyntaxError: invalid token
>>> eval("1+2")
3
>>> eval(u"1+2")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: eval() argument 1 must be string or code object


Follow-Ups:

Date: 2000-Sep-08 08:35
By: lemburg

Comment:
It would be fairly straight forward to fix this by having
eval() and exec auto-convert the input to an 8-bit string
using the default encoding.

Should we proceed this way ?

-------------------------------------------------------

Date: 2000-Sep-19 14:07
By: lemburg

Comment:
exec and eval() now also accept Unicode as code parameter.

This is implemented by having the two APIs convert Unicode
to a string using the default encoding prior to processing the
code string.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113890&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 22:07:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 14:07:54 -0700
Subject: [Python-bugs-list] [Bug #110924] support Unicode for Python source code
Message-ID: <200009192107.OAA19824@bush.i.sourceforge.net>

Bug #110924, was updated on 2000-Aug-02 08:17
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 1
Summary: support Unicode for Python source code

Details: exec u"print 42"
doesn't work.

Follow-Ups:

Date: 2000-Aug-09 02:35
By: effbot

Comment:
python doesn't support 16-bit source code -- so what exactly do you want exec to do?
-------------------------------------------------------

Date: 2000-Aug-17 05:17
By: none

Comment:
That's exactly my point. Python should support Unicode
everywhere, in __str__ and __repr__, exec and eval, in open(), as a format for the source code (which would result in all variable names to be Unicode)...

Currenly working with Unicode (e.g. for XML) is a mess, because it's supported nowhere.

exec "a='ü'" seems to work and seems to treat the string as iso-8859-1 (or not at all)

-------------------------------------------------------

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 05:21
By: lemburg

Comment:
I don't think that the situation is that bad. You can't program
Python in Unicode, but this doesn't stop you from using it
in your Python programs.

Note that __str__ and __repr__ do support Unicode (it gets converted
to an 8-bit string using the default encoding).

There's currently not much need to have exec or eval() automatically
apply any conversion... you can always use str() around the argument
to make it support both 8-bit strings and Unicode.

-------------------------------------------------------

Date: 2000-Sep-16 15:18
By: bwarsaw

Comment:
Reassigning to Guido for final disposal, but I believe this should be marked either as "not a bug" or added to PEP 42.
-------------------------------------------------------

Date: 2000-Sep-16 19:51
By: gvanrossum

Comment:
There's an Accepted patch for this by Marc-Andre Lemburg.
Assigned to Marc-Andre so he can close the bug when he applies the patch.

(Marc-Andre: if you don't have time to apply the patch, let me know and I'll take care of it.)
-------------------------------------------------------

Date: 2000-Sep-19 14:07
By: lemburg

Comment:
exec and eval() now also accept Unicode as code parameter.

This is implemented by having the two APIs convert Unicode
to a string using the default encoding prior to processing the
code string.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110924&group_id=5470

From noreply@sourceforge.net  Tue Sep 19 22:34:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 14:34:59 -0700
Subject: [Python-bugs-list] [Bug #114746] dis module is not up todate in 2.0b1-#4
Message-ID: <200009192134.OAA04997@delerium.i.sourceforge.net>

Bug #114746, was updated on 2000-Sep-18 14:42
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: Works For Me
Bug Group: None
Priority: 1
Summary: dis module is not up todate in 2.0b1-#4

Details: While updating freeze I got an index error for an op
that was outside of the dis.opname list.


Follow-Ups:

Date: 2000-Sep-18 15:04
By: gvanrossum

Comment:
Please supply an example -- I don't have a problem using dis.py.
-------------------------------------------------------

Date: 2000-Sep-19 14:34
By: barry-scott

Comment:
I've failed to reproduce the problem with my edits to Freeze. (I got an other exception that not a problem in dis).

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114746&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 03:04:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 19:04:07 -0700
Subject: [Python-bugs-list] [Bug #114846] python20_d.dll missing
Message-ID: <200009200204.TAA31487@bush.i.sourceforge.net>

Bug #114846, was updated on 2000-Sep-19 19:04
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: python20_d.dll missing

Details: The file python20_d.dll is missing from the
win32-binary distribution.
side note: in python 1.5 this could be worked around
by linking to python15.lib manually. In 1.6 & 2.0 this
work around does not work.
(this is of course when python is embedded into a win32
application)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114846&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 03:13:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 19:13:49 -0700
Subject: [Python-bugs-list] [Bug #114847] Building Python fails due to readline problem
Message-ID: <200009200213.TAA31763@bush.i.sourceforge.net>

Bug #114847, was updated on 2000-Sep-19 19:13
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Building Python fails due to readline problem

Details: When I attempt to compile Python with the readline module enabled, I get the following error:

gcc  -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_sre.c
gcc  -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./readline.c
./readline.c: In function `initreadline':
./readline.c:503: `rl_library_version' undeclared (first use in this function)
./readline.c:503: (Each undeclared identifier is reported only once
./readline.c:503: for each function it appears in.)
*** Error code 1

Stop in /home/jpettit/dev/python/dist/src/Modules.
*** Error code 1

This is an OpenBSD 2.5 x86 system.  

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114847&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 03:18:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 19:18:36 -0700
Subject: [Python-bugs-list] [Bug #114847] Building Python fails due to readline problem
Message-ID: <200009200218.TAA31975@bush.i.sourceforge.net>

Bug #114847, was updated on 2000-Sep-19 19:13
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Building Python fails due to readline problem

Details: When I attempt to compile Python with the readline module enabled, I get the following error:

gcc  -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_sre.c
gcc  -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./readline.c
./readline.c: In function `initreadline':
./readline.c:503: `rl_library_version' undeclared (first use in this function)
./readline.c:503: (Each undeclared identifier is reported only once
./readline.c:503: for each function it appears in.)
*** Error code 1

Stop in /home/jpettit/dev/python/dist/src/Modules.
*** Error code 1

This is an OpenBSD 2.5 x86 system.  

Follow-Ups:

Date: 2000-Sep-19 19:18
By: jpettit

Comment:
I almost forgot: this is using the most current CVS snapshot.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114847&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 07:41:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Sep 2000 23:41:40 -0700
Subject: [Python-bugs-list] [Bug #114846] python20_d.dll missing
Message-ID: <200009200641.XAA24204@delerium.i.sourceforge.net>

Bug #114846, was updated on 2000-Sep-19 19:04
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: python20_d.dll missing

Details: The file python20_d.dll is missing from the
win32-binary distribution.
side note: in python 1.5 this could be worked around
by linking to python15.lib manually. In 1.6 & 2.0 this
work around does not work.
(this is of course when python is embedded into a win32
application)

Follow-Ups:

Date: 2000-Sep-19 23:41
By: tim_one

Comment:
Guido, I assigned this to you just to get your attention:  what do you think?  (MarkH, if you're listening, you too!)

C:\Code\python\dist\src\PCbuild>dir py*.dll

PYTHON20 DLL       692,285  09-19-00 10:14p python20.dll
PYTHON~1 DLL     1,138,751  09-19-00 10:14p python20_d.dll
         2 file(s)      1,831,036 bytes
         0 dir(s)        2,554.24 MB free

C:\Code\python\dist\src\PCbuild>

The debug DLL is a megabyte now, and I personally don't want to bloat the installer with it given that not one user in 1,000 will have any use for it.  Perhaps we could make it available as a separate download for experts?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114846&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 08:30:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 00:30:18 -0700
Subject: [Python-bugs-list] [Bug #113803] [2.0b1 NT4.0] printing non asci char causes idle to abort
Message-ID: <200009200730.AAA10053@bush.i.sourceforge.net>

Bug #113803, was updated on 2000-Sep-07 08:33
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: [2.0b1 NT4.0] printing non asci char causes idle to abort

Details: try:

alef = u'\u05d0'
print alef.encode('utf-8')

any enter after the last statement will cause idle to abort

on 'bare' python this does not cause any problem.

[tebeka@lycosmail.com]

Follow-Ups:

Date: 2000-Sep-07 15:04
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-12 15:13
By: gvanrossum

Comment:
Crash confirmed in IDLE on Win98SE.
Prints (expected) garbage and doesn't crash in command line on Win98SE.
No crash in IDLE or command line on Linux.

Tim, can you take a look with the VC debugger?

-------------------------------------------------------

Date: 2000-Sep-12 19:45
By: tim_one

Comment:
Changed group to platform-specific.

Note that this is a simpler test case w/ the same symptom:

print "\327\220"

Don't know why, do know that _tkinter.pyd and tk83.dll crap out w/ page faults at the end, assigned to Fredrik on the chance he's bumped into this before.  /F, bounce it back at me if it's unclear to you.
-------------------------------------------------------

Date: 2000-Sep-12 23:38
By: tim_one

Comment:
Bad news:  this doesn't always fail in the debugger (sometimes it just prints an alef glyph and nothing odd happens at all).

Better news:  it usually fails, and when it does it dies here (_tkinter.c):

static char *
AsString(PyObject *value, PyObject *tmp)
{
	if (PyString_Check(value))
		return PyString_AsString(value);
	else {
		PyObject *v = PyObject_Str(value);
		PyList_Append(tmp, v);
		Py_DECREF(v);
		return PyString_AsString(v);
	}
}

It's in the "else" branch, v is NULL, and the Py_DECREF expansion blows up with an access violation.  Py_ObjectStr certainly *can* return NULL, and I don't understand the intent of this code well enough to know why it believes that needn't be guarded against.

"value" at this point has type PyUnicode_Type.  For whatever reason, the debugger won't let me cast it to a PyUnicodeObject*.
-------------------------------------------------------

Date: 2000-Sep-20 00:30
By: micpro

Comment:
Crash confirmed for python 2.0 on Linux.
Segfault in _tkinter:267 when called from _tkinter.c:1260
Reason: string object expected, but unicode is given.
AsObj does treat this correctly, so this gets better after
changing line 1260
   Tcl_SetResult(Tkapp_Interp(self), AsString(res, tmp),
                 TCL_VOLATILE);

to
   Tcl_SetObjResult(Tkapp_Interp(self), AsObj(res));

After this change, idle does not segfault anymore and prints
alef correctly, but it still behaves strange after printing. it.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113803&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 14:21:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 06:21:21 -0700
Subject: [Python-bugs-list] [Bug #114846] python20_d.dll missing
Message-ID: <200009201321.GAA22621@bush.i.sourceforge.net>

Bug #114846, was updated on 2000-Sep-19 19:04
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Wont Fix
Bug Group: Platform-specific
Priority: 5
Summary: python20_d.dll missing

Details: The file python20_d.dll is missing from the
win32-binary distribution.
side note: in python 1.5 this could be worked around
by linking to python15.lib manually. In 1.6 & 2.0 this
work around does not work.
(this is of course when python is embedded into a win32
application)

Follow-Ups:

Date: 2000-Sep-19 23:41
By: tim_one

Comment:
Guido, I assigned this to you just to get your attention:  what do you think?  (MarkH, if you're listening, you too!)

C:\Code\python\dist\src\PCbuild>dir py*.dll

PYTHON20 DLL       692,285  09-19-00 10:14p python20.dll
PYTHON~1 DLL     1,138,751  09-19-00 10:14p python20_d.dll
         2 file(s)      1,831,036 bytes
         0 dir(s)        2,554.24 MB free

C:\Code\python\dist\src\PCbuild>

The debug DLL is a megabyte now, and I personally don't want to bloat the installer with it given that not one user in 1,000 will have any use for it.  Perhaps we could make it available as a separate download for experts?

-------------------------------------------------------

Date: 2000-Sep-20 06:21
By: gvanrossum

Comment:
Sorry, I won't fix this. The debug DLL is huge, and you'd need more than just python20_d.dll -- you'd need the _d.pyd version of all the extension modules. This would just be a waste of installer size.

If you have a need for the debug DLLs, you should download the sources and rebuild with debug mode from source. After all you must be debugging something so you must already be using VC++ so rebuilding won't be a problem; see PCbuild/readme.txt for elaborate instructions.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114846&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 14:25:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 06:25:19 -0700
Subject: [Python-bugs-list] [Bug #114847] Building Python fails due to readline problem
Message-ID: <200009201325.GAA22792@bush.i.sourceforge.net>

Bug #114847, was updated on 2000-Sep-19 19:13
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Building Python fails due to readline problem

Details: When I attempt to compile Python with the readline module enabled, I get the following error:

gcc  -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_sre.c
gcc  -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./readline.c
./readline.c: In function `initreadline':
./readline.c:503: `rl_library_version' undeclared (first use in this function)
./readline.c:503: (Each undeclared identifier is reported only once
./readline.c:503: for each function it appears in.)
*** Error code 1

Stop in /home/jpettit/dev/python/dist/src/Modules.
*** Error code 1

This is an OpenBSD 2.5 x86 system.  

Follow-Ups:

Date: 2000-Sep-19 19:18
By: jpettit

Comment:
I almost forgot: this is using the most current CVS snapshot.
-------------------------------------------------------

Date: 2000-Sep-20 06:25
By: gvanrossum

Comment:
Could you try this again after adding

extern char *rl_library_version;

to readline.c, just after

extern Function *rl_event_hook;

(I'd give you a diff but the SourceForge CVS site appears down today.) 

If this works for you, I'll check it in (presuming SourceForge comes back online :-).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114847&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 18:17:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 10:17:26 -0700
Subject: [Python-bugs-list] [Bug #114847] Building Python fails due to readline problem
Message-ID: <200009201717.KAA31684@bush.i.sourceforge.net>

Bug #114847, was updated on 2000-Sep-19 19:13
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Building Python fails due to readline problem

Details: When I attempt to compile Python with the readline module enabled, I get the following error:

gcc  -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_sre.c
gcc  -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./readline.c
./readline.c: In function `initreadline':
./readline.c:503: `rl_library_version' undeclared (first use in this function)
./readline.c:503: (Each undeclared identifier is reported only once
./readline.c:503: for each function it appears in.)
*** Error code 1

Stop in /home/jpettit/dev/python/dist/src/Modules.
*** Error code 1

This is an OpenBSD 2.5 x86 system.  

Follow-Ups:

Date: 2000-Sep-19 19:18
By: jpettit

Comment:
I almost forgot: this is using the most current CVS snapshot.
-------------------------------------------------------

Date: 2000-Sep-20 06:25
By: gvanrossum

Comment:
Could you try this again after adding

extern char *rl_library_version;

to readline.c, just after

extern Function *rl_event_hook;

(I'd give you a diff but the SourceForge CVS site appears down today.) 

If this works for you, I'll check it in (presuming SourceForge comes back online :-).
-------------------------------------------------------

Date: 2000-Sep-20 10:17
By: jpettit

Comment:
Yes, that fixed the problem.  I'm still having problems compiling under OpenBSD 2.5, but they are not related to readline, so I will open a new bug report.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114847&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 18:24:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 10:24:27 -0700
Subject: [Python-bugs-list] [Bug #114900] Undefined Symbols When Building for OpenBSD 2.5
Message-ID: <200009201724.KAA32031@bush.i.sourceforge.net>

Bug #114900, was updated on 2000-Sep-20 10:24
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Undefined Symbols When Building for OpenBSD 2.5

Details: I receive the following errors when I attempt to build Python for OpenBSD 2.5:

cd Modules;  make OPT="-g -O2" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
main.c:115: Undefined symbol `_Py_FatalError' referenced from text segment
main.c:125: Undefined symbol `_Py_DebugFlag' referenced from text segment
main.c:130: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:134: Undefined symbol `_Py_OptimizeFlag' referenced from text segment
main.c:138: Undefined symbol `_Py_NoSiteFlag' referenced from text segment
main.c:142: Undefined symbol `_Py_TabcheckFlag' referenced from text segment
main.c:150: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:158: Undefined symbol `_Py_UnicodeFlag' referenced from text segment
main.c:208: Undefined symbol `_Py_FdIsInteractive' referenced from text segment
main.c:232: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:246: Undefined symbol `_Py_SetProgramName' referenced from text segment
main.c:247: Undefined symbol `_Py_Initialize' referenced from text segment
main.c:249: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:251: Undefined symbol `_Py_GetPlatform' referenced from text segment
main.c:251: Undefined symbol `_Py_GetVersion' referenced from text segment
main.c:261: Undefined symbol `_PySys_SetArgv' referenced from text segment
main.c:266: Undefined symbol `_PyImport_ImportModule' referenced from text segment
main.c:268: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:274: Undefined symbol `_PyRun_SimpleString' referenced from text segment
main.c:283: Undefined symbol `_PyRun_SimpleFile' referenced from text segment
main.c:284: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:289: Undefined symbol `_PyRun_AnyFileEx' referenced from text segment
main.c:297: Undefined symbol `_PyRun_AnyFile' referenced from text segment
main.c:299: Undefined symbol `_Py_Finalize' referenced from text segment
*** Error code 1

Stop in /home/jpettit/dev/python/dist/src/Modules.
*** Error code 1


This is with a snapshot of the CVS tree from yesterday afternoon.  I tar'd up the directory and built it under Linux fine, so I believe this is particular to OpenBSD.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114900&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 20:23:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 12:23:46 -0700
Subject: [Python-bugs-list] [Bug #114846] python20_d.dll missing
Message-ID: <200009201923.MAA19917@delerium.i.sourceforge.net>

Bug #114846, was updated on 2000-Sep-19 19:04
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Wont Fix
Bug Group: Platform-specific
Priority: 5
Summary: python20_d.dll missing

Details: The file python20_d.dll is missing from the
win32-binary distribution.
side note: in python 1.5 this could be worked around
by linking to python15.lib manually. In 1.6 & 2.0 this
work around does not work.
(this is of course when python is embedded into a win32
application)

Follow-Ups:

Date: 2000-Sep-19 23:41
By: tim_one

Comment:
Guido, I assigned this to you just to get your attention:  what do you think?  (MarkH, if you're listening, you too!)

C:\Code\python\dist\src\PCbuild>dir py*.dll

PYTHON20 DLL       692,285  09-19-00 10:14p python20.dll
PYTHON~1 DLL     1,138,751  09-19-00 10:14p python20_d.dll
         2 file(s)      1,831,036 bytes
         0 dir(s)        2,554.24 MB free

C:\Code\python\dist\src\PCbuild>

The debug DLL is a megabyte now, and I personally don't want to bloat the installer with it given that not one user in 1,000 will have any use for it.  Perhaps we could make it available as a separate download for experts?

-------------------------------------------------------

Date: 2000-Sep-20 06:21
By: gvanrossum

Comment:
Sorry, I won't fix this. The debug DLL is huge, and you'd need more than just python20_d.dll -- you'd need the _d.pyd version of all the extension modules. This would just be a waste of installer size.

If you have a need for the debug DLLs, you should download the sources and rebuild with debug mode from source. After all you must be debugging something so you must already be using VC++ so rebuilding won't be a problem; see PCbuild/readme.txt for elaborate instructions.
-------------------------------------------------------

Date: 2000-Sep-20 12:23
By: PSYKOtron

Comment:
I would appreciate it if you can add it into a seperate installer for experts. At the moment I have to compile
all of python, and redistribute all the debug and non-debug lib's and dll's to a couple people responsible for debugging my program. Basicly I used to use the windows installer for the debuggers, now I have to make my own, and
install it manually to each programmer's system.
I believe linux distributions solved this problem by releasing: somelib-1.0 && somelib-1.0-dev
:)
Thanks for all your hard work in python... its helped *a lot* in my project.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114846&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 20:38:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 12:38:55 -0700
Subject: [Python-bugs-list] [Bug #113760] 2.0b1: _xmlplus does not allow site xml to override Lib/xml
Message-ID: <200009201938.MAA20568@delerium.i.sourceforge.net>

Bug #113760, was updated on 2000-Sep-06 16:53
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: 3rd Party
Priority: 7
Summary: 2.0b1: _xmlplus does not allow site xml to override Lib/xml

Details: _xmlplus is represented as a means of overriding the new standard lib xml package with a user-supplied xml package, such as the one from XML-SIG ("There's a special feature whereby a user-installed package named _xmlplus overrides the standard xmlpackage; this is intended to give the XML SIG a hook to distribute backwards-compatible updates to the standard xml package." - quote from News on BeOpen site). While this has _some_ effect, it does not work as described. Under 2.0b1, code using the xml package from the XML-SIG (installed in site-packages) will only work if the new standard xml package in lib is renamed or removed. If used with the new standard xml package, imports such as
from xml.sax import saxexts
fail. If the _xmlplus hook is used (by renaming site-packages/xml to site-packages/_xmlplus or using a symlink), the imports succeed, but later the code fails with a message stating that no parsers can be found. 

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-07 16:12
By: mfavas

Comment:
Martin v. Loewis has justed posted a link on xml-sig to a patch for the "no parsers can be found" problem. I've applied the patch (by hand - "patch" failed) and all seems OK. Custom, tricky ways of finding/doing imports abound... Wasn't there some talk of tidying-up imports and import hooks? (MvL's patch is at http://sourceforge.net/patch/?func=detailpatch&patch_id=101444&group_id=6473 )
- Mark
-------------------------------------------------------

Date: 2000-Sep-07 16:17
By: mfavas

Comment:
Martin v. Loewis has justed posted a link on xml-sig to a patch for the "no parsers can be found" problem. I've applied the patch (by hand - "patch" failed) and all seems OK. Custom, tricky ways of finding/doing imports abound... Wasn't there some talk of tidying-up imports and import hooks? (MvL's patch is at http://sourceforge.net/patch/?func=detailpatch&patch_id=101444&group_id=6473 )
- Mark
-------------------------------------------------------

Date: 2000-Sep-17 04:03
By: loewis

Comment:
The patch to fix this problem is now in the PyXML CVS tree.
-------------------------------------------------------

Date: 2000-Sep-20 12:38
By: loewis

Comment:
Fixed in PyXML 0.6.0, available from http://sourceforge.net/projects/pyxml.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113760&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 20:47:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 12:47:47 -0700
Subject: [Python-bugs-list] [Bug #113795] IDLE 0.6 with Python 2.0b1 doesn't handle chinese characters
Message-ID: <200009201947.MAA20934@delerium.i.sourceforge.net>

Bug #113795, was updated on 2000-Sep-07 06:49
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: IDLE 0.6 with Python 2.0b1 doesn't handle chinese characters

Details: I just switched from 1.5.2 to 2.0b1 on W2K/Simplified Chinese version. I used to be able to input chinese characters directly into IDLE, and access violations did happen quite often. Now with 2.0b1, I can't even input chinese characters into the IDLE window anymore:IDLE automatically changed chinese characters into illegible stuff; it's the same when I copy from a text editor and paste into the IDLE window. I guess it's related to the induction of unicode support in 2.0, but is there a workaround I should know, or I should switch back to 1.5.2, or it's a bug worth fixing?

Thanks.


Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 23:13
By: tim_one

Comment:
Assigned to Fredrik, because Swedes have an uncanny intuition about how IDLE and Tk work in the presence of characters I can't get at <0.9 wink>.  Boosted the priority because it sounds like a legit practical problem.
-------------------------------------------------------

Date: 2000-Sep-20 12:47
By: loewis

Comment:
I can reproduce the problem by installing a Russion or Arabic keyboard layout on Win2k; typing into an Entry or Text widget displays Latin-1 characters. I can observe the same problem with a plain 8.3 wish, so it appears to be a bug in Tk - which apparently truncates characters on input. So I propose to close this as 3rd Party/Later, and recategorize it as Tkinter.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113795&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 20:55:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 12:55:00 -0700
Subject: [Python-bugs-list] [Bug #114900] Undefined Symbols When Building for OpenBSD 2.5
Message-ID: <200009201955.MAA21206@delerium.i.sourceforge.net>

Bug #114900, was updated on 2000-Sep-20 10:24
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Undefined Symbols When Building for OpenBSD 2.5

Details: I receive the following errors when I attempt to build Python for OpenBSD 2.5:

cd Modules;  make OPT="-g -O2" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
main.c:115: Undefined symbol `_Py_FatalError' referenced from text segment
main.c:125: Undefined symbol `_Py_DebugFlag' referenced from text segment
main.c:130: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:134: Undefined symbol `_Py_OptimizeFlag' referenced from text segment
main.c:138: Undefined symbol `_Py_NoSiteFlag' referenced from text segment
main.c:142: Undefined symbol `_Py_TabcheckFlag' referenced from text segment
main.c:150: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:158: Undefined symbol `_Py_UnicodeFlag' referenced from text segment
main.c:208: Undefined symbol `_Py_FdIsInteractive' referenced from text segment
main.c:232: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:246: Undefined symbol `_Py_SetProgramName' referenced from text segment
main.c:247: Undefined symbol `_Py_Initialize' referenced from text segment
main.c:249: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:251: Undefined symbol `_Py_GetPlatform' referenced from text segment
main.c:251: Undefined symbol `_Py_GetVersion' referenced from text segment
main.c:261: Undefined symbol `_PySys_SetArgv' referenced from text segment
main.c:266: Undefined symbol `_PyImport_ImportModule' referenced from text segment
main.c:268: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:274: Undefined symbol `_PyRun_SimpleString' referenced from text segment
main.c:283: Undefined symbol `_PyRun_SimpleFile' referenced from text segment
main.c:284: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:289: Undefined symbol `_PyRun_AnyFileEx' referenced from text segment
main.c:297: Undefined symbol `_PyRun_AnyFile' referenced from text segment
main.c:299: Undefined symbol `_Py_Finalize' referenced from text segment
*** Error code 1

Stop in /home/jpettit/dev/python/dist/src/Modules.
*** Error code 1


This is with a snapshot of the CVS tree from yesterday afternoon.  I tar'd up the directory and built it under Linux fine, so I believe this is particular to OpenBSD.

Follow-Ups:

Date: 2000-Sep-20 12:55
By: loewis

Comment:
Can you check whether pythonrun.o got archived into libpython2.0.a
(ar tv libpython2.0.a), and whether Py_FatalError is exported from pythonrun.o (nm libpython2.0.a and nm pythonrun.o)?

Also, should building the library invoke ranlib on your system? Did it?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114900&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 21:06:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 13:06:16 -0700
Subject: [Python-bugs-list] [Bug #114900] Undefined Symbols When Building for OpenBSD 2.5
Message-ID: <200009202006.NAA21679@delerium.i.sourceforge.net>

Bug #114900, was updated on 2000-Sep-20 10:24
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Undefined Symbols When Building for OpenBSD 2.5

Details: I receive the following errors when I attempt to build Python for OpenBSD 2.5:

cd Modules;  make OPT="-g -O2" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
main.c:115: Undefined symbol `_Py_FatalError' referenced from text segment
main.c:125: Undefined symbol `_Py_DebugFlag' referenced from text segment
main.c:130: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:134: Undefined symbol `_Py_OptimizeFlag' referenced from text segment
main.c:138: Undefined symbol `_Py_NoSiteFlag' referenced from text segment
main.c:142: Undefined symbol `_Py_TabcheckFlag' referenced from text segment
main.c:150: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:158: Undefined symbol `_Py_UnicodeFlag' referenced from text segment
main.c:208: Undefined symbol `_Py_FdIsInteractive' referenced from text segment
main.c:232: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:246: Undefined symbol `_Py_SetProgramName' referenced from text segment
main.c:247: Undefined symbol `_Py_Initialize' referenced from text segment
main.c:249: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:251: Undefined symbol `_Py_GetPlatform' referenced from text segment
main.c:251: Undefined symbol `_Py_GetVersion' referenced from text segment
main.c:261: Undefined symbol `_PySys_SetArgv' referenced from text segment
main.c:266: Undefined symbol `_PyImport_ImportModule' referenced from text segment
main.c:268: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:274: Undefined symbol `_PyRun_SimpleString' referenced from text segment
main.c:283: Undefined symbol `_PyRun_SimpleFile' referenced from text segment
main.c:284: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:289: Undefined symbol `_PyRun_AnyFileEx' referenced from text segment
main.c:297: Undefined symbol `_PyRun_AnyFile' referenced from text segment
main.c:299: Undefined symbol `_Py_Finalize' referenced from text segment
*** Error code 1

Stop in /home/jpettit/dev/python/dist/src/Modules.
*** Error code 1


This is with a snapshot of the CVS tree from yesterday afternoon.  I tar'd up the directory and built it under Linux fine, so I believe this is particular to OpenBSD.

Follow-Ups:

Date: 2000-Sep-20 12:55
By: loewis

Comment:
Can you check whether pythonrun.o got archived into libpython2.0.a
(ar tv libpython2.0.a), and whether Py_FatalError is exported from pythonrun.o (nm libpython2.0.a and nm pythonrun.o)?

Also, should building the library invoke ranlib on your system? Did it?
-------------------------------------------------------

Date: 2000-Sep-20 13:06
By: jpettit

Comment:
No, "pythonrun.o" was not archived into "libpython2.0.a".  When I run the "nm" command and grep for "Py_FatalError", I get the following:

    [jpettit@bastion src]$ nm libpython2.0.a |grep Py_FatalError
         U _Py_FatalError
         U _Py_FatalError
[jpettit@bastion src]$ nm Python/pythonrun.o |grep Py_FatalError
000019dc T _Py_FatalError


Yes, "ranlib" was invoked a few lines before the compiler croaked:

mv -f buildno1 buildno
gcc -c -g -O2 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno`  ./Modules/getbuildinfo.c
ar cr libpython2.0.a getbuildinfo.o
ranlib libpython2.0.a
true
cd Modules;  make OPT="-g -O2" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
main.c:115: Undefined symbol `_Py_FatalError' referenced from text segment
...etc, etc...
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114900&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 21:27:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 13:27:42 -0700
Subject: [Python-bugs-list] [Bug #114847] Building Python fails due to readline problem
Message-ID: <200009202027.NAA22650@delerium.i.sourceforge.net>

Bug #114847, was updated on 2000-Sep-19 19:13
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Building Python fails due to readline problem

Details: When I attempt to compile Python with the readline module enabled, I get the following error:

gcc  -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_sre.c
gcc  -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./readline.c
./readline.c: In function `initreadline':
./readline.c:503: `rl_library_version' undeclared (first use in this function)
./readline.c:503: (Each undeclared identifier is reported only once
./readline.c:503: for each function it appears in.)
*** Error code 1

Stop in /home/jpettit/dev/python/dist/src/Modules.
*** Error code 1

This is an OpenBSD 2.5 x86 system.  

Follow-Ups:

Date: 2000-Sep-19 19:18
By: jpettit

Comment:
I almost forgot: this is using the most current CVS snapshot.
-------------------------------------------------------

Date: 2000-Sep-20 06:25
By: gvanrossum

Comment:
Could you try this again after adding

extern char *rl_library_version;

to readline.c, just after

extern Function *rl_event_hook;

(I'd give you a diff but the SourceForge CVS site appears down today.) 

If this works for you, I'll check it in (presuming SourceForge comes back online :-).
-------------------------------------------------------

Date: 2000-Sep-20 10:17
By: jpettit

Comment:
Yes, that fixed the problem.  I'm still having problems compiling under OpenBSD 2.5, but they are not related to readline, so I will open a new bug report.
-------------------------------------------------------

Date: 2000-Sep-20 13:27
By: gvanrossum

Comment:
Fixed by adding a declaration for rl_library_version.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114847&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 21:33:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 13:33:24 -0700
Subject: [Python-bugs-list] [Bug #110610] .pyc writing/reading race condition (PR#189)
Message-ID: <200009202033.NAA22899@delerium.i.sourceforge.net>

Bug #110610, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 1
Summary: .pyc writing/reading race condition (PR#189)

Details: Jitterbug-Id: 189
Submitted-By: gudo@python.org
Date: Mon, 24 Jan 2000 14:27:24 -0500 (EST)
Version: 1.5.2
OS: any


Patrick Miller reminded me that there's still a race condition in the reading
and writing of .pyc files.  If two processes decide to write the .pyc, and
a third reads the header after the first complete but before the second
starts, but reads the rest of the file after the second starts but before it
is done, the third can read corrupt data (and won't fall back to reading the
.py source).

Solution: when writing the .pyc file, (1) unlink the file before writing,
(2) use open() with the Unix flags that fail creation if the file exists
(and then just treat it like any open failure when writing the .pyc file).



====================================================================
Audit trail:
Mon Jan 24 14:28:42 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-10 11:52
By: gvanrossum

Comment:
No time to fix this now...
-------------------------------------------------------

Date: 2000-Sep-07 15:02
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-20 13:33
By: gvanrossum

Comment:
Fixed as suggested in my last comment; using O_EXCL when opening the file (on Unix).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110610&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 21:39:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 13:39:21 -0700
Subject: [Python-bugs-list] [Bug #110676] fd.readlines() hangs (via popen3) (PR#385)
Message-ID: <200009202039.NAA23144@delerium.i.sourceforge.net>

Bug #110676, was updated on 2000-Jul-31 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: fd.readlines() hangs (via popen3) (PR#385)

Details: Jitterbug-Id: 385
Submitted-By: aron@gweep.net
Date: Tue,  4 Jul 2000 19:07:55 -0400 (EDT)
Version: 1.5.2
OS: Red Hat Linux 6.1 (2.1.12-20)


The following scripts cause a hang at the denoted line. To execute
this code, copy the first bit to master.py and the second to slave.py
(both should be in the same directory). Then, "cd" to that directory
and "python master.py".

Manually killing the program is necessary.

This script has also been tested on a Solaris 5.7 box and worked.

---master.py---
import popen2

r,w,e = popen2.popen3 ( 'python slave.py' )
r.readlines() # Hangs here
e.readlines()
r.close()
e.close()
w.close()

---end---

---slave.py---
import sys

e = sys.stderr.write
w = sys.stdout.write

e(400*'this is a test\n')
w(400*'this is another test\n')
---end---



====================================================================
Audit trail:
Tue Jul 11 08:24:23 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-20 13:39
By: loewis

Comment:
That is a bug in the application code. The slave tries to write 6000 bytes to stderr, and blocks after writing 4096 (number measured on Linux, more generally, after _PC_PIPE_BUF bytes). 
The server starts reading on stdin, and blocks also, so you get a deadlock.
The proper solution is to use
import popen2

r,w,e = popen2.popen3 ( 'python slave.py' )
e.readlines()
r.readlines()
r.close()
e.close()
w.close()

as the server, and 
import sys,posix

e = sys.stderr.write
w = sys.stdout.write

e(400*'this is a test\n')
posix.close(2)
w(400*'this is another test\n')

as the slave. Notice that stderr must be closed after writing all data, or readlines won't return. Also notice that posix.close must be used, as sys.stderr.close() won't close stderr (apparently due to concerns that assigning to sys.stderr will silently close is, so no further errors can be printed).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110676&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 21:42:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 13:42:05 -0700
Subject: [Python-bugs-list] [Bug #114290] search_for_prefix failure on relative path
Message-ID: <200009202042.NAA23292@delerium.i.sourceforge.net>

Bug #114290, was updated on 2000-Sep-12 14:38
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: search_for_prefix failure on relative path

Details: The code in getpath.c fails in Step 3 (search for the libraries using the argv0 path) when python is invoked with a relative path.  The search code should be able to join the relative path with the current working directory and find the landmark file.


Follow-Ups:

Date: 2000-Sep-12 19:20
By: fdrake

Comment:
Barry, didn't you write most of the current code to locate the installation?  If not, assign it to whoever did.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114290&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 22:27:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 14:27:06 -0700
Subject: [Python-bugs-list] [Bug #114923] ToolTip not showing text on AIX 4.3
Message-ID: <200009202127.OAA09113@bush.i.sourceforge.net>

Bug #114923, was updated on 2000-Sep-20 14:27
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: ToolTip not showing text on AIX 4.3

Details: IDLE0.6 runs nicely on AIX except that the tip text itself does not show when the pop up box appears. The box seems to be sized properly but is blank.

-Robin Friedrich

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114923&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 22:46:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 14:46:32 -0700
Subject: [Python-bugs-list] [Bug #114410] 'make tests' fails with thread error on OpenBSD 2.7
Message-ID: <200009202146.OAA25611@delerium.i.sourceforge.net>

Bug #114410, was updated on 2000-Sep-14 02:24
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: 'make tests' fails with thread error on OpenBSD 2.7

Details: Using the latest CVS version of Python, the output from a pass of regrtest follows. It may be an OpenBSD problem, in which case if someone can explain it to me I will sendbug it to the OpenBSD people instead.

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
test_grammar
test_opcodes
test_operations
test_builtin
test_exceptions
test_types
test_MimeWriter
test_al
test test_al skipped --  No module named al
test_array
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test_binascii
test_binhex
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cgi
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test test_fcntl skipped --  No module named FCNTL
test_file
test_fork1
test_format
test_gc
gc: collectable <list 0x36e46c>
gc: collectable <dictionary 0x3d568c>
gc: collectable <list 0x36e46c>
gc: collectable <tuple 0x36e48c>
gc: collectable <class 0x3d570c>
gc: collectable <dictionary 0x3d56cc>
gc: collectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d574c>
gc: collectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d578c>
gc: collectable <instance method 0x25e34c>
gc: collectable <B instance at 0x36e4cc>
gc: collectable <dictionary 0x3d58cc>
gc: uncollectable <dictionary 0x3d584c>
gc: uncollectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d57cc>
gc: collectable <function 0x3d590c>
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test_gl
test test_gl skipped --  No module named gl
test_grp
pid 4207: Fatal error '_libc_private_storage_lock' at line 14 in file /usr/src/lib/libc_r/thread/thread_storage.c (errno = 2)
Abort (core dumped) 
*** Error code 134

Stop in /tmp/python/dist/src (line 212 of Makefile).


Follow-Ups:

Date: 2000-Sep-14 02:34
By: jribbens

Comment:
Oh, if you do './configure --without-threads' then the problem is avoided, of course. 'make tests' then gives:

74 tests OK.
26 tests skipped: test_al test_audioop test_cd test_cl test_crypt test_dbm test_dl test_fcntl test_fork1 test_gdbm test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev test_minidom test_nis test_pty test_pyexpat test_rgbimg test_sunaudiodev test_thread test_timing test_winreg test_winsound test_zlib

But presumably, since Python 2 has threads enabled by default, something else needs to be done ;-)
-------------------------------------------------------

Date: 2000-Sep-16 10:04
By: gvanrossum

Comment:
I don't have an OpenBSD system to debug this myself. I have access to FreeBSD 4.1 which does not have this problem. Perhaps you can try to debug this some more yourself?

If it's decided that this is a bug in OpenBSD (are you using the latest version?), please let us know so we can close this bug report.
-------------------------------------------------------

Date: 2000-Sep-20 14:46
By: jribbens

Comment:
On further investigation, it appears that the problem only occurs if test_fork1 is run at some point before test_grp. 

I'm trying to write some C code to perform similar operations as running test_fork1 followed by test_grp, but I'm getting confused by the fact that pthread seems to cancel all threads on a fork(), but this doesn't happen when test_fork1 forks.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114410&group_id=5470

From noreply@sourceforge.net  Wed Sep 20 23:28:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 15:28:49 -0700
Subject: [Python-bugs-list] [Bug #114410] 'make tests' fails with thread error on OpenBSD 2.7
Message-ID: <200009202228.PAA11447@bush.i.sourceforge.net>

Bug #114410, was updated on 2000-Sep-14 02:24
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: 'make tests' fails with thread error on OpenBSD 2.7

Details: Using the latest CVS version of Python, the output from a pass of regrtest follows. It may be an OpenBSD problem, in which case if someone can explain it to me I will sendbug it to the OpenBSD people instead.

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
test_grammar
test_opcodes
test_operations
test_builtin
test_exceptions
test_types
test_MimeWriter
test_al
test test_al skipped --  No module named al
test_array
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test_binascii
test_binhex
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cgi
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test test_fcntl skipped --  No module named FCNTL
test_file
test_fork1
test_format
test_gc
gc: collectable <list 0x36e46c>
gc: collectable <dictionary 0x3d568c>
gc: collectable <list 0x36e46c>
gc: collectable <tuple 0x36e48c>
gc: collectable <class 0x3d570c>
gc: collectable <dictionary 0x3d56cc>
gc: collectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d574c>
gc: collectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d578c>
gc: collectable <instance method 0x25e34c>
gc: collectable <B instance at 0x36e4cc>
gc: collectable <dictionary 0x3d58cc>
gc: uncollectable <dictionary 0x3d584c>
gc: uncollectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d57cc>
gc: collectable <function 0x3d590c>
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test_gl
test test_gl skipped --  No module named gl
test_grp
pid 4207: Fatal error '_libc_private_storage_lock' at line 14 in file /usr/src/lib/libc_r/thread/thread_storage.c (errno = 2)
Abort (core dumped) 
*** Error code 134

Stop in /tmp/python/dist/src (line 212 of Makefile).


Follow-Ups:

Date: 2000-Sep-14 02:34
By: jribbens

Comment:
Oh, if you do './configure --without-threads' then the problem is avoided, of course. 'make tests' then gives:

74 tests OK.
26 tests skipped: test_al test_audioop test_cd test_cl test_crypt test_dbm test_dl test_fcntl test_fork1 test_gdbm test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev test_minidom test_nis test_pty test_pyexpat test_rgbimg test_sunaudiodev test_thread test_timing test_winreg test_winsound test_zlib

But presumably, since Python 2 has threads enabled by default, something else needs to be done ;-)
-------------------------------------------------------

Date: 2000-Sep-16 10:04
By: gvanrossum

Comment:
I don't have an OpenBSD system to debug this myself. I have access to FreeBSD 4.1 which does not have this problem. Perhaps you can try to debug this some more yourself?

If it's decided that this is a bug in OpenBSD (are you using the latest version?), please let us know so we can close this bug report.
-------------------------------------------------------

Date: 2000-Sep-20 14:46
By: jribbens

Comment:
On further investigation, it appears that the problem only occurs if test_fork1 is run at some point before test_grp. 

I'm trying to write some C code to perform similar operations as running test_fork1 followed by test_grp, but I'm getting confused by the fact that pthread seems to cancel all threads on a fork(), but this doesn't happen when test_fork1 forks.
-------------------------------------------------------

Date: 2000-Sep-20 15:28
By: jribbens

Comment:
It's an OpenBSD problem - setgrent aborts if a thread has been created. You can close this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114410&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 00:54:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 16:54:34 -0700
Subject: [Python-bugs-list] [Bug #114923] ToolTip not showing text on AIX 4.3
Message-ID: <200009202354.QAA32578@delerium.i.sourceforge.net>

Bug #114923, was updated on 2000-Sep-20 14:27
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: ToolTip not showing text on AIX 4.3

Details: IDLE0.6 runs nicely on AIX except that the tip text itself does not show when the pop up box appears. The box seems to be sized properly but is blank.

-Robin Friedrich

Follow-Ups:

Date: 2000-Sep-20 16:54
By: gvanrossum

Comment:
Could it be a Tcl version problem? It's hard to debug this... :-(
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114923&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 01:51:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 17:51:47 -0700
Subject: [Python-bugs-list] [Bug #114900] Undefined Symbols When Building for OpenBSD 2.5
Message-ID: <200009210051.RAA03152@delerium.i.sourceforge.net>

Bug #114900, was updated on 2000-Sep-20 10:24
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Undefined Symbols When Building for OpenBSD 2.5

Details: I receive the following errors when I attempt to build Python for OpenBSD 2.5:

cd Modules;  make OPT="-g -O2" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
main.c:115: Undefined symbol `_Py_FatalError' referenced from text segment
main.c:125: Undefined symbol `_Py_DebugFlag' referenced from text segment
main.c:130: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:134: Undefined symbol `_Py_OptimizeFlag' referenced from text segment
main.c:138: Undefined symbol `_Py_NoSiteFlag' referenced from text segment
main.c:142: Undefined symbol `_Py_TabcheckFlag' referenced from text segment
main.c:150: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:158: Undefined symbol `_Py_UnicodeFlag' referenced from text segment
main.c:208: Undefined symbol `_Py_FdIsInteractive' referenced from text segment
main.c:232: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:246: Undefined symbol `_Py_SetProgramName' referenced from text segment
main.c:247: Undefined symbol `_Py_Initialize' referenced from text segment
main.c:249: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:251: Undefined symbol `_Py_GetPlatform' referenced from text segment
main.c:251: Undefined symbol `_Py_GetVersion' referenced from text segment
main.c:261: Undefined symbol `_PySys_SetArgv' referenced from text segment
main.c:266: Undefined symbol `_PyImport_ImportModule' referenced from text segment
main.c:268: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:274: Undefined symbol `_PyRun_SimpleString' referenced from text segment
main.c:283: Undefined symbol `_PyRun_SimpleFile' referenced from text segment
main.c:284: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:289: Undefined symbol `_PyRun_AnyFileEx' referenced from text segment
main.c:297: Undefined symbol `_PyRun_AnyFile' referenced from text segment
main.c:299: Undefined symbol `_Py_Finalize' referenced from text segment
*** Error code 1

Stop in /home/jpettit/dev/python/dist/src/Modules.
*** Error code 1


This is with a snapshot of the CVS tree from yesterday afternoon.  I tar'd up the directory and built it under Linux fine, so I believe this is particular to OpenBSD.

Follow-Ups:

Date: 2000-Sep-20 12:55
By: loewis

Comment:
Can you check whether pythonrun.o got archived into libpython2.0.a
(ar tv libpython2.0.a), and whether Py_FatalError is exported from pythonrun.o (nm libpython2.0.a and nm pythonrun.o)?

Also, should building the library invoke ranlib on your system? Did it?
-------------------------------------------------------

Date: 2000-Sep-20 13:06
By: jpettit

Comment:
No, "pythonrun.o" was not archived into "libpython2.0.a".  When I run the "nm" command and grep for "Py_FatalError", I get the following:

    [jpettit@bastion src]$ nm libpython2.0.a |grep Py_FatalError
         U _Py_FatalError
         U _Py_FatalError
[jpettit@bastion src]$ nm Python/pythonrun.o |grep Py_FatalError
000019dc T _Py_FatalError


Yes, "ranlib" was invoked a few lines before the compiler croaked:

mv -f buildno1 buildno
gcc -c -g -O2 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno`  ./Modules/getbuildinfo.c
ar cr libpython2.0.a getbuildinfo.o
ranlib libpython2.0.a
true
cd Modules;  make OPT="-g -O2" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
main.c:115: Undefined symbol `_Py_FatalError' referenced from text segment
...etc, etc...
-------------------------------------------------------

Date: 2000-Sep-20 17:51
By: gvanrossum

Comment:
Could you try starting from scratch ("make clean; make")?

If pythonrun.o is not in libpython2.0.a, something's gone wrong!

What files *are* in libpython2.0.a? ("ar tf").
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114900&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 01:53:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 17:53:09 -0700
Subject: [Python-bugs-list] [Bug #114900] Undefined Symbols When Building for OpenBSD 2.5
Message-ID: <200009210053.RAA03172@delerium.i.sourceforge.net>

Bug #114900, was updated on 2000-Sep-20 10:24
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Undefined Symbols When Building for OpenBSD 2.5

Details: I receive the following errors when I attempt to build Python for OpenBSD 2.5:

cd Modules;  make OPT="-g -O2" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
main.c:115: Undefined symbol `_Py_FatalError' referenced from text segment
main.c:125: Undefined symbol `_Py_DebugFlag' referenced from text segment
main.c:130: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:134: Undefined symbol `_Py_OptimizeFlag' referenced from text segment
main.c:138: Undefined symbol `_Py_NoSiteFlag' referenced from text segment
main.c:142: Undefined symbol `_Py_TabcheckFlag' referenced from text segment
main.c:150: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:158: Undefined symbol `_Py_UnicodeFlag' referenced from text segment
main.c:208: Undefined symbol `_Py_FdIsInteractive' referenced from text segment
main.c:232: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:246: Undefined symbol `_Py_SetProgramName' referenced from text segment
main.c:247: Undefined symbol `_Py_Initialize' referenced from text segment
main.c:249: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:251: Undefined symbol `_Py_GetPlatform' referenced from text segment
main.c:251: Undefined symbol `_Py_GetVersion' referenced from text segment
main.c:261: Undefined symbol `_PySys_SetArgv' referenced from text segment
main.c:266: Undefined symbol `_PyImport_ImportModule' referenced from text segment
main.c:268: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:274: Undefined symbol `_PyRun_SimpleString' referenced from text segment
main.c:283: Undefined symbol `_PyRun_SimpleFile' referenced from text segment
main.c:284: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:289: Undefined symbol `_PyRun_AnyFileEx' referenced from text segment
main.c:297: Undefined symbol `_PyRun_AnyFile' referenced from text segment
main.c:299: Undefined symbol `_Py_Finalize' referenced from text segment
*** Error code 1

Stop in /home/jpettit/dev/python/dist/src/Modules.
*** Error code 1


This is with a snapshot of the CVS tree from yesterday afternoon.  I tar'd up the directory and built it under Linux fine, so I believe this is particular to OpenBSD.

Follow-Ups:

Date: 2000-Sep-20 12:55
By: loewis

Comment:
Can you check whether pythonrun.o got archived into libpython2.0.a
(ar tv libpython2.0.a), and whether Py_FatalError is exported from pythonrun.o (nm libpython2.0.a and nm pythonrun.o)?

Also, should building the library invoke ranlib on your system? Did it?
-------------------------------------------------------

Date: 2000-Sep-20 13:06
By: jpettit

Comment:
No, "pythonrun.o" was not archived into "libpython2.0.a".  When I run the "nm" command and grep for "Py_FatalError", I get the following:

    [jpettit@bastion src]$ nm libpython2.0.a |grep Py_FatalError
         U _Py_FatalError
         U _Py_FatalError
[jpettit@bastion src]$ nm Python/pythonrun.o |grep Py_FatalError
000019dc T _Py_FatalError


Yes, "ranlib" was invoked a few lines before the compiler croaked:

mv -f buildno1 buildno
gcc -c -g -O2 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno`  ./Modules/getbuildinfo.c
ar cr libpython2.0.a getbuildinfo.o
ranlib libpython2.0.a
true
cd Modules;  make OPT="-g -O2" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
main.c:115: Undefined symbol `_Py_FatalError' referenced from text segment
...etc, etc...
-------------------------------------------------------

Date: 2000-Sep-20 17:51
By: gvanrossum

Comment:
Could you try starting from scratch ("make clean; make")?

If pythonrun.o is not in libpython2.0.a, something's gone wrong!

What files *are* in libpython2.0.a? ("ar tf").
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114900&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 01:56:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 17:56:53 -0700
Subject: [Python-bugs-list] [Bug #114410] 'make tests' fails with thread error on OpenBSD 2.7
Message-ID: <200009210056.RAA03349@delerium.i.sourceforge.net>

Bug #114410, was updated on 2000-Sep-14 02:24
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: 'make tests' fails with thread error on OpenBSD 2.7

Details: Using the latest CVS version of Python, the output from a pass of regrtest follows. It may be an OpenBSD problem, in which case if someone can explain it to me I will sendbug it to the OpenBSD people instead.

PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
test_grammar
test_opcodes
test_operations
test_builtin
test_exceptions
test_types
test_MimeWriter
test_al
test test_al skipped --  No module named al
test_array
test_atexit
test_audioop
test test_audioop skipped --  No module named audioop
test_augassign
test_binascii
test_binhex
test_bsddb
test_cd
test test_cd skipped --  No module named cd
test_cgi
test_cl
test test_cl skipped --  No module named cl
test_class
test_cmath
test_compile
test_contains
test_cookie
test_cpickle
test_crypt
test test_crypt skipped --  No module named crypt
test_dbm
test test_dbm skipped --  No module named dbm
test_dl
test test_dl skipped --  No module named dl
test_dospath
test_errno
test_extcall
test_fcntl
test test_fcntl skipped --  No module named FCNTL
test_file
test_fork1
test_format
test_gc
gc: collectable <list 0x36e46c>
gc: collectable <dictionary 0x3d568c>
gc: collectable <list 0x36e46c>
gc: collectable <tuple 0x36e48c>
gc: collectable <class 0x3d570c>
gc: collectable <dictionary 0x3d56cc>
gc: collectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d574c>
gc: collectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d578c>
gc: collectable <instance method 0x25e34c>
gc: collectable <B instance at 0x36e4cc>
gc: collectable <dictionary 0x3d58cc>
gc: uncollectable <dictionary 0x3d584c>
gc: uncollectable <A instance at 0x36e46c>
gc: collectable <dictionary 0x3d57cc>
gc: collectable <function 0x3d590c>
test_gdbm
test test_gdbm skipped --  No module named gdbm
test_getopt
test_gettext
test_gl
test test_gl skipped --  No module named gl
test_grp
pid 4207: Fatal error '_libc_private_storage_lock' at line 14 in file /usr/src/lib/libc_r/thread/thread_storage.c (errno = 2)
Abort (core dumped) 
*** Error code 134

Stop in /tmp/python/dist/src (line 212 of Makefile).


Follow-Ups:

Date: 2000-Sep-14 02:34
By: jribbens

Comment:
Oh, if you do './configure --without-threads' then the problem is avoided, of course. 'make tests' then gives:

74 tests OK.
26 tests skipped: test_al test_audioop test_cd test_cl test_crypt test_dbm test_dl test_fcntl test_fork1 test_gdbm test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev test_minidom test_nis test_pty test_pyexpat test_rgbimg test_sunaudiodev test_thread test_timing test_winreg test_winsound test_zlib

But presumably, since Python 2 has threads enabled by default, something else needs to be done ;-)
-------------------------------------------------------

Date: 2000-Sep-16 10:04
By: gvanrossum

Comment:
I don't have an OpenBSD system to debug this myself. I have access to FreeBSD 4.1 which does not have this problem. Perhaps you can try to debug this some more yourself?

If it's decided that this is a bug in OpenBSD (are you using the latest version?), please let us know so we can close this bug report.
-------------------------------------------------------

Date: 2000-Sep-20 14:46
By: jribbens

Comment:
On further investigation, it appears that the problem only occurs if test_fork1 is run at some point before test_grp. 

I'm trying to write some C code to perform similar operations as running test_fork1 followed by test_grp, but I'm getting confused by the fact that pthread seems to cancel all threads on a fork(), but this doesn't happen when test_fork1 forks.
-------------------------------------------------------

Date: 2000-Sep-20 15:28
By: jribbens

Comment:
It's an OpenBSD problem - setgrent aborts if a thread has been created. You can close this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114410&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 02:01:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 18:01:35 -0700
Subject: [Python-bugs-list] [Bug #113795] IDLE 0.6 with Python 2.0b1 doesn't handle chinese characters
Message-ID: <200009210101.SAA03518@delerium.i.sourceforge.net>

Bug #113795, was updated on 2000-Sep-07 06:49
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: Later
Bug Group: 3rd Party
Priority: 1
Summary: IDLE 0.6 with Python 2.0b1 doesn't handle chinese characters

Details: I just switched from 1.5.2 to 2.0b1 on W2K/Simplified Chinese version. I used to be able to input chinese characters directly into IDLE, and access violations did happen quite often. Now with 2.0b1, I can't even input chinese characters into the IDLE window anymore:IDLE automatically changed chinese characters into illegible stuff; it's the same when I copy from a text editor and paste into the IDLE window. I guess it's related to the induction of unicode support in 2.0, but is there a workaround I should know, or I should switch back to 1.5.2, or it's a bug worth fixing?

Thanks.


Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 23:13
By: tim_one

Comment:
Assigned to Fredrik, because Swedes have an uncanny intuition about how IDLE and Tk work in the presence of characters I can't get at <0.9 wink>.  Boosted the priority because it sounds like a legit practical problem.
-------------------------------------------------------

Date: 2000-Sep-20 12:47
By: loewis

Comment:
I can reproduce the problem by installing a Russion or Arabic keyboard layout on Win2k; typing into an Entry or Text widget displays Latin-1 characters. I can observe the same problem with a plain 8.3 wish, so it appears to be a bug in Tk - which apparently truncates characters on input. So I propose to close this as 3rd Party/Later, and recategorize it as Tkinter.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113795&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 02:06:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 18:06:24 -0700
Subject: [Python-bugs-list] [Bug #114846] python20_d.dll missing
Message-ID: <200009210106.SAA15949@bush.i.sourceforge.net>

Bug #114846, was updated on 2000-Sep-19 19:04
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Wont Fix
Bug Group: Platform-specific
Priority: 5
Summary: python20_d.dll missing

Details: The file python20_d.dll is missing from the
win32-binary distribution.
side note: in python 1.5 this could be worked around
by linking to python15.lib manually. In 1.6 & 2.0 this
work around does not work.
(this is of course when python is embedded into a win32
application)

Follow-Ups:

Date: 2000-Sep-19 23:41
By: tim_one

Comment:
Guido, I assigned this to you just to get your attention:  what do you think?  (MarkH, if you're listening, you too!)

C:\Code\python\dist\src\PCbuild>dir py*.dll

PYTHON20 DLL       692,285  09-19-00 10:14p python20.dll
PYTHON~1 DLL     1,138,751  09-19-00 10:14p python20_d.dll
         2 file(s)      1,831,036 bytes
         0 dir(s)        2,554.24 MB free

C:\Code\python\dist\src\PCbuild>

The debug DLL is a megabyte now, and I personally don't want to bloat the installer with it given that not one user in 1,000 will have any use for it.  Perhaps we could make it available as a separate download for experts?

-------------------------------------------------------

Date: 2000-Sep-20 06:21
By: gvanrossum

Comment:
Sorry, I won't fix this. The debug DLL is huge, and you'd need more than just python20_d.dll -- you'd need the _d.pyd version of all the extension modules. This would just be a waste of installer size.

If you have a need for the debug DLLs, you should download the sources and rebuild with debug mode from source. After all you must be debugging something so you must already be using VC++ so rebuilding won't be a problem; see PCbuild/readme.txt for elaborate instructions.
-------------------------------------------------------

Date: 2000-Sep-20 12:23
By: PSYKOtron

Comment:
I would appreciate it if you can add it into a seperate installer for experts. At the moment I have to compile
all of python, and redistribute all the debug and non-debug lib's and dll's to a couple people responsible for debugging my program. Basicly I used to use the windows installer for the debuggers, now I have to make my own, and
install it manually to each programmer's system.
I believe linux distributions solved this problem by releasing: somelib-1.0 && somelib-1.0-dev
:)
Thanks for all your hard work in python... its helped *a lot* in my project.
-------------------------------------------------------

Date: 2000-Sep-20 18:06
By: tim_one

Comment:
Hmm.  Guido, turns out we're already shipping the debug DLLs for the extension modules!

C:\Python20\DLLs>dir *_d.pyd

 Volume in drive C has no label
 Volume Serial Number is 3459-5C23
 Directory of C:\Python20\DLLs

PARSER_D PYD        65,597  09-07-00  2:42a parser_d.pyd
_SOCKE~1 PYD        53,310  09-07-00  2:41a _socket_d.pyd
_SRE_D   PYD        45,115  09-07-00  2:41a _sre_d.pyd
MMAP_D   PYD        36,923  09-07-00  2:42a mmap_d.pyd
SELECT_D PYD        32,829  09-07-00  2:42a select_d.pyd
UCNHAS~1 PYD       548,926  09-07-00  2:42a ucnhash_d.pyd
UNICOD~2 PYD       733,250  09-07-00  2:42a unicodedata_d.pyd
_WINRE~1 PYD        57,406  09-07-00  2:43a _winreg_d.pyd
WINSOU~1 PYD        28,735  09-07-00  2:43a winsound_d.pyd
_TKINT~1 PYD        53,311  09-07-00  2:42a _tkinter_d.pyd
PYEXPA~1 PYD        45,118  09-07-00  2:42a pyexpat_d.pyd
BSDDB_D  PYD       106,556  09-07-00  2:42a bsddb_d.pyd
ZLIB_D   PYD        86,075  09-07-00  2:43a zlib_d.pyd
        13 file(s)      1,893,151 bytes
         0 dir(s)        2,551.06 MB free

C:\Python20\DLLs>

Closing in on 2Mb of fat I can cut out of the installer!

PSKOtron, no, thank you, but I'm not going to build a new installer just so "a couple people" have an easier time.  That isn't cruelty <wink>, it's that thousands of people are waiting for more important things and my time (like yours) is limited.  If someone wants to contribute such an installer, cool.  Else the best I can manage is a no-time approach, such as putting all the _d files into a .zip file at release points and uploading that to an FTP site.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114846&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 02:17:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 18:17:53 -0700
Subject: [Python-bugs-list] [Bug #112693] re behaves differently in 1.6 and 2.0 than 1.52
Message-ID: <200009210117.SAA16393@bush.i.sourceforge.net>

Bug #112693, was updated on 2000-Aug-24 20:04
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: None
Bug Group: None
Priority: 7
Summary: re behaves differently in 1.6 and 2.0 than 1.52

Details: The output is diffrent when run with 1.52 when compared with 1.6 or 2.0

http://dorb.com/python/testRe.py



Follow-Ups:

Date: 2000-Aug-25 07:42
By: jhylton

Comment:
Just noting that we should resolve this bug before release.

-------------------------------------------------------

Date: 2000-Aug-28 00:34
By: effbot

Comment:
The pattern causes excessive recursion (nested repeats on a long target string).  SRE's stack check traps this, but the exception got lost on the way out.

With the current CVS version, the example gives a "maximum recursion limit exceeded".  That's an improvement, but not enough to close the bug...
-------------------------------------------------------

Date: 2000-Sep-05 16:25
By: dgallion

Comment:
Noticed a problem with a more simple pattern.

Python 2.0b1 (#2, Sep  4 2000, 11:03:25) [MSC 32 bit (Intel)] on win32
Copyright (c) 2000 BeOpen.com.
All Rights Reserved.

Copyright (c) 1995-2000 Corporation for National Research Initiatives.
All Rights Reserved.

Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam.
All Rights Reserved.
>>> buf=open('testRe.py').read()
>>> import re
>>> res= re.findall(".*",buf)
>>> len(res)
1
Python 1.5.2 (#0, Aug 12 2000, 14:54:22) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> buf=open('testRe.py').read()
>>> import re
>>> res=re.findall(".*",buf)
>>> len(res)
432

-------------------------------------------------------

Date: 2000-Sep-20 18:17
By: gvanrossum

Comment:
Fixed according to submittor.  Closed without verification.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112693&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 06:32:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 22:32:02 -0700
Subject: [Python-bugs-list] [Bug #113862] 2.0b1 lib.pdf, problems with bookmark titles
Message-ID: <200009210532.WAA25273@bush.i.sourceforge.net>

Bug #113862, was updated on 2000-Sep-08 01:48
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Summary: 2.0b1 lib.pdf, problems with bookmark titles

Details: In Acrobat Reader, 3.25 shows in the Bookmarks as "protect unhbox voidb@x kern.06envbox" etc.  It does show correctly as "__builtin__ -- Built-in functions" in the main window, and when printed.  3.26, same problem.  Other titles seem OK (haven't checked them all, though).



Follow-Ups:

Date: 2000-Sep-08 23:16
By: fdrake

Comment:
The bookmark entry for the copy_reg module has the same defect.  This is probably a result of the seriously painful hackery used to make the underscore be somewhat less special.

Must be fixed for 2.0 final.
-------------------------------------------------------

Date: 2000-Sep-20 22:32
By: fdrake

Comment:
Still not sure how to fix.

I'm reducing the priority of this since it isn't enough to hold off the release of 2.0.  This is also not new in 1.6 or 2.0, so appearantly it is survivable.

It should be fixed, but that may happen as part of the migration to a new markup language & translation tools.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113862&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 06:33:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Sep 2000 22:33:17 -0700
Subject: [Python-bugs-list] [Bug #113773] Python 2.0b1 selectmodule compile error under Redhat 5.2
Message-ID: <200009210533.WAA25284@bush.i.sourceforge.net>

Bug #113773, was updated on 2000-Sep-06 18:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0b1 selectmodule compile error under Redhat 5.2

Details: Environment: Redhat 5.2 running the gcc compiler that comes with the
distribution (gcc 2.7.2.3).

'make' failed when compiling selectmodule.c ('./configure' ran ok)because
the following constants were undefined:

POLLRDNORM, POLLRDBAND, POLLWRBAND

The /usr/include/sys/poll.h file does not contain these constants.
Under Redhat 6.2 the constants are defined in the /usr/include/bits/poll.h
file (which is not present in the Redhat 5.2 distribution).

I used the Redhat 6.2 poll.h file and the selectmodule compiled (under
Redhat 5.2) but got the following error when running 
'make test' (it looks like it might be related to the compile problem):

test test_poll crashed -- select.error: (9, 'Bad file descriptor')

1 test failed: test_poll



Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 23:08
By: tim_one

Comment:
Boosted the priority and assigned to Fred.  Don't know what you can do about an older Redhat build problem, and it's not clear that the test failure isn't simply due to mixing files across OS releases.  I'm inclined to blame it on the OS.
-------------------------------------------------------

Date: 2000-Sep-15 13:11
By: fdrake

Comment:
I've asked SourceForge if there are ways to use older versions of operating systems on their compile farm.  Until then, we'll need a volunteer with a RH5.2 system to help with this.

Stuart:  Are you willing to test a patch if I mail it to you?  Thanks.
-------------------------------------------------------

Date: 2000-Sep-15 19:50
By: fdrake

Comment:
SourceForge will try and provide a RH5.2 installation for us; now that's service!
-------------------------------------------------------

Date: 2000-Sep-20 22:33
By: fdrake

Comment:
Reducing priority since the platform is old and we still don't have access to it.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113773&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 08:40:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 00:40:02 -0700
Subject: [Python-bugs-list] [Bug #114900] Undefined Symbols When Building for OpenBSD 2.5
Message-ID: <200009210740.AAA29500@bush.i.sourceforge.net>

Bug #114900, was updated on 2000-Sep-20 10:24
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Undefined Symbols When Building for OpenBSD 2.5

Details: I receive the following errors when I attempt to build Python for OpenBSD 2.5:

cd Modules;  make OPT="-g -O2" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
main.c:115: Undefined symbol `_Py_FatalError' referenced from text segment
main.c:125: Undefined symbol `_Py_DebugFlag' referenced from text segment
main.c:130: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:134: Undefined symbol `_Py_OptimizeFlag' referenced from text segment
main.c:138: Undefined symbol `_Py_NoSiteFlag' referenced from text segment
main.c:142: Undefined symbol `_Py_TabcheckFlag' referenced from text segment
main.c:150: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:158: Undefined symbol `_Py_UnicodeFlag' referenced from text segment
main.c:208: Undefined symbol `_Py_FdIsInteractive' referenced from text segment
main.c:232: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:246: Undefined symbol `_Py_SetProgramName' referenced from text segment
main.c:247: Undefined symbol `_Py_Initialize' referenced from text segment
main.c:249: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:251: Undefined symbol `_Py_GetPlatform' referenced from text segment
main.c:251: Undefined symbol `_Py_GetVersion' referenced from text segment
main.c:261: Undefined symbol `_PySys_SetArgv' referenced from text segment
main.c:266: Undefined symbol `_PyImport_ImportModule' referenced from text segment
main.c:268: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:274: Undefined symbol `_PyRun_SimpleString' referenced from text segment
main.c:283: Undefined symbol `_PyRun_SimpleFile' referenced from text segment
main.c:284: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:289: Undefined symbol `_PyRun_AnyFileEx' referenced from text segment
main.c:297: Undefined symbol `_PyRun_AnyFile' referenced from text segment
main.c:299: Undefined symbol `_Py_Finalize' referenced from text segment
*** Error code 1

Stop in /home/jpettit/dev/python/dist/src/Modules.
*** Error code 1


This is with a snapshot of the CVS tree from yesterday afternoon.  I tar'd up the directory and built it under Linux fine, so I believe this is particular to OpenBSD.

Follow-Ups:

Date: 2000-Sep-20 12:55
By: loewis

Comment:
Can you check whether pythonrun.o got archived into libpython2.0.a
(ar tv libpython2.0.a), and whether Py_FatalError is exported from pythonrun.o (nm libpython2.0.a and nm pythonrun.o)?

Also, should building the library invoke ranlib on your system? Did it?
-------------------------------------------------------

Date: 2000-Sep-20 13:06
By: jpettit

Comment:
No, "pythonrun.o" was not archived into "libpython2.0.a".  When I run the "nm" command and grep for "Py_FatalError", I get the following:

    [jpettit@bastion src]$ nm libpython2.0.a |grep Py_FatalError
         U _Py_FatalError
         U _Py_FatalError
[jpettit@bastion src]$ nm Python/pythonrun.o |grep Py_FatalError
000019dc T _Py_FatalError


Yes, "ranlib" was invoked a few lines before the compiler croaked:

mv -f buildno1 buildno
gcc -c -g -O2 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno`  ./Modules/getbuildinfo.c
ar cr libpython2.0.a getbuildinfo.o
ranlib libpython2.0.a
true
cd Modules;  make OPT="-g -O2" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
main.c:115: Undefined symbol `_Py_FatalError' referenced from text segment
...etc, etc...
-------------------------------------------------------

Date: 2000-Sep-20 17:51
By: gvanrossum

Comment:
Could you try starting from scratch ("make clean; make")?

If pythonrun.o is not in libpython2.0.a, something's gone wrong!

What files *are* in libpython2.0.a? ("ar tf").
-------------------------------------------------------

Date: 2000-Sep-21 00:40
By: jpettit

Comment:
I've been doing a "make clean" before I try "make".  In fact, I've even been erasing "config.cache" and running "configure" before the make commands.  One of the interesting things is that when I run "make", it looks like it runs all of the "configure" checks (retrieving the cached values) twice.  I can send you the output from "make" if you like.

Here are the files in "libpython2.0.a" (there doesn't appear to be a "-f" flag for "ar" on OpenBSD):

__.SYMDEF
threadmodule.o
gcmodule.o
bsddbmodule.o
regexmodule.o
regexpr.o
pcremodule.o
pypcre.o
posixmodule.o
signalmodule.o
_sre.o
readline.o
arraymodule.o
cmathmodule.o
mathmodule.o
stropmodule.o
structmodule.o
timemodule.o
operator.o
_codecsmodule.o
unicodedata.o
unicodedatabase.o
ucnhash.o
_localemodule.o
fcntlmodule.o
pwdmodule.o
grpmodule.o
errnomodule.o
selectmodule.o
socketmodule.o
mmapmodule.o
md5module.o
md5c.o
shamodule.o
rotormodule.o
syslogmodule.o
newmodule.o
binascii.o
parsermodule.o
cStringIO.o
cPickle.o
config.o
getpath.o
main.o
getbuildinfo.o

Another thing that I noticed is that an error is raised and ignored immediately before the archive command is run:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H  -c main.c
if test -f hassignal;  then echo removing sigcheck.o intrcheck.o;  ar d ../libpython2.0.a sigcheck.o intrcheck.o 2>/dev/null;  else echo leaving sigcheck.o intrcheck.o in; fi
removing sigcheck.o intrcheck.o
*** Error code 1 (ignored)

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114900&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 14:47:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 06:47:14 -0700
Subject: [Python-bugs-list] [Bug #110609] Operator breakage with long int operands (PR#187)
Message-ID: <200009211347.GAA10619@bush.i.sourceforge.net>

Bug #110609, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Operator breakage with long int operands (PR#187)

Details: Jitterbug-Id: 187
Submitted-By: aa8vb@yahoo.com
Date: Mon, 24 Jan 2000 11:19:11 -0500 (EST)
Version: 1.5.2
OS: IRIX 6.5


This came up a few weeks ago, and bit again in the dumbdbm module last week.
In the dumbdbm module in 1.5.2:

     '\0'*(npos-pos)

(npos-pos) on some OSs will be a long int.  However, the '*' operator won't 
handle a long int.  I can't think of a reason why 'a'*10L should be invalid,
for example.

At issue a few weeks ago was long ints and the '%' operator.  For example:

    >>> str( 0x80000000L )
    '2147483648L'
    >>> "%ld" % 0x80000000L
    OverflowError: long int too long to convert

    >>> hex( 0x80000000L )
    '0x80000000L'
    >>> "%lX" % 0x80000000L
    OverflowError: long int too long to convert

Couldn't % use hex() and str() under the hood, for instance?



====================================================================
Audit trail:
Mon Jan 24 14:28:42 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-16 06:57
By: loewis

Comment:
I believe the first issue is resolved in 2.0b1; '\0' * 10L does work.
-------------------------------------------------------

Date: 2000-Sep-16 16:41
By: loewis

Comment:
A patch for the formatting problem in in

http://sourceforge.net/patch/?func=detailpatch&patch_id=101544&group_id=5470
-------------------------------------------------------

Date: 2000-Sep-21 06:47
By: loewis

Comment:
The PyNumber_Format part is fixed with revision 2.89 of stringobject.c.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110609&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 15:18:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 07:18:00 -0700
Subject: [Python-bugs-list] [Bug #114900] Undefined Symbols When Building for OpenBSD 2.5
Message-ID: <200009211418.HAA11909@bush.i.sourceforge.net>

Bug #114900, was updated on 2000-Sep-20 10:24
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Undefined Symbols When Building for OpenBSD 2.5

Details: I receive the following errors when I attempt to build Python for OpenBSD 2.5:

cd Modules;  make OPT="-g -O2" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
main.c:115: Undefined symbol `_Py_FatalError' referenced from text segment
main.c:125: Undefined symbol `_Py_DebugFlag' referenced from text segment
main.c:130: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:134: Undefined symbol `_Py_OptimizeFlag' referenced from text segment
main.c:138: Undefined symbol `_Py_NoSiteFlag' referenced from text segment
main.c:142: Undefined symbol `_Py_TabcheckFlag' referenced from text segment
main.c:150: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:158: Undefined symbol `_Py_UnicodeFlag' referenced from text segment
main.c:208: Undefined symbol `_Py_FdIsInteractive' referenced from text segment
main.c:232: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:246: Undefined symbol `_Py_SetProgramName' referenced from text segment
main.c:247: Undefined symbol `_Py_Initialize' referenced from text segment
main.c:249: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:251: Undefined symbol `_Py_GetPlatform' referenced from text segment
main.c:251: Undefined symbol `_Py_GetVersion' referenced from text segment
main.c:261: Undefined symbol `_PySys_SetArgv' referenced from text segment
main.c:266: Undefined symbol `_PyImport_ImportModule' referenced from text segment
main.c:268: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:274: Undefined symbol `_PyRun_SimpleString' referenced from text segment
main.c:283: Undefined symbol `_PyRun_SimpleFile' referenced from text segment
main.c:284: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:289: Undefined symbol `_PyRun_AnyFileEx' referenced from text segment
main.c:297: Undefined symbol `_PyRun_AnyFile' referenced from text segment
main.c:299: Undefined symbol `_Py_Finalize' referenced from text segment
*** Error code 1

Stop in /home/jpettit/dev/python/dist/src/Modules.
*** Error code 1


This is with a snapshot of the CVS tree from yesterday afternoon.  I tar'd up the directory and built it under Linux fine, so I believe this is particular to OpenBSD.

Follow-Ups:

Date: 2000-Sep-20 12:55
By: loewis

Comment:
Can you check whether pythonrun.o got archived into libpython2.0.a
(ar tv libpython2.0.a), and whether Py_FatalError is exported from pythonrun.o (nm libpython2.0.a and nm pythonrun.o)?

Also, should building the library invoke ranlib on your system? Did it?
-------------------------------------------------------

Date: 2000-Sep-20 13:06
By: jpettit

Comment:
No, "pythonrun.o" was not archived into "libpython2.0.a".  When I run the "nm" command and grep for "Py_FatalError", I get the following:

    [jpettit@bastion src]$ nm libpython2.0.a |grep Py_FatalError
         U _Py_FatalError
         U _Py_FatalError
[jpettit@bastion src]$ nm Python/pythonrun.o |grep Py_FatalError
000019dc T _Py_FatalError


Yes, "ranlib" was invoked a few lines before the compiler croaked:

mv -f buildno1 buildno
gcc -c -g -O2 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno`  ./Modules/getbuildinfo.c
ar cr libpython2.0.a getbuildinfo.o
ranlib libpython2.0.a
true
cd Modules;  make OPT="-g -O2" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
main.c:115: Undefined symbol `_Py_FatalError' referenced from text segment
...etc, etc...
-------------------------------------------------------

Date: 2000-Sep-20 17:51
By: gvanrossum

Comment:
Could you try starting from scratch ("make clean; make")?

If pythonrun.o is not in libpython2.0.a, something's gone wrong!

What files *are* in libpython2.0.a? ("ar tf").
-------------------------------------------------------

Date: 2000-Sep-21 00:40
By: jpettit

Comment:
I've been doing a "make clean" before I try "make".  In fact, I've even been erasing "config.cache" and running "configure" before the make commands.  One of the interesting things is that when I run "make", it looks like it runs all of the "configure" checks (retrieving the cached values) twice.  I can send you the output from "make" if you like.

Here are the files in "libpython2.0.a" (there doesn't appear to be a "-f" flag for "ar" on OpenBSD):

__.SYMDEF
threadmodule.o
gcmodule.o
bsddbmodule.o
regexmodule.o
regexpr.o
pcremodule.o
pypcre.o
posixmodule.o
signalmodule.o
_sre.o
readline.o
arraymodule.o
cmathmodule.o
mathmodule.o
stropmodule.o
structmodule.o
timemodule.o
operator.o
_codecsmodule.o
unicodedata.o
unicodedatabase.o
ucnhash.o
_localemodule.o
fcntlmodule.o
pwdmodule.o
grpmodule.o
errnomodule.o
selectmodule.o
socketmodule.o
mmapmodule.o
md5module.o
md5c.o
shamodule.o
rotormodule.o
syslogmodule.o
newmodule.o
binascii.o
parsermodule.o
cStringIO.o
cPickle.o
config.o
getpath.o
main.o
getbuildinfo.o

Another thing that I noticed is that an error is raised and ignored immediately before the archive command is run:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H  -c main.c
if test -f hassignal;  then echo removing sigcheck.o intrcheck.o;  ar d ../libpython2.0.a sigcheck.o intrcheck.o 2>/dev/null;  else echo leaving sigcheck.o intrcheck.o in; fi
removing sigcheck.o intrcheck.o
*** Error code 1 (ignored)

-------------------------------------------------------

Date: 2000-Sep-21 07:18
By: gvanrossum

Comment:
That listing was a great clue! It appears that the archive only contains the *last* set of files added to it.

Can you check the man page for ar on your platform? I hope it supports adding files piecemeal -- this is what the Python build process uses.

I wonder if you change "$(AR) cr ..." to $(AR) r ..." in the add2lib target in the various sub-Makefiles -- would this fix things? That would mean that the 'c' option has a different meaning for you than it has for me. On every Unix system I've seen, 'c' just serves to suppress a warning when creating the archive. Maybe on OpenBSD it creates a new empty archive?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114900&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 16:17:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 08:17:11 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200009211517.IAA14317@bush.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 13:45
By: fdrake

Comment:
We need to know the output of "uname -s" and "uname -r" for this system.  (If "uname -r" reports an error, please try "uname -v".)

Are you willing to test a modified configure script on this platform?

What additional library is required for the mmap module?
-------------------------------------------------------

Date: 2000-Sep-12 21:59
By: fdrake

Comment:
Received the following response from Daniel Dittmar <ddittmar@users.sourceforge.net>:

> We need to know the output of "uname -s" and "uname -r" 
> for this system.  (If "uname -r" reports an error, please 
> try "uname -v".)

uname -s
ReliantUNIX-N

uname -r
5.45


> Are you willing to test a modified configure script on
> this platform?

sure.

> What additional library is required for the mmap module?

The man page states -lucb. This didn't work on my machine 
as the BSD compatibility layer is not active. I tell you 
more as soon as I know how to activate it.

***********

Another problem: to detect pthreads, the compiler must be 
called with -Kpthread. Otherwise, pthread.h goes into a 
branch where it tries to include a non existent header, 
fails, and configure reports 'no pthreads'.

Daniel

-------------------------------------------------------

Date: 2000-Sep-15 11:57
By: fdrake

Comment:
For the mmap issue, I've added a comment to Modules/Setup.in to let installers know that -lucb may be needed.  In revision 1.110.
-------------------------------------------------------

Date: 2000-Sep-15 13:37
By: fdrake

Comment:
I'm sending a modified version of  the configure script to Daniel Dittmar to test for the first two points in this bug report.
-------------------------------------------------------

Date: 2000-Sep-21 08:17
By: fdrake

Comment:
Sent query to Daniel Dittmar asking if he's had a chance to test the revised configure script I sent.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 16:46:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 08:46:00 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200009211546.IAA15346@bush.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 13:45
By: fdrake

Comment:
We need to know the output of "uname -s" and "uname -r" for this system.  (If "uname -r" reports an error, please try "uname -v".)

Are you willing to test a modified configure script on this platform?

What additional library is required for the mmap module?
-------------------------------------------------------

Date: 2000-Sep-12 21:59
By: fdrake

Comment:
Received the following response from Daniel Dittmar <ddittmar@users.sourceforge.net>:

> We need to know the output of "uname -s" and "uname -r" 
> for this system.  (If "uname -r" reports an error, please 
> try "uname -v".)

uname -s
ReliantUNIX-N

uname -r
5.45


> Are you willing to test a modified configure script on
> this platform?

sure.

> What additional library is required for the mmap module?

The man page states -lucb. This didn't work on my machine 
as the BSD compatibility layer is not active. I tell you 
more as soon as I know how to activate it.

***********

Another problem: to detect pthreads, the compiler must be 
called with -Kpthread. Otherwise, pthread.h goes into a 
branch where it tries to include a non existent header, 
fails, and configure reports 'no pthreads'.

Daniel

-------------------------------------------------------

Date: 2000-Sep-15 11:57
By: fdrake

Comment:
For the mmap issue, I've added a comment to Modules/Setup.in to let installers know that -lucb may be needed.  In revision 1.110.
-------------------------------------------------------

Date: 2000-Sep-15 13:37
By: fdrake

Comment:
I'm sending a modified version of  the configure script to Daniel Dittmar to test for the first two points in this bug report.
-------------------------------------------------------

Date: 2000-Sep-21 08:17
By: fdrake

Comment:
Sent query to Daniel Dittmar asking if he's had a chance to test the revised configure script I sent.
-------------------------------------------------------

Date: 2000-Sep-21 08:46
By: fdrake

Comment:
Received message from Daniel indicating he should get a chace to test the changes this weekend, so it should be available for 2.0b2.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 18:32:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 10:32:25 -0700
Subject: [Python-bugs-list] [Bug #114900] Undefined Symbols When Building for OpenBSD 2.5
Message-ID: <200009211732.KAA11653@delerium.i.sourceforge.net>

Bug #114900, was updated on 2000-Sep-20 10:24
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Undefined Symbols When Building for OpenBSD 2.5

Details: I receive the following errors when I attempt to build Python for OpenBSD 2.5:

cd Modules;  make OPT="-g -O2" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
main.c:115: Undefined symbol `_Py_FatalError' referenced from text segment
main.c:125: Undefined symbol `_Py_DebugFlag' referenced from text segment
main.c:130: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:134: Undefined symbol `_Py_OptimizeFlag' referenced from text segment
main.c:138: Undefined symbol `_Py_NoSiteFlag' referenced from text segment
main.c:142: Undefined symbol `_Py_TabcheckFlag' referenced from text segment
main.c:150: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:158: Undefined symbol `_Py_UnicodeFlag' referenced from text segment
main.c:208: Undefined symbol `_Py_FdIsInteractive' referenced from text segment
main.c:232: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:246: Undefined symbol `_Py_SetProgramName' referenced from text segment
main.c:247: Undefined symbol `_Py_Initialize' referenced from text segment
main.c:249: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:251: Undefined symbol `_Py_GetPlatform' referenced from text segment
main.c:251: Undefined symbol `_Py_GetVersion' referenced from text segment
main.c:261: Undefined symbol `_PySys_SetArgv' referenced from text segment
main.c:266: Undefined symbol `_PyImport_ImportModule' referenced from text segment
main.c:268: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:274: Undefined symbol `_PyRun_SimpleString' referenced from text segment
main.c:283: Undefined symbol `_PyRun_SimpleFile' referenced from text segment
main.c:284: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:289: Undefined symbol `_PyRun_AnyFileEx' referenced from text segment
main.c:297: Undefined symbol `_PyRun_AnyFile' referenced from text segment
main.c:299: Undefined symbol `_Py_Finalize' referenced from text segment
*** Error code 1

Stop in /home/jpettit/dev/python/dist/src/Modules.
*** Error code 1


This is with a snapshot of the CVS tree from yesterday afternoon.  I tar'd up the directory and built it under Linux fine, so I believe this is particular to OpenBSD.

Follow-Ups:

Date: 2000-Sep-20 12:55
By: loewis

Comment:
Can you check whether pythonrun.o got archived into libpython2.0.a
(ar tv libpython2.0.a), and whether Py_FatalError is exported from pythonrun.o (nm libpython2.0.a and nm pythonrun.o)?

Also, should building the library invoke ranlib on your system? Did it?
-------------------------------------------------------

Date: 2000-Sep-20 13:06
By: jpettit

Comment:
No, "pythonrun.o" was not archived into "libpython2.0.a".  When I run the "nm" command and grep for "Py_FatalError", I get the following:

    [jpettit@bastion src]$ nm libpython2.0.a |grep Py_FatalError
         U _Py_FatalError
         U _Py_FatalError
[jpettit@bastion src]$ nm Python/pythonrun.o |grep Py_FatalError
000019dc T _Py_FatalError


Yes, "ranlib" was invoked a few lines before the compiler croaked:

mv -f buildno1 buildno
gcc -c -g -O2 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno`  ./Modules/getbuildinfo.c
ar cr libpython2.0.a getbuildinfo.o
ranlib libpython2.0.a
true
cd Modules;  make OPT="-g -O2" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
main.c:115: Undefined symbol `_Py_FatalError' referenced from text segment
...etc, etc...
-------------------------------------------------------

Date: 2000-Sep-20 17:51
By: gvanrossum

Comment:
Could you try starting from scratch ("make clean; make")?

If pythonrun.o is not in libpython2.0.a, something's gone wrong!

What files *are* in libpython2.0.a? ("ar tf").
-------------------------------------------------------

Date: 2000-Sep-21 00:40
By: jpettit

Comment:
I've been doing a "make clean" before I try "make".  In fact, I've even been erasing "config.cache" and running "configure" before the make commands.  One of the interesting things is that when I run "make", it looks like it runs all of the "configure" checks (retrieving the cached values) twice.  I can send you the output from "make" if you like.

Here are the files in "libpython2.0.a" (there doesn't appear to be a "-f" flag for "ar" on OpenBSD):

__.SYMDEF
threadmodule.o
gcmodule.o
bsddbmodule.o
regexmodule.o
regexpr.o
pcremodule.o
pypcre.o
posixmodule.o
signalmodule.o
_sre.o
readline.o
arraymodule.o
cmathmodule.o
mathmodule.o
stropmodule.o
structmodule.o
timemodule.o
operator.o
_codecsmodule.o
unicodedata.o
unicodedatabase.o
ucnhash.o
_localemodule.o
fcntlmodule.o
pwdmodule.o
grpmodule.o
errnomodule.o
selectmodule.o
socketmodule.o
mmapmodule.o
md5module.o
md5c.o
shamodule.o
rotormodule.o
syslogmodule.o
newmodule.o
binascii.o
parsermodule.o
cStringIO.o
cPickle.o
config.o
getpath.o
main.o
getbuildinfo.o

Another thing that I noticed is that an error is raised and ignored immediately before the archive command is run:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H  -c main.c
if test -f hassignal;  then echo removing sigcheck.o intrcheck.o;  ar d ../libpython2.0.a sigcheck.o intrcheck.o 2>/dev/null;  else echo leaving sigcheck.o intrcheck.o in; fi
removing sigcheck.o intrcheck.o
*** Error code 1 (ignored)

-------------------------------------------------------

Date: 2000-Sep-21 07:18
By: gvanrossum

Comment:
That listing was a great clue! It appears that the archive only contains the *last* set of files added to it.

Can you check the man page for ar on your platform? I hope it supports adding files piecemeal -- this is what the Python build process uses.

I wonder if you change "$(AR) cr ..." to $(AR) r ..." in the add2lib target in the various sub-Makefiles -- would this fix things? That would mean that the 'c' option has a different meaning for you than it has for me. On every Unix system I've seen, 'c' just serves to suppress a warning when creating the archive. Maybe on OpenBSD it creates a new empty archive?
-------------------------------------------------------

Date: 2000-Sep-21 10:32
By: jpettit

Comment:
I think that "ar" does what you want.  Here's the man page explanation of the "-c" flag:

-c   Whenever an archive is created, an informational message to that
     effect is written to standard error.  If the -c option is speci-
     fied, ar creates the archive silently.

I was able to build Python 1.6 without any problems.  There was an issue with the "db" library on 2.0b1, but this seems to have been addressed in revision 1.145 of "configure".  The output of "make" is very strange, so I have mailed it directly to Guido, since it is probably too long to post here.  I received an auto-response, so he may want to check his public BeOpen email.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114900&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 19:32:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 11:32:08 -0700
Subject: [Python-bugs-list] [Bug #114598] Blue Screen crash, popen, Win98, Norton Antivirus 2000
Message-ID: <200009211832.LAA22156@bush.i.sourceforge.net>

Bug #114598, was updated on 2000-Sep-16 13:24
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 7
Summary: Blue Screen crash, popen, Win98, Norton Antivirus 2000

Details: On Windows 98, all of the os.popen*() functions cause a hard "blue screen" crash requiring a reboot, when Nortin Antivirus 2000 is installed and enabled. (Not with Norton Antivirus version 5, not on Windows 2000.)

While this is probably a bug in Norton Antivirus 2000, and we're already warning for this on the download page, that's not enough (we've seen at least one report in the newsgroup), and it would be good if we could somehow prevent it. Even a call to Py_FatalError is better than the blue screen, and raising os.error would be a *lot* better.

Follow-Ups:

Date: 2000-Sep-16 14:26
By: tim_one

Comment:
I don't know how to stop this.  Pissed away an hour trying to get help on the Symantec site, and eventually found a support board to which I posted this msg:

Product: Norton AntiVirus 2000 6.0 for Windows 95/98/NT
Supported operating system: Windows 98
Action: Run Another Program
Error Message: 
Summary: Blue screen crash

I develop the Windows version of the core Python language. Several reports of blue-screen death on Win98 have been traced to NAV2000.  Here's the exact msg from one such:

An exception 0E has occurred at 0028:C02AD9D0 in VxD IFSMGR(04) + 000050E4. This was called from 0028:C000B511 in VxD VMM(01) + 0000A511. It may be possible to continue normally.

This occurs whenever a user executes a member of the popen family of functions from within Python; for example, this Python program:

import os
p = os.popen("dir")

popen is a std C library function, poorly implemented by Microsoft, but not *that* poorly <wink>.

You can get our latest installer here:

http://www.pythonlabs.com/tech/python2.0/download.html

As the warning there says:

-----------------
Incompatibility warning: Norton Antivirus 2000 can cause blue screen crashes on Windows 98 when a function in the os.popen*() family is invoked. To prevent this problem, disable Norton Antivirus when using Python. (Confirmed on Windows 98 Second Edition with Norton Antivirus version 6.10.20. The same Norton Antivirus version doesn't have this
problem on Windows 2000. Norton Antivirus version 5 on Windows 98SE doesn't have this problem either.) 
-----------------

ActiveState is seeing the same problem with their derivative work ActivePython, as is PythonWare with their derivative work PythonWorks. So this affects a lot of people. A recent change to the implementation of a popular library module has made it acutely visible recently (didn't use to use popen, but does now).

A workaround would be nice. More importantly, how can I *detect* whether an affected version of NAV is in use, so that we can shut down Python gracefully with an appropriate message before executing any of the popen functions that throw NAV into blue-screen territory? We try to be a very user-friendly language, and we'll do anything to prevent a crash. Alas, right now I don't know how to stop it.

-------------------------------------------------------

Date: 2000-Sep-19 02:21
By: tim_one

Comment:
1. Sent Guido a small self-contained C program in the hope that it's enough to provoke the problem by itself.  Reassigned this bug to Guido since he has to tell me what happens with that next (then assign back to me).

2. That's because Symantec is being no help at all.  They suggest upgrading to NAV 2001(!).  If I can post a tiny C program, maybe it will embarrass then into doing something.  You can follow this soap opera at:

http://servicenews.symantec.com/cgi-bin/displayArticle.cgi?group=symantec.support.win9x.nortonantivirus2000.general&article=57765

-------------------------------------------------------

Date: 2000-Sep-19 09:06
By: gvanrossum

Comment:
Tim's little C program crashes in the same way as Python when NAV2000 is enabled. back to Tim...
-------------------------------------------------------

Date: 2000-Sep-21 11:32
By: tim_one

Comment:
I cranked up my obnoxiousness level on the Symantec board (URL two comments down), and they may be on the edge of taking this seriously now.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114598&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 21:29:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 13:29:26 -0700
Subject: [Python-bugs-list] [Bug #115005] Python 2.0 won't build on HP Unix 10.2
Message-ID: <200009212029.NAA18801@delerium.i.sourceforge.net>

Bug #115005, was updated on 2000-Sep-21 13:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python 2.0 won't build on HP Unix 10.2

Details: Call me at 877 737 7357 X4477  if I can help. ...Bob

With threads (default) at:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c thread.c

get error message:

In file included from thread.c_116:
thread_pthread.h: In function 'PyThread_get_thread_ident':
thread_pthread.h:181: aggreagete value used where an integer was expected




Without threads at:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c

error message is:

./posixmodule.c:713: 'fdatasync' undeclared (first use in this function)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115005&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 21:31:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 13:31:45 -0700
Subject: [Python-bugs-list] [Bug #115006] Python 2.0 won't build on HP Unix 10.2
Message-ID: <200009212031.NAA18992@delerium.i.sourceforge.net>

Bug #115006, was updated on 2000-Sep-21 13:31
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python 2.0 won't build on HP Unix 10.2

Details: Call me at 877 737 7357 X4477  if I can help. ...Bob

With threads (default) at:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c thread.c

get error message:

In file included from thread.c_116:
thread_pthread.h: In function 'PyThread_get_thread_ident':
thread_pthread.h:181: aggreagete value used where an integer was expected




Without threads at:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c

error message is:

./posixmodule.c:713: 'fdatasync' undeclared (first use in this function)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115006&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 22:17:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 14:17:34 -0700
Subject: [Python-bugs-list] [Bug #114923] ToolTip not showing text on AIX 4.3
Message-ID: <200009212117.OAA20867@delerium.i.sourceforge.net>

Bug #114923, was updated on 2000-Sep-20 14:27
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: ToolTip not showing text on AIX 4.3

Details: IDLE0.6 runs nicely on AIX except that the tip text itself does not show when the pop up box appears. The box seems to be sized properly but is blank.

-Robin Friedrich

Follow-Ups:

Date: 2000-Sep-20 16:54
By: gvanrossum

Comment:
Could it be a Tcl version problem? It's hard to debug this... :-(
-------------------------------------------------------

Date: 2000-Sep-21 14:17
By: none

Comment:
Yes I imagine it will be hard to debug. The tclTk version is 8.3.2. I am unaware of problems with that on the X windows platforms. Has this been noticed on other unices with 2.0b1?  --Robin F.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114923&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 22:23:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 14:23:20 -0700
Subject: [Python-bugs-list] [Bug #114923] ToolTip not showing text on AIX 4.3
Message-ID: <200009212123.OAA21072@delerium.i.sourceforge.net>

Bug #114923, was updated on 2000-Sep-20 14:27
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: ToolTip not showing text on AIX 4.3

Details: IDLE0.6 runs nicely on AIX except that the tip text itself does not show when the pop up box appears. The box seems to be sized properly but is blank.

-Robin Friedrich

Follow-Ups:

Date: 2000-Sep-20 16:54
By: gvanrossum

Comment:
Could it be a Tcl version problem? It's hard to debug this... :-(
-------------------------------------------------------

Date: 2000-Sep-21 14:17
By: none

Comment:
Yes I imagine it will be hard to debug. The tclTk version is 8.3.2. I am unaware of problems with that on the X windows platforms. Has this been noticed on other unices with 2.0b1?  --Robin F.
-------------------------------------------------------

Date: 2000-Sep-21 14:23
By: gvanrossum

Comment:
BTW, where do you expect to see tooltips? The only place I can think of is when you type a function name followed by a left paren. Is that it? What function name did you use?

(And yes, this works fine for me on Linux.)

Could it have to do with font? color? Perhaps your window manager?
Source is in CallTipWindow.py if you want to play.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114923&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 22:31:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 14:31:14 -0700
Subject: [Python-bugs-list] [Bug #114830] Writing of Unicode data not portable
Message-ID: <200009212131.OAA29514@bush.i.sourceforge.net>

Bug #114830, was updated on 2000-Sep-19 13:46
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: Writing of Unicode data not portable

Details: In 2.0b1, writing a Unicode object to a socket has an outcome that depends on the endianness of the processor. This is highly undesirable,
and not documented either in the reference manuals. It also break backwards compatibility in hard-to-analyse ways, as the other end of the socket may react strangely when confronted with Python's internal representation of a Unicode object.

Since determination of an encoding must be an application decision, it seems best if attempts to write Unicode objects to sockets produce an exception. To some degree, the same criticism applies to binary files.

Follow-Ups:

Date: 2000-Sep-21 14:31
By: lemburg

Comment:
Fixed by special casing "s#" for Unicode objects: "s#" will not
return the UTF-16 data, but instead the default encoded string
version of the Unicode object.

To access the internal data, either use one of the access macros
or PyObject_AsReadBuffer() (the read buffer interface still exists 
and returns the internal data representation like the buffer interface
defines).

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114830&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 22:34:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 14:34:36 -0700
Subject: [Python-bugs-list] [Bug #114900] Undefined Symbols When Building
Message-ID: <200009212134.OAA21492@delerium.i.sourceforge.net>

Bug #114900, was updated on 2000-Sep-20 10:24
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 1
Summary: Undefined Symbols When Building

Details: I receive the following errors when I attempt to build Python for OpenBSD 2.5:

cd Modules;  make OPT="-g -O2" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
main.c:115: Undefined symbol `_Py_FatalError' referenced from text segment
main.c:125: Undefined symbol `_Py_DebugFlag' referenced from text segment
main.c:130: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:134: Undefined symbol `_Py_OptimizeFlag' referenced from text segment
main.c:138: Undefined symbol `_Py_NoSiteFlag' referenced from text segment
main.c:142: Undefined symbol `_Py_TabcheckFlag' referenced from text segment
main.c:150: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:158: Undefined symbol `_Py_UnicodeFlag' referenced from text segment
main.c:208: Undefined symbol `_Py_FdIsInteractive' referenced from text segment
main.c:232: Undefined symbol `_Py_InteractiveFlag' referenced from text segment
main.c:246: Undefined symbol `_Py_SetProgramName' referenced from text segment
main.c:247: Undefined symbol `_Py_Initialize' referenced from text segment
main.c:249: Undefined symbol `_Py_VerboseFlag' referenced from text segment
main.c:251: Undefined symbol `_Py_GetPlatform' referenced from text segment
main.c:251: Undefined symbol `_Py_GetVersion' referenced from text segment
main.c:261: Undefined symbol `_PySys_SetArgv' referenced from text segment
main.c:266: Undefined symbol `_PyImport_ImportModule' referenced from text segment
main.c:268: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:274: Undefined symbol `_PyRun_SimpleString' referenced from text segment
main.c:283: Undefined symbol `_PyRun_SimpleFile' referenced from text segment
main.c:284: Undefined symbol `_PyErr_Clear' referenced from text segment
main.c:289: Undefined symbol `_PyRun_AnyFileEx' referenced from text segment
main.c:297: Undefined symbol `_PyRun_AnyFile' referenced from text segment
main.c:299: Undefined symbol `_Py_Finalize' referenced from text segment
*** Error code 1

Stop in /home/jpettit/dev/python/dist/src/Modules.
*** Error code 1


This is with a snapshot of the CVS tree from yesterday afternoon.  I tar'd up the directory and built it under Linux fine, so I believe this is particular to OpenBSD.

Follow-Ups:

Date: 2000-Sep-20 12:55
By: loewis

Comment:
Can you check whether pythonrun.o got archived into libpython2.0.a
(ar tv libpython2.0.a), and whether Py_FatalError is exported from pythonrun.o (nm libpython2.0.a and nm pythonrun.o)?

Also, should building the library invoke ranlib on your system? Did it?
-------------------------------------------------------

Date: 2000-Sep-20 13:06
By: jpettit

Comment:
No, "pythonrun.o" was not archived into "libpython2.0.a".  When I run the "nm" command and grep for "Py_FatalError", I get the following:

    [jpettit@bastion src]$ nm libpython2.0.a |grep Py_FatalError
         U _Py_FatalError
         U _Py_FatalError
[jpettit@bastion src]$ nm Python/pythonrun.o |grep Py_FatalError
000019dc T _Py_FatalError


Yes, "ranlib" was invoked a few lines before the compiler croaked:

mv -f buildno1 buildno
gcc -c -g -O2 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno`  ./Modules/getbuildinfo.c
ar cr libpython2.0.a getbuildinfo.o
ranlib libpython2.0.a
true
cd Modules;  make OPT="-g -O2" VERSION="2.0"  prefix="/usr/local" exec_prefix="/usr/local"  LIBRARY=../libpython2.0.a link
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
main.c:115: Undefined symbol `_Py_FatalError' referenced from text segment
...etc, etc...
-------------------------------------------------------

Date: 2000-Sep-20 17:51
By: gvanrossum

Comment:
Could you try starting from scratch ("make clean; make")?

If pythonrun.o is not in libpython2.0.a, something's gone wrong!

What files *are* in libpython2.0.a? ("ar tf").
-------------------------------------------------------

Date: 2000-Sep-21 00:40
By: jpettit

Comment:
I've been doing a "make clean" before I try "make".  In fact, I've even been erasing "config.cache" and running "configure" before the make commands.  One of the interesting things is that when I run "make", it looks like it runs all of the "configure" checks (retrieving the cached values) twice.  I can send you the output from "make" if you like.

Here are the files in "libpython2.0.a" (there doesn't appear to be a "-f" flag for "ar" on OpenBSD):

__.SYMDEF
threadmodule.o
gcmodule.o
bsddbmodule.o
regexmodule.o
regexpr.o
pcremodule.o
pypcre.o
posixmodule.o
signalmodule.o
_sre.o
readline.o
arraymodule.o
cmathmodule.o
mathmodule.o
stropmodule.o
structmodule.o
timemodule.o
operator.o
_codecsmodule.o
unicodedata.o
unicodedatabase.o
ucnhash.o
_localemodule.o
fcntlmodule.o
pwdmodule.o
grpmodule.o
errnomodule.o
selectmodule.o
socketmodule.o
mmapmodule.o
md5module.o
md5c.o
shamodule.o
rotormodule.o
syslogmodule.o
newmodule.o
binascii.o
parsermodule.o
cStringIO.o
cPickle.o
config.o
getpath.o
main.o
getbuildinfo.o

Another thing that I noticed is that an error is raised and ignored immediately before the archive command is run:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H  -c main.c
if test -f hassignal;  then echo removing sigcheck.o intrcheck.o;  ar d ../libpython2.0.a sigcheck.o intrcheck.o 2>/dev/null;  else echo leaving sigcheck.o intrcheck.o in; fi
removing sigcheck.o intrcheck.o
*** Error code 1 (ignored)

-------------------------------------------------------

Date: 2000-Sep-21 07:18
By: gvanrossum

Comment:
That listing was a great clue! It appears that the archive only contains the *last* set of files added to it.

Can you check the man page for ar on your platform? I hope it supports adding files piecemeal -- this is what the Python build process uses.

I wonder if you change "$(AR) cr ..." to $(AR) r ..." in the add2lib target in the various sub-Makefiles -- would this fix things? That would mean that the 'c' option has a different meaning for you than it has for me. On every Unix system I've seen, 'c' just serves to suppress a warning when creating the archive. Maybe on OpenBSD it creates a new empty archive?
-------------------------------------------------------

Date: 2000-Sep-21 10:32
By: jpettit

Comment:
I think that "ar" does what you want.  Here's the man page explanation of the "-c" flag:

-c   Whenever an archive is created, an informational message to that
     effect is written to standard error.  If the -c option is speci-
     fied, ar creates the archive silently.

I was able to build Python 1.6 without any problems.  There was an issue with the "db" library on 2.0b1, but this seems to have been addressed in revision 1.145 of "configure".  The output of "make" is very strange, so I have mailed it directly to Guido, since it is probably too long to post here.  I received an auto-response, so he may want to check his public BeOpen email.
-------------------------------------------------------

Date: 2000-Sep-21 14:34
By: gvanrossum

Comment:
The best explanation I have for this is that the mtimes of various source files on his system were in the future. This caused various Make rules to trigger more than once. In the Make output he sent me, several C source files were also recompiled twice (the second time in the "add2lib" target), and he received a warning that Setup.in was newer than Setup.

Best I can tell, this has nothing to do with OpenBSD 2.5; I could reproduce this myself using rsync from a system whose clock was an hour ahead.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114900&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 22:38:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 14:38:35 -0700
Subject: [Python-bugs-list] [Bug #114792] Document how to report bugs against python
Message-ID: <200009212138.OAA21656@delerium.i.sourceforge.net>

Bug #114792, was updated on 2000-Sep-19 05:27
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 5
Summary: Document how to report bugs against python

Details: 
Why don't you tell people how to report bugs in python on the web site
or the documentation?
 
I'd expect this info in the docs and on the web site for python.


Follow-Ups:

Date: 2000-Sep-21 14:38
By: fdrake

Comment:
Added an appendix to the API manual, Extending & Embedding manual, & Library Reference giving information about how & where to report bugs, and links to articles which describe good bug reporting practices.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114792&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 22:40:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 14:40:25 -0700
Subject: [Python-bugs-list] [Bug #114847] Building Python fails due to readline problem
Message-ID: <200009212140.OAA21685@delerium.i.sourceforge.net>

Bug #114847, was updated on 2000-Sep-19 19:13
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Building Python fails due to readline problem

Details: When I attempt to compile Python with the readline module enabled, I get the following error:

gcc  -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./_sre.c
gcc  -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./readline.c
./readline.c: In function `initreadline':
./readline.c:503: `rl_library_version' undeclared (first use in this function)
./readline.c:503: (Each undeclared identifier is reported only once
./readline.c:503: for each function it appears in.)
*** Error code 1

Stop in /home/jpettit/dev/python/dist/src/Modules.
*** Error code 1

This is an OpenBSD 2.5 x86 system.  

Follow-Ups:

Date: 2000-Sep-19 19:18
By: jpettit

Comment:
I almost forgot: this is using the most current CVS snapshot.
-------------------------------------------------------

Date: 2000-Sep-20 06:25
By: gvanrossum

Comment:
Could you try this again after adding

extern char *rl_library_version;

to readline.c, just after

extern Function *rl_event_hook;

(I'd give you a diff but the SourceForge CVS site appears down today.) 

If this works for you, I'll check it in (presuming SourceForge comes back online :-).
-------------------------------------------------------

Date: 2000-Sep-20 10:17
By: jpettit

Comment:
Yes, that fixed the problem.  I'm still having problems compiling under OpenBSD 2.5, but they are not related to readline, so I will open a new bug report.
-------------------------------------------------------

Date: 2000-Sep-20 13:27
By: gvanrossum

Comment:
Fixed by adding a declaration for rl_library_version.
-------------------------------------------------------

Date: 2000-Sep-21 14:40
By: gvanrossum

Comment:
Postscript: the rl_library_version variable occurs for the first time in readline 2.2. Unfortunately readline offers *no* way to test at compile time what version it is. GNU READLINE TRULY S*CKS!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114847&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 22:41:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 14:41:49 -0700
Subject: [Python-bugs-list] [Bug #115005] Python 2.0 won't build on HP Unix 10.2
Message-ID: <200009212141.OAA21817@delerium.i.sourceforge.net>

Bug #115005, was updated on 2000-Sep-21 13:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Duplicate
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0 won't build on HP Unix 10.2

Details: Call me at 877 737 7357 X4477  if I can help. ...Bob

With threads (default) at:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c thread.c

get error message:

In file included from thread.c_116:
thread_pthread.h: In function 'PyThread_get_thread_ident':
thread_pthread.h:181: aggreagete value used where an integer was expected




Without threads at:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c

error message is:

./posixmodule.c:713: 'fdatasync' undeclared (first use in this function)

Follow-Ups:

Date: 2000-Sep-21 14:41
By: fdrake

Comment:
This is a duplicate of #115006.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115005&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 22:43:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 14:43:29 -0700
Subject: [Python-bugs-list] [Bug #115006] Python 2.0 won't build on HP Unix 10.2
Message-ID: <200009212143.OAA21861@delerium.i.sourceforge.net>

Bug #115006, was updated on 2000-Sep-21 13:31
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0 won't build on HP Unix 10.2

Details: Call me at 877 737 7357 X4477  if I can help. ...Bob

With threads (default) at:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c thread.c

get error message:

In file included from thread.c_116:
thread_pthread.h: In function 'PyThread_get_thread_ident':
thread_pthread.h:181: aggreagete value used where an integer was expected




Without threads at:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c

error message is:

./posixmodule.c:713: 'fdatasync' undeclared (first use in this function)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115006&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 22:56:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 14:56:53 -0700
Subject: [Python-bugs-list] [Bug #115006] Python 2.0 won't build on HP Unix 10.2
Message-ID: <200009212156.OAA22383@delerium.i.sourceforge.net>

Bug #115006, was updated on 2000-Sep-21 13:31
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0 won't build on HP Unix 10.2

Details: Call me at 877 737 7357 X4477  if I can help. ...Bob

With threads (default) at:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c thread.c

get error message:

In file included from thread.c_116:
thread_pthread.h: In function 'PyThread_get_thread_ident':
thread_pthread.h:181: aggreagete value used where an integer was expected




Without threads at:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c

error message is:

./posixmodule.c:713: 'fdatasync' undeclared (first use in this function)

Follow-Ups:

Date: 2000-Sep-21 14:56
By: fdrake

Comment:
Could you please check your system's man page for fdatasync() to and let us know what includes and compile-time defines are needed?  Thanks!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115006&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 22:57:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 14:57:06 -0700
Subject: [Python-bugs-list] [Bug #114532] cgi + <TextArea>.. + xml-data
Message-ID: <200009212157.OAA22386@delerium.i.sourceforge.net>

Bug #114532, was updated on 2000-Sep-15 10:21
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: Works For Me
Bug Group: Irreproducible
Priority: 1
Summary: cgi + <TextArea>.. + xml-data

Details: Hi!

I'm working under linux (mandrake 7.1) using python for my cgi scripts. There I've a formular containing a "textarea". If entering xml- or html-data into this textarea and submitting it the cgi-script doesn't get that xml-data. With non-xml-data everything works fine.

BTW: It's the same with an "input"-field.

ciao
Volker


Follow-Ups:

Date: 2000-Sep-15 10:57
By: gvanrossum

Comment:
Volker,

We cannot help you with this bug unless you provide us with an example we can try ourselves.  We need at least:

1) a simple but complete script that shows the bug (try to pare it down from the script you are using to somehing that demonstrates just the problem)

2) the HTML of the form (ditto)

3) the text you are entering into the form

We also need:

- the Python version
- the browser name and version
- the server name and version

That said, I suspect that the problem is in your script, but without looking at it, I can't tell!

--Guido
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114532&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 23:20:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 15:20:31 -0700
Subject: [Python-bugs-list] [Bug #114746] dis module is not up todate in 2.0b1-#4
Message-ID: <200009212220.PAA23252@delerium.i.sourceforge.net>

Bug #114746, was updated on 2000-Sep-18 14:42
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Works For Me
Bug Group: Irreproducible
Priority: 1
Summary: dis module is not up todate in 2.0b1-#4

Details: While updating freeze I got an index error for an op
that was outside of the dis.opname list.


Follow-Ups:

Date: 2000-Sep-18 15:04
By: gvanrossum

Comment:
Please supply an example -- I don't have a problem using dis.py.
-------------------------------------------------------

Date: 2000-Sep-19 14:34
By: barry-scott

Comment:
I've failed to reproduce the problem with my edits to Freeze. (I got an other exception that not a problem in dis).

-------------------------------------------------------

Date: 2000-Sep-21 15:20
By: gvanrossum

Comment:
Closed -- the submitter can't reproduce it.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114746&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 23:29:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 15:29:37 -0700
Subject: [Python-bugs-list] [Bug #115026] SSL features undocumented
Message-ID: <200009212229.PAA23619@delerium.i.sourceforge.net>

Bug #115026, was updated on 2000-Sep-21 15:29
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: SSL features undocumented

Details: The socket.ssl function, and the SSL objects, are not documented.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115026&group_id=5470

From noreply@sourceforge.net  Thu Sep 21 23:58:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 15:58:23 -0700
Subject: [Python-bugs-list] [Bug #115026] SSL features undocumented
Message-ID: <200009212258.PAA00429@bush.i.sourceforge.net>

Bug #115026, was updated on 2000-Sep-21 15:29
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: SSL features undocumented

Details: The socket.ssl function, and the SSL objects, are not documented.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115026&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 02:24:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 18:24:53 -0700
Subject: [Python-bugs-list] [Bug #115035] SunOS 4.1.4 with GCC 2.95.2 can't compile complete
Message-ID: <200009220124.SAA05676@bush.i.sourceforge.net>

Bug #115035, was updated on 2000-Sep-21 18:24
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: SunOS 4.1.4 with GCC 2.95.2 can't compile complete

Details: 1) Module/posixmodule.c
  In Module/posixmodule.c, it used rename, pclose, fclose but SunOS 4.1.4's unistd.h does not have these definitions. So add them.
2) Modules/mmapmodule.c
  In Modules/mmapmodule.c, MS_SYNC used but SunOS 4.1.4's mman.h does not have this difinition. So add it.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115035&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 02:35:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 18:35:54 -0700
Subject: [Python-bugs-list] [Bug #110648] performance-problem decoding quoted-printable (PR#340)
Message-ID: <200009220135.SAA30347@delerium.i.sourceforge.net>

Bug #110648, was updated on 2000-Jul-31 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Invalid
Bug Group: None
Priority: 4
Summary: performance-problem decoding quoted-printable (PR#340)

Details: Jitterbug-Id: 340
Submitted-By: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= <ragnark@vestdata.no>
Date: Fri, 26 May 2000 16:51:51 +0200
Version: None
OS: None

--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi

Problem on python 1.5.1 on linux 2.2.14aa6.

Decoding quoted-printable files using mimetools.decode is really slow.
The really strange thing is, that it appers to work a lot faster on
smaller files!

I put together a little test-program that reads blocks from a file, and
decodes them individually. (The output will not be 100% correct. The
point was just to test the performance). 

Results show the time it took to decode a 300k file with the diferent
block-sizes:
1k:	6.28 s
3k:	6.59 s
10k:	8.57 s
30k:	30.45 s
100k:	127.82 s
300k:	221.67 s

I looked in quopri.decode for clues about the problem, but could not
find any. Is there something _very_ wrong with my reasoning, or is
something wrong here?



-- 
Ragnar Kjørstad

--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="test.py"

#!/usr/bin/python
from mimetools import decode
from StringIO import StringIO
from sys import stdout, argv
from string import atoi
bsize=atoi(argv[1])
output=StringIO()
f=open("mail-test")
s=f.read(bsize)
while s:
	input=StringIO(s)
	decode(input, output, 'quoted-printable')
	s=f.read(bsize)
	stdout.write('.')
	stdout.flush()
stdout.write('done\n')

--7JfCtLOvnd9MIVvH--



====================================================================
Audit trail:
Tue Jul 11 08:25:57 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-19 09:52
By: loewis

Comment:
I can't reproduce the problem. On  sparc-sun-solaris2.6, Python 1.5.2 needs the same time for a 330k file, regardless of the block size.
-------------------------------------------------------

Date: 2000-Sep-19 11:11
By: gvanrossum

Comment:
Can't reproduce it either. Note he's using Python 1.5.1. Maybe it was a buffering problem in StringIO there - quopri.py is using readline(). Barry, if you don't have another idea, just close it as Invalid.
-------------------------------------------------------

Date: 2000-Sep-21 18:35
By: tim_one

Comment:
I marked this Invalid and Closed.  There *may* have been a buffering problem in 1.5.2 that got fixed, or it may simply be that the original report used an unrealistic input file (which is what I suspect -- gory details below), or both.  But note that the true complaint ("decode is really slow") probably remains valid.

There's *something* still going on here in 2.0b1, at least under Win98SE.  Here's the output from a more self-contained version of the program:

C:\Python20>python mtest.py
      1024        4.6
      2048        6.1
     10240        7.9
     30720        8.8
    102400        8.9
    307200        9.4
      1024        4.5
      2048        5.8
     10240        8.3
     30720        8.9
    102400        9.0
    307200        9.4

C:\Python20>

That's with everything in cache, and there's a very clear & reproducible factor-of-2 advantage to using the small blocksize.  Here's the program:

BIGFILE = "DLLs/tk83.dll"

def timer(fname, blockseq):
    from mimetools import decode
    from StringIO import StringIO
    from time import clock
    for mult in blockseq:
        start = clock()
        bsize = mult * 1024
        output = StringIO()
        f = open(fname, "rb")
        s = f.read(bsize)
        while s:
            input = StringIO(s)
            decode(input, output, 'quoted-printable')
            s = f.read(bsize)
        f.close()
        del output, f, s, input
        finish = clock()
        print "%10d %10.1f" % (bsize, finish - start)

if __name__ == "__main__":
    timer(BIGFILE, (1, 2, 10, 30, 100, 300) * 2)

Of course, I'm reading in a binary file there, so the test makes no real sense!  And I *suspect* the original bug report also used a nonsense file.  Why that's important will become clear soon.

If I interrupt the program at random, it's usually on line 72 of quopri.py:

  File "C:\PYTHON20\lib\quopri.py", line 72, in decode
    new = new + c; i = i+1

That hints at a problem with the quadratic-time nature of repeated appends.  Conventional wisdom is that's just theoretical, but it isn't, and the crossover point is highly platform-dependent.

If I replace the call to decode with:

            while 1:
                line = input.readline()
                if not line:
                    break
                new = ""
                for ch in line:
                    pass
                output.write(line)

then there's no apparent dependence on block size.  So this is not a problem with buffering, it's specific to decode.

But if I replace the "pass" with

new = new + ch

then I get back a very strong dependence on block size.  And that loop is what decode does, except for the useful parts <wink>.

So that explains *my* glitch:  the smaller the blocksize, the more "lines" get artificially created, the smaller the longest lines become, and the less the ch-at-a-time append can hurt.  But this is all an artifact of me using a binary file for input!  That is, it's an artifact of using a test file with nearly arbitrarily long "lines".

If I create a giant 4Mb text file via catenating all the *.html files in the Windows Python doc/lib directory, there is no dependence on blocksize in the test program, other than that it gets a little *faster* the larger the block size.  And that's what I'd expect (repeated catenation is linear-time on all platforms I've heard of, so long as the lines are reasonably short).

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110648&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 02:56:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 18:56:20 -0700
Subject: [Python-bugs-list] [Bug #115035] SunOS 4.1.4 with GCC 2.95.2 can't compile complete
Message-ID: <200009220156.SAA31024@delerium.i.sourceforge.net>

Bug #115035, was updated on 2000-Sep-21 18:24
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: SunOS 4.1.4 with GCC 2.95.2 can't compile complete

Details: 1) Module/posixmodule.c
  In Module/posixmodule.c, it used rename, pclose, fclose but SunOS 4.1.4's unistd.h does not have these definitions. So add them.
2) Modules/mmapmodule.c
  In Modules/mmapmodule.c, MS_SYNC used but SunOS 4.1.4's mman.h does not have this difinition. So add it.


Follow-Ups:

Date: 2000-Sep-21 18:56
By: gvanrossum

Comment:
I'm not sure what the proper solution is here. Can you provide a patch?
Which C preprocessor symbol do I check for to know that I'm on SunOS 4.1.4?

(1) We can't add decls for these funcs unconditionally because it would conflict with decls in unistd.h or elsewhere on other platforms.

(2) What is the proper replacement for MS_SYNC on SunOS 4.1.4?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115035&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 03:53:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 19:53:28 -0700
Subject: [Python-bugs-list] [Bug #115040] sre behavior differes from pre
Message-ID: <200009220253.TAA08799@bush.i.sourceforge.net>

Bug #115040, was updated on 2000-Sep-21 19:53
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sre behavior differes from pre

Details: This may not be a bug, but it caused some regexes of mine that match under pre to fail under sre.

With pre, an embeded flag like "(?x)" can appear anywhere within a regex and it affects the entire regex. In sre, the position of "(?x)" is important; only after it appears does VERBOSE mode seem to be in effect and whitespace is ignored. If people haven't been careful to place the "(?x)" at the very beginning of the regex, VERBOSE regexes with this defect in existing code may fail to match when sre is used as a drop-in replacement for pre.

Also, and in contrast, "(?s)" doen't seem sensitive to position under sre; wherever it appears in the regex, DOTALL seems to affect the entire regex.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115040&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 04:15:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 20:15:32 -0700
Subject: [Python-bugs-list] [Bug #115040] sre behavior differes from pre
Message-ID: <200009220315.UAA09532@bush.i.sourceforge.net>

Bug #115040, was updated on 2000-Sep-21 19:53
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sre behavior differes from pre

Details: This may not be a bug, but it caused some regexes of mine that match under pre to fail under sre.

With pre, an embeded flag like "(?x)" can appear anywhere within a regex and it affects the entire regex. In sre, the position of "(?x)" is important; only after it appears does VERBOSE mode seem to be in effect and whitespace is ignored. If people haven't been careful to place the "(?x)" at the very beginning of the regex, VERBOSE regexes with this defect in existing code may fail to match when sre is used as a drop-in replacement for pre.

Also, and in contrast, "(?s)" doen't seem sensitive to position under sre; wherever it appears in the regex, DOTALL seems to affect the entire regex.


Follow-Ups:

Date: 2000-Sep-21 20:15
By: tim_one

Comment:
Assigned to Fredrik.  FWIW, years ago I never did figure out Perl did in all cases simply by trying stuff; e.g., it's easy to construct cases where whether (?x) is recognized as such depends on whether you're assuming verbose mode or not while you're parsing!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115040&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 04:15:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 20:15:56 -0700
Subject: [Python-bugs-list] [Bug #115040] sre behavior differes from pre
Message-ID: <200009220315.UAA01341@delerium.i.sourceforge.net>

Bug #115040, was updated on 2000-Sep-21 19:53
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sre behavior differes from pre

Details: This may not be a bug, but it caused some regexes of mine that match under pre to fail under sre.

With pre, an embeded flag like "(?x)" can appear anywhere within a regex and it affects the entire regex. In sre, the position of "(?x)" is important; only after it appears does VERBOSE mode seem to be in effect and whitespace is ignored. If people haven't been careful to place the "(?x)" at the very beginning of the regex, VERBOSE regexes with this defect in existing code may fail to match when sre is used as a drop-in replacement for pre.

Also, and in contrast, "(?s)" doen't seem sensitive to position under sre; wherever it appears in the regex, DOTALL seems to affect the entire regex.


Follow-Ups:

Date: 2000-Sep-21 20:15
By: tim_one

Comment:
Assigned to Fredrik.  FWIW, years ago I never did figure out Perl did in all cases simply by trying stuff; e.g., it's easy to construct cases where whether (?x) is recognized as such depends on whether you're assuming verbose mode or not while you're parsing!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115040&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 04:23:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 20:23:24 -0700
Subject: [Python-bugs-list] [Bug #112289] NetBSD1.4.2 build issue
Message-ID: <200009220323.UAA01673@delerium.i.sourceforge.net>

Bug #112289, was updated on 2000-Aug-18 19:50
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 6
Summary: NetBSD1.4.2 build issue

Details: the recent fileobjects.c work done for large files (tmick) appears
broken when compiled against NetBSD1.4.2.

During the final link, you get the following output:

gcc   python.o  ../libpython2.0.a   -lutil -lm  -o python
fileobject.c:280: Undefined symbol `_TELL64' referenced from text segment

Follow-Ups:

Date: 2000-Aug-18 19:55
By: none

Comment:
NOTE:  I didn't include the configure output.  If that
would be helpful, go ahead and indicate that in this
tracking system.

If tmick (or whoever) would like me to contact them directly,
I would happily do so.
-------------------------------------------------------

Date: 2000-Aug-31 08:45
By: tmick

Comment:
Sent to python-dev:

1. Who reported this bug? He talked about providing more information and I
would like to speak with him. I cannot find his email address.
2. Does anybody have a NetBSD1.4.2 (or close) machine that I can get shell
access to? Do you know if they have such a machine at SourceForge that users
can get shell access to? Or failing that can someone with such a machine give
me the full ./configure and make output and maybe run this command:
   find /usr/include -name "*" -type f | xargs -l grep -nH _TELL64
and give me the output.


-------------------------------------------------------

Date: 2000-Aug-31 08:47
By: tmick

Comment:
I got no reponse and I have no NetBSD machine on which to reproduce so, as Jeremy suggested, if I wouldn't get it by this evening then assign back to him.

Other questions:
- How old/recent is version 1.4.2 of NetBSD?
- Where is _TELL64 coming from? Not from Python code.

-------------------------------------------------------

Date: 2000-Sep-06 08:43
By: tmick

Comment:
Thanks to Brad (knotwell@NOSPAM f5 NOSPAM.com) who reported the bug I got shell access on his NetBSD 1.4.2 box to play a little bit. I found the problem but I don&#039;t have the Right (tm) fix. Here is what I found:

The _TELL64 compilation failure is for the #define TELL64 usage in fileobject.c for a 64-bit capable tell() system function. Currently this is only defined and used for Win64. The funny thing is that to get to the code section using TELL64 the NetBSD box had to (1) pass the configure test for HAVE_LARGEFILE_SUPPORT, (2) have sizeof(fpos_t) >= 8, and (3) *not* have fseeko (as required by the Single Unix Specification) or fseek64 defined.

As far as I can tell NetBSD *should* define fseeko() and ftello() if it wants to say that it supports largefiles. I *think* that you can manage it via fsetpos() and fgetpos(), which is what I did for largefile support on Win64 (although on Win64 I still relied on a 64-bit capable tell() function -- hence TELL64).  I don&#039;t have the time right now to get and verify a working fsetpos/fgetpos solution.

A quick fix is to ifdef out HAVE_LARGEFILE_SUPPORT for NetBSD 1.4.2 but I don&#039;t know the proper #define&#039;s for that. It is also ugly.

-------------------------------------------------------

Date: 2000-Sep-15 12:15
By: jhylton

Comment:
Trent -- will you have time to work on this between now and 2.0b2?

-------------------------------------------------------

Date: 2000-Sep-17 20:54
By: tsarna

Comment:
See patch #101558. Probably will need to add other BSDs to the #elif. Many 44BSDs provided 64bit off_t long before they provided f*o() or f*64().


-------------------------------------------------------

Date: 2000-Sep-21 20:23
By: gvanrossum

Comment:
This should be fixed by my recent checkin to fileobject.c of a patch by Ty Sarna.
(Patch #101558, modified for OpenBSD.)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 04:29:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 20:29:24 -0700
Subject: [Python-bugs-list] [Bug #110612] anydbm can't handle dumbdbm (PR#200)
Message-ID: <200009220329.UAA01879@delerium.i.sourceforge.net>

Bug #110612, was updated on 2000-Jul-31 14:05
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: anydbm can't handle dumbdbm (PR#200)

Details: Jitterbug-Id: 200
Submitted-By: aa8vb@yahoo.com
Date: Wed, 9 Feb 2000 13:05:57 -0500 (EST)
Version: 1.5.2
OS: IRIX 6.5


Basically, anydbm won't open dumbdbm files that anydbm created.

   >>> import anydbm
   >>> db = anydbm.open( "database", "c" )
   >>> db[ "1" ] = "one"
   >>> db.close()
   >>> db = anydbm.open( "database", "r" )
   Traceback (innermost last):
     File "<stdin>", line 1, in ?
     File "/home/rhh/software/python-1.5.2/lib/python1.5/anydbm.py", line 80,
in
 open
       raise error, "need 'c' or 'n' flag to open new db"
   anydbm.error: need 'c' or 'n' flag to open new db

More details can be found in the c.l.python thread "anydbm - a simple
question".

I searched for a matching bug and didn't find one in the database.  Also,
I verified my whichdb.py matches what's currently in CVS, so I don't think
this has been fixed yet.

Thanks,

Randall


====================================================================
Audit trail:
Wed Feb 23 21:40:05 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 02:24
By: moshez

Comment:
It was a simple glitch in whichdb -- it didn't recognize the
dumbdbm format. Fixed it.

-------------------------------------------------------

Date: 2000-Sep-15 16:22
By: none

Comment:
I think this bug has appeared again. I get the exact same error with Python 1.6, but it works with 1.5.2.


-------------------------------------------------------

Date: 2000-Sep-15 17:15
By: gvanrossum

Comment:
Reopened and assigned to Jeremy since a comment claims it's reappeared in 1.6.  Can you check 2.0?
-------------------------------------------------------

Date: 2000-Sep-17 04:24
By: loewis

Comment:
The following script works for me, in 2.0b1

>>> import dumbdbm
>>> dumbdbm.open("/tmp/hhh","c")
<dumbdbm._Database instance at 0x829eaac>
>>> s=_
>>> s['a']='b'
>>> s.close()
>>> import whichdb
>>> whichdb.whichdb("/tmp/hhh")
'dumbdbm'
>>> import anydbm
>>> s=anydbm.open("/tmp/hhh")
>>> s

So it works for me, on i586-pc-linux-gnu.

-------------------------------------------------------

Date: 2000-Sep-21 20:29
By: gvanrossum

Comment:
Fixed in 2.0. Indeed broken in 1.6, but that's water under the bridge.
Am closing this for Jeremy.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110612&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 04:33:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 20:33:29 -0700
Subject: [Python-bugs-list] [Bug #110641] KeyboardInterrupt while waiting for sys.ps2 input kills interpreter (PR#309)
Message-ID: <200009220333.UAA02017@delerium.i.sourceforge.net>

Bug #110641, was updated on 2000-Jul-31 14:09
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Duplicate
Bug Group: Platform-specific
Priority: 5
Summary: KeyboardInterrupt while waiting for sys.ps2 input kills interpreter (PR#309)

Details: Jitterbug-Id: 309
Submitted-By: skip@mojam.com
Date: Fri, 28 Apr 2000 17:00:40 -0400 (EDT)
Version: 1.5.2, 1.6a2
OS: Linux


If you hit Ctrl-C while the Python interpreter is sitting at the ps2 prompt the
interpreter exits instead of returning you to the top-level prompt.

% python
Python 1.5.2+ (#12, Feb 17 2000, 14:52:05)  [GCC pgcc-2.91.66 19990314
(egcs-1.1.2 release)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> if 1:
... 

% PYTHONSTARTUP= ./python
Python 1.6a2 (#7, Apr 24 2000, 23:02:54)  [GCC pgcc-2.91.66 19990314 (egcs-1.1.2
release)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> if 1:
... 

When run under gdb's control, you can see what's happening:

% gdb ./python
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-mandrake-linux"...
(gdb) set env PYTHONSTARTUP ""
(gdb) run
Starting program: /home/beluga/skip/src/python/dist/src/./python 
Python 1.6a2 (#7, Apr 24 2000, 23:02:54)  [GCC pgcc-2.91.66 19990314 (egcs-1.1.2
release)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> if 1:
... 
Program received signal SIGINT, Interrupt.
0x4013bf14 in __libc_read () from /lib/libc.so.6
(gdb) bt
#0  0x4013bf14 in __libc_read () from /lib/libc.so.6
(gdb) c
Continuing.

  File "<stdin>", line 2
    
    ^
SyntaxError: invalid syntax
>>> 

It appears that SIGINT isn't handled properly when awaiting console input in
certain circumstances.  If you can entice the program to continue, things work
okay.  I don't know interrupt handling from a hole in the ground or I'd
investigate further.  It is quite annoying, especially considering that
Python's input history isn't continuous across sessions...


Skip





====================================================================
Audit trail:
Mon May 22 17:23:42 2000	guido	changed notes
Mon May 22 17:23:42 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:40
By: twouters

Comment:
This seems to be platform specific: On Linux, up-to-date CVS compile, this is reproducible. On BSDI 4.1, however, with an almost-up-to-date CVS compile, ^C doesn't exit the interpreter.

-------------------------------------------------------

Date: 2000-Aug-06 04:57
By: twouters

Comment:
Oh, and it's also definately readline-related. (without readline compiled in, the bug doesn't get triggered, in any case.)

-------------------------------------------------------

Date: 2000-Aug-09 08:59
By: twouters

Comment:
I've been toying with this, and the problem *is* readline. Readline overrides a number of signal handlers, in order to do cleanup when exiting, and apparently does not restore them on exit :-S The signals readline 'overrides' the handlers of are:

SIGINT
SIGALRM
SIGTSTP
SIGTTOU
SIGTTIN
SIGTERM
SIGWINCH

Which means that the signal handlers for these signals *vanish* when using readline. Interactive mode uses readline, but scripts can themselves, too. I'm not sure why this isn't showing on BSDI, but it might have something to do with the BSD vs the SysV signal handling routines. I'm also not sure if it's possible to fix this problem; it might be a bug in readline, or it might be documented behaviour. But I wasn't able to find a reference to signal handling in the 2.2.1 readline info files.

-------------------------------------------------------

Date: 2000-Sep-21 20:33
By: gvanrossum

Comment:
I'm quite confident that this was fixed by my checkin (last Sunday) to deal with the mixing of signal() and sigaction(), which makes it a duplicate of bug #110611.
I'm closing this for Thomas.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110641&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 04:46:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 20:46:06 -0700
Subject: [Python-bugs-list] [Bug #110695] complexobject.c optimization error on SGI (PR#144)
Message-ID: <200009220346.UAA02386@delerium.i.sourceforge.net>

Bug #110695, was updated on 2000-Jul-31 14:28
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: Remind
Bug Group: Platform-specific
Priority: 1
Summary: complexobject.c optimization error on SGI (PR#144)

Details: Jitterbug-Id: 144
Submitted-By: robert.harrison@pnl.gov
Date: Fri, 3 Dec 1999 01:35:19 -0500 (EST)
Version: 1.5.2
OS: IRIX64 6.5


On an SGI (IRIX64 6.5, MIPSpro Compilers: Version 7.3.1m, -n32)
Python-1.5.2/Objects/complexobject.c does not compile correctly 
with optimization.  The problem shows up as a bus error in
PyComplex_ImagAsDouble when importing Numeric Python.  All works fine 
when this one file is compiled with -O0 (-O1 and higher fail).
I assume that this is probably just a compiler error.




====================================================================
Audit trail:
Fri Dec 03 10:39:28 1999	guido	changed notes
Fri Dec 03 10:39:28 1999	guido	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 15:02
By: bwarsaw

Comment:
Assigning to Fred, but we really need somebody with the specified OS to do platform specific testing.
-------------------------------------------------------

Date: 2000-Sep-16 15:10
By: fdrake

Comment:
Sent a message to the original submitter asking if this is still a problem, and indicated that we don't have access to any SGI IRIX systems on which to perform testing.
-------------------------------------------------------

Date: 2000-Sep-21 20:46
By: gvanrossum

Comment:
Set priority really low. SGI optimizer bugs are a common pain, but not worth losing sleep over.
Maybe just close it with "Wont Fix"?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110695&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 04:46:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 20:46:06 -0700
Subject: [Python-bugs-list] [Bug #115026] SSL features undocumented
Message-ID: <200009220346.UAA02385@delerium.i.sourceforge.net>

Bug #115026, was updated on 2000-Sep-21 15:29
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: Later
Bug Group: None
Priority: 3
Summary: SSL features undocumented

Details: The socket.ssl function, and the SSL objects, are not documented.

Follow-Ups:

Date: 2000-Sep-21 20:46
By: fdrake

Comment:
Low priority for 2.0, but reasonable patches will be considered.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115026&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 04:49:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 20:49:18 -0700
Subject: [Python-bugs-list] [Bug #111802] anydbm cannot verify shelve database type
Message-ID: <200009220349.UAA02528@delerium.i.sourceforge.net>

Bug #111802, was updated on 2000-Aug-13 10:05
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Duplicate
Bug Group: Trash
Priority: 5
Summary: anydbm cannot verify shelve database type

Details: 	When opening an existing "shelve" database file.  An exception is raised from anydbm saying "the database type could not be determined".  

Follow-Ups:

Date: 2000-Aug-24 06:18
By: moshez

Comment:
This sounds like the bug I fixed in whichdb (it couldn't recognize Python's dumbdbm). Assigned to me so I can deal with it (i.e., verify that it does happen on old Python, and doesn't happen to the CVS version). 
-------------------------------------------------------

Date: 2000-Sep-21 20:49
By: gvanrossum

Comment:
Closed -- this has got to be the same one as bug #110612.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=111802&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 04:57:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 20:57:58 -0700
Subject: [Python-bugs-list] [Bug #110705] combination of socket.gethostbyname and os.system hangs program (PR#401)
Message-ID: <200009220357.UAA11083@bush.i.sourceforge.net>

Bug #110705, was updated on 2000-Jul-31 14:29
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: combination of socket.gethostbyname and os.system hangs program (PR#401)

Details: Jitterbug-Id: 401
Submitted-By: andyg@one.net.au
Date: Mon, 17 Jul 2000 04:26:12 -0400 (EDT)
Version: Python 1.5.2 (#3, Jun 29 2000, 15:52:04)  [GCC 2.8.1] on sunos5
OS: SunOS psol002 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise


A combination of socket.gethostbyname and os.system appears to hang
python intermittently.  We run Dec and Sun systems - it only appears
to be a problem with sun systems.

The following is the simplest way I can reproduce the problem:

test.py:
--------------------------------
#!/usr/local/bin/python
import os
import socket
print socket.gethostbyname( "a hostname (but not localhost)" )
os.system("echo fred")

hang.sh:
--------------------------------
#!/bin/ksh
while true ; do
  ./test.py
done

output:
---------------------------------
10.666.666.666
fred
10.666.666.666
fred
... eventually ...
10.666.666.666
<hung>

If "a hostname" is "localhost" it doesn't hang.  For anything else which it 
can successfully resolve, it seems to hang.

Thanks !
Andy.



====================================================================
Audit trail:
Mon Jul 24 18:39:07 2000	jeremy	changed notes
Mon Jul 24 18:39:07 2000	jeremy	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-12 08:58
By: jhylton

Comment:
attempt to contact the original submittor

-------------------------------------------------------

Date: 2000-Sep-21 20:57
By: gvanrossum

Comment:
Ask if the Sun system is a multi CPU system. It could be the dual CPU bug in disguise.
Otherwise I have no clue how this could be a bug in Python (more likely a platform C library interaction), so am lowering the priority.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110705&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 05:16:41 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 21:16:41 -0700
Subject: [Python-bugs-list] [Bug #110843] Low FD_SETSIZE limit on Win32 (PR#41)
Message-ID: <200009220416.VAA11614@bush.i.sourceforge.net>

Bug #110843, was updated on 2000-Aug-01 14:15
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Low FD_SETSIZE limit on Win32 (PR#41)

Details: Jitterbug-Id: 41
Submitted-By: brian@digicool.com
Date: Fri, 30 Jul 1999 10:10:49 -0400 (EDT)
Version: 1.5.2
OS: NT


It appears that win32 has a default limit of 64 descriptors that 
can be handed to the select() function. This is pretty low for
any serious async servers, and causes them to raise lots of errors
under very moderate loads.

We at DC ran into this using Medusa as a basis for ZServer, which
serves Zope sites. It turns out that you can actually add a define
when compiling the python15.dll for windows to bump the default
fd limit to a more reasonable level.

The approach _I_ took was to add the define: FD_SETSIZE=1024
to the preprocessor options in the MSVC project settings for
python15.dll, though I imagine you could also roll the define
into config.h or something (so long as it's defined before
windows.h or any of the select / socket include files are
referenced). It would make life much easier for win32 server
developers if this define could find its way into the next
official python release :^)

Thanks!


Brian Lloyd        brian@digicool.com
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com 




====================================================================
Audit trail:
Fri Jul 30 10:43:41 1999	guido	moved from incoming to request

Follow-Ups:

Date: 2000-Aug-30 23:19
By: mhammond

Comment:
I am a little worried that adding it to config.h may have side-effects when Python is embedded in other projects with their own socket config (eg, Mozilla :-)

Now that socket and select are external .pyd modules, will it be sufficient to only add it to these extension modules?
-------------------------------------------------------

Date: 2000-Sep-21 21:16
By: tim_one

Comment:
Changed summary to say "Win32" instead of "NT", as this is a general Win32 issue.

Mark, did you email your question directly to Brian?  (This bug got moved over from Jitterbug, so he didn't see your note otherwise.)

I certainly agree Python can't go changing the MS default value in any way visible from Python.h (which #includes config.h).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110843&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 06:33:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 22:33:54 -0700
Subject: [Python-bugs-list] [Bug #115051] Dodgy use of PyTuple_SET_ITEM in pyexpat.c
Message-ID: <200009220533.WAA06109@delerium.i.sourceforge.net>

Bug #115051, was updated on 2000-Sep-21 22:33
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Dodgy use of PyTuple_SET_ITEM in pyexpat.c

Details: CVS Python 2.0b1 (22 Sept) - Modules/pyexpat.c produces the following warning
when compiled, indicating dodgy use of PyTuple_SET_ITEM (testing return value, when it doesn't):
cc: Warning: ./pyexpat.c, line 425: In this statement, "0" of type "int", is being converted to "pointer to struct _object". (cvtdiftypes)
    if (PyTuple_SET_ITEM(arg, 0, bytes) < 0)
--------^

For context:

    if ((arg = PyTuple_New(1)) == NULL)
        goto finally;

    if (PyTuple_SET_ITEM(arg, 0, bytes) < 0)
        goto finally;

    if ((str = PyObject_CallObject(meth, arg)) == NULL)
        goto finally;


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115051&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 07:01:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 23:01:31 -0700
Subject: [Python-bugs-list] [Bug #115051] Dodgy use of PyTuple_SET_ITEM in pyexpat.c
Message-ID: <200009220601.XAA06950@delerium.i.sourceforge.net>

Bug #115051, was updated on 2000-Sep-21 22:33
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: Dodgy use of PyTuple_SET_ITEM in pyexpat.c

Details: CVS Python 2.0b1 (22 Sept) - Modules/pyexpat.c produces the following warning
when compiled, indicating dodgy use of PyTuple_SET_ITEM (testing return value, when it doesn't):
cc: Warning: ./pyexpat.c, line 425: In this statement, "0" of type "int", is being converted to "pointer to struct _object". (cvtdiftypes)
    if (PyTuple_SET_ITEM(arg, 0, bytes) < 0)
--------^

For context:

    if ((arg = PyTuple_New(1)) == NULL)
        goto finally;

    if (PyTuple_SET_ITEM(arg, 0, bytes) < 0)
        goto finally;

    if ((str = PyObject_CallObject(meth, arg)) == NULL)
        goto finally;


Follow-Ups:

Date: 2000-Sep-21 23:01
By: tim_one

Comment:
Fixed in rev 2.20.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115051&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 07:01:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 23:01:25 -0700
Subject: [Python-bugs-list] [Bug #115054] test_minidom has a tab....
Message-ID: <200009220601.XAA06947@delerium.i.sourceforge.net>

Bug #115054, was updated on 2000-Sep-21 23:01
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: test_minidom has a tab....

Details: line 232 in cvs has a tab that results in a exceptions.TabError: inconsistent use of tabs and spaces in indentation.

Line in question is:

# commented out until Fredrick's fix is checked in
def _testElementReprAndStrUnicodeNS():
    dom=Document()
    el=dom.appendChild(
	 dom.createElementNS( u"http://www.slashdot.org", u"slash:abc" ))

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115054&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 07:23:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 23:23:05 -0700
Subject: [Python-bugs-list] [Bug #115056] __init__.py has tab ==> indention error
Message-ID: <200009220623.XAA16000@bush.i.sourceforge.net>

Bug #115056, was updated on 2000-Sep-21 23:23
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: __init__.py has tab ==> indention error

Details: [wolfeden:python/dist/src] lobo% ./python.exe -tt ./Lib/test/test_minidom.py
Traceback (most recent call last):
  File "./Lib/test/test_minidom.py", line 3, in ?
    from xml.dom.minidom import parse, Node, Document, parseString
  File "./Lib/xml/dom/minidom.py", line 1, in ?
    import pulldom
  File "./Lib/xml/dom/pulldom.py", line 5, in ?
    import xml.sax
  File "./Lib/xml/sax/__init__.py", line 73
    return _create_parser(parser_name)
                                     ^
TabError: inconsistent use of tabs and spaces in indentation

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115056&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 07:39:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Sep 2000 23:39:17 -0700
Subject: [Python-bugs-list] [Bug #115057] -program-suffix=SUFFIX not respected
Message-ID: <200009220639.XAA08285@delerium.i.sourceforge.net>

Bug #115057, was updated on 2000-Sep-21 23:39
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: -program-suffix=SUFFIX not respected

Details: Attempting to build under Mac OS X (a case insensitive system) requires that you use the .exe suffix.  Attempting to configure with -program-suffix=.exe doesn't do the right thing and you have to manually change a) src/makefile and b) src/Modules/Makefile lines
# Use ``EXE=.exe'' for Unix emulations on DOS/Windows
EXE=
to 
EXE=.exe

In addition, src/Modules/Makefile lines

# This target is used by the master Makefile to link the final binary.
link:		$(MAINOBJ)
		$(LINKCC) $(LDFLAGS) $(LINKFORSHARED) $(MAINOBJ) \
		  $(LDLIBRARY) $(MODLIBS) $(LIBS) $(SYSLIBS) -o python $(LDLAST)
		mv python$(EXE) ../python$(EXE)

need to be changed to
  $(LDLIBRARY) $(MODLIBS) $(LIBS) $(SYSLIBS) -o python$(EXE) $(LDLAST)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115057&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 10:15:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 02:15:11 -0700
Subject: [Python-bugs-list] [Bug #115076] threads of __del__
Message-ID: <200009220915.CAA13954@delerium.i.sourceforge.net>

Bug #115076, was updated on 2000-Sep-22 02:15
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: threads of __del__

Details: I suspect (but have not proved) that the support for destroying deeply recursive structures can allow for an instances __del__ method to get called in a thread other than the one in which it lost its last reference.

This can happen if it switches to a different thread during deletion of a deeply recursive structure (with _PyTrash_delete_later not empty). 

Should Python guarantee that this does not happen? (I say yes - it is important for COM clients)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115076&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 10:17:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 02:17:43 -0700
Subject: [Python-bugs-list] [Bug #115077] configure.in broken for HP-UX 11 w/ HP ANSI compiler
Message-ID: <200009220917.CAA14076@delerium.i.sourceforge.net>

Bug #115077, was updated on 2000-Sep-22 02:17
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: configure.in broken for HP-UX 11 w/ HP ANSI compiler

Details: If you have any questions, feel free to contact Stefan Norberg (stnor@sweden.hp.com).

Python/getargs.c fails to build because limits.h is not included by default.

$ uname -a
HP-UX robinson B.11.00 A 9000/800 534706537 two-user license

$ diff -u configure.in.orig configure.in
--- configure.in.orig   Fri Sep 22 11:16:30 2000
+++ configure.in        Fri Sep 22 11:17:05 2000
@@ -201,7 +201,7 @@
 case $ac_sys_system in
 hp*|HP*)
     case $CC in
-    cc|*/cc) CC="$CC -Aa -D_HPUX_SOURCE";;
+    cc|*/cc) CC="$CC -Ae";;
     esac;;
 BeOS*)
        case $CC in

--------------------------------------

-Ae is needed to get longlong support (see manpage below). And longlong support is needed in Include/longobject.h for it to include <limits.h>.

From Include/longobject.h:
#ifdef HAVE_LONG_LONG

#ifdef HAVE_LIMITS_H
#include <limits.h>
#endif

-------------------------
$ man cc
....
cc(1)                                                                 cc(1)
                 Requires Optional ANSI C Compiler Software

                        e    (Default) Extended ANSI mode.  Same as -Aa
                             -D_HPUX_SOURCE +e.  This would define the names
                             (macros and typedefs) provided by the HP-UX
                             Operating System and, in addition, allow the
                             following extensions: $ characters in
                             identifier names, sized enums, sized bit-
                             fields, and 64-bit integral type long long.
                             Additional extensions may be added to this
                             option in the future.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115077&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 10:26:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 02:26:17 -0700
Subject: [Python-bugs-list] [Bug #115054] test_minidom has a tab....
Message-ID: <200009220926.CAA14346@delerium.i.sourceforge.net>

Bug #115054, was updated on 2000-Sep-21 23:01
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 1
Summary: test_minidom has a tab....

Details: line 232 in cvs has a tab that results in a exceptions.TabError: inconsistent use of tabs and spaces in indentation.

Line in question is:

# commented out until Fredrick's fix is checked in
def _testElementReprAndStrUnicodeNS():
    dom=Document()
    el=dom.appendChild(
	 dom.createElementNS( u"http://www.slashdot.org", u"slash:abc" ))

Follow-Ups:

Date: 2000-Sep-22 02:26
By: gvanrossum

Comment:
The line with the tab does *not* cause a TabError exception! You never tested this, right?! It is inside matching parentheses and thus not subject to the indentation rules.

However since it's clearly a mistake (it's the only tab in the file!) I've checked in a change. Revision 1.7.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115054&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 10:31:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 02:31:09 -0700
Subject: [Python-bugs-list] [Bug #115056] __init__.py has tab ==> indention error
Message-ID: <200009220931.CAA14540@delerium.i.sourceforge.net>

Bug #115056, was updated on 2000-Sep-21 23:23
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: __init__.py has tab ==> indention error

Details: [wolfeden:python/dist/src] lobo% ./python.exe -tt ./Lib/test/test_minidom.py
Traceback (most recent call last):
  File "./Lib/test/test_minidom.py", line 3, in ?
    from xml.dom.minidom import parse, Node, Document, parseString
  File "./Lib/xml/dom/minidom.py", line 1, in ?
    import pulldom
  File "./Lib/xml/dom/pulldom.py", line 5, in ?
    import xml.sax
  File "./Lib/xml/sax/__init__.py", line 73
    return _create_parser(parser_name)
                                     ^
TabError: inconsistent use of tabs and spaces in indentation

Follow-Ups:

Date: 2000-Sep-22 02:31
By: gvanrossum

Comment:
You're right! Fixed now.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115056&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 10:32:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 02:32:30 -0700
Subject: [Python-bugs-list] [Bug #115057] -program-suffix=SUFFIX not respected
Message-ID: <200009220932.CAA14554@delerium.i.sourceforge.net>

Bug #115057, was updated on 2000-Sep-21 23:39
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: -program-suffix=SUFFIX not respected

Details: Attempting to build under Mac OS X (a case insensitive system) requires that you use the .exe suffix.  Attempting to configure with -program-suffix=.exe doesn't do the right thing and you have to manually change a) src/makefile and b) src/Modules/Makefile lines
# Use ``EXE=.exe'' for Unix emulations on DOS/Windows
EXE=
to 
EXE=.exe

In addition, src/Modules/Makefile lines

# This target is used by the master Makefile to link the final binary.
link:		$(MAINOBJ)
		$(LINKCC) $(LDFLAGS) $(LINKFORSHARED) $(MAINOBJ) \
		  $(LDLIBRARY) $(MODLIBS) $(LIBS) $(SYSLIBS) -o python $(LDLAST)
		mv python$(EXE) ../python$(EXE)

need to be changed to
  $(LDLIBRARY) $(MODLIBS) $(LIBS) $(SYSLIBS) -o python$(EXE) $(LDLAST)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115057&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 10:52:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 02:52:33 -0700
Subject: [Python-bugs-list] [Bug #115076] threads of __del__
Message-ID: <200009220952.CAA15336@delerium.i.sourceforge.net>

Bug #115076, was updated on 2000-Sep-22 02:15
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: threads of __del__

Details: I suspect (but have not proved) that the support for destroying deeply recursive structures can allow for an instances __del__ method to get called in a thread other than the one in which it lost its last reference.

This can happen if it switches to a different thread during deletion of a deeply recursive structure (with _PyTrash_delete_later not empty). 

Should Python guarantee that this does not happen? (I say yes - it is important for COM clients)

Follow-Ups:

Date: 2000-Sep-22 02:52
By: gvanrossum

Comment:
Agreed that this would be a problem if it could cause an inconsistent state of the trashcan (at the end of object.c) structure. However, since the "trash" code is all executed with the global interpreter lock held, I don't see that there can be a problem. Here's why:

The code in _PyTrash_deposit_object() doesn't make any calls that could invoke __del__, so it's safe. The code in _PyTrash_destroy_chain() makes exactly one call to Py_DECREF(), but it takes care that its global data structures are consistent at this point. For a second I thought that _PyTrash_delete_later would have to be declared volatile, but on second thought I don't: the Py_DECREF() macro expands to a possible (indirect) function call, signaling the compiler that the global _PyTrash_delete_later may be changed in arbitrary ways.

Assigned to Tim Peters to verify my reasoning, because of his superior mind in reasoning about threads and race conditions.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115076&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 10:56:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 02:56:03 -0700
Subject: [Python-bugs-list] [Bug #110665] Compiling python on hpux 11.00 with threads (PR#360)
Message-ID: <200009220956.CAA15477@delerium.i.sourceforge.net>

Bug #110665, was updated on 2000-Jul-31 14:12
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Compiling python on hpux 11.00 with threads (PR#360)

Details: Jitterbug-Id: 360
Submitted-By: philipp.jocham@salomon.at
Date: Fri, 16 Jun 2000 08:47:06 -0400 (EDT)
Version: 1.5.2
OS: HP-UX 11.00


There are two missing details in the configure process to make this work
out of the box.

First: The function 
	pthread_create
isn't found in library libpthread.a but in libcma.a, because
pthread_create is just a macro in sys/pthread.h pointing to 
	__pthread_create_system

After patching ./configure directly and running 
	./configure --with-thread
(now detecting the correct library /usr/lib/libpthread.a) I also
added -lcl to Modules/Makefile at
	LIBS=           -lnet -lnsl -ldld  -lpthread -lcl

otherwise importing of modules with threads didn't work 
(in this case oci_.sl from DCOracle). 

I'm not sure about the correct syntax or wether it's the correct
place and method, but I would suggest a solution like the following
code snippet.

[...]
AC_MSG_CHECKING(for --with-thread)
[...]
AC_DEFINE(_POSIX_THREADS)
LIBS="$LIBS -lpthread -lcl"
LIBOBJS="$LIBOBJS thread.o"], [
AC_CHECK_LIB(pthread, __pthread_create_system, [AC_DEFINE(WITH_THREAD)
[...]

I hope this helps to make installation process smoother.
Fell free to contact me, if there are further questions.
Philipp
-- 
I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-22 02:56
By: gvanrossum

Comment:
Taking this because I'm considering to redesign the thread configuration section in configure.in anyway -- there's a similar bug report for Alpha OSF1.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110665&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 10:57:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 02:57:13 -0700
Subject: [Python-bugs-list] [Bug #115077] configure.in broken for HP-UX 11 w/ HP ANSI compiler
Message-ID: <200009220957.CAA15490@delerium.i.sourceforge.net>

Bug #115077, was updated on 2000-Sep-22 02:17
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: configure.in broken for HP-UX 11 w/ HP ANSI compiler

Details: If you have any questions, feel free to contact Stefan Norberg (stnor@sweden.hp.com).

Python/getargs.c fails to build because limits.h is not included by default.

$ uname -a
HP-UX robinson B.11.00 A 9000/800 534706537 two-user license

$ diff -u configure.in.orig configure.in
--- configure.in.orig   Fri Sep 22 11:16:30 2000
+++ configure.in        Fri Sep 22 11:17:05 2000
@@ -201,7 +201,7 @@
 case $ac_sys_system in
 hp*|HP*)
     case $CC in
-    cc|*/cc) CC="$CC -Aa -D_HPUX_SOURCE";;
+    cc|*/cc) CC="$CC -Ae";;
     esac;;
 BeOS*)
        case $CC in

--------------------------------------

-Ae is needed to get longlong support (see manpage below). And longlong support is needed in Include/longobject.h for it to include <limits.h>.

From Include/longobject.h:
#ifdef HAVE_LONG_LONG

#ifdef HAVE_LIMITS_H
#include <limits.h>
#endif

-------------------------
$ man cc
....
cc(1)                                                                 cc(1)
                 Requires Optional ANSI C Compiler Software

                        e    (Default) Extended ANSI mode.  Same as -Aa
                             -D_HPUX_SOURCE +e.  This would define the names
                             (macros and typedefs) provided by the HP-UX
                             Operating System and, in addition, allow the
                             following extensions: $ characters in
                             identifier names, sized enums, sized bit-
                             fields, and 64-bit integral type long long.
                             Additional extensions may be added to this
                             option in the future.


Follow-Ups:

Date: 2000-Sep-22 02:57
By: gvanrossum

Comment:
Assigned to myself because I plan to attack the configure.in mess later today to deal with threads on HP-UX and OSF1 anyway.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115077&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 11:02:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 03:02:08 -0700
Subject: [Python-bugs-list] [Bug #110650] [HP-UX] python with-threads core-dumps (PR#342)
Message-ID: <200009221002.DAA15661@delerium.i.sourceforge.net>

Bug #110650, was updated on 2000-Jul-31 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: [HP-UX] python with-threads core-dumps (PR#342)

Details: Jitterbug-Id: 342
Submitted-By: michael.exner@mrz.uni-magdeburg.de
Date: Wed, 31 May 2000 09:43:38 -0400 (EDT)
Version: 1.5.2
OS: hpux-11.00


When I compile python with threads python core-dumps:
$ ./python
pthread_mutex_init: Invalid argument
Memory fault(coredump)
without thread-support everything works fine
I tried this with hpux-ansi-c and with gcc (2.95.2) but got the same result




====================================================================
Audit trail:
Tue Jul 11 08:25:57 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-28 20:43
By: tim_one

Comment:
Note that the only call to pthread_mutex_init Python makes is in function PyThread_allocate_lock in file phread_pthread.h.  If Python compiled at all, it's extremely unlikely that the first argument is in error.  It's very likely that the second argument is in error, though:  there were many imcompatible revisions of the pthreads std, and pthread_mutexattr_default is a macro conditionally defined near the top of the file.  If this OS actually support pthreads, you have to figure out which *version* of pthreads it defines and arrange for config to define the *correct* one of the

PY_PTHREAD_D4
PY_PTHREAD_D7
PY_PTHREAD_STD
PY_PTHREAD_D6

symbols for your platform.  Else disable threads entirely.
-------------------------------------------------------

Date: 2000-Aug-29 07:34
By: memaul

Comment:
Goto link below for instructions and patches for building
python 152 with threads on hpux 10.20

http://memaul.tripod.com/index.html
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-15 02:34
By: harripasanen

Comment:
I can verify that the bug exists not only in 1.5.2 but also in 1.6.

gcc 2.95.2
HPUX 11.00

I'll see if tim_one's suggestions help.

Regards,

Harri Pasanen
-------------------------------------------------------

Date: 2000-Sep-15 04:55
By: harripasanen

Comment:
The problems seems to be that configure gets the libraries wrong on HP-UX 11.0.   It links with -lcma, when it should link with -lpthread.

So a quick and dirty solution is to relink the python by hand, replacing -lcma with -lpthread.

-------------------------------------------------------

Date: 2000-Sep-15 10:04
By: fdrake

Comment:
Noted that this is HP-UX specific in summary.
-------------------------------------------------------

Date: 2000-Sep-22 03:02
By: gvanrossum

Comment:
Assigned to myself because this is another one about thread configuration on HP-UX, which I plan to tackle. Note that Harri (hi, Harri!) contradicts what another HP-UX bug report (#110665) says -- Harri says you shouldn't link with -lcma, the other says you should. (Or does it? It's ambiguous!)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110650&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 11:03:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 03:03:13 -0700
Subject: [Python-bugs-list] [Bug #115006] Python 2.0 won't build on HP Unix 10.2
Message-ID: <200009221003.DAA15767@delerium.i.sourceforge.net>

Bug #115006, was updated on 2000-Sep-21 13:31
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0 won't build on HP Unix 10.2

Details: Call me at 877 737 7357 X4477  if I can help. ...Bob

With threads (default) at:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c thread.c

get error message:

In file included from thread.c_116:
thread_pthread.h: In function 'PyThread_get_thread_ident':
thread_pthread.h:181: aggreagete value used where an integer was expected




Without threads at:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c

error message is:

./posixmodule.c:713: 'fdatasync' undeclared (first use in this function)

Follow-Ups:

Date: 2000-Sep-21 14:56
By: fdrake

Comment:
Could you please check your system's man page for fdatasync() to and let us know what includes and compile-time defines are needed?  Thanks!
-------------------------------------------------------

Date: 2000-Sep-22 03:03
By: gvanrossum

Comment:
Assigned to me. Suspect it's a duplicate of #110650 and #110665.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115006&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 11:04:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 03:04:49 -0700
Subject: [Python-bugs-list] [Bug #114324] Minor build problems on HPUX for 2.0b1
Message-ID: <200009221004.DAA15791@delerium.i.sourceforge.net>

Bug #114324, was updated on 2000-Sep-13 02:20
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: Minor build problems on HPUX for 2.0b1

Details: Build problems on HPUX10.20/HPUX11.00:

  - There seems to be no prototype for "fdatasync" in any include file
    although it has a man page and it is present in libc (so HAVE_FDATASYNC
    is set). As a result posixmodule.c fails to compile.
   
    Adding a prototype "extern int fdatasync(int);" to posixmodule.c solves 
    this problem, but it may not be portable.
    
  - Modules/mmapmodule.c is missing a "#include <limits.h>"
  
Build problems on HPUX10.20 only:

  - When configured with threading support (default), the cast to (long)
    on line 181 of Python/thread_pthread.h fails. The reason is that
    pthread_t is a struct type. The "configure" test that tries to find out
    the size of pthread_t failed because it tries to cast '0' to a pthread_t,
    so SIZEOF_PTHREAD_T remains undefined.
    
    I suggest changing this line in configure.in:
    
    AC_TRY_COMPILE([#include <pthread.h>], [pthread_t x; x = (pthread_t)0;], have_pthread_t=yes)
    
    to
    
    AC_TRY_COMPILE([#include <pthread.h>], [pthread_t x; x = *(pthread_t*)0;], have_pthread_t=yes)
    
My compiler settings:

   setenv CC 'c89 +DA1.1 +Onolimit -D_HPUX_SOURCE'

Regards,

Eddy

Follow-Ups:

Date: 2000-Sep-16 10:01
By: gvanrossum

Comment:
Randomly assigned to Jeremy for further investigation.
-------------------------------------------------------

Date: 2000-Sep-22 03:04
By: gvanrossum

Comment:
Assigned back to me because I'm planning to tackle HP build problems.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114324&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 11:05:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 03:05:10 -0700
Subject: [Python-bugs-list] [Bug #115076] threads of __del__
Message-ID: <200009221005.DAA23645@bush.i.sourceforge.net>

Bug #115076, was updated on 2000-Sep-22 02:15
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: threads of __del__

Details: I suspect (but have not proved) that the support for destroying deeply recursive structures can allow for an instances __del__ method to get called in a thread other than the one in which it lost its last reference.

This can happen if it switches to a different thread during deletion of a deeply recursive structure (with _PyTrash_delete_later not empty). 

Should Python guarantee that this does not happen? (I say yes - it is important for COM clients)

Follow-Ups:

Date: 2000-Sep-22 02:52
By: gvanrossum

Comment:
Agreed that this would be a problem if it could cause an inconsistent state of the trashcan (at the end of object.c) structure. However, since the "trash" code is all executed with the global interpreter lock held, I don't see that there can be a problem. Here's why:

The code in _PyTrash_deposit_object() doesn't make any calls that could invoke __del__, so it's safe. The code in _PyTrash_destroy_chain() makes exactly one call to Py_DECREF(), but it takes care that its global data structures are consistent at this point. For a second I thought that _PyTrash_delete_later would have to be declared volatile, but on second thought I don't: the Py_DECREF() macro expands to a possible (indirect) function call, signaling the compiler that the global _PyTrash_delete_later may be changed in arbitrary ways.

Assigned to Tim Peters to verify my reasoning, because of his superior mind in reasoning about threads and race conditions.
-------------------------------------------------------

Date: 2000-Sep-22 03:05
By: htrd

Comment:
I agree there is no self-consistency problem with the trashcan, however......

The code in _PyTrash_destroy_chain can call an objects __del__ method, which can release the interpreter lock.

A second thread may then reenter _PyTrash_destroy_chain and continue to clean up the first thread's garbage. (the first thread is safely blocked inside the Py_DECREF)

Yes the garbage gets cleaned up, however it happens in the wrong thread.

I suggest that _PyTrash_delete_later should be part of pyThreadState



-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115076&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 11:08:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 03:08:47 -0700
Subject: [Python-bugs-list] [Bug #115076] threads of __del__
Message-ID: <200009221008.DAA15925@delerium.i.sourceforge.net>

Bug #115076, was updated on 2000-Sep-22 02:15
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: threads of __del__

Details: I suspect (but have not proved) that the support for destroying deeply recursive structures can allow for an instances __del__ method to get called in a thread other than the one in which it lost its last reference.

This can happen if it switches to a different thread during deletion of a deeply recursive structure (with _PyTrash_delete_later not empty). 

Should Python guarantee that this does not happen? (I say yes - it is important for COM clients)

Follow-Ups:

Date: 2000-Sep-22 02:52
By: gvanrossum

Comment:
Agreed that this would be a problem if it could cause an inconsistent state of the trashcan (at the end of object.c) structure. However, since the "trash" code is all executed with the global interpreter lock held, I don't see that there can be a problem. Here's why:

The code in _PyTrash_deposit_object() doesn't make any calls that could invoke __del__, so it's safe. The code in _PyTrash_destroy_chain() makes exactly one call to Py_DECREF(), but it takes care that its global data structures are consistent at this point. For a second I thought that _PyTrash_delete_later would have to be declared volatile, but on second thought I don't: the Py_DECREF() macro expands to a possible (indirect) function call, signaling the compiler that the global _PyTrash_delete_later may be changed in arbitrary ways.

Assigned to Tim Peters to verify my reasoning, because of his superior mind in reasoning about threads and race conditions.
-------------------------------------------------------

Date: 2000-Sep-22 03:05
By: htrd

Comment:
I agree there is no self-consistency problem with the trashcan, however......

The code in _PyTrash_destroy_chain can call an objects __del__ method, which can release the interpreter lock.

A second thread may then reenter _PyTrash_destroy_chain and continue to clean up the first thread's garbage. (the first thread is safely blocked inside the Py_DECREF)

Yes the garbage gets cleaned up, however it happens in the wrong thread.

I suggest that _PyTrash_delete_later should be part of pyThreadState



-------------------------------------------------------

Date: 2000-Sep-22 03:08
By: gvanrossum

Comment:
And why, exactly, would it be a problem that the trash is deleted in the 'wrong" thread? It's just trash. Any thread can delete it.

Or am I missing something?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115076&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 11:27:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 03:27:24 -0700
Subject: [Python-bugs-list] [Bug #115076] threads of __del__
Message-ID: <200009221027.DAA24394@bush.i.sourceforge.net>

Bug #115076, was updated on 2000-Sep-22 02:15
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: threads of __del__

Details: I suspect (but have not proved) that the support for destroying deeply recursive structures can allow for an instances __del__ method to get called in a thread other than the one in which it lost its last reference.

This can happen if it switches to a different thread during deletion of a deeply recursive structure (with _PyTrash_delete_later not empty). 

Should Python guarantee that this does not happen? (I say yes - it is important for COM clients)

Follow-Ups:

Date: 2000-Sep-22 02:52
By: gvanrossum

Comment:
Agreed that this would be a problem if it could cause an inconsistent state of the trashcan (at the end of object.c) structure. However, since the "trash" code is all executed with the global interpreter lock held, I don't see that there can be a problem. Here's why:

The code in _PyTrash_deposit_object() doesn't make any calls that could invoke __del__, so it's safe. The code in _PyTrash_destroy_chain() makes exactly one call to Py_DECREF(), but it takes care that its global data structures are consistent at this point. For a second I thought that _PyTrash_delete_later would have to be declared volatile, but on second thought I don't: the Py_DECREF() macro expands to a possible (indirect) function call, signaling the compiler that the global _PyTrash_delete_later may be changed in arbitrary ways.

Assigned to Tim Peters to verify my reasoning, because of his superior mind in reasoning about threads and race conditions.
-------------------------------------------------------

Date: 2000-Sep-22 03:05
By: htrd

Comment:
I agree there is no self-consistency problem with the trashcan, however......

The code in _PyTrash_destroy_chain can call an objects __del__ method, which can release the interpreter lock.

A second thread may then reenter _PyTrash_destroy_chain and continue to clean up the first thread's garbage. (the first thread is safely blocked inside the Py_DECREF)

Yes the garbage gets cleaned up, however it happens in the wrong thread.

I suggest that _PyTrash_delete_later should be part of pyThreadState



-------------------------------------------------------

Date: 2000-Sep-22 03:08
By: gvanrossum

Comment:
And why, exactly, would it be a problem that the trash is deleted in the 'wrong" thread? It's just trash. Any thread can delete it.

Or am I missing something?
-------------------------------------------------------

Date: 2000-Sep-22 03:27
By: htrd

Comment:
There are two cases that I have in mind:

First is that of a COM client.

It depends on the COM threading model in use, but this problem applies in the most common threading model which is also the default threading model using Mark Hammond's pythoncom.

It is only permitted to access a reference to a COM object from the thread in which it is created. This restiction applies to the Release() method that is used by pythoncom to release its reference to the COM server.


Secondly, it is common to use a dictionary keyed by thread.get_ident() to provide thread-local storage. This is used extensively in Zope. Any application that uses this type of thread-local storage in a __del__ is likely to be broken.



-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115076&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 14:30:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 06:30:29 -0700
Subject: [Python-bugs-list] [Bug #115076] threads of __del__
Message-ID: <200009221330.GAA31149@bush.i.sourceforge.net>

Bug #115076, was updated on 2000-Sep-22 02:15
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: threads of __del__

Details: I suspect (but have not proved) that the support for destroying deeply recursive structures can allow for an instances __del__ method to get called in a thread other than the one in which it lost its last reference.

This can happen if it switches to a different thread during deletion of a deeply recursive structure (with _PyTrash_delete_later not empty). 

Should Python guarantee that this does not happen? (I say yes - it is important for COM clients)

Follow-Ups:

Date: 2000-Sep-22 02:52
By: gvanrossum

Comment:
Agreed that this would be a problem if it could cause an inconsistent state of the trashcan (at the end of object.c) structure. However, since the "trash" code is all executed with the global interpreter lock held, I don't see that there can be a problem. Here's why:

The code in _PyTrash_deposit_object() doesn't make any calls that could invoke __del__, so it's safe. The code in _PyTrash_destroy_chain() makes exactly one call to Py_DECREF(), but it takes care that its global data structures are consistent at this point. For a second I thought that _PyTrash_delete_later would have to be declared volatile, but on second thought I don't: the Py_DECREF() macro expands to a possible (indirect) function call, signaling the compiler that the global _PyTrash_delete_later may be changed in arbitrary ways.

Assigned to Tim Peters to verify my reasoning, because of his superior mind in reasoning about threads and race conditions.
-------------------------------------------------------

Date: 2000-Sep-22 03:05
By: htrd

Comment:
I agree there is no self-consistency problem with the trashcan, however......

The code in _PyTrash_destroy_chain can call an objects __del__ method, which can release the interpreter lock.

A second thread may then reenter _PyTrash_destroy_chain and continue to clean up the first thread's garbage. (the first thread is safely blocked inside the Py_DECREF)

Yes the garbage gets cleaned up, however it happens in the wrong thread.

I suggest that _PyTrash_delete_later should be part of pyThreadState



-------------------------------------------------------

Date: 2000-Sep-22 03:08
By: gvanrossum

Comment:
And why, exactly, would it be a problem that the trash is deleted in the 'wrong" thread? It's just trash. Any thread can delete it.

Or am I missing something?
-------------------------------------------------------

Date: 2000-Sep-22 03:27
By: htrd

Comment:
There are two cases that I have in mind:

First is that of a COM client.

It depends on the COM threading model in use, but this problem applies in the most common threading model which is also the default threading model using Mark Hammond's pythoncom.

It is only permitted to access a reference to a COM object from the thread in which it is created. This restiction applies to the Release() method that is used by pythoncom to release its reference to the COM server.


Secondly, it is common to use a dictionary keyed by thread.get_ident() to provide thread-local storage. This is used extensively in Zope. Any application that uses this type of thread-local storage in a __del__ is likely to be broken.



-------------------------------------------------------

Date: 2000-Sep-22 06:30
By: gvanrossum

Comment:
It sounds that it will be hard to enforce that __del__ is called in the constructing thread even without the complication of the trashcan code.

Explicitly referencing thread-specific data in a __del__ seems silly -- if the object is tied so closely to the thread, why not add a pointer to the thread to the object.

Nevertheless, especially the COM thing sounds like it would be a good thing to prevent this if it is possible, and your solution (make the trashcan state part of the thread state) sounds reasonable -- except that it means that every deallocation of a tuple, list, dict, frame or traceback needs yet another call to PyThreadState_Get(). And, most disturbing of all, we found before releasing 2.0b1 that there are situations where dictionaries (and possibly other objects) are used when there is no current thread state!!!

Replacing one theoretical problem with another not-so-theoretical one doesn't seem right. Perhaps we could invent a flag that prevents thread-switches while the trashcan dealloc code is running? This could be a simple global boolean that, when set, stops the ceval main loop (and the BEGIN/END ALLOW THREADS macros and related functions!) from ever yielding the interpreter loop. It would almost never be triggered in practice, but guarantee safety in worst cases -- if not efficiency (other threads would be completely blocked until the trashcan code is done).

Back to Tim...
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115076&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 15:32:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 07:32:16 -0700
Subject: [Python-bugs-list] [Bug #113773] Python 2.0b1 selectmodule compile error under Redhat 5.2
Message-ID: <200009221432.HAA01051@bush.i.sourceforge.net>

Bug #113773, was updated on 2000-Sep-06 18:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0b1 selectmodule compile error under Redhat 5.2

Details: Environment: Redhat 5.2 running the gcc compiler that comes with the
distribution (gcc 2.7.2.3).

'make' failed when compiling selectmodule.c ('./configure' ran ok)because
the following constants were undefined:

POLLRDNORM, POLLRDBAND, POLLWRBAND

The /usr/include/sys/poll.h file does not contain these constants.
Under Redhat 6.2 the constants are defined in the /usr/include/bits/poll.h
file (which is not present in the Redhat 5.2 distribution).

I used the Redhat 6.2 poll.h file and the selectmodule compiled (under
Redhat 5.2) but got the following error when running 
'make test' (it looks like it might be related to the compile problem):

test test_poll crashed -- select.error: (9, 'Bad file descriptor')

1 test failed: test_poll



Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 23:08
By: tim_one

Comment:
Boosted the priority and assigned to Fred.  Don't know what you can do about an older Redhat build problem, and it's not clear that the test failure isn't simply due to mixing files across OS releases.  I'm inclined to blame it on the OS.
-------------------------------------------------------

Date: 2000-Sep-15 13:11
By: fdrake

Comment:
I've asked SourceForge if there are ways to use older versions of operating systems on their compile farm.  Until then, we'll need a volunteer with a RH5.2 system to help with this.

Stuart:  Are you willing to test a patch if I mail it to you?  Thanks.
-------------------------------------------------------

Date: 2000-Sep-15 19:50
By: fdrake

Comment:
SourceForge will try and provide a RH5.2 installation for us; now that's service!
-------------------------------------------------------

Date: 2000-Sep-20 22:33
By: fdrake

Comment:
Reducing priority since the platform is old and we still don't have access to it.
-------------------------------------------------------

Date: 2000-Sep-22 07:32
By: fdrake

Comment:
For the record, SF stills plans to attempt to provide a RH5.2 installation / "virtual environment" we can use, but the person who handles it says it will be this weekend or next week before he can get to it.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113773&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 15:52:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 07:52:39 -0700
Subject: [Python-bugs-list] [Bug #115076] threads of __del__
Message-ID: <200009221452.HAA26543@delerium.i.sourceforge.net>

Bug #115076, was updated on 2000-Sep-22 02:15
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: threads of __del__

Details: I suspect (but have not proved) that the support for destroying deeply recursive structures can allow for an instances __del__ method to get called in a thread other than the one in which it lost its last reference.

This can happen if it switches to a different thread during deletion of a deeply recursive structure (with _PyTrash_delete_later not empty). 

Should Python guarantee that this does not happen? (I say yes - it is important for COM clients)

Follow-Ups:

Date: 2000-Sep-22 02:52
By: gvanrossum

Comment:
Agreed that this would be a problem if it could cause an inconsistent state of the trashcan (at the end of object.c) structure. However, since the "trash" code is all executed with the global interpreter lock held, I don't see that there can be a problem. Here's why:

The code in _PyTrash_deposit_object() doesn't make any calls that could invoke __del__, so it's safe. The code in _PyTrash_destroy_chain() makes exactly one call to Py_DECREF(), but it takes care that its global data structures are consistent at this point. For a second I thought that _PyTrash_delete_later would have to be declared volatile, but on second thought I don't: the Py_DECREF() macro expands to a possible (indirect) function call, signaling the compiler that the global _PyTrash_delete_later may be changed in arbitrary ways.

Assigned to Tim Peters to verify my reasoning, because of his superior mind in reasoning about threads and race conditions.
-------------------------------------------------------

Date: 2000-Sep-22 03:05
By: htrd

Comment:
I agree there is no self-consistency problem with the trashcan, however......

The code in _PyTrash_destroy_chain can call an objects __del__ method, which can release the interpreter lock.

A second thread may then reenter _PyTrash_destroy_chain and continue to clean up the first thread's garbage. (the first thread is safely blocked inside the Py_DECREF)

Yes the garbage gets cleaned up, however it happens in the wrong thread.

I suggest that _PyTrash_delete_later should be part of pyThreadState



-------------------------------------------------------

Date: 2000-Sep-22 03:08
By: gvanrossum

Comment:
And why, exactly, would it be a problem that the trash is deleted in the 'wrong" thread? It's just trash. Any thread can delete it.

Or am I missing something?
-------------------------------------------------------

Date: 2000-Sep-22 03:27
By: htrd

Comment:
There are two cases that I have in mind:

First is that of a COM client.

It depends on the COM threading model in use, but this problem applies in the most common threading model which is also the default threading model using Mark Hammond's pythoncom.

It is only permitted to access a reference to a COM object from the thread in which it is created. This restiction applies to the Release() method that is used by pythoncom to release its reference to the COM server.


Secondly, it is common to use a dictionary keyed by thread.get_ident() to provide thread-local storage. This is used extensively in Zope. Any application that uses this type of thread-local storage in a __del__ is likely to be broken.



-------------------------------------------------------

Date: 2000-Sep-22 06:30
By: gvanrossum

Comment:
It sounds that it will be hard to enforce that __del__ is called in the constructing thread even without the complication of the trashcan code.

Explicitly referencing thread-specific data in a __del__ seems silly -- if the object is tied so closely to the thread, why not add a pointer to the thread to the object.

Nevertheless, especially the COM thing sounds like it would be a good thing to prevent this if it is possible, and your solution (make the trashcan state part of the thread state) sounds reasonable -- except that it means that every deallocation of a tuple, list, dict, frame or traceback needs yet another call to PyThreadState_Get(). And, most disturbing of all, we found before releasing 2.0b1 that there are situations where dictionaries (and possibly other objects) are used when there is no current thread state!!!

Replacing one theoretical problem with another not-so-theoretical one doesn't seem right. Perhaps we could invent a flag that prevents thread-switches while the trashcan dealloc code is running? This could be a simple global boolean that, when set, stops the ceval main loop (and the BEGIN/END ALLOW THREADS macros and related functions!) from ever yielding the interpreter loop. It would almost never be triggered in practice, but guarantee safety in worst cases -- if not efficiency (other threads would be completely blocked until the trashcan code is done).

Back to Tim...
-------------------------------------------------------

Date: 2000-Sep-22 07:52
By: htrd

Comment:
There is a patch to move the trashcan into the thread state. see http://sourceforge.net/patch/?func=detailpatch&patch_id=101606&group_id=5470

This uses PyThreadState_GET() once to avoid the extra function call in the normal path, and only uses the trashcan if the thread state is non NULL. (assuming we are never deleting deeply recursive objects with no thread state)

On performance, this gives me a 2% increase in pystones....

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115076&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 16:38:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 08:38:51 -0700
Subject: [Python-bugs-list] [Bug #115057] -program-suffix=SUFFIX not respected
Message-ID: <200009221538.IAA28319@delerium.i.sourceforge.net>

Bug #115057, was updated on 2000-Sep-21 23:39
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: -program-suffix=SUFFIX not respected

Details: Attempting to build under Mac OS X (a case insensitive system) requires that you use the .exe suffix.  Attempting to configure with -program-suffix=.exe doesn't do the right thing and you have to manually change a) src/makefile and b) src/Modules/Makefile lines
# Use ``EXE=.exe'' for Unix emulations on DOS/Windows
EXE=
to 
EXE=.exe

In addition, src/Modules/Makefile lines

# This target is used by the master Makefile to link the final binary.
link:		$(MAINOBJ)
		$(LINKCC) $(LDFLAGS) $(LINKFORSHARED) $(MAINOBJ) \
		  $(LDLIBRARY) $(MODLIBS) $(LIBS) $(SYSLIBS) -o python $(LDLAST)
		mv python$(EXE) ../python$(EXE)

need to be changed to
  $(LDLIBRARY) $(MODLIBS) $(LIBS) $(SYSLIBS) -o python$(EXE) $(LDLAST)

Follow-Ups:

Date: 2000-Sep-22 08:38
By: gvanrossum

Comment:
Fixed the Makefiles as you suggest and add a --witg-suffix=.... option to the configure script.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115057&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 17:03:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 09:03:40 -0700
Subject: [Python-bugs-list] [Bug #115006] Python 2.0 won't build on HP Unix 10.2
Message-ID: <200009221603.JAA04798@bush.i.sourceforge.net>

Bug #115006, was updated on 2000-Sep-21 13:31
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0 won't build on HP Unix 10.2

Details: Call me at 877 737 7357 X4477  if I can help. ...Bob

With threads (default) at:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c thread.c

get error message:

In file included from thread.c_116:
thread_pthread.h: In function 'PyThread_get_thread_ident':
thread_pthread.h:181: aggreagete value used where an integer was expected




Without threads at:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c

error message is:

./posixmodule.c:713: 'fdatasync' undeclared (first use in this function)

Follow-Ups:

Date: 2000-Sep-21 14:56
By: fdrake

Comment:
Could you please check your system's man page for fdatasync() to and let us know what includes and compile-time defines are needed?  Thanks!
-------------------------------------------------------

Date: 2000-Sep-22 03:03
By: gvanrossum

Comment:
Assigned to me. Suspect it's a duplicate of #110650 and #110665.
-------------------------------------------------------

Date: 2000-Sep-22 09:03
By: gvanrossum

Comment:
Bob, I've checked in a fix for fdatasync. Can you test that? I'm also working on the thread configuration, but that'll take longer.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115006&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 17:04:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 09:04:37 -0700
Subject: [Python-bugs-list] [Bug #114324] Minor build problems on HPUX for 2.0b1
Message-ID: <200009221604.JAA04817@bush.i.sourceforge.net>

Bug #114324, was updated on 2000-Sep-13 02:20
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: Minor build problems on HPUX for 2.0b1

Details: Build problems on HPUX10.20/HPUX11.00:

  - There seems to be no prototype for "fdatasync" in any include file
    although it has a man page and it is present in libc (so HAVE_FDATASYNC
    is set). As a result posixmodule.c fails to compile.
   
    Adding a prototype "extern int fdatasync(int);" to posixmodule.c solves 
    this problem, but it may not be portable.
    
  - Modules/mmapmodule.c is missing a "#include <limits.h>"
  
Build problems on HPUX10.20 only:

  - When configured with threading support (default), the cast to (long)
    on line 181 of Python/thread_pthread.h fails. The reason is that
    pthread_t is a struct type. The "configure" test that tries to find out
    the size of pthread_t failed because it tries to cast '0' to a pthread_t,
    so SIZEOF_PTHREAD_T remains undefined.
    
    I suggest changing this line in configure.in:
    
    AC_TRY_COMPILE([#include <pthread.h>], [pthread_t x; x = (pthread_t)0;], have_pthread_t=yes)
    
    to
    
    AC_TRY_COMPILE([#include <pthread.h>], [pthread_t x; x = *(pthread_t*)0;], have_pthread_t=yes)
    
My compiler settings:

   setenv CC 'c89 +DA1.1 +Onolimit -D_HPUX_SOURCE'

Regards,

Eddy

Follow-Ups:

Date: 2000-Sep-16 10:01
By: gvanrossum

Comment:
Randomly assigned to Jeremy for further investigation.
-------------------------------------------------------

Date: 2000-Sep-22 03:04
By: gvanrossum

Comment:
Assigned back to me because I'm planning to tackle HP build problems.
-------------------------------------------------------

Date: 2000-Sep-22 09:04
By: gvanrossum

Comment:
I've checked in a fix for fdatasync. Can you test that?
I'm also working on the thread config, that'll take longer.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114324&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 17:17:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 09:17:51 -0700
Subject: [Python-bugs-list] [Bug #115077] configure.in broken for HP-UX 11 w/ HP ANSI compiler
Message-ID: <200009221617.JAA29737@delerium.i.sourceforge.net>

Bug #115077, was updated on 2000-Sep-22 02:17
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: configure.in broken for HP-UX 11 w/ HP ANSI compiler

Details: If you have any questions, feel free to contact Stefan Norberg (stnor@sweden.hp.com).

Python/getargs.c fails to build because limits.h is not included by default.

$ uname -a
HP-UX robinson B.11.00 A 9000/800 534706537 two-user license

$ diff -u configure.in.orig configure.in
--- configure.in.orig   Fri Sep 22 11:16:30 2000
+++ configure.in        Fri Sep 22 11:17:05 2000
@@ -201,7 +201,7 @@
 case $ac_sys_system in
 hp*|HP*)
     case $CC in
-    cc|*/cc) CC="$CC -Aa -D_HPUX_SOURCE";;
+    cc|*/cc) CC="$CC -Ae";;
     esac;;
 BeOS*)
        case $CC in

--------------------------------------

-Ae is needed to get longlong support (see manpage below). And longlong support is needed in Include/longobject.h for it to include <limits.h>.

From Include/longobject.h:
#ifdef HAVE_LONG_LONG

#ifdef HAVE_LIMITS_H
#include <limits.h>
#endif

-------------------------
$ man cc
....
cc(1)                                                                 cc(1)
                 Requires Optional ANSI C Compiler Software

                        e    (Default) Extended ANSI mode.  Same as -Aa
                             -D_HPUX_SOURCE +e.  This would define the names
                             (macros and typedefs) provided by the HP-UX
                             Operating System and, in addition, allow the
                             following extensions: $ characters in
                             identifier names, sized enums, sized bit-
                             fields, and 64-bit integral type long long.
                             Additional extensions may be added to this
                             option in the future.


Follow-Ups:

Date: 2000-Sep-22 02:57
By: gvanrossum

Comment:
Assigned to myself because I plan to attack the configure.in mess later today to deal with threads on HP-UX and OSF1 anyway.
-------------------------------------------------------

Date: 2000-Sep-22 09:17
By: gvanrossum

Comment:
Checked in the change to the compiler options as suggested. Please test!
(We're also making changes to include <limits.h> unconditionally.)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115077&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 17:18:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 09:18:03 -0700
Subject: [Python-bugs-list] [Bug #115077] configure.in broken for HP-UX 11 w/ HP ANSI compiler
Message-ID: <200009221618.JAA29740@delerium.i.sourceforge.net>

Bug #115077, was updated on 2000-Sep-22 02:17
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: configure.in broken for HP-UX 11 w/ HP ANSI compiler

Details: If you have any questions, feel free to contact Stefan Norberg (stnor@sweden.hp.com).

Python/getargs.c fails to build because limits.h is not included by default.

$ uname -a
HP-UX robinson B.11.00 A 9000/800 534706537 two-user license

$ diff -u configure.in.orig configure.in
--- configure.in.orig   Fri Sep 22 11:16:30 2000
+++ configure.in        Fri Sep 22 11:17:05 2000
@@ -201,7 +201,7 @@
 case $ac_sys_system in
 hp*|HP*)
     case $CC in
-    cc|*/cc) CC="$CC -Aa -D_HPUX_SOURCE";;
+    cc|*/cc) CC="$CC -Ae";;
     esac;;
 BeOS*)
        case $CC in

--------------------------------------

-Ae is needed to get longlong support (see manpage below). And longlong support is needed in Include/longobject.h for it to include <limits.h>.

From Include/longobject.h:
#ifdef HAVE_LONG_LONG

#ifdef HAVE_LIMITS_H
#include <limits.h>
#endif

-------------------------
$ man cc
....
cc(1)                                                                 cc(1)
                 Requires Optional ANSI C Compiler Software

                        e    (Default) Extended ANSI mode.  Same as -Aa
                             -D_HPUX_SOURCE +e.  This would define the names
                             (macros and typedefs) provided by the HP-UX
                             Operating System and, in addition, allow the
                             following extensions: $ characters in
                             identifier names, sized enums, sized bit-
                             fields, and 64-bit integral type long long.
                             Additional extensions may be added to this
                             option in the future.


Follow-Ups:

Date: 2000-Sep-22 02:57
By: gvanrossum

Comment:
Assigned to myself because I plan to attack the configure.in mess later today to deal with threads on HP-UX and OSF1 anyway.
-------------------------------------------------------

Date: 2000-Sep-22 09:17
By: gvanrossum

Comment:
Checked in the change to the compiler options as suggested. Please test!
(We're also making changes to include <limits.h> unconditionally.)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115077&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 17:36:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 09:36:03 -0700
Subject: [Python-bugs-list] [Bug #115112] can you post release files on sourceforge?
Message-ID: <200009221636.JAA30469@delerium.i.sourceforge.net>

Bug #115112, was updated on 2000-Sep-22 09:36
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: can you post release files on sourceforge?

Details: I would like to download them at the source. Thank you very much.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115112&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 17:41:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 09:41:21 -0700
Subject: [Python-bugs-list] [Bug #114324] Minor build problems on HPUX for 2.0b1
Message-ID: <200009221641.JAA06184@bush.i.sourceforge.net>

Bug #114324, was updated on 2000-Sep-13 02:20
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: Minor build problems on HPUX for 2.0b1

Details: Build problems on HPUX10.20/HPUX11.00:

  - There seems to be no prototype for "fdatasync" in any include file
    although it has a man page and it is present in libc (so HAVE_FDATASYNC
    is set). As a result posixmodule.c fails to compile.
   
    Adding a prototype "extern int fdatasync(int);" to posixmodule.c solves 
    this problem, but it may not be portable.
    
  - Modules/mmapmodule.c is missing a "#include <limits.h>"
  
Build problems on HPUX10.20 only:

  - When configured with threading support (default), the cast to (long)
    on line 181 of Python/thread_pthread.h fails. The reason is that
    pthread_t is a struct type. The "configure" test that tries to find out
    the size of pthread_t failed because it tries to cast '0' to a pthread_t,
    so SIZEOF_PTHREAD_T remains undefined.
    
    I suggest changing this line in configure.in:
    
    AC_TRY_COMPILE([#include <pthread.h>], [pthread_t x; x = (pthread_t)0;], have_pthread_t=yes)
    
    to
    
    AC_TRY_COMPILE([#include <pthread.h>], [pthread_t x; x = *(pthread_t*)0;], have_pthread_t=yes)
    
My compiler settings:

   setenv CC 'c89 +DA1.1 +Onolimit -D_HPUX_SOURCE'

Regards,

Eddy

Follow-Ups:

Date: 2000-Sep-16 10:01
By: gvanrossum

Comment:
Randomly assigned to Jeremy for further investigation.
-------------------------------------------------------

Date: 2000-Sep-22 03:04
By: gvanrossum

Comment:
Assigned back to me because I'm planning to tackle HP build problems.
-------------------------------------------------------

Date: 2000-Sep-22 09:04
By: gvanrossum

Comment:
I've checked in a fix for fdatasync. Can you test that?
I'm also working on the thread config, that'll take longer.
-------------------------------------------------------

Date: 2000-Sep-22 09:41
By: edg

Comment:
The fix for fdatasync works.
However, I think it's better to use __hpux instead of __hppa to detect HP-UX.
(__hppa identifies the processor architecture).

FYI: The native cc/c89 compiler defines both __hppa and __hpux.
Gcc additionally defines hppa and hpux.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114324&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 18:03:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 10:03:33 -0700
Subject: [Python-bugs-list] [Bug #115112] can you post release files on sourceforge?
Message-ID: <200009221703.KAA07102@bush.i.sourceforge.net>

Bug #115112, was updated on 2000-Sep-22 09:36
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: None
Bug Group: None
Priority: 5
Summary: can you post release files on sourceforge?

Details: I would like to download them at the source. Thank you very much.

Follow-Ups:

Date: 2000-Sep-22 10:03
By: gvanrossum

Comment:
We prefer to make them available through the PythonLabs.com website. After all BeOpen pays our salaries.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115112&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 18:10:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 10:10:42 -0700
Subject: [Python-bugs-list] [Bug #114749] HTML docs: mark off-site links
Message-ID: <200009221710.KAA31767@delerium.i.sourceforge.net>

Bug #114749, was updated on 2000-Sep-18 15:05
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 4
Summary: HTML docs: mark off-site links

Details: The module index is empty.
In the library the contents is empty.

The tag <tex2html_anchor_invisible_mark> appears in lots of the .html files.

The encode() method is not documented for strings.

No docs on unicode strings in lib ref like the strings module.

Please mark links that leave the local machine. For example the link to "Python How-To Guides".


Follow-Ups:

Date: 2000-Sep-18 20:38
By: fdrake

Comment:
The "".encode() method is documented in the latest documentation package.  The Module Index and Contents pages are corrected as well.

What docs were you looking for on Unicode strings that was missing?  Please be sure to use the latest version of the documentation on www.pythonlabs.com; python.org is out of date.

I'll look into the other matters; things can clearly be improved.
-------------------------------------------------------

Date: 2000-Sep-22 10:10
By: fdrake

Comment:
The <tex2html_anchor_invisible_mark> is removed as of Doc/perl/python.perl revision 1.86.

The only remaining problem from this bug report is the marking of off-site links, so I'm classifying this as a feature request and reducing the priority a little.  I've also modified the summary to better reflect this remaining issue.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114749&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 18:34:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 10:34:33 -0700
Subject: [Python-bugs-list] [Bug #110687] mailbox module's maildir class broken? (PR#414)
Message-ID: <200009221734.KAA32625@delerium.i.sourceforge.net>

Bug #110687, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: mailbox module's maildir class broken? (PR#414)

Details: Jitterbug-Id: 414
Submitted-By: arb@anand.org
Date: Wed, 26 Jul 2000 12:23:32 -0400 (EDT)
Version: 1.5.2
OS: i386-Redhat-linux 6.2


I'm using the "mailbox" module that comes with python. I'm trying to use the
maildir class in there, but I think it's not following the maildir protocol
properly. The maildir protocol specifies that in a Maildir, a message file
can have any name that is unique, as long as it doesn't begin with a period.
However, the maildir class looks for valid message filenames, by checking to
see if the filename has more than 1 period in it, ie. consists of 3 or more
sections separated by periods. Typically, this is the sort of name one finds
in a Maildir, because the Maildir protocol page describes one simple way of
creating a unique filename, ie. by using the timestamp, pid of the writer, and
the hostname. However, when I insert messages into a maildir which don't follow
that system of generating unique filenames,  the maildir class
of the module doesn't see them. Additioanlly, it _does_ see message files which
begin with a period, eg. .12345678.1234.hostname. This is also a violation of
the
maildir protocol. I believe that a maildir reader should simply look at all
files in a maildir, no matter what the name, except for those that begin with a
period.



====================================================================
Audit trail:
Wed Jul 26 18:15:33 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:02
By: none

Comment:
From: Guido van Rossum <guido@beopen.com>
Subject: Re: [Python-bugs-list] mailbox module's maildir class broken? (PR#414)
Date: Wed, 26 Jul 2000 17:31:29 -0500

> I'm using the "mailbox" module that comes with python. I'm trying to
> use the maildir class in there, but I think it's not following the
> maildir protocol properly. The maildir protocol specifies that in a
> Maildir, a message file can have any name that is unique, as long as
> it doesn't begin with a period.  However, the maildir class looks
> for valid message filenames, by checking to see if the filename has
> more than 1 period in it, ie. consists of 3 or more sections
> separated by periods. Typically, this is the sort of name one finds
> in a Maildir, because the Maildir protocol page describes one simple
> way of creating a unique filename, ie. by using the timestamp, pid
> of the writer, and the hostname. However, when I insert messages
> into a maildir which don't follow that system of generating unique
> filenames, the maildir class of the module doesn't see
> them. Additioanlly, it _does_ see message files which begin with a
> period, eg. .12345678.1234.hostname. This is also a violation of the
> maildir protocol. I believe that a maildir reader should simply look
> at all files in a maildir, no matter what the name, except for those
> that begin with a period.

You're probably right.  I've never used that code, and according to
the logs it was contributed to Mike Meyer (no email known).  Perhaps
you would be willing to create a patch?  See
http://www.python.org/patches/ for submission guidelines.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)


-------------------------------------------------------

Date: 2000-Aug-05 11:45
By: twouters

Comment:
This bug is still present. Fred is/was working on the 'mailbox' module, but I do not know whether he'll fix this, too. If not, I'll do it, it's not that big a chance.
-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110687&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 18:35:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 10:35:01 -0700
Subject: [Python-bugs-list] [Bug #114287] InPlace API needs refcount info
Message-ID: <200009221735.KAA32641@delerium.i.sourceforge.net>

Bug #114287, was updated on 2000-Sep-12 13:53
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: InPlace API needs refcount info

Details: The Doc/api/refcounts.dat file needs to be updated to include the InPlace API calls.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114287&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 18:35:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 10:35:06 -0700
Subject: [Python-bugs-list] [Bug #113779] test_gc coredump on Alpha
Message-ID: <200009221735.KAA08551@bush.i.sourceforge.net>

Bug #113779, was updated on 2000-Sep-06 21:44
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: test_gc coredump on Alpha

Details: Configured --with-cycle-gc --with-sigfpe

gc: collectable <list 0x12043d158>
gc: collectable <dictionary 0x12043d1d8>
gc: collectable <list 0x12043d158>
gc: collectable <tuple 0x12043d198>
gc: collectable <class 0x12043d218>
gc: collectable <dictionary 0x12043d278>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d2c8>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d328>
gc: collectable <instance method 0x12043d378>
gc: collectable <B instance at 0x12043d6b8>
gc: collectable <dictionary 0x12043d6f8>
gc: uncollectable <dictionary 0x12043d5f8>
gc: uncollectable <A instance at 0x12043d158>
Segmentation fault (core dumped)

gdb reports:

Core was generated by `./python -tt Lib/test/regrtest.py -l -v test_gc'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2.1...done.
Reading symbols from /lib/libutil.so.1.1...done.
Reading symbols from /lib/libm.so.6.1...done.
Reading symbols from /lib/libc.so.6.1...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
168             if (!PyList_Check(op)) {
(gdb) where
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
#1  0x120085fac in handle_finalizers (finalizers=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:312
#2  0x1200862d8 in collect (young=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:438
#3  0x120086704 in gc_collect (self=0x100000000, args=0x12043d158)
    at ./gcmodule.c:588
#4  0x120018ef0 in call_builtin (func=0x1, arg=0x12039e258, kw=0x0)
    at ceval.c:2628
#5  0x120018d30 in PyEval_CallObjectWithKeywords (func=0x1204377c0, 
    arg=0x12039e258, kw=0x0) at ceval.c:2596
#6  0x12001713c in eval_code2 (co=0x12043b890, globals=0x12043d158, 
    locals=0x120370488, args=0xffffffffffffffff, argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1929
#7  0x120016cc4 in eval_code2 (co=0x12043c400, globals=0x12043d158, 
    locals=0x120370488, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
...

(gdb) print op
$1 = (PyObject *) 0x100000000
(gdb) print newitem
$2 = (PyObject *) 0x12043d158



Follow-Ups:

Date: 2000-Sep-06 21:49
By: none

Comment:
Note that without -l to regrtest it does NOT dump core,
and completes correctly.

-------------------------------------------------------

Date: 2000-Sep-07 08:23
By: bwarsaw

Comment:
It could just be a bug in the debug printing of collected objects.  The -l switch for the regrtest simply adds a call to gc.set_debug(gc.DEBUG_LEAK) before the rest of the tests get going.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 01:02
By: none

Comment:
By the way, the original post was made by tomh@po.crl.go.jp,
who can test a fix.  However, he's out of town until 9/14.

-------------------------------------------------------

Date: 2000-Sep-14 11:38
By: nascheme

Comment:
The output from "print *op" and "print *newitem" would have been useful.  The 0x100000000 pointer looks funny.  It is a really pointer or NULL or what?  If its not a real pointer then somehow the uncollectable garbage list was corrupted or was not initialized. 
-------------------------------------------------------

Date: 2000-Sep-22 10:35
By: gvanrossum

Comment:
Several fixes have been checked in to the GC code. Could the original (anonymous :-( ) submitter -- or someone else with access to an Alpha -- check out the current CVS tree and see if the problem is fixed?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113779&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 18:35:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 10:35:53 -0700
Subject: [Python-bugs-list] [Bug #113773] Python 2.0b1 selectmodule compile error under Redhat 5.2
Message-ID: <200009221735.KAA08567@bush.i.sourceforge.net>

Bug #113773, was updated on 2000-Sep-06 18:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: Python 2.0b1 selectmodule compile error under Redhat 5.2

Details: Environment: Redhat 5.2 running the gcc compiler that comes with the
distribution (gcc 2.7.2.3).

'make' failed when compiling selectmodule.c ('./configure' ran ok)because
the following constants were undefined:

POLLRDNORM, POLLRDBAND, POLLWRBAND

The /usr/include/sys/poll.h file does not contain these constants.
Under Redhat 6.2 the constants are defined in the /usr/include/bits/poll.h
file (which is not present in the Redhat 5.2 distribution).

I used the Redhat 6.2 poll.h file and the selectmodule compiled (under
Redhat 5.2) but got the following error when running 
'make test' (it looks like it might be related to the compile problem):

test test_poll crashed -- select.error: (9, 'Bad file descriptor')

1 test failed: test_poll



Follow-Ups:

Date: 2000-Sep-07 15:06
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-14 23:08
By: tim_one

Comment:
Boosted the priority and assigned to Fred.  Don't know what you can do about an older Redhat build problem, and it's not clear that the test failure isn't simply due to mixing files across OS releases.  I'm inclined to blame it on the OS.
-------------------------------------------------------

Date: 2000-Sep-15 13:11
By: fdrake

Comment:
I've asked SourceForge if there are ways to use older versions of operating systems on their compile farm.  Until then, we'll need a volunteer with a RH5.2 system to help with this.

Stuart:  Are you willing to test a patch if I mail it to you?  Thanks.
-------------------------------------------------------

Date: 2000-Sep-15 19:50
By: fdrake

Comment:
SourceForge will try and provide a RH5.2 installation for us; now that's service!
-------------------------------------------------------

Date: 2000-Sep-20 22:33
By: fdrake

Comment:
Reducing priority since the platform is old and we still don't have access to it.
-------------------------------------------------------

Date: 2000-Sep-22 07:32
By: fdrake

Comment:
For the record, SF stills plans to attempt to provide a RH5.2 installation / "virtual environment" we can use, but the person who handles it says it will be this weekend or next week before he can get to it.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113773&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 18:36:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 10:36:21 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200009221736.KAA08572@bush.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 13:45
By: fdrake

Comment:
We need to know the output of "uname -s" and "uname -r" for this system.  (If "uname -r" reports an error, please try "uname -v".)

Are you willing to test a modified configure script on this platform?

What additional library is required for the mmap module?
-------------------------------------------------------

Date: 2000-Sep-12 21:59
By: fdrake

Comment:
Received the following response from Daniel Dittmar <ddittmar@users.sourceforge.net>:

> We need to know the output of "uname -s" and "uname -r" 
> for this system.  (If "uname -r" reports an error, please 
> try "uname -v".)

uname -s
ReliantUNIX-N

uname -r
5.45


> Are you willing to test a modified configure script on
> this platform?

sure.

> What additional library is required for the mmap module?

The man page states -lucb. This didn't work on my machine 
as the BSD compatibility layer is not active. I tell you 
more as soon as I know how to activate it.

***********

Another problem: to detect pthreads, the compiler must be 
called with -Kpthread. Otherwise, pthread.h goes into a 
branch where it tries to include a non existent header, 
fails, and configure reports 'no pthreads'.

Daniel

-------------------------------------------------------

Date: 2000-Sep-15 11:57
By: fdrake

Comment:
For the mmap issue, I've added a comment to Modules/Setup.in to let installers know that -lucb may be needed.  In revision 1.110.
-------------------------------------------------------

Date: 2000-Sep-15 13:37
By: fdrake

Comment:
I'm sending a modified version of  the configure script to Daniel Dittmar to test for the first two points in this bug report.
-------------------------------------------------------

Date: 2000-Sep-21 08:17
By: fdrake

Comment:
Sent query to Daniel Dittmar asking if he's had a chance to test the revised configure script I sent.
-------------------------------------------------------

Date: 2000-Sep-21 08:46
By: fdrake

Comment:
Received message from Daniel indicating he should get a chace to test the changes this weekend, so it should be available for 2.0b2.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 18:38:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 10:38:17 -0700
Subject: [Python-bugs-list] [Bug #110659] IDLE-0.5 copy command (PR#354)
Message-ID: <200009221738.KAA08709@bush.i.sourceforge.net>

Bug #110659, was updated on 2000-Jul-31 14:11
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: IDLE-0.5 copy command (PR#354)

Details: Jitterbug-Id: 354
Submitted-By: gpk@bell-labs.com
Date: Tue, 13 Jun 2000 10:05:35 -0400 (EDT)
Version: 1.6a2+
OS: Solaris sparc 2.6


Alt-w is advertised to copy the selected text.
It doesn't.   It pops up the 'window' menu.
However, even if you are in the 'edit' menu,
alt-w apparently does nothing.

I can select text, do alt-E alt-W, move the pointer,
then do ctrl-Y, and nothing pops up.


By the way, 'ctl-U ctl-U ctl-S' is an absurdly long
sequence for something as common as searching for text.



====================================================================
Audit trail:
Tue Jul 11 08:26:00 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110659&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 19:03:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 11:03:16 -0700
Subject: [Python-bugs-list] [Bug #110662] rfc822 (PR#358)
Message-ID: <200009221803.LAB09641@bush.i.sourceforge.net>

Bug #110662, was updated on 2000-Jul-31 14:11
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Works For Me
Bug Group: Irreproducible
Priority: 1
Summary: rfc822 (PR#358)

Details: Jitterbug-Id: 358
Submitted-By: jbearce@copeland.com
Date: Thu, 15 Jun 2000 19:37:00 -0400 (EDT)
Version: 1.5.2
OS: RedHat Linux 6.2


For very long headers returned from a web server rfc822.readheaders does not
correctly build the header.

The following patch fixes it in my situation but I don't know if I broke
anything else:

Example Header:

Location: https://www.website.com:443/tengah/Dpc/vContent.jhtml?page_type=3&PLANID=4&CONTENTPAGEID=0&TengahSession=312442259237-529/2748412123003458168/-1407548368/4/7002/7002/7004/7004

This ends up as

https://www.website.com:443/tengah/Dpc/vContent.jhtml?page_type=3&PLA

and the rest of the header (along with any headers following this one) get
returned as part of the message.

--- /usr/lib/python1.5/rfc822.py.orig   Thu Jun 15 19:35:42 2000
+++ /usr/lib/python1.5/rfc822.py        Thu Jun 15 19:36:00 2000
@@ -125,6 +125,7 @@
         self.status = ''
         headerseen = ""
         firstline = 1
+        lastheader = ''
         startofline = unread = tell = None
         if hasattr(self.fp, 'unread'):
             unread = self.fp.unread
@@ -150,16 +151,22 @@
                 continue
             elif self.iscomment(line):
                 # It's a comment.  Ignore it.
+               lastheader = ''
                 continue
             elif self.islast(line):
                 # Note! No pushback here!  The delimiter line gets eaten.
+               lastheader = ''
                 break
             headerseen = self.isheader(line)
             if headerseen:
                 # It's a legal header line, save it.
                 list.append(line)
                 self.dict[headerseen] = string.strip(line[len(headerseen)+2:])
+               lastheader = headerseen
                 continue
+            elif lastheader:
+               list.append(line)
+               self.dict[lastheader] = self.dict[lastheader] +
string.strip(line)
             else:
                 # It's not a header line; throw it back and stop here.
                 if not self.dict:



====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-17 04:48
By: loewis

Comment:
I can't reproduce the problem. In 2.0b1, 

>>> s="Location: https://www.website.com:443/tengah/Dpc/vContent.jhtml?page_type=3&PLANID=4&CONTENTPAGEID=0&TengahSession=312442259237-529/2748412123003458168/-1407548368/4/7002/7002/7004/7004\r\n\r\n"
>>> t=rfc822.Message(cStringIO.StringIO(s))
>>> t['location']
'https://www.website.com:443/tengah/Dpc/vContent.jhtml?page_type=3&PLANID=4&CONTENTPAGEID=0&TengahSession=312442259237-529/2748412123003458168/-1407548368/4/7002/7002/7004/7004'

works fine for me. If the line break between Location: and the URL in the original report was intentional, rfc822.Message is right in rejecting the header: Continuation lines must start with white space.
-------------------------------------------------------

Date: 2000-Sep-22 11:03
By: gvanrossum

Comment:
Can't reproduce it either. Let's not waste time with this.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110662&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 19:05:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 11:05:40 -0700
Subject: [Python-bugs-list] [Bug #115118] float errors in Python 1.6
Message-ID: <200009221805.LAA09793@bush.i.sourceforge.net>

Bug #115118, was updated on 2000-Sep-22 11:05
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: float errors in Python 1.6

Details: Same machiine, two python versions, both brand new releases
to the machine. Just typed ./configure;make to build them.

Python 1.5.2 (#1, Sep 22 2000, 10:12:21)  [GCC 2.95.2 19991024 (release)] on freebsd4
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> 13 * 1557.7
20250.1
>>> 

Python 1.6 (#3, Sep 22 2000, 09:17:22)  [GCC 2.95.2 19991024 (release)] on freebsd4
Copyright (c) 1995-2000 Corporation for National Research Initiatives.
All Rights Reserved.
Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam.
All Rights Reserved.
>>> 13 * 1557.7
20250.100000000002
>>> 


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115118&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 19:05:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 11:05:02 -0700
Subject: [Python-bugs-list] [Bug #114660] sre hangs with "collapse whitespace" RE
Message-ID: <200009221805.LAA09774@bush.i.sourceforge.net>

Bug #114660, was updated on 2000-Sep-17 17:38
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: sre hangs with "collapse whitespace" RE

Details: In Python 1.5.2, 1.6, and 2.0b1 using "pre", the following regex substitution works fine:

>>> s = "hello      there     how are you?"
>>> re.sub (r'(\S)\s+(\S)', r'\1 \2', s)
'hello there how are you?'

But in 2.0b1 using the standard "re" module, Python goes into an apparently infinite loop.  (CPU is pegged, memory doesn't increase at all.)

Follow-Ups:

Date: 2000-Sep-17 18:18
By: tim_one

Comment:
It's in an infinite loop trying to parse the \1 in the replacement pattern (parse_sre.py, function parse_template).  It recognizes that "1" is a valid group name, but apparently doesn't recognize that "1 " (i.e., the digit one followed by a blank) is not a valid group name), in turn perhaps because int("1 ") returns 1.

I can fix it by adding the clause

s.next not in DIGITS or

after the existing

if (not s.next or

on line 637 and then this gets the result you expect, but I'll defer to /F on whether that's the right way to fix this.

I hope you (Greg) aren't actually using this regexp to normalize whitespace!  split followed by join is the usual way to do that, and this regexp-based way looks wrong (e.g., if somewhere in the middle there's a single letter followed by mounds of whitespace on each side:  the space following the letter won't get collapsed).
-------------------------------------------------------

Date: 2000-Sep-17 19:04
By: gward

Comment:
Not related to the bug, but since Tim brought it up: I once used that regex to normalize whitespace; I must have written that line of code when I was still a recovering Perl programmer.  Unfortunately, that particular line of code lived on in distutils/text_file.py until this past weekend, so someone stumbled across it using Distutils 0.9.2 under Python 2.0b1.  The regex is gone in the current Distutils CVS, so this won't be an issue once 0.9.3 is out.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114660&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 19:10:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 11:10:52 -0700
Subject: [Python-bugs-list] [Bug #115118] float errors in Python 1.6
Message-ID: <200009221810.LAA09992@bush.i.sourceforge.net>

Bug #115118, was updated on 2000-Sep-22 11:05
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 5
Summary: float errors in Python 1.6

Details: Same machiine, two python versions, both brand new releases
to the machine. Just typed ./configure;make to build them.

Python 1.5.2 (#1, Sep 22 2000, 10:12:21)  [GCC 2.95.2 19991024 (release)] on freebsd4
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> 13 * 1557.7
20250.1
>>> 

Python 1.6 (#3, Sep 22 2000, 09:17:22)  [GCC 2.95.2 19991024 (release)] on freebsd4
Copyright (c) 1995-2000 Corporation for National Research Initiatives.
All Rights Reserved.
Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam.
All Rights Reserved.
>>> 13 * 1557.7
20250.100000000002
>>> 


Follow-Ups:

Date: 2000-Sep-22 11:10
By: gvanrossum

Comment:
Not a bug. The outcome (or the second operand, for that matter) can't be represented exactly in binary floating point. In Python 1.5.2, some precision was lost on output so you got a rounded result that looked fine. In Python 1.6 and 2.0, repr() prints enough digits re be able to reproduce the number exactly (17 digits, to be exact). use print or str() to get the rounded result back.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115118&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 19:12:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 11:12:45 -0700
Subject: [Python-bugs-list] [Bug #115119] re module docs missing lookbehind, etc.
Message-ID: <200009221812.LAA01574@delerium.i.sourceforge.net>

Bug #115119, was updated on 2000-Sep-22 11:12
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: re module docs missing lookbehind, etc.

Details: Perhap this is not a bug, but the re module documentation does not describe some PCRE2 features that sre incorporates. Note that these did not make it into pre, and so are not necessary for pre compatibility, but maybe should be documented as sre features.

Here follows a text description from a message by AMK that accompanied a pyPCRE snapshot:

[I've lost the reference to the original and had to retype what follows.]

========
New features in PCRE2 compared to PCRE1 are:

\z    Matches only at the end of the string. This differs from the existing \Z, which will match at the end of the string, or before a final newline at the end of the string.

(?<=...)    Positive lookbehind assertion. Matches if the current position in the string is preceded by a match for the contained regex

(?<!...)    Negative lookbehind assertion. Matches if the current position in the string is not preceded by a match for the contained regex

========

FYI, two other PCRE2 features that AMK described don't seem to have make it into sre: "once-only subpatterns" and "conditional subpatterns".



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115119&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 19:14:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 11:14:39 -0700
Subject: [Python-bugs-list] [Bug #115119] re module docs missing lookbehind, etc.
Message-ID: <200009221814.LAA10151@bush.i.sourceforge.net>

Bug #115119, was updated on 2000-Sep-22 11:12
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: re module docs missing lookbehind, etc.

Details: Perhap this is not a bug, but the re module documentation does not describe some PCRE2 features that sre incorporates. Note that these did not make it into pre, and so are not necessary for pre compatibility, but maybe should be documented as sre features.

Here follows a text description from a message by AMK that accompanied a pyPCRE snapshot:

[I've lost the reference to the original and had to retype what follows.]

========
New features in PCRE2 compared to PCRE1 are:

\z    Matches only at the end of the string. This differs from the existing \Z, which will match at the end of the string, or before a final newline at the end of the string.

(?<=...)    Positive lookbehind assertion. Matches if the current position in the string is preceded by a match for the contained regex

(?<!...)    Negative lookbehind assertion. Matches if the current position in the string is not preceded by a match for the contained regex

========

FYI, two other PCRE2 features that AMK described don't seem to have make it into sre: "once-only subpatterns" and "conditional subpatterns".



Follow-Ups:

Date: 2000-Sep-22 11:14
By: gvanrossum

Comment:
For Fred to negotiate with Fredrik.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115119&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 19:20:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 11:20:16 -0700
Subject: [Python-bugs-list] [Bug #114287] InPlace API needs refcount info
Message-ID: <200009221820.LAA10395@bush.i.sourceforge.net>

Bug #114287, was updated on 2000-Sep-12 13:53
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: InPlace API needs refcount info

Details: The Doc/api/refcounts.dat file needs to be updated to include the InPlace API calls.

Follow-Ups:

Date: 2000-Sep-22 11:20
By: fdrake

Comment:
Added the required inforamation in Doc/api/refcounts.dat revision 1.18.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114287&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 19:21:47 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 11:21:47 -0700
Subject: [Python-bugs-list] [Bug #115119] re module docs missing lookbehind, etc.
Message-ID: <200009221821.LAA01899@delerium.i.sourceforge.net>

Bug #115119, was updated on 2000-Sep-22 11:12
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: re module docs missing lookbehind, etc.

Details: Perhap this is not a bug, but the re module documentation does not describe some PCRE2 features that sre incorporates. Note that these did not make it into pre, and so are not necessary for pre compatibility, but maybe should be documented as sre features.

Here follows a text description from a message by AMK that accompanied a pyPCRE snapshot:

[I've lost the reference to the original and had to retype what follows.]

========
New features in PCRE2 compared to PCRE1 are:

\z    Matches only at the end of the string. This differs from the existing \Z, which will match at the end of the string, or before a final newline at the end of the string.

(?<=...)    Positive lookbehind assertion. Matches if the current position in the string is preceded by a match for the contained regex

(?<!...)    Negative lookbehind assertion. Matches if the current position in the string is not preceded by a match for the contained regex

========

FYI, two other PCRE2 features that AMK described don't seem to have make it into sre: "once-only subpatterns" and "conditional subpatterns".



Follow-Ups:

Date: 2000-Sep-22 11:14
By: gvanrossum

Comment:
For Fred to negotiate with Fredrik.
-------------------------------------------------------

Date: 2000-Sep-22 11:21
By: jdnier

Comment:
Actually, '\z' is supported by pre, so at least that should be added to the docs.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115119&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 19:42:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 11:42:40 -0700
Subject: [Python-bugs-list] [Bug #110687] mailbox module's maildir class broken? (PR#414)
Message-ID: <200009221842.LAA02671@delerium.i.sourceforge.net>

Bug #110687, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 3
Summary: mailbox module's maildir class broken? (PR#414)

Details: Jitterbug-Id: 414
Submitted-By: arb@anand.org
Date: Wed, 26 Jul 2000 12:23:32 -0400 (EDT)
Version: 1.5.2
OS: i386-Redhat-linux 6.2


I'm using the "mailbox" module that comes with python. I'm trying to use the
maildir class in there, but I think it's not following the maildir protocol
properly. The maildir protocol specifies that in a Maildir, a message file
can have any name that is unique, as long as it doesn't begin with a period.
However, the maildir class looks for valid message filenames, by checking to
see if the filename has more than 1 period in it, ie. consists of 3 or more
sections separated by periods. Typically, this is the sort of name one finds
in a Maildir, because the Maildir protocol page describes one simple way of
creating a unique filename, ie. by using the timestamp, pid of the writer, and
the hostname. However, when I insert messages into a maildir which don't follow
that system of generating unique filenames,  the maildir class
of the module doesn't see them. Additioanlly, it _does_ see message files which
begin with a period, eg. .12345678.1234.hostname. This is also a violation of
the
maildir protocol. I believe that a maildir reader should simply look at all
files in a maildir, no matter what the name, except for those that begin with a
period.



====================================================================
Audit trail:
Wed Jul 26 18:15:33 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:02
By: none

Comment:
From: Guido van Rossum <guido@beopen.com>
Subject: Re: [Python-bugs-list] mailbox module's maildir class broken? (PR#414)
Date: Wed, 26 Jul 2000 17:31:29 -0500

> I'm using the "mailbox" module that comes with python. I'm trying to
> use the maildir class in there, but I think it's not following the
> maildir protocol properly. The maildir protocol specifies that in a
> Maildir, a message file can have any name that is unique, as long as
> it doesn't begin with a period.  However, the maildir class looks
> for valid message filenames, by checking to see if the filename has
> more than 1 period in it, ie. consists of 3 or more sections
> separated by periods. Typically, this is the sort of name one finds
> in a Maildir, because the Maildir protocol page describes one simple
> way of creating a unique filename, ie. by using the timestamp, pid
> of the writer, and the hostname. However, when I insert messages
> into a maildir which don't follow that system of generating unique
> filenames, the maildir class of the module doesn't see
> them. Additioanlly, it _does_ see message files which begin with a
> period, eg. .12345678.1234.hostname. This is also a violation of the
> maildir protocol. I believe that a maildir reader should simply look
> at all files in a maildir, no matter what the name, except for those
> that begin with a period.

You're probably right.  I've never used that code, and according to
the logs it was contributed to Mike Meyer (no email known).  Perhaps
you would be willing to create a patch?  See
http://www.python.org/patches/ for submission guidelines.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)


-------------------------------------------------------

Date: 2000-Aug-05 11:45
By: twouters

Comment:
This bug is still present. Fred is/was working on the 'mailbox' module, but I do not know whether he'll fix this, too. If not, I'll do it, it's not that big a chance.
-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-22 11:42
By: fdrake

Comment:
Fixed in Lib/mailbox.py revision 1.24.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110687&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 19:52:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 11:52:35 -0700
Subject: [Python-bugs-list] [Bug #115076] threads of __del__
Message-ID: <200009221852.LAA11658@bush.i.sourceforge.net>

Bug #115076, was updated on 2000-Sep-22 02:15
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: threads of __del__

Details: I suspect (but have not proved) that the support for destroying deeply recursive structures can allow for an instances __del__ method to get called in a thread other than the one in which it lost its last reference.

This can happen if it switches to a different thread during deletion of a deeply recursive structure (with _PyTrash_delete_later not empty). 

Should Python guarantee that this does not happen? (I say yes - it is important for COM clients)

Follow-Ups:

Date: 2000-Sep-22 02:52
By: gvanrossum

Comment:
Agreed that this would be a problem if it could cause an inconsistent state of the trashcan (at the end of object.c) structure. However, since the "trash" code is all executed with the global interpreter lock held, I don't see that there can be a problem. Here's why:

The code in _PyTrash_deposit_object() doesn't make any calls that could invoke __del__, so it's safe. The code in _PyTrash_destroy_chain() makes exactly one call to Py_DECREF(), but it takes care that its global data structures are consistent at this point. For a second I thought that _PyTrash_delete_later would have to be declared volatile, but on second thought I don't: the Py_DECREF() macro expands to a possible (indirect) function call, signaling the compiler that the global _PyTrash_delete_later may be changed in arbitrary ways.

Assigned to Tim Peters to verify my reasoning, because of his superior mind in reasoning about threads and race conditions.
-------------------------------------------------------

Date: 2000-Sep-22 03:05
By: htrd

Comment:
I agree there is no self-consistency problem with the trashcan, however......

The code in _PyTrash_destroy_chain can call an objects __del__ method, which can release the interpreter lock.

A second thread may then reenter _PyTrash_destroy_chain and continue to clean up the first thread's garbage. (the first thread is safely blocked inside the Py_DECREF)

Yes the garbage gets cleaned up, however it happens in the wrong thread.

I suggest that _PyTrash_delete_later should be part of pyThreadState



-------------------------------------------------------

Date: 2000-Sep-22 03:08
By: gvanrossum

Comment:
And why, exactly, would it be a problem that the trash is deleted in the 'wrong" thread? It's just trash. Any thread can delete it.

Or am I missing something?
-------------------------------------------------------

Date: 2000-Sep-22 03:27
By: htrd

Comment:
There are two cases that I have in mind:

First is that of a COM client.

It depends on the COM threading model in use, but this problem applies in the most common threading model which is also the default threading model using Mark Hammond's pythoncom.

It is only permitted to access a reference to a COM object from the thread in which it is created. This restiction applies to the Release() method that is used by pythoncom to release its reference to the COM server.


Secondly, it is common to use a dictionary keyed by thread.get_ident() to provide thread-local storage. This is used extensively in Zope. Any application that uses this type of thread-local storage in a __del__ is likely to be broken.



-------------------------------------------------------

Date: 2000-Sep-22 06:30
By: gvanrossum

Comment:
It sounds that it will be hard to enforce that __del__ is called in the constructing thread even without the complication of the trashcan code.

Explicitly referencing thread-specific data in a __del__ seems silly -- if the object is tied so closely to the thread, why not add a pointer to the thread to the object.

Nevertheless, especially the COM thing sounds like it would be a good thing to prevent this if it is possible, and your solution (make the trashcan state part of the thread state) sounds reasonable -- except that it means that every deallocation of a tuple, list, dict, frame or traceback needs yet another call to PyThreadState_Get(). And, most disturbing of all, we found before releasing 2.0b1 that there are situations where dictionaries (and possibly other objects) are used when there is no current thread state!!!

Replacing one theoretical problem with another not-so-theoretical one doesn't seem right. Perhaps we could invent a flag that prevents thread-switches while the trashcan dealloc code is running? This could be a simple global boolean that, when set, stops the ceval main loop (and the BEGIN/END ALLOW THREADS macros and related functions!) from ever yielding the interpreter loop. It would almost never be triggered in practice, but guarantee safety in worst cases -- if not efficiency (other threads would be completely blocked until the trashcan code is done).

Back to Tim...
-------------------------------------------------------

Date: 2000-Sep-22 07:52
By: htrd

Comment:
There is a patch to move the trashcan into the thread state. see http://sourceforge.net/patch/?func=detailpatch&patch_id=101606&group_id=5470

This uses PyThreadState_GET() once to avoid the extra function call in the normal path, and only uses the trashcan if the thread state is non NULL. (assuming we are never deleting deeply recursive objects with no thread state)

On performance, this gives me a 2% increase in pystones....

-------------------------------------------------------

Date: 2000-Sep-22 11:52
By: tim_one

Comment:
Assigned to MarkH, as I want his opinion on this.

I dislike it on principle:  it elevates an accident of refcount semantics into a design goal, and complicates the code to achieve that.

The Microsoft .NET implementation of Python doesn't do refcounting, so not even the pre-trashcan refcount semantics can be relied on there, and I don't want to add to users' difficulties in moving among Python implementations (despite that it may be in my immediate financial interest to lock people into CPython, I'll leave "embrace & extend" to MS <wink>).

If this sounds like a good idea to Mark anyway, fine, but I don't buy it otherwise.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115076&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 19:58:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 11:58:53 -0700
Subject: [Python-bugs-list] [Bug #114749] HTML docs: mark off-site links
Message-ID: <200009221858.LAA11926@bush.i.sourceforge.net>

Bug #114749, was updated on 2000-Sep-18 15:05
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 4
Summary: HTML docs: mark off-site links

Details: The module index is empty.
In the library the contents is empty.

The tag <tex2html_anchor_invisible_mark> appears in lots of the .html files.

The encode() method is not documented for strings.

No docs on unicode strings in lib ref like the strings module.

Please mark links that leave the local machine. For example the link to "Python How-To Guides".


Follow-Ups:

Date: 2000-Sep-18 20:38
By: fdrake

Comment:
The "".encode() method is documented in the latest documentation package.  The Module Index and Contents pages are corrected as well.

What docs were you looking for on Unicode strings that was missing?  Please be sure to use the latest version of the documentation on www.pythonlabs.com; python.org is out of date.

I'll look into the other matters; things can clearly be improved.
-------------------------------------------------------

Date: 2000-Sep-22 10:10
By: fdrake

Comment:
The <tex2html_anchor_invisible_mark> is removed as of Doc/perl/python.perl revision 1.86.

The only remaining problem from this bug report is the marking of off-site links, so I'm classifying this as a feature request and reducing the priority a little.  I've also modified the summary to better reflect this remaining issue.
-------------------------------------------------------

Date: 2000-Sep-22 11:58
By: fdrake

Comment:
I expect I may have a small link-icon to use for this late next week (but it could take longer).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114749&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 20:36:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 12:36:01 -0700
Subject: [Python-bugs-list] [Bug #115126] Over restricted type checking on eval() function
Message-ID: <200009221936.MAA04661@delerium.i.sourceforge.net>

Bug #115126, was updated on 2000-Sep-22 12:36
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Over restricted type checking on eval() function

Details: The built-in function eval() takes a string argument and a dictionary.  The second argument should allow any instance which defines __getitem__ as opposed to just dictionaries.

The following example creates a type error:
  eval, argument 2: expected dictionary,   instance found

class SpreadSheet:
    _cells = {}
    def __setitem__( self, key, formula ):
        self._cells[key] = formula
    def __getitem__( self, key ):
        return eval( self._cells[key], self )

ss = SpreadSheet()
ss['a1'] = '5'
ss['a2'] = 'a1*5'
ss['a2']


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115126&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 20:42:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 12:42:45 -0700
Subject: [Python-bugs-list] [Bug #115126] Over restricted type checking on eval() function
Message-ID: <200009221942.MAA04923@delerium.i.sourceforge.net>

Bug #115126, was updated on 2000-Sep-22 12:36
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Over restricted type checking on eval() function

Details: The built-in function eval() takes a string argument and a dictionary.  The second argument should allow any instance which defines __getitem__ as opposed to just dictionaries.

The following example creates a type error:
  eval, argument 2: expected dictionary,   instance found

class SpreadSheet:
    _cells = {}
    def __setitem__( self, key, formula ):
        self._cells[key] = formula
    def __getitem__( self, key ):
        return eval( self._cells[key], self )

ss = SpreadSheet()
ss['a1'] = '5'
ss['a2'] = 'a1*5'
ss['a2']


Follow-Ups:

Date: 2000-Sep-22 12:42
By: tim_one

Comment:
Changed Group to Feature Request.  Should be added to PEP 42 (I'll do that if nobody beats me to it).

CPython requires a genuine dict now for speed.  I believe JPython allows any mapping object.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115126&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 20:43:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 12:43:00 -0700
Subject: [Python-bugs-list] [Bug #115006] Python 2.0 won't build on HP Unix 10.2
Message-ID: <200009221943.MAA04934@delerium.i.sourceforge.net>

Bug #115006, was updated on 2000-Sep-21 13:31
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0 won't build on HP Unix 10.2

Details: Call me at 877 737 7357 X4477  if I can help. ...Bob

With threads (default) at:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c thread.c

get error message:

In file included from thread.c_116:
thread_pthread.h: In function 'PyThread_get_thread_ident':
thread_pthread.h:181: aggreagete value used where an integer was expected




Without threads at:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c

error message is:

./posixmodule.c:713: 'fdatasync' undeclared (first use in this function)

Follow-Ups:

Date: 2000-Sep-21 14:56
By: fdrake

Comment:
Could you please check your system's man page for fdatasync() to and let us know what includes and compile-time defines are needed?  Thanks!
-------------------------------------------------------

Date: 2000-Sep-22 03:03
By: gvanrossum

Comment:
Assigned to me. Suspect it's a duplicate of #110650 and #110665.
-------------------------------------------------------

Date: 2000-Sep-22 09:03
By: gvanrossum

Comment:
Bob, I've checked in a fix for fdatasync. Can you test that? I'm also working on the thread configuration, but that'll take longer.

-------------------------------------------------------

Date: 2000-Sep-22 12:43
By: gvanrossum

Comment:
I *think* I've squished this one with my latest checkin. Please test!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115006&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 20:44:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 12:44:05 -0700
Subject: [Python-bugs-list] [Bug #114324] Minor build problems on HPUX for 2.0b1
Message-ID: <200009221944.MAA05041@delerium.i.sourceforge.net>

Bug #114324, was updated on 2000-Sep-13 02:20
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: Minor build problems on HPUX for 2.0b1

Details: Build problems on HPUX10.20/HPUX11.00:

  - There seems to be no prototype for "fdatasync" in any include file
    although it has a man page and it is present in libc (so HAVE_FDATASYNC
    is set). As a result posixmodule.c fails to compile.
   
    Adding a prototype "extern int fdatasync(int);" to posixmodule.c solves 
    this problem, but it may not be portable.
    
  - Modules/mmapmodule.c is missing a "#include <limits.h>"
  
Build problems on HPUX10.20 only:

  - When configured with threading support (default), the cast to (long)
    on line 181 of Python/thread_pthread.h fails. The reason is that
    pthread_t is a struct type. The "configure" test that tries to find out
    the size of pthread_t failed because it tries to cast '0' to a pthread_t,
    so SIZEOF_PTHREAD_T remains undefined.
    
    I suggest changing this line in configure.in:
    
    AC_TRY_COMPILE([#include <pthread.h>], [pthread_t x; x = (pthread_t)0;], have_pthread_t=yes)
    
    to
    
    AC_TRY_COMPILE([#include <pthread.h>], [pthread_t x; x = *(pthread_t*)0;], have_pthread_t=yes)
    
My compiler settings:

   setenv CC 'c89 +DA1.1 +Onolimit -D_HPUX_SOURCE'

Regards,

Eddy

Follow-Ups:

Date: 2000-Sep-16 10:01
By: gvanrossum

Comment:
Randomly assigned to Jeremy for further investigation.
-------------------------------------------------------

Date: 2000-Sep-22 03:04
By: gvanrossum

Comment:
Assigned back to me because I'm planning to tackle HP build problems.
-------------------------------------------------------

Date: 2000-Sep-22 09:04
By: gvanrossum

Comment:
I've checked in a fix for fdatasync. Can you test that?
I'm also working on the thread config, that'll take longer.
-------------------------------------------------------

Date: 2000-Sep-22 09:41
By: edg

Comment:
The fix for fdatasync works.
However, I think it's better to use __hpux instead of __hppa to detect HP-UX.
(__hppa identifies the processor architecture).

FYI: The native cc/c89 compiler defines both __hppa and __hpux.
Gcc additionally defines hppa and hpux.

-------------------------------------------------------

Date: 2000-Sep-22 12:44
By: gvanrossum

Comment:
I *think* I've squashed this bug with my latest checkin to configure.in and configure. Thanks for the suggestion! Please test so I can close this bug report.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114324&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 21:18:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 13:18:24 -0700
Subject: [Python-bugs-list] [Bug #114324] Minor build problems on HPUX for 2.0b1
Message-ID: <200009222018.NAA14959@bush.i.sourceforge.net>

Bug #114324, was updated on 2000-Sep-13 02:20
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: Minor build problems on HPUX for 2.0b1

Details: Build problems on HPUX10.20/HPUX11.00:

  - There seems to be no prototype for "fdatasync" in any include file
    although it has a man page and it is present in libc (so HAVE_FDATASYNC
    is set). As a result posixmodule.c fails to compile.
   
    Adding a prototype "extern int fdatasync(int);" to posixmodule.c solves 
    this problem, but it may not be portable.
    
  - Modules/mmapmodule.c is missing a "#include <limits.h>"
  
Build problems on HPUX10.20 only:

  - When configured with threading support (default), the cast to (long)
    on line 181 of Python/thread_pthread.h fails. The reason is that
    pthread_t is a struct type. The "configure" test that tries to find out
    the size of pthread_t failed because it tries to cast '0' to a pthread_t,
    so SIZEOF_PTHREAD_T remains undefined.
    
    I suggest changing this line in configure.in:
    
    AC_TRY_COMPILE([#include <pthread.h>], [pthread_t x; x = (pthread_t)0;], have_pthread_t=yes)
    
    to
    
    AC_TRY_COMPILE([#include <pthread.h>], [pthread_t x; x = *(pthread_t*)0;], have_pthread_t=yes)
    
My compiler settings:

   setenv CC 'c89 +DA1.1 +Onolimit -D_HPUX_SOURCE'

Regards,

Eddy

Follow-Ups:

Date: 2000-Sep-16 10:01
By: gvanrossum

Comment:
Randomly assigned to Jeremy for further investigation.
-------------------------------------------------------

Date: 2000-Sep-22 03:04
By: gvanrossum

Comment:
Assigned back to me because I'm planning to tackle HP build problems.
-------------------------------------------------------

Date: 2000-Sep-22 09:04
By: gvanrossum

Comment:
I've checked in a fix for fdatasync. Can you test that?
I'm also working on the thread config, that'll take longer.
-------------------------------------------------------

Date: 2000-Sep-22 09:41
By: edg

Comment:
The fix for fdatasync works.
However, I think it's better to use __hpux instead of __hppa to detect HP-UX.
(__hppa identifies the processor architecture).

FYI: The native cc/c89 compiler defines both __hppa and __hpux.
Gcc additionally defines hppa and hpux.

-------------------------------------------------------

Date: 2000-Sep-22 12:44
By: gvanrossum

Comment:
I *think* I've squashed this bug with my latest checkin to configure.in and configure. Thanks for the suggestion! Please test so I can close this bug report.
-------------------------------------------------------

Date: 2000-Sep-22 13:18
By: edg

Comment:
I can't test it before Monday, but it looks like you've
made a typo:

Configure.in, line 2522:
  ... *(pthread_t)*0; 

should be:

  ... *(pthread_t*)0; 

BTW: Modules/mmapmodule.c still misses 

#ifdef HAVE_LIMITS_H
#include <limits.h>
#endif

Without this, INT_MAX is undefined on HP-UX.

I'll test it first thing Monday morning.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114324&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 22:57:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 14:57:34 -0700
Subject: [Python-bugs-list] [Bug #115143] Python sometimes complains about continue in an except
Message-ID: <200009222157.OAA10226@delerium.i.sourceforge.net>

Bug #115143, was updated on 2000-Sep-22 14:57
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python sometimes complains about continue in an except

Details: If a continue statement occurs in the second try/except
statement nested within another try statement, it complains
about the second continue.  For example, this code generates a SyntaxError:

    for i in range(10):
        try:
            try:
                pass
            except:
                continue
            try:
                pass
            except:
                continue
        except:
            pass

while this is fine:

    for i in range(10):
        try:
            pass
        except:
            continue
        try:
            pass
        except:
            continue

This problem exists in both 1.5.2 and 2.0b1.

A workaround is to raise "continue" from the inner 
try/except statements and catch it in the outer try/except:

    for i in range(10):
        try:
            try:
                pass
            except:
                raise "continue"
            try:
                pass
            except:
                raise "continue"
        except "continue":
            continue
        except:
            pass



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115143&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 23:39:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 15:39:03 -0700
Subject: [Python-bugs-list] [Bug #113779] test_gc coredump on Alpha
Message-ID: <200009222239.PAA20286@bush.i.sourceforge.net>

Bug #113779, was updated on 2000-Sep-06 21:44
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 3
Summary: test_gc coredump on Alpha

Details: Configured --with-cycle-gc --with-sigfpe

gc: collectable <list 0x12043d158>
gc: collectable <dictionary 0x12043d1d8>
gc: collectable <list 0x12043d158>
gc: collectable <tuple 0x12043d198>
gc: collectable <class 0x12043d218>
gc: collectable <dictionary 0x12043d278>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d2c8>
gc: collectable <A instance at 0x12043d158>
gc: collectable <dictionary 0x12043d328>
gc: collectable <instance method 0x12043d378>
gc: collectable <B instance at 0x12043d6b8>
gc: collectable <dictionary 0x12043d6f8>
gc: uncollectable <dictionary 0x12043d5f8>
gc: uncollectable <A instance at 0x12043d158>
Segmentation fault (core dumped)

gdb reports:

Core was generated by `./python -tt Lib/test/regrtest.py -l -v test_gc'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2.1...done.
Reading symbols from /lib/libutil.so.1.1...done.
Reading symbols from /lib/libm.so.6.1...done.
Reading symbols from /lib/libc.so.6.1...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
168             if (!PyList_Check(op)) {
(gdb) where
#0  0x12004ec54 in PyList_Append (op=0x100000000, newitem=0x12043d158)
    at listobject.c:168
#1  0x120085fac in handle_finalizers (finalizers=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:312
#2  0x1200862d8 in collect (young=0x11fffe0b0, old=0x12037c7a0)
    at ./gcmodule.c:438
#3  0x120086704 in gc_collect (self=0x100000000, args=0x12043d158)
    at ./gcmodule.c:588
#4  0x120018ef0 in call_builtin (func=0x1, arg=0x12039e258, kw=0x0)
    at ceval.c:2628
#5  0x120018d30 in PyEval_CallObjectWithKeywords (func=0x1204377c0, 
    arg=0x12039e258, kw=0x0) at ceval.c:2596
#6  0x12001713c in eval_code2 (co=0x12043b890, globals=0x12043d158, 
    locals=0x120370488, args=0xffffffffffffffff, argcount=0, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1929
#7  0x120016cc4 in eval_code2 (co=0x12043c400, globals=0x12043d158, 
    locals=0x120370488, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
...

(gdb) print op
$1 = (PyObject *) 0x100000000
(gdb) print newitem
$2 = (PyObject *) 0x12043d158



Follow-Ups:

Date: 2000-Sep-06 21:49
By: none

Comment:
Note that without -l to regrtest it does NOT dump core,
and completes correctly.

-------------------------------------------------------

Date: 2000-Sep-07 08:23
By: bwarsaw

Comment:
It could just be a bug in the debug printing of collected objects.  The -l switch for the regrtest simply adds a call to gc.set_debug(gc.DEBUG_LEAK) before the rest of the tests get going.
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 01:02
By: none

Comment:
By the way, the original post was made by tomh@po.crl.go.jp,
who can test a fix.  However, he's out of town until 9/14.

-------------------------------------------------------

Date: 2000-Sep-14 11:38
By: nascheme

Comment:
The output from "print *op" and "print *newitem" would have been useful.  The 0x100000000 pointer looks funny.  It is a really pointer or NULL or what?  If its not a real pointer then somehow the uncollectable garbage list was corrupted or was not initialized. 
-------------------------------------------------------

Date: 2000-Sep-22 10:35
By: gvanrossum

Comment:
Several fixes have been checked in to the GC code. Could the original (anonymous :-( ) submitter -- or someone else with access to an Alpha -- check out the current CVS tree and see if the problem is fixed?
-------------------------------------------------------

Date: 2000-Sep-22 15:39
By: nascheme

Comment:
Found it.  PyArg_ParseTuple(args, "l:set_debug", &debug) when debug is
declared as an int.  This one was tricky to track down.  "set watch" is your friend even though software watchpoints suck.  Thanks Compaq for your test-drive program.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113779&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 23:39:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 15:39:34 -0700
Subject: [Python-bugs-list] [Bug #115146] time.strptime returns bad day of month
Message-ID: <200009222239.PAA20299@bush.i.sourceforge.net>

Bug #115146, was updated on 2000-Sep-22 15:39
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: time.strptime returns bad day of month

Details: Python 1.5.2 (#1, May  9 2000, 15:05:56)  [GCC 2.95.3 19991030 (prerelease)] on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import time
>>> time.strptime("00:00","%M:%S")
(1900, 1, 0, 0, 0, 0, 6, 1, 0)

According to documentation (Beazley, "Python Essential Reference" p172), strptime "returns a time tuple of the same form as returned by localtime() or gmtime()." Documentation for gmtime() (ibid, pp170-1) states that the valid range for day is 1-31. I suspect someone's either used to the POSIX strftime, or there's an off-by-one error.


Q #1: Why 1900? Why not assume epoch unless told otherwise?

Q #2: If you're assuming things, why not assume day-of-month as 1, not 0? According

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115146&group_id=5470

From noreply@sourceforge.net  Fri Sep 22 23:41:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 15:41:58 -0700
Subject: [Python-bugs-list] [Bug #115147] os.execvp ignores first item in arguments
Message-ID: <200009222241.PAA20362@bush.i.sourceforge.net>

Bug #115147, was updated on 2000-Sep-22 15:41
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: os.execvp ignores first item in arguments

Details: purp@wug:~/wbhome/tests/lsf [15:38] <139> python
Python 1.5.2 (#1, May  9 2000, 15:05:56)  [GCC 2.95.3 19991030 (prerelease)] on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import os
>>> os.execvp('echo',['foo','bar'])
bar

That seems odd... off-by-one error?

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115147&group_id=5470

From noreply@sourceforge.net  Sat Sep 23 00:57:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 16:57:21 -0700
Subject: [Python-bugs-list] [Bug #115076] threads of __del__
Message-ID: <200009222357.QAA14462@delerium.i.sourceforge.net>

Bug #115076, was updated on 2000-Sep-22 02:15
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: threads of __del__

Details: I suspect (but have not proved) that the support for destroying deeply recursive structures can allow for an instances __del__ method to get called in a thread other than the one in which it lost its last reference.

This can happen if it switches to a different thread during deletion of a deeply recursive structure (with _PyTrash_delete_later not empty). 

Should Python guarantee that this does not happen? (I say yes - it is important for COM clients)

Follow-Ups:

Date: 2000-Sep-22 02:52
By: gvanrossum

Comment:
Agreed that this would be a problem if it could cause an inconsistent state of the trashcan (at the end of object.c) structure. However, since the "trash" code is all executed with the global interpreter lock held, I don't see that there can be a problem. Here's why:

The code in _PyTrash_deposit_object() doesn't make any calls that could invoke __del__, so it's safe. The code in _PyTrash_destroy_chain() makes exactly one call to Py_DECREF(), but it takes care that its global data structures are consistent at this point. For a second I thought that _PyTrash_delete_later would have to be declared volatile, but on second thought I don't: the Py_DECREF() macro expands to a possible (indirect) function call, signaling the compiler that the global _PyTrash_delete_later may be changed in arbitrary ways.

Assigned to Tim Peters to verify my reasoning, because of his superior mind in reasoning about threads and race conditions.
-------------------------------------------------------

Date: 2000-Sep-22 03:05
By: htrd

Comment:
I agree there is no self-consistency problem with the trashcan, however......

The code in _PyTrash_destroy_chain can call an objects __del__ method, which can release the interpreter lock.

A second thread may then reenter _PyTrash_destroy_chain and continue to clean up the first thread's garbage. (the first thread is safely blocked inside the Py_DECREF)

Yes the garbage gets cleaned up, however it happens in the wrong thread.

I suggest that _PyTrash_delete_later should be part of pyThreadState



-------------------------------------------------------

Date: 2000-Sep-22 03:08
By: gvanrossum

Comment:
And why, exactly, would it be a problem that the trash is deleted in the 'wrong" thread? It's just trash. Any thread can delete it.

Or am I missing something?
-------------------------------------------------------

Date: 2000-Sep-22 03:27
By: htrd

Comment:
There are two cases that I have in mind:

First is that of a COM client.

It depends on the COM threading model in use, but this problem applies in the most common threading model which is also the default threading model using Mark Hammond's pythoncom.

It is only permitted to access a reference to a COM object from the thread in which it is created. This restiction applies to the Release() method that is used by pythoncom to release its reference to the COM server.


Secondly, it is common to use a dictionary keyed by thread.get_ident() to provide thread-local storage. This is used extensively in Zope. Any application that uses this type of thread-local storage in a __del__ is likely to be broken.



-------------------------------------------------------

Date: 2000-Sep-22 06:30
By: gvanrossum

Comment:
It sounds that it will be hard to enforce that __del__ is called in the constructing thread even without the complication of the trashcan code.

Explicitly referencing thread-specific data in a __del__ seems silly -- if the object is tied so closely to the thread, why not add a pointer to the thread to the object.

Nevertheless, especially the COM thing sounds like it would be a good thing to prevent this if it is possible, and your solution (make the trashcan state part of the thread state) sounds reasonable -- except that it means that every deallocation of a tuple, list, dict, frame or traceback needs yet another call to PyThreadState_Get(). And, most disturbing of all, we found before releasing 2.0b1 that there are situations where dictionaries (and possibly other objects) are used when there is no current thread state!!!

Replacing one theoretical problem with another not-so-theoretical one doesn't seem right. Perhaps we could invent a flag that prevents thread-switches while the trashcan dealloc code is running? This could be a simple global boolean that, when set, stops the ceval main loop (and the BEGIN/END ALLOW THREADS macros and related functions!) from ever yielding the interpreter loop. It would almost never be triggered in practice, but guarantee safety in worst cases -- if not efficiency (other threads would be completely blocked until the trashcan code is done).

Back to Tim...
-------------------------------------------------------

Date: 2000-Sep-22 07:52
By: htrd

Comment:
There is a patch to move the trashcan into the thread state. see http://sourceforge.net/patch/?func=detailpatch&patch_id=101606&group_id=5470

This uses PyThreadState_GET() once to avoid the extra function call in the normal path, and only uses the trashcan if the thread state is non NULL. (assuming we are never deleting deeply recursive objects with no thread state)

On performance, this gives me a 2% increase in pystones....

-------------------------------------------------------

Date: 2000-Sep-22 11:52
By: tim_one

Comment:
Assigned to MarkH, as I want his opinion on this.

I dislike it on principle:  it elevates an accident of refcount semantics into a design goal, and complicates the code to achieve that.

The Microsoft .NET implementation of Python doesn't do refcounting, so not even the pre-trashcan refcount semantics can be relied on there, and I don't want to add to users' difficulties in moving among Python implementations (despite that it may be in my immediate financial interest to lock people into CPython, I'll leave "embrace & extend" to MS <wink>).

If this sounds like a good idea to Mark anyway, fine, but I don't buy it otherwise.
-------------------------------------------------------

Date: 2000-Sep-22 16:57
By: mhammond

Comment:
I've got to side with Tim that "last thread with a reference" is not the correct semantic to be applied here.

On the other hand, I do agree that some determinism would be nice here.  The reporter is completely correct about, eg, COM rules.  If I was BDFL, I would probably go for something deterministic, and that probably is "last thread to release", as anything else is just unreasonable.

My understanding of .NET is that it does GC on a seperate GC thread!  So there you are guaranteed to not get the behaviour (but guaranteed not to get it ever ;-)

Sorry Tim - back at ya!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115076&group_id=5470

From noreply@sourceforge.net  Sat Sep 23 00:59:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 16:59:11 -0700
Subject: [Python-bugs-list] [Bug #115147] os.execvp ignores first item in arguments
Message-ID: <200009222359.QAA14593@delerium.i.sourceforge.net>

Bug #115147, was updated on 2000-Sep-22 15:41
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: os.execvp ignores first item in arguments

Details: purp@wug:~/wbhome/tests/lsf [15:38] <139> python
Python 1.5.2 (#1, May  9 2000, 15:05:56)  [GCC 2.95.3 19991030 (prerelease)] on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import os
>>> os.execvp('echo',['foo','bar'])
bar

That seems odd... off-by-one error?

Follow-Ups:

Date: 2000-Sep-22 16:59
By: tim_one

Comment:
Assigned to Fred as he's the only Unix guy around this weekend, but marked Not-a-Bug and Invalid.  Fred, how about you Close it after adding a line to the docs?  This is almost a FAQ.

The arglist passed to one of these guys becomes argv on the other end, and, as always, argv[0] is the file name associated with the file being executed.  See any manpage for execvp; this is inherited directly from how Unix(tm) defines these functions.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115147&group_id=5470

From noreply@sourceforge.net  Sat Sep 23 01:20:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 17:20:42 -0700
Subject: [Python-bugs-list] [Bug #115146] time.strptime returns bad day of month
Message-ID: <200009230020.RAA23757@bush.i.sourceforge.net>

Bug #115146, was updated on 2000-Sep-22 15:39
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 5
Summary: time.strptime returns bad day of month

Details: Python 1.5.2 (#1, May  9 2000, 15:05:56)  [GCC 2.95.3 19991030 (prerelease)] on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import time
>>> time.strptime("00:00","%M:%S")
(1900, 1, 0, 0, 0, 0, 6, 1, 0)

According to documentation (Beazley, "Python Essential Reference" p172), strptime "returns a time tuple of the same form as returned by localtime() or gmtime()." Documentation for gmtime() (ibid, pp170-1) states that the valid range for day is 1-31. I suspect someone's either used to the POSIX strftime, or there's an off-by-one error.


Q #1: Why 1900? Why not assume epoch unless told otherwise?

Q #2: If you're assuming things, why not assume day-of-month as 1, not 0? According

Follow-Ups:

Date: 2000-Sep-22 17:20
By: tim_one

Comment:
Marked 3rdParty and assigned to Fred.

The function time_strptime in Python's timemodule.c simply calls the platform strptime function, and converts the result to a tuple.  Virtually all bugs claimed in it so far have been traced to the platform's implementation of strptime.

In particular, since Python passes on the day value untouched, it's clearly a bug in your version of libc that you're getting a 0 value.  As to the 1900, that's how a struct tm is defined to work, but again it's almost certainly your platform strptime screwing up in not setting that field to 70.

Unfortunately, since strptime is not defined by the ANSI/ISO C std, results in endcases do vary across platforms.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115146&group_id=5470

From noreply@sourceforge.net  Sat Sep 23 02:09:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 18:09:00 -0700
Subject: [Python-bugs-list] [Bug #110624] float("1.0e-309") inconsistency on win32 (PR#245)
Message-ID: <200009230109.SAA25354@bush.i.sourceforge.net>

Bug #110624, was updated on 2000-Jul-31 14:08
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: float("1.0e-309") inconsistency on win32 (PR#245)

Details: Jitterbug-Id: 245
Submitted-By: sde@recombinant.demon.co.uk
Date: Wed, 22 Mar 2000 16:13:26 -0500 (EST)
Version: 1.5.2
OS: win32


#! /usr/bin/python

# Inconsistent behaviour.

# Python 1.5.2 win32 fails the second print (why not both?)
# other versions print both expressions

#              Ok  Python 1.5.2 on SuSE Linux 6.3
#              Ok  JPython 1.1 on java1.1.7B
# Partial failure  Python 1.5.2 win32

print eval("float(1.0e-309)")
print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309




====================================================================
Audit trail:
Fri Mar 24 16:42:36 2000	guido	changed notes
Fri Mar 24 16:42:36 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:08
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Thu, 23 Mar 2000 01:43:30 -0500

> -----Original Message-----
> From: python-bugs-list-admin@python.org
> [mailto:python-bugs-list-admin@python.org]On Behalf Of
> sde@recombinant.demon.co.uk
> Sent: Wednesday, March 22, 2000 4:13 PM
> To: python-bugs-list@python.org
> Cc: bugs-py@python.org
> Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32
> (PR#245)
>
>
> Full_Name: Stephen D Evans
> Version: 1.5.2
> OS: win32
> Submission from: recombinant.demon.co.uk (212.229.73.7)
>
>
> #! /usr/bin/python
>
> # Inconsistent behaviour.
>
> # Python 1.5.2 win32 fails the second print (why not both?)
> # other versions print both expressions
>
> #              Ok  Python 1.5.2 on SuSE Linux 6.3
> #              Ok  JPython 1.1 on java1.1.7B
> # Partial failure  Python 1.5.2 win32
>
> print eval("float(1.0e-309)")
> print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309

First note that these don't do the same thing:  the first passes a float to
"float", the second passes a string to "float".  Change the first to

    print eval("float('1.0e-309')")

and it gives the same bogus error as the second one.

Then it turns out the error is Microsoft's fault.  This tiny C program shows
the bug:

#include <errno.h>
#include <stdlib.h>
#include <stdio.h>

void
main()
{
    double x;
    char* dontcare;
    errno = 0;
    x = strtod("1.0e-309", &dontcare);
    printf("errno after = %d\n", errno);
    printf("x after = %g\n", x);
}

This prints

    errno after = 34
    x after = 0

when compiled & linked with MS's VC5; don't know about VC6.  Same thing for
"1.0e-308".  Works fine for "1.0e-307".  Doubt this will get fixed before MS
fixes their library.




-------------------------------------------------------

Date: 2000-Jul-31 14:08
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Fri, 24 Mar 2000 04:51:57 -0500

> > Full_Name: Stephen D Evans
> > Version: 1.5.2
> > OS: win32
> > Submission from: recombinant.demon.co.uk (212.229.73.7)
> >
> >
> > #! /usr/bin/python
> >
> > # Inconsistent behaviour.
> >
> > # Python 1.5.2 win32 fails the second print (why not both?)
> > # other versions print both expressions
> >
> > #              Ok  Python 1.5.2 on SuSE Linux 6.3
> > #              Ok  JPython 1.1 on java1.1.7B
> > # Partial failure  Python 1.5.2 win32
> >
> > print eval("float(1.0e-309)")
> > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309
> 
> First note that these don't do the same thing:  the first passes a float to
> "float", the second passes a string to "float".  Change the first to
> 
>     print eval("float('1.0e-309')")
> 
> and it gives the same bogus error as the second one.
> 
> Then it turns out the error is Microsoft's fault.  This tiny C program shows
> the bug:
> 
> #include <errno.h>
> #include <stdlib.h>
> #include <stdio.h>
> 
> void
> main()
> {
>     double x;
>     char* dontcare;
>     errno = 0;
>     x = strtod("1.0e-309", &dontcare);
>     printf("errno after = %d\n", errno);
>     printf("x after = %g\n", x);
> }
> 
> This prints
> 
>     errno after = 34
>     x after = 0
> 
> when compiled & linked with MS's VC5; don't know about VC6.  Same thing for
> "1.0e-308".  Works fine for "1.0e-307".  Doubt this will get fixed before MS
> fixes their library.

The bizarre thing is that this is broken the same way on Solaris:

>>> 1.0e-309
1.0000000000000019e-309
>>> float("1.0e-309")
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: float() literal too large: 1.0e-309
>>>

I looked and it turns out that Python uses atof() in the first case
(string literal encountered in a Python expression) and strtod() in
the second case (string passed to float()).

Apparently strtod() and atof() differ in implementation, even though
the Solaris man page says "The atof(str) function call is equivalent
to strtod(str, (char **)NULL)."

We could fix this by changing float() to do its own syntax checking
and then use atof()...  Is it worth it?

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Jul-31 14:08
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Fri, 24 Mar 2000 22:48:50 -0500

[atof and strtod act differently given denormals on both Windows &
 Solaris]

[Guido]
> ...
> Apparently strtod() and atof() differ in implementation, even though
> the Solaris man page says "The atof(str) function call is equivalent
> to strtod(str, (char **)NULL)."

Ya, their man page is lying.  atof() existed in the mists of prehistory and
typically did no error checking at all.  IIRC, ANSI C introduced strtod(),
which generally got implemented as a layer of error-checking around atof.

I have to take it back that this is a bug in MS's strtod:  DBL_MIN is MS's
limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero
inputs with absolute value smaller than that.

> We could fix this by changing float() to do its own syntax checking
> and then use atof()...  Is it worth it?

Depends on your goal <wink>:  do you want more extreme cases, like 1e-500,
to blow up (strtod) or underflow to 0 (atof)?  The example in the original
test case is subtler because atof made it *appear* to be "a regular old
number"; in fact, it's not, it's small enough that it falls into 754's
"denormalized" range.  This means the conversion loses some extraordinary
amount of-- but not all --information (whereas 1e-500 is below even the
denorm range:  conversion loses all information).

Without a coherent strategy for dealing with 754 issues, it's hard to decide
which is better.  Since strtod() is more restrictive, if this is worth
bothering about at all now (for P3K I think 754 needs to be taken
seriously), I actually recommend changing  current atof() calls to use
native strtod() instead.




-------------------------------------------------------

Date: 2000-Jul-31 14:08
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Fri, 24 Mar 2000 23:14:29 -0500

> [atof and strtod act differently given denormals on both Windows &
>  Solaris]
> 
> [Guido]
> > ...
> > Apparently strtod() and atof() differ in implementation, even though
> > the Solaris man page says "The atof(str) function call is equivalent
> > to strtod(str, (char **)NULL)."

[Tim]
> Ya, their man page is lying.  atof() existed in the mists of prehistory and
> typically did no error checking at all.  IIRC, ANSI C introduced strtod(),
> which generally got implemented as a layer of error-checking around atof.
> 
> I have to take it back that this is a bug in MS's strtod:  DBL_MIN is MS's
> limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero
> inputs with absolute value smaller than that.
> 
> > We could fix this by changing float() to do its own syntax checking
> > and then use atof()...  Is it worth it?
> 
> Depends on your goal <wink>:  do you want more extreme cases, like 1e-500,
> to blow up (strtod) or underflow to 0 (atof)?  The example in the original
> test case is subtler because atof made it *appear* to be "a regular old
> number"; in fact, it's not, it's small enough that it falls into 754's
> "denormalized" range.  This means the conversion loses some extraordinary
> amount of-- but not all --information (whereas 1e-500 is below even the
> denorm range:  conversion loses all information).
> 
> Without a coherent strategy for dealing with 754 issues, it's hard to decide
> which is better.  Since strtod() is more restrictive, if this is worth
> bothering about at all now (for P3K I think 754 needs to be taken
> seriously), I actually recommend changing  current atof() calls to use
> native strtod() instead.

Hm, I'm not so sure.  Suppose I'm writing a program that reads a data
files generated by some Fortran program.  The Fortran program is
giving me points to plot for example.  If Fortran manages to output
1e-500, wouldn't it make more sense if I rounded that to zero instead
of rejecting it?  After all, after converting to plot precision it's
going to be zero anyway.

This way I could almost defend using strtod() for literals in
Python source code (where it makes more sense to warn about underflow)
but atof() for input.  Except that of course input could conceivably
be using eval()...

Another argument for turning underflow into zero is that that also
happens in regular arithmetic:

>>> 0.1**2**8
1.0000000000000275e-256
>>> 0.1**2**9
0.0

I like this uniform behavior: overflow -> exception, underflow ->
zero.  My calculator does this too.

Am I hopelessly naive about this?  What else can we do?  What control
does C give?  What does sscanf() do?

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Jul-31 14:08
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Fri, 24 Mar 2000 23:53:10 -0500

"In the face of ambiguity, refuse the temptation to guess".

That's one of the Pythonic Theses you're tempted to ignore too often <wink>.

Part of taking 754 seriously is that 754 gives the user complete control
over what happens in case of exceptions (including underflow):  ignore them,
raise a fatal error, or simply set a flag saying it occurred.
Unfortunately, we have to wait for C9x until there's a portable way to get
at that stuff.  Before then, it requires wildly varying platform-specific
hair.

> Hm, I'm not so sure.  Suppose I'm writing a program that reads a data
> files generated by some Fortran program.  The Fortran program is
> giving me points to plot for example.  If Fortran manages to output
> 1e-500, wouldn't it make more sense if I rounded that to zero instead
> of rejecting it?

This *may* make good sense if Python had certain knowledge that the program
is merely going to plot the points, but probably not even then.  That is,
"insignificantly small" is relative to the application, and e.g. for all we
know the Fortran program generated a million doubles *all* in the range
[1e-500, 10e-500]:  the intended plot of the data could very well be a
pointillistic version of the Mona Lisa rather than a straight line.

> After all, after converting to plot precision it's
> going to be zero anyway.

As above, this conclusion relies on the dubious assumption that 1e-500 is
very much smaller than the other values.

> This way I could almost defend using strtod() for literals in
> Python source code (where it makes more sense to warn about underflow)
> but atof() for input.  Except that of course input could conceivably
> be using eval()...
>
> Another argument for turning underflow into zero is that that also
> happens in regular arithmetic:
>
> >>> 0.1**2**8
> 1.0000000000000275e-256
> >>> 0.1**2**9
> 0.0

Which is often desired but sometimes a disaster -- the language simply can't
guess.  On whatever machine you ran this on, it almost certainly set the
"underflow happened" flag but continued on because the underflow exception
was masked out by default.

> I like this uniform behavior: overflow -> exception, underflow ->
> zero.  My calculator does this too.

Not mine <wink>.  Really, whether underflow gripes is controlled by a
user-settable flag on high end HP calculators.  Note too that neither does
float *overflow* raise an exception under most Pythons today:

D:\Python>python
Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> 1e500
1.#INF
>>> 1e200**2
1.#INF
>>>

I personally favor raising exceptions (by default) on 754's overflow, divide
by 0, and invalid operation conditions, while (again by default) letting
underflow and inexact pass without comment.  But it again requires fiddling
the HW's 754 control registers to make that happen.  P3K, not now.

> Am I hopelessly naive about this?

Not *entirely* hopeless, but close <wink>.  If we ever talk about it for an
hour, I'll convince you of the futility of fighting 754.  They beat all
resistance out of me in a mere decade <0.5 wink>.

> What else can we do?

Not much!  Switching uniformly to either atof() or strtod() would be OK by
me for now, although I don't think patching over the current inconsistency
buys enough bang for the buck to be worth the effort.

> What control does C give?

None, until C9X.

> What does sscanf() do?

I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI
C's numerics fight the *right* thing to do now just about every step of the
way.  C9x is supposed to fix all that.

In the meantime, I think what JPython does is much more interesting (but
don't know what that is):  whatever we do here should be consistent with The
Other Python too, and Java has a much better 754 story than ANSI C.  754 is
here to stay, but the last iteration of ANSI C isn't.  Best guess is that
Java acts more like atof than strtod in this case.




-------------------------------------------------------

Date: 2000-Jul-31 14:08
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Sat, 25 Mar 2000 14:15:54 -0500

> "In the face of ambiguity, refuse the temptation to guess".
> 
> That's one of the Pythonic Theses you're tempted to ignore too often <wink>.
> 
> Part of taking 754 seriously is that 754 gives the user complete control
> over what happens in case of exceptions (including underflow):  ignore them,
> raise a fatal error, or simply set a flag saying it occurred.
> Unfortunately, we have to wait for C9x until there's a portable way to get
> at that stuff.  Before then, it requires wildly varying platform-specific
> hair.

OK, so let's stick with the defaults that 754 presecribes until we can
give the user control.  That's the purpose of defaults, right?

> > Hm, I'm not so sure.  Suppose I'm writing a program that reads a data
> > files generated by some Fortran program.  The Fortran program is
> > giving me points to plot for example.  If Fortran manages to output
> > 1e-500, wouldn't it make more sense if I rounded that to zero instead
> > of rejecting it?
> 
> This *may* make good sense if Python had certain knowledge that the program
> is merely going to plot the points, but probably not even then.  That is,
> "insignificantly small" is relative to the application, and e.g. for all we
> know the Fortran program generated a million doubles *all* in the range
> [1e-500, 10e-500]:  the intended plot of the data could very well be a
> pointillistic version of the Mona Lisa rather than a straight line.

OK, forget the example.

> > After all, after converting to plot precision it's
> > going to be zero anyway.
> 
> As above, this conclusion relies on the dubious assumption that 1e-500 is
> very much smaller than the other values.

I think even 754 tells us that 1e-500 is smaller than what we normally
need to deal with.

> > This way I could almost defend using strtod() for literals in
> > Python source code (where it makes more sense to warn about underflow)
> > but atof() for input.  Except that of course input could conceivably
> > be using eval()...
> >
> > Another argument for turning underflow into zero is that that also
> > happens in regular arithmetic:
> >
> > >>> 0.1**2**8
> > 1.0000000000000275e-256
> > >>> 0.1**2**9
> > 0.0
> 
> Which is often desired but sometimes a disaster -- the language simply can't
> guess.  On whatever machine you ran this on, it almost certainly set the
> "underflow happened" flag but continued on because the underflow exception
> was masked out by default.

Again: 754 gives a default.  I want to conform to the default -- it's
better to provide control, but even when we provide control, there will
still be default behavior, and (if I understand 754 correctly) the
default is not to interrupt for underflow.

> > I like this uniform behavior: overflow -> exception, underflow ->
> > zero.  My calculator does this too.
> 
> Not mine <wink>.  Really, whether underflow gripes is controlled by a
> user-settable flag on high end HP calculators.  Note too that neither does
> float *overflow* raise an exception under most Pythons today:
> 
> D:\Python>python
> Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> 1e500
> 1.#INF
> >>> 1e200**2
> 1.#INF
> >>>

Oops, you're right.  Must be another 754 default behavior!

> I personally favor raising exceptions (by default) on 754's overflow, divide
> by 0, and invalid operation conditions, while (again by default) letting
> the HW's 754 control registers to make that happen.  P3K, not now.

I would personally also prefer an exception for overflow.  You don't
say what you want for underflow though.  I still like silent underflow
to zero by default.

> > Am I hopelessly naive about this?
> 
> Not *entirely* hopeless, but close <wink>.  If we ever talk about it for an
> hour, I'll convince you of the futility of fighting 754.  They beat all
> resistance out of me in a mere decade <0.5 wink>.

I'm not fighting it.  Say the ideal Python has full user control over
fp exceptions.  What should the defaults be?  Python 1.6 should have
the same defaults, even if it doesn't have the controls.

> > What else can we do?
> 
> Not much!  Switching uniformly to either atof() or strtod() would be OK by
> me for now, although I don't think patching over the current inconsistency
> buys enough bang for the buck to be worth the effort.
> 
> > What control does C give?
> 
> None, until C9X.
> 
> > What does sscanf() do?
> 
> I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI
> C's numerics fight the *right* thing to do now just about every step of the
> way.  C9x is supposed to fix all that.
> 
> In the meantime, I think what JPython does is much more interesting (but
> don't know what that is):  whatever we do here should be consistent with The
> Other Python too, and Java has a much better 754 story than ANSI C.  754 is
> here to stay, but the last iteration of ANSI C isn't.  Best guess is that
> Java acts more like atof than strtod in this case.

Bingo.  Indeed it does.  1e500 prints as Infinity; 1e-500 is 0.0,
either as literal or when converted from a string.

I'll change float() to use atof().

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Jul-31 14:08
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Tue, 4 Apr 2000 00:29:01 -0400

[Guido]
> OK, so let's stick with the defaults that 754 presecribes until we can
> give the user control.  That's the purpose of defaults, right?

In every world other 754 (see below), but we really have no choice now
(because C doesn't give us any control now).

> I think even 754 tells us that 1e-500 is smaller than what we normally
> need to deal with.

Well, there is no 1e-500 under 754, which is why there's some reason to at
least warn about it (if the user wanted 0, why didn't they type 0?).

> Again: 754 gives a default.  I want to conform to the default -- it's
> better to provide control, but even when we provide control, there will
> still be default behavior, and (if I understand 754 correctly) the
> default is not to interrupt for underflow.

The 754 default is never to raise an exception no matter what, whether
overflow, underflow, invalid operation (like sqrt(-4)), or divide by 0.  So
Python's current behavior wrt these two is non-conforming:

    math.sqrt(-4)
    1. / 0.

However, 754 is primarily a HW std, and the defaults were prescribed by a
committee of HW geeks and math library authors.  They were caught totally
off guard by how long it took for languages to provide the control features
the std also mandates -- for "regular users" it's plainly insane to avoid
griping about the two above, and it was never 754's intent to let them pass
silently for regular users.

Note that Java has been skewered mercilessly by Kahan (Mr. 754 Himself) for
accepting the defaults but not providing the also-mandated control
functions.  The std is subtler than it appears, and all the fiddly bits are
really needed.

>> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>> >>> 1e500
>> 1.#INF
>> >>> 1e200**2
>> 1.#INF
>> >>>

> Oops, you're right.  Must be another 754 default behavior!

Right.

> I would personally also prefer an exception for overflow.  You don't
> say what you want for underflow though.  I still like silent underflow
> to zero by default.

754 defines (almost) everything:  underflow when the underflow exception is
masked out must deliver a zero with the same sign as the infinite-precision
result.

> I'm not fighting it.

You will <wink>; e.g., returning 1 for "x == x" is incorrect when x is a
NaN.

> Say the ideal Python has full user control over fp exceptions.  What
> should the defaults be?

IMO, exception on overflow, divide-by-0 and invalid operation.  Let
underflow and inexact pass silently.  That's what I implemented at KSR, and
customers were *very* much happier with that than with the 754 defaults.  Of
course I also implemented all the 754 control and status inquiry functions,
so the one 754-savvy programmer per site was happy too (they need the
control to write robust numerical libraries for everyone else to use -- the
*true* purpose of the 754 HW defaults).

> Python 1.6 should have the same defaults, even if it doesn't have the
> controls.

This is a big project, as there's no portable way even to detect fp overflow
now.  The math libraries should play along too.

> I'll change float() to use atof().

OK by me!




-------------------------------------------------------

Date: 2000-Aug-03 05:43
By: twouters

Comment:
I *think* this one is fixed and closed. It looks like Guido promises to fix this, in any case, and it looks done.

-------------------------------------------------------

Date: 2000-Aug-10 11:48
By: gvanrossum

Comment:
No, it's not fixed, but it is platform dependent how it behaves.
The conclusion was that we should use atof() everywhere, and write a separate syntax checker (since atof() stops at the first invalid character).
I made a start at a syntax checker but then got distracted. Here's my code:

static char *
floatsyntax(char *s)
{
	/* Check for valid floating point syntax:
	   space*
	   [sign]
	   (digit+ [period digit*] | period digit+)
	   [(e|E) [sign] digit+]
	   space*
	*/
	int digits, period;

	while (isspace(*s))
		s++;
	if (*s == '+' || *s == '-')
		s++;
	digits = period = 0;
	for (;;) {
		if (isdigit(*s))
			digits++;
		else if (*s == '.') {
			if (period)
				return NULL;
			period++;
		}
		else
			break;
	}
	if (!digits)
		return NULL;
	if (*s == 'e' || *s == 'E') {
		s++;
		if (*s == '+' || *s == '-')
			s++;
		digits = 0;
		while (isdigit(*s))
			digits++;
		if (!digits)
			return NULL;
	}
	return s;
}

-------------------------------------------------------

Date: 2000-Aug-10 11:51
By: gvanrossum

Comment:
Shit. SF removes leading whitespace. Oh well, mail me for a properly formatted version of that code.
-------------------------------------------------------

Date: 2000-Aug-10 21:57
By: tim_one

Comment:
It's curious that in the change mail SF generated, leading indentation was *not* lost.  This must be a browser display thing.
Anyway, by eyeball the syntax checker has two bugs:

1. Infinite loop when looking at an exponent.

x   while (isdigit(*s)) digits++; 

should be

x   while (isdigit(*s)) {digits++; s++;)

2. Like atof, stops at an invalid character.  Before the

x   return s;

it should have, e.g.,

x   while (ispace(*s)) ++s;
x   if (*s) return NULL;

although I'm not sure what the assumptions are about the input to this function.

-------------------------------------------------------

Date: 2000-Aug-27 11:38
By: gvanrossum

Comment:
I'm mailing Tim a fixed version of floatsyntax().
-------------------------------------------------------

Date: 2000-Aug-30 00:39
By: tim_one

Comment:
I'm afraid the code here is a freakin' mess.  No wonder Guido assigned it to me <0.3 wink>.  Turnabout is fair play, so I'm assigning it back to him (for Pronouncements, or at least to alert him what's going on here).

I *think* you intended to change the guts of PyFloat_FromString.  Which appears to be a so-far undocumented public API function, with a strtod-like prototype, and where nobody calls it with anything but NULL for the 2nd argument.  Does the signature of this have to remain the same, or can I toss the 2nd argument?  Or even define it to do something useful <wink>?  Note that in the Unicode case, pend is set to point into stack trash!

Python has its own strtod.c and atof.c files too.  Are these really needed, or can I toss those as well?  (They're not used on Windows, but I don't understand the layers of Unix config.)  They're both ANSI std, so I don't think we should be supplying our own anymore (besides which, they suck numerically).

Bad news:  our strategy for fixing this bug relies on atof() behavior that's explicitly not defined by the std (if strtod sets errno on a given input, the result of atof on that same input is undefined).  Let's assume from here on that we're just lucky.

Note that complex_from_string (bltinmodule.c) does its own by-hand parsing, again calling strtod directly, so the bug here will just pop up there too.

Ditto for load_float in cpickle.c (we can *write out* flost strings that strtod won't read back in -- in effect, that *is* this bug, in another guise).

Ditto for strop_atof in stropmodule.c.

If we *don't* assume we're lucky, there are about 6 calls to atof that are vulnerable too.

Unfortunately, C did a bad job of defining float<->string facilities, and C's problems have propagated throughout Python (i.e., wherever atof or strtod are called).

Note that atof/strtod both get much hairier in C99 (they sprout new ways to spell NaN and Inf, and support a new binary floating-point notation too).  The Python code calling these guys now doesn't know anything about that, so it will again be a distributed mess to fix all the call sites.

I suggest there should be exactly one routine in the entire source tree that converts strings to doubles, exactly one in the other direction too; and outside of the former, calls to atof and strtod should be strictly banned.  C is a mess here, C99 is less of a mess but much more complex, and we can't afford to have the mess or the complexity spread throughout the codebase.
-------------------------------------------------------

Date: 2000-Sep-06 17:18
By: gvanrossum

Comment:
Back to Tim.

- You can ignore strtod.c and atof.c; these aren't used *except* on platforms that don't have them in libc. (Are there any left? It used to be necessary for some, but that was almost 10 years ago.)

- Let's not change existing APIs, even if they aren't documented.

- Let's assume we're "lucky".

- I agree with your proposed solution: one function each way. Go ahead! This is fine for 2.0b1.
-------------------------------------------------------

Date: 2000-Sep-22 18:08
By: tim_one

Comment:
Changed Resolution back to None since I'm working on it now.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110624&group_id=5470

From noreply@sourceforge.net  Sat Sep 23 04:37:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 20:37:57 -0700
Subject: [Python-bugs-list] [Bug #110624] float("1.0e-309") inconsistency (PR#245)
Message-ID: <200009230337.UAA22091@delerium.i.sourceforge.net>

Bug #110624, was updated on 2000-Jul-31 14:08
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: float("1.0e-309") inconsistency (PR#245)

Details: Jitterbug-Id: 245
Submitted-By: sde@recombinant.demon.co.uk
Date: Wed, 22 Mar 2000 16:13:26 -0500 (EST)
Version: 1.5.2
OS: win32


#! /usr/bin/python

# Inconsistent behaviour.

# Python 1.5.2 win32 fails the second print (why not both?)
# other versions print both expressions

#              Ok  Python 1.5.2 on SuSE Linux 6.3
#              Ok  JPython 1.1 on java1.1.7B
# Partial failure  Python 1.5.2 win32

print eval("float(1.0e-309)")
print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309




====================================================================
Audit trail:
Fri Mar 24 16:42:36 2000	guido	changed notes
Fri Mar 24 16:42:36 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Jul-31 14:08
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Thu, 23 Mar 2000 01:43:30 -0500

> -----Original Message-----
> From: python-bugs-list-admin@python.org
> [mailto:python-bugs-list-admin@python.org]On Behalf Of
> sde@recombinant.demon.co.uk
> Sent: Wednesday, March 22, 2000 4:13 PM
> To: python-bugs-list@python.org
> Cc: bugs-py@python.org
> Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32
> (PR#245)
>
>
> Full_Name: Stephen D Evans
> Version: 1.5.2
> OS: win32
> Submission from: recombinant.demon.co.uk (212.229.73.7)
>
>
> #! /usr/bin/python
>
> # Inconsistent behaviour.
>
> # Python 1.5.2 win32 fails the second print (why not both?)
> # other versions print both expressions
>
> #              Ok  Python 1.5.2 on SuSE Linux 6.3
> #              Ok  JPython 1.1 on java1.1.7B
> # Partial failure  Python 1.5.2 win32
>
> print eval("float(1.0e-309)")
> print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309

First note that these don't do the same thing:  the first passes a float to
"float", the second passes a string to "float".  Change the first to

    print eval("float('1.0e-309')")

and it gives the same bogus error as the second one.

Then it turns out the error is Microsoft's fault.  This tiny C program shows
the bug:

#include <errno.h>
#include <stdlib.h>
#include <stdio.h>

void
main()
{
    double x;
    char* dontcare;
    errno = 0;
    x = strtod("1.0e-309", &dontcare);
    printf("errno after = %d\n", errno);
    printf("x after = %g\n", x);
}

This prints

    errno after = 34
    x after = 0

when compiled & linked with MS's VC5; don't know about VC6.  Same thing for
"1.0e-308".  Works fine for "1.0e-307".  Doubt this will get fixed before MS
fixes their library.




-------------------------------------------------------

Date: 2000-Jul-31 14:08
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Fri, 24 Mar 2000 04:51:57 -0500

> > Full_Name: Stephen D Evans
> > Version: 1.5.2
> > OS: win32
> > Submission from: recombinant.demon.co.uk (212.229.73.7)
> >
> >
> > #! /usr/bin/python
> >
> > # Inconsistent behaviour.
> >
> > # Python 1.5.2 win32 fails the second print (why not both?)
> > # other versions print both expressions
> >
> > #              Ok  Python 1.5.2 on SuSE Linux 6.3
> > #              Ok  JPython 1.1 on java1.1.7B
> > # Partial failure  Python 1.5.2 win32
> >
> > print eval("float(1.0e-309)")
> > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309
> 
> First note that these don't do the same thing:  the first passes a float to
> "float", the second passes a string to "float".  Change the first to
> 
>     print eval("float('1.0e-309')")
> 
> and it gives the same bogus error as the second one.
> 
> Then it turns out the error is Microsoft's fault.  This tiny C program shows
> the bug:
> 
> #include <errno.h>
> #include <stdlib.h>
> #include <stdio.h>
> 
> void
> main()
> {
>     double x;
>     char* dontcare;
>     errno = 0;
>     x = strtod("1.0e-309", &dontcare);
>     printf("errno after = %d\n", errno);
>     printf("x after = %g\n", x);
> }
> 
> This prints
> 
>     errno after = 34
>     x after = 0
> 
> when compiled & linked with MS's VC5; don't know about VC6.  Same thing for
> "1.0e-308".  Works fine for "1.0e-307".  Doubt this will get fixed before MS
> fixes their library.

The bizarre thing is that this is broken the same way on Solaris:

>>> 1.0e-309
1.0000000000000019e-309
>>> float("1.0e-309")
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ValueError: float() literal too large: 1.0e-309
>>>

I looked and it turns out that Python uses atof() in the first case
(string literal encountered in a Python expression) and strtod() in
the second case (string passed to float()).

Apparently strtod() and atof() differ in implementation, even though
the Solaris man page says "The atof(str) function call is equivalent
to strtod(str, (char **)NULL)."

We could fix this by changing float() to do its own syntax checking
and then use atof()...  Is it worth it?

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Jul-31 14:08
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Fri, 24 Mar 2000 22:48:50 -0500

[atof and strtod act differently given denormals on both Windows &
 Solaris]

[Guido]
> ...
> Apparently strtod() and atof() differ in implementation, even though
> the Solaris man page says "The atof(str) function call is equivalent
> to strtod(str, (char **)NULL)."

Ya, their man page is lying.  atof() existed in the mists of prehistory and
typically did no error checking at all.  IIRC, ANSI C introduced strtod(),
which generally got implemented as a layer of error-checking around atof.

I have to take it back that this is a bug in MS's strtod:  DBL_MIN is MS's
limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero
inputs with absolute value smaller than that.

> We could fix this by changing float() to do its own syntax checking
> and then use atof()...  Is it worth it?

Depends on your goal <wink>:  do you want more extreme cases, like 1e-500,
to blow up (strtod) or underflow to 0 (atof)?  The example in the original
test case is subtler because atof made it *appear* to be "a regular old
number"; in fact, it's not, it's small enough that it falls into 754's
"denormalized" range.  This means the conversion loses some extraordinary
amount of-- but not all --information (whereas 1e-500 is below even the
denorm range:  conversion loses all information).

Without a coherent strategy for dealing with 754 issues, it's hard to decide
which is better.  Since strtod() is more restrictive, if this is worth
bothering about at all now (for P3K I think 754 needs to be taken
seriously), I actually recommend changing  current atof() calls to use
native strtod() instead.




-------------------------------------------------------

Date: 2000-Jul-31 14:08
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Fri, 24 Mar 2000 23:14:29 -0500

> [atof and strtod act differently given denormals on both Windows &
>  Solaris]
> 
> [Guido]
> > ...
> > Apparently strtod() and atof() differ in implementation, even though
> > the Solaris man page says "The atof(str) function call is equivalent
> > to strtod(str, (char **)NULL)."

[Tim]
> Ya, their man page is lying.  atof() existed in the mists of prehistory and
> typically did no error checking at all.  IIRC, ANSI C introduced strtod(),
> which generally got implemented as a layer of error-checking around atof.
> 
> I have to take it back that this is a bug in MS's strtod:  DBL_MIN is MS's
> limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero
> inputs with absolute value smaller than that.
> 
> > We could fix this by changing float() to do its own syntax checking
> > and then use atof()...  Is it worth it?
> 
> Depends on your goal <wink>:  do you want more extreme cases, like 1e-500,
> to blow up (strtod) or underflow to 0 (atof)?  The example in the original
> test case is subtler because atof made it *appear* to be "a regular old
> number"; in fact, it's not, it's small enough that it falls into 754's
> "denormalized" range.  This means the conversion loses some extraordinary
> amount of-- but not all --information (whereas 1e-500 is below even the
> denorm range:  conversion loses all information).
> 
> Without a coherent strategy for dealing with 754 issues, it's hard to decide
> which is better.  Since strtod() is more restrictive, if this is worth
> bothering about at all now (for P3K I think 754 needs to be taken
> seriously), I actually recommend changing  current atof() calls to use
> native strtod() instead.

Hm, I'm not so sure.  Suppose I'm writing a program that reads a data
files generated by some Fortran program.  The Fortran program is
giving me points to plot for example.  If Fortran manages to output
1e-500, wouldn't it make more sense if I rounded that to zero instead
of rejecting it?  After all, after converting to plot precision it's
going to be zero anyway.

This way I could almost defend using strtod() for literals in
Python source code (where it makes more sense to warn about underflow)
but atof() for input.  Except that of course input could conceivably
be using eval()...

Another argument for turning underflow into zero is that that also
happens in regular arithmetic:

>>> 0.1**2**8
1.0000000000000275e-256
>>> 0.1**2**9
0.0

I like this uniform behavior: overflow -> exception, underflow ->
zero.  My calculator does this too.

Am I hopelessly naive about this?  What else can we do?  What control
does C give?  What does sscanf() do?

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Jul-31 14:08
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Fri, 24 Mar 2000 23:53:10 -0500

"In the face of ambiguity, refuse the temptation to guess".

That's one of the Pythonic Theses you're tempted to ignore too often <wink>.

Part of taking 754 seriously is that 754 gives the user complete control
over what happens in case of exceptions (including underflow):  ignore them,
raise a fatal error, or simply set a flag saying it occurred.
Unfortunately, we have to wait for C9x until there's a portable way to get
at that stuff.  Before then, it requires wildly varying platform-specific
hair.

> Hm, I'm not so sure.  Suppose I'm writing a program that reads a data
> files generated by some Fortran program.  The Fortran program is
> giving me points to plot for example.  If Fortran manages to output
> 1e-500, wouldn't it make more sense if I rounded that to zero instead
> of rejecting it?

This *may* make good sense if Python had certain knowledge that the program
is merely going to plot the points, but probably not even then.  That is,
"insignificantly small" is relative to the application, and e.g. for all we
know the Fortran program generated a million doubles *all* in the range
[1e-500, 10e-500]:  the intended plot of the data could very well be a
pointillistic version of the Mona Lisa rather than a straight line.

> After all, after converting to plot precision it's
> going to be zero anyway.

As above, this conclusion relies on the dubious assumption that 1e-500 is
very much smaller than the other values.

> This way I could almost defend using strtod() for literals in
> Python source code (where it makes more sense to warn about underflow)
> but atof() for input.  Except that of course input could conceivably
> be using eval()...
>
> Another argument for turning underflow into zero is that that also
> happens in regular arithmetic:
>
> >>> 0.1**2**8
> 1.0000000000000275e-256
> >>> 0.1**2**9
> 0.0

Which is often desired but sometimes a disaster -- the language simply can't
guess.  On whatever machine you ran this on, it almost certainly set the
"underflow happened" flag but continued on because the underflow exception
was masked out by default.

> I like this uniform behavior: overflow -> exception, underflow ->
> zero.  My calculator does this too.

Not mine <wink>.  Really, whether underflow gripes is controlled by a
user-settable flag on high end HP calculators.  Note too that neither does
float *overflow* raise an exception under most Pythons today:

D:\Python>python
Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> 1e500
1.#INF
>>> 1e200**2
1.#INF
>>>

I personally favor raising exceptions (by default) on 754's overflow, divide
by 0, and invalid operation conditions, while (again by default) letting
underflow and inexact pass without comment.  But it again requires fiddling
the HW's 754 control registers to make that happen.  P3K, not now.

> Am I hopelessly naive about this?

Not *entirely* hopeless, but close <wink>.  If we ever talk about it for an
hour, I'll convince you of the futility of fighting 754.  They beat all
resistance out of me in a mere decade <0.5 wink>.

> What else can we do?

Not much!  Switching uniformly to either atof() or strtod() would be OK by
me for now, although I don't think patching over the current inconsistency
buys enough bang for the buck to be worth the effort.

> What control does C give?

None, until C9X.

> What does sscanf() do?

I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI
C's numerics fight the *right* thing to do now just about every step of the
way.  C9x is supposed to fix all that.

In the meantime, I think what JPython does is much more interesting (but
don't know what that is):  whatever we do here should be consistent with The
Other Python too, and Java has a much better 754 story than ANSI C.  754 is
here to stay, but the last iteration of ANSI C isn't.  Best guess is that
Java acts more like atof than strtod in this case.




-------------------------------------------------------

Date: 2000-Jul-31 14:08
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Sat, 25 Mar 2000 14:15:54 -0500

> "In the face of ambiguity, refuse the temptation to guess".
> 
> That's one of the Pythonic Theses you're tempted to ignore too often <wink>.
> 
> Part of taking 754 seriously is that 754 gives the user complete control
> over what happens in case of exceptions (including underflow):  ignore them,
> raise a fatal error, or simply set a flag saying it occurred.
> Unfortunately, we have to wait for C9x until there's a portable way to get
> at that stuff.  Before then, it requires wildly varying platform-specific
> hair.

OK, so let's stick with the defaults that 754 presecribes until we can
give the user control.  That's the purpose of defaults, right?

> > Hm, I'm not so sure.  Suppose I'm writing a program that reads a data
> > files generated by some Fortran program.  The Fortran program is
> > giving me points to plot for example.  If Fortran manages to output
> > 1e-500, wouldn't it make more sense if I rounded that to zero instead
> > of rejecting it?
> 
> This *may* make good sense if Python had certain knowledge that the program
> is merely going to plot the points, but probably not even then.  That is,
> "insignificantly small" is relative to the application, and e.g. for all we
> know the Fortran program generated a million doubles *all* in the range
> [1e-500, 10e-500]:  the intended plot of the data could very well be a
> pointillistic version of the Mona Lisa rather than a straight line.

OK, forget the example.

> > After all, after converting to plot precision it's
> > going to be zero anyway.
> 
> As above, this conclusion relies on the dubious assumption that 1e-500 is
> very much smaller than the other values.

I think even 754 tells us that 1e-500 is smaller than what we normally
need to deal with.

> > This way I could almost defend using strtod() for literals in
> > Python source code (where it makes more sense to warn about underflow)
> > but atof() for input.  Except that of course input could conceivably
> > be using eval()...
> >
> > Another argument for turning underflow into zero is that that also
> > happens in regular arithmetic:
> >
> > >>> 0.1**2**8
> > 1.0000000000000275e-256
> > >>> 0.1**2**9
> > 0.0
> 
> Which is often desired but sometimes a disaster -- the language simply can't
> guess.  On whatever machine you ran this on, it almost certainly set the
> "underflow happened" flag but continued on because the underflow exception
> was masked out by default.

Again: 754 gives a default.  I want to conform to the default -- it's
better to provide control, but even when we provide control, there will
still be default behavior, and (if I understand 754 correctly) the
default is not to interrupt for underflow.

> > I like this uniform behavior: overflow -> exception, underflow ->
> > zero.  My calculator does this too.
> 
> Not mine <wink>.  Really, whether underflow gripes is controlled by a
> user-settable flag on high end HP calculators.  Note too that neither does
> float *overflow* raise an exception under most Pythons today:
> 
> D:\Python>python
> Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> 1e500
> 1.#INF
> >>> 1e200**2
> 1.#INF
> >>>

Oops, you're right.  Must be another 754 default behavior!

> I personally favor raising exceptions (by default) on 754's overflow, divide
> by 0, and invalid operation conditions, while (again by default) letting
> the HW's 754 control registers to make that happen.  P3K, not now.

I would personally also prefer an exception for overflow.  You don't
say what you want for underflow though.  I still like silent underflow
to zero by default.

> > Am I hopelessly naive about this?
> 
> Not *entirely* hopeless, but close <wink>.  If we ever talk about it for an
> hour, I'll convince you of the futility of fighting 754.  They beat all
> resistance out of me in a mere decade <0.5 wink>.

I'm not fighting it.  Say the ideal Python has full user control over
fp exceptions.  What should the defaults be?  Python 1.6 should have
the same defaults, even if it doesn't have the controls.

> > What else can we do?
> 
> Not much!  Switching uniformly to either atof() or strtod() would be OK by
> me for now, although I don't think patching over the current inconsistency
> buys enough bang for the buck to be worth the effort.
> 
> > What control does C give?
> 
> None, until C9X.
> 
> > What does sscanf() do?
> 
> I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI
> C's numerics fight the *right* thing to do now just about every step of the
> way.  C9x is supposed to fix all that.
> 
> In the meantime, I think what JPython does is much more interesting (but
> don't know what that is):  whatever we do here should be consistent with The
> Other Python too, and Java has a much better 754 story than ANSI C.  754 is
> here to stay, but the last iteration of ANSI C isn't.  Best guess is that
> Java acts more like atof than strtod in this case.

Bingo.  Indeed it does.  1e500 prints as Infinity; 1e-500 is 0.0,
either as literal or when converted from a string.

I'll change float() to use atof().

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Jul-31 14:08
By: none

Comment:
From: "Tim Peters" <tim_one@email.msn.com>
Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245)
Date: Tue, 4 Apr 2000 00:29:01 -0400

[Guido]
> OK, so let's stick with the defaults that 754 presecribes until we can
> give the user control.  That's the purpose of defaults, right?

In every world other 754 (see below), but we really have no choice now
(because C doesn't give us any control now).

> I think even 754 tells us that 1e-500 is smaller than what we normally
> need to deal with.

Well, there is no 1e-500 under 754, which is why there's some reason to at
least warn about it (if the user wanted 0, why didn't they type 0?).

> Again: 754 gives a default.  I want to conform to the default -- it's
> better to provide control, but even when we provide control, there will
> still be default behavior, and (if I understand 754 correctly) the
> default is not to interrupt for underflow.

The 754 default is never to raise an exception no matter what, whether
overflow, underflow, invalid operation (like sqrt(-4)), or divide by 0.  So
Python's current behavior wrt these two is non-conforming:

    math.sqrt(-4)
    1. / 0.

However, 754 is primarily a HW std, and the defaults were prescribed by a
committee of HW geeks and math library authors.  They were caught totally
off guard by how long it took for languages to provide the control features
the std also mandates -- for "regular users" it's plainly insane to avoid
griping about the two above, and it was never 754's intent to let them pass
silently for regular users.

Note that Java has been skewered mercilessly by Kahan (Mr. 754 Himself) for
accepting the defaults but not providing the also-mandated control
functions.  The std is subtler than it appears, and all the fiddly bits are
really needed.

>> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>> >>> 1e500
>> 1.#INF
>> >>> 1e200**2
>> 1.#INF
>> >>>

> Oops, you're right.  Must be another 754 default behavior!

Right.

> I would personally also prefer an exception for overflow.  You don't
> say what you want for underflow though.  I still like silent underflow
> to zero by default.

754 defines (almost) everything:  underflow when the underflow exception is
masked out must deliver a zero with the same sign as the infinite-precision
result.

> I'm not fighting it.

You will <wink>; e.g., returning 1 for "x == x" is incorrect when x is a
NaN.

> Say the ideal Python has full user control over fp exceptions.  What
> should the defaults be?

IMO, exception on overflow, divide-by-0 and invalid operation.  Let
underflow and inexact pass silently.  That's what I implemented at KSR, and
customers were *very* much happier with that than with the 754 defaults.  Of
course I also implemented all the 754 control and status inquiry functions,
so the one 754-savvy programmer per site was happy too (they need the
control to write robust numerical libraries for everyone else to use -- the
*true* purpose of the 754 HW defaults).

> Python 1.6 should have the same defaults, even if it doesn't have the
> controls.

This is a big project, as there's no portable way even to detect fp overflow
now.  The math libraries should play along too.

> I'll change float() to use atof().

OK by me!




-------------------------------------------------------

Date: 2000-Aug-03 05:43
By: twouters

Comment:
I *think* this one is fixed and closed. It looks like Guido promises to fix this, in any case, and it looks done.

-------------------------------------------------------

Date: 2000-Aug-10 11:48
By: gvanrossum

Comment:
No, it's not fixed, but it is platform dependent how it behaves.
The conclusion was that we should use atof() everywhere, and write a separate syntax checker (since atof() stops at the first invalid character).
I made a start at a syntax checker but then got distracted. Here's my code:

static char *
floatsyntax(char *s)
{
	/* Check for valid floating point syntax:
	   space*
	   [sign]
	   (digit+ [period digit*] | period digit+)
	   [(e|E) [sign] digit+]
	   space*
	*/
	int digits, period;

	while (isspace(*s))
		s++;
	if (*s == '+' || *s == '-')
		s++;
	digits = period = 0;
	for (;;) {
		if (isdigit(*s))
			digits++;
		else if (*s == '.') {
			if (period)
				return NULL;
			period++;
		}
		else
			break;
	}
	if (!digits)
		return NULL;
	if (*s == 'e' || *s == 'E') {
		s++;
		if (*s == '+' || *s == '-')
			s++;
		digits = 0;
		while (isdigit(*s))
			digits++;
		if (!digits)
			return NULL;
	}
	return s;
}

-------------------------------------------------------

Date: 2000-Aug-10 11:51
By: gvanrossum

Comment:
Shit. SF removes leading whitespace. Oh well, mail me for a properly formatted version of that code.
-------------------------------------------------------

Date: 2000-Aug-10 21:57
By: tim_one

Comment:
It's curious that in the change mail SF generated, leading indentation was *not* lost.  This must be a browser display thing.
Anyway, by eyeball the syntax checker has two bugs:

1. Infinite loop when looking at an exponent.

x   while (isdigit(*s)) digits++; 

should be

x   while (isdigit(*s)) {digits++; s++;)

2. Like atof, stops at an invalid character.  Before the

x   return s;

it should have, e.g.,

x   while (ispace(*s)) ++s;
x   if (*s) return NULL;

although I'm not sure what the assumptions are about the input to this function.

-------------------------------------------------------

Date: 2000-Aug-27 11:38
By: gvanrossum

Comment:
I'm mailing Tim a fixed version of floatsyntax().
-------------------------------------------------------

Date: 2000-Aug-30 00:39
By: tim_one

Comment:
I'm afraid the code here is a freakin' mess.  No wonder Guido assigned it to me <0.3 wink>.  Turnabout is fair play, so I'm assigning it back to him (for Pronouncements, or at least to alert him what's going on here).

I *think* you intended to change the guts of PyFloat_FromString.  Which appears to be a so-far undocumented public API function, with a strtod-like prototype, and where nobody calls it with anything but NULL for the 2nd argument.  Does the signature of this have to remain the same, or can I toss the 2nd argument?  Or even define it to do something useful <wink>?  Note that in the Unicode case, pend is set to point into stack trash!

Python has its own strtod.c and atof.c files too.  Are these really needed, or can I toss those as well?  (They're not used on Windows, but I don't understand the layers of Unix config.)  They're both ANSI std, so I don't think we should be supplying our own anymore (besides which, they suck numerically).

Bad news:  our strategy for fixing this bug relies on atof() behavior that's explicitly not defined by the std (if strtod sets errno on a given input, the result of atof on that same input is undefined).  Let's assume from here on that we're just lucky.

Note that complex_from_string (bltinmodule.c) does its own by-hand parsing, again calling strtod directly, so the bug here will just pop up there too.

Ditto for load_float in cpickle.c (we can *write out* flost strings that strtod won't read back in -- in effect, that *is* this bug, in another guise).

Ditto for strop_atof in stropmodule.c.

If we *don't* assume we're lucky, there are about 6 calls to atof that are vulnerable too.

Unfortunately, C did a bad job of defining float<->string facilities, and C's problems have propagated throughout Python (i.e., wherever atof or strtod are called).

Note that atof/strtod both get much hairier in C99 (they sprout new ways to spell NaN and Inf, and support a new binary floating-point notation too).  The Python code calling these guys now doesn't know anything about that, so it will again be a distributed mess to fix all the call sites.

I suggest there should be exactly one routine in the entire source tree that converts strings to doubles, exactly one in the other direction too; and outside of the former, calls to atof and strtod should be strictly banned.  C is a mess here, C99 is less of a mess but much more complex, and we can't afford to have the mess or the complexity spread throughout the codebase.
-------------------------------------------------------

Date: 2000-Sep-06 17:18
By: gvanrossum

Comment:
Back to Tim.

- You can ignore strtod.c and atof.c; these aren't used *except* on platforms that don't have them in libc. (Are there any left? It used to be necessary for some, but that was almost 10 years ago.)

- Let's not change existing APIs, even if they aren't documented.

- Let's assume we're "lucky".

- I agree with your proposed solution: one function each way. Go ahead! This is fine for 2.0b1.
-------------------------------------------------------

Date: 2000-Sep-22 18:08
By: tim_one

Comment:
Changed Resolution back to None since I'm working on it now.
-------------------------------------------------------

Date: 2000-Sep-22 20:37
By: tim_one

Comment:
I fixed the specific complaint (1e-309 is returned in both contexts now).  Changed the summary line to remove the "Win32" bit, since it also occurred on some flavors of Unix.

The grander schemes are, I think, hopeless before P3K and C99.  For example:

+ The low-level details of floating-point syntax are locale-dependent, and up until now we've deferred to the platform on all such issues (including ways they may have to spell infinity and NaN).  So we can't plug in any parser of our own that won't break *somebody's* code without a whale of a lot of work and community help.  C99 is better-defined.

+ Safe ways to generate infs and NaNs are wildly platform-dependent now.  C99 and P3K.

Note that I didn't change the interface to PyFloat_FromString, but did declare that its 2nd (pend) argument is now officially useless (see the checkin comment for why).

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110624&group_id=5470

From noreply@sourceforge.net  Sat Sep 23 04:46:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 20:46:02 -0700
Subject: [Python-bugs-list] [Bug #114598] Blue Screen crash, popen, Win98, Norton Antivirus 2000
Message-ID: <200009230346.UAA22355@delerium.i.sourceforge.net>

Bug #114598, was updated on 2000-Sep-16 13:24
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 6
Summary: Blue Screen crash, popen, Win98, Norton Antivirus 2000

Details: On Windows 98, all of the os.popen*() functions cause a hard "blue screen" crash requiring a reboot, when Nortin Antivirus 2000 is installed and enabled. (Not with Norton Antivirus version 5, not on Windows 2000.)

While this is probably a bug in Norton Antivirus 2000, and we're already warning for this on the download page, that's not enough (we've seen at least one report in the newsgroup), and it would be good if we could somehow prevent it. Even a call to Py_FatalError is better than the blue screen, and raising os.error would be a *lot* better.

Follow-Ups:

Date: 2000-Sep-16 14:26
By: tim_one

Comment:
I don't know how to stop this.  Pissed away an hour trying to get help on the Symantec site, and eventually found a support board to which I posted this msg:

Product: Norton AntiVirus 2000 6.0 for Windows 95/98/NT
Supported operating system: Windows 98
Action: Run Another Program
Error Message: 
Summary: Blue screen crash

I develop the Windows version of the core Python language. Several reports of blue-screen death on Win98 have been traced to NAV2000.  Here's the exact msg from one such:

An exception 0E has occurred at 0028:C02AD9D0 in VxD IFSMGR(04) + 000050E4. This was called from 0028:C000B511 in VxD VMM(01) + 0000A511. It may be possible to continue normally.

This occurs whenever a user executes a member of the popen family of functions from within Python; for example, this Python program:

import os
p = os.popen("dir")

popen is a std C library function, poorly implemented by Microsoft, but not *that* poorly <wink>.

You can get our latest installer here:

http://www.pythonlabs.com/tech/python2.0/download.html

As the warning there says:

-----------------
Incompatibility warning: Norton Antivirus 2000 can cause blue screen crashes on Windows 98 when a function in the os.popen*() family is invoked. To prevent this problem, disable Norton Antivirus when using Python. (Confirmed on Windows 98 Second Edition with Norton Antivirus version 6.10.20. The same Norton Antivirus version doesn't have this
problem on Windows 2000. Norton Antivirus version 5 on Windows 98SE doesn't have this problem either.) 
-----------------

ActiveState is seeing the same problem with their derivative work ActivePython, as is PythonWare with their derivative work PythonWorks. So this affects a lot of people. A recent change to the implementation of a popular library module has made it acutely visible recently (didn't use to use popen, but does now).

A workaround would be nice. More importantly, how can I *detect* whether an affected version of NAV is in use, so that we can shut down Python gracefully with an appropriate message before executing any of the popen functions that throw NAV into blue-screen territory? We try to be a very user-friendly language, and we'll do anything to prevent a crash. Alas, right now I don't know how to stop it.

-------------------------------------------------------

Date: 2000-Sep-19 02:21
By: tim_one

Comment:
1. Sent Guido a small self-contained C program in the hope that it's enough to provoke the problem by itself.  Reassigned this bug to Guido since he has to tell me what happens with that next (then assign back to me).

2. That's because Symantec is being no help at all.  They suggest upgrading to NAV 2001(!).  If I can post a tiny C program, maybe it will embarrass then into doing something.  You can follow this soap opera at:

http://servicenews.symantec.com/cgi-bin/displayArticle.cgi?group=symantec.support.win9x.nortonantivirus2000.general&article=57765

-------------------------------------------------------

Date: 2000-Sep-19 09:06
By: gvanrossum

Comment:
Tim's little C program crashes in the same way as Python when NAV2000 is enabled. back to Tim...
-------------------------------------------------------

Date: 2000-Sep-21 11:32
By: tim_one

Comment:
I cranked up my obnoxiousness level on the Symantec board (URL two comments down), and they may be on the edge of taking this seriously now.
-------------------------------------------------------

Date: 2000-Sep-22 20:46
By: tim_one

Comment:
Reduced the priority a notch.  The biggest trigger here was IDLE's use of os.popen (indirectly via webbrowser.py) to launch the Python HTML docs.  I put in a new Windows function (os.startfile) that uses Win32 ShellExecute instead, and changed webbrowser.py to use that.  IDLE now lives peacefully with NAV 6.10.20.

This was all Guido's idea, and he suggested that the priority of this bug should be dropped now.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114598&group_id=5470

From noreply@sourceforge.net  Sat Sep 23 05:18:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 21:18:21 -0700
Subject: [Python-bugs-list] [Bug #115126] Over restricted type checking on eval() function
Message-ID: <200009230418.VAA31488@bush.i.sourceforge.net>

Bug #115126, was updated on 2000-Sep-22 12:36
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 5
Summary: Over restricted type checking on eval() function

Details: The built-in function eval() takes a string argument and a dictionary.  The second argument should allow any instance which defines __getitem__ as opposed to just dictionaries.

The following example creates a type error:
  eval, argument 2: expected dictionary,   instance found

class SpreadSheet:
    _cells = {}
    def __setitem__( self, key, formula ):
        self._cells[key] = formula
    def __getitem__( self, key ):
        return eval( self._cells[key], self )

ss = SpreadSheet()
ss['a1'] = '5'
ss['a2'] = 'a1*5'
ss['a2']


Follow-Ups:

Date: 2000-Sep-22 12:42
By: tim_one

Comment:
Changed Group to Feature Request.  Should be added to PEP 42 (I'll do that if nobody beats me to it).

CPython requires a genuine dict now for speed.  I believe JPython allows any mapping object.

-------------------------------------------------------

Date: 2000-Sep-22 21:18
By: tim_one

Comment:
Added to PEP 42.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115126&group_id=5470

From noreply@sourceforge.net  Sat Sep 23 05:37:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 21:37:55 -0700
Subject: [Python-bugs-list] [Bug #110644] bug in PyLong_FromLongLong (PR#324)
Message-ID: <200009230437.VAA32095@bush.i.sourceforge.net>

Bug #110644, was updated on 2000-Jul-31 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: bug in PyLong_FromLongLong (PR#324)

Details: Jitterbug-Id: 324
Submitted-By: Thomas.Malik@t-online.de
Date: Wed, 10 May 2000 15:37:28 -0400 (EDT)
Version: 1.5.2
OS: all


there's a bug in PyLong_FromLongLong, resulting in truncation of negative 64 bit
integers. PyLong_FromLongLong starts with: 
	if( ival <= (LONG_LONG)LONG_MAX ) {
		return PyLong_FromLong( (long)ival );
	}
	else if( ival <= (unsigned LONG_LONG)ULONG_MAX ) {
		return PyLong_FromUnsignedLong( (unsigned long)ival );
	}
	else {
             ....

Now, if ival is smaller than -LONG_MAX, it falls outside the long integer range
(being a 64 bit negative integer), but gets handled by the first if-then-case in
above code ('cause it is, of course, smaller than LONG_MAX). This results in
truncation of the 64 bit negative integer to a more or less arbitrary 32 bit
number. The way to fix it is to compare the absolute value of imax against
LONG_MAX in the first condition. The second condition (ULONG_MAX) must, at
least, check wether ival is positive. 




====================================================================
Audit trail:
Mon May 22 17:13:25 2000	guido	changed notes
Mon May 22 17:13:25 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-23 11:20
By: tim_one

Comment:
Reassigned from Trent to me -- Python had the same bug in its "regular int" code for years, and I fixed it there, so I should fix it here too.  'Tis tricky to get right.
-------------------------------------------------------

Date: 2000-Aug-23 15:08
By: tmick

Comment:
Tim, Sorry to have left this siting here. I did not know that it was assigned to me. The code is now:
    if ((LONG_LONG)LONG_MIN <= ival && ival <= (LONG_LONG)LONG_MAX) {
        return PyLong_FromLong( (long)ival );
    }
    else if (0 <= ival && ival <= (unsigned LONG_LONG)ULONG_MAX) {
        return PyLong_FromUnsignedLong( (unsigned long)ival );
    }
    else {

which means that the bug is fixed n'est ce pas? I remember discussing this way back (though "way back" for me is like last week for you).

-------------------------------------------------------

Date: 2000-Aug-23 17:27
By: tim_one

Comment:
What do you mean you didn't know it was assigned to you?  It was assigned to you for an entire 7 minutes before I reassigned it to me <wink>!
So I assigned it back to you.  You're indeed right about the fix -- I had hallucinated this into something deeper than it was.  Better for you to fix it since you can actually test it!  Thanks, Trent.
-------------------------------------------------------

Date: 2000-Aug-31 08:49
By: tmick

Comment:
I am confident that this is fixed I just can't test it because my Win64 box is currently down. I'll leave it open and close it when I get a change to verify (a week or two from now).
-------------------------------------------------------

Date: 2000-Sep-22 21:37
By: tim_one

Comment:
Marked this Fixed since Trent checked in the change weeks ago.  Leaving it for Trent to Close, though.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110644&group_id=5470

From noreply@sourceforge.net  Sat Sep 23 05:39:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 21:39:59 -0700
Subject: [Python-bugs-list] [Bug #115146] time.strptime returns bad day of month
Message-ID: <200009230439.VAA32214@bush.i.sourceforge.net>

Bug #115146, was updated on 2000-Sep-22 15:39
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Later
Bug Group: 3rd Party
Priority: 5
Summary: time.strptime returns bad day of month

Details: Python 1.5.2 (#1, May  9 2000, 15:05:56)  [GCC 2.95.3 19991030 (prerelease)] on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import time
>>> time.strptime("00:00","%M:%S")
(1900, 1, 0, 0, 0, 0, 6, 1, 0)

According to documentation (Beazley, "Python Essential Reference" p172), strptime "returns a time tuple of the same form as returned by localtime() or gmtime()." Documentation for gmtime() (ibid, pp170-1) states that the valid range for day is 1-31. I suspect someone's either used to the POSIX strftime, or there's an off-by-one error.


Q #1: Why 1900? Why not assume epoch unless told otherwise?

Q #2: If you're assuming things, why not assume day-of-month as 1, not 0? According

Follow-Ups:

Date: 2000-Sep-22 17:20
By: tim_one

Comment:
Marked 3rdParty and assigned to Fred.

The function time_strptime in Python's timemodule.c simply calls the platform strptime function, and converts the result to a tuple.  Virtually all bugs claimed in it so far have been traced to the platform's implementation of strptime.

In particular, since Python passes on the day value untouched, it's clearly a bug in your version of libc that you're getting a 0 value.  As to the 1900, that's how a struct tm is defined to work, but again it's almost certainly your platform strptime screwing up in not setting that field to 70.

Unfortunately, since strptime is not defined by the ANSI/ISO C std, results in endcases do vary across platforms.
-------------------------------------------------------

Date: 2000-Sep-22 21:39
By: fdrake

Comment:
Added some warnings to the strptime() documentation about the vagaries of the return value based on Tim's comments and the Linux manpage for strptime().  Checked in as Doc/lib/libtime.tex revision 1.34.

Closed this and added a request for a portable (& working!) strptime() implementation to PEP 42.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115146&group_id=5470

From noreply@sourceforge.net  Sat Sep 23 05:44:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 21:44:50 -0700
Subject: [Python-bugs-list] [Bug #114532] cgi + <TextArea>.. + xml-data
Message-ID: <200009230444.VAA32382@bush.i.sourceforge.net>

Bug #114532, was updated on 2000-Sep-15 10:21
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Works For Me
Bug Group: Irreproducible
Priority: 1
Summary: cgi + <TextArea>.. + xml-data

Details: Hi!

I'm working under linux (mandrake 7.1) using python for my cgi scripts. There I've a formular containing a "textarea". If entering xml- or html-data into this textarea and submitting it the cgi-script doesn't get that xml-data. With non-xml-data everything works fine.

BTW: It's the same with an "input"-field.

ciao
Volker


Follow-Ups:

Date: 2000-Sep-15 10:57
By: gvanrossum

Comment:
Volker,

We cannot help you with this bug unless you provide us with an example we can try ourselves.  We need at least:

1) a simple but complete script that shows the bug (try to pare it down from the script you are using to somehing that demonstrates just the problem)

2) the HTML of the form (ditto)

3) the text you are entering into the form

We also need:

- the Python version
- the browser name and version
- the server name and version

That said, I suspect that the problem is in your script, but without looking at it, I can't tell!

--Guido
-------------------------------------------------------

Date: 2000-Sep-22 21:44
By: tim_one

Comment:
Closed it, as a week has gone by without further info.  We'll open it again if richieee supplies something to act on.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114532&group_id=5470

From noreply@sourceforge.net  Sat Sep 23 05:55:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 21:55:25 -0700
Subject: [Python-bugs-list] [Bug #110667] select module: Bug in select.select() (PR#365)
Message-ID: <200009230455.VAA32696@bush.i.sourceforge.net>

Bug #110667, was updated on 2000-Jul-31 14:12
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: select module: Bug in select.select() (PR#365)

Details: Jitterbug-Id: 365
Submitted-By: r32813@email.sps.mot.com
Date: Wed, 21 Jun 2000 12:00:54 -0400 (EDT)
Version: 1.5.2
OS: AIX 4.3.1


 The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when 
 this command was run:-
 
       select.select(waitList, [], [], timeWait)
 
 This command worked fine in Python 1.5.1 build and also fine on Python
 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on
 2 AIX machines that we have. 

 






====================================================================
Audit trail:
Tue Jul 11 08:24:19 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] select module: Bug in select.select() (PR#365)
Date: Wed, 21 Jun 2000 17:08:33 -0500

>  The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when 
>  this command was run:-
>  
>        select.select(waitList, [], [], timeWait)
>  
>  This command worked fine in Python 1.5.1 build and also fine on Python
>  1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on
>  2 AIX machines that we have. 

Could you give us some more information?  You're indicating that it's
platform specific; we don't have an AIX box.  I'm guessing it's not
obvious that our code is wrong, but it may violate some guidelines
given by AIX manuals.  If we ever want to fix this, we'll need to
interact with you.  the first thing we need is a decent stack trace;
we'll take it from there.

If you could investigate this on your own and come up with a fix, that
would probably the best solution...

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "Wahmeng Wong" <r32813@email.sps.mot.com>
Subject: Re: [Python-bugs-list] select module: Bug in select.select() (PR#365)
Date: Thu, 22 Jun 2000 19:02:11 -0700

This is a multi-part message in MIME format.
--------------F9E74BCE6963FE221E423528
Content-Type: multipart/alternative;
 boundary="------------FF8E270086909CA1DBDDA697"


--------------FF8E270086909CA1DBDDA697
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Guido,

Below is the dbx information from the coredump. This only occurs when the
select.select() function is used within a thread. This same error occurs on
both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does not
occur on AIX 4.1.4.

$ dbx -I ./Modules ./python core
Type 'help' for help.
reading symbolic information ...
[using memory image in core]

Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c"
($t2)
  235           PyObject *tout = Py_None;

We have been able to reproduce the coredump by modifying the test_select.py
to perform the test within a thread. Attached is the modified file called
test_thread_select.py. Just place this file in the Lib/test directory to see
this problem.

Thanks for all your help.

Regards,
Wah Meng

Guido van Rossum wrote:

> >  The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when
> >  this command was run:-
> >
> >        select.select(waitList, [], [], timeWait)
> >
> >  This command worked fine in Python 1.5.1 build and also fine on Python
> >  1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on
> >  2 AIX machines that we have.
>
> Could you give us some more information?  You're indicating that it's
> platform specific; we don't have an AIX box.  I'm guessing it's not
> obvious that our code is wrong, but it may violate some guidelines
> given by AIX manuals.  If we ever want to fix this, we'll need to
> interact with you.  the first thing we need is a decent stack trace;
> we'll take it from there.
>
> If you could investigate this on your own and come up with a fix, that
> would probably the best solution...
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)

--------------FF8E270086909CA1DBDDA697
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Guido,
<p>Below is the dbx information from the coredump. This only occurs when
the select.select() function is used within a thread. This same error occurs
on both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does
not occur on AIX 4.1.4.
<p><tt>$ dbx -I ./Modules ./python core</tt>
<br><tt>Type 'help' for help.</tt>
<br><tt>reading symbolic information ...</tt>
<br><tt>[using memory image in core]</tt><tt></tt>
<p><tt>Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c"
($t2)</tt>
<br><tt>&nbsp; 235&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PyObject *tout = Py_None;</tt>
<p>We have been able to reproduce the coredump by modifying the test_select.py
to perform the test within a thread. Attached is the modified file called
test_thread_select.py. Just place this file in the Lib/test directory to
see this problem.
<p>Thanks for all your help.
<p>Regards,
<br>Wah Meng
<p>Guido van Rossum wrote:
<blockquote TYPE=CITE>>&nbsp; The python 1.5.2 built on AIX 4.3.1.0 platform
created a coredump when
<br>>&nbsp; this command was run:-
<br>>
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; select.select(waitList,
[], [], timeWait)
<br>>
<br>>&nbsp; This command worked fine in Python 1.5.1 build and also fine
on Python
<br>>&nbsp; 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0
build on
<br>>&nbsp; 2 AIX machines that we have.
<p>Could you give us some more information?&nbsp; You're indicating that
it's
<br>platform specific; we don't have an AIX box.&nbsp; I'm guessing it's
not
<br>obvious that our code is wrong, but it may violate some guidelines
<br>given by AIX manuals.&nbsp; If we ever want to fix this, we'll need
to
<br>interact with you.&nbsp; the first thing we need is a decent stack
trace;
<br>we'll take it from there.
<p>If you could investigate this on your own and come up with a fix, that
<br>would probably the best solution...
<p>--Guido van Rossum (home page: <a href="http://www.python.org/~guido/">http://www.python.org/~guido/</a>)</blockquote>
</html>

--------------FF8E270086909CA1DBDDA697--

--------------F9E74BCE6963FE221E423528
Content-Type: application/x-unknown-content-type-Python.File;
 name="test_thread_select.py"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="test_thread_select.py"

IyBUZXN0aW5nIHNlbGVjdCBtb2R1bGUNCmZyb20gdGVzdF9zdXBwb3J0IGltcG9ydCB2ZXJi
b3NlDQppbXBvcnQgc2VsZWN0LCB0aHJlYWQsIFF1ZXVlDQppbXBvcnQgb3MNCg0KIyB0ZXN0
IHNvbWUga25vd24gZXJyb3IgY29uZGl0aW9ucw0KdHJ5Og0KICAgIHJmZCwgd2ZkLCB4ZmQg
PSBzZWxlY3Quc2VsZWN0KDEsIDIsIDMpDQpleGNlcHQgVHlwZUVycm9yOg0KICAgIHBhc3MN
CmVsc2U6DQogICAgcHJpbnQgJ2V4cGVjdGVkIFR5cGVFcnJvciBleGNlcHRpb24gbm90IHJh
aXNlZCcNCg0KY2xhc3MgTm9wZToNCiAgICBwYXNzDQoNCmNsYXNzIEFsbW9zdDoNCiAgICBk
ZWYgZmlsZW5vKHNlbGYpOg0KICAgICAgICByZXR1cm4gJ2ZpbGVubycNCiAgICANCnRyeToN
CiAgICByZmQsIHdmZCwgeGZkID0gc2VsZWN0LnNlbGVjdChbTm9wZSgpXSwgW10sIFtdKQ0K
ZXhjZXB0IFR5cGVFcnJvcjoNCiAgICBwYXNzDQplbHNlOg0KICAgIHByaW50ICdleHBlY3Rl
ZCBUeXBlRXJyb3IgZXhjZXB0aW9uIG5vdCByYWlzZWQnDQoNCnRyeToNCiAgICByZmQsIHdm
ZCwgeGZkID0gc2VsZWN0LnNlbGVjdChbQWxtb3N0KCldLCBbXSwgW10pDQpleGNlcHQgVHlw
ZUVycm9yOg0KICAgIHBhc3MNCmVsc2U6DQogICAgcHJpbnQgJ2V4cGVjdGVkIFR5cGVFcnJv
ciBleGNlcHRpb24gbm90IHJhaXNlZCcNCg0KDQpkZWYgdGVzdChxKToNCiAgICAgICAgaW1w
b3J0IHN5cw0KICAgICAgICBpZiBzeXMucGxhdGZvcm1bOjNdIGluICgnd2luJywgJ21hYycs
ICdvczInKToNCiAgICAgICAgICAgICAgICBpZiB2ZXJib3NlOg0KICAgICAgICAgICAgICAg
ICAgICAgICAgcHJpbnQgIkNhbid0IHRlc3Qgc2VsZWN0IGVhc2lseSBvbiIsIHN5cy5wbGF0
Zm9ybQ0KICAgICAgICAgICAgICAgIHJldHVybg0KICAgICAgICBjbWQgPSAnZm9yIGkgaW4g
MCAxIDIgMyA0IDUgNiA3IDggOTsgZG8gZWNobyB0ZXN0aW5nLi4uOyBzbGVlcCAxOyBkb25l
Jw0KICAgICAgICBwID0gb3MucG9wZW4oY21kLCAncicpDQogICAgICAgIGZvciB0b3V0IGlu
ICgwLCAxLCAyLCA0LCA4LCAxNikgKyAoTm9uZSwpKjEwOg0KICAgICAgICAgICAgICAgIGlm
IHZlcmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICBwcmludCAndGltZW91dCA9Jywg
dG91dA0KICAgICAgICAgICAgICAgIHJmZCwgd2ZkLCB4ZmQgPSBzZWxlY3Quc2VsZWN0KFtw
XSwgW10sIFtdLCB0b3V0KQ0KIyMgICAgICAgICAgICAgIHByaW50IHJmZCwgd2ZkLCB4ZmQN
CiAgICAgICAgICAgICAgICBpZiAocmZkLCB3ZmQsIHhmZCkgPT0gKFtdLCBbXSwgW10pOg0K
ICAgICAgICAgICAgICAgICAgICAgICAgY29udGludWUNCiAgICAgICAgICAgICAgICBpZiAo
cmZkLCB3ZmQsIHhmZCkgPT0gKFtwXSwgW10sIFtdKToNCiAgICAgICAgICAgICAgICAgICAg
ICAgIGxpbmUgPSBwLnJlYWRsaW5lKCkNCiAgICAgICAgICAgICAgICAgICAgICAgIGlmIHZl
cmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByaW50IGBsaW5lYA0K
ICAgICAgICAgICAgICAgICAgICAgICAgaWYgbm90IGxpbmU6DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGlmIHZlcmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgcHJpbnQgJ0VPRicNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgYnJlYWsNCiAgICAgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlDQogICAgICAg
ICAgICAgICAgcHJpbnQgJ0hlaD8nDQogICAgICAgIHAuY2xvc2UoKQ0KICAgICAgICBxLnB1
dCgxKQ0KDQoNCnEgPSBRdWV1ZS5RdWV1ZSgxKQ0KdGhyZWFkLnN0YXJ0X25ld190aHJlYWQo
dGVzdCwocSwpKQ0KI3dhaXQgZm9yIHRocmVhZCB0byBjb21wbGV0ZSB0ZXN0IGZ1bmN0aW9u
DQpkb25lID0gcS5nZXQoKQ0KcHJpbnQgJ3RocmVhZCBjb21wbGV0ZWQgdGVzdCwgZXhpdGlu
ZycNCg0K
--------------F9E74BCE6963FE221E423528--



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] select module: Bug in select.select() (PR#365)
Date: Fri, 23 Jun 2000 11:01:40 -0500

> Below is the dbx information from the coredump. This only occurs when the
> select.select() function is used within a thread. This same error occurs on
> both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does not
> occur on AIX 4.1.4.
> 
> $ dbx -I ./Modules ./python core
> Type 'help' for help.
> reading symbolic information ...
> [using memory image in core]
> 
> Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c"
> ($t2)
>   235           PyObject *tout = Py_None;

Thanks.  Could you do this again and also type the "bt" (backtrace)
command?  That would perhaps be more helpful.  We can't reproduce this
here since we don't have access to AIX!  (Even if we ha,d it would be
low priority :-( ).

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Sep-22 21:55
By: tim_one

Comment:
Just putting the fellow's test_thread_select.py here as plain text (it's given only as base64 below):

# Testing select module
from test_support import verbose
import select, thread, Queue
import os

# test some known error conditions
try:
    rfd, wfd, xfd = select.select(1, 2, 3)
except TypeError:
    pass
else:
    print 'expected TypeError exception not raised'

class Nope:
    pass

class Almost:
    def fileno(self):
        return 'fileno'
    
try:
    rfd, wfd, xfd = select.select([Nope()], [], [])
except TypeError:
    pass
else:
    print 'expected TypeError exception not raised'

try:
    rfd, wfd, xfd = select.select([Almost()], [], [])
except TypeError:
    pass
else:
    print 'expected TypeError exception not raised'


def test(q):
        import sys
        if sys.platform[:3] in ('win', 'mac', 'os2'):
                if verbose:
                        print "Can't test select easily on", sys.platform
                return
        cmd = 'for i in 0 1 2 3 4 5 6 7 8 9; do echo testing...; sleep 1; done'
        p = os.popen(cmd, 'r')
        for tout in (0, 1, 2, 4, 8, 16) + (None,)*10:
                if verbose:
                        print 'timeout =', tout
                rfd, wfd, xfd = select.select([p], [], [], tout)
##              print rfd, wfd, xfd
                if (rfd, wfd, xfd) == ([], [], []):
                        continue
                if (rfd, wfd, xfd) == ([p], [], []):
                        line = p.readline()
                        if verbose:
                                print `line`
                        if not line:
                                if verbose:
                                        print 'EOF'
                                break
                        continue
                print 'Heh?'
        p.close()
        q.put(1)


q = Queue.Queue(1)
thread.start_new_thread(test,(q,))
#wait for thread to complete test function
done = q.get()
print 'thread completed test, exiting'

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110667&group_id=5470

From noreply@sourceforge.net  Sat Sep 23 06:00:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 22:00:53 -0700
Subject: [Python-bugs-list] [Bug #115146] time.strptime returns bad day of month
Message-ID: <200009230500.WAA00388@bush.i.sourceforge.net>

Bug #115146, was updated on 2000-Sep-22 15:39
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Later
Bug Group: 3rd Party
Priority: 5
Summary: time.strptime returns bad day of month

Details: Python 1.5.2 (#1, May  9 2000, 15:05:56)  [GCC 2.95.3 19991030 (prerelease)] on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import time
>>> time.strptime("00:00","%M:%S")
(1900, 1, 0, 0, 0, 0, 6, 1, 0)

According to documentation (Beazley, "Python Essential Reference" p172), strptime "returns a time tuple of the same form as returned by localtime() or gmtime()." Documentation for gmtime() (ibid, pp170-1) states that the valid range for day is 1-31. I suspect someone's either used to the POSIX strftime, or there's an off-by-one error.


Q #1: Why 1900? Why not assume epoch unless told otherwise?

Q #2: If you're assuming things, why not assume day-of-month as 1, not 0? According

Follow-Ups:

Date: 2000-Sep-22 17:20
By: tim_one

Comment:
Marked 3rdParty and assigned to Fred.

The function time_strptime in Python's timemodule.c simply calls the platform strptime function, and converts the result to a tuple.  Virtually all bugs claimed in it so far have been traced to the platform's implementation of strptime.

In particular, since Python passes on the day value untouched, it's clearly a bug in your version of libc that you're getting a 0 value.  As to the 1900, that's how a struct tm is defined to work, but again it's almost certainly your platform strptime screwing up in not setting that field to 70.

Unfortunately, since strptime is not defined by the ANSI/ISO C std, results in endcases do vary across platforms.
-------------------------------------------------------

Date: 2000-Sep-22 21:39
By: fdrake

Comment:
Added some warnings to the strptime() documentation about the vagaries of the return value based on Tim's comments and the Linux manpage for strptime().  Checked in as Doc/lib/libtime.tex revision 1.34.

Closed this and added a request for a portable (& working!) strptime() implementation to PEP 42.
-------------------------------------------------------

Date: 2000-Sep-22 22:00
By: tim_one

Comment:
Fred, note that there was already a request for a portable strptime in PEP 42.  Although, I'll agree, it wasn't a request for a *working* one <wink>.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115146&group_id=5470

From noreply@sourceforge.net  Sat Sep 23 06:22:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 22:22:29 -0700
Subject: [Python-bugs-list] [Bug #115147] os.execvp ignores first item in arguments
Message-ID: <200009230522.WAA01004@bush.i.sourceforge.net>

Bug #115147, was updated on 2000-Sep-22 15:41
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: os.execvp ignores first item in arguments

Details: purp@wug:~/wbhome/tests/lsf [15:38] <139> python
Python 1.5.2 (#1, May  9 2000, 15:05:56)  [GCC 2.95.3 19991030 (prerelease)] on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import os
>>> os.execvp('echo',['foo','bar'])
bar

That seems odd... off-by-one error?

Follow-Ups:

Date: 2000-Sep-22 16:59
By: tim_one

Comment:
Assigned to Fred as he's the only Unix guy around this weekend, but marked Not-a-Bug and Invalid.  Fred, how about you Close it after adding a line to the docs?  This is almost a FAQ.

The arglist passed to one of these guys becomes argv on the other end, and, as always, argv[0] is the file name associated with the file being executed.  See any manpage for execvp; this is inherited directly from how Unix(tm) defines these functions.
-------------------------------------------------------

Date: 2000-Sep-22 22:22
By: fdrake

Comment:
Added explanation of how the first program argument (arg0 or args[0]) passed to the various exec*() functions is used.  Checked in as Doc/lib/libos.tex revision 1.47.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115147&group_id=5470

From noreply@sourceforge.net  Sat Sep 23 06:33:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Sep 2000 22:33:54 -0700
Subject: [Python-bugs-list] [Bug #115143] Python sometimes complains about continue in an except
Message-ID: <200009230533.WAA01295@bush.i.sourceforge.net>

Bug #115143, was updated on 2000-Sep-22 14:57
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Summary: Python sometimes complains about continue in an except

Details: If a continue statement occurs in the second try/except
statement nested within another try statement, it complains
about the second continue.  For example, this code generates a SyntaxError:

    for i in range(10):
        try:
            try:
                pass
            except:
                continue
            try:
                pass
            except:
                continue
        except:
            pass

while this is fine:

    for i in range(10):
        try:
            pass
        except:
            continue
        try:
            pass
        except:
            continue

This problem exists in both 1.5.2 and 2.0b1.

A workaround is to raise "continue" from the inner 
try/except statements and catch it in the outer try/except:

    for i in range(10):
        try:
            try:
                pass
            except:
                raise "continue"
            try:
                pass
            except:
                raise "continue"
        except "continue":
            continue
        except:
            pass



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115143&group_id=5470

From noreply@sourceforge.net  Sat Sep 23 09:52:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 23 Sep 2000 01:52:31 -0700
Subject: [Python-bugs-list] [Bug #115035] SunOS 4.1.4 with GCC 2.95.2 can't compile complete
Message-ID: <200009230852.BAA07356@bush.i.sourceforge.net>

Bug #115035, was updated on 2000-Sep-21 18:24
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: SunOS 4.1.4 with GCC 2.95.2 can't compile complete

Details: 1) Module/posixmodule.c
  In Module/posixmodule.c, it used rename, pclose, fclose but SunOS 4.1.4's unistd.h does not have these definitions. So add them.
2) Modules/mmapmodule.c
  In Modules/mmapmodule.c, MS_SYNC used but SunOS 4.1.4's mman.h does not have this difinition. So add it.


Follow-Ups:

Date: 2000-Sep-21 18:56
By: gvanrossum

Comment:
I'm not sure what the proper solution is here. Can you provide a patch?
Which C preprocessor symbol do I check for to know that I'm on SunOS 4.1.4?

(1) We can't add decls for these funcs unconditionally because it would conflict with decls in unistd.h or elsewhere on other platforms.

(2) What is the proper replacement for MS_SYNC on SunOS 4.1.4?
-------------------------------------------------------

Date: 2000-Sep-23 01:52
By: loewis

Comment:
Specifying MS_SYNC is not necessary on SunOS 4, the msync manpage says

MS_ASYNC returns msync() immediately once all  I/O  operations  are  scheduled;  normally,  msync() will not return until all  I/O  operations  are  complete.

So it is safe to define it as 0.

I believe SunOS 4 can be recognized by testing that "sun" is defined and "__SVR4" is not.

According to the man pages, the missing prototypes are

       int rename(path1, path2)
       char *path1, *path2;
       fclose(stream)
       FILE *stream;
       pclose(stream)
       FILE *stream;

Indeed, no header file on this system has an fclose prototype...
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115035&group_id=5470

From noreply@sourceforge.net  Sun Sep 24 13:46:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Sep 2000 05:46:35 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200009241246.FAA24453@delerium.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 13:45
By: fdrake

Comment:
We need to know the output of "uname -s" and "uname -r" for this system.  (If "uname -r" reports an error, please try "uname -v".)

Are you willing to test a modified configure script on this platform?

What additional library is required for the mmap module?
-------------------------------------------------------

Date: 2000-Sep-12 21:59
By: fdrake

Comment:
Received the following response from Daniel Dittmar <ddittmar@users.sourceforge.net>:

> We need to know the output of "uname -s" and "uname -r" 
> for this system.  (If "uname -r" reports an error, please 
> try "uname -v".)

uname -s
ReliantUNIX-N

uname -r
5.45


> Are you willing to test a modified configure script on
> this platform?

sure.

> What additional library is required for the mmap module?

The man page states -lucb. This didn't work on my machine 
as the BSD compatibility layer is not active. I tell you 
more as soon as I know how to activate it.

***********

Another problem: to detect pthreads, the compiler must be 
called with -Kpthread. Otherwise, pthread.h goes into a 
branch where it tries to include a non existent header, 
fails, and configure reports 'no pthreads'.

Daniel

-------------------------------------------------------

Date: 2000-Sep-15 11:57
By: fdrake

Comment:
For the mmap issue, I've added a comment to Modules/Setup.in to let installers know that -lucb may be needed.  In revision 1.110.
-------------------------------------------------------

Date: 2000-Sep-15 13:37
By: fdrake

Comment:
I'm sending a modified version of  the configure script to Daniel Dittmar to test for the first two points in this bug report.
-------------------------------------------------------

Date: 2000-Sep-21 08:17
By: fdrake

Comment:
Sent query to Daniel Dittmar asking if he's had a chance to test the revised configure script I sent.
-------------------------------------------------------

Date: 2000-Sep-21 08:46
By: fdrake

Comment:
Received message from Daniel indicating he should get a chace to test the changes this weekend, so it should be available for 2.0b2.
-------------------------------------------------------

Date: 2000-Sep-24 05:46
By: ddittmar

Comment:
- configure --without-threads works with the configure patch Revision 1.158

- mmapmodule would work if it includes the lines

#include <unistd.h>

static int
getpagesize (void)
{
    return sysconf (_SC_PAGESIZE);
}

This would be the preferred way as using the BSD compatibility with -lucb is discouraged.

It requires chages to configure (has_pagesize, has_sysconf_sc_pagesize)

- configure --with-threads doesn't build yet, keeping contact with fdrake
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470


From noreply@sourceforge.net  Sun Sep 24 15:01:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Sep 2000 07:01:05 -0700
Subject: [Python-bugs-list] [Bug #110823] Tkinter missing button state symbols (PR#132)
Message-ID: <200009241401.HAA26749@delerium.i.sourceforge.net>

Bug #110823, was updated on 2000-Aug-01 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Tkinter missing button state symbols (PR#132)

Details: Jitterbug-Id: 132
Submitted-By: aa8vb@yahoo.com
Date: Thu, 18 Nov 1999 08:16:55 -0500 (EST)
Version: 1.5.2
OS: IRIX 6.5


I have:

  picture.bind( "<ButtonPress-1>"  , click_cb )
  picture.bind( "<ButtonRelease-1>", click_cb )

In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease.

Where are the Tkinter constants for these?  Or how should one distinguish
between a press and release in a callback?

(I want to avoid having a separate callback for each type of event.)



====================================================================
Audit trail:
Thu Nov 18 10:42:46 1999	guido	changed notes
Thu Nov 18 10:42:46 1999	guido	moved from incoming to notabug
Thu Nov 18 14:07:59 1999	guido	changed notes
Thu Nov 18 14:07:59 1999	guido	moved from notabug to request

Follow-Ups:

Date: 2000-Aug-01 14:10
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132)
Date: Thu, 18 Nov 1999 10:41:31 -0500

> Full_Name: Randall Hopper
> Version: 1.5.2
> OS: IRIX 6.5
> Submission from: ethyl-f.rtpfddi.epa.gov (134.67.65.11)
> 
> 
> I have:
> 
>   picture.bind( "<ButtonPress-1>"  , click_cb )
>   picture.bind( "<ButtonRelease-1>", click_cb )
> 
> In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease.
> 
> Where are the Tkinter constants for these?  Or how should one distinguish
> between a press and release in a callback?
> 
> (I want to avoid having a separate callback for each type of event.)

This is not a question for the bugs list.

Write to help@python.org or use the newsgroup for help.  I don't know
offhand what the answer is to your question; I suspect that the answer
is in the Tcl/Tk man page for the bind command though.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:10
By: none

Comment:
From: Randall Hopper <Hopper.Randall@epa.gov>
Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132)
Date: Thu, 18 Nov 1999 14:04:13 -0500

Guido van Rossum:
 |> Full_Name: Randall Hopper
 |> Version: 1.5.2
 |> OS: IRIX 6.5
 |> Submission from: ethyl-f.rtpfddi.epa.gov (134.67.65.11)
 |> 
 |> 
 |> I have:
 |> 
 |>   picture.bind( "<ButtonPress-1>"  , click_cb )
 |>   picture.bind( "<ButtonRelease-1>", click_cb )
 |> 
 |> In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease.
 |> 
 |> Where are the Tkinter constants for these?  Or how should one distinguish
 |> between a press and release in a callback?
 |> 
 |> (I want to avoid having a separate callback for each type of event.)
 |
 |This is not a question for the bugs list.
 |
 |Write to help@python.org or use the newsgroup for help.  I don't know
 |offhand what the answer is to your question; I suspect that the answer
 |is in the Tcl/Tk man page for the bind command though.

My fault.  I should have rephrased the question into a statement.  Tkinter
does not provide symbol defines for event.state values (%s keyword in Tcl).
Tcl doesn't either, but it would be useful if Tkinter did.

This is a small enhancement request rather than a hard bug, but I thought
the submission form was for probably applicable for both.

Thanks,

Randall

-------------------------------------------------------

Date: 2000-Aug-01 14:10
By: none

Comment:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132)
Date: Thu, 18 Nov 1999 14:05:57 -0500

Yes, requests are okay.  Sorry for the confusion.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-------------------------------------------------------

Date: 2000-Aug-01 14:10
By: none

Comment:
Should add a symbol as he suggests.
-------------------------------------------------------

Date: 2000-Aug-09 02:21
By: effbot

Comment:
IIRC, these constants are platform (X library) dependent (they have to be exported from _tkinter.c, not Tkconstants.py).

I'll investigate.  Feel free to assign the bug to me if you like.

</F>
-------------------------------------------------------

Date: 2000-Aug-10 11:43
By: gvanrossum

Comment:
/F, go for it!
-------------------------------------------------------

Date: 2000-Sep-24 07:01
By: none

Comment:
LOL.I DON'T UNDERSTAND THIS SHIT BUT SOUNDS REALLY INTERESTING.WHERE CAN I LEARN HOW TO DO THIS??? SOME-ONE HELP ME!!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110823&group_id=5470


From noreply@sourceforge.net  Sun Sep 24 15:38:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Sep 2000 07:38:17 -0700
Subject: [Python-bugs-list] [Bug #115221] test_poll hangs on Debian Linux 2.2
Message-ID: <200009241438.HAA28056@delerium.i.sourceforge.net>

Bug #115221, was updated on 2000-Sep-24 07:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: test_poll hangs on Debian Linux 2.2

Details: When run from the command-line test_poll.py prints
"This is a test." 12 times and then hangs, without ever printing "Poll test 1 complete".

All other tests seem to work just fine.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115221&group_id=5470


From noreply@sourceforge.net  Sun Sep 24 15:40:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Sep 2000 07:40:12 -0700
Subject: [Python-bugs-list] [Bug #114660] sre hangs with "collapse whitespace" RE
Message-ID: <200009241440.HAA28105@delerium.i.sourceforge.net>

Bug #114660, was updated on 2000-Sep-17 17:38
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: sre hangs with "collapse whitespace" RE

Details: In Python 1.5.2, 1.6, and 2.0b1 using "pre", the following regex substitution works fine:

>>> s = "hello      there     how are you?"
>>> re.sub (r'(\S)\s+(\S)', r'\1 \2', s)
'hello there how are you?'

But in 2.0b1 using the standard "re" module, Python goes into an apparently infinite loop.  (CPU is pegged, memory doesn't increase at all.)

Follow-Ups:

Date: 2000-Sep-17 18:18
By: tim_one

Comment:
It's in an infinite loop trying to parse the \1 in the replacement pattern (parse_sre.py, function parse_template).  It recognizes that "1" is a valid group name, but apparently doesn't recognize that "1 " (i.e., the digit one followed by a blank) is not a valid group name), in turn perhaps because int("1 ") returns 1.

I can fix it by adding the clause

s.next not in DIGITS or

after the existing

if (not s.next or

on line 637 and then this gets the result you expect, but I'll defer to /F on whether that's the right way to fix this.

I hope you (Greg) aren't actually using this regexp to normalize whitespace!  split followed by join is the usual way to do that, and this regexp-based way looks wrong (e.g., if somewhere in the middle there's a single letter followed by mounds of whitespace on each side:  the space following the letter won't get collapsed).
-------------------------------------------------------

Date: 2000-Sep-17 19:04
By: gward

Comment:
Not related to the bug, but since Tim brought it up: I once used that regex to normalize whitespace; I must have written that line of code when I was still a recovering Perl programmer.  Unfortunately, that particular line of code lived on in distutils/text_file.py until this past weekend, so someone stumbled across it using Distutils 0.9.2 under Python 2.0b1.  The regex is gone in the current Distutils CVS, so this won't be an issue once 0.9.3 is out.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114660&group_id=5470


From noreply@sourceforge.net  Sun Sep 24 15:42:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Sep 2000 07:42:18 -0700
Subject: [Python-bugs-list] [Bug #114660] sre hangs with "collapse whitespace" RE
Message-ID: <200009241442.HAA28225@delerium.i.sourceforge.net>

Bug #114660, was updated on 2000-Sep-17 17:38
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: sre hangs with "collapse whitespace" RE

Details: In Python 1.5.2, 1.6, and 2.0b1 using "pre", the following regex substitution works fine:

>>> s = "hello      there     how are you?"
>>> re.sub (r'(\S)\s+(\S)', r'\1 \2', s)
'hello there how are you?'

But in 2.0b1 using the standard "re" module, Python goes into an apparently infinite loop.  (CPU is pegged, memory doesn't increase at all.)

Follow-Ups:

Date: 2000-Sep-17 18:18
By: tim_one

Comment:
It's in an infinite loop trying to parse the \1 in the replacement pattern (parse_sre.py, function parse_template).  It recognizes that "1" is a valid group name, but apparently doesn't recognize that "1 " (i.e., the digit one followed by a blank) is not a valid group name), in turn perhaps because int("1 ") returns 1.

I can fix it by adding the clause

s.next not in DIGITS or

after the existing

if (not s.next or

on line 637 and then this gets the result you expect, but I'll defer to /F on whether that's the right way to fix this.

I hope you (Greg) aren't actually using this regexp to normalize whitespace!  split followed by join is the usual way to do that, and this regexp-based way looks wrong (e.g., if somewhere in the middle there's a single letter followed by mounds of whitespace on each side:  the space following the letter won't get collapsed).
-------------------------------------------------------

Date: 2000-Sep-17 19:04
By: gward

Comment:
Not related to the bug, but since Tim brought it up: I once used that regex to normalize whitespace; I must have written that line of code when I was still a recovering Perl programmer.  Unfortunately, that particular line of code lived on in distutils/text_file.py until this past weekend, so someone stumbled across it using Distutils 0.9.2 under Python 2.0b1.  The regex is gone in the current Distutils CVS, so this won't be an issue once 0.9.3 is out.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114660&group_id=5470


From noreply@sourceforge.net  Sun Sep 24 17:54:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Sep 2000 09:54:55 -0700
Subject: [Python-bugs-list] [Bug #115221] test_poll hangs on Debian Linux 2.2
Message-ID: <200009241654.JAA08784@bush.i.sourceforge.net>

Bug #115221, was updated on 2000-Sep-24 07:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_poll hangs on Debian Linux 2.2

Details: When run from the command-line test_poll.py prints
"This is a test." 12 times and then hangs, without ever printing "Poll test 1 complete".

All other tests seem to work just fine.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115221&group_id=5470


From noreply@sourceforge.net  Sun Sep 24 19:51:04 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Sep 2000 11:51:04 -0700
Subject: [Python-bugs-list] [Bug #114256] Python 2.0b1, Win2K - urllib failure
Message-ID: <200009241851.LAA04542@delerium.i.sourceforge.net>

Bug #114256, was updated on 2000-Sep-12 09:16
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0b1, Win2K - urllib failure

Details: This might be related to bug #110692, since it seems to be related to proxies.

A program I have that works under older versions of Python now fails with this traceback:


Traceback (most recent call last):
  File "IGNRatings.py", line 289, in ?
    main(sys.argv[1:])
  File "IGNRatings.py", line 133, in main
    inStream = urllib.urlopen(url)
  File "E:\Python20\lib\urllib.py", line 61, in urlopen
    return _urlopener.open(url)
  File "E:\Python20\lib\urllib.py", line 163, in open
    return getattr(self, name)(url)
  File "E:\Python20\lib\urllib.py", line 259, in open_http
    h = httplib.HTTP(host)
  File "E:\Python20\lib\httplib.py", line 624, in __init__
    self._conn = self._connection_class(host, port)
  File "E:\Python20\lib\httplib.py", line 324, in __init__
    self._set_hostport(host, port)
  File "E:\Python20\lib\httplib.py", line 330, in _set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int():


My URL is nothing special:

    'http://dreamcast.ign.com/review_lists/a.html'


I have tracked the problem down a bit:

In urllib.py, line 147, the statement

    proxy = self.proxies[type]

assigns the string

    'http://http://proxy:8080'

to "proxy". My guess is that's not right. Anyway, the following line assigns

    type = 'http'
    proxy = '//http://proxy:8080'

and the next line assigns

    host = 'http:'
    selector = '//proxy:8080'

'http:' as a host name then goes on to cause trouble when an HTTPConnection is constructed.

Hope this info helps you track it down.

Bob Alexander
bobalex@home.com

Follow-Ups:

Date: 2000-Sep-24 11:51
By: effbot

Comment:
Fixed in 2.0b2.

The earlier code assumed "protocol=host;protocol=host;..." or "host", but Windows may also use "protocol=host" (just one entry), as well as "protocol://host".  This code needs some more work, so I'll leave the bug open for now.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114256&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 00:54:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Sep 2000 16:54:00 -0700
Subject: [Python-bugs-list] [Bug #115035] SunOS 4.1.4 with GCC 2.95.2 can't compile complete
Message-ID: <200009242354.QAA23876@bush.i.sourceforge.net>

Bug #115035, was updated on 2000-Sep-21 18:24
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: SunOS 4.1.4 with GCC 2.95.2 can't compile complete

Details: 1) Module/posixmodule.c
  In Module/posixmodule.c, it used rename, pclose, fclose but SunOS 4.1.4's unistd.h does not have these definitions. So add them.
2) Modules/mmapmodule.c
  In Modules/mmapmodule.c, MS_SYNC used but SunOS 4.1.4's mman.h does not have this difinition. So add it.


Follow-Ups:

Date: 2000-Sep-21 18:56
By: gvanrossum

Comment:
I'm not sure what the proper solution is here. Can you provide a patch?
Which C preprocessor symbol do I check for to know that I'm on SunOS 4.1.4?

(1) We can't add decls for these funcs unconditionally because it would conflict with decls in unistd.h or elsewhere on other platforms.

(2) What is the proper replacement for MS_SYNC on SunOS 4.1.4?
-------------------------------------------------------

Date: 2000-Sep-23 01:52
By: loewis

Comment:
Specifying MS_SYNC is not necessary on SunOS 4, the msync manpage says

MS_ASYNC returns msync() immediately once all  I/O  operations  are  scheduled;  normally,  msync() will not return until all  I/O  operations  are  complete.

So it is safe to define it as 0.

I believe SunOS 4 can be recognized by testing that "sun" is defined and "__SVR4" is not.

According to the man pages, the missing prototypes are

       int rename(path1, path2)
       char *path1, *path2;
       fclose(stream)
       FILE *stream;
       pclose(stream)
       FILE *stream;

Indeed, no header file on this system has an fclose prototype...
-------------------------------------------------------

Date: 2000-Sep-24 16:54
By: moroo

Comment:
Pathes are last half of this message.

And more trouble
1) When making -L does not have any arguments, so making is stopped.
2) Some test does not pass.
  test log added next of pacthes.

Patches:
--- Patch Begin ---
*** Modules/mmapmodule.c.org    Fri Sep 22 17:01:14 2000
--- Modules/mmapmodule.c        Fri Sep 22 16:52:55 2000
***************
*** 24,29 ****
--- 24,35 ----
  #define UNIX
  #endif

+ #ifdef sun
+ #ifndef MS_SYNC
+ #define MS_SYNC 0x0
+ #endif
+ #endif
+
  #ifdef MS_WIN32
  #include <windows.h>
  #endif
*** Modules/posixmodule.c.org   Fri Sep 22 17:01:25 2000
--- Modules/posixmodule.c       Fri Sep 22 16:51:46 2000
***************
*** 106,111 ****
--- 106,118 ----

  #ifdef HAVE_UNISTD_H
  #include <unistd.h>
+ #ifdef sun
+ #ifdef _POSIX_VERSION
+ extern int rename(const char *, const char *);
+ extern int pclose(FILE *);
+ extern int fclose(FILE *);
+ #endif
+ #endif
  #endif

  #ifdef NeXT

--- Patch End ---

--- Test Log ---
#Delete successed lines.

test test_cgi crashed -- exceptions.AttributeError: uname
test test_format crashed -- exceptions.SystemError: error return without excepti
on set
test test_largefile skipped --  platform does not have largefile support
test test_poll skipped --  select.poll not defined -- skipping test_poll
test test_popen2 crashed -- exceptions.AttributeError: waitpid
test test_pwd crashed -- exceptions.AttributeError: getpwall
test test_signal crashed -- exceptions.AttributeError: alarm
test test_socket crashed -- exceptions.AttributeError: getpeername
test test_strftime skipped --  cannot import name mktime
test test_time crashed -- exceptions.AttributeError: clock
test test_unicode crashed -- exceptions.SystemError: error return without except
ion set
test test_urllib crashed -- exceptions.AttributeError: quote
9 tests failed: test_cgi test_format test_popen2 test_pwd test_signal test_socke
t test_time test_unicode test_urllib
31 tests skipped: test_al test_audioop test_bsddb test_cd test_cl test_crypt tes
t_dbm test_dl test_fork1 test_gc test_gdbm test_gl test_gzip test_imageop test_i
mgfile test_largefile test_linuxaudiodev test_minidom test_nis test_openpty test
_poll test_pty test_pyexpat test_rgbimg test_strftime test_sunaudiodev test_thre
ad test_timing test_winreg test_winsound test_zlib
test test_cgi crashed -- exceptions.AttributeError: uname
test test_format crashed -- exceptions.SystemError: error return without excepti
on set
test test_largefile skipped --  platform does not have largefile support
test test_longexp crashed -- exceptions.MemoryError:
test test_popen2 crashed -- exceptions.OSError: [Errno 12] Not enough memory
test test_pwd crashed -- exceptions.AttributeError: getpwall
/bin/sh: 12372 Memory fault - core dumped
--- End ---


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115035&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 02:51:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Sep 2000 18:51:15 -0700
Subject: [Python-bugs-list] [Bug #115247] 2.0b1 Gives error on Install.
Message-ID: <200009250151.SAA27743@bush.i.sourceforge.net>

Bug #115247, was updated on 2000-Sep-24 18:51
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Not a Bug
Priority: 5
Summary: 2.0b1 Gives error on Install.

Details:    I've downloaded Python 2.0b1 for Windows (.exe version) twice, and each time I get a "Currupt installation detected." error immediately after executing BeOpen-Python-2.0b1.exe

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115247&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 03:20:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Sep 2000 19:20:49 -0700
Subject: [Python-bugs-list] [Bug #115247] 2.0b1 Gives error on Install.
Message-ID: <200009250220.TAA20227@delerium.i.sourceforge.net>

Bug #115247, was updated on 2000-Sep-24 18:51
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 9
Summary: 2.0b1 Gives error on Install.

Details:    I've downloaded Python 2.0b1 for Windows (.exe version) twice, and each time I get a "Currupt installation detected." error immediately after executing BeOpen-Python-2.0b1.exe

Follow-Ups:

Date: 2000-Sep-24 19:20
By: tim_one

Comment:
We discovered today that *all* the downloads on the BeOpen site somehow or other got corrupted.

Until this is repaired, you get a correct Windows installer from
ftp://python.beopen.com/pub/tmp/BeOpen-Python-2.0b1.exe

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115247&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 06:31:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Sep 2000 22:31:45 -0700
Subject: [Python-bugs-list] [Bug #115247] 2.0b1 Gives error on Install.
Message-ID: <200009250531.WAA02259@bush.i.sourceforge.net>

Bug #115247, was updated on 2000-Sep-24 18:51
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Fixed
Bug Group: 3rd Party
Priority: 9
Summary: 2.0b1 Gives error on Install.

Details:    I've downloaded Python 2.0b1 for Windows (.exe version) twice, and each time I get a "Currupt installation detected." error immediately after executing BeOpen-Python-2.0b1.exe

Follow-Ups:

Date: 2000-Sep-24 19:20
By: tim_one

Comment:
We discovered today that *all* the downloads on the BeOpen site somehow or other got corrupted.

Until this is repaired, you get a correct Windows installer from
ftp://python.beopen.com/pub/tmp/BeOpen-Python-2.0b1.exe

-------------------------------------------------------

Date: 2000-Sep-24 22:31
By: tim_one

Comment:
Fixed and Closed.

Unfortunately, the BeOpen webmasters haven't figured this one out yet.  The files on the site are fine, it's Apache and/or Zope screwing them up on download.  This is nasty corruption, as it doesn't change the lengths of the files, it just replaces gobs of bytes throughout the interior with seemingly random trash bytes (but consistently!  it's the same trash in the same places each time).

Until it is figured out, they changed the download page to use a different method of serving files.  This appears to work.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115247&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 09:02:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 01:02:48 -0700
Subject: [Python-bugs-list] [Bug #115261] ambiguous else
Message-ID: <200009250802.BAA31904@delerium.i.sourceforge.net>

Bug #115261, was updated on 2000-Sep-25 01:02
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: ambiguous else

Details: A statement like:

      if (newref) Py_DECREF(obj);

will generate an ambiguous else message.  (The line
is from SWIG1.3a4.)

It's good practice to always use braces, because you
never know what context your code will get copied into
(this is true even if it's not a macro; think cut & paste).

I'd change it (and other similar) to:

#define Py_DECREF(op) { \
        if (--_Py_RefTotal, --(op)->ob_refcnt != 0) { \
        } else { \
                _Py_Dealloc((PyObject *)(op)); \
        }}


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115261&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 09:24:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 01:24:21 -0700
Subject: [Python-bugs-list] [Bug #114324] Minor build problems on HPUX for 2.0b1
Message-ID: <200009250824.BAA32657@delerium.i.sourceforge.net>

Bug #114324, was updated on 2000-Sep-13 02:20
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: Minor build problems on HPUX for 2.0b1

Details: Build problems on HPUX10.20/HPUX11.00:

  - There seems to be no prototype for "fdatasync" in any include file
    although it has a man page and it is present in libc (so HAVE_FDATASYNC
    is set). As a result posixmodule.c fails to compile.
   
    Adding a prototype "extern int fdatasync(int);" to posixmodule.c solves 
    this problem, but it may not be portable.
    
  - Modules/mmapmodule.c is missing a "#include <limits.h>"
  
Build problems on HPUX10.20 only:

  - When configured with threading support (default), the cast to (long)
    on line 181 of Python/thread_pthread.h fails. The reason is that
    pthread_t is a struct type. The "configure" test that tries to find out
    the size of pthread_t failed because it tries to cast '0' to a pthread_t,
    so SIZEOF_PTHREAD_T remains undefined.
    
    I suggest changing this line in configure.in:
    
    AC_TRY_COMPILE([#include <pthread.h>], [pthread_t x; x = (pthread_t)0;], have_pthread_t=yes)
    
    to
    
    AC_TRY_COMPILE([#include <pthread.h>], [pthread_t x; x = *(pthread_t*)0;], have_pthread_t=yes)
    
My compiler settings:

   setenv CC 'c89 +DA1.1 +Onolimit -D_HPUX_SOURCE'

Regards,

Eddy

Follow-Ups:

Date: 2000-Sep-16 10:01
By: gvanrossum

Comment:
Randomly assigned to Jeremy for further investigation.
-------------------------------------------------------

Date: 2000-Sep-22 03:04
By: gvanrossum

Comment:
Assigned back to me because I'm planning to tackle HP build problems.
-------------------------------------------------------

Date: 2000-Sep-22 09:04
By: gvanrossum

Comment:
I've checked in a fix for fdatasync. Can you test that?
I'm also working on the thread config, that'll take longer.
-------------------------------------------------------

Date: 2000-Sep-22 09:41
By: edg

Comment:
The fix for fdatasync works.
However, I think it's better to use __hpux instead of __hppa to detect HP-UX.
(__hppa identifies the processor architecture).

FYI: The native cc/c89 compiler defines both __hppa and __hpux.
Gcc additionally defines hppa and hpux.

-------------------------------------------------------

Date: 2000-Sep-22 12:44
By: gvanrossum

Comment:
I *think* I've squashed this bug with my latest checkin to configure.in and configure. Thanks for the suggestion! Please test so I can close this bug report.
-------------------------------------------------------

Date: 2000-Sep-22 13:18
By: edg

Comment:
I can't test it before Monday, but it looks like you've
made a typo:

Configure.in, line 2522:
  ... *(pthread_t)*0; 

should be:

  ... *(pthread_t*)0; 

BTW: Modules/mmapmodule.c still misses 

#ifdef HAVE_LIMITS_H
#include <limits.h>
#endif

Without this, INT_MAX is undefined on HP-UX.

I'll test it first thing Monday morning.

-------------------------------------------------------

Date: 2000-Sep-25 01:24
By: edg

Comment:
The thread fix is ok.
Except for mmapmodule.c everything compiles straight out of the box now.



-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114324&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 10:04:49 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 02:04:49 -0700
Subject: [Python-bugs-list] [Bug #115076] threads of __del__
Message-ID: <200009250904.CAA09685@bush.i.sourceforge.net>

Bug #115076, was updated on 2000-Sep-22 02:15
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Summary: threads of __del__

Details: I suspect (but have not proved) that the support for destroying deeply recursive structures can allow for an instances __del__ method to get called in a thread other than the one in which it lost its last reference.

This can happen if it switches to a different thread during deletion of a deeply recursive structure (with _PyTrash_delete_later not empty). 

Should Python guarantee that this does not happen? (I say yes - it is important for COM clients)

Follow-Ups:

Date: 2000-Sep-22 02:52
By: gvanrossum

Comment:
Agreed that this would be a problem if it could cause an inconsistent state of the trashcan (at the end of object.c) structure. However, since the "trash" code is all executed with the global interpreter lock held, I don't see that there can be a problem. Here's why:

The code in _PyTrash_deposit_object() doesn't make any calls that could invoke __del__, so it's safe. The code in _PyTrash_destroy_chain() makes exactly one call to Py_DECREF(), but it takes care that its global data structures are consistent at this point. For a second I thought that _PyTrash_delete_later would have to be declared volatile, but on second thought I don't: the Py_DECREF() macro expands to a possible (indirect) function call, signaling the compiler that the global _PyTrash_delete_later may be changed in arbitrary ways.

Assigned to Tim Peters to verify my reasoning, because of his superior mind in reasoning about threads and race conditions.
-------------------------------------------------------

Date: 2000-Sep-22 03:05
By: htrd

Comment:
I agree there is no self-consistency problem with the trashcan, however......

The code in _PyTrash_destroy_chain can call an objects __del__ method, which can release the interpreter lock.

A second thread may then reenter _PyTrash_destroy_chain and continue to clean up the first thread's garbage. (the first thread is safely blocked inside the Py_DECREF)

Yes the garbage gets cleaned up, however it happens in the wrong thread.

I suggest that _PyTrash_delete_later should be part of pyThreadState



-------------------------------------------------------

Date: 2000-Sep-22 03:08
By: gvanrossum

Comment:
And why, exactly, would it be a problem that the trash is deleted in the 'wrong" thread? It's just trash. Any thread can delete it.

Or am I missing something?
-------------------------------------------------------

Date: 2000-Sep-22 03:27
By: htrd

Comment:
There are two cases that I have in mind:

First is that of a COM client.

It depends on the COM threading model in use, but this problem applies in the most common threading model which is also the default threading model using Mark Hammond's pythoncom.

It is only permitted to access a reference to a COM object from the thread in which it is created. This restiction applies to the Release() method that is used by pythoncom to release its reference to the COM server.


Secondly, it is common to use a dictionary keyed by thread.get_ident() to provide thread-local storage. This is used extensively in Zope. Any application that uses this type of thread-local storage in a __del__ is likely to be broken.



-------------------------------------------------------

Date: 2000-Sep-22 06:30
By: gvanrossum

Comment:
It sounds that it will be hard to enforce that __del__ is called in the constructing thread even without the complication of the trashcan code.

Explicitly referencing thread-specific data in a __del__ seems silly -- if the object is tied so closely to the thread, why not add a pointer to the thread to the object.

Nevertheless, especially the COM thing sounds like it would be a good thing to prevent this if it is possible, and your solution (make the trashcan state part of the thread state) sounds reasonable -- except that it means that every deallocation of a tuple, list, dict, frame or traceback needs yet another call to PyThreadState_Get(). And, most disturbing of all, we found before releasing 2.0b1 that there are situations where dictionaries (and possibly other objects) are used when there is no current thread state!!!

Replacing one theoretical problem with another not-so-theoretical one doesn't seem right. Perhaps we could invent a flag that prevents thread-switches while the trashcan dealloc code is running? This could be a simple global boolean that, when set, stops the ceval main loop (and the BEGIN/END ALLOW THREADS macros and related functions!) from ever yielding the interpreter loop. It would almost never be triggered in practice, but guarantee safety in worst cases -- if not efficiency (other threads would be completely blocked until the trashcan code is done).

Back to Tim...
-------------------------------------------------------

Date: 2000-Sep-22 07:52
By: htrd

Comment:
There is a patch to move the trashcan into the thread state. see http://sourceforge.net/patch/?func=detailpatch&patch_id=101606&group_id=5470

This uses PyThreadState_GET() once to avoid the extra function call in the normal path, and only uses the trashcan if the thread state is non NULL. (assuming we are never deleting deeply recursive objects with no thread state)

On performance, this gives me a 2% increase in pystones....

-------------------------------------------------------

Date: 2000-Sep-22 11:52
By: tim_one

Comment:
Assigned to MarkH, as I want his opinion on this.

I dislike it on principle:  it elevates an accident of refcount semantics into a design goal, and complicates the code to achieve that.

The Microsoft .NET implementation of Python doesn't do refcounting, so not even the pre-trashcan refcount semantics can be relied on there, and I don't want to add to users' difficulties in moving among Python implementations (despite that it may be in my immediate financial interest to lock people into CPython, I'll leave "embrace & extend" to MS <wink>).

If this sounds like a good idea to Mark anyway, fine, but I don't buy it otherwise.
-------------------------------------------------------

Date: 2000-Sep-22 16:57
By: mhammond

Comment:
I've got to side with Tim that "last thread with a reference" is not the correct semantic to be applied here.

On the other hand, I do agree that some determinism would be nice here.  The reporter is completely correct about, eg, COM rules.  If I was BDFL, I would probably go for something deterministic, and that probably is "last thread to release", as anything else is just unreasonable.

My understanding of .NET is that it does GC on a seperate GC thread!  So there you are guaranteed to not get the behaviour (but guaranteed not to get it ever ;-)

Sorry Tim - back at ya!
-------------------------------------------------------

Date: 2000-Sep-25 02:04
By: htrd

Comment:
Ive noticed that this patch also fixes a different problem that I hadnt realised was related....

We were observing that one thread occasionally became blocked for a few tens of seconds, and the profiler wasnt giving any hints.

It turns out that this thread was busy emptying the trashcan, and running the deallocator functions for the objects used and discardered by all the other threads.

The script below shows up this problem (on NT). It prints pairs of numbers; the first out of each pair will stay the same for 'a long time'.

Mark: I assume Python.net will print the 'Waaah' lines too?

import thread,time

class A:
    def __init__(self,other):
        self._other = other
        self._ident = thread.get_ident()

    def __del__(self):
        new_ident = thread.get_ident()
        if new_ident!=self._ident:
            print 'Waaaaaah', new_ident, self._ident

def work(size):
    ident = thread.get_ident()
    while 1:
        a=None
        for i in range(size):
            a = A(a)
            for i in range(10):
                a = (a,)
            


# Three few big ones
for i in range(3):
    thread.start_new_thread(work,(1000,))
# And one huge one
work(100000)

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115076&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 14:02:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 06:02:51 -0700
Subject: [Python-bugs-list] [Bug #114324] Minor build problems on HPUX for 2.0b1
Message-ID: <200009251302.GAA10413@delerium.i.sourceforge.net>

Bug #114324, was updated on 2000-Sep-13 02:20
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 4
Summary: Minor build problems on HPUX for 2.0b1

Details: Build problems on HPUX10.20/HPUX11.00:

  - There seems to be no prototype for "fdatasync" in any include file
    although it has a man page and it is present in libc (so HAVE_FDATASYNC
    is set). As a result posixmodule.c fails to compile.
   
    Adding a prototype "extern int fdatasync(int);" to posixmodule.c solves 
    this problem, but it may not be portable.
    
  - Modules/mmapmodule.c is missing a "#include <limits.h>"
  
Build problems on HPUX10.20 only:

  - When configured with threading support (default), the cast to (long)
    on line 181 of Python/thread_pthread.h fails. The reason is that
    pthread_t is a struct type. The "configure" test that tries to find out
    the size of pthread_t failed because it tries to cast '0' to a pthread_t,
    so SIZEOF_PTHREAD_T remains undefined.
    
    I suggest changing this line in configure.in:
    
    AC_TRY_COMPILE([#include <pthread.h>], [pthread_t x; x = (pthread_t)0;], have_pthread_t=yes)
    
    to
    
    AC_TRY_COMPILE([#include <pthread.h>], [pthread_t x; x = *(pthread_t*)0;], have_pthread_t=yes)
    
My compiler settings:

   setenv CC 'c89 +DA1.1 +Onolimit -D_HPUX_SOURCE'

Regards,

Eddy

Follow-Ups:

Date: 2000-Sep-16 10:01
By: gvanrossum

Comment:
Randomly assigned to Jeremy for further investigation.
-------------------------------------------------------

Date: 2000-Sep-22 03:04
By: gvanrossum

Comment:
Assigned back to me because I'm planning to tackle HP build problems.
-------------------------------------------------------

Date: 2000-Sep-22 09:04
By: gvanrossum

Comment:
I've checked in a fix for fdatasync. Can you test that?
I'm also working on the thread config, that'll take longer.
-------------------------------------------------------

Date: 2000-Sep-22 09:41
By: edg

Comment:
The fix for fdatasync works.
However, I think it's better to use __hpux instead of __hppa to detect HP-UX.
(__hppa identifies the processor architecture).

FYI: The native cc/c89 compiler defines both __hppa and __hpux.
Gcc additionally defines hppa and hpux.

-------------------------------------------------------

Date: 2000-Sep-22 12:44
By: gvanrossum

Comment:
I *think* I've squashed this bug with my latest checkin to configure.in and configure. Thanks for the suggestion! Please test so I can close this bug report.
-------------------------------------------------------

Date: 2000-Sep-22 13:18
By: edg

Comment:
I can't test it before Monday, but it looks like you've
made a typo:

Configure.in, line 2522:
  ... *(pthread_t)*0; 

should be:

  ... *(pthread_t*)0; 

BTW: Modules/mmapmodule.c still misses 

#ifdef HAVE_LIMITS_H
#include <limits.h>
#endif

Without this, INT_MAX is undefined on HP-UX.

I'll test it first thing Monday morning.

-------------------------------------------------------

Date: 2000-Sep-25 01:24
By: edg

Comment:
The thread fix is ok.
Except for mmapmodule.c everything compiles straight out of the box now.



-------------------------------------------------------

Date: 2000-Sep-25 06:02
By: gvanrossum

Comment:
Thanks for your siggested fixes, this is closed.
I'll add <limits.h> to the set of standard include files included by Python.h.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114324&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 14:03:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 06:03:34 -0700
Subject: [Python-bugs-list] [Bug #115006] Python 2.0 won't build on HP Unix 10.2
Message-ID: <200009251303.GAA10426@delerium.i.sourceforge.net>

Bug #115006, was updated on 2000-Sep-21 13:31
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Duplicate
Bug Group: Platform-specific
Priority: 5
Summary: Python 2.0 won't build on HP Unix 10.2

Details: Call me at 877 737 7357 X4477  if I can help. ...Bob

With threads (default) at:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c thread.c

get error message:

In file included from thread.c_116:
thread_pthread.h: In function 'PyThread_get_thread_ident':
thread_pthread.h:181: aggreagete value used where an integer was expected




Without threads at:

gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c

error message is:

./posixmodule.c:713: 'fdatasync' undeclared (first use in this function)

Follow-Ups:

Date: 2000-Sep-21 14:56
By: fdrake

Comment:
Could you please check your system's man page for fdatasync() to and let us know what includes and compile-time defines are needed?  Thanks!
-------------------------------------------------------

Date: 2000-Sep-22 03:03
By: gvanrossum

Comment:
Assigned to me. Suspect it's a duplicate of #110650 and #110665.
-------------------------------------------------------

Date: 2000-Sep-22 09:03
By: gvanrossum

Comment:
Bob, I've checked in a fix for fdatasync. Can you test that? I'm also working on the thread configuration, but that'll take longer.

-------------------------------------------------------

Date: 2000-Sep-22 12:43
By: gvanrossum

Comment:
I *think* I've squished this one with my latest checkin. Please test!
-------------------------------------------------------

Date: 2000-Sep-25 06:03
By: gvanrossum

Comment:
This was a duplicate of Bug #114324; it's fixed now.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115006&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 14:10:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 06:10:34 -0700
Subject: [Python-bugs-list] [Bug #110650] [HP-UX] python with-threads core-dumps (PR#342)
Message-ID: <200009251310.GAA10654@delerium.i.sourceforge.net>

Bug #110650, was updated on 2000-Jul-31 14:10
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: [HP-UX] python with-threads core-dumps (PR#342)

Details: Jitterbug-Id: 342
Submitted-By: michael.exner@mrz.uni-magdeburg.de
Date: Wed, 31 May 2000 09:43:38 -0400 (EDT)
Version: 1.5.2
OS: hpux-11.00


When I compile python with threads python core-dumps:
$ ./python
pthread_mutex_init: Invalid argument
Memory fault(coredump)
without thread-support everything works fine
I tried this with hpux-ansi-c and with gcc (2.95.2) but got the same result




====================================================================
Audit trail:
Tue Jul 11 08:25:57 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-28 20:43
By: tim_one

Comment:
Note that the only call to pthread_mutex_init Python makes is in function PyThread_allocate_lock in file phread_pthread.h.  If Python compiled at all, it's extremely unlikely that the first argument is in error.  It's very likely that the second argument is in error, though:  there were many imcompatible revisions of the pthreads std, and pthread_mutexattr_default is a macro conditionally defined near the top of the file.  If this OS actually support pthreads, you have to figure out which *version* of pthreads it defines and arrange for config to define the *correct* one of the

PY_PTHREAD_D4
PY_PTHREAD_D7
PY_PTHREAD_STD
PY_PTHREAD_D6

symbols for your platform.  Else disable threads entirely.
-------------------------------------------------------

Date: 2000-Aug-29 07:34
By: memaul

Comment:
Goto link below for instructions and patches for building
python 152 with threads on hpux 10.20

http://memaul.tripod.com/index.html
-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-15 02:34
By: harripasanen

Comment:
I can verify that the bug exists not only in 1.5.2 but also in 1.6.

gcc 2.95.2
HPUX 11.00

I'll see if tim_one's suggestions help.

Regards,

Harri Pasanen
-------------------------------------------------------

Date: 2000-Sep-15 04:55
By: harripasanen

Comment:
The problems seems to be that configure gets the libraries wrong on HP-UX 11.0.   It links with -lcma, when it should link with -lpthread.

So a quick and dirty solution is to relink the python by hand, replacing -lcma with -lpthread.

-------------------------------------------------------

Date: 2000-Sep-15 10:04
By: fdrake

Comment:
Noted that this is HP-UX specific in summary.
-------------------------------------------------------

Date: 2000-Sep-22 03:02
By: gvanrossum

Comment:
Assigned to myself because this is another one about thread configuration on HP-UX, which I plan to tackle. Note that Harri (hi, Harri!) contradicts what another HP-UX bug report (#110665) says -- Harri says you shouldn't link with -lcma, the other says you should. (Or does it? It's ambiguous!)
-------------------------------------------------------

Date: 2000-Sep-25 06:10
By: gvanrossum

Comment:
I'm hoping that this was fixed by recent changes. Sent an email to the original submittor to verify.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110650&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 14:10:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 06:10:54 -0700
Subject: [Python-bugs-list] [Bug #110665] Compiling python on hpux 11.00 with threads (PR#360)
Message-ID: <200009251310.GAA10679@delerium.i.sourceforge.net>

Bug #110665, was updated on 2000-Jul-31 14:12
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Compiling python on hpux 11.00 with threads (PR#360)

Details: Jitterbug-Id: 360
Submitted-By: philipp.jocham@salomon.at
Date: Fri, 16 Jun 2000 08:47:06 -0400 (EDT)
Version: 1.5.2
OS: HP-UX 11.00


There are two missing details in the configure process to make this work
out of the box.

First: The function 
	pthread_create
isn't found in library libpthread.a but in libcma.a, because
pthread_create is just a macro in sys/pthread.h pointing to 
	__pthread_create_system

After patching ./configure directly and running 
	./configure --with-thread
(now detecting the correct library /usr/lib/libpthread.a) I also
added -lcl to Modules/Makefile at
	LIBS=           -lnet -lnsl -ldld  -lpthread -lcl

otherwise importing of modules with threads didn't work 
(in this case oci_.sl from DCOracle). 

I'm not sure about the correct syntax or wether it's the correct
place and method, but I would suggest a solution like the following
code snippet.

[...]
AC_MSG_CHECKING(for --with-thread)
[...]
AC_DEFINE(_POSIX_THREADS)
LIBS="$LIBS -lpthread -lcl"
LIBOBJS="$LIBOBJS thread.o"], [
AC_CHECK_LIB(pthread, __pthread_create_system, [AC_DEFINE(WITH_THREAD)
[...]

I hope this helps to make installation process smoother.
Fell free to contact me, if there are further questions.
Philipp
-- 
I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-22 02:56
By: gvanrossum

Comment:
Taking this because I'm considering to redesign the thread configuration section in configure.in anyway -- there's a similar bug report for Alpha OSF1.
-------------------------------------------------------

Date: 2000-Sep-25 06:10
By: gvanrossum

Comment:
I'm hoping that this was fixed by recent changes. Sent an email to the original submittor to verify.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110665&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 14:22:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 06:22:35 -0700
Subject: [Python-bugs-list] [Bug #115035] SunOS 4.1.4 with GCC 2.95.2 can't compile complete
Message-ID: <200009251322.GAA11041@delerium.i.sourceforge.net>

Bug #115035, was updated on 2000-Sep-21 18:24
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 1
Summary: SunOS 4.1.4 with GCC 2.95.2 can't compile complete

Details: 1) Module/posixmodule.c
  In Module/posixmodule.c, it used rename, pclose, fclose but SunOS 4.1.4's unistd.h does not have these definitions. So add them.
2) Modules/mmapmodule.c
  In Modules/mmapmodule.c, MS_SYNC used but SunOS 4.1.4's mman.h does not have this difinition. So add it.


Follow-Ups:

Date: 2000-Sep-21 18:56
By: gvanrossum

Comment:
I'm not sure what the proper solution is here. Can you provide a patch?
Which C preprocessor symbol do I check for to know that I'm on SunOS 4.1.4?

(1) We can't add decls for these funcs unconditionally because it would conflict with decls in unistd.h or elsewhere on other platforms.

(2) What is the proper replacement for MS_SYNC on SunOS 4.1.4?
-------------------------------------------------------

Date: 2000-Sep-23 01:52
By: loewis

Comment:
Specifying MS_SYNC is not necessary on SunOS 4, the msync manpage says

MS_ASYNC returns msync() immediately once all  I/O  operations  are  scheduled;  normally,  msync() will not return until all  I/O  operations  are  complete.

So it is safe to define it as 0.

I believe SunOS 4 can be recognized by testing that "sun" is defined and "__SVR4" is not.

According to the man pages, the missing prototypes are

       int rename(path1, path2)
       char *path1, *path2;
       fclose(stream)
       FILE *stream;
       pclose(stream)
       FILE *stream;

Indeed, no header file on this system has an fclose prototype...
-------------------------------------------------------

Date: 2000-Sep-24 16:54
By: moroo

Comment:
Pathes are last half of this message.

And more trouble
1) When making -L does not have any arguments, so making is stopped.
2) Some test does not pass.
  test log added next of pacthes.

Patches:
--- Patch Begin ---
*** Modules/mmapmodule.c.org    Fri Sep 22 17:01:14 2000
--- Modules/mmapmodule.c        Fri Sep 22 16:52:55 2000
***************
*** 24,29 ****
--- 24,35 ----
  #define UNIX
  #endif

+ #ifdef sun
+ #ifndef MS_SYNC
+ #define MS_SYNC 0x0
+ #endif
+ #endif
+
  #ifdef MS_WIN32
  #include <windows.h>
  #endif
*** Modules/posixmodule.c.org   Fri Sep 22 17:01:25 2000
--- Modules/posixmodule.c       Fri Sep 22 16:51:46 2000
***************
*** 106,111 ****
--- 106,118 ----

  #ifdef HAVE_UNISTD_H
  #include <unistd.h>
+ #ifdef sun
+ #ifdef _POSIX_VERSION
+ extern int rename(const char *, const char *);
+ extern int pclose(FILE *);
+ extern int fclose(FILE *);
+ #endif
+ #endif
  #endif

  #ifdef NeXT

--- Patch End ---

--- Test Log ---
#Delete successed lines.

test test_cgi crashed -- exceptions.AttributeError: uname
test test_format crashed -- exceptions.SystemError: error return without excepti
on set
test test_largefile skipped --  platform does not have largefile support
test test_poll skipped --  select.poll not defined -- skipping test_poll
test test_popen2 crashed -- exceptions.AttributeError: waitpid
test test_pwd crashed -- exceptions.AttributeError: getpwall
test test_signal crashed -- exceptions.AttributeError: alarm
test test_socket crashed -- exceptions.AttributeError: getpeername
test test_strftime skipped --  cannot import name mktime
test test_time crashed -- exceptions.AttributeError: clock
test test_unicode crashed -- exceptions.SystemError: error return without except
ion set
test test_urllib crashed -- exceptions.AttributeError: quote
9 tests failed: test_cgi test_format test_popen2 test_pwd test_signal test_socke
t test_time test_unicode test_urllib
31 tests skipped: test_al test_audioop test_bsddb test_cd test_cl test_crypt tes
t_dbm test_dl test_fork1 test_gc test_gdbm test_gl test_gzip test_imageop test_i
mgfile test_largefile test_linuxaudiodev test_minidom test_nis test_openpty test
_poll test_pty test_pyexpat test_rgbimg test_strftime test_sunaudiodev test_thre
ad test_timing test_winreg test_winsound test_zlib
test test_cgi crashed -- exceptions.AttributeError: uname
test test_format crashed -- exceptions.SystemError: error return without excepti
on set
test test_largefile skipped --  platform does not have largefile support
test test_longexp crashed -- exceptions.MemoryError:
test test_popen2 crashed -- exceptions.OSError: [Errno 12] Not enough memory
test test_pwd crashed -- exceptions.AttributeError: getpwall
/bin/sh: 12372 Memory fault - core dumped
--- End ---


-------------------------------------------------------

Date: 2000-Sep-25 06:22
By: gvanrossum

Comment:
Fixed both issues. Please test from the CVS tree (or wait for 2.0b2, in two days), as I don't have a SunOS 4.1.4 system available for testing!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115035&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 14:46:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 06:46:43 -0700
Subject: [Python-bugs-list] [Bug #115261] ambiguous else
Message-ID: <200009251346.GAA11991@delerium.i.sourceforge.net>

Bug #115261, was updated on 2000-Sep-25 01:02
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Invalid
Bug Group: None
Priority: 5
Summary: ambiguous else

Details: A statement like:

      if (newref) Py_DECREF(obj);

will generate an ambiguous else message.  (The line
is from SWIG1.3a4.)

It's good practice to always use braces, because you
never know what context your code will get copied into
(this is true even if it's not a macro; think cut & paste).

I'd change it (and other similar) to:

#define Py_DECREF(op) { \
        if (--_Py_RefTotal, --(op)->ob_refcnt != 0) { \
        } else { \
                _Py_Dealloc((PyObject *)(op)); \
        }}


Follow-Ups:

Date: 2000-Sep-25 06:46
By: gvanrossum

Comment:
With your proposed version, this code:

if (...) Py_DECREF(obj); else { ... }

will give a syntax error -- it expands to

if (...) { ... } ; else { ... }

where the " } ; " part is invalid.

Please believe me, we know what we are doing. The Py_INCREF() macro is correct, your compiler is wrong to warn about that construct. To keep your compile happy, you can write

if (...) { Py_DECREF(obj); }

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115261&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 14:46:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 06:46:11 -0700
Subject: [Python-bugs-list] [Bug #115261] ambiguous else
Message-ID: <200009251346.GAA11974@delerium.i.sourceforge.net>

Bug #115261, was updated on 2000-Sep-25 01:02
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: ambiguous else

Details: A statement like:

      if (newref) Py_DECREF(obj);

will generate an ambiguous else message.  (The line
is from SWIG1.3a4.)

It's good practice to always use braces, because you
never know what context your code will get copied into
(this is true even if it's not a macro; think cut & paste).

I'd change it (and other similar) to:

#define Py_DECREF(op) { \
        if (--_Py_RefTotal, --(op)->ob_refcnt != 0) { \
        } else { \
                _Py_Dealloc((PyObject *)(op)); \
        }}


Follow-Ups:

Date: 2000-Sep-25 06:46
By: gvanrossum

Comment:
With your proposed version, this code:

if (...) Py_DECREF(obj); else { ... }

will give a syntax error -- it expands to

if (...) { ... } ; else { ... }

where the " } ; " part is invalid.

Please believe me, we know what we are doing. The Py_INCREF() macro is correct, your compiler is wrong to warn about that construct. To keep your compile happy, you can write

if (...) { Py_DECREF(obj); }

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115261&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 16:06:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 08:06:28 -0700
Subject: [Python-bugs-list] [Bug #110621] rfc822.py module - address parsing problem (PR#235)
Message-ID: <200009251506.IAA23259@bush.i.sourceforge.net>

Bug #110621, was updated on 2000-Jul-31 14:06
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: rfc822.py module - address parsing problem (PR#235)

Details: Jitterbug-Id: 235
Submitted-By: piers@cs.su.oz.au
Date: Tue, 14 Mar 2000 18:55:39 -0500 (EST)
Version: 1.5.2
OS: sunos


RFC822 specifies an address form known as a "domain literal",
eg: [132.151.1.21], but rfc822.parseaddr() incorrectly strips
the square brackets denoting special treatment of the contents.
(This routine is used by smtplib module, and thus causes it
to deliver messages using this form of address incorrectly.)

Here is an example:

: s ; python
Python 1.5.2 (#10, May 11 1999, 15:32:03)  [GCC 2.8.1] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import rfc822
>>> rfc822.parseaddr('guido@[132.151.1.21]')
('', 'guido@132.151.1.21')
>>> 





====================================================================
Audit trail:
Mon May 22 17:36:36 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-25 08:06
By: bwarsaw

Comment:
The patch is simple.  Change line 706 (in the 2.0beta1 CVS tree) to read

return '[%s]' % self.getdelimited('[', ']\r', 0)

to rewrap the value in angle brackets.  Will try to get this into 2.0beta2.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110621&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 16:08:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 08:08:37 -0700
Subject: [Python-bugs-list] [Bug #110621] rfc822.py module - address parsing problem (PR#235)
Message-ID: <200009251508.IAA23393@bush.i.sourceforge.net>

Bug #110621, was updated on 2000-Jul-31 14:06
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: rfc822.py module - address parsing problem (PR#235)

Details: Jitterbug-Id: 235
Submitted-By: piers@cs.su.oz.au
Date: Tue, 14 Mar 2000 18:55:39 -0500 (EST)
Version: 1.5.2
OS: sunos


RFC822 specifies an address form known as a "domain literal",
eg: [132.151.1.21], but rfc822.parseaddr() incorrectly strips
the square brackets denoting special treatment of the contents.
(This routine is used by smtplib module, and thus causes it
to deliver messages using this form of address incorrectly.)

Here is an example:

: s ; python
Python 1.5.2 (#10, May 11 1999, 15:32:03)  [GCC 2.8.1] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import rfc822
>>> rfc822.parseaddr('guido@[132.151.1.21]')
('', 'guido@132.151.1.21')
>>> 





====================================================================
Audit trail:
Mon May 22 17:36:36 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Sep-25 08:06
By: bwarsaw

Comment:
The patch is simple.  Change line 706 (in the 2.0beta1 CVS tree) to read

return '[%s]' % self.getdelimited('[', ']\r', 0)

to rewrap the value in angle brackets.  Will try to get this into 2.0beta2.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110621&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 16:10:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 08:10:52 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200009251510.IAA23445@bush.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 13:45
By: fdrake

Comment:
We need to know the output of "uname -s" and "uname -r" for this system.  (If "uname -r" reports an error, please try "uname -v".)

Are you willing to test a modified configure script on this platform?

What additional library is required for the mmap module?
-------------------------------------------------------

Date: 2000-Sep-12 21:59
By: fdrake

Comment:
Received the following response from Daniel Dittmar <ddittmar@users.sourceforge.net>:

> We need to know the output of "uname -s" and "uname -r" 
> for this system.  (If "uname -r" reports an error, please 
> try "uname -v".)

uname -s
ReliantUNIX-N

uname -r
5.45


> Are you willing to test a modified configure script on
> this platform?

sure.

> What additional library is required for the mmap module?

The man page states -lucb. This didn't work on my machine 
as the BSD compatibility layer is not active. I tell you 
more as soon as I know how to activate it.

***********

Another problem: to detect pthreads, the compiler must be 
called with -Kpthread. Otherwise, pthread.h goes into a 
branch where it tries to include a non existent header, 
fails, and configure reports 'no pthreads'.

Daniel

-------------------------------------------------------

Date: 2000-Sep-15 11:57
By: fdrake

Comment:
For the mmap issue, I've added a comment to Modules/Setup.in to let installers know that -lucb may be needed.  In revision 1.110.
-------------------------------------------------------

Date: 2000-Sep-15 13:37
By: fdrake

Comment:
I'm sending a modified version of  the configure script to Daniel Dittmar to test for the first two points in this bug report.
-------------------------------------------------------

Date: 2000-Sep-21 08:17
By: fdrake

Comment:
Sent query to Daniel Dittmar asking if he's had a chance to test the revised configure script I sent.
-------------------------------------------------------

Date: 2000-Sep-21 08:46
By: fdrake

Comment:
Received message from Daniel indicating he should get a chace to test the changes this weekend, so it should be available for 2.0b2.
-------------------------------------------------------

Date: 2000-Sep-24 05:46
By: ddittmar

Comment:
- configure --without-threads works with the configure patch Revision 1.158

- mmapmodule would work if it includes the lines

#include <unistd.h>

static int
getpagesize (void)
{
    return sysconf (_SC_PAGESIZE);
}

This would be the preferred way as using the BSD compatibility with -lucb is discouraged.

It requires chages to configure (has_pagesize, has_sysconf_sc_pagesize)

- configure --with-threads doesn't build yet, keeping contact with fdrake
-------------------------------------------------------

Date: 2000-Sep-25 08:10
By: fdrake

Comment:
Fix to make sure the public API properly exposed to extensions checked in as configure.in revision 1.155.  The rest of these issues can be dealt with in 2.0 final.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 16:59:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 08:59:42 -0700
Subject: [Python-bugs-list] [Bug #110678] rfc822.Message getaddr method bug (PR#39)
Message-ID: <200009251559.IAA25451@bush.i.sourceforge.net>

Bug #110678, was updated on 2000-Jul-31 14:13
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 3
Summary: rfc822.Message getaddr method bug (PR#39)

Details: Jitterbug-Id: 39
Submitted-By: piers@cs.su.oz.au
Date: Fri, 30 Jul 1999 01:34:24 -0400 (EDT)
Version: 1.5.2
OS: Solaris


The following mail header, when parsed by rfc822, returns an incorrect
address from the method getaddr:

        From nobody@bounces.amazon.com Thu Jul 29 18:09:07 1999
        Date: Thu, 29 Jul 1999 00:05:26 -0700
        MIME-Version: 1.0
        Content-Type: multipart/alternative; boundary=z
        Subject: A Message from Amazon.com Delivers
        From: Amazon.com <delivers-news2@amazon.com>

        >>> import rfc822
        >>> fd=open('mail/amazon.com')
        >>> M=rfc822.Message(fd, 1)
        >>> M.getaddr('From')
        ('', 'Amazon.com')

Python version is:
Python 1.5.2 (#10, May 11 1999, 15:32:03)  [GCC 2.8.1] on sunos5



====================================================================
Audit trail:
Fri Jul 30 08:25:26 1999	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Sjoerd Mullender <sjoerd@oratrix.nl>
Subject: Re: [Python-bugs-list] rfc822.Message getaddr method bug (PR#39)
Date: Mon, 02 Aug 1999 14:09:40 +0200

On Fri, Jul 30 1999 piers@cs.su.oz.au wrote:

> Full_Name: Piers Lauder
> Version: 1.5.2
> OS: Solaris
> Submission from: metra.ucc.usyd.edu.au (129.78.64.5)
> 
> 
> The following mail header, when parsed by rfc822, returns an incorrect
> address from the method getaddr:
> 
>         From nobody@bounces.amazon.com Thu Jul 29 18:09:07 1999
>         Date: Thu, 29 Jul 1999 00:05:26 -0700
>         MIME-Version: 1.0
>         Content-Type: multipart/alternative; boundary=z
>         Subject: A Message from Amazon.com Delivers
>         From: Amazon.com <delivers-news2@amazon.com>
> 
>         >>> import rfc822
>         >>> fd=open('mail/amazon.com')
>         >>> M=rfc822.Message(fd, 1)
>         >>> M.getaddr('From')
>         ('', 'Amazon.com')
> 
> Python version is:
> Python 1.5.2 (#10, May 11 1999, 15:32:03)  [GCC 2.8.1] on sunos5

It's an incorrect mail header.  The period in Amazon.com is not
allowed there but the name has to be quoted with double quotes.

But I guess rfc822.py could (and should) be lenient and let you get
away with this.

-- Sjoerd Mullender <sjoerd.mullender@oratrix.com>

-------------------------------------------------------

Date: 2000-Sep-07 15:01
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-12 08:54
By: jhylton

Comment:
Barry -- you're the resident mail guy.  You might think about adding this feature post 2.0.

-------------------------------------------------------

Date: 2000-Sep-25 08:59
By: bwarsaw

Comment:
Sjoerd's right.  I've added this feature request to PEP 42 so we can close this bug report.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110678&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 18:00:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 10:00:42 -0700
Subject: [Python-bugs-list] [Bug #114290] search_for_prefix failure on relative path
Message-ID: <200009251700.KAA27827@bush.i.sourceforge.net>

Bug #114290, was updated on 2000-Sep-12 14:38
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: search_for_prefix failure on relative path

Details: The code in getpath.c fails in Step 3 (search for the libraries using the argv0 path) when python is invoked with a relative path.  The search code should be able to join the relative path with the current working directory and find the landmark file.


Follow-Ups:

Date: 2000-Sep-12 19:20
By: fdrake

Comment:
Barry, didn't you write most of the current code to locate the installation?  If not, assign it to whoever did.
-------------------------------------------------------

Date: 2000-Sep-25 10:00
By: jhylton

Comment:
fixed in rev. 1.31 of Modules/getpath.c

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114290&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 18:03:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 10:03:52 -0700
Subject: [Python-bugs-list] [Bug #114290] search_for_prefix failure on relative path
Message-ID: <200009251703.KAA27995@bush.i.sourceforge.net>

Bug #114290, was updated on 2000-Sep-12 14:38
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Summary: search_for_prefix failure on relative path

Details: The code in getpath.c fails in Step 3 (search for the libraries using the argv0 path) when python is invoked with a relative path.  The search code should be able to join the relative path with the current working directory and find the landmark file.


Follow-Ups:

Date: 2000-Sep-12 19:20
By: fdrake

Comment:
Barry, didn't you write most of the current code to locate the installation?  If not, assign it to whoever did.
-------------------------------------------------------

Date: 2000-Sep-25 10:00
By: jhylton

Comment:
fixed in rev. 1.31 of Modules/getpath.c

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114290&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 19:39:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 11:39:43 -0700
Subject: [Python-bugs-list] [Bug #114923] ToolTip not showing text on AIX 4.3
Message-ID: <200009251839.LAA31722@bush.i.sourceforge.net>

Bug #114923, was updated on 2000-Sep-20 14:27
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: ToolTip not showing text on AIX 4.3

Details: IDLE0.6 runs nicely on AIX except that the tip text itself does not show when the pop up box appears. The box seems to be sized properly but is blank.

-Robin Friedrich

Follow-Ups:

Date: 2000-Sep-20 16:54
By: gvanrossum

Comment:
Could it be a Tcl version problem? It's hard to debug this... :-(
-------------------------------------------------------

Date: 2000-Sep-21 14:17
By: none

Comment:
Yes I imagine it will be hard to debug. The tclTk version is 8.3.2. I am unaware of problems with that on the X windows platforms. Has this been noticed on other unices with 2.0b1?  --Robin F.
-------------------------------------------------------

Date: 2000-Sep-21 14:23
By: gvanrossum

Comment:
BTW, where do you expect to see tooltips? The only place I can think of is when you type a function name followed by a left paren. Is that it? What function name did you use?

(And yes, this works fine for me on Linux.)

Could it have to do with font? color? Perhaps your window manager?
Source is in CallTipWindow.py if you want to play.
-------------------------------------------------------

Date: 2000-Sep-25 11:39
By: none

Comment:
The open paren binding yes. Any function like those in the string module.
OK I've played with CallTipWindow.py and the main() test routine exhibits the bug nicely. The code looks dead simple and should work. I can only blame Tk 8.3.2. I tried linking in our old Tk 8.0 libraries/headers (hoping Tkinter was still compatible with it) and the tooltip call now raises the following. We are using X/Motif with the CDE window manager.

>>> idle.CallTipWindow.main()
>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "./Lib/lib-tk/Tkinter.py", line 1283, in __call__
    args = apply(self.subst, args)
  File "./Lib/lib-tk/Tkinter.py", line 1053, in _substitute
    e.delta = getint(D)
ValueError: invalid literal for int(): D




-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114923&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 20:00:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 12:00:16 -0700
Subject: [Python-bugs-list] [Bug #115308] codecs base classes need documentation
Message-ID: <200009251900.MAA24390@delerium.i.sourceforge.net>

Bug #115308, was updated on 2000-Sep-25 12:00
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: codecs base classes need documentation

Details: The documentation for the codecs module includes a note that base classes need to be implemented; this needs to happen for the 2.0 final release.

There should be some note at the top of the section about what the module is for -- Unicode is not mentioned, but that's the primary (expected) use.  Let's say something about that, and perhaps give examples at the end (especially for handling encoded files).

For the open() function, the docs refer to a "buffering" parameter, and say that it matches the meaning of the the same thing for the open() built-in.  It should be called "bufsize" to match the built-in documentation.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115308&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 20:41:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 12:41:16 -0700
Subject: [Python-bugs-list] [Bug #114923] ToolTip not showing text on AIX 4.3
Message-ID: <200009251941.MAA01679@bush.i.sourceforge.net>

Bug #114923, was updated on 2000-Sep-20 14:27
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: ToolTip not showing text on AIX 4.3

Details: IDLE0.6 runs nicely on AIX except that the tip text itself does not show when the pop up box appears. The box seems to be sized properly but is blank.

-Robin Friedrich

Follow-Ups:

Date: 2000-Sep-20 16:54
By: gvanrossum

Comment:
Could it be a Tcl version problem? It's hard to debug this... :-(
-------------------------------------------------------

Date: 2000-Sep-21 14:17
By: none

Comment:
Yes I imagine it will be hard to debug. The tclTk version is 8.3.2. I am unaware of problems with that on the X windows platforms. Has this been noticed on other unices with 2.0b1?  --Robin F.
-------------------------------------------------------

Date: 2000-Sep-21 14:23
By: gvanrossum

Comment:
BTW, where do you expect to see tooltips? The only place I can think of is when you type a function name followed by a left paren. Is that it? What function name did you use?

(And yes, this works fine for me on Linux.)

Could it have to do with font? color? Perhaps your window manager?
Source is in CallTipWindow.py if you want to play.
-------------------------------------------------------

Date: 2000-Sep-25 11:39
By: none

Comment:
The open paren binding yes. Any function like those in the string module.
OK I've played with CallTipWindow.py and the main() test routine exhibits the bug nicely. The code looks dead simple and should work. I can only blame Tk 8.3.2. I tried linking in our old Tk 8.0 libraries/headers (hoping Tkinter was still compatible with it) and the tooltip call now raises the following. We are using X/Motif with the CDE window manager.

>>> idle.CallTipWindow.main()
>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "./Lib/lib-tk/Tkinter.py", line 1283, in __call__
    args = apply(self.subst, args)
  File "./Lib/lib-tk/Tkinter.py", line 1053, in _substitute
    e.delta = getint(D)
ValueError: invalid literal for int(): D




-------------------------------------------------------

Date: 2000-Sep-25 12:41
By: gvanrossum

Comment:
The getint(D) problem is because earlier versions of Tkinter don't support the mousewheel delta value.

Try again with the current CVS version (or wait 1.5 days for Python 2.0b2 to be released). The getint(D) problem should be solved in the CVS version (a try/except is put around it).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114923&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 20:54:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 12:54:02 -0700
Subject: [Python-bugs-list] [Bug #110681] memory leak in loops (PR#398)
Message-ID: <200009251954.MAA26518@delerium.i.sourceforge.net>

Bug #110681, was updated on 2000-Jul-31 14:14
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 5
Summary: memory leak in loops (PR#398)

Details: Jitterbug-Id: 398
Submitted-By: ingo.adler@synacon.ch
Date: Fri, 14 Jul 2000 05:10:25 -0400 (EDT)
Version: 1.5.2
OS: win nt


I have a simple loop, which produces memory leaks at every call (36 bytes):

{
    Py_SetProgramName("pythontest.exe");
    Py_Initialize();

    initxmodulec();

    PyRun_SimpleString("print \"... Python started ...\"");

    PyRun_SimpleString("import xmodule");
    PyRun_SimpleString("from xmodule import *");

// The Loop
    PyRun_SimpleString(
        "y = Y()\n"
        "for i in range(1000):\n"
        "\tx = y.getX()\n"
        "\tx.getNumber()\n"
    );




    PyRun_SimpleString("print \"... Python finished ...\"");
    Py_Finalize();
}

X and Y are my classes implemented in C++, connected to Python via Swig Shadow
Classes:

class X {

public:
    float getNumber()
    {
        return 12.2;
    }
};

class Y {
    X* pX;

public:
    Y()
    {
        pX = new X;
    }

    ~Y()
    {
        delete pX;
    }

    X* getX()
    {
        return pX;
    }
};

The classes and python are compiled statically with CBuilder5.0, Swig1.3a3 (same
problem with swig1.1).

I tested the application with "CodeGuard", which shows the memory leaks.
For every call in the loop there is an entry like this (I translated it to
English):

Error. 0x300010 (Thread 0x013B):
resource leak: memory block (0x15422F0) was never released

memory leak (0x015422F0) [size: 36 Byte] was assigned with malloc
call stack:
   0x0045ED5D(=pythontest.exe:0x01:05DD5D)
G:\Projects\src\fortuna\Python\Objects\stringobject.c#145
   0x00401EFD(=pythontest.exe:0x01:000EFD)
G:\Projects\src\fortuna\test\xmodule_wrap.c#769
   0x0040255D(=pythontest.exe:0x01:00155D)
G:\Projects\src\fortuna\test\xmodule_wrap.c#941
   0x0041BA79(=pythontest.exe:0x01:01AA79)
G:\Projects\src\fortuna\Python\Python\ceval.c#2359
   0x0041B912(=pythontest.exe:0x01:01A912)
G:\Projects\src\fortuna\Python\Python\ceval.c#2324
   0x0040EE3E(=pythontest.exe:0x01:00DE3E)
G:\Projects\src\fortuna\Python\Python\bltinmodule.c#12


The Code for line 941:

#define Y_getX(_swigobj)  (_swigobj->getX())
static PyObject *_wrap_Y_getX(PyObject *self, PyObject *args) {
    Y  *_arg0;
    PyObject  *_resultobj,*_argo0=0;
    X  *_result;
    self = self;
    if(!PyArg_ParseTuple(args,"O:Y_getX",&_argo0)) 
        return NULL;
    if ((SWIG_ConvertPtr(_argo0,(void **) &_arg0,SWIGTYPE_Y_p,1)) == -1) return
NULL;
    _result = (X *)Y_getX(_arg0);
/*941*/ _resultobj = SWIG_NewPointerObj((void *) _result, SWIGTYPE_X_p);
    return _resultobj;
}

The Code for line 769:

SWIGSTATICRUNTIME(PyObject *)
SWIG_NewPointerObj(void *ptr, _swig_type_info *type) {
  char result[512];
  PyObject *robj;
  if (!ptr) {
    Py_INCREF(Py_None);
    return Py_None;
  }
#ifdef SWIG_COBJECT_TYPES
  robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, type->name, NULL);
#else
  SWIG_MakePtr(result,ptr,type);
/*769*/  robj = PyString_FromString(result);
#endif
  return robj;
}


Ingo Adler



====================================================================
Audit trail:
Tue Jul 25 07:27:50 2000	guido	changed notes
Tue Jul 25 07:27:50 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "M.-A. Lemburg" <mal@lemburg.com>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 11:22:51 +0200

ingo.adler@synacon.ch wrote:
> 
> Full_Name: ingo adler
> Version: 1.5.2
> OS: win nt
> Submission from: megazh-d-201.agrinet.ch (212.28.158.201)
> 
> I have a simple loop, which produces memory leaks at every call (36 bytes):
> 
> {
>     Py_SetProgramName("pythontest.exe");
>     Py_Initialize();
> 
>     initxmodulec();
> 
>     PyRun_SimpleString("print \"... Python started ...\"");
> 
>     PyRun_SimpleString("import xmodule");
>     PyRun_SimpleString("from xmodule import *");
> 
> // The Loop
>     PyRun_SimpleString(
>         "y = Y()\n"
>         "for i in range(1000):\n"
>         "\tx = y.getX()\n"
>         "\tx.getNumber()\n"

Could be that SWIG doesn't get a chance to cleanup the shadow
object for x and y. Try adding

del x,y

as final script line.

Note that SWIG uses Python strings to represent pointers in
C++. It uses an internal table to store these.

>     );
> 
>     PyRun_SimpleString("print \"... Python finished ...\"");
>     Py_Finalize();
> }
> 
> X and Y are my classes implemented in C++, connected to Python via Swig Shadow
> Classes:
> 
> class X {
> 
> public:
>     float getNumber()
>     {
>         return 12.2;
>     }
> };
> 
> class Y {
>     X* pX;
> 
> public:
>     Y()
>     {
>         pX = new X;
>     }
> 
>     ~Y()
>     {
>         delete pX;
>     }
> 
>     X* getX()
>     {
>         return pX;
>     }
> };
> 
> The classes and python are compiled statically with CBuilder5.0, Swig1.3a3 (same
> problem with swig1.1).
> 
> I tested the application with "CodeGuard", which shows the memory leaks.
> For every call in the loop there is an entry like this (I translated it to
> English):
> 
> Error. 0x300010 (Thread 0x013B):
> resource leak: memory block (0x15422F0) was never released
> 
> memory leak (0x015422F0) [size: 36 Byte] was assigned with malloc
> call stack:
>    0x0045ED5D(=pythontest.exe:0x01:05DD5D)
> G:\Projects\src\fortuna\Python\Objects\stringobject.c#145
>    0x00401EFD(=pythontest.exe:0x01:000EFD)
> G:\Projects\src\fortuna\test\xmodule_wrap.c#769
>    0x0040255D(=pythontest.exe:0x01:00155D)
> G:\Projects\src\fortuna\test\xmodule_wrap.c#941
>    0x0041BA79(=pythontest.exe:0x01:01AA79)
> G:\Projects\src\fortuna\Python\Python\ceval.c#2359
>    0x0041B912(=pythontest.exe:0x01:01A912)
> G:\Projects\src\fortuna\Python\Python\ceval.c#2324
>    0x0040EE3E(=pythontest.exe:0x01:00DE3E)
> G:\Projects\src\fortuna\Python\Python\bltinmodule.c#12
> 
> The Code for line 941:
> 
> #define Y_getX(_swigobj)  (_swigobj->getX())
> static PyObject *_wrap_Y_getX(PyObject *self, PyObject *args) {
>     Y  *_arg0;
>     PyObject  *_resultobj,*_argo0=0;
>     X  *_result;
>     self = self;
>     if(!PyArg_ParseTuple(args,"O:Y_getX",&_argo0))
>         return NULL;
>     if ((SWIG_ConvertPtr(_argo0,(void **) &_arg0,SWIGTYPE_Y_p,1)) == -1) return
> NULL;
>     _result = (X *)Y_getX(_arg0);
> /*941*/ _resultobj = SWIG_NewPointerObj((void *) _result, SWIGTYPE_X_p);
>     return _resultobj;
> }
> 
> The Code for line 769:
> 
> SWIGSTATICRUNTIME(PyObject *)
> SWIG_NewPointerObj(void *ptr, _swig_type_info *type) {
>   char result[512];
>   PyObject *robj;
>   if (!ptr) {
>     Py_INCREF(Py_None);
>     return Py_None;
>   }
> #ifdef SWIG_COBJECT_TYPES
>   robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, type->name, NULL);
> #else
>   SWIG_MakePtr(result,ptr,type);
> /*769*/  robj = PyString_FromString(result);
> #endif
>   return robj;
> }
> 
> Ingo Adler
> 
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Ingo Adler <ingo.adler@synacon.ch>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 11:40:42 +0100

This is a multi-part message in MIME format.
--------------6D29988B97CCE77010389AE2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> > // The Loop
> >     PyRun_SimpleString(
> >         "y = Y()\n"
> >         "for i in range(1000):\n"
> >         "\tx = y.getX()\n"
> >         "\tx.getNumber()\n"
>
> Could be that SWIG doesn't get a chance to cleanup the shadow
> object for x and y. Try adding
>
> del x,y
>
> as final script line.
>
> Note that SWIG uses Python strings to represent pointers in
> C++. It uses an internal table to store these.
>

I changed the code to:

    PyRun_SimpleString(
        "y = Y()\n"
        "for i in range(1000):\n"
        "\tx = y.getX()\n"
        "\tx.getNumber()\n"
        "\tdel x\n"
    );

It doesn't change anything.

The memory leak only occurs when I call x.getNumber() in the loop. Otherwise x =
y.getX() is memory leak free.

Ingo Adler

--------------6D29988B97CCE77010389AE2
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;cell:+41-79-3786792
tel;fax:+41-41-7103244
tel;home:+41-41-7103268
tel;work:+41-41-8111500
x-mozilla-html:FALSE
url:www.synacon.ch
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
title:Dipl.-Inform.
fn:Ingo Adler
end:vcard

--------------6D29988B97CCE77010389AE2--



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "M.-A. Lemburg" <mal@lemburg.com>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 12:13:13 +0200

Ingo Adler wrote:
> 
> > > // The Loop
> > >     PyRun_SimpleString(
> > >         "y = Y()\n"
> > >         "for i in range(1000):\n"
> > >         "\tx = y.getX()\n"
> > >         "\tx.getNumber()\n"
> >
> > Could be that SWIG doesn't get a chance to cleanup the shadow
> > object for x and y. Try adding
> >
> > del x,y
> >
> > as final script line.
> >
> > Note that SWIG uses Python strings to represent pointers in
> > C++. It uses an internal table to store these.
> >
> 
> I changed the code to:
> 
>     PyRun_SimpleString(
>         "y = Y()\n"
>         "for i in range(1000):\n"
>         "\tx = y.getX()\n"
>         "\tx.getNumber()\n"
>         "\tdel x\n"
>     );
> 
> It doesn't change anything.
> 
> The memory leak only occurs when I call x.getNumber() in the loop. Otherwise x =
> y.getX() is memory leak free.

Two other possibilities:

1. Python interns the string object used by SWIG to represent
the point. It should then free the memory in the Py_Finalize()
call. If it doesn't, there's a bug to be found ;-)

2. SWIG has the leak. Try using the alternative method of
defining SWIG_COBJECT_TYPES (don't know how this is done --
it seems to be new in SWIG).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Ingo Adler <ingo.adler@synacon.ch>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Fri, 14 Jul 2000 12:45:02 +0100

This is a multi-part message in MIME format.
--------------82393A6779ADCFC3A2ADE19E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I could reproduce the problem with Developer Studio 6.0.

If anyone wants the project to test it - I can provide it.

Ingo Adler

--------------82393A6779ADCFC3A2ADE19E
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;cell:+41-79-3786792
tel;fax:+41-41-7103244
tel;home:+41-41-7103268
tel;work:+41-41-8111500
x-mozilla-html:FALSE
url:www.synacon.ch
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
title:Dipl.-Inform.
fn:Ingo Adler
end:vcard

--------------82393A6779ADCFC3A2ADE19E--



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "Mark Hammond" <mhammond@skippinet.com.au>
Subject: RE: [Python-bugs-list] memory leak in loops (PR#398)
Date: Mon, 17 Jul 2000 22:16:54 -0400

> I could reproduce the problem with Developer Studio 6.0.
>
> If anyone wants the project to test it - I can provide it.

If you can repro the problem in just a few lines of C/C++ code but with no
SWIG generated code, I would be interested.  Otherwise, I suggest you do
some more work to narrow the problem down some more; as described, there is
still too much work to be done to narrow down the problem to the cause for
me to be interested (or anyone else given the feedback to date!)

Mark.



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Ingo Adler <ingo.adler@synacon.ch>
Subject: Re: [Python-bugs-list] memory leak in loops (PR#398)
Date: Tue, 25 Jul 2000 01:34:22 +0200

This is a multi-part message in MIME format.
--------------72A23DA082087CB843E12C92
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Mark,

I could repro the memory leaks (they seem to be the same) with a much smaller
program:

int main(int argc, char* argv[])
{
    Py_SetProgramName("pythontest.exe");
    Py_Initialize();
    PyRun_SimpleString("print \"... Python started ...\"");
    PyRun_SimpleString("print \"... Python finished ...\"");
    Py_Finalize();

    return 0;
}

There seems to be a more general problem, which includes my special problem.

Output of Code Guard (translated to English). BoundsChecker shows the same
leaks.

Ingo

Output:

Memory Block (0x014EB9B4) [Size: 37 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043515A(=pythontest.exe:0x01:03415A)
D:\projects\Python\Objects\stringobject.c#95
   0x0043A8EB(=pythontest.exe:0x01:0398EB)
D:\projects\Python\Python\marshal.c#483
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB88(=pythontest.exe:0x01:039B88)
D:\projects\Python\Python\marshal.c#568
   0x0043AD37(=pythontest.exe:0x01:039D37)
D:\projects\Python\Python\marshal.c#624
   0x0042BC54(=pythontest.exe:0x01:02AC54)
D:\projects\Python\Python\import.c#575

------------------------------------------
Error 00078. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E4858) was never freed

Memory Block (0x014E4858) [Size: 31 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x00433896(=pythontest.exe:0x01:032896)
D:\projects\Python\Objects\moduleobject.c#56
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428
   0x0043B0C9(=pythontest.exe:0x01:03A0C9)
D:\projects\Python\Python\modsupport.c#82
   0x0040C68A(=pythontest.exe:0x01:00B68A)
D:\projects\Python\Python\bltinmodule.c#2393

------------------------------------------
Error 00079. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E47D0) was never freed

Memory Block (0x014E47D0) [Size: 28 Byte] was assigned with malloc
Aufrufhierarchie:
   0x00433CB3(=pythontest.exe:0x01:032CB3)
D:\projects\Python\Objects\object.c#122
   0x00424115(=pythontest.exe:0x01:023115)
D:\projects\Python\Objects\dictobject.c#124
   0x004367D3(=pythontest.exe:0x01:0357D3)
D:\projects\Python\Objects\stringobject.c#1075
   0x00425418(=pythontest.exe:0x01:024418)
D:\projects\Python\Objects\dictobject.c#1087
   0x0043387A(=pythontest.exe:0x01:03287A)
D:\projects\Python\Objects\moduleobject.c#54
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428

------------------------------------------
Error 00080. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E47AC) was never freed

Memory Block (0x014E47AC) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x0043387A(=pythontest.exe:0x01:03287A)
D:\projects\Python\Objects\moduleobject.c#54
   0x0042B993(=pythontest.exe:0x01:02A993)
D:\projects\Python\Python\import.c#428
   0x0043B0C9(=pythontest.exe:0x01:03A0C9)
D:\projects\Python\Python\modsupport.c#82
   0x0040C68A(=pythontest.exe:0x01:00B68A)
D:\projects\Python\Python\bltinmodule.c#2393

------------------------------------------
Error 00081. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E46E4) was never freed

Memory Block (0x014E46E4) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x004240F7(=pythontest.exe:0x01:0230F7)
D:\projects\Python\Objects\dictobject.c#120
   0x0043C27B(=pythontest.exe:0x01:03B27B)
D:\projects\Python\Python\pythonrun.c#132
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00082. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x1524000) was never freed

Memory Block (0x01524000) [Size: 12288 Byte] was assigned with malloc
Aufrufhierarchie:
   0x004243A7(=pythontest.exe:0x01:0233A7)
D:\projects\Python\Objects\dictobject.c#280
   0x004245C4(=pythontest.exe:0x01:0235C4)
D:\projects\Python\Objects\dictobject.c#370
   0x00436837(=pythontest.exe:0x01:035837)
D:\projects\Python\Objects\stringobject.c#1086
   0x00415CA9(=pythontest.exe:0x01:014CA9)
D:\projects\Python\Python\compile.c#249
   0x0043AC12(=pythontest.exe:0x01:039C12)
D:\projects\Python\Python\marshal.c#578
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504

------------------------------------------
Error 00083. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC9C) was never freed

Memory Block (0x014EFC9C) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411EE6(=pythontest.exe:0x01:010EE6)
D:\projects\Python\Objects\classobject.c#126
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00084. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC74) was never freed

Memory Block (0x014EFC74) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411ED6(=pythontest.exe:0x01:010ED6)
D:\projects\Python\Objects\classobject.c#125
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00085. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFC4C) was never freed

Memory Block (0x014EFC4C) [Size: 35 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411EC6(=pythontest.exe:0x01:010EC6)
D:\projects\Python\Objects\classobject.c#124
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00086. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14F19CC) was never freed

Memory Block (0x014F19CC) [Size: 47 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00431E97(=pythontest.exe:0x01:030E97)
D:\projects\Python\Objects\listobject.c#309
   0x0041137E(=pythontest.exe:0x01:01037E)
D:\projects\Python\Python\ceval.c#2512
   0x0040F906(=pythontest.exe:0x01:00E906)
D:\projects\Python\Python\ceval.c#1503
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324
   0x0042BAD4(=pythontest.exe:0x01:02AAD4)
D:\projects\Python\Python\import.c#485

------------------------------------------
Error 00087. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14F596C) was never freed

Memory Block (0x014F596C) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x0042CED6(=pythontest.exe:0x01:02BED6)
D:\projects\Python\Python\import.c#1513
   0x0042CD19(=pythontest.exe:0x01:02BD19)
D:\projects\Python\Python\import.c#1441
   0x0042CE6A(=pythontest.exe:0x01:02BE6A)
D:\projects\Python\Python\import.c#1489
   0x00409B32(=pythontest.exe:0x01:008B32)
D:\projects\Python\Python\bltinmodule.c#65

------------------------------------------
Error 00088. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EB870) was never freed

Memory Block (0x014EB870) [Size: 32 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043515A(=pythontest.exe:0x01:03415A)
D:\projects\Python\Objects\stringobject.c#95
   0x0043A8EB(=pythontest.exe:0x01:0398EB)
D:\projects\Python\Python\marshal.c#483
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB88(=pythontest.exe:0x01:039B88)
D:\projects\Python\Python\marshal.c#568
   0x0043A9A1(=pythontest.exe:0x01:0399A1)
D:\projects\Python\Python\marshal.c#504
   0x0043AB76(=pythontest.exe:0x01:039B76)
D:\projects\Python\Python\marshal.c#567

------------------------------------------
Error 00089. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EFBDC) was never freed

Memory Block (0x014EFBDC) [Size: 34 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x00411C9E(=pythontest.exe:0x01:010C9E)
D:\projects\Python\Objects\classobject.c#58
   0x004118FB(=pythontest.exe:0x01:0108FB)
D:\projects\Python\Python\ceval.c#2720
   0x0040EE08(=pythontest.exe:0x01:00DE08)
D:\projects\Python\Python\ceval.c#1167
   0x0040D597(=pythontest.exe:0x01:00C597)
D:\projects\Python\Python\ceval.c#324

------------------------------------------
Error 00090. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E74C4) was never freed

Memory Block (0x014E74C4) [Size: 988 Byte] was assigned with malloc
Aufrufhierarchie:
   0x00430B62(=pythontest.exe:0x01:02FB62)
D:\projects\Python\Objects\intobject.c#113
   0x00430BFD(=pythontest.exe:0x01:02FBFD)
D:\projects\Python\Objects\intobject.c#163
   0x0040C6FC(=pythontest.exe:0x01:00B6FC)
D:\projects\Python\Python\bltinmodule.c#2404
   0x0043C29A(=pythontest.exe:0x01:03B29A)
D:\projects\Python\Python\pythonrun.c#136
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00091. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14E96C4) was never freed

Memory Block (0x014E96C4) [Size: 174 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0042B0D9(=pythontest.exe:0x01:02A0D9) D:\projects\Python\PC\getpathp.c#403

   0x0042B2D5(=pythontest.exe:0x01:02A2D5) D:\projects\Python\PC\getpathp.c#508

   0x0043E40C(=pythontest.exe:0x01:03D40C)
D:\projects\Python\Python\sysmodule.c#413
   0x0043C2CA(=pythontest.exe:0x01:03B2CA)
D:\projects\Python\Python\pythonrun.c#142
   0x00402934(=pythontest.exe:0x01:001934)
G:\Projects\src\test\pythonmain.cpp#15
   0x3257DC12(=CC3250MT.DLL:0x01:07CC12)

------------------------------------------
Error 00092. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x14EF660) was never freed

Memory Block (0x014EF660) [Size: 36 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x00425400(=pythontest.exe:0x01:024400)
D:\projects\Python\Objects\dictobject.c#1084
   0x0042BA54(=pythontest.exe:0x01:02AA54)
D:\projects\Python\Python\import.c#466
   0x0042BF73(=pythontest.exe:0x01:02AF73)
D:\projects\Python\Python\import.c#724
   0x0042C876(=pythontest.exe:0x01:02B876)
D:\projects\Python\Python\import.c#1202
   0x0042D51E(=pythontest.exe:0x01:02C51E)
D:\projects\Python\Python\import.c#1755

------------------------------------------
Error 00093. 0x300010 (Thread 0x012D):
Resource-Leak: Memory Block (0x15211C8) was never freed

Memory Block (0x015211C8) [Size: 31 Byte] was assigned with malloc
Aufrufhierarchie:
   0x0043526B(=pythontest.exe:0x01:03426B)
D:\projects\Python\Objects\stringobject.c#145
   0x0043685E(=pythontest.exe:0x01:03585E)
D:\projects\Python\Objects\stringobject.c#1098
   0x004129EE(=pythontest.exe:0x01:0119EE)
D:\projects\Python\Objects\classobject.c#517
   0x004246DD(=pythontest.exe:0x01:0236DD)
D:\projects\Python\Objects\dictobject.c#419
   0x0042546E(=pythontest.exe:0x01:02446E)
D:\projects\Python\Objects\dictobject.c#1103
   0x0043DF2E(=pythontest.exe:0x01:03CF2E)
D:\projects\Python\Python\sysmodule.c#95

------------------------------------------
Aufgerufene Funktionen:
 delete (35 Mal)
 getchar (1 Mal)
 fflush (2 Mal)
 fputs (2 Mal)
 fwrite (2 Mal)
 vsprintf (2 Mal)
 strrchr (14 Mal)
 fclose (14 Mal)
 strspn (251 Mal)
 fread (2021 Mal)
 _fgetc (40 Mal)
 fstat (7 Mal)
 fopen (72 Mal)
 strncmp (19 Mal)
 strcmp (423 Mal)
 stat (21 Mal)
 strncpy (32 Mal)
 strchr (125 Mal)
 sprintf (2 Mal)
 memcmp (1349 Mal)
 memset (133 Mal)
 strcpy (834 Mal)
 strlen (784 Mal)
 SysFreeMem (87 Mal)
 SysGetMem (87 Mal)
 realloc (88 Mal)
 memcpy (837 Mal)
 delete[] (2 Mal)
 free (4936 Mal)
 new[] (14 Mal)
 new (40 Mal)
 calloc (5 Mal)
 malloc (4946 Mal)
Verwendete Resource-Arten:
 Datei-Stream (14 Allocs, 5 max)
 Datei-Handle (14 Allocs, 5 max)
 Objekt-Array (14 Allocs, 13 max)
 Objekt (40 Allocs, 28 max)
 Memory Block (5039 Allocs, 2448 max)
Verwendete Module:
 00400000 07/25/2000 01:06:08 G:\Projects\src\bin\pythontest.exe
 0CD00000 02/03/2000 06:00:00 g:\programme\borland\cbuilder5\bin\CG32.DLL
 201A0000 02/22/2000 05:20:00 C:\WINNT.45\TRAYHOOK.dll
 32500000 02/03/2000 06:00:00 G:\Projects\src\bin\CC3250MT.DLL
 40000000 02/03/2000 05:01:00 C:\WINNT.45\System32\VCL50.BPL
 41000000 02/03/2000 06:00:00 G:\Projects\src\bin\BORLNDMM.DLL
 52180000 08/09/1996 00:00:00 C:\WINNT.45\system32\version.dll
 61220000 12/07/1999 16:03:46 G:\Programme\Microsoft
 Hardware\Mouse\MSH_ZWF.dll
 65340000 02/18/2000 16:16:02 C:\WINNT.45\system32\oleaut32.dll
 70970000 05/09/1998 13:57:06 C:\WINNT.45\system32\SHELL32.dll
 70BD0000 03/18/1999 00:00:00 C:\WINNT.45\system32\SHLWAPI.dll
 71190000 07/22/1999 21:09:08 C:\WINNT.45\system32\MSIDLE.DLL
 71590000 03/18/1999 00:00:00 C:\WINNT.45\system32\COMCTL32.dll
 73060000 05/13/1999 12:05:00 C:\WINNT.45\System32\winspool.drv
 77660000 05/13/1999 12:05:00 C:\WINNT.45\System32\MSWSOCK.dll
 77666C35 05/13/1999 12:05:00 C:\WINNT.45\system32\wsock32.dll
 77690000 05/13/1999 12:05:00 C:\WINNT.45\system32\WS2HELP.dll
 776A0000 05/13/1999 12:05:00 C:\WINNT.45\system32\WS2_32.dll
 77710000 05/13/1999 12:05:00 C:\WINNT.45\system32\mpr.dll
 77920000 05/13/1999 12:05:00 C:\WINNT.45\System32\oledlg.dll
 779B0000 08/09/1996 00:00:00 C:\WINNT.45\system32\LZ32.dll
 77B80000 05/13/1999 12:05:00 C:\WINNT.45\system32\ole32.dll
 77D80000 05/13/1999 12:05:00 C:\WINNT.45\system32\comdlg32.dll
 77DC0000 05/13/1999 12:05:00 C:\WINNT.45\system32\ADVAPI32.dll
 77E10000 05/13/1999 12:05:00 C:\WINNT.45\system32\RPCRT4.dll
 77E70000 05/13/1999 12:05:00 C:\WINNT.45\system32\user32.dll
 77ED0000 05/13/1999 12:05:00 C:\WINNT.45\system32\GDI32.dll
 77F00000 05/13/1999 12:05:00 C:\WINNT.45\system32\kernel32.dll
 77F70000 05/13/1999 12:05:00 C:\WINNT.45\System32\ntdll.dll
 78000000 12/07/1999 05:00:00 C:\WINNT.45\system32\MSVCRT.dll
==========================================



Mark Hammond wrote:

> > I could reproduce the problem with Developer Studio 6.0.
> >
> > If anyone wants the project to test it - I can provide it.
>
> If you can repro the problem in just a few lines of C/C++ code but with no
> SWIG generated code, I would be interested.  Otherwise, I suggest you do
> some more work to narrow the problem down some more; as described, there is
> still too much work to be done to narrow down the problem to the cause for
> me to be interested (or anyone else given the feedback to date!)
>
> Mark.

--------------72A23DA082087CB843E12C92
Content-Type: text/x-vcard; charset=us-ascii;
 name="ingo.adler.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ingo Adler
Content-Disposition: attachment;
 filename="ingo.adler.vcf"

begin:vcard 
n:Adler;Ingo
tel;fax:+41-41-7103244
tel;work:+41-41-8111500
x-mozilla-html:FALSE
org:Synacon GmbH
adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland
version:2.1
email;internet:ingo.adler@synacon.ch
fn:Ingo Adler
end:vcard

--------------72A23DA082087CB843E12C92--



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
Actually, it's hard to say whether this is worth fixing...
Could it be a SWIG problem?
-------------------------------------------------------

Date: 2000-Sep-25 12:54
By: bwarsaw

Comment:
I don't believe there is a Python bug worth fixing here.  I've done some memory use testing with Python 2.0b2 using Insure++ on Linux, both with the regular interpreter, and with the small example embedded script given below.

There are "technical" memory leaks but they are almost all related to either leaks in the OS, or global memory still in use at the time Python exits.  An example of the former is leaks in strerror() - nothing we can do about that.  An example of the latter are leaks in the string intern dictionary, and we've already decided not to do anything about that.

There no identifiable chunks of memory leaked every time through the loop so I believe the problems reported below are either related to swig, have been fixed for Python 2.0, or are of the variety described above.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110681&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 21:37:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 13:37:20 -0700
Subject: [Python-bugs-list] [Bug #114923] ToolTip not showing text on AIX 4.3
Message-ID: <200009252037.NAA03843@bush.i.sourceforge.net>

Bug #114923, was updated on 2000-Sep-20 14:27
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: ToolTip not showing text on AIX 4.3

Details: IDLE0.6 runs nicely on AIX except that the tip text itself does not show when the pop up box appears. The box seems to be sized properly but is blank.

-Robin Friedrich

Follow-Ups:

Date: 2000-Sep-20 16:54
By: gvanrossum

Comment:
Could it be a Tcl version problem? It's hard to debug this... :-(
-------------------------------------------------------

Date: 2000-Sep-21 14:17
By: none

Comment:
Yes I imagine it will be hard to debug. The tclTk version is 8.3.2. I am unaware of problems with that on the X windows platforms. Has this been noticed on other unices with 2.0b1?  --Robin F.
-------------------------------------------------------

Date: 2000-Sep-21 14:23
By: gvanrossum

Comment:
BTW, where do you expect to see tooltips? The only place I can think of is when you type a function name followed by a left paren. Is that it? What function name did you use?

(And yes, this works fine for me on Linux.)

Could it have to do with font? color? Perhaps your window manager?
Source is in CallTipWindow.py if you want to play.
-------------------------------------------------------

Date: 2000-Sep-25 11:39
By: none

Comment:
The open paren binding yes. Any function like those in the string module.
OK I've played with CallTipWindow.py and the main() test routine exhibits the bug nicely. The code looks dead simple and should work. I can only blame Tk 8.3.2. I tried linking in our old Tk 8.0 libraries/headers (hoping Tkinter was still compatible with it) and the tooltip call now raises the following. We are using X/Motif with the CDE window manager.

>>> idle.CallTipWindow.main()
>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "./Lib/lib-tk/Tkinter.py", line 1283, in __call__
    args = apply(self.subst, args)
  File "./Lib/lib-tk/Tkinter.py", line 1053, in _substitute
    e.delta = getint(D)
ValueError: invalid literal for int(): D




-------------------------------------------------------

Date: 2000-Sep-25 12:41
By: gvanrossum

Comment:
The getint(D) problem is because earlier versions of Tkinter don't support the mousewheel delta value.

Try again with the current CVS version (or wait 1.5 days for Python 2.0b2 to be released). The getint(D) problem should be solved in the CVS version (a try/except is put around it).
-------------------------------------------------------

Date: 2000-Sep-25 13:37
By: none

Comment:
I tried to trap the error and go on but then the test still fails to show text in the tooltip window with 8.0 Tk. I'm kinda stumped at this point.   Do you know of any other AIX users which I could pester instead of you?

-Robin F.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114923&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 22:03:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 14:03:45 -0700
Subject: [Python-bugs-list] [Bug #115308] codecs base classes need documentation
Message-ID: <200009252103.OAA05004@bush.i.sourceforge.net>

Bug #115308, was updated on 2000-Sep-25 12:00
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: codecs base classes need documentation

Details: The documentation for the codecs module includes a note that base classes need to be implemented; this needs to happen for the 2.0 final release.

There should be some note at the top of the section about what the module is for -- Unicode is not mentioned, but that's the primary (expected) use.  Let's say something about that, and perhaps give examples at the end (especially for handling encoded files).

For the open() function, the docs refer to a "buffering" parameter, and say that it matches the meaning of the the same thing for the open() built-in.  It should be called "bufsize" to match the built-in documentation.

Follow-Ups:

Date: 2000-Sep-25 14:03
By: lemburg

Comment:
I'll try to write something up, but can't promise anything this
week. I that's a problem, you'll have to assign the bug
to someone else.

Note that the codecs.py module has extensive doc-string
documentation which can be used as basis.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115308&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 22:49:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 14:49:28 -0700
Subject: [Python-bugs-list] [Bug #114780] Rare hangs in w9xpopen.exe
Message-ID: <200009252149.OAA06803@bush.i.sourceforge.net>

Bug #114780, was updated on 2000-Sep-19 01:50
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Rare hangs in w9xpopen.exe

Details: Every two or three days, when I'm running the std test suite on my Win98SE box, test_popen2 just hangs.  wintop shows that w9xpopen.exe is alive, but not consuming any cycles.  test_popen2.py is waiting on a .read().

No other clues.  It *may* be the case that I'm establishing a modem connection near the time test_popen2 starts to run.  I'll try to provoke that.

Assigned to MarkH simply to share the misery <wink>.  Mark, I don't expect you to "fix this", but I don't expect me to either -- it's just something we should both be aware of.


Follow-Ups:

Date: 2000-Sep-19 05:51
By: gvanrossum

Comment:
Tim, do you remember the problem I had with using popen() from IDLE? I had code that essentially did os.popen("start "+url).close(). This worked fine in a DOS box but hung inexplicably for 30 seconds before returning and starting the browser when used in IDLE. The problem went away (the call returned immediately and the browser was started within 2-3 seconds) when I saved the pipe object in an instance variable. We never fixed this, but I tracked it down to probably something having to do with the need to pump events. Mark will understand. I don't doubt that popen2, popen3, popen4 all share this problem. (Check webbrowser.py, class WindowsDefault, for the current solution.)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114780&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 22:48:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 14:48:52 -0700
Subject: [Python-bugs-list] [Bug #114490] crash on empty module registry key
Message-ID: <200009252148.OAA06771@bush.i.sourceforge.net>

Bug #114490, was updated on 2000-Sep-15 00:31
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: crash on empty module registry key

Details: Having an empty module path key under the PythonPath Registry key lets Python die on startup.

Follow-Ups:

Date: 2000-Sep-15 00:40
By: tim_one

Comment:
Assigned to MarkH and boosted priority.

BobJuner, you didn't say which version of Python you're using.  If you can, please try it with a current snapshot from CVS:  MarkH very recently fixed something similar, and possibly similar enough to be identical.

-------------------------------------------------------

Date: 2000-Sep-16 14:29
By: BobJuner

Comment:
This occured to me using 2.0b1. I'll try a CVS snapshot during the next days.
-------------------------------------------------------

Date: 2000-Sep-16 15:40
By: mhammond

Comment:
Almost certainly a dupe of 113828 - as you have not produced a test case I can not be 100% sure this is the same bug, but am pretty close to that sure :-)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114490&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 23:06:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 15:06:39 -0700
Subject: [Python-bugs-list] [Bug #110674] memory bloat in binary file upload (PR#381)
Message-ID: <200009252206.PAA31813@delerium.i.sourceforge.net>

Bug #110674, was updated on 2000-Jul-31 14:13
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 4
Summary: memory bloat in binary file upload (PR#381)

Details: Jitterbug-Id: 381
Submitted-By: naris@ensim.com
Date: Mon,  3 Jul 2000 21:29:25 -0400 (EDT)
Version: 1.5.2
OS: RedHat 6.1


read_lines_to_outerboundary chews up memory.
there's a while (1) loop that does a readline(), which
is probably not good, as you could have a binary file that
doesn't have an endline til the end, and thus readline would
read the entire file into memory.  i did the following:
dd'd a 100MB /dev/zero file and used zope to upload it.
it chewed up a large amount of memory.

there seems to be bug reports about text files and windows
systems (and needing to use python -u), but this problem
is unrelated.  i am using a unix browser -> unix web server.



====================================================================
Audit trail:
Tue Jul 11 08:24:22 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-24 12:38
By: naris

Comment:
there's a bug i submitted to zope that deals with a second problem
with read_lines_to_outerboundary, which will also cause a memory
leak.

the read_lines_to_outerboundary has an unnecessary line 
self.lines.append(line).  removing will fix it this second problem.
-------------------------------------------------------

Date: 2000-Sep-25 15:06
By: bwarsaw

Comment:
Agreed that readlines() isn't the best thing to use in the face of large binary uploads.  I've added this feature request to PEP 42 (and am closing this bug report).

Removing self.lines might be more problematic, since although it's not documented as part of the public interface for FieldStorage, it is possible that existing code is using it, and that code would break.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110674&group_id=5470


From noreply@sourceforge.net  Mon Sep 25 23:07:33 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 15:07:33 -0700
Subject: [Python-bugs-list] [Bug #114780] Rare hangs in w9xpopen.exe
Message-ID: <200009252207.PAA31833@delerium.i.sourceforge.net>

Bug #114780, was updated on 2000-Sep-19 01:50
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: Rare hangs in w9xpopen.exe

Details: Every two or three days, when I'm running the std test suite on my Win98SE box, test_popen2 just hangs.  wintop shows that w9xpopen.exe is alive, but not consuming any cycles.  test_popen2.py is waiting on a .read().

No other clues.  It *may* be the case that I'm establishing a modem connection near the time test_popen2 starts to run.  I'll try to provoke that.

Assigned to MarkH simply to share the misery <wink>.  Mark, I don't expect you to "fix this", but I don't expect me to either -- it's just something we should both be aware of.


Follow-Ups:

Date: 2000-Sep-19 05:51
By: gvanrossum

Comment:
Tim, do you remember the problem I had with using popen() from IDLE? I had code that essentially did os.popen("start "+url).close(). This worked fine in a DOS box but hung inexplicably for 30 seconds before returning and starting the browser when used in IDLE. The problem went away (the call returned immediately and the browser was started within 2-3 seconds) when I saved the pipe object in an instance variable. We never fixed this, but I tracked it down to probably something having to do with the need to pump events. Mark will understand. I don't doubt that popen2, popen3, popen4 all share this problem. (Check webbrowser.py, class WindowsDefault, for the current solution.)
-------------------------------------------------------

Date: 2000-Sep-25 15:07
By: tim_one

Comment:
Just noting that I've been building and testing Python a *lot* since I entered this bug report, and haven't seen the problem again.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114780&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 02:59:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 18:59:52 -0700
Subject: [Python-bugs-list] [Bug #115323] limits.h should be included in one place only
Message-ID: <200009260159.SAA15676@bush.i.sourceforge.net>

Bug #115323, was updated on 2000-Sep-25 18:59
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Not a Bug
Priority: 6
Summary: limits.h should be included in one place only

Details: limits.h, where available, should be included in Python.h, not in a dozen different places all over the sources.

To be fixed immediately after 2.0b2 ships.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115323&group_id=5470


From nobody@sourceforge.net  Tue Sep 26 05:04:24 2000
From: nobody@sourceforge.net (Nobody)
Date: Mon, 25 Sep 2000 21:04:24 -0700
Subject: [Python-bugs-list] [Bug #115330] popen2 should use dup2() rather than dup().
Message-ID: <200009260404.VAA12457@delerium.i.sourceforge.net>

From: noreply@sourceforge.net

Bug #115330, was updated on 2000-Sep-25 21:04
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: popen2 should use dup2() rather than dup().


Details: Reason:

1. Simpler and less syscalls.
2. close() following fork() changes the std{in,out,err} to blocking mode
        unintentionally in FreeBSD's pthread library.
        dup2() doesn't change the mode.

Fix:

*** /usr/local/lib/python2.0/popen2.py  Tue Sep 26 12:34:40 2000
--- popen2.py   Tue Sep 26 12:42:22 2000
***************
*** 37,51 ****
          self.pid = os.fork()
          if self.pid == 0:
              # Child
!             os.close(0)
!             os.close(1)
!             if os.dup(p2cread) <> 0:
                  sys.stderr.write('popen2: bad read dup\n')
!             if os.dup(c2pwrite) <> 1:
                  sys.stderr.write('popen2: bad write dup\n')
              if capturestderr:
!                 os.close(2)
!                 if os.dup(errin) <> 2: pass
              for i in range(3, MAXFD):
                  try:
                      os.close(i)
--- 37,48 ----
          self.pid = os.fork()
          if self.pid == 0:
              # Child
!             if os.dup2(p2cread, 0) < 0:
                  sys.stderr.write('popen2: bad read dup\n')
!             if os.dup2(c2pwrite, 1) < 0:
                  sys.stderr.write('popen2: bad write dup\n')
              if capturestderr:
!                 if os.dup2(errin, 2) < 0: pass
              for i in range(3, MAXFD):
                  try:
                      os.close(i)


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115330&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 06:02:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 22:02:29 -0700
Subject: [Python-bugs-list] [Bug #115323] limits.h should be included in one place only
Message-ID: <200009260502.WAA21775@bush.i.sourceforge.net>

Bug #115323, was updated on 2000-Sep-25 18:59
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Not a Bug
Priority: 6
Summary: limits.h should be included in one place only

Details: limits.h, where available, should be included in Python.h, not in a dozen different places all over the sources.

To be fixed immediately after 2.0b2 ships.

Follow-Ups:

Date: 2000-Sep-25 22:02
By: fdrake

Comment:
Patch #101659 is a proposed fix.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115323&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 07:00:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Sep 2000 23:00:01 -0700
Subject: [Python-bugs-list] [Bug #115323] limits.h should be included in one place only
Message-ID: <200009260600.XAA23961@bush.i.sourceforge.net>

Bug #115323, was updated on 2000-Sep-25 18:59
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: Not a Bug
Priority: 6
Summary: limits.h should be included in one place only

Details: limits.h, where available, should be included in Python.h, not in a dozen different places all over the sources.

To be fixed immediately after 2.0b2 ships.

Follow-Ups:

Date: 2000-Sep-25 22:02
By: fdrake

Comment:
Patch #101659 is a proposed fix.
-------------------------------------------------------

Date: 2000-Sep-25 23:00
By: fdrake

Comment:
Checked in patch #101659 to fix this situation.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115323&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 08:21:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 00:21:29 -0700
Subject: [Python-bugs-list] [Bug #115338] 2.0b1.1 HTML docs: Contents/Module index problem
Message-ID: <200009260721.AAA26958@bush.i.sourceforge.net>

Bug #115338, was updated on 2000-Sep-26 00:21
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b1.1 HTML docs: Contents/Module index problem

Details: 1) The library reference page "lib.html" contains the "Contents" listing
2) The "Contents" listing ("contents.html") is empty.
3) The "Module index" button is not a link at the top of the "lib.html" file.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115338&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 08:28:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 00:28:40 -0700
Subject: [Python-bugs-list] [Bug #115338] 2.0b1.1 HTML docs: Contents/Module index problem
Message-ID: <200009260728.AAA27204@bush.i.sourceforge.net>

Bug #115338, was updated on 2000-Sep-26 00:21
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b1.1 HTML docs: Contents/Module index problem

Details: 1) The library reference page "lib.html" contains the "Contents" listing
2) The "Contents" listing ("contents.html") is empty.
3) The "Module index" button is not a link at the top of the "lib.html" file.

Follow-Ups:

Date: 2000-Sep-26 00:28
By: hooft

Comment:
4) The "module index" button is not a link at the top any library reference chapter. Only the one in the general index.html works so far.
5) See also closed bug #114294, which reports the same problem.
6) At the bottom of "about.html", there is a reference to "About this document".


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115338&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 09:43:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 01:43:48 -0700
Subject: [Python-bugs-list] [Bug #115341] Todays CVS python dumps core in gcmodule.c?!
Message-ID: <200009260843.BAA21806@delerium.i.sourceforge.net>

Bug #115341, was updated on 2000-Sep-26 01:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Todays CVS python dumps core in gcmodule.c?!

Details: While tracing a bug in my own code, I got a core dump from python.
Since it is extremely difficult to find out WHERE in my 58k lines of code this
happens,  I can't just make a small test case. I thought at this stage it might
be useful to report anyway.

no203[204]lehmann%3% gdb =python core        
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `/usr/local/nonius/bin/python /usr/local/nonius/app/gui/to
p.py new orient x.non'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libutil.so.1...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/stropmodule.so.
..done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/timemodule.so..
.done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/_tkinter.so...
done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/local/nonius/lib/libBLT24.so...done.
Reading symbols from /usr/local/nonius/lib/libtk8.3.so...done.
Reading symbols from /usr/local/nonius/lib/libtcl8.3.so...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/mathmodule.so..
.done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/md5module.so...
done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/multi
array.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/_nump
y.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/umath
.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/structmodule.so
...done.
Reading symbols from /usr/local/nonius/app/misc/linux/_ntoolsmodule.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/_socketmodule.s
o...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/cStringIO.so...
done.
Reading symbols from /lib/libnss_files.so.2...done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/lapac
k_lite.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/selectmodule.so
...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/gdbmmodule.so..
.done.
Reading symbols from /usr/lib/libgdbm.so.2...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/cPickle.so...
done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/ranli
b.so...done.
#0  update_refs (containers=0x80bfec0) at ./gcmodule.c:150
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
(gdb) where
#0  update_refs (containers=0x80bfec0) at ./gcmodule.c:150
#1  0x808ae9b in collect (young=0x80bfec0, old=0x80bfecc) at ./gcmodule.c:382
#2  0x808b0cc in collect_generations () at ./gcmodule.c:488
#3  0x808b10f in _PyGC_Insert (op=0x8703824) at ./gcmodule.c:507
#4  0x807fbe4 in PyTuple_New (size=3) at tupleobject.c:87
#5  0x80561df in eval_code2 (co=0x8260518, globals=0x823fcd4, locals=0x0, 
    args=0x824d258, argcount=2, kws=0x8780190, kwcount=5, defs=0x8268f50, 
    defcount=1, owner=0x82699e4) at ceval.c:1561
#6  0x8057e3b in call_function (func=0x8269a7c, arg=0x87616cc, kw=0x87743ac)
    at ceval.c:2744
#7  0x8057a4b in PyEval_CallObjectWithKeywords (func=0x87816bc, arg=0x87616cc, 
    kw=0x87743ac) at ceval.c:2588
#8  0x806df7b in PyInstance_New (class=0x82699e4, arg=0x87616cc, kw=0x87743ac)
    at classobject.c:463
#9  0x8057b51 in call_builtin (func=0x82699e4, arg=0x87616cc, kw=0x87743ac)
    at ceval.c:2625
#10 0x8057a58 in PyEval_CallObjectWithKeywords (func=0x82699e4, arg=0x87616cc, 
    kw=0x87743ac) at ceval.c:2590
#11 0x8056bab in eval_code2 (co=0x81f0c58, globals=0x8201b1c, locals=0x0, 
    args=0x875cd8c, argcount=2, kws=0x875cd94, kwcount=0, defs=0x8201248, 
    defcount=1, owner=0x81fe94c) at ceval.c:1923
#12 0x805687c in eval_code2 (co=0x81f2de8, globals=0x8201b1c, locals=0x0, 
    args=0x866e2b0, argcount=2, kws=0x866e2b8, kwcount=0, defs=0x0, 
---Type <return> to continue, or q <return> to quit---
    defcount=0, owner=0x8201a4c) at ceval.c:1822
#13 0x805687c in eval_code2 (co=0x81ef9d0, globals=0x8201b1c, locals=0x0, 
    args=0x8203314, argcount=2, kws=0x820331c, kwcount=0, defs=0x8201098, 
    defcount=1, owner=0x81f4e8c) at ceval.c:1822
#14 0x805687c in eval_code2 (co=0x83d1d10, globals=0x83d8044, locals=0x0, 
    args=0x8202840, argcount=2, kws=0x8202848, kwcount=0, defs=0x0, 
    defcount=0, owner=0x85fc974) at ceval.c:1822
#15 0x805687c in eval_code2 (co=0x83cff98, globals=0x83d8044, locals=0x0, 
    args=0x8202068, argcount=1, kws=0x820206c, kwcount=0, defs=0x0, 
    defcount=0, owner=0x85fc974) at ceval.c:1822
#16 0x805687c in eval_code2 (co=0x83af368, globals=0x83b2574, locals=0x0, 
    args=0x86134f0, argcount=2, kws=0x0, kwcount=0, defs=0x83b2120, 
    defcount=1, owner=0x83c8b8c) at ceval.c:1822
#17 0x8057e3b in call_function (func=0x83bcc7c, arg=0x860fcac, kw=0x0)
    at ceval.c:2744
#18 0x8057a4b in PyEval_CallObjectWithKeywords (func=0x8203194, arg=0x860fcac, 
    kw=0x0) at ceval.c:2588
#19 0x806df7b in PyInstance_New (class=0x85fc974, arg=0x860fcac, kw=0x0)
    at classobject.c:463
#20 0x8057b51 in call_builtin (func=0x85fc974, arg=0x860fcac, kw=0x0)
    at ceval.c:2625
#21 0x8057a58 in PyEval_CallObjectWithKeywords (func=0x85fc974, arg=0x860fcac, 
    kw=0x0) at ceval.c:2590
---Type <return> to continue, or q <return> to quit---
#22 0x8056bab in eval_code2 (co=0x8163568, globals=0x80caecc, locals=0x0, 
    args=0x80d562c, argcount=2, kws=0x80d5634, kwcount=0, defs=0x0, 
    defcount=0, owner=0x860e81c) at ceval.c:1923
#23 0x805687c in eval_code2 (co=0x810e8f8, globals=0x80caecc, 
    locals=0x80caecc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1822
#24 0x80545d7 in PyEval_EvalCode (co=0x810e8f8, globals=0x80caecc, 
    locals=0x80caecc) at ceval.c:319
#25 0x80660b4 in run_node (n=0x80d3cc8, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", globals=0x80caecc, 
    locals=0x80caecc) at pythonrun.c:886
#26 0x8066079 in run_err_node (n=0x80d3cc8, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", globals=0x80caecc, 
    locals=0x80caecc) at pythonrun.c:874
#27 0x8066057 in PyRun_FileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", start=257, 
    globals=0x80caecc, locals=0x80caecc, closeit=1) at pythonrun.c:866
#28 0x8065821 in PyRun_SimpleFileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", closeit=1)
    at pythonrun.c:579
#29 0x80654d0 in PyRun_AnyFileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", closeit=1)
    at pythonrun.c:459
---Type <return> to continue, or q <return> to quit---
#30 0x8051a40 in Py_Main (argc=4, argv=0xbffff814) at main.c:289
#31 0x8051566 in main (argc=5, argv=0xbffff814) at python.c:10
(gdb) 
(gdb) list
145     static void
146     update_refs(PyGC_Head *containers)
147     {
148             PyGC_Head *gc = containers->gc_next;
149             for (; gc != containers; gc=gc->gc_next) {
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
151             }
152     }
153
154     static int
(gdb) print gc
$1 = (PyGC_Head *) 0x0


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115341&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 11:46:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 03:46:19 -0700
Subject: [Python-bugs-list] [Bug #115330] popen2 should use dup2() rather than dup().
Message-ID: <200009261046.DAA01721@bush.i.sourceforge.net>

Bug #115330, was updated on 2000-Sep-25 21:04
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: popen2 should use dup2() rather than dup().

Details: Reason:

1. Simpler and less syscalls.
2. close() following fork() changes the std{in,out,err} to blocking mode
        unintentionally in FreeBSD's pthread library.
        dup2() doesn't change the mode.

Fix:

*** /usr/local/lib/python2.0/popen2.py  Tue Sep 26 12:34:40 2000
--- popen2.py   Tue Sep 26 12:42:22 2000
***************
*** 37,51 ****
          self.pid = os.fork()
          if self.pid == 0:
              # Child
!             os.close(0)
!             os.close(1)
!             if os.dup(p2cread) <> 0:
                  sys.stderr.write('popen2: bad read dup\n')
!             if os.dup(c2pwrite) <> 1:
                  sys.stderr.write('popen2: bad write dup\n')
              if capturestderr:
!                 os.close(2)
!                 if os.dup(errin) <> 2: pass
              for i in range(3, MAXFD):
                  try:
                      os.close(i)
--- 37,48 ----
          self.pid = os.fork()
          if self.pid == 0:
              # Child
!             if os.dup2(p2cread, 0) < 0:
                  sys.stderr.write('popen2: bad read dup\n')
!             if os.dup2(c2pwrite, 1) < 0:
                  sys.stderr.write('popen2: bad write dup\n')
              if capturestderr:
!                 if os.dup2(errin, 2) < 0: pass
              for i in range(3, MAXFD):
                  try:
                      os.close(i)


Follow-Ups:

Date: 2000-Sep-26 03:46
By: gvanrossum

Comment:
Assigned to Fred, since he's the popen2 guy :-)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115330&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 11:47:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 03:47:40 -0700
Subject: [Python-bugs-list] [Bug #115353] os.popen4() missing on Unix
Message-ID: <200009261047.DAA01742@bush.i.sourceforge.net>

Bug #115353, was updated on 2000-Sep-26 03:47
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: os.popen4() missing on Unix

Details: Fred, let's not forget to add popen4() -- right after the beta would be a good idea.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115353&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 11:50:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 03:50:16 -0700
Subject: [Python-bugs-list] [Bug #115353] os.popen4() missing on Unix
Message-ID: <200009261050.DAA01887@bush.i.sourceforge.net>

Bug #115353, was updated on 2000-Sep-26 03:47
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: os.popen4() missing on Unix

Details: Fred, let's not forget to add popen4() -- right after the beta would be a good idea.

Follow-Ups:

Date: 2000-Sep-26 03:50
By: gvanrossum

Comment:
(Or just before Jeremy gets up :-)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115353&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 12:28:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 04:28:43 -0700
Subject: [Python-bugs-list] [Bug #115338] 2.0b1.1 HTML docs: Contents/Module index problem
Message-ID: <200009261128.EAA03343@bush.i.sourceforge.net>

Bug #115338, was updated on 2000-Sep-26 00:21
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 2.0b1.1 HTML docs: Contents/Module index problem

Details: 1) The library reference page "lib.html" contains the "Contents" listing
2) The "Contents" listing ("contents.html") is empty.
3) The "Module index" button is not a link at the top of the "lib.html" file.

Follow-Ups:

Date: 2000-Sep-26 00:28
By: hooft

Comment:
4) The "module index" button is not a link at the top any library reference chapter. Only the one in the general index.html works so far.
5) See also closed bug #114294, which reports the same problem.
6) At the bottom of "about.html", there is a reference to "About this document".


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115338&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 12:31:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 04:31:35 -0700
Subject: [Python-bugs-list] [Bug #115341] Todays CVS python dumps core in gcmodule.c?!
Message-ID: <200009261131.EAA03491@bush.i.sourceforge.net>

Bug #115341, was updated on 2000-Sep-26 01:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 9
Summary: Todays CVS python dumps core in gcmodule.c?!

Details: While tracing a bug in my own code, I got a core dump from python.
Since it is extremely difficult to find out WHERE in my 58k lines of code this
happens,  I can't just make a small test case. I thought at this stage it might
be useful to report anyway.

no203[204]lehmann%3% gdb =python core        
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `/usr/local/nonius/bin/python /usr/local/nonius/app/gui/to
p.py new orient x.non'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libutil.so.1...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/stropmodule.so.
..done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/timemodule.so..
.done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/_tkinter.so...
done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/local/nonius/lib/libBLT24.so...done.
Reading symbols from /usr/local/nonius/lib/libtk8.3.so...done.
Reading symbols from /usr/local/nonius/lib/libtcl8.3.so...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/mathmodule.so..
.done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/md5module.so...
done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/multi
array.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/_nump
y.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/umath
.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/structmodule.so
...done.
Reading symbols from /usr/local/nonius/app/misc/linux/_ntoolsmodule.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/_socketmodule.s
o...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/cStringIO.so...
done.
Reading symbols from /lib/libnss_files.so.2...done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/lapac
k_lite.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/selectmodule.so
...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/gdbmmodule.so..
.done.
Reading symbols from /usr/lib/libgdbm.so.2...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/cPickle.so...
done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/ranli
b.so...done.
#0  update_refs (containers=0x80bfec0) at ./gcmodule.c:150
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
(gdb) where
#0  update_refs (containers=0x80bfec0) at ./gcmodule.c:150
#1  0x808ae9b in collect (young=0x80bfec0, old=0x80bfecc) at ./gcmodule.c:382
#2  0x808b0cc in collect_generations () at ./gcmodule.c:488
#3  0x808b10f in _PyGC_Insert (op=0x8703824) at ./gcmodule.c:507
#4  0x807fbe4 in PyTuple_New (size=3) at tupleobject.c:87
#5  0x80561df in eval_code2 (co=0x8260518, globals=0x823fcd4, locals=0x0, 
    args=0x824d258, argcount=2, kws=0x8780190, kwcount=5, defs=0x8268f50, 
    defcount=1, owner=0x82699e4) at ceval.c:1561
#6  0x8057e3b in call_function (func=0x8269a7c, arg=0x87616cc, kw=0x87743ac)
    at ceval.c:2744
#7  0x8057a4b in PyEval_CallObjectWithKeywords (func=0x87816bc, arg=0x87616cc, 
    kw=0x87743ac) at ceval.c:2588
#8  0x806df7b in PyInstance_New (class=0x82699e4, arg=0x87616cc, kw=0x87743ac)
    at classobject.c:463
#9  0x8057b51 in call_builtin (func=0x82699e4, arg=0x87616cc, kw=0x87743ac)
    at ceval.c:2625
#10 0x8057a58 in PyEval_CallObjectWithKeywords (func=0x82699e4, arg=0x87616cc, 
    kw=0x87743ac) at ceval.c:2590
#11 0x8056bab in eval_code2 (co=0x81f0c58, globals=0x8201b1c, locals=0x0, 
    args=0x875cd8c, argcount=2, kws=0x875cd94, kwcount=0, defs=0x8201248, 
    defcount=1, owner=0x81fe94c) at ceval.c:1923
#12 0x805687c in eval_code2 (co=0x81f2de8, globals=0x8201b1c, locals=0x0, 
    args=0x866e2b0, argcount=2, kws=0x866e2b8, kwcount=0, defs=0x0, 
---Type <return> to continue, or q <return> to quit---
    defcount=0, owner=0x8201a4c) at ceval.c:1822
#13 0x805687c in eval_code2 (co=0x81ef9d0, globals=0x8201b1c, locals=0x0, 
    args=0x8203314, argcount=2, kws=0x820331c, kwcount=0, defs=0x8201098, 
    defcount=1, owner=0x81f4e8c) at ceval.c:1822
#14 0x805687c in eval_code2 (co=0x83d1d10, globals=0x83d8044, locals=0x0, 
    args=0x8202840, argcount=2, kws=0x8202848, kwcount=0, defs=0x0, 
    defcount=0, owner=0x85fc974) at ceval.c:1822
#15 0x805687c in eval_code2 (co=0x83cff98, globals=0x83d8044, locals=0x0, 
    args=0x8202068, argcount=1, kws=0x820206c, kwcount=0, defs=0x0, 
    defcount=0, owner=0x85fc974) at ceval.c:1822
#16 0x805687c in eval_code2 (co=0x83af368, globals=0x83b2574, locals=0x0, 
    args=0x86134f0, argcount=2, kws=0x0, kwcount=0, defs=0x83b2120, 
    defcount=1, owner=0x83c8b8c) at ceval.c:1822
#17 0x8057e3b in call_function (func=0x83bcc7c, arg=0x860fcac, kw=0x0)
    at ceval.c:2744
#18 0x8057a4b in PyEval_CallObjectWithKeywords (func=0x8203194, arg=0x860fcac, 
    kw=0x0) at ceval.c:2588
#19 0x806df7b in PyInstance_New (class=0x85fc974, arg=0x860fcac, kw=0x0)
    at classobject.c:463
#20 0x8057b51 in call_builtin (func=0x85fc974, arg=0x860fcac, kw=0x0)
    at ceval.c:2625
#21 0x8057a58 in PyEval_CallObjectWithKeywords (func=0x85fc974, arg=0x860fcac, 
    kw=0x0) at ceval.c:2590
---Type <return> to continue, or q <return> to quit---
#22 0x8056bab in eval_code2 (co=0x8163568, globals=0x80caecc, locals=0x0, 
    args=0x80d562c, argcount=2, kws=0x80d5634, kwcount=0, defs=0x0, 
    defcount=0, owner=0x860e81c) at ceval.c:1923
#23 0x805687c in eval_code2 (co=0x810e8f8, globals=0x80caecc, 
    locals=0x80caecc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1822
#24 0x80545d7 in PyEval_EvalCode (co=0x810e8f8, globals=0x80caecc, 
    locals=0x80caecc) at ceval.c:319
#25 0x80660b4 in run_node (n=0x80d3cc8, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", globals=0x80caecc, 
    locals=0x80caecc) at pythonrun.c:886
#26 0x8066079 in run_err_node (n=0x80d3cc8, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", globals=0x80caecc, 
    locals=0x80caecc) at pythonrun.c:874
#27 0x8066057 in PyRun_FileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", start=257, 
    globals=0x80caecc, locals=0x80caecc, closeit=1) at pythonrun.c:866
#28 0x8065821 in PyRun_SimpleFileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", closeit=1)
    at pythonrun.c:579
#29 0x80654d0 in PyRun_AnyFileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", closeit=1)
    at pythonrun.c:459
---Type <return> to continue, or q <return> to quit---
#30 0x8051a40 in Py_Main (argc=4, argv=0xbffff814) at main.c:289
#31 0x8051566 in main (argc=5, argv=0xbffff814) at python.c:10
(gdb) 
(gdb) list
145     static void
146     update_refs(PyGC_Head *containers)
147     {
148             PyGC_Head *gc = containers->gc_next;
149             for (; gc != containers; gc=gc->gc_next) {
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
151             }
152     }
153
154     static int
(gdb) print gc
$1 = (PyGC_Head *) 0x0


Follow-Ups:

Date: 2000-Sep-26 04:31
By: gvanrossum

Comment:
Neil, can you have a look at this?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115341&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 13:31:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 05:31:28 -0700
Subject: [Python-bugs-list] [Bug #115357] ConfigParser feedback
Message-ID: <200009261231.FAA29921@delerium.i.sourceforge.net>

Bug #115357, was updated on 2000-Sep-26 05:31
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 1
Summary: ConfigParser feedback

Details: (I received this via email; the submitter doesn't seem to be interested in using SourceForge.)

From: "Todd R. Palmer" <todd.palmer@callcti.com>

1. ConfigParser chokes on sections headers with spaces (ie [Log File] ).  I 
know that these are vaild on MS Windows, and I'm pretty sure they are valid on Unix config files. It looks like just the regular expression needs to change for the headers (sorry I'm really bad at regex).

2. sections() returns all sections including the '__name__' key.  Should it?  It's pretty easy for us to skip, but it's just used internally.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115357&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 15:04:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 07:04:11 -0700
Subject: [Python-bugs-list] [Bug #115362] ConfigParser chokes on capitalization
Message-ID: <200009261404.HAA09299@bush.i.sourceforge.net>

Bug #115362, was updated on 2000-Sep-26 07:04
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: ConfigParser chokes on capitalization

Details: Apparantly, options are meant to be case-insensitive. They are not. Line 264 of the get function transforms the requested option using "option = self.optionxform(option)". The __read function does no transformation on options it reads in.

Demonstration: The following function is a simple introspector function for a ConfigParser():

def tree_config(cfg):
	sections = cfg.sections()
	for sct in sections:
		print sct
		options = cfg.options(sct)
		for opt in options:
			try:
				value = cfg.get(sct, opt)
			except:
				value = 'Error'
			print '\t', opt, '=', value

Try it on the following config file:
[SomeSection]
X = 1
Y = 2
Z = 3

The result is:

SomeSection
	X = Error
	Z = Error
	__name__ = SomeSection
	Y = Error

Resolution:

Insert "optname = self.optionxform(optname)" before line 442 
"cursect[optname] = optval"

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115362&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 15:23:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 07:23:26 -0700
Subject: [Python-bugs-list] [Bug #115362] ConfigParser chokes on capitalization
Message-ID: <200009261423.HAA01724@delerium.i.sourceforge.net>

Bug #115362, was updated on 2000-Sep-26 07:04
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: ConfigParser chokes on capitalization

Details: Apparantly, options are meant to be case-insensitive. They are not. Line 264 of the get function transforms the requested option using "option = self.optionxform(option)". The __read function does no transformation on options it reads in.

Demonstration: The following function is a simple introspector function for a ConfigParser():

def tree_config(cfg):
	sections = cfg.sections()
	for sct in sections:
		print sct
		options = cfg.options(sct)
		for opt in options:
			try:
				value = cfg.get(sct, opt)
			except:
				value = 'Error'
			print '\t', opt, '=', value

Try it on the following config file:
[SomeSection]
X = 1
Y = 2
Z = 3

The result is:

SomeSection
	X = Error
	Z = Error
	__name__ = SomeSection
	Y = Error

Resolution:

Insert "optname = self.optionxform(optname)" before line 442 
"cursect[optname] = optval"

Follow-Ups:

Date: 2000-Sep-26 07:23
By: gvanrossum

Comment:
Thanks - I just fixed this yeasterday. Wait for the release of 2.0b2 later today, or check out the CVS tree!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115362&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 15:40:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 07:40:23 -0700
Subject: [Python-bugs-list] [Bug #115338] 2.0b1.1 HTML docs: Contents/Module index problem
Message-ID: <200009261440.HAA10800@bush.i.sourceforge.net>

Bug #115338, was updated on 2000-Sep-26 00:21
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: 2.0b1.1 HTML docs: Contents/Module index problem

Details: 1) The library reference page "lib.html" contains the "Contents" listing
2) The "Contents" listing ("contents.html") is empty.
3) The "Module index" button is not a link at the top of the "lib.html" file.

Follow-Ups:

Date: 2000-Sep-26 00:28
By: hooft

Comment:
4) The "module index" button is not a link at the top any library reference chapter. Only the one in the general index.html works so far.
5) See also closed bug #114294, which reports the same problem.
6) At the bottom of "about.html", there is a reference to "About this document".


-------------------------------------------------------

Date: 2000-Sep-26 07:40
By: fdrake

Comment:
Already fixed in CVS and the upcoming 2.0b2 release.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115338&group_id=5470


From nascheme@enme.ucalgary.ca  Tue Sep 26 15:48:59 2000
From: nascheme@enme.ucalgary.ca (Neil Schemenauer)
Date: Tue, 26 Sep 2000 08:48:59 -0600
Subject: [Python-bugs-list] Re: [Bug #115341] Todays CVS python dumps core in gcmodule.c?!
In-Reply-To: <200009261131.EAA03491@bush.i.sourceforge.net>; from noreply@sourceforge.net on Tue, Sep 26, 2000 at 04:31:35AM -0700
References: <200009261131.EAA03491@bush.i.sourceforge.net>
Message-ID: <20000926084859.A4022@keymaster.enme.ucalgary.ca>

[Rob]
> Details: While tracing a bug in my own code, I got a core dump from
> python.  Since it is extremely difficult to find out WHERE in my 58k
> lines of code this happens,  I can't just make a small test case. I
> thought at this stage it might be useful to report anyway.

Can you try compiling Python with Py_DEBUG defined?  Also, calling
gc.set_debug(gc.DEBUG_LEAK) and gc.set_threshold(1) may help to trigger
the bug closer to the source of the problem.

[Guido]
> Neil, can you have a look at this?

Without being able to reproduce this its hard to do anything.  It looks
like a gc_next pointer is NULL.  I'll have to think really hard about it
some more. :)

  Neil


From noreply@sourceforge.net  Tue Sep 26 15:53:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 07:53:25 -0700
Subject: [Python-bugs-list] [Bug #115341] Todays CVS python dumps core in gcmodule.c?!
Message-ID: <200009261453.HAA11286@bush.i.sourceforge.net>

Bug #115341, was updated on 2000-Sep-26 01:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Todays CVS python dumps core in gcmodule.c?!

Details: While tracing a bug in my own code, I got a core dump from python.
Since it is extremely difficult to find out WHERE in my 58k lines of code this
happens,  I can't just make a small test case. I thought at this stage it might
be useful to report anyway.

no203[204]lehmann%3% gdb =python core        
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `/usr/local/nonius/bin/python /usr/local/nonius/app/gui/to
p.py new orient x.non'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libutil.so.1...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/stropmodule.so.
..done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/timemodule.so..
.done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/_tkinter.so...
done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/local/nonius/lib/libBLT24.so...done.
Reading symbols from /usr/local/nonius/lib/libtk8.3.so...done.
Reading symbols from /usr/local/nonius/lib/libtcl8.3.so...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/mathmodule.so..
.done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/md5module.so...
done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/multi
array.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/_nump
y.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/umath
.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/structmodule.so
...done.
Reading symbols from /usr/local/nonius/app/misc/linux/_ntoolsmodule.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/_socketmodule.s
o...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/cStringIO.so...
done.
Reading symbols from /lib/libnss_files.so.2...done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/lapac
k_lite.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/selectmodule.so
...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/gdbmmodule.so..
.done.
Reading symbols from /usr/lib/libgdbm.so.2...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/cPickle.so...
done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/ranli
b.so...done.
#0  update_refs (containers=0x80bfec0) at ./gcmodule.c:150
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
(gdb) where
#0  update_refs (containers=0x80bfec0) at ./gcmodule.c:150
#1  0x808ae9b in collect (young=0x80bfec0, old=0x80bfecc) at ./gcmodule.c:382
#2  0x808b0cc in collect_generations () at ./gcmodule.c:488
#3  0x808b10f in _PyGC_Insert (op=0x8703824) at ./gcmodule.c:507
#4  0x807fbe4 in PyTuple_New (size=3) at tupleobject.c:87
#5  0x80561df in eval_code2 (co=0x8260518, globals=0x823fcd4, locals=0x0, 
    args=0x824d258, argcount=2, kws=0x8780190, kwcount=5, defs=0x8268f50, 
    defcount=1, owner=0x82699e4) at ceval.c:1561
#6  0x8057e3b in call_function (func=0x8269a7c, arg=0x87616cc, kw=0x87743ac)
    at ceval.c:2744
#7  0x8057a4b in PyEval_CallObjectWithKeywords (func=0x87816bc, arg=0x87616cc, 
    kw=0x87743ac) at ceval.c:2588
#8  0x806df7b in PyInstance_New (class=0x82699e4, arg=0x87616cc, kw=0x87743ac)
    at classobject.c:463
#9  0x8057b51 in call_builtin (func=0x82699e4, arg=0x87616cc, kw=0x87743ac)
    at ceval.c:2625
#10 0x8057a58 in PyEval_CallObjectWithKeywords (func=0x82699e4, arg=0x87616cc, 
    kw=0x87743ac) at ceval.c:2590
#11 0x8056bab in eval_code2 (co=0x81f0c58, globals=0x8201b1c, locals=0x0, 
    args=0x875cd8c, argcount=2, kws=0x875cd94, kwcount=0, defs=0x8201248, 
    defcount=1, owner=0x81fe94c) at ceval.c:1923
#12 0x805687c in eval_code2 (co=0x81f2de8, globals=0x8201b1c, locals=0x0, 
    args=0x866e2b0, argcount=2, kws=0x866e2b8, kwcount=0, defs=0x0, 
---Type <return> to continue, or q <return> to quit---
    defcount=0, owner=0x8201a4c) at ceval.c:1822
#13 0x805687c in eval_code2 (co=0x81ef9d0, globals=0x8201b1c, locals=0x0, 
    args=0x8203314, argcount=2, kws=0x820331c, kwcount=0, defs=0x8201098, 
    defcount=1, owner=0x81f4e8c) at ceval.c:1822
#14 0x805687c in eval_code2 (co=0x83d1d10, globals=0x83d8044, locals=0x0, 
    args=0x8202840, argcount=2, kws=0x8202848, kwcount=0, defs=0x0, 
    defcount=0, owner=0x85fc974) at ceval.c:1822
#15 0x805687c in eval_code2 (co=0x83cff98, globals=0x83d8044, locals=0x0, 
    args=0x8202068, argcount=1, kws=0x820206c, kwcount=0, defs=0x0, 
    defcount=0, owner=0x85fc974) at ceval.c:1822
#16 0x805687c in eval_code2 (co=0x83af368, globals=0x83b2574, locals=0x0, 
    args=0x86134f0, argcount=2, kws=0x0, kwcount=0, defs=0x83b2120, 
    defcount=1, owner=0x83c8b8c) at ceval.c:1822
#17 0x8057e3b in call_function (func=0x83bcc7c, arg=0x860fcac, kw=0x0)
    at ceval.c:2744
#18 0x8057a4b in PyEval_CallObjectWithKeywords (func=0x8203194, arg=0x860fcac, 
    kw=0x0) at ceval.c:2588
#19 0x806df7b in PyInstance_New (class=0x85fc974, arg=0x860fcac, kw=0x0)
    at classobject.c:463
#20 0x8057b51 in call_builtin (func=0x85fc974, arg=0x860fcac, kw=0x0)
    at ceval.c:2625
#21 0x8057a58 in PyEval_CallObjectWithKeywords (func=0x85fc974, arg=0x860fcac, 
    kw=0x0) at ceval.c:2590
---Type <return> to continue, or q <return> to quit---
#22 0x8056bab in eval_code2 (co=0x8163568, globals=0x80caecc, locals=0x0, 
    args=0x80d562c, argcount=2, kws=0x80d5634, kwcount=0, defs=0x0, 
    defcount=0, owner=0x860e81c) at ceval.c:1923
#23 0x805687c in eval_code2 (co=0x810e8f8, globals=0x80caecc, 
    locals=0x80caecc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1822
#24 0x80545d7 in PyEval_EvalCode (co=0x810e8f8, globals=0x80caecc, 
    locals=0x80caecc) at ceval.c:319
#25 0x80660b4 in run_node (n=0x80d3cc8, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", globals=0x80caecc, 
    locals=0x80caecc) at pythonrun.c:886
#26 0x8066079 in run_err_node (n=0x80d3cc8, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", globals=0x80caecc, 
    locals=0x80caecc) at pythonrun.c:874
#27 0x8066057 in PyRun_FileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", start=257, 
    globals=0x80caecc, locals=0x80caecc, closeit=1) at pythonrun.c:866
#28 0x8065821 in PyRun_SimpleFileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", closeit=1)
    at pythonrun.c:579
#29 0x80654d0 in PyRun_AnyFileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", closeit=1)
    at pythonrun.c:459
---Type <return> to continue, or q <return> to quit---
#30 0x8051a40 in Py_Main (argc=4, argv=0xbffff814) at main.c:289
#31 0x8051566 in main (argc=5, argv=0xbffff814) at python.c:10
(gdb) 
(gdb) list
145     static void
146     update_refs(PyGC_Head *containers)
147     {
148             PyGC_Head *gc = containers->gc_next;
149             for (; gc != containers; gc=gc->gc_next) {
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
151             }
152     }
153
154     static int
(gdb) print gc
$1 = (PyGC_Head *) 0x0


Follow-Ups:

Date: 2000-Sep-26 04:31
By: gvanrossum

Comment:
Neil, can you have a look at this?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115341&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 16:14:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 08:14:00 -0700
Subject: [Python-bugs-list] [Bug #115357] ConfigParser feedback
Message-ID: <200009261514.IAA03727@delerium.i.sourceforge.net>

Bug #115357, was updated on 2000-Sep-26 05:31
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 1
Summary: ConfigParser feedback

Details: (I received this via email; the submitter doesn't seem to be interested in using SourceForge.)

From: "Todd R. Palmer" <todd.palmer@callcti.com>

1. ConfigParser chokes on sections headers with spaces (ie [Log File] ).  I 
know that these are vaild on MS Windows, and I'm pretty sure they are valid on Unix config files. It looks like just the regular expression needs to change for the headers (sorry I'm really bad at regex).

2. sections() returns all sections including the '__name__' key.  Should it?  It's pretty easy for us to skip, but it's just used internally.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115357&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 17:44:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 09:44:58 -0700
Subject: [Python-bugs-list] [Bug #115341] Todays CVS python dumps core in gcmodule.c?!
Message-ID: <200009261644.JAA07319@delerium.i.sourceforge.net>

Bug #115341, was updated on 2000-Sep-26 01:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Todays CVS python dumps core in gcmodule.c?!

Details: While tracing a bug in my own code, I got a core dump from python.
Since it is extremely difficult to find out WHERE in my 58k lines of code this
happens,  I can't just make a small test case. I thought at this stage it might
be useful to report anyway.

no203[204]lehmann%3% gdb =python core        
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `/usr/local/nonius/bin/python /usr/local/nonius/app/gui/to
p.py new orient x.non'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libutil.so.1...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/stropmodule.so.
..done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/timemodule.so..
.done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/_tkinter.so...
done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/local/nonius/lib/libBLT24.so...done.
Reading symbols from /usr/local/nonius/lib/libtk8.3.so...done.
Reading symbols from /usr/local/nonius/lib/libtcl8.3.so...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/mathmodule.so..
.done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/md5module.so...
done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/multi
array.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/_nump
y.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/umath
.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/structmodule.so
...done.
Reading symbols from /usr/local/nonius/app/misc/linux/_ntoolsmodule.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/_socketmodule.s
o...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/cStringIO.so...
done.
Reading symbols from /lib/libnss_files.so.2...done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/lapac
k_lite.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/selectmodule.so
...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/gdbmmodule.so..
.done.
Reading symbols from /usr/lib/libgdbm.so.2...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/cPickle.so...
done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/ranli
b.so...done.
#0  update_refs (containers=0x80bfec0) at ./gcmodule.c:150
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
(gdb) where
#0  update_refs (containers=0x80bfec0) at ./gcmodule.c:150
#1  0x808ae9b in collect (young=0x80bfec0, old=0x80bfecc) at ./gcmodule.c:382
#2  0x808b0cc in collect_generations () at ./gcmodule.c:488
#3  0x808b10f in _PyGC_Insert (op=0x8703824) at ./gcmodule.c:507
#4  0x807fbe4 in PyTuple_New (size=3) at tupleobject.c:87
#5  0x80561df in eval_code2 (co=0x8260518, globals=0x823fcd4, locals=0x0, 
    args=0x824d258, argcount=2, kws=0x8780190, kwcount=5, defs=0x8268f50, 
    defcount=1, owner=0x82699e4) at ceval.c:1561
#6  0x8057e3b in call_function (func=0x8269a7c, arg=0x87616cc, kw=0x87743ac)
    at ceval.c:2744
#7  0x8057a4b in PyEval_CallObjectWithKeywords (func=0x87816bc, arg=0x87616cc, 
    kw=0x87743ac) at ceval.c:2588
#8  0x806df7b in PyInstance_New (class=0x82699e4, arg=0x87616cc, kw=0x87743ac)
    at classobject.c:463
#9  0x8057b51 in call_builtin (func=0x82699e4, arg=0x87616cc, kw=0x87743ac)
    at ceval.c:2625
#10 0x8057a58 in PyEval_CallObjectWithKeywords (func=0x82699e4, arg=0x87616cc, 
    kw=0x87743ac) at ceval.c:2590
#11 0x8056bab in eval_code2 (co=0x81f0c58, globals=0x8201b1c, locals=0x0, 
    args=0x875cd8c, argcount=2, kws=0x875cd94, kwcount=0, defs=0x8201248, 
    defcount=1, owner=0x81fe94c) at ceval.c:1923
#12 0x805687c in eval_code2 (co=0x81f2de8, globals=0x8201b1c, locals=0x0, 
    args=0x866e2b0, argcount=2, kws=0x866e2b8, kwcount=0, defs=0x0, 
---Type <return> to continue, or q <return> to quit---
    defcount=0, owner=0x8201a4c) at ceval.c:1822
#13 0x805687c in eval_code2 (co=0x81ef9d0, globals=0x8201b1c, locals=0x0, 
    args=0x8203314, argcount=2, kws=0x820331c, kwcount=0, defs=0x8201098, 
    defcount=1, owner=0x81f4e8c) at ceval.c:1822
#14 0x805687c in eval_code2 (co=0x83d1d10, globals=0x83d8044, locals=0x0, 
    args=0x8202840, argcount=2, kws=0x8202848, kwcount=0, defs=0x0, 
    defcount=0, owner=0x85fc974) at ceval.c:1822
#15 0x805687c in eval_code2 (co=0x83cff98, globals=0x83d8044, locals=0x0, 
    args=0x8202068, argcount=1, kws=0x820206c, kwcount=0, defs=0x0, 
    defcount=0, owner=0x85fc974) at ceval.c:1822
#16 0x805687c in eval_code2 (co=0x83af368, globals=0x83b2574, locals=0x0, 
    args=0x86134f0, argcount=2, kws=0x0, kwcount=0, defs=0x83b2120, 
    defcount=1, owner=0x83c8b8c) at ceval.c:1822
#17 0x8057e3b in call_function (func=0x83bcc7c, arg=0x860fcac, kw=0x0)
    at ceval.c:2744
#18 0x8057a4b in PyEval_CallObjectWithKeywords (func=0x8203194, arg=0x860fcac, 
    kw=0x0) at ceval.c:2588
#19 0x806df7b in PyInstance_New (class=0x85fc974, arg=0x860fcac, kw=0x0)
    at classobject.c:463
#20 0x8057b51 in call_builtin (func=0x85fc974, arg=0x860fcac, kw=0x0)
    at ceval.c:2625
#21 0x8057a58 in PyEval_CallObjectWithKeywords (func=0x85fc974, arg=0x860fcac, 
    kw=0x0) at ceval.c:2590
---Type <return> to continue, or q <return> to quit---
#22 0x8056bab in eval_code2 (co=0x8163568, globals=0x80caecc, locals=0x0, 
    args=0x80d562c, argcount=2, kws=0x80d5634, kwcount=0, defs=0x0, 
    defcount=0, owner=0x860e81c) at ceval.c:1923
#23 0x805687c in eval_code2 (co=0x810e8f8, globals=0x80caecc, 
    locals=0x80caecc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1822
#24 0x80545d7 in PyEval_EvalCode (co=0x810e8f8, globals=0x80caecc, 
    locals=0x80caecc) at ceval.c:319
#25 0x80660b4 in run_node (n=0x80d3cc8, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", globals=0x80caecc, 
    locals=0x80caecc) at pythonrun.c:886
#26 0x8066079 in run_err_node (n=0x80d3cc8, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", globals=0x80caecc, 
    locals=0x80caecc) at pythonrun.c:874
#27 0x8066057 in PyRun_FileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", start=257, 
    globals=0x80caecc, locals=0x80caecc, closeit=1) at pythonrun.c:866
#28 0x8065821 in PyRun_SimpleFileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", closeit=1)
    at pythonrun.c:579
#29 0x80654d0 in PyRun_AnyFileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", closeit=1)
    at pythonrun.c:459
---Type <return> to continue, or q <return> to quit---
#30 0x8051a40 in Py_Main (argc=4, argv=0xbffff814) at main.c:289
#31 0x8051566 in main (argc=5, argv=0xbffff814) at python.c:10
(gdb) 
(gdb) list
145     static void
146     update_refs(PyGC_Head *containers)
147     {
148             PyGC_Head *gc = containers->gc_next;
149             for (; gc != containers; gc=gc->gc_next) {
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
151             }
152     }
153
154     static int
(gdb) print gc
$1 = (PyGC_Head *) 0x0


Follow-Ups:

Date: 2000-Sep-26 04:31
By: gvanrossum

Comment:
Neil, can you have a look at this?
-------------------------------------------------------

Date: 2000-Sep-26 09:44
By: nascheme

Comment:
Since I can't reproduce this bug here are some things to 
try:

- compile Python with Py_DEBUG defined
- compile Python with Py_DEBUG and without GC
- at the start of your application call
  gc.set_debug(gc.DEBUG_LEAK) and gc.set_threshold(1)
- at the start of your application disable GC with gc.disable()
- recompile your extension modules
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115341&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 17:45:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 09:45:54 -0700
Subject: [Python-bugs-list] [Bug #115341] Todays CVS python dumps core in gcmodule.c?!
Message-ID: <200009261645.JAA07364@delerium.i.sourceforge.net>

Bug #115341, was updated on 2000-Sep-26 01:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Todays CVS python dumps core in gcmodule.c?!

Details: While tracing a bug in my own code, I got a core dump from python.
Since it is extremely difficult to find out WHERE in my 58k lines of code this
happens,  I can't just make a small test case. I thought at this stage it might
be useful to report anyway.

no203[204]lehmann%3% gdb =python core        
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `/usr/local/nonius/bin/python /usr/local/nonius/app/gui/to
p.py new orient x.non'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libutil.so.1...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/stropmodule.so.
..done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/timemodule.so..
.done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/_tkinter.so...
done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/local/nonius/lib/libBLT24.so...done.
Reading symbols from /usr/local/nonius/lib/libtk8.3.so...done.
Reading symbols from /usr/local/nonius/lib/libtcl8.3.so...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/mathmodule.so..
.done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/md5module.so...
done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/multi
array.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/_nump
y.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/umath
.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/structmodule.so
...done.
Reading symbols from /usr/local/nonius/app/misc/linux/_ntoolsmodule.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/_socketmodule.s
o...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/cStringIO.so...
done.
Reading symbols from /lib/libnss_files.so.2...done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/lapac
k_lite.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/selectmodule.so
...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/gdbmmodule.so..
.done.
Reading symbols from /usr/lib/libgdbm.so.2...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/cPickle.so...
done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/ranli
b.so...done.
#0  update_refs (containers=0x80bfec0) at ./gcmodule.c:150
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
(gdb) where
#0  update_refs (containers=0x80bfec0) at ./gcmodule.c:150
#1  0x808ae9b in collect (young=0x80bfec0, old=0x80bfecc) at ./gcmodule.c:382
#2  0x808b0cc in collect_generations () at ./gcmodule.c:488
#3  0x808b10f in _PyGC_Insert (op=0x8703824) at ./gcmodule.c:507
#4  0x807fbe4 in PyTuple_New (size=3) at tupleobject.c:87
#5  0x80561df in eval_code2 (co=0x8260518, globals=0x823fcd4, locals=0x0, 
    args=0x824d258, argcount=2, kws=0x8780190, kwcount=5, defs=0x8268f50, 
    defcount=1, owner=0x82699e4) at ceval.c:1561
#6  0x8057e3b in call_function (func=0x8269a7c, arg=0x87616cc, kw=0x87743ac)
    at ceval.c:2744
#7  0x8057a4b in PyEval_CallObjectWithKeywords (func=0x87816bc, arg=0x87616cc, 
    kw=0x87743ac) at ceval.c:2588
#8  0x806df7b in PyInstance_New (class=0x82699e4, arg=0x87616cc, kw=0x87743ac)
    at classobject.c:463
#9  0x8057b51 in call_builtin (func=0x82699e4, arg=0x87616cc, kw=0x87743ac)
    at ceval.c:2625
#10 0x8057a58 in PyEval_CallObjectWithKeywords (func=0x82699e4, arg=0x87616cc, 
    kw=0x87743ac) at ceval.c:2590
#11 0x8056bab in eval_code2 (co=0x81f0c58, globals=0x8201b1c, locals=0x0, 
    args=0x875cd8c, argcount=2, kws=0x875cd94, kwcount=0, defs=0x8201248, 
    defcount=1, owner=0x81fe94c) at ceval.c:1923
#12 0x805687c in eval_code2 (co=0x81f2de8, globals=0x8201b1c, locals=0x0, 
    args=0x866e2b0, argcount=2, kws=0x866e2b8, kwcount=0, defs=0x0, 
---Type <return> to continue, or q <return> to quit---
    defcount=0, owner=0x8201a4c) at ceval.c:1822
#13 0x805687c in eval_code2 (co=0x81ef9d0, globals=0x8201b1c, locals=0x0, 
    args=0x8203314, argcount=2, kws=0x820331c, kwcount=0, defs=0x8201098, 
    defcount=1, owner=0x81f4e8c) at ceval.c:1822
#14 0x805687c in eval_code2 (co=0x83d1d10, globals=0x83d8044, locals=0x0, 
    args=0x8202840, argcount=2, kws=0x8202848, kwcount=0, defs=0x0, 
    defcount=0, owner=0x85fc974) at ceval.c:1822
#15 0x805687c in eval_code2 (co=0x83cff98, globals=0x83d8044, locals=0x0, 
    args=0x8202068, argcount=1, kws=0x820206c, kwcount=0, defs=0x0, 
    defcount=0, owner=0x85fc974) at ceval.c:1822
#16 0x805687c in eval_code2 (co=0x83af368, globals=0x83b2574, locals=0x0, 
    args=0x86134f0, argcount=2, kws=0x0, kwcount=0, defs=0x83b2120, 
    defcount=1, owner=0x83c8b8c) at ceval.c:1822
#17 0x8057e3b in call_function (func=0x83bcc7c, arg=0x860fcac, kw=0x0)
    at ceval.c:2744
#18 0x8057a4b in PyEval_CallObjectWithKeywords (func=0x8203194, arg=0x860fcac, 
    kw=0x0) at ceval.c:2588
#19 0x806df7b in PyInstance_New (class=0x85fc974, arg=0x860fcac, kw=0x0)
    at classobject.c:463
#20 0x8057b51 in call_builtin (func=0x85fc974, arg=0x860fcac, kw=0x0)
    at ceval.c:2625
#21 0x8057a58 in PyEval_CallObjectWithKeywords (func=0x85fc974, arg=0x860fcac, 
    kw=0x0) at ceval.c:2590
---Type <return> to continue, or q <return> to quit---
#22 0x8056bab in eval_code2 (co=0x8163568, globals=0x80caecc, locals=0x0, 
    args=0x80d562c, argcount=2, kws=0x80d5634, kwcount=0, defs=0x0, 
    defcount=0, owner=0x860e81c) at ceval.c:1923
#23 0x805687c in eval_code2 (co=0x810e8f8, globals=0x80caecc, 
    locals=0x80caecc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1822
#24 0x80545d7 in PyEval_EvalCode (co=0x810e8f8, globals=0x80caecc, 
    locals=0x80caecc) at ceval.c:319
#25 0x80660b4 in run_node (n=0x80d3cc8, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", globals=0x80caecc, 
    locals=0x80caecc) at pythonrun.c:886
#26 0x8066079 in run_err_node (n=0x80d3cc8, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", globals=0x80caecc, 
    locals=0x80caecc) at pythonrun.c:874
#27 0x8066057 in PyRun_FileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", start=257, 
    globals=0x80caecc, locals=0x80caecc, closeit=1) at pythonrun.c:866
#28 0x8065821 in PyRun_SimpleFileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", closeit=1)
    at pythonrun.c:579
#29 0x80654d0 in PyRun_AnyFileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", closeit=1)
    at pythonrun.c:459
---Type <return> to continue, or q <return> to quit---
#30 0x8051a40 in Py_Main (argc=4, argv=0xbffff814) at main.c:289
#31 0x8051566 in main (argc=5, argv=0xbffff814) at python.c:10
(gdb) 
(gdb) list
145     static void
146     update_refs(PyGC_Head *containers)
147     {
148             PyGC_Head *gc = containers->gc_next;
149             for (; gc != containers; gc=gc->gc_next) {
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
151             }
152     }
153
154     static int
(gdb) print gc
$1 = (PyGC_Head *) 0x0


Follow-Ups:

Date: 2000-Sep-26 04:31
By: gvanrossum

Comment:
Neil, can you have a look at this?
-------------------------------------------------------

Date: 2000-Sep-26 09:44
By: nascheme

Comment:
Since I can't reproduce this bug here are some things to 
try:

- compile Python with Py_DEBUG defined
- compile Python with Py_DEBUG and without GC
- at the start of your application call
  gc.set_debug(gc.DEBUG_LEAK) and gc.set_threshold(1)
- at the start of your application disable GC with gc.disable()
- recompile your extension modules
-------------------------------------------------------

Date: 2000-Sep-26 09:45
By: nascheme

Comment:
Since I can't reproduce this bug here are some things to 
try:

- compile Python with Py_DEBUG defined
- compile Python with Py_DEBUG and without GC
- at the start of your application call
  gc.set_debug(gc.DEBUG_LEAK) and gc.set_threshold(1)
- at the start of your application disable GC with gc.disable()
- recompile your extension modules
- checkout Python from a few days ago (cvs -D option)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115341&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 20:13:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 12:13:13 -0700
Subject: [Python-bugs-list] [Bug #115392] Build under SunOS 4.1.4_JL fails
Message-ID: <200009261913.MAA21639@bush.i.sourceforge.net>

Bug #115392, was updated on 2000-Sep-26 12:13
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Build under SunOS 4.1.4_JL fails

Details: The linkage of the python executable fails under SunOS 4.1.4_JL since
LDFLAGS in Modules/Makefile is defined as:

  LDFLAGS = -L

That is, no value of the -L option is specified.  This definition seems
to be generated by the configure script.  The same problem raises even
though a explicit definition of LDFLAGS is given when the configure
script is invoked, as shown below:

  $ env LDFLAGS='' ./configure

(In fact, no -L options are needed for my configuration, so the linkage
is successfully done by running make LDFLAGS='').

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115392&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 20:18:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 12:18:56 -0700
Subject: [Python-bugs-list] [Bug #115392] Build under SunOS 4.1.4_JL fails
Message-ID: <200009261918.MAA21859@bush.i.sourceforge.net>

Bug #115392, was updated on 2000-Sep-26 12:13
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Build under SunOS 4.1.4_JL fails

Details: The linkage of the python executable fails under SunOS 4.1.4_JL since
LDFLAGS in Modules/Makefile is defined as:

  LDFLAGS = -L

That is, no value of the -L option is specified.  This definition seems
to be generated by the configure script.  The same problem raises even
though a explicit definition of LDFLAGS is given when the configure
script is invoked, as shown below:

  $ env LDFLAGS='' ./configure

(In fact, no -L options are needed for my configuration, so the linkage
is successfully done by running make LDFLAGS='').

Follow-Ups:

Date: 2000-Sep-26 12:18
By: kajiyama

Comment:
I forgot to give the version: 2.0b1, of course :-)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115392&group_id=5470


From noreply@sourceforge.net  Tue Sep 26 20:38:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Sep 2000 12:38:05 -0700
Subject: [Python-bugs-list] [Bug #115392] Build under SunOS 4.1.4_JL fails
Message-ID: <200009261938.MAA22613@bush.i.sourceforge.net>

Bug #115392, was updated on 2000-Sep-26 12:13
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 4
Summary: Build under SunOS 4.1.4_JL fails

Details: The linkage of the python executable fails under SunOS 4.1.4_JL since
LDFLAGS in Modules/Makefile is defined as:

  LDFLAGS = -L

That is, no value of the -L option is specified.  This definition seems
to be generated by the configure script.  The same problem raises even
though a explicit definition of LDFLAGS is given when the configure
script is invoked, as shown below:

  $ env LDFLAGS='' ./configure

(In fact, no -L options are needed for my configuration, so the linkage
is successfully done by running make LDFLAGS='').

Follow-Ups:

Date: 2000-Sep-26 12:18
By: kajiyama

Comment:
I forgot to give the version: 2.0b1, of course :-)
-------------------------------------------------------

Date: 2000-Sep-26 12:38
By: fdrake

Comment:
Assigned to Barry since he's the GNUish guy, and he should know enough autoconf to fix this.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115392&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 09:54:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 01:54:19 -0700
Subject: [Python-bugs-list] [Bug #115469] test_socket hangs on Debian Linux 2.2
Message-ID: <200009270854.BAA09453@delerium.i.sourceforge.net>

Bug #115469, was updated on 2000-Sep-27 01:54
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_socket hangs on Debian Linux 2.2

Details: The test runs until it prints "child connecting" and then just hangs. Pressing C-c causes a traceback that points at the
s.accept() call in line 105.

uname -a says
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686  unknown

ldd python says
libdl.so.2 => /lib/libdl.so.2 (0x4001a000)
libm.so.6 => /lib/libm.so.6 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x4003b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

This bug is probably related to 115221.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115469&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 11:38:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 03:38:51 -0700
Subject: [Python-bugs-list] [Bug #110674] memory bloat in binary file upload (PR#381)
Message-ID: <200009271038.DAA21698@bush.i.sourceforge.net>

Bug #110674, was updated on 2000-Jul-31 14:13
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 4
Summary: memory bloat in binary file upload (PR#381)

Details: Jitterbug-Id: 381
Submitted-By: naris@ensim.com
Date: Mon,  3 Jul 2000 21:29:25 -0400 (EDT)
Version: 1.5.2
OS: RedHat 6.1


read_lines_to_outerboundary chews up memory.
there's a while (1) loop that does a readline(), which
is probably not good, as you could have a binary file that
doesn't have an endline til the end, and thus readline would
read the entire file into memory.  i did the following:
dd'd a 100MB /dev/zero file and used zope to upload it.
it chewed up a large amount of memory.

there seems to be bug reports about text files and windows
systems (and needing to use python -u), but this problem
is unrelated.  i am using a unix browser -> unix web server.



====================================================================
Audit trail:
Tue Jul 11 08:24:22 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-24 12:38
By: naris

Comment:
there's a bug i submitted to zope that deals with a second problem
with read_lines_to_outerboundary, which will also cause a memory
leak.

the read_lines_to_outerboundary has an unnecessary line 
self.lines.append(line).  removing will fix it this second problem.
-------------------------------------------------------

Date: 2000-Sep-25 15:06
By: bwarsaw

Comment:
Agreed that readlines() isn't the best thing to use in the face of large binary uploads.  I've added this feature request to PEP 42 (and am closing this bug report).

Removing self.lines might be more problematic, since although it's not documented as part of the public interface for FieldStorage, it is possible that existing code is using it, and that code would break.
-------------------------------------------------------

Date: 2000-Sep-27 03:38
By: naris

Comment:
i feel the self.lines.append() is is a pretty serious problem...have you got any
second opinions on how to proceed?

if its not part of the public interface for FieldStorage, then wouldn't it be somewhat safe to remove it (you might anger some people, but they could always stick to using the old cgi.py)?

my argument is that if they changed the socket connect/bind functions to reject connect(host,port) in favor of connect((host,port)), then we should certainly be able to remove this self.lines.append() :-)

what do you think?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110674&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 13:26:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 05:26:32 -0700
Subject: [Python-bugs-list] [Bug #115476] Python-2.0b2 is incompatible with readline version 2
Message-ID: <200009271226.FAA25494@bush.i.sourceforge.net>

Bug #115476, was updated on 2000-Sep-27 05:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Python-2.0b2 is incompatible with readline version 2

Details: Python-2.0b2 is now incompatible with GNU readline version 2. This is new, Python-2.0b1 worked fine with it. The only reason that it is incompatible is that it is trying to read the symbol rl_library_version. I suggest this code is simply removed again.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115476&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 17:28:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 09:28:42 -0700
Subject: [Python-bugs-list] [Bug #115487] Windows installer not logo compliant
Message-ID: <200009271628.JAA02206@bush.i.sourceforge.net>

Bug #115487, was updated on 2000-Sep-27 09:28
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Windows installer not logo compliant

Details: Python 2.0b2 is not Windows 2000 Logo compliant. I noticed the following problems:

Installer does not use the Microsoft Windows Installer Service [2.1]

Installer does not install into "Program Files" by default [2.4]

Installer does not create new Uninstall registry entries: [2.5]
InstallLocation, Publisher, VersionMajor, VersionMinor

Installer does not support advertising [2.6]

IDLE does not default to My Documents when saving files [4.1]

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115487&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 18:09:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 10:09:29 -0700
Subject: [Python-bugs-list] [Bug #115392] Build under SunOS 4.1.4_JL fails
Message-ID: <200009271709.KAA27963@delerium.i.sourceforge.net>

Bug #115392, was updated on 2000-Sep-26 12:13
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Summary: Build under SunOS 4.1.4_JL fails

Details: The linkage of the python executable fails under SunOS 4.1.4_JL since
LDFLAGS in Modules/Makefile is defined as:

  LDFLAGS = -L

That is, no value of the -L option is specified.  This definition seems
to be generated by the configure script.  The same problem raises even
though a explicit definition of LDFLAGS is given when the configure
script is invoked, as shown below:

  $ env LDFLAGS='' ./configure

(In fact, no -L options are needed for my configuration, so the linkage
is successfully done by running make LDFLAGS='').

Follow-Ups:

Date: 2000-Sep-26 12:18
By: kajiyama

Comment:
I forgot to give the version: 2.0b1, of course :-)
-------------------------------------------------------

Date: 2000-Sep-26 12:38
By: fdrake

Comment:
Assigned to Barry since he's the GNUish guy, and he should know enough autoconf to fix this.
-------------------------------------------------------

Date: 2000-Sep-27 10:09
By: loewis

Comment:
The bug is caused by the configure.in fragment

    if test -d "$with_threads"
    then LDFLAGS="$LDFLAGS -L$with_threads"
    fi

with_threads is empty, yet the test whether it is a directory(!) succeeds.

It appears that 'test -d' must be replaced with 'test -n' in many places in configure.in; bumped priority so this gets attention.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115392&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 18:40:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 10:40:42 -0700
Subject: [Python-bugs-list] [Bug #115487] Windows installer not logo compliant
Message-ID: <200009271740.KAA05001@bush.i.sourceforge.net>

Bug #115487, was updated on 2000-Sep-27 09:28
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Windows installer not logo compliant

Details: Python 2.0b2 is not Windows 2000 Logo compliant. I noticed the following problems:

Installer does not use the Microsoft Windows Installer Service [2.1]

Installer does not install into "Program Files" by default [2.4]

Installer does not create new Uninstall registry entries: [2.5]
InstallLocation, Publisher, VersionMajor, VersionMinor

Installer does not support advertising [2.6]

IDLE does not default to My Documents when saving files [4.1]

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115487&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 18:41:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 10:41:57 -0700
Subject: [Python-bugs-list] [Bug #115469] test_socket hangs on Debian Linux 2.2
Message-ID: <200009271741.KAA05143@bush.i.sourceforge.net>

Bug #115469, was updated on 2000-Sep-27 01:54
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_socket hangs on Debian Linux 2.2

Details: The test runs until it prints "child connecting" and then just hangs. Pressing C-c causes a traceback that points at the
s.accept() call in line 105.

uname -a says
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686  unknown

ldd python says
libdl.so.2 => /lib/libdl.so.2 (0x4001a000)
libm.so.6 => /lib/libm.so.6 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x4003b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

This bug is probably related to 115221.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115469&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 18:42:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 10:42:05 -0700
Subject: [Python-bugs-list] [Bug #115469] test_socket hangs on Debian Linux 2.2
Message-ID: <200009271742.KAA05146@bush.i.sourceforge.net>

Bug #115469, was updated on 2000-Sep-27 01:54
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: test_socket hangs on Debian Linux 2.2

Details: The test runs until it prints "child connecting" and then just hangs. Pressing C-c causes a traceback that points at the
s.accept() call in line 105.

uname -a says
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686  unknown

ldd python says
libdl.so.2 => /lib/libdl.so.2 (0x4001a000)
libm.so.6 => /lib/libm.so.6 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x4003b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

This bug is probably related to 115221.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115469&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 18:52:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 10:52:38 -0700
Subject: [Python-bugs-list] [Bug #115476] Python-2.0b2 is incompatible with readline version 2
Message-ID: <200009271752.KAA29673@delerium.i.sourceforge.net>

Bug #115476, was updated on 2000-Sep-27 05:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: Python-2.0b2 is incompatible with readline version 2

Details: Python-2.0b2 is now incompatible with GNU readline version 2. This is new, Python-2.0b1 worked fine with it. The only reason that it is incompatible is that it is trying to read the symbol rl_library_version. I suggest this code is simply removed again.


Follow-Ups:

Date: 2000-Sep-27 10:52
By: jhylton

Comment:
The uses of rl_library_version was added a week ago after a suggestion by jpettit.  Need to resolve this for old issues of readline.

Question for jribbens: How unreasonable would it be to require readline 3 or later?  readline ver. 2 is more than three years old.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115476&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 18:58:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 10:58:03 -0700
Subject: [Python-bugs-list] [Bug #115221] test_poll hangs on Debian Linux 2.2
Message-ID: <200009271758.KAA29892@delerium.i.sourceforge.net>

Bug #115221, was updated on 2000-Sep-24 07:38
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_poll hangs on Debian Linux 2.2

Details: When run from the command-line test_poll.py prints
"This is a test." 12 times and then hangs, without ever printing "Poll test 1 complete".

All other tests seem to work just fine.

Follow-Ups:

Date: 2000-Sep-27 10:58
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 system running Linux
 2.2.16.  Can you give the output from "uname -a" and "dpkg 
-l libc6"?  I am using libc6 2.1.3-13.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115221&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 19:04:54 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 11:04:54 -0700
Subject: [Python-bugs-list] [Bug #115469] test_socket hangs on Debian Linux 2.2
Message-ID: <200009271804.LAA30120@delerium.i.sourceforge.net>

Bug #115469, was updated on 2000-Sep-27 01:54
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: test_socket hangs on Debian Linux 2.2

Details: The test runs until it prints "child connecting" and then just hangs. Pressing C-c causes a traceback that points at the
s.accept() call in line 105.

uname -a says
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686  unknown

ldd python says
libdl.so.2 => /lib/libdl.so.2 (0x4001a000)
libm.so.6 => /lib/libm.so.6 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x4003b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

This bug is probably related to 115221.

Follow-Ups:

Date: 2000-Sep-27 11:04
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 machine running 
Linux 2.2.16.  Which libc6 are you using (dpkg -l libc6)?  
Also, it is possible that something is wrong with the loopback network.  The output from "netstat -tnp; ifconfig lo" taken during the hang may be helpful
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115469&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 19:22:23 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 11:22:23 -0700
Subject: [Python-bugs-list] [Bug #115491] 2.0b2:test_unicodedata fails: Sparc Solaris 2.7/6
Message-ID: <200009271822.LAA30856@delerium.i.sourceforge.net>

Bug #115491, was updated on 2000-Sep-27 11:22
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: 2.0b2:test_unicodedata fails: Sparc Solaris 2.7/6

Details: Sparc Solaris 2.7
gcc 2.95.2
test_methods sha hexdigest output does not match expected results. 

Note: test_unicodedata.py script differs on windows version of 2.0b2 (is same as version supplied with
unix source 2.0b1). 

Sorry if this has already been reported. Did not see in current bug list. 

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115491&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 19:45:12 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 11:45:12 -0700
Subject: [Python-bugs-list] [Bug #115492] 1 test failed: test_unicodedata
Message-ID: <200009271845.LAA07504@bush.i.sourceforge.net>

Bug #115492, was updated on 2000-Sep-27 11:45
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: 1 test failed: test_unicodedata

Details: Running the self-test ("make test") for 2.0b2 under

$ uname -a
SunOS jimi 5.6 Generic_105181-17 sun4u sparc SUNW,Ultra-5_10

...
test_unicodedata
test test_unicodedata failed -- Writing: 'e052289ecef97fc89c794cf663cb74a64631d34e', expected: 'b886
84df19fca8c3d0ab31f040dd8de89f7836fe'

$pwd
/var/build/Python-2.0b2/Lib/test

$ ../../python test_unicodedata.py 
Testing Unicode Database...
Methods: e052289ecef97fc89c794cf663cb74a64631d34e
Functions: 5abd7e976848725e58f5834a0e5e37615f40d3a2
API: ok

$ cat output/test_unicodedata 
test_unicodedata
Testing Unicode Database...
Methods: b88684df19fca8c3d0ab31f040dd8de89f7836fe
Functions: 5abd7e976848725e58f5834a0e5e37615f40d3a2
API: ok


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115492&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 20:10:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 12:10:16 -0700
Subject: [Python-bugs-list] [Bug #115487] Windows installer not logo compliant
Message-ID: <200009271910.MAA08470@bush.i.sourceforge.net>

Bug #115487, was updated on 2000-Sep-27 09:28
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Wont Fix
Bug Group: Feature Request
Priority: 5
Summary: Windows installer not logo compliant

Details: Python 2.0b2 is not Windows 2000 Logo compliant. I noticed the following problems:

Installer does not use the Microsoft Windows Installer Service [2.1]

Installer does not install into "Program Files" by default [2.4]

Installer does not create new Uninstall registry entries: [2.5]
InstallLocation, Publisher, VersionMajor, VersionMinor

Installer does not support advertising [2.6]

IDLE does not default to My Documents when saving files [4.1]

Follow-Ups:

Date: 2000-Sep-27 12:10
By: tim_one

Comment:
W2000 Logo compliance is a non-goal.

Some of these may be nice (e.g., using MSI when available), others will never happen (installing into "Program Files" -- that (a path with an embedded space) is the dumbest conceivable place to install an app users want to run from a cmd line -- Python *used* to get installed there, and dealing with the space was a major barrier for newbies).

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115487&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 20:13:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 12:13:37 -0700
Subject: [Python-bugs-list] [Bug #115492] 1 test failed: test_unicodedata
Message-ID: <200009271913.MAA08625@bush.i.sourceforge.net>

Bug #115492, was updated on 2000-Sep-27 11:45
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: 1 test failed: test_unicodedata

Details: Running the self-test ("make test") for 2.0b2 under

$ uname -a
SunOS jimi 5.6 Generic_105181-17 sun4u sparc SUNW,Ultra-5_10

...
test_unicodedata
test test_unicodedata failed -- Writing: 'e052289ecef97fc89c794cf663cb74a64631d34e', expected: 'b886
84df19fca8c3d0ab31f040dd8de89f7836fe'

$pwd
/var/build/Python-2.0b2/Lib/test

$ ../../python test_unicodedata.py 
Testing Unicode Database...
Methods: e052289ecef97fc89c794cf663cb74a64631d34e
Functions: 5abd7e976848725e58f5834a0e5e37615f40d3a2
API: ok

$ cat output/test_unicodedata 
test_unicodedata
Testing Unicode Database...
Methods: b88684df19fca8c3d0ab31f040dd8de89f7836fe
Functions: 5abd7e976848725e58f5834a0e5e37615f40d3a2
API: ok


Follow-Ups:

Date: 2000-Sep-27 12:13
By: tim_one

Comment:
Changed to platform-specific and assigned to MAL.  Looks like the little-endian vs big-endian glitch again to me.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115492&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 20:25:02 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 12:25:02 -0700
Subject: [Python-bugs-list] [Bug #115491] 2.0b2:test_unicodedata fails: Sparc Solaris 2.7/6
Message-ID: <200009271925.MAA09069@bush.i.sourceforge.net>

Bug #115491, was updated on 2000-Sep-27 11:22
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: 2.0b2:test_unicodedata fails: Sparc Solaris 2.7/6

Details: Sparc Solaris 2.7
gcc 2.95.2
test_methods sha hexdigest output does not match expected results. 

Note: test_unicodedata.py script differs on windows version of 2.0b2 (is same as version supplied with
unix source 2.0b1). 

Sorry if this has already been reported. Did not see in current bug list. 

Follow-Ups:

Date: 2000-Sep-27 12:25
By: lemburg

Comment:
I have already checked in a patch which should solve this
problem -- can't check it though, since I don't have access to
a big endian machine.

The CVS tree has the patched versions of the test_unicodedata.py
file and the new test output.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115491&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 20:25:10 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 12:25:10 -0700
Subject: [Python-bugs-list] [Bug #115492] 1 test failed: test_unicodedata
Message-ID: <200009271925.MAA09076@bush.i.sourceforge.net>

Bug #115492, was updated on 2000-Sep-27 11:45
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: 1 test failed: test_unicodedata

Details: Running the self-test ("make test") for 2.0b2 under

$ uname -a
SunOS jimi 5.6 Generic_105181-17 sun4u sparc SUNW,Ultra-5_10

...
test_unicodedata
test test_unicodedata failed -- Writing: 'e052289ecef97fc89c794cf663cb74a64631d34e', expected: 'b886
84df19fca8c3d0ab31f040dd8de89f7836fe'

$pwd
/var/build/Python-2.0b2/Lib/test

$ ../../python test_unicodedata.py 
Testing Unicode Database...
Methods: e052289ecef97fc89c794cf663cb74a64631d34e
Functions: 5abd7e976848725e58f5834a0e5e37615f40d3a2
API: ok

$ cat output/test_unicodedata 
test_unicodedata
Testing Unicode Database...
Methods: b88684df19fca8c3d0ab31f040dd8de89f7836fe
Functions: 5abd7e976848725e58f5834a0e5e37615f40d3a2
API: ok


Follow-Ups:

Date: 2000-Sep-27 12:13
By: tim_one

Comment:
Changed to platform-specific and assigned to MAL.  Looks like the little-endian vs big-endian glitch again to me.

-------------------------------------------------------

Date: 2000-Sep-27 12:25
By: lemburg

Comment:
I have already checked in a patch which should solve this
problem -- can't check it though, since I don't have access to
a big endian machine.

The CVS tree has the patched versions of the test_unicodedata.py
file and the new test output.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115492&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 22:51:19 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 14:51:19 -0700
Subject: [Python-bugs-list] [Bug #115506] recent change to md5.h causes md5c.c compilation failure
Message-ID: <200009272151.OAA06856@delerium.i.sourceforge.net>

Bug #115506, was updated on 2000-Sep-27 14:51
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: recent change to md5.h causes md5c.c compilation failure

Details: Around the time 2.0b2 was released, a change to md5.h involving the removal of
#include <limits.h>
causes macros to become undefined, and compilation on Tru64 Unix to fail. The relevant code in md5.h is:

/* UINT4 defines a four byte word */
#if SIZEOF_LONG == 4
typedef unsigned long int UINT4;
#else
#if INT_MAX == 2147483647
typedef unsigned int UINT4;
#endif
/* Too bad if neither is; pyport.h would need to be fixed. */
#endif

md5c.c #includes only "config.h" and then "md5.h". Config.h defines SIZEOF_LONG, but not INT_MAX, and on a machine where SIZEOF_LONG is 8, as it is on Tru64 Unix, this results in UINT4 is not being typedef'ed, leading to compilation errors in md5c.c . The comment about pyport.h has no relevance here, since it doesn't get #included. The previous version of md5.h #included <limits.h>, causing INT_MAX to be defined, so things worked. The fix is either to re-include limits.h, or have INT_MAX defined in config.h when generated by configure.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115506&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 22:58:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 14:58:06 -0700
Subject: [Python-bugs-list] [Bug #115506] recent change to md5.h causes md5c.c compilation failure
Message-ID: <200009272158.OAA07198@delerium.i.sourceforge.net>

Bug #115506, was updated on 2000-Sep-27 14:51
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: recent change to md5.h causes md5c.c compilation failure

Details: Around the time 2.0b2 was released, a change to md5.h involving the removal of
#include <limits.h>
causes macros to become undefined, and compilation on Tru64 Unix to fail. The relevant code in md5.h is:

/* UINT4 defines a four byte word */
#if SIZEOF_LONG == 4
typedef unsigned long int UINT4;
#else
#if INT_MAX == 2147483647
typedef unsigned int UINT4;
#endif
/* Too bad if neither is; pyport.h would need to be fixed. */
#endif

md5c.c #includes only "config.h" and then "md5.h". Config.h defines SIZEOF_LONG, but not INT_MAX, and on a machine where SIZEOF_LONG is 8, as it is on Tru64 Unix, this results in UINT4 is not being typedef'ed, leading to compilation errors in md5c.c . The comment about pyport.h has no relevance here, since it doesn't get #included. The previous version of md5.h #included <limits.h>, causing INT_MAX to be defined, so things worked. The fix is either to re-include limits.h, or have INT_MAX defined in config.h when generated by configure.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115506&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 23:14:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 15:14:48 -0700
Subject: [Python-bugs-list] [Bug #115506] recent change to md5.h causes md5c.c compilation failure
Message-ID: <200009272214.PAA15675@bush.i.sourceforge.net>

Bug #115506, was updated on 2000-Sep-27 14:51
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: recent change to md5.h causes md5c.c compilation failure

Details: Around the time 2.0b2 was released, a change to md5.h involving the removal of
#include <limits.h>
causes macros to become undefined, and compilation on Tru64 Unix to fail. The relevant code in md5.h is:

/* UINT4 defines a four byte word */
#if SIZEOF_LONG == 4
typedef unsigned long int UINT4;
#else
#if INT_MAX == 2147483647
typedef unsigned int UINT4;
#endif
/* Too bad if neither is; pyport.h would need to be fixed. */
#endif

md5c.c #includes only "config.h" and then "md5.h". Config.h defines SIZEOF_LONG, but not INT_MAX, and on a machine where SIZEOF_LONG is 8, as it is on Tru64 Unix, this results in UINT4 is not being typedef'ed, leading to compilation errors in md5c.c . The comment about pyport.h has no relevance here, since it doesn't get #included. The previous version of md5.h #included <limits.h>, causing INT_MAX to be defined, so things worked. The fix is either to re-include limits.h, or have INT_MAX defined in config.h when generated by configure.

Follow-Ups:

Date: 2000-Sep-27 15:14
By: tim_one

Comment:
All modules should #include Python.h.  The bug appears to be that md5c.c doesn't.  It shouldn't include config.h directly.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115506&group_id=5470


From noreply@sourceforge.net  Wed Sep 27 23:44:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 15:44:43 -0700
Subject: [Python-bugs-list] [Bug #115357] ConfigParser feedback
Message-ID: <200009272244.PAA16697@bush.i.sourceforge.net>

Bug #115357, was updated on 2000-Sep-26 05:31
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 1
Summary: ConfigParser feedback

Details: (I received this via email; the submitter doesn't seem to be interested in using SourceForge.)

From: "Todd R. Palmer" <todd.palmer@callcti.com>

1. ConfigParser chokes on sections headers with spaces (ie [Log File] ).  I 
know that these are vaild on MS Windows, and I'm pretty sure they are valid on Unix config files. It looks like just the regular expression needs to change for the headers (sorry I'm really bad at regex).

2. sections() returns all sections including the '__name__' key.  Should it?  It's pretty easy for us to skip, but it's just used internally.

Follow-Ups:

Date: 2000-Sep-27 15:44
By: fdrake

Comment:
Fixed in Lib/ConfigParser.py revision 1.23.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115357&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 00:45:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 16:45:29 -0700
Subject: [Python-bugs-list] [Bug #115515] build with read-only source files fails
Message-ID: <200009272345.QAA11263@delerium.i.sourceforge.net>

Bug #115515, was updated on 2000-Sep-27 16:45
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: build with read-only source files fails

Details: I found this when compiling 2.0b2; I am new to Python and
have not tried earlier versions.
The problem is that 'cp' fails when its target exists and
is readonly.  (I typically build with readonly sources as
that uncovers where the tree mysteriously modifies the
distributed files.)

One solution might be not to distribute Include/graminit.h
and Python/graminit.c, and to rely on the build to create
them.  Another solution would be to remove the files before
copying them in.  I am not sure how well I will be able to
paste a patchfile in here, but I'll give it a shot.

*** Grammar/Makefile.in0        Thu Aug 17 07:38:18 2000
--- Grammar/Makefile.in Wed Sep 27 18:57:10 2000
***************
*** 35,43 ****
--- 35,45 ----
  depend:
  
  $(DESTH):     graminit.h
+               -rm -f $(DESTH)
                cp graminit.h $(DESTH)
  
  $(DESTC):     graminit.c
+               -rm -f $(DESTC)
                cp graminit.c $(DESTC)
  
  graminit.c graminit.h: $(PGEN) Grammar


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115515&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 01:26:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 17:26:57 -0700
Subject: [Python-bugs-list] [Bug #115517] no option of using { } for nested blocks
Message-ID: <200009280026.RAA12731@delerium.i.sourceforge.net>

Bug #115517, was updated on 2000-Sep-27 17:26
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: no option of using { } for nested blocks

Details: It would be much appriciated if there was an option to use { and } 
for nested blocks of code.  This will enable more folks to adopt the
language.  using indentation as the only method of nested blocks does
lead to less style conflicts, but makes the language more pron to coding errors, especially if you don't use tabs, or have a special editor that automatically indents for you.  tracking down missing spaces in front of
an elif, or else is such a pain in the arse.  the { and } completely eliminates this, and would be a much appriciated addition.  without it I just won't use python, and I'm sure I'm not the only one.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115517&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 02:22:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 18:22:26 -0700
Subject: [Python-bugs-list] [Bug #115035] SunOS 4.1.4 with GCC 2.95.2 can't compile complete
Message-ID: <200009280122.SAA22255@bush.i.sourceforge.net>

Bug #115035, was updated on 2000-Sep-21 18:24
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 1
Summary: SunOS 4.1.4 with GCC 2.95.2 can't compile complete

Details: 1) Module/posixmodule.c
  In Module/posixmodule.c, it used rename, pclose, fclose but SunOS 4.1.4's unistd.h does not have these definitions. So add them.
2) Modules/mmapmodule.c
  In Modules/mmapmodule.c, MS_SYNC used but SunOS 4.1.4's mman.h does not have this difinition. So add it.


Follow-Ups:

Date: 2000-Sep-21 18:56
By: gvanrossum

Comment:
I'm not sure what the proper solution is here. Can you provide a patch?
Which C preprocessor symbol do I check for to know that I'm on SunOS 4.1.4?

(1) We can't add decls for these funcs unconditionally because it would conflict with decls in unistd.h or elsewhere on other platforms.

(2) What is the proper replacement for MS_SYNC on SunOS 4.1.4?
-------------------------------------------------------

Date: 2000-Sep-23 01:52
By: loewis

Comment:
Specifying MS_SYNC is not necessary on SunOS 4, the msync manpage says

MS_ASYNC returns msync() immediately once all  I/O  operations  are  scheduled;  normally,  msync() will not return until all  I/O  operations  are  complete.

So it is safe to define it as 0.

I believe SunOS 4 can be recognized by testing that "sun" is defined and "__SVR4" is not.

According to the man pages, the missing prototypes are

       int rename(path1, path2)
       char *path1, *path2;
       fclose(stream)
       FILE *stream;
       pclose(stream)
       FILE *stream;

Indeed, no header file on this system has an fclose prototype...
-------------------------------------------------------

Date: 2000-Sep-24 16:54
By: moroo

Comment:
Pathes are last half of this message.

And more trouble
1) When making -L does not have any arguments, so making is stopped.
2) Some test does not pass.
  test log added next of pacthes.

Patches:
--- Patch Begin ---
*** Modules/mmapmodule.c.org    Fri Sep 22 17:01:14 2000
--- Modules/mmapmodule.c        Fri Sep 22 16:52:55 2000
***************
*** 24,29 ****
--- 24,35 ----
  #define UNIX
  #endif

+ #ifdef sun
+ #ifndef MS_SYNC
+ #define MS_SYNC 0x0
+ #endif
+ #endif
+
  #ifdef MS_WIN32
  #include <windows.h>
  #endif
*** Modules/posixmodule.c.org   Fri Sep 22 17:01:25 2000
--- Modules/posixmodule.c       Fri Sep 22 16:51:46 2000
***************
*** 106,111 ****
--- 106,118 ----

  #ifdef HAVE_UNISTD_H
  #include <unistd.h>
+ #ifdef sun
+ #ifdef _POSIX_VERSION
+ extern int rename(const char *, const char *);
+ extern int pclose(FILE *);
+ extern int fclose(FILE *);
+ #endif
+ #endif
  #endif

  #ifdef NeXT

--- Patch End ---

--- Test Log ---
#Delete successed lines.

test test_cgi crashed -- exceptions.AttributeError: uname
test test_format crashed -- exceptions.SystemError: error return without excepti
on set
test test_largefile skipped --  platform does not have largefile support
test test_poll skipped --  select.poll not defined -- skipping test_poll
test test_popen2 crashed -- exceptions.AttributeError: waitpid
test test_pwd crashed -- exceptions.AttributeError: getpwall
test test_signal crashed -- exceptions.AttributeError: alarm
test test_socket crashed -- exceptions.AttributeError: getpeername
test test_strftime skipped --  cannot import name mktime
test test_time crashed -- exceptions.AttributeError: clock
test test_unicode crashed -- exceptions.SystemError: error return without except
ion set
test test_urllib crashed -- exceptions.AttributeError: quote
9 tests failed: test_cgi test_format test_popen2 test_pwd test_signal test_socke
t test_time test_unicode test_urllib
31 tests skipped: test_al test_audioop test_bsddb test_cd test_cl test_crypt tes
t_dbm test_dl test_fork1 test_gc test_gdbm test_gl test_gzip test_imageop test_i
mgfile test_largefile test_linuxaudiodev test_minidom test_nis test_openpty test
_poll test_pty test_pyexpat test_rgbimg test_strftime test_sunaudiodev test_thre
ad test_timing test_winreg test_winsound test_zlib
test test_cgi crashed -- exceptions.AttributeError: uname
test test_format crashed -- exceptions.SystemError: error return without excepti
on set
test test_largefile skipped --  platform does not have largefile support
test test_longexp crashed -- exceptions.MemoryError:
test test_popen2 crashed -- exceptions.OSError: [Errno 12] Not enough memory
test test_pwd crashed -- exceptions.AttributeError: getpwall
/bin/sh: 12372 Memory fault - core dumped
--- End ---


-------------------------------------------------------

Date: 2000-Sep-25 06:22
By: gvanrossum

Comment:
Fixed both issues. Please test from the CVS tree (or wait for 2.0b2, in two days), as I don't have a SunOS 4.1.4 system available for testing!
-------------------------------------------------------

Date: 2000-Sep-27 18:22
By: moroo

Comment:
I tried to build Python 2.0b2 on SunOS 4.1.4.
It looks good on posixmodule and mmapmodule.
But now unicodedatabase causes error. SunOS 4.1.4 does not have NULL. So add NULL define on unicodedatabase.c.

And one more build error (I reported already on 2000-Sep-24 23:54)
gcc -L  python.o \
          ../libpython2.0.a   -lnsl -ldl  -lm  -o python
ld: -L: pathname missing
collect2: ld returned 4 exit status

Test status:
63 tests OK.
8 tests failed: test_format test_popen2 test_pwd test_signal test_socket test_ti
me test_unicode test_unicodedata
31 tests skipped: test_al test_audioop test_bsddb test_cd test_cl test_crypt tes
t_dbm test_dl test_fork1 test_gdbm test_gl test_gzip test_imageop test_imgfile t
est_largefile test_linuxaudiodev test_minidom test_nis test_openpty test_poll te
st_pty test_pyexpat test_rgbimg test_sax test_strftime test_sunaudiodev test_thr
ead test_timing test_winreg test_winsound test_zlib

test test_format crashed -- exceptions.SystemError: error return without exception set
test test_popen2 crashed -- exceptions.OSError: [Errno 12] Not enough memory
test test_pwd crashed -- exceptions.AttributeError: getpwall
test test_signal crashed -- exceptions.AttributeError: alarm
test test_socket crashed -- exceptions.OSError: [Errno 12] Not enough memory
test test_time crashed -- exceptions.AttributeError: clock
test test_unicode crashed -- exceptions.SystemError: error return without exception set

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115035&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 02:26:43 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 18:26:43 -0700
Subject: [Python-bugs-list] [Bug #115517] no option of using { } for nested blocks
Message-ID: <200009280126.SAA22335@bush.i.sourceforge.net>

Bug #115517, was updated on 2000-Sep-27 17:26
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: Wont Fix
Bug Group: Feature Request
Priority: 5
Summary: no option of using { } for nested blocks

Details: It would be much appriciated if there was an option to use { and } 
for nested blocks of code.  This will enable more folks to adopt the
language.  using indentation as the only method of nested blocks does
lead to less style conflicts, but makes the language more pron to coding errors, especially if you don't use tabs, or have a special editor that automatically indents for you.  tracking down missing spaces in front of
an elif, or else is such a pain in the arse.  the { and } completely eliminates this, and would be a much appriciated addition.  without it I just won't use python, and I'm sure I'm not the only one.

Follow-Ups:

Date: 2000-Sep-27 18:26
By: tim_one

Comment:
Closed w/ Won'tFix.  The language's designer has said this won't happen.

If you try the language anyway, you just might find that you like it!  That's a very common experience.

In the meantime, catering to random prejudice (as you say, you're not a Python user) isn't a sound basis for language design.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115517&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 03:42:37 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 19:42:37 -0700
Subject: [Python-bugs-list] [Bug #115527] StringIO.StringIO does not support truncate()
Message-ID: <200009280242.TAA17479@delerium.i.sourceforge.net>

Bug #115527, was updated on 2000-Sep-27 19:42
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: StringIO.StringIO does not support truncate()

Details: StringIO module does not support the truncate() method to clear the internal buffer.

cStringIO does support this method.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115527&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 03:56:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 19:56:05 -0700
Subject: [Python-bugs-list] [Bug #115506] recent change to md5.h causes md5c.c compilation failure
Message-ID: <200009280256.TAA17878@delerium.i.sourceforge.net>

Bug #115506, was updated on 2000-Sep-27 14:51
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: recent change to md5.h causes md5c.c compilation failure

Details: Around the time 2.0b2 was released, a change to md5.h involving the removal of
#include <limits.h>
causes macros to become undefined, and compilation on Tru64 Unix to fail. The relevant code in md5.h is:

/* UINT4 defines a four byte word */
#if SIZEOF_LONG == 4
typedef unsigned long int UINT4;
#else
#if INT_MAX == 2147483647
typedef unsigned int UINT4;
#endif
/* Too bad if neither is; pyport.h would need to be fixed. */
#endif

md5c.c #includes only "config.h" and then "md5.h". Config.h defines SIZEOF_LONG, but not INT_MAX, and on a machine where SIZEOF_LONG is 8, as it is on Tru64 Unix, this results in UINT4 is not being typedef'ed, leading to compilation errors in md5c.c . The comment about pyport.h has no relevance here, since it doesn't get #included. The previous version of md5.h #included <limits.h>, causing INT_MAX to be defined, so things worked. The fix is either to re-include limits.h, or have INT_MAX defined in config.h when generated by configure.

Follow-Ups:

Date: 2000-Sep-27 15:14
By: tim_one

Comment:
All modules should #include Python.h.  The bug appears to be that md5c.c doesn't.  It shouldn't include config.h directly.
-------------------------------------------------------

Date: 2000-Sep-27 19:56
By: fdrake

Comment:
Made suggested correction to Modules/md5c.c revision 2.6.

Mark, could you please test this on your 64-bit machine?  Thanks!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115506&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 04:05:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 20:05:35 -0700
Subject: [Python-bugs-list] [Bug #115515] build with read-only source files fails
Message-ID: <200009280305.UAA18212@delerium.i.sourceforge.net>

Bug #115515, was updated on 2000-Sep-27 16:45
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: build with read-only source files fails

Details: I found this when compiling 2.0b2; I am new to Python and
have not tried earlier versions.
The problem is that 'cp' fails when its target exists and
is readonly.  (I typically build with readonly sources as
that uncovers where the tree mysteriously modifies the
distributed files.)

One solution might be not to distribute Include/graminit.h
and Python/graminit.c, and to rely on the build to create
them.  Another solution would be to remove the files before
copying them in.  I am not sure how well I will be able to
paste a patchfile in here, but I'll give it a shot.

*** Grammar/Makefile.in0        Thu Aug 17 07:38:18 2000
--- Grammar/Makefile.in Wed Sep 27 18:57:10 2000
***************
*** 35,43 ****
--- 35,45 ----
  depend:
  
  $(DESTH):     graminit.h
+               -rm -f $(DESTH)
                cp graminit.h $(DESTH)
  
  $(DESTC):     graminit.c
+               -rm -f $(DESTC)
                cp graminit.c $(DESTC)
  
  graminit.c graminit.h: $(PGEN) Grammar


Follow-Ups:

Date: 2000-Sep-27 20:05
By: fdrake

Comment:
I think the suggested change would be fine for Unix, but I have no idea how the Windows "project" files would handle this, or if it's already supported there.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115515&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 04:08:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 20:08:35 -0700
Subject: [Python-bugs-list] [Bug #115528] import creates extra modules if in working directory
Message-ID: <200009280308.UAA25845@bush.i.sourceforge.net>

Bug #115528, was updated on 2000-Sep-27 20:08
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: import creates extra modules if in working directory

Details: Given the directory structure:

lib/
    foo/
         __init__.py
         bar.py

and PYTHONPATH includes lib

If my current working directory is lib/foo, then
>>> import bar
>>> print bar.__file__
bar.py
>>> import foo.bar
>>> print foo.bar.__file__
lib/foo/bar.py
>>> print bar == foo.bar
0

I think that any one file should produce only one module at runtime and this behavior is wrong.

The reason I am trying to count on file-module mapping is because I was to index some behavior by class, and if I can't count on classes from the same file testing identical then I'm stuck.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115528&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 04:15:48 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 20:15:48 -0700
Subject: [Python-bugs-list] [Bug #115515] build with read-only source files fails
Message-ID: <200009280315.UAA18583@delerium.i.sourceforge.net>

Bug #115515, was updated on 2000-Sep-27 16:45
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: build with read-only source files fails

Details: I found this when compiling 2.0b2; I am new to Python and
have not tried earlier versions.
The problem is that 'cp' fails when its target exists and
is readonly.  (I typically build with readonly sources as
that uncovers where the tree mysteriously modifies the
distributed files.)

One solution might be not to distribute Include/graminit.h
and Python/graminit.c, and to rely on the build to create
them.  Another solution would be to remove the files before
copying them in.  I am not sure how well I will be able to
paste a patchfile in here, but I'll give it a shot.

*** Grammar/Makefile.in0        Thu Aug 17 07:38:18 2000
--- Grammar/Makefile.in Wed Sep 27 18:57:10 2000
***************
*** 35,43 ****
--- 35,45 ----
  depend:
  
  $(DESTH):     graminit.h
+               -rm -f $(DESTH)
                cp graminit.h $(DESTH)
  
  $(DESTC):     graminit.c
+               -rm -f $(DESTC)
                cp graminit.c $(DESTC)
  
  graminit.c graminit.h: $(PGEN) Grammar


Follow-Ups:

Date: 2000-Sep-27 20:05
By: fdrake

Comment:
I think the suggested change would be fine for Unix, but I have no idea how the Windows "project" files would handle this, or if it's already supported there.
-------------------------------------------------------

Date: 2000-Sep-27 20:15
By: tim_one

Comment:
Back to Fred.  Windows people rely on Unix people to rebuild the grammar files as needed and check them in -- the Windows setup doesn't even know *how* to rebuild them.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115515&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 04:48:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 20:48:34 -0700
Subject: [Python-bugs-list] [Bug #115530] cStringIO.StringIO() doesn't raise IOError when closed
Message-ID: <200009280348.UAA19740@delerium.i.sourceforge.net>

Bug #115530, was updated on 2000-Sep-27 20:48
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: cStringIO.StringIO() doesn't raise IOError when closed

Details: When write() is called on a closed StringO instance, ValueError should be raised.  Other methods should be checked for this as well.

>>> import cStringIO, StringIO
>>> f = cStringIO.StringIO()
>>> f.close()
>>> f.write('')

>>> f = StringIO.StringIO()    
>>> f.close()
>>> f.write('')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "./../Lib/StringIO.py", line 119, in write
    raise ValueError, "I/O operation on closed file"
ValueError: I/O operation on closed file

>>> f = open('junk.txt', 'w')
>>> f.close()
>>> f.write('abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: I/O operation on closed file

Assigned to Ken since he works at Digital Creations and can pester Jim Fulton about this.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115530&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 04:53:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 20:53:16 -0700
Subject: [Python-bugs-list] [Bug #115530] cStringIO.StringIO() doesn't raise ValueError when closed
Message-ID: <200009280353.UAA19895@delerium.i.sourceforge.net>

Bug #115530, was updated on 2000-Sep-27 20:48
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: cStringIO.StringIO() doesn't raise ValueError when closed

Details: When write() is called on a closed StringO instance, ValueError should be raised.  Other methods should be checked for this as well.

>>> import cStringIO, StringIO
>>> f = cStringIO.StringIO()
>>> f.close()
>>> f.write('')

>>> f = StringIO.StringIO()    
>>> f.close()
>>> f.write('')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "./../Lib/StringIO.py", line 119, in write
    raise ValueError, "I/O operation on closed file"
ValueError: I/O operation on closed file

>>> f = open('junk.txt', 'w')
>>> f.close()
>>> f.write('abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: I/O operation on closed file

Assigned to Ken since he works at Digital Creations and can pester Jim Fulton about this.

Follow-Ups:

Date: 2000-Sep-27 20:53
By: fdrake

Comment:
Oops -- fixed summary to refer to the proper exception.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115530&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 04:57:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 20:57:18 -0700
Subject: [Python-bugs-list] [Bug #115531] cStringIO truncate() doesn't support size parameter
Message-ID: <200009280357.UAA19983@delerium.i.sourceforge.net>

Bug #115531, was updated on 2000-Sep-27 20:57
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: cStringIO truncate() doesn't support size parameter

Details: The truncate() method doesn't handle the optional size parameter to truncate, nor does it check its parameters in any way.  Many (all?) methods don't check arguments when they don't expect any.

Assigned to Ken because he works at Digital Creations and can pester Jim about this.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115531&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 05:21:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 21:21:56 -0700
Subject: [Python-bugs-list] [Bug #115527] StringIO.StringIO does not support truncate()
Message-ID: <200009280421.VAA28267@bush.i.sourceforge.net>

Bug #115527, was updated on 2000-Sep-27 19:42
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: StringIO.StringIO does not support truncate()

Details: StringIO module does not support the truncate() method to clear the internal buffer.

cStringIO does support this method.

Follow-Ups:

Date: 2000-Sep-27 21:21
By: fdrake

Comment:
Fixed in Lib/StringIO.py revision 1.11.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115527&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 05:27:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 21:27:09 -0700
Subject: [Python-bugs-list] [Bug #115530] cStringIO.StringIO() doesn't raise ValueError when closed
Message-ID: <200009280427.VAA28414@bush.i.sourceforge.net>

Bug #115530, was updated on 2000-Sep-27 20:48
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: cStringIO.StringIO() doesn't raise ValueError when closed

Details: When write() is called on a closed StringO instance, ValueError should be raised.  Other methods should be checked for this as well.

>>> import cStringIO, StringIO
>>> f = cStringIO.StringIO()
>>> f.close()
>>> f.write('')

>>> f = StringIO.StringIO()    
>>> f.close()
>>> f.write('')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "./../Lib/StringIO.py", line 119, in write
    raise ValueError, "I/O operation on closed file"
ValueError: I/O operation on closed file

>>> f = open('junk.txt', 'w')
>>> f.close()
>>> f.write('abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: I/O operation on closed file

Assigned to Ken since he works at Digital Creations and can pester Jim Fulton about this.

Follow-Ups:

Date: 2000-Sep-27 20:53
By: fdrake

Comment:
Oops -- fixed summary to refer to the proper exception.
-------------------------------------------------------

Date: 2000-Sep-27 21:27
By: fdrake

Comment:
A simple test for this is commented out in Lib/test/test_StringIO.py; please uncomment and regenerate output when fixing this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115530&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 05:27:34 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 21:27:34 -0700
Subject: [Python-bugs-list] [Bug #115531] cStringIO truncate() doesn't support size parameter
Message-ID: <200009280427.VAA28519@bush.i.sourceforge.net>

Bug #115531, was updated on 2000-Sep-27 20:57
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: cStringIO truncate() doesn't support size parameter

Details: The truncate() method doesn't handle the optional size parameter to truncate, nor does it check its parameters in any way.  Many (all?) methods don't check arguments when they don't expect any.

Assigned to Ken because he works at Digital Creations and can pester Jim about this.

Follow-Ups:

Date: 2000-Sep-27 21:27
By: fdrake

Comment:
A simple test for this is commented out in Lib/test/test_StringIO.py; please uncomment and regenerate output when fixing this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115531&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 05:28:57 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Sep 2000 21:28:57 -0700
Subject: [Python-bugs-list] [Bug #115506] recent change to md5.h causes md5c.c compilation failure
Message-ID: <200009280428.VAA28527@bush.i.sourceforge.net>

Bug #115506, was updated on 2000-Sep-27 14:51
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 7
Summary: recent change to md5.h causes md5c.c compilation failure

Details: Around the time 2.0b2 was released, a change to md5.h involving the removal of
#include <limits.h>
causes macros to become undefined, and compilation on Tru64 Unix to fail. The relevant code in md5.h is:

/* UINT4 defines a four byte word */
#if SIZEOF_LONG == 4
typedef unsigned long int UINT4;
#else
#if INT_MAX == 2147483647
typedef unsigned int UINT4;
#endif
/* Too bad if neither is; pyport.h would need to be fixed. */
#endif

md5c.c #includes only "config.h" and then "md5.h". Config.h defines SIZEOF_LONG, but not INT_MAX, and on a machine where SIZEOF_LONG is 8, as it is on Tru64 Unix, this results in UINT4 is not being typedef'ed, leading to compilation errors in md5c.c . The comment about pyport.h has no relevance here, since it doesn't get #included. The previous version of md5.h #included <limits.h>, causing INT_MAX to be defined, so things worked. The fix is either to re-include limits.h, or have INT_MAX defined in config.h when generated by configure.

Follow-Ups:

Date: 2000-Sep-27 15:14
By: tim_one

Comment:
All modules should #include Python.h.  The bug appears to be that md5c.c doesn't.  It shouldn't include config.h directly.
-------------------------------------------------------

Date: 2000-Sep-27 19:56
By: fdrake

Comment:
Made suggested correction to Modules/md5c.c revision 2.6.

Mark, could you please test this on your 64-bit machine?  Thanks!
-------------------------------------------------------

Date: 2000-Sep-27 21:28
By: fdrake

Comment:
Fix confirmed by Mark Favas; closing this bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115506&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 10:46:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 02:46:03 -0700
Subject: [Python-bugs-list] [Bug #115476] Python-2.0b2 is incompatible with readline version 2
Message-ID: <200009280946.CAA06972@bush.i.sourceforge.net>

Bug #115476, was updated on 2000-Sep-27 05:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: Python-2.0b2 is incompatible with readline version 2

Details: Python-2.0b2 is now incompatible with GNU readline version 2. This is new, Python-2.0b1 worked fine with it. The only reason that it is incompatible is that it is trying to read the symbol rl_library_version. I suggest this code is simply removed again.


Follow-Ups:

Date: 2000-Sep-27 10:52
By: jhylton

Comment:
The uses of rl_library_version was added a week ago after a suggestion by jpettit.  Need to resolve this for old issues of readline.

Question for jribbens: How unreasonable would it be to require readline 3 or later?  readline ver. 2 is more than three years old.

-------------------------------------------------------

Date: 2000-Sep-28 02:46
By: jribbens

Comment:
True, but unfortunately OpenBSD latest version ships with readline v2 installed. Normally I would consider this OpenBSD's fault for having an old version of readline, but since Python is not actually relying on any post-v2 features, I think it might be worthwhile retaining compatibility with the older library.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115476&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 11:42:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 03:42:11 -0700
Subject: [Python-bugs-list] [Bug #115555] Parser crashes for deeply nested list displays
Message-ID: <200009281042.DAA08898@bush.i.sourceforge.net>

Bug #115555, was updated on 2000-Sep-28 03:42
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Parser crashes for deeply nested list displays

Details: Compiling

s=[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]

gives an error message

s_push: parser stack overflow

Python 1.5.2 then reports a MemoryError, 2.0b2 a SyntaxError.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115555&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 14:01:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 06:01:14 -0700
Subject: [Python-bugs-list] [Bug #115119] re module docs missing lookbehind, etc.
Message-ID: <200009281301.GAA14051@bush.i.sourceforge.net>

Bug #115119, was updated on 2000-Sep-22 11:12
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: re module docs missing lookbehind, etc.

Details: Perhap this is not a bug, but the re module documentation does not describe some PCRE2 features that sre incorporates. Note that these did not make it into pre, and so are not necessary for pre compatibility, but maybe should be documented as sre features.

Here follows a text description from a message by AMK that accompanied a pyPCRE snapshot:

[I've lost the reference to the original and had to retype what follows.]

========
New features in PCRE2 compared to PCRE1 are:

\z    Matches only at the end of the string. This differs from the existing \Z, which will match at the end of the string, or before a final newline at the end of the string.

(?<=...)    Positive lookbehind assertion. Matches if the current position in the string is preceded by a match for the contained regex

(?<!...)    Negative lookbehind assertion. Matches if the current position in the string is not preceded by a match for the contained regex

========

FYI, two other PCRE2 features that AMK described don't seem to have make it into sre: "once-only subpatterns" and "conditional subpatterns".



Follow-Ups:

Date: 2000-Sep-22 11:14
By: gvanrossum

Comment:
For Fred to negotiate with Fredrik.
-------------------------------------------------------

Date: 2000-Sep-22 11:21
By: jdnier

Comment:
Actually, '\z' is supported by pre, so at least that should be added to the docs.
-------------------------------------------------------

Date: 2000-Sep-28 06:01
By: fdrake

Comment:
Andrew, you're more in the know than I on this topic -- if I can get some text from you, I can mark it up.  Thanks!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115119&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 14:03:21 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 06:03:21 -0700
Subject: [Python-bugs-list] [Bug #115528] import creates extra modules if in working directory
Message-ID: <200009281303.GAA14188@bush.i.sourceforge.net>

Bug #115528, was updated on 2000-Sep-27 20:08
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: import creates extra modules if in working directory

Details: Given the directory structure:

lib/
    foo/
         __init__.py
         bar.py

and PYTHONPATH includes lib

If my current working directory is lib/foo, then
>>> import bar
>>> print bar.__file__
bar.py
>>> import foo.bar
>>> print foo.bar.__file__
lib/foo/bar.py
>>> print bar == foo.bar
0

I think that any one file should produce only one module at runtime and this behavior is wrong.

The reason I am trying to count on file-module mapping is because I was to index some behavior by class, and if I can't count on classes from the same file testing identical then I'm stuck.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115528&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 14:15:18 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 06:15:18 -0700
Subject: [Python-bugs-list] [Bug #115528] import creates extra modules if in working directory
Message-ID: <200009281315.GAA06645@delerium.i.sourceforge.net>

Bug #115528, was updated on 2000-Sep-27 20:08
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Summary: import creates extra modules if in working directory

Details: Given the directory structure:

lib/
    foo/
         __init__.py
         bar.py

and PYTHONPATH includes lib

If my current working directory is lib/foo, then
>>> import bar
>>> print bar.__file__
bar.py
>>> import foo.bar
>>> print foo.bar.__file__
lib/foo/bar.py
>>> print bar == foo.bar
0

I think that any one file should produce only one module at runtime and this behavior is wrong.

The reason I am trying to count on file-module mapping is because I was to index some behavior by class, and if I can't count on classes from the same file testing identical then I'm stuck.

Follow-Ups:

Date: 2000-Sep-28 06:15
By: fdrake

Comment:
This is a result of including both lib/ and . (as '') on sys.path; the file is legitimately found for two different module imports, so it is loaded for each.  We recommend that you do not run the Python interpreter from within a package; determining this situation from the interpreter at runtime would be prohibitively expensive and slow startup.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115528&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 14:18:24 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 06:18:24 -0700
Subject: [Python-bugs-list] [Bug #115528] import creates extra modules if in working directory
Message-ID: <200009281318.GAA06807@delerium.i.sourceforge.net>

Bug #115528, was updated on 2000-Sep-27 20:08
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: import creates extra modules if in working directory

Details: Given the directory structure:

lib/
    foo/
         __init__.py
         bar.py

and PYTHONPATH includes lib

If my current working directory is lib/foo, then
>>> import bar
>>> print bar.__file__
bar.py
>>> import foo.bar
>>> print foo.bar.__file__
lib/foo/bar.py
>>> print bar == foo.bar
0

I think that any one file should produce only one module at runtime and this behavior is wrong.

The reason I am trying to count on file-module mapping is because I was to index some behavior by class, and if I can't count on classes from the same file testing identical then I'm stuck.

Follow-Ups:

Date: 2000-Sep-28 06:15
By: fdrake

Comment:
This is a result of including both lib/ and . (as '') on sys.path; the file is legitimately found for two different module imports, so it is loaded for each.  We recommend that you do not run the Python interpreter from within a package; determining this situation from the interpreter at runtime would be prohibitively expensive and slow startup.
-------------------------------------------------------

Date: 2000-Sep-28 06:18
By: lemburg

Comment:
Perhaps modules should use an absolute file name in the __file__
attribute and also be stored under this name in the module
dictionary ?!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115528&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 18:05:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 10:05:58 -0700
Subject: [Python-bugs-list] [Bug #115528] import creates extra modules if in working directory
Message-ID: <200009281705.KAA23562@bush.i.sourceforge.net>

Bug #115528, was updated on 2000-Sep-27 20:08
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: import creates extra modules if in working directory

Details: Given the directory structure:

lib/
    foo/
         __init__.py
         bar.py

and PYTHONPATH includes lib

If my current working directory is lib/foo, then
>>> import bar
>>> print bar.__file__
bar.py
>>> import foo.bar
>>> print foo.bar.__file__
lib/foo/bar.py
>>> print bar == foo.bar
0

I think that any one file should produce only one module at runtime and this behavior is wrong.

The reason I am trying to count on file-module mapping is because I was to index some behavior by class, and if I can't count on classes from the same file testing identical then I'm stuck.

Follow-Ups:

Date: 2000-Sep-28 06:15
By: fdrake

Comment:
This is a result of including both lib/ and . (as '') on sys.path; the file is legitimately found for two different module imports, so it is loaded for each.  We recommend that you do not run the Python interpreter from within a package; determining this situation from the interpreter at runtime would be prohibitively expensive and slow startup.
-------------------------------------------------------

Date: 2000-Sep-28 06:18
By: lemburg

Comment:
Perhaps modules should use an absolute file name in the __file__
attribute and also be stored under this name in the module
dictionary ?!
-------------------------------------------------------

Date: 2000-Sep-28 10:05
By: fdrake

Comment:
Storing modules by filename in a dictionary isn't quite enough.  If there isn't a .pyc file, or if it's out of date, an import will use the .py file, but the next import will use the .pyc file generated from the first import.

Perhaps the directory of the script shoudn't be added to sys.path if there's an __init__.py file in that directory?  In the specific case reported here, the first import would have raised an ImportError in that case, unless there really was a different bar module elsewhere.  That seems acceptable to me, but I'm not at all sure how much legacy code would break (though I suspect very little).

This should probably be discussed on the Import-SIG; I'll send something shortly.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115528&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 18:13:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 10:13:28 -0700
Subject: [Python-bugs-list] [Bug #115595] Building extensions on windows
Message-ID: <200009281713.KAA15995@delerium.i.sourceforge.net>

Bug #115595, was updated on 2000-Sep-28 10:13
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Building extensions on windows

Details: Reported by Mike Fletcher:
Building extensions on windows(at least with MSVC) in debug mode link with the wrong python import library. This leads to crashes because the extension loads the release python dll instead of the debug dll:

Fatal Python error: PyThreadState_Get: no current thread


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115595&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 18:36:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 10:36:05 -0700
Subject: [Python-bugs-list] [Bug #113797] Build problems on Reliant Unix
Message-ID: <200009281736.KAA24708@bush.i.sourceforge.net>

Bug #113797, was updated on 2000-Sep-07 07:33
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 1
Summary: Build problems on Reliant Unix

Details: - the linker requires the options '-W1 -Blargedynsym', otherwise, Python's global functions and variables are not visible to external modules

- when building --with-threads, the linker requires the option -Kpthread

- mmapmodule.o requires a special library

Python version: 2.0b1

compiler version:CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000
CDR9908: cc: Fujitsu Siemens Computers GmbH: CDS++ V2.0C0003, 1.2.7.2 from 29 Jun 2000


Follow-Ups:

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-08 13:45
By: fdrake

Comment:
We need to know the output of "uname -s" and "uname -r" for this system.  (If "uname -r" reports an error, please try "uname -v".)

Are you willing to test a modified configure script on this platform?

What additional library is required for the mmap module?
-------------------------------------------------------

Date: 2000-Sep-12 21:59
By: fdrake

Comment:
Received the following response from Daniel Dittmar <ddittmar@users.sourceforge.net>:

> We need to know the output of "uname -s" and "uname -r" 
> for this system.  (If "uname -r" reports an error, please 
> try "uname -v".)

uname -s
ReliantUNIX-N

uname -r
5.45


> Are you willing to test a modified configure script on
> this platform?

sure.

> What additional library is required for the mmap module?

The man page states -lucb. This didn't work on my machine 
as the BSD compatibility layer is not active. I tell you 
more as soon as I know how to activate it.

***********

Another problem: to detect pthreads, the compiler must be 
called with -Kpthread. Otherwise, pthread.h goes into a 
branch where it tries to include a non existent header, 
fails, and configure reports 'no pthreads'.

Daniel

-------------------------------------------------------

Date: 2000-Sep-15 11:57
By: fdrake

Comment:
For the mmap issue, I've added a comment to Modules/Setup.in to let installers know that -lucb may be needed.  In revision 1.110.
-------------------------------------------------------

Date: 2000-Sep-15 13:37
By: fdrake

Comment:
I'm sending a modified version of  the configure script to Daniel Dittmar to test for the first two points in this bug report.
-------------------------------------------------------

Date: 2000-Sep-21 08:17
By: fdrake

Comment:
Sent query to Daniel Dittmar asking if he's had a chance to test the revised configure script I sent.
-------------------------------------------------------

Date: 2000-Sep-21 08:46
By: fdrake

Comment:
Received message from Daniel indicating he should get a chace to test the changes this weekend, so it should be available for 2.0b2.
-------------------------------------------------------

Date: 2000-Sep-24 05:46
By: ddittmar

Comment:
- configure --without-threads works with the configure patch Revision 1.158

- mmapmodule would work if it includes the lines

#include <unistd.h>

static int
getpagesize (void)
{
    return sysconf (_SC_PAGESIZE);
}

This would be the preferred way as using the BSD compatibility with -lucb is discouraged.

It requires chages to configure (has_pagesize, has_sysconf_sc_pagesize)

- configure --with-threads doesn't build yet, keeping contact with fdrake
-------------------------------------------------------

Date: 2000-Sep-25 08:10
By: fdrake

Comment:
Fix to make sure the public API properly exposed to extensions checked in as configure.in revision 1.155.  The rest of these issues can be dealt with in 2.0 final.
-------------------------------------------------------

Date: 2000-Sep-28 10:36
By: fdrake

Comment:
I've sent a patch for the mmap module to Daniel to test on Reliant UNIX; the patch should remove the need to link to libucb on that platform (the only platform that needed that as far as we know).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113797&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 18:41:17 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 10:41:17 -0700
Subject: [Python-bugs-list] [Bug #115595] Building extensions on windows
Message-ID: <200009281741.KAA24898@bush.i.sourceforge.net>

Bug #115595, was updated on 2000-Sep-28 10:13
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Building extensions on windows

Details: Reported by Mike Fletcher:
Building extensions on windows(at least with MSVC) in debug mode link with the wrong python import library. This leads to crashes because the extension loads the release python dll instead of the debug dll:

Fatal Python error: PyThreadState_Get: no current thread


Follow-Ups:

Date: 2000-Sep-28 10:41
By: fdrake

Comment:
Assigned to Thomas Heller since he's the distutils-on-Windows export!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115595&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 20:09:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 12:09:01 -0700
Subject: [Python-bugs-list] [Bug #115330] popen2 should use dup2() rather than dup().
Message-ID: <200009281909.MAA28312@bush.i.sourceforge.net>

Bug #115330, was updated on 2000-Sep-25 21:04
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: popen2 should use dup2() rather than dup().

Details: Reason:

1. Simpler and less syscalls.
2. close() following fork() changes the std{in,out,err} to blocking mode
        unintentionally in FreeBSD's pthread library.
        dup2() doesn't change the mode.

Fix:

*** /usr/local/lib/python2.0/popen2.py  Tue Sep 26 12:34:40 2000
--- popen2.py   Tue Sep 26 12:42:22 2000
***************
*** 37,51 ****
          self.pid = os.fork()
          if self.pid == 0:
              # Child
!             os.close(0)
!             os.close(1)
!             if os.dup(p2cread) <> 0:
                  sys.stderr.write('popen2: bad read dup\n')
!             if os.dup(c2pwrite) <> 1:
                  sys.stderr.write('popen2: bad write dup\n')
              if capturestderr:
!                 os.close(2)
!                 if os.dup(errin) <> 2: pass
              for i in range(3, MAXFD):
                  try:
                      os.close(i)
--- 37,48 ----
          self.pid = os.fork()
          if self.pid == 0:
              # Child
!             if os.dup2(p2cread, 0) < 0:
                  sys.stderr.write('popen2: bad read dup\n')
!             if os.dup2(c2pwrite, 1) < 0:
                  sys.stderr.write('popen2: bad write dup\n')
              if capturestderr:
!                 if os.dup2(errin, 2) < 0: pass
              for i in range(3, MAXFD):
                  try:
                      os.close(i)


Follow-Ups:

Date: 2000-Sep-26 03:46
By: gvanrossum

Comment:
Assigned to Fred, since he's the popen2 guy :-)
-------------------------------------------------------

Date: 2000-Sep-28 12:09
By: fdrake

Comment:
Fixed in Lib/popen2.py revision 1.16.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115330&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 20:11:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 12:11:45 -0700
Subject: [Python-bugs-list] [Bug #115353] os.popen4() missing on Unix
Message-ID: <200009281911.MAA28379@bush.i.sourceforge.net>

Bug #115353, was updated on 2000-Sep-26 03:47
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: os.popen4() missing on Unix

Details: Fred, let's not forget to add popen4() -- right after the beta would be a good idea.

Follow-Ups:

Date: 2000-Sep-26 03:50
By: gvanrossum

Comment:
(Or just before Jeremy gets up :-)
-------------------------------------------------------

Date: 2000-Sep-28 12:11
By: fdrake

Comment:
Fixed in Lib/popen2.py revision 1.16 and Lib/os.py revision 1.39.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115353&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 20:35:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 12:35:20 -0700
Subject: [Python-bugs-list] [Bug #115555] Parser crashes for deeply nested list displays
Message-ID: <200009281935.MAA29418@bush.i.sourceforge.net>

Bug #115555, was updated on 2000-Sep-28 03:42
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Parser crashes for deeply nested list displays

Details: Compiling

s=[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]

gives an error message

s_push: parser stack overflow

Python 1.5.2 then reports a MemoryError, 2.0b2 a SyntaxError.

Follow-Ups:

Date: 2000-Sep-28 12:35
By: jhylton

Comment:
What is the desired outcome here?  Python is reporting a SyntaxError; it's not crashing.  Would you like to increase the max stack size for the parser?  What should it's limit be?

The current parser stack limit allows eval("["*x+"]"*x) for values of x up to and including 35.  I'm not sure why the limit is set this low.  I bumped the value of MAXSTACK in parser.c from 500 to 5000 and it accepted the nest list expression for values of x up to 357.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115555&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 21:04:28 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 13:04:28 -0700
Subject: [Python-bugs-list] [Bug #115608] Readme.txt
Message-ID: <200009282004.NAA30592@bush.i.sourceforge.net>

Bug #115608, was updated on 2000-Sep-28 13:04
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Not a Bug
Priority: 5
Summary: Readme.txt

Details: The Readme.txt file says "the Tk interface is not enabled by default".  However, Tk comes with the 2.0 Windows distribution (at least), and appears to work fine immediately after installation.

I suggest that Readme be clarified with "(except on Windows)" or whatever.

thanks for all the great work, guys!

=g2

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115608&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 21:11:32 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 13:11:32 -0700
Subject: [Python-bugs-list] [Bug #115609] Please include regexdemo.py in main distribution
Message-ID: <200009282011.NAA23120@delerium.i.sourceforge.net>

Bug #115609, was updated on 2000-Sep-28 13:11
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Please include regexdemo.py in main distribution

Details: I would like to recommend that Guido's regexdemo.py be included in the main distribution of 2.0.  (It was included in as a "demo" in the source distribution of v1.5.2.)

I find regexdemo to be a very useful tool for debugging my REs.  I think others would find it useful too, but since it is buried fairly far down in the source distribution, it is rather hard for newcomers to find.  I therefore recommend you include it in the "tools" directory of the main distribution.

As you know, REs are very difficult to learn (and even to use after you "learn" them!), so I think an excellent aid like regexdemo.py should be given more prominence.

thanks as always,

=g2

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115609&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 22:06:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 14:06:14 -0700
Subject: [Python-bugs-list] [Bug #115515] build with read-only source files fails
Message-ID: <200009282106.OAA00752@bush.i.sourceforge.net>

Bug #115515, was updated on 2000-Sep-27 16:45
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Wont Fix
Bug Group: Feature Request
Priority: 5
Summary: build with read-only source files fails

Details: I found this when compiling 2.0b2; I am new to Python and
have not tried earlier versions.
The problem is that 'cp' fails when its target exists and
is readonly.  (I typically build with readonly sources as
that uncovers where the tree mysteriously modifies the
distributed files.)

One solution might be not to distribute Include/graminit.h
and Python/graminit.c, and to rely on the build to create
them.  Another solution would be to remove the files before
copying them in.  I am not sure how well I will be able to
paste a patchfile in here, but I'll give it a shot.

*** Grammar/Makefile.in0        Thu Aug 17 07:38:18 2000
--- Grammar/Makefile.in Wed Sep 27 18:57:10 2000
***************
*** 35,43 ****
--- 35,45 ----
  depend:
  
  $(DESTH):     graminit.h
+               -rm -f $(DESTH)
                cp graminit.h $(DESTH)
  
  $(DESTC):     graminit.c
+               -rm -f $(DESTC)
                cp graminit.c $(DESTC)
  
  graminit.c graminit.h: $(PGEN) Grammar


Follow-Ups:

Date: 2000-Sep-27 20:05
By: fdrake

Comment:
I think the suggested change would be fine for Unix, but I have no idea how the Windows "project" files would handle this, or if it's already supported there.
-------------------------------------------------------

Date: 2000-Sep-27 20:15
By: tim_one

Comment:
Back to Fred.  Windows people rely on Unix people to rebuild the grammar files as needed and check them in -- the Windows setup doesn't even know *how* to rebuild them.
-------------------------------------------------------

Date: 2000-Sep-28 14:06
By: fdrake

Comment:
I don't see any reasonable way around this as long as the Grammar directory is handled automatically by make.  Let's classify building in a read-only source tree as a "don't do that" situation.

This isn't ideal, but isn't worth changing.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115515&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 22:31:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 14:31:06 -0700
Subject: [Python-bugs-list] [Bug #115615] atof, atoi, atol  not behaving as methods
Message-ID: <200009282131.OAA01763@bush.i.sourceforge.net>

Bug #115615, was updated on 2000-Sep-28 14:31
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: atof, atoi, atol  not behaving as methods

Details: Similar to lower(),  upper() etc shouldn't atof(),  atoi(),  atol()  behave as methods on the new String
objects?
------------------------------
Python 2.0b2 (#6, Sep 26 2000, 14:59:21) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.

>>> "23".atoi()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: atoi
--------------------------------
similarly for atof(), atol()


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115615&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 22:37:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 14:37:35 -0700
Subject: [Python-bugs-list] [Bug #115617] poll problem on Linux 2.0.38, glibc 2.0.7
Message-ID: <200009282137.OAA26667@delerium.i.sourceforge.net>

Bug #115617, was updated on 2000-Sep-28 14:37
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: poll problem on Linux 2.0.38, glibc 2.0.7

Details: Originally reported by Neil Schemenauer in a
comment in patch #101682:

After this patch the selectmodule compiles but test_poll fails with: 
File "Lib/test/test_poll.py", line 77, in poll_unit_tests 
r = p.poll() 
error: (9, 'Bad file descriptor') 

The kernel is 2.0.38 if that makes a difference.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115617&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 22:47:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 14:47:26 -0700
Subject: [Python-bugs-list] [Bug #115618] SRE lookbehind raises a RuntimeError
Message-ID: <200009282147.OAA27088@delerium.i.sourceforge.net>

Bug #115618, was updated on 2000-Sep-28 14:47
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: SRE lookbehind raises a RuntimeError

Details: Test program:

import re
p=re.compile('(?<!abc)(def)')
p.search('abcddef')    

This raises an exception in the search():
RuntimeError: internal error in regular expression engine                       


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115618&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 22:50:40 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 14:50:40 -0700
Subject: [Python-bugs-list] [Bug #115119] re module docs missing lookbehind, etc.
Message-ID: <200009282150.OAA27273@delerium.i.sourceforge.net>

Bug #115119, was updated on 2000-Sep-22 11:12
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: re module docs missing lookbehind, etc.

Details: Perhap this is not a bug, but the re module documentation does not describe some PCRE2 features that sre incorporates. Note that these did not make it into pre, and so are not necessary for pre compatibility, but maybe should be documented as sre features.

Here follows a text description from a message by AMK that accompanied a pyPCRE snapshot:

[I've lost the reference to the original and had to retype what follows.]

========
New features in PCRE2 compared to PCRE1 are:

\z    Matches only at the end of the string. This differs from the existing \Z, which will match at the end of the string, or before a final newline at the end of the string.

(?<=...)    Positive lookbehind assertion. Matches if the current position in the string is preceded by a match for the contained regex

(?<!...)    Negative lookbehind assertion. Matches if the current position in the string is not preceded by a match for the contained regex

========

FYI, two other PCRE2 features that AMK described don't seem to have make it into sre: "once-only subpatterns" and "conditional subpatterns".



Follow-Ups:

Date: 2000-Sep-22 11:14
By: gvanrossum

Comment:
For Fred to negotiate with Fredrik.
-------------------------------------------------------

Date: 2000-Sep-22 11:21
By: jdnier

Comment:
Actually, '\z' is supported by pre, so at least that should be added to the docs.
-------------------------------------------------------

Date: 2000-Sep-28 06:01
By: fdrake

Comment:
Andrew, you're more in the know than I on this topic -- if I can get some text from you, I can mark it up.  Thanks!
-------------------------------------------------------

Date: 2000-Sep-28 14:50
By: akuchling

Comment:
Looking at the SRE code, it doesn't seem like it supports \z.  Lookbehinds do seem to be implemented, though; I'll work on producing some text for this.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115119&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 22:45:44 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 14:45:44 -0700
Subject: [Python-bugs-list] [Bug #113862] 2.0b1 lib.pdf, problems with bookmark titles
Message-ID: <200009282145.OAA02401@bush.i.sourceforge.net>

Bug #113862, was updated on 2000-Sep-08 01:48
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Wont Fix
Bug Group: None
Priority: 4
Summary: 2.0b1 lib.pdf, problems with bookmark titles

Details: In Acrobat Reader, 3.25 shows in the Bookmarks as "protect unhbox voidb@x kern.06envbox" etc.  It does show correctly as "__builtin__ -- Built-in functions" in the main window, and when printed.  3.26, same problem.  Other titles seem OK (haven't checked them all, though).



Follow-Ups:

Date: 2000-Sep-08 23:16
By: fdrake

Comment:
The bookmark entry for the copy_reg module has the same defect.  This is probably a result of the seriously painful hackery used to make the underscore be somewhat less special.

Must be fixed for 2.0 final.
-------------------------------------------------------

Date: 2000-Sep-20 22:32
By: fdrake

Comment:
Still not sure how to fix.

I'm reducing the priority of this since it isn't enough to hold off the release of 2.0.  This is also not new in 1.6 or 2.0, so appearantly it is survivable.

It should be fixed, but that may happen as part of the migration to a new markup language & translation tools.
-------------------------------------------------------

Date: 2000-Sep-28 14:45
By: fdrake

Comment:
Ok, I've tried a bunch of things, but pdflatex doesn't seem to want to put an underscore in the bookmarks.  I'll mark this as "won't fix" since the problems will probably all change when we switch to XML for the documentation, and fixing this isn't so important.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=113862&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 23:02:46 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 15:02:46 -0700
Subject: [Python-bugs-list] [Bug #115615] atof, atoi, atol  not behaving as methods
Message-ID: <200009282202.PAA03057@bush.i.sourceforge.net>

Bug #115615, was updated on 2000-Sep-28 14:31
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Wont Fix
Bug Group: None
Priority: 5
Summary: atof, atoi, atol  not behaving as methods

Details: Similar to lower(),  upper() etc shouldn't atof(),  atoi(),  atol()  behave as methods on the new String
objects?
------------------------------
Python 2.0b2 (#6, Sep 26 2000, 14:59:21) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.

>>> "23".atoi()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: atoi
--------------------------------
similarly for atof(), atol()


Follow-Ups:

Date: 2000-Sep-28 15:02
By: bwarsaw

Comment:
No.  When we were designing the string methods, we decided not to include atof(), atoi(), and atol() since the built-ins int(), long(), and float() now do everything those functions did and they should be used instead.

You'll notice that for backwards compatibility, string.atof(), string.atoi(), and string.atol() are defined in terms of the respective builtins.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115615&group_id=5470


From noreply@sourceforge.net  Thu Sep 28 23:21:35 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 15:21:35 -0700
Subject: [Python-bugs-list] [Bug #110667] select module: Bug in select.select() (PR#365)
Message-ID: <200009282221.PAA03887@bush.i.sourceforge.net>

Bug #110667, was updated on 2000-Jul-31 14:12
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Works For Me
Bug Group: Platform-specific
Priority: 5
Summary: select module: Bug in select.select() (PR#365)

Details: Jitterbug-Id: 365
Submitted-By: r32813@email.sps.mot.com
Date: Wed, 21 Jun 2000 12:00:54 -0400 (EDT)
Version: 1.5.2
OS: AIX 4.3.1


 The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when 
 this command was run:-
 
       select.select(waitList, [], [], timeWait)
 
 This command worked fine in Python 1.5.1 build and also fine on Python
 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on
 2 AIX machines that we have. 

 






====================================================================
Audit trail:
Tue Jul 11 08:24:19 2000	guido	moved from incoming to open

Follow-Ups:

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] select module: Bug in select.select() (PR#365)
Date: Wed, 21 Jun 2000 17:08:33 -0500

>  The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when 
>  this command was run:-
>  
>        select.select(waitList, [], [], timeWait)
>  
>  This command worked fine in Python 1.5.1 build and also fine on Python
>  1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on
>  2 AIX machines that we have. 

Could you give us some more information?  You're indicating that it's
platform specific; we don't have an AIX box.  I'm guessing it's not
obvious that our code is wrong, but it may violate some guidelines
given by AIX manuals.  If we ever want to fix this, we'll need to
interact with you.  the first thing we need is a decent stack trace;
we'll take it from there.

If you could investigate this on your own and come up with a fix, that
would probably the best solution...

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: "Wahmeng Wong" <r32813@email.sps.mot.com>
Subject: Re: [Python-bugs-list] select module: Bug in select.select() (PR#365)
Date: Thu, 22 Jun 2000 19:02:11 -0700

This is a multi-part message in MIME format.
--------------F9E74BCE6963FE221E423528
Content-Type: multipart/alternative;
 boundary="------------FF8E270086909CA1DBDDA697"


--------------FF8E270086909CA1DBDDA697
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Guido,

Below is the dbx information from the coredump. This only occurs when the
select.select() function is used within a thread. This same error occurs on
both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does not
occur on AIX 4.1.4.

$ dbx -I ./Modules ./python core
Type 'help' for help.
reading symbolic information ...
[using memory image in core]

Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c"
($t2)
  235           PyObject *tout = Py_None;

We have been able to reproduce the coredump by modifying the test_select.py
to perform the test within a thread. Attached is the modified file called
test_thread_select.py. Just place this file in the Lib/test directory to see
this problem.

Thanks for all your help.

Regards,
Wah Meng

Guido van Rossum wrote:

> >  The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when
> >  this command was run:-
> >
> >        select.select(waitList, [], [], timeWait)
> >
> >  This command worked fine in Python 1.5.1 build and also fine on Python
> >  1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on
> >  2 AIX machines that we have.
>
> Could you give us some more information?  You're indicating that it's
> platform specific; we don't have an AIX box.  I'm guessing it's not
> obvious that our code is wrong, but it may violate some guidelines
> given by AIX manuals.  If we ever want to fix this, we'll need to
> interact with you.  the first thing we need is a decent stack trace;
> we'll take it from there.
>
> If you could investigate this on your own and come up with a fix, that
> would probably the best solution...
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)

--------------FF8E270086909CA1DBDDA697
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Guido,
<p>Below is the dbx information from the coredump. This only occurs when
the select.select() function is used within a thread. This same error occurs
on both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does
not occur on AIX 4.1.4.
<p><tt>$ dbx -I ./Modules ./python core</tt>
<br><tt>Type 'help' for help.</tt>
<br><tt>reading symbolic information ...</tt>
<br><tt>[using memory image in core]</tt><tt></tt>
<p><tt>Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c"
($t2)</tt>
<br><tt>&nbsp; 235&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PyObject *tout = Py_None;</tt>
<p>We have been able to reproduce the coredump by modifying the test_select.py
to perform the test within a thread. Attached is the modified file called
test_thread_select.py. Just place this file in the Lib/test directory to
see this problem.
<p>Thanks for all your help.
<p>Regards,
<br>Wah Meng
<p>Guido van Rossum wrote:
<blockquote TYPE=CITE>>&nbsp; The python 1.5.2 built on AIX 4.3.1.0 platform
created a coredump when
<br>>&nbsp; this command was run:-
<br>>
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; select.select(waitList,
[], [], timeWait)
<br>>
<br>>&nbsp; This command worked fine in Python 1.5.1 build and also fine
on Python
<br>>&nbsp; 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0
build on
<br>>&nbsp; 2 AIX machines that we have.
<p>Could you give us some more information?&nbsp; You're indicating that
it's
<br>platform specific; we don't have an AIX box.&nbsp; I'm guessing it's
not
<br>obvious that our code is wrong, but it may violate some guidelines
<br>given by AIX manuals.&nbsp; If we ever want to fix this, we'll need
to
<br>interact with you.&nbsp; the first thing we need is a decent stack
trace;
<br>we'll take it from there.
<p>If you could investigate this on your own and come up with a fix, that
<br>would probably the best solution...
<p>--Guido van Rossum (home page: <a href="http://www.python.org/~guido/">http://www.python.org/~guido/</a>)</blockquote>
</html>

--------------FF8E270086909CA1DBDDA697--

--------------F9E74BCE6963FE221E423528
Content-Type: application/x-unknown-content-type-Python.File;
 name="test_thread_select.py"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="test_thread_select.py"

IyBUZXN0aW5nIHNlbGVjdCBtb2R1bGUNCmZyb20gdGVzdF9zdXBwb3J0IGltcG9ydCB2ZXJi
b3NlDQppbXBvcnQgc2VsZWN0LCB0aHJlYWQsIFF1ZXVlDQppbXBvcnQgb3MNCg0KIyB0ZXN0
IHNvbWUga25vd24gZXJyb3IgY29uZGl0aW9ucw0KdHJ5Og0KICAgIHJmZCwgd2ZkLCB4ZmQg
PSBzZWxlY3Quc2VsZWN0KDEsIDIsIDMpDQpleGNlcHQgVHlwZUVycm9yOg0KICAgIHBhc3MN
CmVsc2U6DQogICAgcHJpbnQgJ2V4cGVjdGVkIFR5cGVFcnJvciBleGNlcHRpb24gbm90IHJh
aXNlZCcNCg0KY2xhc3MgTm9wZToNCiAgICBwYXNzDQoNCmNsYXNzIEFsbW9zdDoNCiAgICBk
ZWYgZmlsZW5vKHNlbGYpOg0KICAgICAgICByZXR1cm4gJ2ZpbGVubycNCiAgICANCnRyeToN
CiAgICByZmQsIHdmZCwgeGZkID0gc2VsZWN0LnNlbGVjdChbTm9wZSgpXSwgW10sIFtdKQ0K
ZXhjZXB0IFR5cGVFcnJvcjoNCiAgICBwYXNzDQplbHNlOg0KICAgIHByaW50ICdleHBlY3Rl
ZCBUeXBlRXJyb3IgZXhjZXB0aW9uIG5vdCByYWlzZWQnDQoNCnRyeToNCiAgICByZmQsIHdm
ZCwgeGZkID0gc2VsZWN0LnNlbGVjdChbQWxtb3N0KCldLCBbXSwgW10pDQpleGNlcHQgVHlw
ZUVycm9yOg0KICAgIHBhc3MNCmVsc2U6DQogICAgcHJpbnQgJ2V4cGVjdGVkIFR5cGVFcnJv
ciBleGNlcHRpb24gbm90IHJhaXNlZCcNCg0KDQpkZWYgdGVzdChxKToNCiAgICAgICAgaW1w
b3J0IHN5cw0KICAgICAgICBpZiBzeXMucGxhdGZvcm1bOjNdIGluICgnd2luJywgJ21hYycs
ICdvczInKToNCiAgICAgICAgICAgICAgICBpZiB2ZXJib3NlOg0KICAgICAgICAgICAgICAg
ICAgICAgICAgcHJpbnQgIkNhbid0IHRlc3Qgc2VsZWN0IGVhc2lseSBvbiIsIHN5cy5wbGF0
Zm9ybQ0KICAgICAgICAgICAgICAgIHJldHVybg0KICAgICAgICBjbWQgPSAnZm9yIGkgaW4g
MCAxIDIgMyA0IDUgNiA3IDggOTsgZG8gZWNobyB0ZXN0aW5nLi4uOyBzbGVlcCAxOyBkb25l
Jw0KICAgICAgICBwID0gb3MucG9wZW4oY21kLCAncicpDQogICAgICAgIGZvciB0b3V0IGlu
ICgwLCAxLCAyLCA0LCA4LCAxNikgKyAoTm9uZSwpKjEwOg0KICAgICAgICAgICAgICAgIGlm
IHZlcmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICBwcmludCAndGltZW91dCA9Jywg
dG91dA0KICAgICAgICAgICAgICAgIHJmZCwgd2ZkLCB4ZmQgPSBzZWxlY3Quc2VsZWN0KFtw
XSwgW10sIFtdLCB0b3V0KQ0KIyMgICAgICAgICAgICAgIHByaW50IHJmZCwgd2ZkLCB4ZmQN
CiAgICAgICAgICAgICAgICBpZiAocmZkLCB3ZmQsIHhmZCkgPT0gKFtdLCBbXSwgW10pOg0K
ICAgICAgICAgICAgICAgICAgICAgICAgY29udGludWUNCiAgICAgICAgICAgICAgICBpZiAo
cmZkLCB3ZmQsIHhmZCkgPT0gKFtwXSwgW10sIFtdKToNCiAgICAgICAgICAgICAgICAgICAg
ICAgIGxpbmUgPSBwLnJlYWRsaW5lKCkNCiAgICAgICAgICAgICAgICAgICAgICAgIGlmIHZl
cmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByaW50IGBsaW5lYA0K
ICAgICAgICAgICAgICAgICAgICAgICAgaWYgbm90IGxpbmU6DQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGlmIHZlcmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgcHJpbnQgJ0VPRicNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgYnJlYWsNCiAgICAgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlDQogICAgICAg
ICAgICAgICAgcHJpbnQgJ0hlaD8nDQogICAgICAgIHAuY2xvc2UoKQ0KICAgICAgICBxLnB1
dCgxKQ0KDQoNCnEgPSBRdWV1ZS5RdWV1ZSgxKQ0KdGhyZWFkLnN0YXJ0X25ld190aHJlYWQo
dGVzdCwocSwpKQ0KI3dhaXQgZm9yIHRocmVhZCB0byBjb21wbGV0ZSB0ZXN0IGZ1bmN0aW9u
DQpkb25lID0gcS5nZXQoKQ0KcHJpbnQgJ3RocmVhZCBjb21wbGV0ZWQgdGVzdCwgZXhpdGlu
ZycNCg0K
--------------F9E74BCE6963FE221E423528--



-------------------------------------------------------

Date: 2000-Aug-01 14:01
By: none

Comment:
From: Guido van Rossum <guido@python.org>
Subject: Re: [Python-bugs-list] select module: Bug in select.select() (PR#365)
Date: Fri, 23 Jun 2000 11:01:40 -0500

> Below is the dbx information from the coredump. This only occurs when the
> select.select() function is used within a thread. This same error occurs on
> both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does not
> occur on AIX 4.1.4.
> 
> $ dbx -I ./Modules ./python core
> Type 'help' for help.
> reading symbolic information ...
> [using memory image in core]
> 
> Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c"
> ($t2)
>   235           PyObject *tout = Py_None;

Thanks.  Could you do this again and also type the "bt" (backtrace)
command?  That would perhaps be more helpful.  We can't reproduce this
here since we don't have access to AIX!  (Even if we ha,d it would be
low priority :-( ).

--Guido van Rossum (home page: http://www.python.org/~guido/)


-------------------------------------------------------

Date: 2000-Sep-22 21:55
By: tim_one

Comment:
Just putting the fellow's test_thread_select.py here as plain text (it's given only as base64 below):

# Testing select module
from test_support import verbose
import select, thread, Queue
import os

# test some known error conditions
try:
    rfd, wfd, xfd = select.select(1, 2, 3)
except TypeError:
    pass
else:
    print 'expected TypeError exception not raised'

class Nope:
    pass

class Almost:
    def fileno(self):
        return 'fileno'
    
try:
    rfd, wfd, xfd = select.select([Nope()], [], [])
except TypeError:
    pass
else:
    print 'expected TypeError exception not raised'

try:
    rfd, wfd, xfd = select.select([Almost()], [], [])
except TypeError:
    pass
else:
    print 'expected TypeError exception not raised'


def test(q):
        import sys
        if sys.platform[:3] in ('win', 'mac', 'os2'):
                if verbose:
                        print "Can't test select easily on", sys.platform
                return
        cmd = 'for i in 0 1 2 3 4 5 6 7 8 9; do echo testing...; sleep 1; done'
        p = os.popen(cmd, 'r')
        for tout in (0, 1, 2, 4, 8, 16) + (None,)*10:
                if verbose:
                        print 'timeout =', tout
                rfd, wfd, xfd = select.select([p], [], [], tout)
##              print rfd, wfd, xfd
                if (rfd, wfd, xfd) == ([], [], []):
                        continue
                if (rfd, wfd, xfd) == ([p], [], []):
                        line = p.readline()
                        if verbose:
                                print `line`
                        if not line:
                                if verbose:
                                        print 'EOF'
                                break
                        continue
                print 'Heh?'
        p.close()
        q.put(1)


q = Queue.Queue(1)
thread.start_new_thread(test,(q,))
#wait for thread to complete test function
done = q.get()
print 'thread completed test, exiting'

-------------------------------------------------------

Date: 2000-Sep-28 15:21
By: akuchling

Comment:
It seems impossible to reproduce this without actually having an AIX box, and IBM has no equivalent of Compaq's
test drive, unfortunately.

At first blush, it's difficult to come up with
a hypothesis; why would the *tout = Py_None line cause 
a segfault?  Perhaps a refcounting bug 
decreased the RC of _Py_None_struct to 0 
and caused it to be deallocated, but that shouldn't crash
on that line of code.

I'm going to mark this "Works for Me", pending 
further reports from the original submitter, or from
anyone else.  

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110667&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 00:20:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 16:20:26 -0700
Subject: [Python-bugs-list] [Bug #115625] python2.0b2 test_pty fails on x86 Solaris 8
Message-ID: <200009282320.QAA30913@delerium.i.sourceforge.net>

Bug #115625, was updated on 2000-Sep-28 16:20
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: python2.0b2 test_pty fails on x86 Solaris 8

Details: When I enable the termios module in Python 2.0b2 on x86
Solaris 8, the test_pty test fails with the following
message:

test test_pty failed -- master_fd is not a tty

I have no special interest in the termios module,
but I thought I'd report the problem since the README
file suggests enabling it if possible.  I have not tried
any other platforms so I cannot tell if the problem is
system-specific.

It would be worth checking the list of suggested Unix
modules in the README file against the Setup file, because
some files suggested in the README were already uncommented,
and others were marked as obsolete (e.g. soundex).

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115625&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 00:23:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 16:23:42 -0700
Subject: [Python-bugs-list] [Bug #115609] Please include regexdemo.py in main distribution
Message-ID: <200009282323.QAA30963@delerium.i.sourceforge.net>

Bug #115609, was updated on 2000-Sep-28 13:11
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Please include regexdemo.py in main distribution

Details: I would like to recommend that Guido's regexdemo.py be included in the main distribution of 2.0.  (It was included in as a "demo" in the source distribution of v1.5.2.)

I find regexdemo to be a very useful tool for debugging my REs.  I think others would find it useful too, but since it is buried fairly far down in the source distribution, it is rather hard for newcomers to find.  I therefore recommend you include it in the "tools" directory of the main distribution.

As you know, REs are very difficult to learn (and even to use after you "learn" them!), so I think an excellent aid like regexdemo.py should be given more prominence.

thanks as always,

=g2

Follow-Ups:

Date: 2000-Sep-28 16:23
By: fdrake

Comment:
regexdemo.py is located in Demo/tkinter/guido/ and should be in the source distribution (don't know about Windows).  It is out of date as it uses regex instead of re; Guido will need to decide whether to update this or drop it before 2.0.  If it can't be updated before then, it should be dropped as regex is obsolete.

If someone decides to resurrect or replace it with an up to date version at a later time, it can be added back.

Patches to update it would be welcome.  Assigned to Guido for a decision on the disposition of this demo.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115609&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 00:29:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 16:29:55 -0700
Subject: [Python-bugs-list] [Bug #115608] Readme.txt
Message-ID: <200009282329.QAB31270@delerium.i.sourceforge.net>

Bug #115608, was updated on 2000-Sep-28 13:04
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: Not a Bug
Priority: 5
Summary: Readme.txt

Details: The Readme.txt file says "the Tk interface is not enabled by default".  However, Tk comes with the 2.0 Windows distribution (at least), and appears to work fine immediately after installation.

I suggest that Readme be clarified with "(except on Windows)" or whatever.

thanks for all the great work, guys!

=g2

Follow-Ups:

Date: 2000-Sep-28 16:29
By: fdrake

Comment:
Clarified in README revision 1.99.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115608&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 01:31:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 17:31:01 -0700
Subject: [Python-bugs-list] [Bug #115625] python2.0b2 test_pty fails on x86 Solaris 8
Message-ID: <200009290031.RAA08753@bush.i.sourceforge.net>

Bug #115625, was updated on 2000-Sep-28 16:20
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: python2.0b2 test_pty fails on x86 Solaris 8

Details: When I enable the termios module in Python 2.0b2 on x86
Solaris 8, the test_pty test fails with the following
message:

test test_pty failed -- master_fd is not a tty

I have no special interest in the termios module,
but I thought I'd report the problem since the README
file suggests enabling it if possible.  I have not tried
any other platforms so I cannot tell if the problem is
system-specific.

It would be worth checking the list of suggested Unix
modules in the README file against the Setup file, because
some files suggested in the README were already uncommented,
and others were marked as obsolete (e.g. soundex).

Follow-Ups:

Date: 2000-Sep-28 17:31
By: fdrake

Comment:
Updated the information about potentially interesting extensions in the README file, revision 1.100.

The test_pty failure remains.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115625&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 01:53:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 17:53:16 -0700
Subject: [Python-bugs-list] [Bug #115492] 1 test failed: test_unicodedata
Message-ID: <200009290053.RAA01709@delerium.i.sourceforge.net>

Bug #115492, was updated on 2000-Sep-27 11:45
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: 1 test failed: test_unicodedata

Details: Running the self-test ("make test") for 2.0b2 under

$ uname -a
SunOS jimi 5.6 Generic_105181-17 sun4u sparc SUNW,Ultra-5_10

...
test_unicodedata
test test_unicodedata failed -- Writing: 'e052289ecef97fc89c794cf663cb74a64631d34e', expected: 'b886
84df19fca8c3d0ab31f040dd8de89f7836fe'

$pwd
/var/build/Python-2.0b2/Lib/test

$ ../../python test_unicodedata.py 
Testing Unicode Database...
Methods: e052289ecef97fc89c794cf663cb74a64631d34e
Functions: 5abd7e976848725e58f5834a0e5e37615f40d3a2
API: ok

$ cat output/test_unicodedata 
test_unicodedata
Testing Unicode Database...
Methods: b88684df19fca8c3d0ab31f040dd8de89f7836fe
Functions: 5abd7e976848725e58f5834a0e5e37615f40d3a2
API: ok


Follow-Ups:

Date: 2000-Sep-27 12:13
By: tim_one

Comment:
Changed to platform-specific and assigned to MAL.  Looks like the little-endian vs big-endian glitch again to me.

-------------------------------------------------------

Date: 2000-Sep-27 12:25
By: lemburg

Comment:
I have already checked in a patch which should solve this
problem -- can't check it though, since I don't have access to
a big endian machine.

The CVS tree has the patched versions of the test_unicodedata.py
file and the new test output.

-------------------------------------------------------

Date: 2000-Sep-28 17:53
By: mdb

Comment:
FYI, I grabbed a snapshot of the CVS tree at 00 GMT, 29 Sep 2000, compiled using gcc-2.95.2, and confirmed that the test_unicodedata.py script successfully completes under Solaris-2.6/Sparc (i.e., same platform as original).
Thanks.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115492&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 03:33:26 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Sep 2000 19:33:26 -0700
Subject: [Python-bugs-list] [Bug #110864] problem with MSVC library (bogus)
Message-ID: <200009290233.TAA13238@bush.i.sourceforge.net>

Bug #110864, was updated on 2000-Aug-01 14:39
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: None
Bug Group: Irreproducible
Priority: 1
Summary: problem with MSVC library (bogus)

Details: Jitterbug-Id: 364
Submitted-By: tong@aristotech.com
Date: Tue, 20 Jun 2000 18:38:41 -0400 (EDT)
Version: 1.5
OS: win NT


We just moved to msvc6.0 and since then, some of our developers (including
myself)will crash on following every time we run from msvc debugger:

c:\vsvc98\crt\src\sbheap.c
    //  test if previous entry was free with an index change or allocated
    if (!((sizePrev & 1) == 0 && indPrev == indEntry))
    {
        //  connect pEntry entry to indEntry
        //  add entry to the start of the bucket list
        pHead = (PENTRY)((char *)&pGroup->listHead[indEntry] - sizeof(int));
        pEntry->pEntryNext = pHead->pEntryNext;
        pEntry->pEntryPrev = pHead;
        pHead->pEntryNext = pEntry;
        pEntry->pEntryNext->pEntryPrev = pEntry;

I'm using NT4.0 service pack 6 but developers who use service pack4 and pack5
also encouter this problem.

We use python/tk.



====================================================================
Audit trail:
Tue Jul 11 08:24:19 2000	guido	moved from incoming to irreproducible

Follow-Ups:

Date: 2000-Aug-01 14:40
By: none

Comment:
From: "Mark Hammond" <mhammond@skippinet.com.au>
Subject: RE: [Python-bugs-list] PRIVATE: Unhandled exception in python.exe (MSVCRTD.DLL): 0Xc0000005: Access Violation (PR#364)
Date: Wed, 21 Jun 2000 09:57:40 +1000

It appears you have simply quoted the code from the MSVC runtime library.

Can you give us some details about the script that is running?  Does it use
any extension modules?

You should also be able to provide the complete stack trace when the
program crashes, as shown in the MSVC debugger "Call Stack" window.

If you can provide this, we will be able to look into it further.  However,
Python is used successfully in many many projects.  The most likely
candidate is your own C code, if any exists in the project.  If not, the
next most likely candidate is mixing the CRT library versions - you mention
MSVCRTD.DLL.  You must ensure that _all_ code loaded, including Python
itself, is using this debug DLL.  This generally means you need to be
running with the "_d" versions of the Python binaries, and with all your
code compiled with "/MDd".

Carefully check the MSVC "Output" window - there should be exactly one
reference to "msvcrt.dll" _or_ exactly one reference to "msvcrtd.dll" - if
references to both exist, or the same DLL name from different directories
has been loaded twice, that is your problem.

Mark.

> -----Original Message-----
> From: python-bugs-list-admin@python.org
> [mailto:python-bugs-list-admin@python.org]On Behalf Of
> tong@aristotech.com
> Sent: Wednesday, 21 June 2000 8:39 AM
> To: python-bugs-list@python.org
> Cc: bugs-py@python.org
> Subject: [Python-bugs-list] PRIVATE: Unhandled exception in python.exe
> (MSVCRTD.DLL): 0Xc0000005: Access Violation (PR#364)
>
>
> Full_Name: Siu-Tong Hui
> Version: 1.5
> OS: win NT
> Submission from: node-d8e9472.powerinter.net (216.233.71.2)
>
>
> We just moved to msvc6.0 and since then, some of our developers
> (including
> myself)will crash on following every time we run from msvc debugger:
>
> c:\vsvc98\crt\src\sbheap.c
>     //  test if previous entry was free with an index change or allocated
>     if (!((sizePrev & 1) == 0 && indPrev == indEntry))
>     {
>         //  connect pEntry entry to indEntry
>         //  add entry to the start of the bucket list
>         pHead = (PENTRY)((char *)&pGroup->listHead[indEntry] -
> sizeof(int));
>         pEntry->pEntryNext = pHead->pEntryNext;
>         pEntry->pEntryPrev = pHead;
>         pHead->pEntryNext = pEntry;
>         pEntry->pEntryNext->pEntryPrev = pEntry;
>
> I'm using NT4.0 service pack 6 but developers who use service
> pack4 and pack5
> also encouter this problem.
>
> We use python/tk.
>
>
>
> _______________________________________________
> Python-bugs-list maillist  -  Python-bugs-list@python.org
> http://www.python.org/mailman/listinfo/python-bugs-list
>



-------------------------------------------------------

Date: 2000-Sep-07 15:05
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-28 19:33
By: fdrake

Comment:
Appearantly something screwy happened to the database; this had a status of "None", so I'm closing it.  ;)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110864&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 08:20:22 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 00:20:22 -0700
Subject: [Python-bugs-list] [Bug #115641] Dynamic Loading Fails on Mac OS X
Message-ID: <200009290720.AAA23310@bush.i.sourceforge.net>

Bug #115641, was updated on 2000-Sep-29 00:20
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Dynamic Loading Fails on Mac OS X

Details: Martin v. Loewis asked me to report that dynamic loading fails on Mac OS X.  I was able to successfully build the CVS version of Python following the directions posted by Dan Wolfe to Python-Dev:

http://www.python.org/pipermail/python-dev/2000-September/016289.html

However, I had some problems compiling the CVS version of Python/XML and reported them as a bug to Source Forge:

https://sourceforge.net/bugs/?func=detailbug&group_id=6473&bug_id=115544

Martin pointed out "how distutils comes up with the linker line: They read the configure-generated Makefile and scan for LDSHARED. So anything that was in the Python Makefile will be used when linking a distutils module."  He aksed me to try to build Python a few different ways, but they all failed.

When configured with:

./configure -with-threads -with-dyld --with-next-framework -with-suffix=.exe

Building Python produced the following:

cd Modules ; make OPT="-g -O2 -fno-common" VERSION="2.0" \
                prefix="/usr/local" exec_prefix="/usr/local" all
make[2]: Nothing to be done for `all'.
libtool -o libpython2.0.dylib -dynamic  libpython2.0.a -framework System  
ld: for architecture ppc
ld: Undefined symbols:
restFP
saveFP
___eprintf
_environ
libtool: internal link edit command failed
make[1]: *** [libpython2.0.dylib] Error 1
make: *** [python.exe] Error 2

When line 579 in "configure" is modified to the following:

then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress'

building Python results in the following:

for i in Parser Grammar Objects Python Modules; do \
                (cd $i; make VERSION="2.0" add2lib); done
make[2]: `add2lib' is up to date.
make[2]: Nothing to be done for `add2lib'.
make[2]: `add2lib' is up to date.
make[2]: `add2lib' is up to date.
make[2]: `add2lib' is up to date.
libtool -o libpython2.0.dylib -dynamic  libpython2.0.a -framework System  
ld: for architecture ppc
ld: Undefined symbols:
___eprintf
_environ
libtool: internal link edit command failed
make[1]: *** [libpython2.0.dylib] Error 1
make: *** [python.exe] Error 2

I have only been using Mac OS X for a few days (and the development tools even less), so this could definitely be due to user error, but I will help out however I can.



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115641&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 08:57:27 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 00:57:27 -0700
Subject: [Python-bugs-list] [Bug #115491] 2.0b2:test_unicodedata fails: Sparc Solaris 2.7/6
Message-ID: <200009290757.AAA24561@bush.i.sourceforge.net>

Bug #115491, was updated on 2000-Sep-27 11:22
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: 2.0b2:test_unicodedata fails: Sparc Solaris 2.7/6

Details: Sparc Solaris 2.7
gcc 2.95.2
test_methods sha hexdigest output does not match expected results. 

Note: test_unicodedata.py script differs on windows version of 2.0b2 (is same as version supplied with
unix source 2.0b1). 

Sorry if this has already been reported. Did not see in current bug list. 

Follow-Ups:

Date: 2000-Sep-27 12:25
By: lemburg

Comment:
I have already checked in a patch which should solve this
problem -- can't check it though, since I don't have access to
a big endian machine.

The CVS tree has the patched versions of the test_unicodedata.py
file and the new test output.

-------------------------------------------------------

Date: 2000-Sep-29 00:57
By: lemburg

Comment:
Same bug as #115492.

Closed.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115491&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 08:57:29 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 00:57:29 -0700
Subject: [Python-bugs-list] [Bug #115492] 1 test failed: test_unicodedata
Message-ID: <200009290757.AAA24570@bush.i.sourceforge.net>

Bug #115492, was updated on 2000-Sep-27 11:45
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Summary: 1 test failed: test_unicodedata

Details: Running the self-test ("make test") for 2.0b2 under

$ uname -a
SunOS jimi 5.6 Generic_105181-17 sun4u sparc SUNW,Ultra-5_10

...
test_unicodedata
test test_unicodedata failed -- Writing: 'e052289ecef97fc89c794cf663cb74a64631d34e', expected: 'b886
84df19fca8c3d0ab31f040dd8de89f7836fe'

$pwd
/var/build/Python-2.0b2/Lib/test

$ ../../python test_unicodedata.py 
Testing Unicode Database...
Methods: e052289ecef97fc89c794cf663cb74a64631d34e
Functions: 5abd7e976848725e58f5834a0e5e37615f40d3a2
API: ok

$ cat output/test_unicodedata 
test_unicodedata
Testing Unicode Database...
Methods: b88684df19fca8c3d0ab31f040dd8de89f7836fe
Functions: 5abd7e976848725e58f5834a0e5e37615f40d3a2
API: ok


Follow-Ups:

Date: 2000-Sep-27 12:13
By: tim_one

Comment:
Changed to platform-specific and assigned to MAL.  Looks like the little-endian vs big-endian glitch again to me.

-------------------------------------------------------

Date: 2000-Sep-27 12:25
By: lemburg

Comment:
I have already checked in a patch which should solve this
problem -- can't check it though, since I don't have access to
a big endian machine.

The CVS tree has the patched versions of the test_unicodedata.py
file and the new test output.

-------------------------------------------------------

Date: 2000-Sep-28 17:53
By: mdb

Comment:
FYI, I grabbed a snapshot of the CVS tree at 00 GMT, 29 Sep 2000, compiled using gcc-2.95.2, and confirmed that the test_unicodedata.py script successfully completes under Solaris-2.6/Sparc (i.e., same platform as original).
Thanks.
-------------------------------------------------------

Date: 2000-Sep-29 00:57
By: lemburg

Comment:
Ok, so I'll take that as proof that the test also works on
big endian machines.

Bug closed.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115492&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 09:21:42 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 01:21:42 -0700
Subject: [Python-bugs-list] [Bug #115643] test_longexp Fails on OpenBSD
Message-ID: <200009290821.BAA25457@bush.i.sourceforge.net>

Bug #115643, was updated on 2000-Sep-29 01:21
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_longexp Fails on OpenBSD

Details: The test "test_longexp" fails on OpenBSD 2.5 shortly after 60,000 (sometime between 60,000 and 60,500) repetitions:

Traceback (most recent call last):
  File "test_longexp.py", line 4, in ?
    l = eval("[" + "2," * REPS + "]") 
MemoryError

On OpenBSD 2.7, it did not fail (and seemed to take the right amount of time), but returned the value "44".

The OpenBSD 2.5 system is using the most current CVS version.  The OpenBSD 2.7 system is using 2.0b2.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115643&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 09:31:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 01:31:20 -0700
Subject: [Python-bugs-list] [Bug #115617] poll problem on Linux 2.0.38, glibc 2.0.7
Message-ID: <200009290831.BAA25816@bush.i.sourceforge.net>

Bug #115617, was updated on 2000-Sep-28 14:37
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: poll problem on Linux 2.0.38, glibc 2.0.7

Details: Originally reported by Neil Schemenauer in a
comment in patch #101682:

After this patch the selectmodule compiles but test_poll fails with: 
File "Lib/test/test_poll.py", line 77, in poll_unit_tests 
r = p.poll() 
error: (9, 'Bad file descriptor') 

The kernel is 2.0.38 if that makes a difference.

Follow-Ups:

Date: 2000-Sep-29 01:31
By: jpettit

Comment:
I get the exact same result on OpenBSD 2.5 with the most current CVS version.  On OpenBSD 2.7 (this has Python 2.0b2 installed), I get:

test_support.TestSkipped: select.poll not defined -- skipping test_poll

Both versions of OpenBSD appear to support the poll mechanism.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115617&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 09:32:58 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 01:32:58 -0700
Subject: [Python-bugs-list] [Bug #115617] poll problem on Linux 2.0.38, glibc 2.0.7
Message-ID: <200009290832.BAA25852@bush.i.sourceforge.net>

Bug #115617, was updated on 2000-Sep-28 14:37
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: poll problem on Linux 2.0.38, glibc 2.0.7

Details: Originally reported by Neil Schemenauer in a
comment in patch #101682:

After this patch the selectmodule compiles but test_poll fails with: 
File "Lib/test/test_poll.py", line 77, in poll_unit_tests 
r = p.poll() 
error: (9, 'Bad file descriptor') 

The kernel is 2.0.38 if that makes a difference.

Follow-Ups:

Date: 2000-Sep-29 01:31
By: jpettit

Comment:
I get the exact same result on OpenBSD 2.5 with the most current CVS version.  On OpenBSD 2.7 (this has Python 2.0b2 installed), I get:

test_support.TestSkipped: select.poll not defined -- skipping test_poll

Both versions of OpenBSD appear to support the poll mechanism.

-------------------------------------------------------

Date: 2000-Sep-29 01:32
By: jpettit

Comment:
I get the exact same result on OpenBSD 2.5 with the most current CVS version.  On OpenBSD 2.7 (this has Python 2.0b2 installed), I get:

test_support.TestSkipped: select.poll not defined -- skipping test_poll

Both versions of OpenBSD appear to support the poll mechanism.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115617&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 09:39:51 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 01:39:51 -0700
Subject: [Python-bugs-list] [Bug #115341] Todays CVS python dumps core in gcmodule.c?!
Message-ID: <200009290839.BAA26148@bush.i.sourceforge.net>

Bug #115341, was updated on 2000-Sep-26 01:43
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Todays CVS python dumps core in gcmodule.c?!

Details: While tracing a bug in my own code, I got a core dump from python.
Since it is extremely difficult to find out WHERE in my 58k lines of code this
happens,  I can't just make a small test case. I thought at this stage it might
be useful to report anyway.

no203[204]lehmann%3% gdb =python core        
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `/usr/local/nonius/bin/python /usr/local/nonius/app/gui/to
p.py new orient x.non'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdb.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libutil.so.1...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/stropmodule.so.
..done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/timemodule.so..
.done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/_tkinter.so...
done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/local/nonius/lib/libBLT24.so...done.
Reading symbols from /usr/local/nonius/lib/libtk8.3.so...done.
Reading symbols from /usr/local/nonius/lib/libtcl8.3.so...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/mathmodule.so..
.done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/md5module.so...
done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/multi
array.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/_nump
y.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/umath
.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/structmodule.so
...done.
Reading symbols from /usr/local/nonius/app/misc/linux/_ntoolsmodule.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/_socketmodule.s
o...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/cStringIO.so...
done.
Reading symbols from /lib/libnss_files.so.2...done.
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/lapac
k_lite.so...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/selectmodule.so
...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/gdbmmodule.so..
.done.
Reading symbols from /usr/lib/libgdbm.so.2...done.
Reading symbols from /usr/local/nonius/lib/python2.0/lib-dynload/cPickle.so...
done.
Reading symbols from /usr/local/nonius/lib/python2.0/site-packages/Numeric/ranli
b.so...done.
#0  update_refs (containers=0x80bfec0) at ./gcmodule.c:150
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
(gdb) where
#0  update_refs (containers=0x80bfec0) at ./gcmodule.c:150
#1  0x808ae9b in collect (young=0x80bfec0, old=0x80bfecc) at ./gcmodule.c:382
#2  0x808b0cc in collect_generations () at ./gcmodule.c:488
#3  0x808b10f in _PyGC_Insert (op=0x8703824) at ./gcmodule.c:507
#4  0x807fbe4 in PyTuple_New (size=3) at tupleobject.c:87
#5  0x80561df in eval_code2 (co=0x8260518, globals=0x823fcd4, locals=0x0, 
    args=0x824d258, argcount=2, kws=0x8780190, kwcount=5, defs=0x8268f50, 
    defcount=1, owner=0x82699e4) at ceval.c:1561
#6  0x8057e3b in call_function (func=0x8269a7c, arg=0x87616cc, kw=0x87743ac)
    at ceval.c:2744
#7  0x8057a4b in PyEval_CallObjectWithKeywords (func=0x87816bc, arg=0x87616cc, 
    kw=0x87743ac) at ceval.c:2588
#8  0x806df7b in PyInstance_New (class=0x82699e4, arg=0x87616cc, kw=0x87743ac)
    at classobject.c:463
#9  0x8057b51 in call_builtin (func=0x82699e4, arg=0x87616cc, kw=0x87743ac)
    at ceval.c:2625
#10 0x8057a58 in PyEval_CallObjectWithKeywords (func=0x82699e4, arg=0x87616cc, 
    kw=0x87743ac) at ceval.c:2590
#11 0x8056bab in eval_code2 (co=0x81f0c58, globals=0x8201b1c, locals=0x0, 
    args=0x875cd8c, argcount=2, kws=0x875cd94, kwcount=0, defs=0x8201248, 
    defcount=1, owner=0x81fe94c) at ceval.c:1923
#12 0x805687c in eval_code2 (co=0x81f2de8, globals=0x8201b1c, locals=0x0, 
    args=0x866e2b0, argcount=2, kws=0x866e2b8, kwcount=0, defs=0x0, 
---Type <return> to continue, or q <return> to quit---
    defcount=0, owner=0x8201a4c) at ceval.c:1822
#13 0x805687c in eval_code2 (co=0x81ef9d0, globals=0x8201b1c, locals=0x0, 
    args=0x8203314, argcount=2, kws=0x820331c, kwcount=0, defs=0x8201098, 
    defcount=1, owner=0x81f4e8c) at ceval.c:1822
#14 0x805687c in eval_code2 (co=0x83d1d10, globals=0x83d8044, locals=0x0, 
    args=0x8202840, argcount=2, kws=0x8202848, kwcount=0, defs=0x0, 
    defcount=0, owner=0x85fc974) at ceval.c:1822
#15 0x805687c in eval_code2 (co=0x83cff98, globals=0x83d8044, locals=0x0, 
    args=0x8202068, argcount=1, kws=0x820206c, kwcount=0, defs=0x0, 
    defcount=0, owner=0x85fc974) at ceval.c:1822
#16 0x805687c in eval_code2 (co=0x83af368, globals=0x83b2574, locals=0x0, 
    args=0x86134f0, argcount=2, kws=0x0, kwcount=0, defs=0x83b2120, 
    defcount=1, owner=0x83c8b8c) at ceval.c:1822
#17 0x8057e3b in call_function (func=0x83bcc7c, arg=0x860fcac, kw=0x0)
    at ceval.c:2744
#18 0x8057a4b in PyEval_CallObjectWithKeywords (func=0x8203194, arg=0x860fcac, 
    kw=0x0) at ceval.c:2588
#19 0x806df7b in PyInstance_New (class=0x85fc974, arg=0x860fcac, kw=0x0)
    at classobject.c:463
#20 0x8057b51 in call_builtin (func=0x85fc974, arg=0x860fcac, kw=0x0)
    at ceval.c:2625
#21 0x8057a58 in PyEval_CallObjectWithKeywords (func=0x85fc974, arg=0x860fcac, 
    kw=0x0) at ceval.c:2590
---Type <return> to continue, or q <return> to quit---
#22 0x8056bab in eval_code2 (co=0x8163568, globals=0x80caecc, locals=0x0, 
    args=0x80d562c, argcount=2, kws=0x80d5634, kwcount=0, defs=0x0, 
    defcount=0, owner=0x860e81c) at ceval.c:1923
#23 0x805687c in eval_code2 (co=0x810e8f8, globals=0x80caecc, 
    locals=0x80caecc, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, owner=0x0) at ceval.c:1822
#24 0x80545d7 in PyEval_EvalCode (co=0x810e8f8, globals=0x80caecc, 
    locals=0x80caecc) at ceval.c:319
#25 0x80660b4 in run_node (n=0x80d3cc8, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", globals=0x80caecc, 
    locals=0x80caecc) at pythonrun.c:886
#26 0x8066079 in run_err_node (n=0x80d3cc8, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", globals=0x80caecc, 
    locals=0x80caecc) at pythonrun.c:874
#27 0x8066057 in PyRun_FileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", start=257, 
    globals=0x80caecc, locals=0x80caecc, closeit=1) at pythonrun.c:866
#28 0x8065821 in PyRun_SimpleFileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", closeit=1)
    at pythonrun.c:579
#29 0x80654d0 in PyRun_AnyFileEx (fp=0x80c6e68, 
    filename=0xbffff998 "/usr/local/nonius/app/gui/top.py", closeit=1)
    at pythonrun.c:459
---Type <return> to continue, or q <return> to quit---
#30 0x8051a40 in Py_Main (argc=4, argv=0xbffff814) at main.c:289
#31 0x8051566 in main (argc=5, argv=0xbffff814) at python.c:10
(gdb) 
(gdb) list
145     static void
146     update_refs(PyGC_Head *containers)
147     {
148             PyGC_Head *gc = containers->gc_next;
149             for (; gc != containers; gc=gc->gc_next) {
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
151             }
152     }
153
154     static int
(gdb) print gc
$1 = (PyGC_Head *) 0x0


Follow-Ups:

Date: 2000-Sep-26 04:31
By: gvanrossum

Comment:
Neil, can you have a look at this?
-------------------------------------------------------

Date: 2000-Sep-26 09:44
By: nascheme

Comment:
Since I can't reproduce this bug here are some things to 
try:

- compile Python with Py_DEBUG defined
- compile Python with Py_DEBUG and without GC
- at the start of your application call
  gc.set_debug(gc.DEBUG_LEAK) and gc.set_threshold(1)
- at the start of your application disable GC with gc.disable()
- recompile your extension modules
-------------------------------------------------------

Date: 2000-Sep-26 09:45
By: nascheme

Comment:
Since I can't reproduce this bug here are some things to 
try:

- compile Python with Py_DEBUG defined
- compile Python with Py_DEBUG and without GC
- at the start of your application call
  gc.set_debug(gc.DEBUG_LEAK) and gc.set_threshold(1)
- at the start of your application disable GC with gc.disable()
- recompile your extension modules
- checkout Python from a few days ago (cvs -D option)
-------------------------------------------------------

Date: 2000-Sep-29 01:39
By: hooft

Comment:
Sorry that I have not been able to react quicker. Unfortunately I won't be here in the weekend either.

- Py_Debug didn't change anything, it still dumped core.
- set_debug and set_threshold(1) : it still dumps core.

#0  update_refs (containers=0x80be6f8) at ./gcmodule.c:150
150                     gc->gc_refs = PyObject_FROM_GC(gc)->ob_refcnt;
(gdb) where
#0  update_refs (containers=0x80be6f8) at ./gcmodule.c:150
#1  0x8079db3 in collect (young=0x80be6f8, old=0x80be6f8) at ./gcmodule.c:382
#2  0x8079f57 in collect_generations () at ./gcmodule.c:471
#3  0x807a044 in _PyGC_Insert (op=0x87b1c14) at ./gcmodule.c:507
#4  0x80589cb in PyTuple_New (size=3) at tupleobject.c:87

(gdb) print containers
$50 = (PyGC_Head *) 0x80be6f8
(gdb) print gc
$51 = (PyGC_Head *) 0x0

I checked the first 50 or so references, no NULL encountered yet.

- gc.disable makes it continue, but I get all kinds of weird trouble
   with Tk:
Error: 3
AttributeError Exception in Tk callback
  Function: <function <lambda> at 0x87cb8e4> (type: <type 'function'>)
  Args: ('3652', '1', '1', '0', '1', '0', '-449121110', '0', '102', '0', '??', '0', '??', '0', '.138093276.141021828.141028308.142397076.142399772.142400300.142414228', '7', '544', '454', '1')
Traceback (innermost last):
  File "/usr/local/nonius/lib/python2.0/site-packages/Pmw/Pmw_0_8_4/lib/PmwBase.py", line 1668, in __call__
    args = apply(self.subst, args)
  File "/usr/local/nonius/lib/python2.0/lib-tk/Tkinter.py", line 1048, in _substitute
    e.widget = self._nametowidget(W)
  File "/usr/local/nonius/lib/python2.0/lib-tk/Tkinter.py", line 973, in nametowidget
    w = w._root()
  File "/usr/local/nonius/lib/python2.0/lib-tk/Tkinter.py", line 1012, in _root
    while w.master: w = w.master
AttributeError: 'Frame' instance has no attribute 'master'

And when the program terminates:
  [73562 refs]
  Print left references? [ny] n
  zsh: segmentation fault (core dumped)  collect new orient
  collect new orient  6.18s user 0.33s system 2% cpu 4:06.65 total

(gdb) where
#0  0x400e7129 in chunk_free (ar_ptr=0x4017bd60, p=0x87ce2f8) at malloc.c:3111
#1  0x400e6fba in __libc_free (mem=0x87ce300) at malloc.c:3023
#2  0x805941e in PyTuple_Fini () at tupleobject.c:562
#3  0x80762b6 in Py_Finalize () at pythonrun.c:243
#4  0x80777f4 in Py_Exit (sts=0) at pythonrun.c:1120
#5  0x8076d5e in PyErr_PrintEx (set_sys_last_vars=1) at pythonrun.c:708
#6  0x8076c6a in PyErr_Print () at pythonrun.c:671
#7  0x80769c1 in PyRun_SimpleFileEx (fp=0x80ce428, filename=0xbffff9a3 "/usr/local/nonius/app/gui/top.py", closeit=1) at pythonrun.c:582
#8  0x8076610 in PyRun_AnyFileEx (fp=0x80ce428, filename=0xbffff9a3 "/usr/local/nonius/app/gui/top.py", closeit=1) at pythonrun.c:459
#9  0x8051c40 in Py_Main (argc=3, argv=0xbffff834) at main.c:289
#10 0x8051756 in main (argc=4, argv=0xbffff834) at python.c:10

- to be able to enable Py_DEBUG I had to recompile all extension modules, so that point I skipped.
- I don't think "cvs -D" will be very useful, it is just the first time I'm seeing
   this here, but it might have been present already for a long time.

I am at a loss. I really have no clue how to reduce the program while maintaining the problem to make a simple test case. I can't even trace where my program is failing?!?!?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115341&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 13:35:53 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 05:35:53 -0700
Subject: [Python-bugs-list] [Bug #115595] Building extensions on windows
Message-ID: <200009291235.FAA26660@delerium.i.sourceforge.net>

Bug #115595, was updated on 2000-Sep-28 10:13
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Building extensions on windows

Details: Reported by Mike Fletcher:
Building extensions on windows(at least with MSVC) in debug mode link with the wrong python import library. This leads to crashes because the extension loads the release python dll instead of the debug dll:

Fatal Python error: PyThreadState_Get: no current thread


Follow-Ups:

Date: 2000-Sep-28 10:41
By: fdrake

Comment:
Assigned to Thomas Heller since he's the distutils-on-Windows export!
-------------------------------------------------------

Date: 2000-Sep-29 05:35
By: theller

Comment:
According to my tests, the bug seems fixed with the recent
changes I made.
I'm still leaving it open because I'm still working on the
library stuff.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115595&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 13:43:31 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 05:43:31 -0700
Subject: [Python-bugs-list] [Bug #115658] Minor spelling mistakes in tutorial of beta2 documentation
Message-ID: <200009291243.FAA26886@delerium.i.sourceforge.net>

Bug #115658, was updated on 2000-Sep-29 05:43
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Minor spelling mistakes in tutorial of beta2 documentation

Details: In section 3.1.3 of the tutorial, second paragraph, "internationalization" is spelt "internalization"

Also, at the start of section 3 (i the HTML version at least ) the prompt is described as he two chacters »> ( ie &#187; ) rather than >>>.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115658&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 14:32:08 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 06:32:08 -0700
Subject: [Python-bugs-list] [Bug #115641] Dynamic Loading Fails on Mac OS X
Message-ID: <200009291332.GAA28765@delerium.i.sourceforge.net>

Bug #115641, was updated on 2000-Sep-29 00:20
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: Dynamic Loading Fails on Mac OS X

Details: Martin v. Loewis asked me to report that dynamic loading fails on Mac OS X.  I was able to successfully build the CVS version of Python following the directions posted by Dan Wolfe to Python-Dev:

http://www.python.org/pipermail/python-dev/2000-September/016289.html

However, I had some problems compiling the CVS version of Python/XML and reported them as a bug to Source Forge:

https://sourceforge.net/bugs/?func=detailbug&group_id=6473&bug_id=115544

Martin pointed out "how distutils comes up with the linker line: They read the configure-generated Makefile and scan for LDSHARED. So anything that was in the Python Makefile will be used when linking a distutils module."  He aksed me to try to build Python a few different ways, but they all failed.

When configured with:

./configure -with-threads -with-dyld --with-next-framework -with-suffix=.exe

Building Python produced the following:

cd Modules ; make OPT="-g -O2 -fno-common" VERSION="2.0" \
                prefix="/usr/local" exec_prefix="/usr/local" all
make[2]: Nothing to be done for `all'.
libtool -o libpython2.0.dylib -dynamic  libpython2.0.a -framework System  
ld: for architecture ppc
ld: Undefined symbols:
restFP
saveFP
___eprintf
_environ
libtool: internal link edit command failed
make[1]: *** [libpython2.0.dylib] Error 1
make: *** [python.exe] Error 2

When line 579 in "configure" is modified to the following:

then LDSHARED='$(CC) $(LDFLAGS) -bundle -undefined suppress'

building Python results in the following:

for i in Parser Grammar Objects Python Modules; do \
                (cd $i; make VERSION="2.0" add2lib); done
make[2]: `add2lib' is up to date.
make[2]: Nothing to be done for `add2lib'.
make[2]: `add2lib' is up to date.
make[2]: `add2lib' is up to date.
make[2]: `add2lib' is up to date.
libtool -o libpython2.0.dylib -dynamic  libpython2.0.a -framework System  
ld: for architecture ppc
ld: Undefined symbols:
___eprintf
_environ
libtool: internal link edit command failed
make[1]: *** [libpython2.0.dylib] Error 1
make: *** [python.exe] Error 2

I have only been using Mac OS X for a few days (and the development tools even less), so this could definitely be due to user error, but I will help out however I can.



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115641&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 15:48:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 07:48:13 -0700
Subject: [Python-bugs-list] [Bug #115643] test_longexp Fails on OpenBSD
Message-ID: <200009291448.HAA31657@delerium.i.sourceforge.net>

Bug #115643, was updated on 2000-Sep-29 01:21
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_longexp Fails on OpenBSD

Details: The test "test_longexp" fails on OpenBSD 2.5 shortly after 60,000 (sometime between 60,000 and 60,500) repetitions:

Traceback (most recent call last):
  File "test_longexp.py", line 4, in ?
    l = eval("[" + "2," * REPS + "]") 
MemoryError

On OpenBSD 2.7, it did not fail (and seemed to take the right amount of time), but returned the value "44".

The OpenBSD 2.5 system is using the most current CVS version.  The OpenBSD 2.7 system is using 2.0b2.

Follow-Ups:

Date: 2000-Sep-29 07:48
By: jhylton

Comment:
Is it possible that there isn't much memory available on the 2.5 system?  When the test runs successfully on my Linux box, the Python process uses 32MB.

Are you sure that the 2.7 version returns 44?  It should return 65580 (the value of REPS).  Can you run it as "python -i test_longexp.py" and then print l.  Is it really only 44 elements long?

Are all the other tests succeeding?

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115643&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 15:52:16 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 07:52:16 -0700
Subject: [Python-bugs-list] [Bug #115658] Minor spelling mistakes in tutorial of beta2 documentation
Message-ID: <200009291452.HAA31811@delerium.i.sourceforge.net>

Bug #115658, was updated on 2000-Sep-29 05:43
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: Minor spelling mistakes in tutorial of beta2 documentation

Details: In section 3.1.3 of the tutorial, second paragraph, "internationalization" is spelt "internalization"

Also, at the start of section 3 (i the HTML version at least ) the prompt is described as he two chacters »> ( ie &#187; ) rather than >>>.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115658&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 16:18:05 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 08:18:05 -0700
Subject: [Python-bugs-list] [Bug #115658] Minor spelling mistakes in tutorial of beta2 documentation
Message-ID: <200009291518.IAA00341@delerium.i.sourceforge.net>

Bug #115658, was updated on 2000-Sep-29 05:43
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 6
Summary: Minor spelling mistakes in tutorial of beta2 documentation

Details: In section 3.1.3 of the tutorial, second paragraph, "internationalization" is spelt "internalization"

Also, at the start of section 3 (i the HTML version at least ) the prompt is described as he two chacters »> ( ie &#187; ) rather than >>>.


Follow-Ups:

Date: 2000-Sep-29 08:18
By: fdrake

Comment:
Fixed in Doc/tut/tut..tex revision 1.118 -- the problem with the prompt occurred in two other places as well.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115658&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 16:21:50 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 08:21:50 -0700
Subject: [Python-bugs-list] [Bug #115643] test_longexp Fails on OpenBSD
Message-ID: <200009291521.IAA08757@bush.i.sourceforge.net>

Bug #115643, was updated on 2000-Sep-29 01:21
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_longexp Fails on OpenBSD

Details: The test "test_longexp" fails on OpenBSD 2.5 shortly after 60,000 (sometime between 60,000 and 60,500) repetitions:

Traceback (most recent call last):
  File "test_longexp.py", line 4, in ?
    l = eval("[" + "2," * REPS + "]") 
MemoryError

On OpenBSD 2.7, it did not fail (and seemed to take the right amount of time), but returned the value "44".

The OpenBSD 2.5 system is using the most current CVS version.  The OpenBSD 2.7 system is using 2.0b2.

Follow-Ups:

Date: 2000-Sep-29 07:48
By: jhylton

Comment:
Is it possible that there isn't much memory available on the 2.5 system?  When the test runs successfully on my Linux box, the Python process uses 32MB.

Are you sure that the 2.7 version returns 44?  It should return 65580 (the value of REPS).  Can you run it as "python -i test_longexp.py" and then print l.  Is it really only 44 elements long?

Are all the other tests succeeding?

-------------------------------------------------------

Date: 2000-Sep-29 08:21
By: jpettit

Comment:
It appears that the 2.7 issue is my own fault, I mis-typed Python and accidently invoked Python 1.6.  I thought I was careful to check that, but apparently not.  Sorry.

On the 2.5 system, it is a Pentium 133 with 64MB of memory.  Using "top", it shows the memory size of Python to be 32MB, but there appears to be plenty of swap space left.  Here's the memory line from "top" just before it raises the exception:

Memory: Real: 31M/40M act/tot  Free: 1224K  Swap: 3560K/48M used/tot

The 2.7 seems to work fine, and it has only 32MB of RAM.  Of course, I am also using the current version in CVS on the 2.5 system and 2.0b2 on the 2.7 system.  I am going to try the CVS version on 2.7, but it will take me a while to setup due to a slow modem link.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115643&group_id=5470


From jeremy@beopen.com  Fri Sep 29 16:30:59 2000
From: jeremy@beopen.com (Jeremy Hylton)
Date: Fri, 29 Sep 2000 11:30:59 -0400 (EDT)
Subject: [Python-bugs-list] Re: [Bug #115643] test_longexp Fails on OpenBSD
In-Reply-To: <200009291521.IAA08757@bush.i.sourceforge.net>
References: <200009291521.IAA08757@bush.i.sourceforge.net>
Message-ID: <14804.46515.174668.104146@bitdiddle.concentric.net>

>>>>> "JP" == jpettit@raznick.com writes:

  JP> On the 2.5 system, it is a Pentium 133 with 64MB of memory.
  JP> Using "top", it shows the memory size of Python to be 32MB, but
  JP> there appears to be plenty of swap space left.  Here's the
  JP> memory line from "top" just before it raises the exception:

  JP> Memory: Real: 31M/40M act/tot Free: 1224K Swap: 3560K/48M
  JP> used/tot

  JP> The 2.7 seems to work fine, and it has only 32MB of RAM.  Of
  JP> course, I am also using the current version in CVS on the 2.5
  JP> system and 2.0b2 on the 2.7 system.  I am going to try the CVS
  JP> version on 2.7, but it will take me a while to setup due to a
  JP> slow modem link.

If it helps, you can get a snapshot of the CVS tree from 3am on any
particular day from ftp://python.beopen.com/pub/python/snapshots.

Jeremy



From noreply@sourceforge.net  Fri Sep 29 17:08:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 09:08:14 -0700
Subject: [Python-bugs-list] [Bug #115555] Parser crashes for deeply nested list displays
Message-ID: <200009291608.JAA10538@bush.i.sourceforge.net>

Bug #115555, was updated on 2000-Sep-28 03:42
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Parser crashes for deeply nested list displays

Details: Compiling

s=[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]

gives an error message

s_push: parser stack overflow

Python 1.5.2 then reports a MemoryError, 2.0b2 a SyntaxError.

Follow-Ups:

Date: 2000-Sep-28 12:35
By: jhylton

Comment:
What is the desired outcome here?  Python is reporting a SyntaxError; it's not crashing.  Would you like to increase the max stack size for the parser?  What should it's limit be?

The current parser stack limit allows eval("["*x+"]"*x) for values of x up to and including 35.  I'm not sure why the limit is set this low.  I bumped the value of MAXSTACK in parser.c from 500 to 5000 and it accepted the nest list expression for values of x up to 357.

-------------------------------------------------------

Date: 2000-Sep-29 09:08
By: loewis

Comment:
It was confusing that Python would produce a SyntaxError for an obviously-correct script, and that such a small limit was found in the parser.

Since the limit is not due to recursion on the C stack:  Would a patch removing this limitation be accepted (certainly not for 2.0). The two alternatives I see are to make the array completely dynamic, or to allocate a dynamic array in the stack if the static one overflows.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115555&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 17:27:59 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 09:27:59 -0700
Subject: [Python-bugs-list] [Bug #114532] cgi + <TextArea>.. + xml-data
Message-ID: <200009291627.JAA11287@bush.i.sourceforge.net>

Bug #114532, was updated on 2000-Sep-15 10:21
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Works For Me
Bug Group: Irreproducible
Priority: 1
Summary: cgi + <TextArea>.. + xml-data

Details: Hi!

I'm working under linux (mandrake 7.1) using python for my cgi scripts. There I've a formular containing a "textarea". If entering xml- or html-data into this textarea and submitting it the cgi-script doesn't get that xml-data. With non-xml-data everything works fine.

BTW: It's the same with an "input"-field.

ciao
Volker


Follow-Ups:

Date: 2000-Sep-15 10:57
By: gvanrossum

Comment:
Volker,

We cannot help you with this bug unless you provide us with an example we can try ourselves.  We need at least:

1) a simple but complete script that shows the bug (try to pare it down from the script you are using to somehing that demonstrates just the problem)

2) the HTML of the form (ditto)

3) the text you are entering into the form

We also need:

- the Python version
- the browser name and version
- the server name and version

That said, I suspect that the problem is in your script, but without looking at it, I can't tell!

--Guido
-------------------------------------------------------

Date: 2000-Sep-22 21:44
By: tim_one

Comment:
Closed it, as a week has gone by without further info.  We'll open it again if richieee supplies something to act on.
-------------------------------------------------------

Date: 2000-Sep-29 09:27
By: richieee

Comment:
Hi!

Because I was too busy the last week I couldn't give any example. Now I tried to reconstruct it and noticed that it actually works. Maybe the constellation is different now. In case I come over this again I'll give a more complete description.

ciao
Volker

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114532&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 18:04:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 10:04:45 -0700
Subject: [Python-bugs-list] [Bug #115673] Typo in the documentation (very low priority)
Message-ID: <200009291704.KAA04412@delerium.i.sourceforge.net>

Bug #115673, was updated on 2000-Sep-29 10:04
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: Not a Bug
Priority: 5
Summary: Typo in the documentation (very low priority)

Details: Python v2.0b2 docs contain the non-word 'reversely'.  Perhaps 'conversely' was intended.

See Section 8.1 of "Python/C API Reference Manual".  Last sentence of the following paragraph:

"The global interpreter lock is used to protect the pointer to the current thread state. When releasing the lock and saving the thread state, the current thread state pointer must be retrieved before the lock is released (since another thread could immediately acquire the lock and store its own thread state in the global variable). Reversely, when acquiring the lock and restoring the thread state, the lock must be acquired before storing the thread state pointer."



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115673&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 18:21:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 10:21:07 -0700
Subject: [Python-bugs-list] [Bug #115643] test_longexp Fails on OpenBSD
Message-ID: <200009291721.KAA05072@delerium.i.sourceforge.net>

Bug #115643, was updated on 2000-Sep-29 01:21
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Summary: test_longexp Fails on OpenBSD

Details: The test "test_longexp" fails on OpenBSD 2.5 shortly after 60,000 (sometime between 60,000 and 60,500) repetitions:

Traceback (most recent call last):
  File "test_longexp.py", line 4, in ?
    l = eval("[" + "2," * REPS + "]") 
MemoryError

On OpenBSD 2.7, it did not fail (and seemed to take the right amount of time), but returned the value "44".

The OpenBSD 2.5 system is using the most current CVS version.  The OpenBSD 2.7 system is using 2.0b2.

Follow-Ups:

Date: 2000-Sep-29 07:48
By: jhylton

Comment:
Is it possible that there isn't much memory available on the 2.5 system?  When the test runs successfully on my Linux box, the Python process uses 32MB.

Are you sure that the 2.7 version returns 44?  It should return 65580 (the value of REPS).  Can you run it as "python -i test_longexp.py" and then print l.  Is it really only 44 elements long?

Are all the other tests succeeding?

-------------------------------------------------------

Date: 2000-Sep-29 08:21
By: jpettit

Comment:
It appears that the 2.7 issue is my own fault, I mis-typed Python and accidently invoked Python 1.6.  I thought I was careful to check that, but apparently not.  Sorry.

On the 2.5 system, it is a Pentium 133 with 64MB of memory.  Using "top", it shows the memory size of Python to be 32MB, but there appears to be plenty of swap space left.  Here's the memory line from "top" just before it raises the exception:

Memory: Real: 31M/40M act/tot  Free: 1224K  Swap: 3560K/48M used/tot

The 2.7 seems to work fine, and it has only 32MB of RAM.  Of course, I am also using the current version in CVS on the 2.5 system and 2.0b2 on the 2.7 system.  I am going to try the CVS version on 2.7, but it will take me a while to setup due to a slow modem link.
-------------------------------------------------------

Date: 2000-Sep-29 10:21
By: jpettit

Comment:
I just tried running the exact same CVS version on the OpenBSD 2.7 system, and it worked fine. 
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115643&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 18:24:06 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 10:24:06 -0700
Subject: [Python-bugs-list] [Bug #115673] Typo in the documentation (very low priority)
Message-ID: <200009291724.KAA05138@delerium.i.sourceforge.net>

Bug #115673, was updated on 2000-Sep-29 10:04
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: Not a Bug
Priority: 1
Summary: Typo in the documentation (very low priority)

Details: Python v2.0b2 docs contain the non-word 'reversely'.  Perhaps 'conversely' was intended.

See Section 8.1 of "Python/C API Reference Manual".  Last sentence of the following paragraph:

"The global interpreter lock is used to protect the pointer to the current thread state. When releasing the lock and saving the thread state, the current thread state pointer must be retrieved before the lock is released (since another thread could immediately acquire the lock and store its own thread state in the global variable). Reversely, when acquiring the lock and restoring the thread state, the lock must be acquired before storing the thread state pointer."



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115673&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 18:23:45 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 10:23:45 -0700
Subject: [Python-bugs-list] [Bug #115643] test_longexp Fails on OpenBSD
Message-ID: <200009291723.KAA05132@delerium.i.sourceforge.net>

Bug #115643, was updated on 2000-Sep-29 01:21
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Works For Me
Bug Group: Platform-specific
Priority: 5
Summary: test_longexp Fails on OpenBSD

Details: The test "test_longexp" fails on OpenBSD 2.5 shortly after 60,000 (sometime between 60,000 and 60,500) repetitions:

Traceback (most recent call last):
  File "test_longexp.py", line 4, in ?
    l = eval("[" + "2," * REPS + "]") 
MemoryError

On OpenBSD 2.7, it did not fail (and seemed to take the right amount of time), but returned the value "44".

The OpenBSD 2.5 system is using the most current CVS version.  The OpenBSD 2.7 system is using 2.0b2.

Follow-Ups:

Date: 2000-Sep-29 07:48
By: jhylton

Comment:
Is it possible that there isn't much memory available on the 2.5 system?  When the test runs successfully on my Linux box, the Python process uses 32MB.

Are you sure that the 2.7 version returns 44?  It should return 65580 (the value of REPS).  Can you run it as "python -i test_longexp.py" and then print l.  Is it really only 44 elements long?

Are all the other tests succeeding?

-------------------------------------------------------

Date: 2000-Sep-29 08:21
By: jpettit

Comment:
It appears that the 2.7 issue is my own fault, I mis-typed Python and accidently invoked Python 1.6.  I thought I was careful to check that, but apparently not.  Sorry.

On the 2.5 system, it is a Pentium 133 with 64MB of memory.  Using "top", it shows the memory size of Python to be 32MB, but there appears to be plenty of swap space left.  Here's the memory line from "top" just before it raises the exception:

Memory: Real: 31M/40M act/tot  Free: 1224K  Swap: 3560K/48M used/tot

The 2.7 seems to work fine, and it has only 32MB of RAM.  Of course, I am also using the current version in CVS on the 2.5 system and 2.0b2 on the 2.7 system.  I am going to try the CVS version on 2.7, but it will take me a while to setup due to a slow modem link.
-------------------------------------------------------

Date: 2000-Sep-29 10:21
By: jpettit

Comment:
I just tried running the exact same CVS version on the OpenBSD 2.7 system, and it worked fine. 
-------------------------------------------------------

Date: 2000-Sep-29 10:23
By: jhylton

Comment:
So I assume we can close this bug.  Let me know if there is any reason to reopen this.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115643&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 18:32:09 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 10:32:09 -0700
Subject: [Python-bugs-list] [Bug #115673] Typo in the documentation (very low priority)
Message-ID: <200009291732.KAA05518@delerium.i.sourceforge.net>

Bug #115673, was updated on 2000-Sep-29 10:04
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: Fixed
Bug Group: Not a Bug
Priority: 1
Summary: Typo in the documentation (very low priority)

Details: Python v2.0b2 docs contain the non-word 'reversely'.  Perhaps 'conversely' was intended.

See Section 8.1 of "Python/C API Reference Manual".  Last sentence of the following paragraph:

"The global interpreter lock is used to protect the pointer to the current thread state. When releasing the lock and saving the thread state, the current thread state pointer must be retrieved before the lock is released (since another thread could immediately acquire the lock and store its own thread state in the global variable). Reversely, when acquiring the lock and restoring the thread state, the lock must be acquired before storing the thread state pointer."



Follow-Ups:

Date: 2000-Sep-29 10:32
By: fdrake

Comment:
Fixed in Doc/api/api.tex revision 1.93.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115673&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 18:33:30 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 10:33:30 -0700
Subject: [Python-bugs-list] [Bug #115673] Typo in the documentation (very low priority)
Message-ID: <200009291733.KAA05555@delerium.i.sourceforge.net>

Bug #115673, was updated on 2000-Sep-29 10:04
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: Not a Bug
Priority: 1
Summary: Typo in the documentation (very low priority)

Details: Python v2.0b2 docs contain the non-word 'reversely'.  Perhaps 'conversely' was intended.

See Section 8.1 of "Python/C API Reference Manual".  Last sentence of the following paragraph:

"The global interpreter lock is used to protect the pointer to the current thread state. When releasing the lock and saving the thread state, the current thread state pointer must be retrieved before the lock is released (since another thread could immediately acquire the lock and store its own thread state in the global variable). Reversely, when acquiring the lock and restoring the thread state, the lock must be acquired before storing the thread state pointer."



Follow-Ups:

Date: 2000-Sep-29 10:32
By: fdrake

Comment:
Fixed in Doc/api/api.tex revision 1.93.
-------------------------------------------------------

Date: 2000-Sep-29 10:33
By: fdrake

Comment:
Oops, forgot to mark this closed.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115673&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 18:44:52 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 10:44:52 -0700
Subject: [Python-bugs-list] [Bug #110695] complexobject.c optimization error on SGI (PR#144)
Message-ID: <200009291744.KAA05969@delerium.i.sourceforge.net>

Bug #110695, was updated on 2000-Jul-31 14:28
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Wont Fix
Bug Group: Platform-specific
Priority: 1
Summary: complexobject.c optimization error on SGI (PR#144)

Details: Jitterbug-Id: 144
Submitted-By: robert.harrison@pnl.gov
Date: Fri, 3 Dec 1999 01:35:19 -0500 (EST)
Version: 1.5.2
OS: IRIX64 6.5


On an SGI (IRIX64 6.5, MIPSpro Compilers: Version 7.3.1m, -n32)
Python-1.5.2/Objects/complexobject.c does not compile correctly 
with optimization.  The problem shows up as a bus error in
PyComplex_ImagAsDouble when importing Numeric Python.  All works fine 
when this one file is compiled with -O0 (-O1 and higher fail).
I assume that this is probably just a compiler error.




====================================================================
Audit trail:
Fri Dec 03 10:39:28 1999	guido	changed notes
Fri Dec 03 10:39:28 1999	guido	moved from incoming to platformbug

Follow-Ups:

Date: 2000-Sep-07 15:03
By: jhylton

Comment:
Please do triage on this bug.
-------------------------------------------------------

Date: 2000-Sep-16 15:02
By: bwarsaw

Comment:
Assigning to Fred, but we really need somebody with the specified OS to do platform specific testing.
-------------------------------------------------------

Date: 2000-Sep-16 15:10
By: fdrake

Comment:
Sent a message to the original submitter asking if this is still a problem, and indicated that we don't have access to any SGI IRIX systems on which to perform testing.
-------------------------------------------------------

Date: 2000-Sep-21 20:46
By: gvanrossum

Comment:
Set priority really low. SGI optimizer bugs are a common pain, but not worth losing sleep over.
Maybe just close it with "Wont Fix"?
-------------------------------------------------------

Date: 2000-Sep-29 10:44
By: fdrake

Comment:
Added a note to the README file explaining the optimization bug and how to build so that the complex object is compiled without optimization.  Closing this as "Won't Fix."
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=110695&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 18:47:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 10:47:15 -0700
Subject: [Python-bugs-list] [Bug #115676] repr(__builtin__.license) reads from stdin
Message-ID: <200009291747.KAA14280@bush.i.sourceforge.net>

Bug #115676, was updated on 2000-Sep-29 10:47
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: repr(__builtin__.license) reads from stdin

Details: Invoking repr or str on __builtin__.license invokes the site._Printer's __repr__ mthod which interacts with the console.  This causes problems for tools, such as a debugger, that use repr to inspect the environment and might set a bad precedent  for definition of __repr__, which is documented to return a string representation of the value.  I realize that _Printer is used to provide a pager for the license in an interactive interpreter session.  Could it only be used when the session is interactive and disabled when running a scipt from a file?  I realize that individual tools can work around this, but it seems odd to have to special case this.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115676&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 20:46:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 12:46:39 -0700
Subject: [Python-bugs-list] [Bug #115681] zipfile documentation out of sync with module
Message-ID: <200009291946.MAA18926@bush.i.sourceforge.net>

Bug #115681, was updated on 2000-Sep-29 12:46
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: zipfile documentation out of sync with module

Details: From: "Pete Shinners" <pete@visionart.com>
Subject: zipfile docs out of sync
Date: Fri, 29 Sep 2000 12:11:46 -0700

i've been using the zipfile module recently, and noticed
the documentation for it (both 2.0b1 & 2.0b2) are way
out of sync with the actual code in the module. specifically
the documentation for the zipfile.ZipFile objects.

for example, i cannot find the "TOC" variable.
"A read-only dictionary whose keys are the names in the
archive, and whose values are tuples as follows: "
the listdir() method is also missing?

it appears these have been changed to using
"NameToInfo" and "getinfo" for TOC, and listdir()
has changed to namelist() ??? it's hard to be sure.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115681&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 20:48:36 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 12:48:36 -0700
Subject: [Python-bugs-list] [Bug #115681] zipfile documentation out of sync with module
Message-ID: <200009291948.MAA18970@bush.i.sourceforge.net>

Bug #115681, was updated on 2000-Sep-29 12:46
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: Remind
Bug Group: None
Priority: 6
Summary: zipfile documentation out of sync with module

Details: From: "Pete Shinners" <pete@visionart.com>
Subject: zipfile docs out of sync
Date: Fri, 29 Sep 2000 12:11:46 -0700

i've been using the zipfile module recently, and noticed
the documentation for it (both 2.0b1 & 2.0b2) are way
out of sync with the actual code in the module. specifically
the documentation for the zipfile.ZipFile objects.

for example, i cannot find the "TOC" variable.
"A read-only dictionary whose keys are the names in the
archive, and whose values are tuples as follows: "
the listdir() method is also missing?

it appears these have been changed to using
"NameToInfo" and "getinfo" for TOC, and listdir()
has changed to namelist() ??? it's hard to be sure.


Follow-Ups:

Date: 2000-Sep-29 12:48
By: fdrake

Comment:
I've sent a note to Jim Ahlstrom asking him to update the documentation or provide a list of changes that need to be made, since what we have is just TeXified from text he provided when he contributed the module.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115681&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 21:05:56 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 13:05:56 -0700
Subject: [Python-bugs-list] [Bug #115643] test_longexp Fails on OpenBSD
Message-ID: <200009292005.NAA19728@bush.i.sourceforge.net>

Bug #115643, was updated on 2000-Sep-29 01:21
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Works For Me
Bug Group: Platform-specific
Priority: 5
Summary: test_longexp Fails on OpenBSD

Details: The test "test_longexp" fails on OpenBSD 2.5 shortly after 60,000 (sometime between 60,000 and 60,500) repetitions:

Traceback (most recent call last):
  File "test_longexp.py", line 4, in ?
    l = eval("[" + "2," * REPS + "]") 
MemoryError

On OpenBSD 2.7, it did not fail (and seemed to take the right amount of time), but returned the value "44".

The OpenBSD 2.5 system is using the most current CVS version.  The OpenBSD 2.7 system is using 2.0b2.

Follow-Ups:

Date: 2000-Sep-29 07:48
By: jhylton

Comment:
Is it possible that there isn't much memory available on the 2.5 system?  When the test runs successfully on my Linux box, the Python process uses 32MB.

Are you sure that the 2.7 version returns 44?  It should return 65580 (the value of REPS).  Can you run it as "python -i test_longexp.py" and then print l.  Is it really only 44 elements long?

Are all the other tests succeeding?

-------------------------------------------------------

Date: 2000-Sep-29 08:21
By: jpettit

Comment:
It appears that the 2.7 issue is my own fault, I mis-typed Python and accidently invoked Python 1.6.  I thought I was careful to check that, but apparently not.  Sorry.

On the 2.5 system, it is a Pentium 133 with 64MB of memory.  Using "top", it shows the memory size of Python to be 32MB, but there appears to be plenty of swap space left.  Here's the memory line from "top" just before it raises the exception:

Memory: Real: 31M/40M act/tot  Free: 1224K  Swap: 3560K/48M used/tot

The 2.7 seems to work fine, and it has only 32MB of RAM.  Of course, I am also using the current version in CVS on the 2.5 system and 2.0b2 on the 2.7 system.  I am going to try the CVS version on 2.7, but it will take me a while to setup due to a slow modem link.
-------------------------------------------------------

Date: 2000-Sep-29 10:21
By: jpettit

Comment:
I just tried running the exact same CVS version on the OpenBSD 2.7 system, and it worked fine. 
-------------------------------------------------------

Date: 2000-Sep-29 10:23
By: jhylton

Comment:
So I assume we can close this bug.  Let me know if there is any reason to reopen this.

-------------------------------------------------------

Date: 2000-Sep-29 13:05
By: jpettit

Comment:
I have figured out the problem on the 2.5 system.  It had a resource limit of 32MB for the data segment.  I increased this value to 64MB, and the problem went away.  I think the 32MB is only off by a megabyte or two.  Is this worth addressing in the test?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115643&group_id=5470


From noreply@sourceforge.net  Fri Sep 29 22:55:15 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 14:55:15 -0700
Subject: [Python-bugs-list] [Bug #115690] Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6
Message-ID: <200009292155.OAA24103@bush.i.sourceforge.net>

Bug #115690, was updated on 2000-Sep-29 14:55
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6

Details: I get a Dr. Watson error:

    pythonw.exe
    Exception: access violation (0xc0000005), 
    Address: 0x00e31652

when I run the following code in Idle 0.6, using Edit->Run Script:

---%<---cut---%<---

import unicodedata
for c in range(0x10000):
    x=unichr(c)
    try:
        b = unicodedata.numeric(x)
        #print "numeric:", repr(x)
        try:
            a = unicodedata.digit(x)
            if a != b:
                print "bad" , repr(x)
        except:
            print "Numeric but not digit", hex(c), x.encode("utf8"), \
                  "numeric ->", b
    except:
        pass

---%<---cut---%<---

(This code was recently posted on python-dev)

I've modified my .idle file, adding 

    [EditorWindow]
    font-name=tahoma


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115690&group_id=5470


From noreply@sourceforge.net  Sat Sep 30 01:08:25 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 17:08:25 -0700
Subject: [Python-bugs-list] [Bug #115143] Python sometimes complains about continue in an except
Message-ID: <200009300008.RAA28981@bush.i.sourceforge.net>

Bug #115143, was updated on 2000-Sep-22 14:57
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Summary: Python sometimes complains about continue in an except

Details: If a continue statement occurs in the second try/except
statement nested within another try statement, it complains
about the second continue.  For example, this code generates a SyntaxError:

    for i in range(10):
        try:
            try:
                pass
            except:
                continue
            try:
                pass
            except:
                continue
        except:
            pass

while this is fine:

    for i in range(10):
        try:
            pass
        except:
            continue
        try:
            pass
        except:
            continue

This problem exists in both 1.5.2 and 2.0b1.

A workaround is to raise "continue" from the inner 
try/except statements and catch it in the outer try/except:

    for i in range(10):
        try:
            try:
                pass
            except:
                raise "continue"
            try:
                pass
            except:
                raise "continue"
        except "continue":
            continue
        except:
            pass



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115143&group_id=5470


From noreply@sourceforge.net  Sat Sep 30 03:47:13 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 19:47:13 -0700
Subject: [Python-bugs-list] [Bug #115696] sre RuntimeError when .*? matches >16K string
Message-ID: <200009300247.TAA24999@delerium.i.sourceforge.net>

Bug #115696, was updated on 2000-Sep-29 19:47
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: sre RuntimeError when .*? matches >16K string

Details: The following code (run under WinNT):

    sre.search('x.*?z', 'x%sx' % ("y" * 16037,))

raises "RuntimeError: maximum recursion limit exceeded".

sre doesn't seem to be able to do a minimal match across more than ~16K characters. I think pcre can match something like 2**32 characters, so this is an area where the sre behavior deviates radically from pcre. I have lots of code that breaks with this limit. Yikes! Can something be done?

While trying to come up with the magic number of characters that cause a minimal match to fail, I ran this interactive session 
(I'm not sure if this means anything or if it's a quirk of the interactive interpreter.)

C:\>python
Python 2.0b2 (#6, Sep 26 2000, 14:59:21) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.

>>> import sre

>>> sre.search('x.*?x', 'x%sx' % ('@'*16035,))
<SRE_Match object at 009D7FC0>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16036,))
<SRE_Match object at 009D7040>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16037,))      <-- first failure
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "D:\Python20\lib\sre.py", line 47, in search
    return _compile(pattern, flags).search(string)
RuntimeError: maximum recursion limit exceeded

>>> sre.search('x.*?x', 'x%sx' % ('@'*16037,))      <-- now it works (?!)
<SRE_Match object at 009D7630>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16038,))
<SRE_Match object at 009D7040>

>>>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16166,))
<SRE_Match object at 009D7A60>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16167,))  <-- here it fails again
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "D:\Python20\lib\sre.py", line 47, in search
    return _compile(pattern, flags).search(string)
RuntimeError: maximum recursion limit exceeded

>>> sre.search('x.*?x', 'x%sx' % ('@'*16167,))  <-- continues to fail
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "D:\Python20\lib\sre.py", line 47, in search
    return _compile(pattern, flags).search(string)
RuntimeError: maximum recursion limit exceeded



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115696&group_id=5470


From noreply@sourceforge.net  Sat Sep 30 05:40:11 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 21:40:11 -0700
Subject: [Python-bugs-list] [Bug #115676] repr(__builtin__.license) reads from stdin
Message-ID: <200009300440.VAA05882@bush.i.sourceforge.net>

Bug #115676, was updated on 2000-Sep-29 10:47
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Summary: repr(__builtin__.license) reads from stdin

Details: Invoking repr or str on __builtin__.license invokes the site._Printer's __repr__ mthod which interacts with the console.  This causes problems for tools, such as a debugger, that use repr to inspect the environment and might set a bad precedent  for definition of __repr__, which is documented to return a string representation of the value.  I realize that _Printer is used to provide a pager for the license in an interactive interpreter session.  Could it only be used when the session is interactive and disabled when running a scipt from a file?  I realize that individual tools can work around this, but it seems odd to have to special case this.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115676&group_id=5470


From noreply@sourceforge.net  Sat Sep 30 05:42:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 21:42:03 -0700
Subject: [Python-bugs-list] [Bug #115690] Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6
Message-ID: <200009300442.VAA05993@bush.i.sourceforge.net>

Bug #115690, was updated on 2000-Sep-29 14:55
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: Dr. Watson error on Python2.0b2 Idle 0.6 WinNT4.0 SP6

Details: I get a Dr. Watson error:

    pythonw.exe
    Exception: access violation (0xc0000005), 
    Address: 0x00e31652

when I run the following code in Idle 0.6, using Edit->Run Script:

---%<---cut---%<---

import unicodedata
for c in range(0x10000):
    x=unichr(c)
    try:
        b = unicodedata.numeric(x)
        #print "numeric:", repr(x)
        try:
            a = unicodedata.digit(x)
            if a != b:
                print "bad" , repr(x)
        except:
            print "Numeric but not digit", hex(c), x.encode("utf8"), \
                  "numeric ->", b
    except:
        pass

---%<---cut---%<---

(This code was recently posted on python-dev)

I've modified my .idle file, adding 

    [EditorWindow]
    font-name=tahoma


Follow-Ups:

Date: 2000-Sep-29 21:42
By: jhylton

Comment:
Marc-Andre can you check whether this is a Unicode bug that is going to come up with or without idle.  If it seems Idle specific, please assign it to Guido or Tim.  If not, it's yours :-).


-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115690&group_id=5470


From noreply@sourceforge.net  Sat Sep 30 05:42:55 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 21:42:55 -0700
Subject: [Python-bugs-list] [Bug #115696] sre RuntimeError when .*? matches >16K string
Message-ID: <200009300442.VAA06011@bush.i.sourceforge.net>

Bug #115696, was updated on 2000-Sep-29 19:47
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Summary: sre RuntimeError when .*? matches >16K string

Details: The following code (run under WinNT):

    sre.search('x.*?z', 'x%sx' % ("y" * 16037,))

raises "RuntimeError: maximum recursion limit exceeded".

sre doesn't seem to be able to do a minimal match across more than ~16K characters. I think pcre can match something like 2**32 characters, so this is an area where the sre behavior deviates radically from pcre. I have lots of code that breaks with this limit. Yikes! Can something be done?

While trying to come up with the magic number of characters that cause a minimal match to fail, I ran this interactive session 
(I'm not sure if this means anything or if it's a quirk of the interactive interpreter.)

C:\>python
Python 2.0b2 (#6, Sep 26 2000, 14:59:21) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.

>>> import sre

>>> sre.search('x.*?x', 'x%sx' % ('@'*16035,))
<SRE_Match object at 009D7FC0>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16036,))
<SRE_Match object at 009D7040>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16037,))      <-- first failure
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "D:\Python20\lib\sre.py", line 47, in search
    return _compile(pattern, flags).search(string)
RuntimeError: maximum recursion limit exceeded

>>> sre.search('x.*?x', 'x%sx' % ('@'*16037,))      <-- now it works (?!)
<SRE_Match object at 009D7630>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16038,))
<SRE_Match object at 009D7040>

>>>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16166,))
<SRE_Match object at 009D7A60>

>>> sre.search('x.*?x', 'x%sx' % ('@'*16167,))  <-- here it fails again
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "D:\Python20\lib\sre.py", line 47, in search
    return _compile(pattern, flags).search(string)
RuntimeError: maximum recursion limit exceeded

>>> sre.search('x.*?x', 'x%sx' % ('@'*16167,))  <-- continues to fail
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "D:\Python20\lib\sre.py", line 47, in search
    return _compile(pattern, flags).search(string)
RuntimeError: maximum recursion limit exceeded



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115696&group_id=5470


From noreply@sourceforge.net  Sat Sep 30 05:48:00 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Sep 2000 21:48:00 -0700
Subject: [Python-bugs-list] [Bug #115555] Parser crashes for deeply nested list displays
Message-ID: <200009300448.VAA06186@bush.i.sourceforge.net>

Bug #115555, was updated on 2000-Sep-28 03:42
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Summary: Parser crashes for deeply nested list displays

Details: Compiling

s=[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]

gives an error message

s_push: parser stack overflow

Python 1.5.2 then reports a MemoryError, 2.0b2 a SyntaxError.

Follow-Ups:

Date: 2000-Sep-28 12:35
By: jhylton

Comment:
What is the desired outcome here?  Python is reporting a SyntaxError; it's not crashing.  Would you like to increase the max stack size for the parser?  What should it's limit be?

The current parser stack limit allows eval("["*x+"]"*x) for values of x up to and including 35.  I'm not sure why the limit is set this low.  I bumped the value of MAXSTACK in parser.c from 500 to 5000 and it accepted the nest list expression for values of x up to 357.

-------------------------------------------------------

Date: 2000-Sep-29 09:08
By: loewis

Comment:
It was confusing that Python would produce a SyntaxError for an obviously-correct script, and that such a small limit was found in the parser.

Since the limit is not due to recursion on the C stack:  Would a patch removing this limitation be accepted (certainly not for 2.0). The two alternatives I see are to make the array completely dynamic, or to allocate a dynamic array in the stack if the static one overflows.
-------------------------------------------------------

Date: 2000-Sep-29 21:48
By: jhylton

Comment:
There is a limit that is based on the C stack, because the parser is recursive descent.  If I set the max stack size to 100000, I get a seg fault.
I'm not sure if a patch for this would be accepted post 2.0 or not; I'll talk to Guido and see what he thinks.

I think we could safely increase the static limit before 2.0, though I'm not 100% certain.  What nesting level did your application come up with?
I would guess that max stack == 10000 (700 nested lists) should be safe on all reasonable platforms and much more useful.

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115555&group_id=5470


From noreply@sourceforge.net  Sat Sep 30 13:57:03 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 05:57:03 -0700
Subject: [Python-bugs-list] [Bug #115712] mimetools.decode doesn't work with '7bit' encoding
Message-ID: <200009301257.FAA21520@bush.i.sourceforge.net>

Bug #115712, was updated on 2000-Sep-30 05:57
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: mimetools.decode doesn't work with '7bit' encoding

Details: 1. mimetools.decode/encode doesn't work with '7bit'/'8bin' encoding.

From mimetools.py:

...
def decode(input, output, encoding):
    ...
    if encoding in ('7bit', '8bit'):
        output.write(input.read())
>>>>>>>>You forget 'return' there!
    if decodetab.has_key(encoding):
        pipethrough(input, decodetab[encoding], output)
    else:
        raise ValueError, \
          'unknown Content-Transfer-Encoding: %s' % encoding

2. mimetools.py used tabs instead of spaces.

3. Bug in documentation

12.5.2 'MultiFile example', line 2:
import MultiFile # instead of 'multifile'


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115712&group_id=5470


From noreply@sourceforge.net  Sat Sep 30 14:03:39 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 06:03:39 -0700
Subject: [Python-bugs-list] [Bug #115714] Module 'turtle' exports name 'Tk'...
Message-ID: <200009301303.GAA21720@bush.i.sourceforge.net>

Bug #115714, was updated on 2000-Sep-30 06:03
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Module 'turtle' exports name 'Tk'...

Details: 
...and this produce error in the following code:

from Tkinter import *
from turtle import *

root = Tk()  # Oops! TypeError: call of non-function.
...



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115714&group_id=5470


From noreply@sourceforge.net  Sat Sep 30 15:29:20 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 07:29:20 -0700
Subject: [Python-bugs-list] [Bug #115530] cStringIO.StringIO() doesn't raise ValueError when closed
Message-ID: <200009301429.HAA24454@bush.i.sourceforge.net>

Bug #115530, was updated on 2000-Sep-27 20:48
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: cStringIO.StringIO() doesn't raise ValueError when closed

Details: When write() is called on a closed StringO instance, ValueError should be raised.  Other methods should be checked for this as well.

>>> import cStringIO, StringIO
>>> f = cStringIO.StringIO()
>>> f.close()
>>> f.write('')

>>> f = StringIO.StringIO()    
>>> f.close()
>>> f.write('')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "./../Lib/StringIO.py", line 119, in write
    raise ValueError, "I/O operation on closed file"
ValueError: I/O operation on closed file

>>> f = open('junk.txt', 'w')
>>> f.close()
>>> f.write('abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: I/O operation on closed file

Assigned to Ken since he works at Digital Creations and can pester Jim Fulton about this.

Follow-Ups:

Date: 2000-Sep-27 20:53
By: fdrake

Comment:
Oops -- fixed summary to refer to the proper exception.
-------------------------------------------------------

Date: 2000-Sep-27 21:27
By: fdrake

Comment:
A simple test for this is commented out in Lib/test/test_StringIO.py; please uncomment and regenerate output when fixing this bug.
-------------------------------------------------------

Date: 2000-Sep-30 07:29
By: loewis

Comment:
A patch is in http://sourceforge.net/patch/?func=detailpatch&patch_id=101721&group_id=5470

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115530&group_id=5470


From noreply@sourceforge.net  Sat Sep 30 17:27:01 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 09:27:01 -0700
Subject: [Python-bugs-list] [Bug #115531] cStringIO truncate() doesn't support size parameter
Message-ID: <200009301627.JAA19327@delerium.i.sourceforge.net>

Bug #115531, was updated on 2000-Sep-27 20:57
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: cStringIO truncate() doesn't support size parameter

Details: The truncate() method doesn't handle the optional size parameter to truncate, nor does it check its parameters in any way.  Many (all?) methods don't check arguments when they don't expect any.

Assigned to Ken because he works at Digital Creations and can pester Jim about this.

Follow-Ups:

Date: 2000-Sep-27 21:27
By: fdrake

Comment:
A simple test for this is commented out in Lib/test/test_StringIO.py; please uncomment and regenerate output when fixing this bug.
-------------------------------------------------------

Date: 2000-Sep-30 09:27
By: loewis

Comment:
A patch for that is in http://sourceforge.net/patch/?func=detailpatch&patch_id=101721&group_id=5470
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115531&group_id=5470


From noreply@sourceforge.net  Sat Sep 30 17:38:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 09:38:07 -0700
Subject: [Python-bugs-list] [Bug #115714] Module 'turtle' exports name 'Tk'...
Message-ID: <200009301638.JAA19750@delerium.i.sourceforge.net>

Bug #115714, was updated on 2000-Sep-30 06:03
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Module 'turtle' exports name 'Tk'...

Details: 
...and this produce error in the following code:

from Tkinter import *
from turtle import *

root = Tk()  # Oops! TypeError: call of non-function.
...



Follow-Ups:

Date: 2000-Sep-30 09:38
By: loewis

Comment:
A patch for that is in
http://sourceforge.net/patch/?func=detailpatch&patch_id=101724&group_id=5470
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115714&group_id=5470


From noreply@sourceforge.net  Sat Sep 30 18:07:07 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 10:07:07 -0700
Subject: [Python-bugs-list] [Bug #115712] mimetools.decode doesn't work with '7bit' encoding
Message-ID: <200009301707.KAA20800@delerium.i.sourceforge.net>

Bug #115712, was updated on 2000-Sep-30 05:57
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: mimetools.decode doesn't work with '7bit' encoding

Details: 1. mimetools.decode/encode doesn't work with '7bit'/'8bin' encoding.

From mimetools.py:

...
def decode(input, output, encoding):
    ...
    if encoding in ('7bit', '8bit'):
        output.write(input.read())
>>>>>>>>You forget 'return' there!
    if decodetab.has_key(encoding):
        pipethrough(input, decodetab[encoding], output)
    else:
        raise ValueError, \
          'unknown Content-Transfer-Encoding: %s' % encoding

2. mimetools.py used tabs instead of spaces.

3. Bug in documentation

12.5.2 'MultiFile example', line 2:
import MultiFile # instead of 'multifile'


Follow-Ups:

Date: 2000-Sep-30 10:07
By: loewis

Comment:
Fixed in version 1.18 of mimetools.py and version 1.10 of libmultifile.tex.
Conversion of tabs to spaces won't be done for Python 2.0, according to PEP 42.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115712&group_id=5470


From noreply@sourceforge.net  Sat Sep 30 18:12:38 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 10:12:38 -0700
Subject: [Python-bugs-list] [Bug #115712] mimetools.decode doesn't work with '7bit' encoding
Message-ID: <200009301712.KAA20988@delerium.i.sourceforge.net>

Bug #115712, was updated on 2000-Sep-30 05:57
Here is a current snapshot of the bug.

Project: Python
Category: Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: mimetools.decode doesn't work with '7bit' encoding

Details: 1. mimetools.decode/encode doesn't work with '7bit'/'8bin' encoding.

From mimetools.py:

...
def decode(input, output, encoding):
    ...
    if encoding in ('7bit', '8bit'):
        output.write(input.read())
>>>>>>>>You forget 'return' there!
    if decodetab.has_key(encoding):
        pipethrough(input, decodetab[encoding], output)
    else:
        raise ValueError, \
          'unknown Content-Transfer-Encoding: %s' % encoding

2. mimetools.py used tabs instead of spaces.

3. Bug in documentation

12.5.2 'MultiFile example', line 2:
import MultiFile # instead of 'multifile'


Follow-Ups:

Date: 2000-Sep-30 10:07
By: loewis

Comment:
Fixed in version 1.18 of mimetools.py and version 1.10 of libmultifile.tex.
Conversion of tabs to spaces won't be done for Python 2.0, according to PEP 42.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115712&group_id=5470


From noreply@sourceforge.net  Sat Sep 30 19:29:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 11:29:14 -0700
Subject: [Python-bugs-list] [Bug #115731] Linking with old versions of readline
Message-ID: <200009301829.LAA23692@delerium.i.sourceforge.net>

Bug #115731, was updated on 2000-Sep-30 11:29
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Linking with old versions of readline

Details: Python 2.0b2 introduced a new variable into the readline module 'library_version'. This relies on a feature not present in all versions of readline - 'rl_library_version' -  such as the one shipped with OpenBSD 2.7. The latest CVS version fails to link correctly against readlines that don't contain this variable:

[laurie /usr/local/src/Python-2.0b2]$ uname -a
OpenBSD droptop 2.7 GENERIC#25 i386
[laurie /usr/local/src/Python-2.0b2]$ make
<standard make output ... >
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
./posixmodule.c:2910: warning: this program uses setreuid(), which is deprecated.
./posixmodule.c:2929: warning: this program uses setregid(), which is deprecated.
./posixmodule.c:4062: warning: tempnam() possibly used unsafely; consider using mkstemp()
./posixmodule.c:4108: warning: tmpnam() possibly used unsafely; consider using mkstemp()
./readline.c:504: Undefined symbol `_rl_library_version' referenced from text segment
collect2: ld returned 1 exit status

The only obvious fix to this is to test for the presence of the variable in the configure file and have a HAS_READLINE_VERSION #define or similar which doesn't reference the readline variable, although that doesn't suggest what the library_version should be set to in its absence... None?

This is effectively a followup to bug #11487 which reported compilation problems with the aforementioned variable. It seems likely that the original bug submitter didn't get as far as linking Python due to other compilation problems so the original fix would have appeared to work.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115731&group_id=5470


From noreply@sourceforge.net  Sat Sep 30 19:36:14 2000
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Sep 2000 11:36:14 -0700
Subject: [Python-bugs-list] [Bug #115732] Linking fails with old versions of readline
Message-ID: <200009301836.LAA23894@delerium.i.sourceforge.net>

Bug #115732, was updated on 2000-Sep-30 11:36
Here is a current snapshot of the bug.

Project: Python
Category: Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Linking fails with old versions of readline

Details: Python 2.0b2 introduced a new variable into the readline module 'library_version'. This relies on a feature not present in all versions of readline - 'rl_library_version' -  such as the one shipped with OpenBSD 2.7. The latest CVS version fails to link correctly against readlines that don't contain this variable:

[laurie /usr/local/src/Python-2.0b2]$ uname -a
OpenBSD droptop 2.7 GENERIC#25 i386
[laurie /usr/local/src/Python-2.0b2]$ make
<standard make output ... >
gcc   python.o  ../libpython2.0.a -lreadline -ltermcap  -lc_r -lutil -lm  -o python 
./readline.c:504: Undefined symbol `_rl_library_version' referenced from text segment
collect2: ld returned 1 exit status

The only obvious fix to this is to test for the presence of the variable in the configure file and have a HAS_READLINE_VERSION #define or similar which doesn't reference the readline variable, although that doesn't suggest what the library_version should be set to in its absence... None?

This is effectively a followup to bug #11487 which reported compilation problems with the aforementioned variable. It seems likely that the original bug submitter didn't get as far as linking Python due to other compilation problems so the original fix would have appeared to work.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115732&group_id=5470