From guido@python.org  Mon Jul 12 20:03:25 1999
From: guido@python.org (guido@python.org)
Date: Mon, 12 Jul 1999 15:03:25 -0400 (EDT)
Subject: [Python-bugs-list] re group self-reference weird behavior (PR#2)
Message-ID: <199907121903.PAA03217@python.org>

Full_Name: Guido van Rossum
Version: 1.5.2
OS: Unix, Windows
Submission from: eric.cnri.reston.va.us (132.151.1.38)


Try the following:

import re
re.search("((.)\\1+)","a")

This isn't proper syntax (you shouldn't reference a group
inside itself), but it seems to hang -- in fact it takes
several minutes to execute.

Possibly it runs out of some resource on its path to infinite
recursion and then backtracks?




From skip@mojam.com  Mon Jul 12 20:36:04 1999
From: skip@mojam.com (skip@mojam.com)
Date: Mon, 12 Jul 1999 15:36:04 -0400 (EDT)
Subject: [Python-bugs-list] rfc822.Message.readheaders bug (PR#3)
Message-ID: <199907121936.PAA03739@python.org>

Full_Name: Skip Montanaro
Version: 1.5.2
OS: Unix
Submission from: eric.cnri.reston.va.us (132.151.1.38)
Submitted by: guido


[resubmitted by GvR]

I think there's a bug in rfc822.Message.readheaders (v. 1.5.2).  In that
method it splits a header into name and value and assigns to a dict:

    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:])
	continue

See the "len(headerseen)+2" as the starting index of the slice?  I think
that should be "len(headerseen)+1".  It appears the code assumes there is a
space following the colon that separates the name and the value.  My reading 
of the relevant section of RFC 822 suggests that a single colon is the only
separator between a field name and its value:

     3.2.  HEADER FIELD DEFINITIONS

          These rules show a field meta-syntax, without regard for the
     particular  type  or internal syntax.  Their purpose is to permit
     detection of fields; also, they present to  higher-level  parsers
     an image of each field as fitting on one line.

     field       =  field-name ":" [ field-body ] CRLF

     field-name  =  1*<any CHAR, excluding CTLs, SPACE, and ":">

     field-body  =  field-body-contents
                    [CRLF LWSP-char field-body]

     field-body-contents =
                   <the ASCII characters making up the field-body, as
                    defined in the following sections, and consisting
                    of combinations of atom, quoted-string, and
                    specials tokens, or else consisting of texts>

I got the above from http://www.faqs.org/rfcs/rfc822.html.





From MHammond@skippinet.com.au  Mon Jul 12 20:38:47 1999
From: MHammond@skippinet.com.au (MHammond@skippinet.com.au)
Date: Mon, 12 Jul 1999 15:38:47 -0400 (EDT)
Subject: [Python-bugs-list] pdb can only step when at botframe (PR#4)
Message-ID: <199907121938.PAA03857@python.org>

Full_Name: Mark Hammond
Version: 1.5.2
OS: Windows
Submission from: eric.cnri.reston.va.us (132.151.1.38)
Submitted by: guido


[Resubmitted by GvR]

It is a problem that bugged me for _ages_.  Since the years I first wrote
the Pythonwin debugger Ive learnt alot about how it works :-)

The problem is simply:  when the frame being debugged is self.botframe, it
is impossible to continue - only "step" works.  A "continue" command
functions as a step until you start debugging a frame below self.botframe.

It is less of a problem with pdb, but makes a GUI debugger clunky - if you
start a debug session by stepping into a module, the "go" command seems
broken.

The simplest way to demonstrate the problem is to create a module, and add
a "pdb.set_trace()" statement at the top_level (ie, at indent level 0).
You will not be able to "continue" until you enter a function.

My solution was this:  instead of run() calling "exec" directly, it calls
another internal function.  This internal function contains a single line -
the "exec", and therefore never needs to be debugged directly.  Then
stop_here is modified accordingly.

The end result is that "self.botframe" becomes an "intermediate" frame, and
is never actually stopped at - ie, self.botframe effectivly becomes one
frame _below_ the bottom frame the user is interested in.

Im not yet trying to propose a patch, just to discuss this and see if the
"right thing" can be determined and put into pdb.

Thanks,

Mark.






From guido@python.org  Mon Jul 12 20:55:44 1999
From: guido@python.org (guido@python.org)
Date: Mon, 12 Jul 1999 15:55:44 -0400 (EDT)
Subject: [Python-bugs-list] tuple repetition not safe (PR#6)
Message-ID: <199907121955.PAA04217@python.org>

Full_Name: Guido van Rossum
Version: 1.5.2
OS: Unix
Submission from: eric.cnri.reston.va.us (132.151.1.38)


Found this on the news:

> This is on a Sun machine:
>
> >>> x=sys.maxint*[1,]
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> MemoryError
> >>> x=sys.maxint*(1,)
> Segmentation Fault (core dumped)




From da@ski.org  Mon Jul 12 23:53:11 1999
From: da@ski.org (da@ski.org)
Date: Mon, 12 Jul 1999 18:53:11 -0400 (EDT)
Subject: [Python-bugs-list] comparisons of recursive objects (PR#7)
Message-ID: <199907122253.SAA08497@python.org>

Full_Name: David Ascher
Version: 1.5.2
OS: NT4SP3
Submission from: (NULL) (209.117.142.20)


When comparing (e.g.) two lists that contain themselves, the interpreter can
dump core. For
example: 

  a = []; a.append(a)
  b = []; b.append(b)
  cmp(a, b)



From da@ski.org  Mon Jul 12 23:53:18 1999
From: da@ski.org (da@ski.org)
Date: Mon, 12 Jul 1999 18:53:18 -0400 (EDT)
Subject: [Python-bugs-list] comparisons of recursive objects (PR#8)
Message-ID: <199907122253.SAA08516@python.org>

Full_Name: David Ascher
Version: 1.5.2
OS: NT4SP3
Submission from: (NULL) (209.117.142.20)


When comparing (e.g.) two lists that contain themselves, the interpreter can
dump core. For
example: 

  a = []; a.append(a)
  b = []; b.append(b)
  cmp(a, b)



From guido@CNRI.Reston.VA.US  Tue Jul 13 00:19:53 1999
From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US)
Date: Mon, 12 Jul 1999 19:19:53 -0400 (EDT)
Subject: [Python-bugs-list] test jitterbug (PR#9)
Message-ID: <199907122319.TAA09123@python.org>

Full_Name: GvR
Version: 1.5.2
OS: NT4SP3
Submission from: (NULL) (209.117.142.20)


testing



From bwarsaw@python.org  Tue Jul 13 00:21:57 1999
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Mon, 12 Jul 1999 19:21:57 -0400 (EDT)
Subject: [Python-bugs-list] testing jitterbug through cgi (PR#10)
Message-ID: <199907122321.TAA09203@python.org>

Full_Name: Barry Warsaw
Version: 1.5.2+
OS: Solaris
Submission from: anthem.cnri.reston.va.us (132.151.1.40)


testing jitterbug through cgi



From tim_one@email.msn.com  Tue Jul 13 01:47:08 1999
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Mon, 12 Jul 1999 20:47:08 -0400 (EDT)
Subject: [Python-bugs-list] Traceback off by a line under -x (PR#11)
Message-ID: <199907130047.UAA10474@python.org>

Full_Name: Tim Peters
Version: 1.5.2
OS: Win95
Submission from: 1cust154.tnt3.bos1.da.uu.net (153.34.162.154)


Running

    python -x whatever.py

skips over the first line of the script (that's a feature), but Python also then
considers the second line of the file to be line number 1.  This causes
tracebacks in the main script to display a wrong (off by one) line.

Already fixed in the CVS version.





From tim_one@email.msn.com  Tue Jul 13 01:53:24 1999
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Mon, 12 Jul 1999 20:53:24 -0400 (EDT)
Subject: [Python-bugs-list] PyThreadState_Delete: invalid tstate (PR#12)
Message-ID: <199907130053.UAA10636@python.org>

Full_Name: Tim Peters
Version: 1.5.2
OS: Win95
Submission from: 1cust154.tnt3.bos1.da.uu.net (153.34.162.154)


People running a threaded Python under 1.5.2 (& earlier) sometimes reported
random

    Fatal Python error: PyThreadState_Delete: invalid tstate

deaths, and more rarely memory faults.  These typically occurred under heavy
load, with a high rate of thread death.

This is probably fixed in the CVS version:  some small timing holes were
discovered "by eye" in the code that cleans up thread states, and got fixed.  A
test case written to provoke the problem ran without incident on several systems
after the fix.




From tim_one@email.msn.com  Tue Jul 13 01:56:41 1999
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Mon, 12 Jul 1999 20:56:41 -0400 (EDT)
Subject: [Python-bugs-list] re should gripe about repeated group names (PR#13)
Message-ID: <199907130056.UAA10741@python.org>

Full_Name: Tim Peters
Version: 1.5.2
OS: Win95
Submission from: 1cust154.tnt3.bos1.da.uu.net (153.34.162.154)


>>> p = re.compile("(?P<a> a1) (?P<a> b2)")
>>> p.groupindex
{'a': 2}
>>>

re can't do anything sensible with a repeated group name, so it should complain
about it instead of silently redefining it.  Has come up a few times on c.l.py.




From tim_one@email.msn.com  Tue Jul 13 01:56:50 1999
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Mon, 12 Jul 1999 20:56:50 -0400 (EDT)
Subject: [Python-bugs-list] re should gripe about repeated group names (PR#14)
Message-ID: <199907130056.UAA10756@python.org>

Full_Name: Tim Peters
Version: 1.5.2
OS: Win95
Submission from: 1cust154.tnt3.bos1.da.uu.net (153.34.162.154)


>>> p = re.compile("(?P<a> a1) (?P<a> b2)")
>>> p.groupindex
{'a': 2}
>>>

re can't do anything sensible with a repeated group name, so it should complain
about it instead of silently redefining it.  Has come up a few times on c.l.py.




From tim_one@email.msn.com  Tue Jul 13 02:00:33 1999
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Mon, 12 Jul 1999 21:00:33 -0400 (EDT)
Subject: [Python-bugs-list] re should gripe about repeated group names (PR#15)
Message-ID: <199907130100.VAA10888@python.org>

Full_Name: Tim Peters
Version: 1.5.2
OS: Win95
Submission from: 1cust154.tnt3.bos1.da.uu.net (153.34.162.154)


>>> p = re.compile("(?P<a> a1) (?P<a> b2)")
>>> p.groupindex
{'a': 2}
>>>

re can't do anything sensible with a repeated group name, so it should complain
about it instead of silently redefining it.  Has come up a few times on c.l.py.




From tim_one@email.msn.com  Tue Jul 13 02:06:55 1999
From: tim_one@email.msn.com (tim_one@email.msn.com)
Date: Mon, 12 Jul 1999 21:06:55 -0400 (EDT)
Subject: [Python-bugs-list] re should gripe about repeated group names (PR#16)
Message-ID: <199907130106.VAA11090@python.org>

Full_Name: Tim Peters
Version: 1.5.2
OS: Win95
Submission from: 1cust2.tnt1.bos1.da.uu.net (153.34.158.2)


>>> p = re.compile("(?P<a> a1) (?P<a> b2)")
>>> p.groupindex
{'a': 2}
>>>

re can't do anything sensible with a repeated group name, so it should complain
about it instead of silently redefining it.  Has come up a few times on c.l.py.




From guido@python.org  Tue Jul 13 16:09:51 1999
From: guido@python.org (guido@python.org)
Date: Tue, 13 Jul 1999 11:09:51 -0400 (EDT)
Subject: [Python-bugs-list] testing (PR#17)
Message-ID: <199907131509.LAA27151@python.org>

Full_Name: GvR
Version: 
OS: 
Submission from: eric.cnri.reston.va.us (132.151.1.38)


testing the jitterbug bug




From guido@python.org  Tue Jul 13 16:26:18 1999
From: guido@python.org (guido@python.org)
Date: Tue, 13 Jul 1999 11:26:18 -0400 (EDT)
Subject: [Python-bugs-list] testing again (PR#18)
Message-ID: <199907131526.LAA27597@python.org>

Full_Name: GvR
Version: 
OS: 
Submission from: eric.cnri.reston.va.us (132.151.1.38)


testing



From guido@python.org  Tue Jul 13 16:26:34 1999
From: guido@python.org (guido@python.org)
Date: Tue, 13 Jul 1999 11:26:34 -0400 (EDT)
Subject: [Python-bugs-list] testing again (PR#19)
Message-ID: <199907131526.LAA27638@python.org>

Full_Name: GvR
Version: 
OS: 
Submission from: eric.cnri.reston.va.us (132.151.1.38)


testing



From guido@python.org  Tue Jul 13 17:05:16 1999
From: guido@python.org (guido@python.org)
Date: Tue, 13 Jul 1999 12:05:16 -0400 (EDT)
Subject: [Python-bugs-list] testing (PR#20)
Message-ID: <199907131605.MAA28609@python.org>

Full_Name: GvR
Version: 
OS: 
Submission from: eric.cnri.reston.va.us (132.151.1.38)
Submitted by: guido


testing



From guido@CNRI.Reston.VA.US  Tue Jul 13 17:26:06 1999
From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US)
Date: Tue, 13 Jul 1999 12:26:06 -0400 (EDT)
Subject: [Python-bugs-list] testing email submission (PR#21)
Message-ID: <199907131626.MAA29327@python.org>

So...  Does this do anything useful?

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



From beazley@cs.uchicago.edu  Tue Jul 13 19:46:44 1999
From: beazley@cs.uchicago.edu (beazley@cs.uchicago.edu)
Date: Tue, 13 Jul 1999 14:46:44 -0400 (EDT)
Subject: [Python-bugs-list] Bug in getpass module (PR#22)
Message-ID: <199907131846.OAA01956@python.org>

Full_Name: David Beazley
Version: 1.5.2
OS: Linux (Redhat 5.2)
Submission from: flash-gordon.cs.uchicago.edu (128.135.11.106)


The getpass.getpass() function does not disable character echoing
under Linux. Seems to work fine under Solaris.




From pmoran@nas.nasa.gov  Tue Jul 13 21:36:36 1999
From: pmoran@nas.nasa.gov (pmoran@nas.nasa.gov)
Date: Tue, 13 Jul 1999 16:36:36 -0400 (EDT)
Subject: [Python-bugs-list] Irix configure bug (PR#23)
Message-ID: <199907132036.QAA04099@python.org>

Full_Name: Patrick J. Moran
Version: 
OS: Irix 6.4
Submission from: eric.cnri.reston.va.us (132.151.1.38)


[Reposted from c.l.py by GvR]

Hi,

I've encounted a bug with the configure on Irix.  I'm not sure
where to report it, so to the newsgroup it goes.

The problem is under Irix 6.4 with the MIPSpro 7.2 compiler.
The problem is that configure concludes that size_t, mode_t
and pid_t are not defined in <sys/types.h>, when in reality
they are.  I suspect configure comes to this conclusion because
there are #if's around the definitions, and _MIPS_SZLONG has to
be defined as 32 (or 64) in order for the typedef's to be visible.
I presume _MIPS_SZLONG isn't defined when configure does its
tests.  So configure generates #define's in config.h for the
names it thinks are missing, and the defines cause problems
later when the compiler encounters the typedefs.  In particular,
the define for size_t causes errors later.

My current work-around is to just go in to config.h after configure
has been run and comment out to offending defines.

Pat

------------------------------------------------------------
Patrick J. Moran, Ph.D.      http://www.nas.nasa.gov/~pmoran
MRJ Technology Solutions           NASA Ames Research Center




From beazley@cs.uchicago.edu  Wed Jul 14 02:08:45 1999
From: beazley@cs.uchicago.edu (beazley@cs.uchicago.edu)
Date: Tue, 13 Jul 1999 21:08:45 -0400 (EDT)
Subject: [Python-bugs-list] Re: Bug in getpass module (PR#22)
Message-ID: <199907140108.VAA08711@python.org>

Guido van Rossum writes:
> PS: In particular, compare the value for MACHDEPPATH in Setup
> with that in Setup.in; most likely, your Setup file is old
> (mine was, which is why I could reproduce your problem :-).

Hmm. The problem goes away if I manually hack the Setup file
to include termios.   It appears to be disabled
in the default configuration.  Sorry for the false alarm :-).

Cheers,

Dave




From guido@python.org  Wed Jul 14 16:16:52 1999
From: guido@python.org (guido@python.org)
Date: Wed, 14 Jul 1999 11:16:52 -0400 (EDT)
Subject: [Python-bugs-list] -with-cxx option to configure script (PR#24)
Message-ID: <199907141516.LAA26566@python.org>

Full_Name: Guido van Rossum
Version: 1.5.2
OS: Unix
Submission from: eric.cnri.reston.va.us (132.151.1.38)
Submitted by: guido


Geoff Furnish has a patch for the configure script which might be reasonable.

See http://www.python.org/sigs/c++-sig/sig_code.html




From fp@contact.de  Wed Jul 14 16:35:05 1999
From: fp@contact.de (fp@contact.de)
Date: Wed, 14 Jul 1999 11:35:05 -0400 (EDT)
Subject: [Python-bugs-list] SWIG's embed.i and Python 1.5.2 on WinNT (PR#25)
Message-ID: <199907141535.LAA26994@python.org>

Full_Name: Frank Patz
Version: 1.5.2
OS: WinNT 4.0
Submission from: b82.bitz.uni-bremen.de (134.102.49.82)


PYTHON15.DLL does not export "initimp", "initsha", "PyMarshal_Init" 
and "PyImport_Inittab". Those are needed to use Swig's embed.i on
Windows. I had to patch PC/config.c, Python/import.c, Python/marshal.c
and Modules/shamodule.c to get everything working. I also had to 
apply a small change to SWIG's embed.i.

*** PC\config.c	Wed Jul 14 17:10:04 1999
***************
*** 73,79 ****
  extern void PyMarshal_Init();
  extern void initimp();
  
! struct _inittab _PyImport_Inittab[] = {
  
          {"array", initarray},
  #ifdef MS_WINDOWS
--- 73,79 ----
  extern void PyMarshal_Init();
  extern void initimp();
  
! DL_EXPORT(struct _inittab) _PyImport_Inittab[] = {
  
          {"array", initarray},
  #ifdef MS_WINDOWS

*** Python/import.c	Wed Jul 14 17:08:24 1999
***************
*** 92,98 ****
  /* This table is defined in config.c: */
  extern struct _inittab _PyImport_Inittab[];
  
! struct _inittab *PyImport_Inittab = _PyImport_Inittab;
  
  /* Initialize things */
  
--- 92,98 ----
  /* This table is defined in config.c: */
  extern struct _inittab _PyImport_Inittab[];
  
! DL_EXPORT(struct _inittab *) PyImport_Inittab = _PyImport_Inittab;
  
  /* Initialize things */
  
***************
*** 2326,2332 ****
  	return err;
  }
  
! void
  initimp()
  {
  	PyObject *m, *d;
--- 2326,2332 ----
  	return err;
  }
  
! DL_EXPORT(void)
  initimp()
  {
  	PyObject *m, *d;

*** Python/marshal.c	Wed Jul 14 17:11:10 1999
***************
*** 766,772 ****
  	{NULL,		NULL}		/* sentinel */
  };
  
! void
  PyMarshal_Init()
  {
  	(void) Py_InitModule("marshal", marshal_methods);
--- 766,772 ----
  	{NULL,		NULL}		/* sentinel */
  };
  
! DL_EXPORT(void)
  PyMarshal_Init()
  {
  	(void) Py_InitModule("marshal", marshal_methods);

*** Modules/shamodule.c	Wed Jul 14 17:12:32 1999
***************
*** 582,588 ****
  	if (o!=NULL) PyDict_SetItemString(d,n,o); \
  	Py_XDECREF(o); }
  
! void
  initsha()
  {
  	PyObject *d, *m;
--- 582,588 ----
  	if (o!=NULL) PyDict_SetItemString(d,n,o); \
  	Py_XDECREF(o); }
  
! DL_EXPORT(void)
  initsha()
  {
  	PyObject *d, *m;



This is the patch for SWIG's embed.i

*** swig_lib/python/embed.i	Wed Jul 14 17:14:20 1999
***************
*** 99,105 ****
  }
  #endif
  
! /* extern struct _inittab *PyImport_Inittab; */
  
  int
  main(int argc, char **argv) {
--- 99,105 ----
  }
  #endif
  
! extern struct _inittab *PyImport_Inittab;
  
  int
  main(int argc, char **argv) {





From fp@contact.de  Wed Jul 14 16:35:35 1999
From: fp@contact.de (fp@contact.de)
Date: Wed, 14 Jul 1999 11:35:35 -0400 (EDT)
Subject: [Python-bugs-list] SWIG's embed.i and Python 1.5.2 on WinNT (PR#26)
Message-ID: <199907141535.LAA27039@python.org>

Full_Name: Frank Patz
Version: 1.5.2
OS: WinNT 4.0
Submission from: b82.bitz.uni-bremen.de (134.102.49.82)


PYTHON15.DLL does not export "initimp", "initsha", "PyMarshal_Init" 
and "PyImport_Inittab". Those are needed to use Swig's embed.i on
Windows. I had to patch PC/config.c, Python/import.c, Python/marshal.c
and Modules/shamodule.c to get everything working. I also had to 
apply a small change to SWIG's embed.i.

*** PC\config.c	Wed Jul 14 17:10:04 1999
***************
*** 73,79 ****
  extern void PyMarshal_Init();
  extern void initimp();
  
! struct _inittab _PyImport_Inittab[] = {
  
          {"array", initarray},
  #ifdef MS_WINDOWS
--- 73,79 ----
  extern void PyMarshal_Init();
  extern void initimp();
  
! DL_EXPORT(struct _inittab) _PyImport_Inittab[] = {
  
          {"array", initarray},
  #ifdef MS_WINDOWS

*** Python/import.c	Wed Jul 14 17:08:24 1999
***************
*** 92,98 ****
  /* This table is defined in config.c: */
  extern struct _inittab _PyImport_Inittab[];
  
! struct _inittab *PyImport_Inittab = _PyImport_Inittab;
  
  /* Initialize things */
  
--- 92,98 ----
  /* This table is defined in config.c: */
  extern struct _inittab _PyImport_Inittab[];
  
! DL_EXPORT(struct _inittab *) PyImport_Inittab = _PyImport_Inittab;
  
  /* Initialize things */
  
***************
*** 2326,2332 ****
  	return err;
  }
  
! void
  initimp()
  {
  	PyObject *m, *d;
--- 2326,2332 ----
  	return err;
  }
  
! DL_EXPORT(void)
  initimp()
  {
  	PyObject *m, *d;

*** Python/marshal.c	Wed Jul 14 17:11:10 1999
***************
*** 766,772 ****
  	{NULL,		NULL}		/* sentinel */
  };
  
! void
  PyMarshal_Init()
  {
  	(void) Py_InitModule("marshal", marshal_methods);
--- 766,772 ----
  	{NULL,		NULL}		/* sentinel */
  };
  
! DL_EXPORT(void)
  PyMarshal_Init()
  {
  	(void) Py_InitModule("marshal", marshal_methods);

*** Modules/shamodule.c	Wed Jul 14 17:12:32 1999
***************
*** 582,588 ****
  	if (o!=NULL) PyDict_SetItemString(d,n,o); \
  	Py_XDECREF(o); }
  
! void
  initsha()
  {
  	PyObject *d, *m;
--- 582,588 ----
  	if (o!=NULL) PyDict_SetItemString(d,n,o); \
  	Py_XDECREF(o); }
  
! DL_EXPORT(void)
  initsha()
  {
  	PyObject *d, *m;



This is the patch for SWIG's embed.i

*** swig_lib/python/embed.i	Wed Jul 14 17:14:20 1999
***************
*** 99,105 ****
  }
  #endif
  
! /* extern struct _inittab *PyImport_Inittab; */
  
  int
  main(int argc, char **argv) {
--- 99,105 ----
  }
  #endif
  
! extern struct _inittab *PyImport_Inittab;
  
  int
  main(int argc, char **argv) {





From fp@contact.de  Wed Jul 14 17:34:51 1999
From: fp@contact.de (fp@contact.de)
Date: Wed, 14 Jul 1999 12:34:51 -0400 (EDT)
Subject: [Python-bugs-list] Re: SWIG's embed.i and Python 1.5.2 on WinNT (PR#25)
Message-ID: <199907141634.MAA28496@python.org>

Hi Guido,

SWIG automatically generates scripting language bindings
for C libraries. It provides a feature to build a standalone
interpreter that contains the wrapper module and all the
standard builtin modules of Python. For that purpose the
SWIG-generated module source provides its own `main',
"grabs" Python's inittab[] structure, adds the wrapper
module, sets PyImport_Inittab to the patched inittab and
calls Py_Main(). The generated source looks like this
(with some omissions):

	#define _PyImport_Inittab swig_inittab
	/* Grab Python's inittab[] structure */

	#include <config.c> /* This is Pythons's config.c! */

	#undef _PyImport_Inittab 

	/* Now define our own version of it.
	   Hopefully someone does not have more than 1000
	   built-in modules */

	struct _inittab _SwigImport_Inittab[1000];       

	[...]

	int
	main(int argc, char **argv) {
		swig_add_builtin(); /* add wrapper module */
		PyImport_Inittab = _SwigImport_Inittab;
		return Py_Main(argc,argv);
	}

If you allow, I'd like to forward your questions to Dave Beazley
(beazley@cs.uchicago.edu), the author of SWIG.

	- frank

P.S. Sorry for the duplicate PR#26. I was braindead and
     pressed "Reload".

Guido van Rossum wrote:
> I don't think that exporting module initialization calls is the right
> solution.  I don't know SWIG -- why is it calling these functions?
> If you reference some other extension module, will it require that
> module's init function to be exported?  On Unix, will it fail if those
> extensions happen to be dynamically loaded instead of statically linked?
> 
> A better approach would be to use the PyImport_ImportModule()
> function to import the module by name.  This will find the module
> you're looking for regardless of whether it is built in or provided
> as a shared library.

-- 
Frank Patz
CONTACT Software GmbH                 email: fp@contact.de
Wiener Str. 1-3                       phone: +49 421 20153 18
D-28359 Bremen                        fax:   +49 421 20153 41



From guido@CNRI.Reston.VA.US  Wed Jul 14 18:03:38 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Wed, 14 Jul 1999 13:03:38 -0400
Subject: [Python-bugs-list] Re: SWIG's embed.i and Python 1.5.2 on WinNT (PR#25)
In-Reply-To: Your message of "Wed, 14 Jul 1999 12:34:51 EDT."
 <199907141634.MAA28496@python.org>
References: <199907141634.MAA28496@python.org>
Message-ID: <199907141703.NAA12629@eric.cnri.reston.va.us>

> SWIG automatically generates scripting language bindings
> for C libraries.

I knew that :-)

> It provides a feature to build a standalone
> interpreter that contains the wrapper module and all the
> standard builtin modules of Python. For that purpose the
> SWIG-generated module source provides its own `main',
> "grabs" Python's inittab[] structure, adds the wrapper
> module, sets PyImport_Inittab to the patched inittab and
> calls Py_Main(). The generated source looks like this
> (with some omissions):
> 
> 	#define _PyImport_Inittab swig_inittab
> 	/* Grab Python's inittab[] structure */
> 
> 	#include <config.c> /* This is Pythons's config.c! */
> 
> 	#undef _PyImport_Inittab 
> 
> 	/* Now define our own version of it.
> 	   Hopefully someone does not have more than 1000
> 	   built-in modules */
> 
> 	struct _inittab _SwigImport_Inittab[1000];       
> 
> 	[...]
> 
> 	int
> 	main(int argc, char **argv) {
> 		swig_add_builtin(); /* add wrapper module */
> 		PyImport_Inittab = _SwigImport_Inittab;
> 		return Py_Main(argc,argv);
> 	}

I'm not sure I understand what this has to do with your original
request.  Do you still think it requires a patch to Python?

Also Python has a better way to manipulate the inittab than to play
dirty preprocessor tricks.  There's a whole API to deal with it:
PyImport_ExtendInittab(), PyImport_AppendInittab().

> If you allow, I'd like to forward your questions to Dave Beazley
> (beazley@cs.uchicago.edu), the author of SWIG.

Sure, go agead.

> P.S. Sorry for the duplicate PR#26. I was braindead and
>      pressed "Reload".

No problem -- it has happened to each of us.  We conclude that the
Jitterbug interface has a problem, but we can't easily fix it so we'll
live with it.

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



From guido@CNRI.Reston.VA.US  Wed Jul 14 18:03:46 1999
From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US)
Date: Wed, 14 Jul 1999 13:03:46 -0400 (EDT)
Subject: [Python-bugs-list] Re: SWIG's embed.i and Python 1.5.2 on WinNT (PR#25)
Message-ID: <199907141703.NAA28814@python.org>

> SWIG automatically generates scripting language bindings
> for C libraries.

I knew that :-)

> It provides a feature to build a standalone
> interpreter that contains the wrapper module and all the
> standard builtin modules of Python. For that purpose the
> SWIG-generated module source provides its own `main',
> "grabs" Python's inittab[] structure, adds the wrapper
> module, sets PyImport_Inittab to the patched inittab and
> calls Py_Main(). The generated source looks like this
> (with some omissions):
> 
> 	#define _PyImport_Inittab swig_inittab
> 	/* Grab Python's inittab[] structure */
> 
> 	#include <config.c> /* This is Pythons's config.c! */
> 
> 	#undef _PyImport_Inittab 
> 
> 	/* Now define our own version of it.
> 	   Hopefully someone does not have more than 1000
> 	   built-in modules */
> 
> 	struct _inittab _SwigImport_Inittab[1000];       
> 
> 	[...]
> 
> 	int
> 	main(int argc, char **argv) {
> 		swig_add_builtin(); /* add wrapper module */
> 		PyImport_Inittab = _SwigImport_Inittab;
> 		return Py_Main(argc,argv);
> 	}

I'm not sure I understand what this has to do with your original
request.  Do you still think it requires a patch to Python?

Also Python has a better way to manipulate the inittab than to play
dirty preprocessor tricks.  There's a whole API to deal with it:
PyImport_ExtendInittab(), PyImport_AppendInittab().

> If you allow, I'd like to forward your questions to Dave Beazley
> (beazley@cs.uchicago.edu), the author of SWIG.

Sure, go agead.

> P.S. Sorry for the duplicate PR#26. I was braindead and
>      pressed "Reload".

No problem -- it has happened to each of us.  We conclude that the
Jitterbug interface has a problem, but we can't easily fix it so we'll
live with it.

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




From fp@contact.de  Wed Jul 14 18:49:14 1999
From: fp@contact.de (fp@contact.de)
Date: Wed, 14 Jul 1999 13:49:14 -0400 (EDT)
Subject: [Python-bugs-list] Re: SWIG's embed.i and Python 1.5.2 on WinNT (PR#27)
Message-ID: <199907141749.NAA29738@python.org>

Guido van Rossum wrote:
> > SWIG automatically generates scripting language bindings
> > for C libraries.
> 
> I knew that :-)

I guess you do. Just in case :-)

> > It provides a feature to build a standalone
> > interpreter that contains the wrapper module and all the
> > standard builtin modules of Python. For that purpose the
> > SWIG-generated module source provides its own `main',
> > "grabs" Python's inittab[] structure, adds the wrapper
> > module, sets PyImport_Inittab to the patched inittab and
> > calls Py_Main(). The generated source looks like this
> > (with some omissions):
> >
> >       #define _PyImport_Inittab swig_inittab
> >       /* Grab Python's inittab[] structure */
> >
> >       #include <config.c> /* This is Pythons's config.c! */
> >
> >       #undef _PyImport_Inittab
> >
> >       /* Now define our own version of it.
> >          Hopefully someone does not have more than 1000
> >          built-in modules */
> >
> >       struct _inittab _SwigImport_Inittab[1000];
> >
> >       [...]
> >
> >       int
> >       main(int argc, char **argv) {
> >               swig_add_builtin(); /* add wrapper module */
> >               PyImport_Inittab = _SwigImport_Inittab;
> >               return Py_Main(argc,argv);
> >       }
> 
> I'm not sure I understand what this has to do with your original
> request.  Do you still think it requires a patch to Python?

The problem is that PyImport_Inittab lives in the DLL. It needs
to be exported since main() assigns to it. _SwigImport_Inittab
lives in my .EXE and has references to initimp, PyMarshal_Init
and initsha, and so those need to be exported too.
The initialization functions of all the other builtin modules
are declared "DL_EXPORT"; that was the reason I thougt initimp
etc. have been left out unintentionally.

> Also Python has a better way to manipulate the inittab than to play
> dirty preprocessor tricks.  There's a whole API to deal with it:
> PyImport_ExtendInittab(), PyImport_AppendInittab().

Seems to be a much cleaner way to do the same. The thing to be
changed is SWIG, I think. I will check that with Dave Beazley.

Thank you for your help,
	Frank

-- 
Frank Patz
CONTACT Software GmbH                 email: fp@contact.de
Wiener Str. 1-3                       phone: +49 421 20153 18
D-28359 Bremen                        fax:   +49 421 20153 41



From guido@python.org  Wed Jul 14 19:00:15 1999
From: guido@python.org (guido@python.org)
Date: Wed, 14 Jul 1999 14:00:15 -0400 (EDT)
Subject: [Python-bugs-list] Tkinter Image names may be reused (PR#28)
Message-ID: <199907141800.OAA00137@python.org>

Full_Name: GvR
Version: 1.5.2b
OS: 
Submission from: eric.cnri.reston.va.us (132.151.1.38)
Submitted by: guido


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.)




From mkes@ra.rockwell.com  Fri Jul 16 15:47:40 1999
From: mkes@ra.rockwell.com (mkes@ra.rockwell.com)
Date: Fri, 16 Jul 1999 10:47:40 -0400 (EDT)
Subject: [Python-bugs-list] 1.5.2 & xmllib : runtime error (PR#29)
Message-ID: <199907161447.KAA22062@python.org>

Full_Name: Miroslav Kein s
Version: 1.5.2
OS: FreeBSD 3.2
Submission from: (NULL) (205.175.223.11)


In the 1.5.2 I have experienced following problem . 
I wrote a simple XML parser using xmllib (the source code and the XML example
file is 
attached). When I run it it produces following runtime error:


odysseus:/usr/home/mira/engine> python
Python 1.5.2 (#2, May 11 1999, 17:14:37)  [GCC 2.7.2.1] on freebsd3
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import xmlparser
>>> p = xmlparser.KBParser()
>>> p.Run( '../xml/kb_test1.xml')
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "xmlparser.py", line 152, in Run
    self.close()
  File "/usr/local/lib/python1.5/xmllib.py", line 154, in close
    if self.__fixed:
AttributeError: _XMLParser__fixed
>>>   


The strange thing is that in  Python 1.5.2b1 this runs OK !!!

The source is here:
--------------------------------------------------------------------
import xmllib
import sys

## class MyXMLParser( xmllib.XMLParser ):

##     def unknown_starttag( self, tag, attributes ):
## 	print 'start tag: ' + tag + str( attributes )

##     def unknown_endtag( self, tag ):
## 	print 'end tag: ' + tag

##     def handle_data( self, data ):
## 	print data

##     def run( self, filename ):
## 	self.reset()
## 	file = open( filename, 'r' )
## 	self.feed( file.read())
## 	self.close()
## 	file.close()

class KBParser( xmllib.XMLParser ):

    KB = {}
    TagStack = []
    ReadData = 0

    def __init__( self ):
	self.attributes = { 'SYMPTOM_TEST': { 'IMPORTANCE' : 'MUST' }}
	self.elements = { 'KB': ( self.DictionaryTagStart, self.KBTagEnd  ),
			  'QUESTION': ( self.DictionaryTagStart, self.AddDataAs_ListInDictionary_Item
),
			  'QUESTION_ID':( self.LeafTagStart, self.ValueSourceTagEnd  ),
			  'TEXT':( self.LeafTagStart, self.GeneralTagEnd ),
			  'VALUE':( self.LeafTagStart, self.ValueTagEnd ),
			  'EXTERNAL_VARIABLE':( self.DictionaryTagStart,
self.AddDataAs_ListInDictionary_Item  ),
			  'EXTERNAL_VARIABLE_ID':( self.LeafTagStart, self.ValueSourceTagEnd ),
			  'DESCRIPTION':( self.LeafTagStart, self.GeneralTagEnd ),
			  'ATTRIBUTE':( self.DictionaryTagStart, self.AddDataAs_ListInDictionary_Item
),
			  'ATTRIBUTE_ID':( self.LeafTagStart, self.GeneralTagEnd ),
			  'SYMPTOM':( self.DictionaryTagStart, self.AddDataAs_ListInDictionary_Item
),
			  'SYMPTOM_ID':( self.LeafTagStart, self.SymptomIDTagEnd ),
			  'PARENT_ID':( self.LeafTagStart, self.GeneralTagEnd ),
			  'IDENTITY':( self.DictionaryTagStart, self.AddDataAs_ListInDictionary_Item
),
			  'DIAGNOSIS':( self.DictionaryTagStart, self.AddDataAs_ListInDictionary_Item
),
			  'DIAGNOSIS_ID':( self.LeafTagStart, self.GeneralTagEnd ),
			  'NAME':( self.LeafTagStart, self.GeneralTagEnd ),
			  'CASE':( self.ListTagStart, self.AddDataAs_ListInDictionary_Item ),
			  'SYMPTOM_TEST':( self.DictionaryTagStart, self.AddDataAs_ListInList_Item
),
			  'WEIGHT':( self.LeafTagStart, self.GeneralTagEnd ),
			  'CORRECTIVE_ACTION':( self.DictionaryTagStart,
self.AddDataAs_ListInDictionary_Item ),
			  'CORRECTIVE_ACTION_ID':( self.LeafTagStart, self.GeneralTagEnd ) }
	
    def handle_starttag( self, tag, method, attributes ):
	method( tag, attributes )

    def handle_data( self, data ):
	if self.ReadData:
	    self.TagStack[len( self.TagStack ) - 1]['dataStruct'] = data
	    self.ReadData = 0

    def handle_endtag( self, tag, method ):
	method( tag )

    def DictionaryTagStart( self, tag, attributes ):
	self.TagStack.append( { 'tagName' : tag, 'dataStruct' : {}, 'attributes' :
attributes } )

    def ListTagStart( self, tag, attributes ):
	self.TagStack.append( { 'tagName' : tag, 'dataStruct' : [], 'attributes' :
attributes } )

    def LeafTagStart( self, tag, attributes ):
	self.TagStack.append( { 'tagName' : tag, 'dataStruct' : None, 'attributes' :
attributes } )
	self.ReadData = 1	

    def GeneralTagEnd( self, tag ):
	stackDepth = len( self.TagStack )
	tagStructure = self.TagStack[stackDepth - 1]
	container = self.TagStack[stackDepth - 2]
	containerDataStorage = container['dataStruct']
	if type(containerDataStorage) is type( [] ):
	    containerDataStorage.append( { 'tag_value' : tagStructure['dataStruct'],
'tag_attribute' : tagStructure['attributes'] } )
	else:
	    containerDataStorage[tagStructure['tagName']] = { 'tag_value' :
tagStructure['dataStruct'], 'tag_attribute' : tagStructure['attributes'] }
	self.TagStack.remove( tagStructure ) 

    def AddDataAs_ListInDictionary_Item( self, tag ):
	stackDepth = len( self.TagStack )
	tagStructure = self.TagStack[stackDepth - 1]
	container = self.TagStack[stackDepth - 2]
	containerDataStorage = container['dataStruct']
	if containerDataStorage.has_key( tag ) == 0:
	    containerDataStorage[tag] = []
	containerDataStorage[tag].append( { 'tag_value' : tagStructure['dataStruct'],
'tag_attribute' : tagStructure['attributes'] } )
	self.TagStack.remove( tagStructure )

    def AddDataAs_ListInList_Item( self, tag ):
	stackDepth = len( self.TagStack )
	tagStructure = self.TagStack[stackDepth - 1]
	container = self.TagStack[stackDepth - 2]
	containerDataStorage = container['dataStruct']
	containerDataStorage.append( { 'tag_value' : tagStructure['dataStruct'],
'tag_attribute' : tagStructure['attributes'] } )
	self.TagStack.remove( tagStructure )
	
    def KBTagEnd( self, tag ):
	self.KB = self.TagStack[0]['dataStruct']
	self.TagStack.remove( self.TagStack[0] )

    def ValueTagEnd( self, tag ):
	stackDepth = len( self.TagStack )
	container = self.TagStack[stackDepth - 2]
	containerName = container['tagName']
	if containerName == 'QUESTION' or containerName  == 'EXTERNAL_VARIABLE':
	    self.AddDataAs_ListInDictionary_Item( tag )
	elif containerName == 'IDENTITY':
	    self.GeneralTagEnd( tag )
	else:
	    pass

    def ValueSourceTagEnd( self, tag ):
	stackDepth = len( self.TagStack )
	container = self.TagStack[stackDepth - 2]
	containerName = container['tagName']
	if containerName == 'QUESTION' or containerName == 'EXTERNAL_VARIABLE' or
containerName == 'IDENTITY':
	    self.GeneralTagEnd( tag )
	elif containerName == 'SYMPTOM' or containerName == 'ATTRIBUTE':
	    self.AddDataAs_ListInDictionary_Item( 'VALUE_SOURCE' )
	else:
	    pass	    

    def SymptomIDTagEnd( self, tag ):
	stackDepth = len( self.TagStack )
	container = self.TagStack[stackDepth - 2]
	containerName = container['tagName']
	if containerName == 'SYMPTOM':
	    self.GeneralTagEnd( tag )
	else:
	    self.AddDataAs_ListInDictionary_Item( tag )	    

    def handle_doctype( self, tag, data, bla1, bla2 ):
	pass

    def unknown_starttag( self, tag, attributes ):
	print 'unknown start tag: ' + tag + str( attributes )

    def unknown_endtag( self, tag ):
	print 'unknown end tag: ' + tag

    def Run( self, filename ):
	self.reset()
	TagStack = []	
	file = open( filename, 'r' )
	self.feed( file.read())
	self.close()
	file.close()
	return self.KB

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

Here is the XML file:

-------------------------------------------------------
<?xml version="1.0"?>
<!-- DOCTYPE KB SYSTEM "kb.dtd" -->

<KB>
	<QUESTION>
		<QUESTION_ID>Q1</QUESTION_ID>
		<TEXT>Are there any disturbancies in speed feedback ?</TEXT>
		<VALUE>Yes</VALUE>
		<VALUE>No</VALUE>
	</QUESTION>

	<QUESTION>
		<QUESTION_ID>Q2</QUESTION_ID>
		<TEXT>Are the disturbancies periodic ?</TEXT>
		<VALUE>Yes</VALUE>
		<VALUE>No</VALUE>
	</QUESTION>

	<QUESTION>
		<QUESTION_ID>Q3</QUESTION_ID>
		<TEXT>Is the frequency of oscillation proportional to the line speed ?</TEXT>
		<VALUE>Yes</VALUE>
		<VALUE>No</VALUE>
	</QUESTION>

	<QUESTION>
		<QUESTION_ID>Q4</QUESTION_ID>
		<TEXT>Does the problem disappear when the motor is disconnected from the
gearbox?</TEXT>
		<VALUE>Yes</VALUE>
		<VALUE>No</VALUE>
	</QUESTION>

	<QUESTION>
		<QUESTION_ID>Q5</QUESTION_ID>
		<TEXT>What frequency matches the frequency of oscillation ?</TEXT>
		<VALUE>Motor speed</VALUE>
		<VALUE>Motor speed times 2</VALUE>
		<VALUE>Gerbox output speed</VALUE>
		<VALUE>Gerbox output speed times 2</VALUE>
	</QUESTION>

	<ATTRIBUTE>
		<ATTRIBUTE_ID>A1</ATTRIBUTE_ID>
		<QUESTION_ID>Q1</QUESTION_ID>
		<SYMPTOM>
			<SYMPTOM_ID>S1</SYMPTOM_ID>
			<PARENT_ID>A1</PARENT_ID>
			<IDENTITY>
				<QUESTION_ID>Q1</QUESTION_ID>
				<VALUE>Yes</VALUE>
			</IDENTITY>
			<QUESTION_ID>Q2</QUESTION_ID>
		</SYMPTOM>
		<SYMPTOM>
			<SYMPTOM_ID>S2</SYMPTOM_ID>
			<PARENT_ID>A1</PARENT_ID>
			<IDENTITY>
				<QUESTION_ID>Q1</QUESTION_ID>
				<VALUE>No</VALUE>
			</IDENTITY>
		</SYMPTOM>
		<SYMPTOM>
			<SYMPTOM_ID>S3</SYMPTOM_ID>
			<PARENT_ID>S1</PARENT_ID>
			<IDENTITY>
				<QUESTION_ID>Q2</QUESTION_ID>
				<VALUE>Yes</VALUE>
			</IDENTITY>
			<QUESTION_ID>Q3</QUESTION_ID>
		</SYMPTOM>
		<SYMPTOM>
			<SYMPTOM_ID>S4</SYMPTOM_ID>
			<PARENT_ID>S1</PARENT_ID>
			<IDENTITY>
				<QUESTION_ID>Q2</QUESTION_ID>
				<VALUE>No</VALUE>
			</IDENTITY>
		</SYMPTOM>
		<SYMPTOM>
			<SYMPTOM_ID>S5</SYMPTOM_ID>
			<PARENT_ID>S3</PARENT_ID>
			<IDENTITY>
				<QUESTION_ID>Q3</QUESTION_ID>
				<VALUE>Yes</VALUE>
			</IDENTITY>
			<QUESTION_ID>Q5</QUESTION_ID>
		</SYMPTOM>
		<SYMPTOM>
			<SYMPTOM_ID>S6</SYMPTOM_ID>
			<PARENT_ID>S5</PARENT_ID>
			<IDENTITY>
				<QUESTION_ID>Q5</QUESTION_ID>
				<VALUE>Motor speed</VALUE>
			</IDENTITY>
		</SYMPTOM>
		<SYMPTOM>
			<SYMPTOM_ID>S7</SYMPTOM_ID>
			<PARENT_ID>S5</PARENT_ID>
			<IDENTITY>
				<QUESTION_ID>Q5</QUESTION_ID>
				<VALUE>Motor speed times 2</VALUE>
			</IDENTITY>
		</SYMPTOM>
		<SYMPTOM>
			<SYMPTOM_ID>S8</SYMPTOM_ID>
			<PARENT_ID>S5</PARENT_ID>
			<IDENTITY>
				<QUESTION_ID>Q5</QUESTION_ID>
				<VALUE>Gerbox output speed</VALUE>
			</IDENTITY>
		</SYMPTOM>
		<SYMPTOM>
			<SYMPTOM_ID>S9</SYMPTOM_ID>
			<PARENT_ID>S5</PARENT_ID>
			<IDENTITY>
				<QUESTION_ID>Q5</QUESTION_ID>
				<VALUE>Gerbox output speed times 2</VALUE>
			</IDENTITY>
		</SYMPTOM>
		<SYMPTOM>
			<SYMPTOM_ID>S10</SYMPTOM_ID>
			<PARENT_ID>S3</PARENT_ID>
			<IDENTITY>
				<QUESTION_ID>Q3</QUESTION_ID>
				<VALUE>No</VALUE>
			</IDENTITY>
		</SYMPTOM>
	</ATTRIBUTE>

	<ATTRIBUTE TYPE="CONFIG">
		<ATTRIBUTE_ID>A2</ATTRIBUTE_ID>
		<QUESTION_ID>Q4</QUESTION_ID>
		<SYMPTOM>
			<SYMPTOM_ID>S1</SYMPTOM_ID>
			<PARENT_ID>A2</PARENT_ID>
			<IDENTITY>
				<QUESTION_ID>Q4</QUESTION_ID>
				<VALUE>Yes</VALUE>
			</IDENTITY>
		</SYMPTOM>
		<SYMPTOM>
			<SYMPTOM_ID>S2</SYMPTOM_ID>
			<PARENT_ID>A2</PARENT_ID>
			<IDENTITY>
				<QUESTION_ID>Q4</QUESTION_ID>
				<VALUE>No</VALUE>
			</IDENTITY>
		</SYMPTOM>
	</ATTRIBUTE>

	<DIAGNOSIS>
		<DIAGNOSIS_ID>D1</DIAGNOSIS_ID>
		<NAME>Incorrect alignment motor - speed sensor</NAME>
		<CASE>
			<SYMPTOM_TEST>
				<ATTRIBUTE_ID>A1</ATTRIBUTE_ID>
				<SYMPTOM_ID>S7</SYMPTOM_ID>
				<WEIGHT>0.5</WEIGHT>
			</SYMPTOM_TEST>
			<SYMPTOM_TEST>
				<ATTRIBUTE_ID>A2</ATTRIBUTE_ID>
				<SYMPTOM_ID>S1</SYMPTOM_ID>
			</SYMPTOM_TEST>
		</CASE>
	</DIAGNOSIS>
	<DIAGNOSIS>
		<DIAGNOSIS_ID>D2</DIAGNOSIS_ID>
		<NAME>Incorrect alignment motor - gearbox</NAME>
		<CASE>
			<SYMPTOM_TEST>
				<ATTRIBUTE_ID>A1</ATTRIBUTE_ID>
				<SYMPTOM_ID>S7</SYMPTOM_ID>
				<WEIGHT>0.5</WEIGHT>
			</SYMPTOM_TEST>
			<SYMPTOM_TEST>
				<ATTRIBUTE_ID>A2</ATTRIBUTE_ID>
				<SYMPTOM_ID>S2</SYMPTOM_ID>
			</SYMPTOM_TEST>
		</CASE>
	</DIAGNOSIS>
</KB>

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





From tim.hochberg@ieee.org  Mon Jul 19 02:35:15 1999
From: tim.hochberg@ieee.org (tim.hochberg@ieee.org)
Date: Sun, 18 Jul 1999 21:35:15 -0400 (EDT)
Subject: [Python-bugs-list] slice __doc__ string is wrong (PR#30)
Message-ID: <199907190135.VAA20363@python.org>

Full_Name: Tim Hochberg
Version: 1.5.2
OS: Windows 95
Submission from: 2-404.phx.psn.net (205.164.63.104)


The __doc__ string for the slice function is wrong.

>>> slice.__doc__
'slice([start,] step[, stop]) -> slice object
Create a slice object.  This is used for slicing by the Numeric extensions.'

versus the library reference:

slice ([start,] stop[, step]) 
    Return a slice object representing the set of indices specified by
range(start, stop, step)....

The actual behaviour matches that described in the library reference.



From sjmachin@lexicon.net  Mon Jul 19 04:27:23 1999
From: sjmachin@lexicon.net (sjmachin@lexicon.net)
Date: Sun, 18 Jul 1999 23:27:23 -0400 (EDT)
Subject: [Python-bugs-list] string.zfill() mishandles empty string (PR#31)
Message-ID: <199907190327.XAA21576@python.org>

Full_Name: John Machin
Version: 1.5.2
OS: Win 95 & NT
Submission from: news.colonial.com.au (140.168.16.251)


[WIN95] C:\junk>c:\progra~1\python\python
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import string
>>> string.zfill('',4)
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "C:\Program Files\Python\Lib\string.py", line 478, in zfill
    if s[0] in ('-', '+'):
IndexError: string index out of range
>>>
Comment: this should return '0000'.
Suggested fix: 
After the line that says
   if n >= width: return s
add this line:
   if not n: return '0' * width



From mkes@ra.rockwell.com  Mon Jul 19 09:36:30 1999
From: mkes@ra.rockwell.com (mkes@ra.rockwell.com)
Date: Mon, 19 Jul 1999 04:36:30 -0400 (EDT)
Subject: [Python-bugs-list] Re: 1.5.2 & xmllib : runtime error (PR#29)
Message-ID: <199907190836.EAA00142@python.org>

Thanks,

... now it works.
Nevertheless it seems to me strange now that the 1.5.2b1 was able to tolerate
this - I run the controversial program many times. :-))

Mira




Guido van Rossum <bugs-py@python.org> on 17.07.99 17:54:39

To:   Miroslav Kes/GTS/RA/Rockwell
cc:
Subject:  Re: 1.5.2 & xmllib : runtime error (PR#29)




This is not a bug -- you haven't called the base class __init__ method
in your derived class __init__ method.








From brainval@ehome.encis.es  Mon Jul 19 11:24:49 1999
From: brainval@ehome.encis.es (brainval@ehome.encis.es)
Date: Mon, 19 Jul 1999 06:24:49 -0400 (EDT)
Subject: [Python-bugs-list] compiling long strings crashes (PR#32)
Message-ID: <199907191024.GAA01758@python.org>

Full_Name: Ricardo Montesa Andres
Version: 1.5.2
OS: IRIX 6.5
Submission from: be-209-vale-x2.red.retevision.es (62.81.86.209)


- Make a file consisting of a simple commented paragraph like:
"""
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
.....
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
"""

so that it occupies 20Mb more or less.

Running python with this file crashes with the message:
SystemError: com_addbyte: byte out of range

We are having this kind of error when compiling big files.
With other kind of strings the file can be of 1Mb more or less to make it
crash.
Your help will be very much appreciated.
Thank you.



From sjoerd@oratrix.nl  Mon Jul 19 12:13:22 1999
From: sjoerd@oratrix.nl (Sjoerd Mullender)
Date: Mon, 19 Jul 1999 13:13:22 +0200
Subject: [Python-bugs-list] 1.5.2 & xmllib : runtime error (PR#29)
In-Reply-To: Your message of Fri, 16 Jul 1999 10:47:40 -0400.
 <199907161447.KAA22062@python.org>
References: <199907161447.KAA22062@python.org>
Message-ID: <19990719111323.7D43E301CFA@bireme.oratrix.nl>

You should call xmllib.XMLParser.__init__(self) from your __init__
method.

On Fri, Jul 16 1999 mkes@ra.rockwell.com wrote:

> Full_Name: Miroslav Kein s
> Version: 1.5.2
> OS: FreeBSD 3.2
> Submission from: (NULL) (205.175.223.11)
> 
> 
> In the 1.5.2 I have experienced following problem . 
> I wrote a simple XML parser using xmllib (the source code and the XML example
> file is 
> attached). When I run it it produces following runtime error:
> 
> 
> odysseus:/usr/home/mira/engine> python
> Python 1.5.2 (#2, May 11 1999, 17:14:37)  [GCC 2.7.2.1] on freebsd3
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> import xmlparser
> >>> p = xmlparser.KBParser()
> >>> p.Run( '../xml/kb_test1.xml')
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
>   File "xmlparser.py", line 152, in Run
>     self.close()
>   File "/usr/local/lib/python1.5/xmllib.py", line 154, in close
>     if self.__fixed:
> AttributeError: _XMLParser__fixed
> >>>   
> 
> 
> The strange thing is that in  Python 1.5.2b1 this runs OK !!!
> 
> The source is here:
> --------------------------------------------------------------------
> import xmllib
> import sys
> 
> ## class MyXMLParser( xmllib.XMLParser ):
> 
> ##     def unknown_starttag( self, tag, attributes ):
> ## 	print 'start tag: ' + tag + str( attributes )
> 
> ##     def unknown_endtag( self, tag ):
> ## 	print 'end tag: ' + tag
> 
> ##     def handle_data( self, data ):
> ## 	print data
> 
> ##     def run( self, filename ):
> ## 	self.reset()
> ## 	file = open( filename, 'r' )
> ## 	self.feed( file.read())
> ## 	self.close()
> ## 	file.close()
> 
> class KBParser( xmllib.XMLParser ):
> 
>     KB = {}
>     TagStack = []
>     ReadData = 0
> 
>     def __init__( self ):
> 	self.attributes = { 'SYMPTOM_TEST': { 'IMPORTANCE' : 'MUST' }}
> 	self.elements = { 'KB': ( self.DictionaryTagStart, self.KBTagEnd  ),
> 			  'QUESTION': ( self.DictionaryTagStart, self.AddDataAs_ListInDictionary_Item
> ),
> 			  'QUESTION_ID':( self.LeafTagStart, self.ValueSourceTagEnd  ),
> 			  'TEXT':( self.LeafTagStart, self.GeneralTagEnd ),
> 			  'VALUE':( self.LeafTagStart, self.ValueTagEnd ),
> 			  'EXTERNAL_VARIABLE':( self.DictionaryTagStart,
> self.AddDataAs_ListInDictionary_Item  ),
> 			  'EXTERNAL_VARIABLE_ID':( self.LeafTagStart, self.ValueSourceTagEnd ),
> 			  'DESCRIPTION':( self.LeafTagStart, self.GeneralTagEnd ),
> 			  'ATTRIBUTE':( self.DictionaryTagStart, self.AddDataAs_ListInDictionary_Item
> ),
> 			  'ATTRIBUTE_ID':( self.LeafTagStart, self.GeneralTagEnd ),
> 			  'SYMPTOM':( self.DictionaryTagStart, self.AddDataAs_ListInDictionary_Item
> ),
> 			  'SYMPTOM_ID':( self.LeafTagStart, self.SymptomIDTagEnd ),
> 			  'PARENT_ID':( self.LeafTagStart, self.GeneralTagEnd ),
> 			  'IDENTITY':( self.DictionaryTagStart, self.AddDataAs_ListInDictionary_Item
> ),
> 			  'DIAGNOSIS':( self.DictionaryTagStart, self.AddDataAs_ListInDictionary_Item
> ),
> 			  'DIAGNOSIS_ID':( self.LeafTagStart, self.GeneralTagEnd ),
> 			  'NAME':( self.LeafTagStart, self.GeneralTagEnd ),
> 			  'CASE':( self.ListTagStart, self.AddDataAs_ListInDictionary_Item ),
> 			  'SYMPTOM_TEST':( self.DictionaryTagStart, self.AddDataAs_ListInList_Item
> ),
> 			  'WEIGHT':( self.LeafTagStart, self.GeneralTagEnd ),
> 			  'CORRECTIVE_ACTION':( self.DictionaryTagStart,
> self.AddDataAs_ListInDictionary_Item ),
> 			  'CORRECTIVE_ACTION_ID':( self.LeafTagStart, self.GeneralTagEnd ) }
> 	
>     def handle_starttag( self, tag, method, attributes ):
> 	method( tag, attributes )
> 
>     def handle_data( self, data ):
> 	if self.ReadData:
> 	    self.TagStack[len( self.TagStack ) - 1]['dataStruct'] = data
> 	    self.ReadData = 0
> 
>     def handle_endtag( self, tag, method ):
> 	method( tag )
> 
>     def DictionaryTagStart( self, tag, attributes ):
> 	self.TagStack.append( { 'tagName' : tag, 'dataStruct' : {}, 'attributes' :
> attributes } )
> 
>     def ListTagStart( self, tag, attributes ):
> 	self.TagStack.append( { 'tagName' : tag, 'dataStruct' : [], 'attributes' :
> attributes } )
> 
>     def LeafTagStart( self, tag, attributes ):
> 	self.TagStack.append( { 'tagName' : tag, 'dataStruct' : None, 'attributes' :
> attributes } )
> 	self.ReadData = 1	
> 
>     def GeneralTagEnd( self, tag ):
> 	stackDepth = len( self.TagStack )
> 	tagStructure = self.TagStack[stackDepth - 1]
> 	container = self.TagStack[stackDepth - 2]
> 	containerDataStorage = container['dataStruct']
> 	if type(containerDataStorage) is type( [] ):
> 	    containerDataStorage.append( { 'tag_value' : tagStructure['dataStruct'],
> 'tag_attribute' : tagStructure['attributes'] } )
> 	else:
> 	    containerDataStorage[tagStructure['tagName']] = { 'tag_value' :
> tagStructure['dataStruct'], 'tag_attribute' : tagStructure['attributes'] }
> 	self.TagStack.remove( tagStructure ) 
> 
>     def AddDataAs_ListInDictionary_Item( self, tag ):
> 	stackDepth = len( self.TagStack )
> 	tagStructure = self.TagStack[stackDepth - 1]
> 	container = self.TagStack[stackDepth - 2]
> 	containerDataStorage = container['dataStruct']
> 	if containerDataStorage.has_key( tag ) == 0:
> 	    containerDataStorage[tag] = []
> 	containerDataStorage[tag].append( { 'tag_value' : tagStructure['dataStruct'],
> 'tag_attribute' : tagStructure['attributes'] } )
> 	self.TagStack.remove( tagStructure )
> 
>     def AddDataAs_ListInList_Item( self, tag ):
> 	stackDepth = len( self.TagStack )
> 	tagStructure = self.TagStack[stackDepth - 1]
> 	container = self.TagStack[stackDepth - 2]
> 	containerDataStorage = container['dataStruct']
> 	containerDataStorage.append( { 'tag_value' : tagStructure['dataStruct'],
> 'tag_attribute' : tagStructure['attributes'] } )
> 	self.TagStack.remove( tagStructure )
> 	
>     def KBTagEnd( self, tag ):
> 	self.KB = self.TagStack[0]['dataStruct']
> 	self.TagStack.remove( self.TagStack[0] )
> 
>     def ValueTagEnd( self, tag ):
> 	stackDepth = len( self.TagStack )
> 	container = self.TagStack[stackDepth - 2]
> 	containerName = container['tagName']
> 	if containerName == 'QUESTION' or containerName  == 'EXTERNAL_VARIABLE':
> 	    self.AddDataAs_ListInDictionary_Item( tag )
> 	elif containerName == 'IDENTITY':
> 	    self.GeneralTagEnd( tag )
> 	else:
> 	    pass
> 
>     def ValueSourceTagEnd( self, tag ):
> 	stackDepth = len( self.TagStack )
> 	container = self.TagStack[stackDepth - 2]
> 	containerName = container['tagName']
> 	if containerName == 'QUESTION' or containerName == 'EXTERNAL_VARIABLE' or
> containerName == 'IDENTITY':
> 	    self.GeneralTagEnd( tag )
> 	elif containerName == 'SYMPTOM' or containerName == 'ATTRIBUTE':
> 	    self.AddDataAs_ListInDictionary_Item( 'VALUE_SOURCE' )
> 	else:
> 	    pass	    
> 
>     def SymptomIDTagEnd( self, tag ):
> 	stackDepth = len( self.TagStack )
> 	container = self.TagStack[stackDepth - 2]
> 	containerName = container['tagName']
> 	if containerName == 'SYMPTOM':
> 	    self.GeneralTagEnd( tag )
> 	else:
> 	    self.AddDataAs_ListInDictionary_Item( tag )	    
> 
>     def handle_doctype( self, tag, data, bla1, bla2 ):
> 	pass
> 
>     def unknown_starttag( self, tag, attributes ):
> 	print 'unknown start tag: ' + tag + str( attributes )
> 
>     def unknown_endtag( self, tag ):
> 	print 'unknown end tag: ' + tag
> 
>     def Run( self, filename ):
> 	self.reset()
> 	TagStack = []	
> 	file = open( filename, 'r' )
> 	self.feed( file.read())
> 	self.close()
> 	file.close()
> 	return self.KB
> 
> -------------------------------------------------------------------------
> 
> Here is the XML file:
> 
> -------------------------------------------------------
> <?xml version="1.0"?>
> <!-- DOCTYPE KB SYSTEM "kb.dtd" -->
> 
> <KB>
> 	<QUESTION>
> 		<QUESTION_ID>Q1</QUESTION_ID>
> 		<TEXT>Are there any disturbancies in speed feedback ?</TEXT>
> 		<VALUE>Yes</VALUE>
> 		<VALUE>No</VALUE>
> 	</QUESTION>
> 
> 	<QUESTION>
> 		<QUESTION_ID>Q2</QUESTION_ID>
> 		<TEXT>Are the disturbancies periodic ?</TEXT>
> 		<VALUE>Yes</VALUE>
> 		<VALUE>No</VALUE>
> 	</QUESTION>
> 
> 	<QUESTION>
> 		<QUESTION_ID>Q3</QUESTION_ID>
> 		<TEXT>Is the frequency of oscillation proportional to the line speed ?</TEXT>
> 		<VALUE>Yes</VALUE>
> 		<VALUE>No</VALUE>
> 	</QUESTION>
> 
> 	<QUESTION>
> 		<QUESTION_ID>Q4</QUESTION_ID>
> 		<TEXT>Does the problem disappear when the motor is disconnected from the
> gearbox?</TEXT>
> 		<VALUE>Yes</VALUE>
> 		<VALUE>No</VALUE>
> 	</QUESTION>
> 
> 	<QUESTION>
> 		<QUESTION_ID>Q5</QUESTION_ID>
> 		<TEXT>What frequency matches the frequency of oscillation ?</TEXT>
> 		<VALUE>Motor speed</VALUE>
> 		<VALUE>Motor speed times 2</VALUE>
> 		<VALUE>Gerbox output speed</VALUE>
> 		<VALUE>Gerbox output speed times 2</VALUE>
> 	</QUESTION>
> 
> 	<ATTRIBUTE>
> 		<ATTRIBUTE_ID>A1</ATTRIBUTE_ID>
> 		<QUESTION_ID>Q1</QUESTION_ID>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S1</SYMPTOM_ID>
> 			<PARENT_ID>A1</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q1</QUESTION_ID>
> 				<VALUE>Yes</VALUE>
> 			</IDENTITY>
> 			<QUESTION_ID>Q2</QUESTION_ID>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S2</SYMPTOM_ID>
> 			<PARENT_ID>A1</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q1</QUESTION_ID>
> 				<VALUE>No</VALUE>
> 			</IDENTITY>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S3</SYMPTOM_ID>
> 			<PARENT_ID>S1</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q2</QUESTION_ID>
> 				<VALUE>Yes</VALUE>
> 			</IDENTITY>
> 			<QUESTION_ID>Q3</QUESTION_ID>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S4</SYMPTOM_ID>
> 			<PARENT_ID>S1</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q2</QUESTION_ID>
> 				<VALUE>No</VALUE>
> 			</IDENTITY>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S5</SYMPTOM_ID>
> 			<PARENT_ID>S3</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q3</QUESTION_ID>
> 				<VALUE>Yes</VALUE>
> 			</IDENTITY>
> 			<QUESTION_ID>Q5</QUESTION_ID>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S6</SYMPTOM_ID>
> 			<PARENT_ID>S5</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q5</QUESTION_ID>
> 				<VALUE>Motor speed</VALUE>
> 			</IDENTITY>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S7</SYMPTOM_ID>
> 			<PARENT_ID>S5</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q5</QUESTION_ID>
> 				<VALUE>Motor speed times 2</VALUE>
> 			</IDENTITY>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S8</SYMPTOM_ID>
> 			<PARENT_ID>S5</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q5</QUESTION_ID>
> 				<VALUE>Gerbox output speed</VALUE>
> 			</IDENTITY>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S9</SYMPTOM_ID>
> 			<PARENT_ID>S5</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q5</QUESTION_ID>
> 				<VALUE>Gerbox output speed times 2</VALUE>
> 			</IDENTITY>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S10</SYMPTOM_ID>
> 			<PARENT_ID>S3</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q3</QUESTION_ID>
> 				<VALUE>No</VALUE>
> 			</IDENTITY>
> 		</SYMPTOM>
> 	</ATTRIBUTE>
> 
> 	<ATTRIBUTE TYPE="CONFIG">
> 		<ATTRIBUTE_ID>A2</ATTRIBUTE_ID>
> 		<QUESTION_ID>Q4</QUESTION_ID>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S1</SYMPTOM_ID>
> 			<PARENT_ID>A2</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q4</QUESTION_ID>
> 				<VALUE>Yes</VALUE>
> 			</IDENTITY>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S2</SYMPTOM_ID>
> 			<PARENT_ID>A2</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q4</QUESTION_ID>
> 				<VALUE>No</VALUE>
> 			</IDENTITY>
> 		</SYMPTOM>
> 	</ATTRIBUTE>
> 
> 	<DIAGNOSIS>
> 		<DIAGNOSIS_ID>D1</DIAGNOSIS_ID>
> 		<NAME>Incorrect alignment motor - speed sensor</NAME>
> 		<CASE>
> 			<SYMPTOM_TEST>
> 				<ATTRIBUTE_ID>A1</ATTRIBUTE_ID>
> 				<SYMPTOM_ID>S7</SYMPTOM_ID>
> 				<WEIGHT>0.5</WEIGHT>
> 			</SYMPTOM_TEST>
> 			<SYMPTOM_TEST>
> 				<ATTRIBUTE_ID>A2</ATTRIBUTE_ID>
> 				<SYMPTOM_ID>S1</SYMPTOM_ID>
> 			</SYMPTOM_TEST>
> 		</CASE>
> 	</DIAGNOSIS>
> 	<DIAGNOSIS>
> 		<DIAGNOSIS_ID>D2</DIAGNOSIS_ID>
> 		<NAME>Incorrect alignment motor - gearbox</NAME>
> 		<CASE>
> 			<SYMPTOM_TEST>
> 				<ATTRIBUTE_ID>A1</ATTRIBUTE_ID>
> 				<SYMPTOM_ID>S7</SYMPTOM_ID>
> 				<WEIGHT>0.5</WEIGHT>
> 			</SYMPTOM_TEST>
> 			<SYMPTOM_TEST>
> 				<ATTRIBUTE_ID>A2</ATTRIBUTE_ID>
> 				<SYMPTOM_ID>S2</SYMPTOM_ID>
> 			</SYMPTOM_TEST>
> 		</CASE>
> 	</DIAGNOSIS>
> </KB>
> 
> -------------------------------------------------------------------------
> 
> 
> 
> 
> 

-- Sjoerd Mullender <sjoerd.mullender@oratrix.com>


From sjoerd@oratrix.nl  Mon Jul 19 12:13:33 1999
From: sjoerd@oratrix.nl (sjoerd@oratrix.nl)
Date: Mon, 19 Jul 1999 07:13:33 -0400 (EDT)
Subject: [Python-bugs-list] 1.5.2 & xmllib : runtime error (PR#29)
Message-ID: <199907191113.HAA03288@python.org>

You should call xmllib.XMLParser.__init__(self) from your __init__
method.

On Fri, Jul 16 1999 mkes@ra.rockwell.com wrote:

> Full_Name: Miroslav Kein s
> Version: 1.5.2
> OS: FreeBSD 3.2
> Submission from: (NULL) (205.175.223.11)
> 
> 
> In the 1.5.2 I have experienced following problem . 
> I wrote a simple XML parser using xmllib (the source code and the XML example
> file is 
> attached). When I run it it produces following runtime error:
> 
> 
> odysseus:/usr/home/mira/engine> python
> Python 1.5.2 (#2, May 11 1999, 17:14:37)  [GCC 2.7.2.1] on freebsd3
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> import xmlparser
> >>> p = xmlparser.KBParser()
> >>> p.Run( '../xml/kb_test1.xml')
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
>   File "xmlparser.py", line 152, in Run
>     self.close()
>   File "/usr/local/lib/python1.5/xmllib.py", line 154, in close
>     if self.__fixed:
> AttributeError: _XMLParser__fixed
> >>>   
> 
> 
> The strange thing is that in  Python 1.5.2b1 this runs OK !!!
> 
> The source is here:
> --------------------------------------------------------------------
> import xmllib
> import sys
> 
> ## class MyXMLParser( xmllib.XMLParser ):
> 
> ##     def unknown_starttag( self, tag, attributes ):
> ## 	print 'start tag: ' + tag + str( attributes )
> 
> ##     def unknown_endtag( self, tag ):
> ## 	print 'end tag: ' + tag
> 
> ##     def handle_data( self, data ):
> ## 	print data
> 
> ##     def run( self, filename ):
> ## 	self.reset()
> ## 	file = open( filename, 'r' )
> ## 	self.feed( file.read())
> ## 	self.close()
> ## 	file.close()
> 
> class KBParser( xmllib.XMLParser ):
> 
>     KB = {}
>     TagStack = []
>     ReadData = 0
> 
>     def __init__( self ):
> 	self.attributes = { 'SYMPTOM_TEST': { 'IMPORTANCE' : 'MUST' }}
> 	self.elements = { 'KB': ( self.DictionaryTagStart, self.KBTagEnd  ),
> 			  'QUESTION': ( self.DictionaryTagStart, self.AddDataAs_ListInDictionary_Item
> ),
> 			  'QUESTION_ID':( self.LeafTagStart, self.ValueSourceTagEnd  ),
> 			  'TEXT':( self.LeafTagStart, self.GeneralTagEnd ),
> 			  'VALUE':( self.LeafTagStart, self.ValueTagEnd ),
> 			  'EXTERNAL_VARIABLE':( self.DictionaryTagStart,
> self.AddDataAs_ListInDictionary_Item  ),
> 			  'EXTERNAL_VARIABLE_ID':( self.LeafTagStart, self.ValueSourceTagEnd ),
> 			  'DESCRIPTION':( self.LeafTagStart, self.GeneralTagEnd ),
> 			  'ATTRIBUTE':( self.DictionaryTagStart, self.AddDataAs_ListInDictionary_Item
> ),
> 			  'ATTRIBUTE_ID':( self.LeafTagStart, self.GeneralTagEnd ),
> 			  'SYMPTOM':( self.DictionaryTagStart, self.AddDataAs_ListInDictionary_Item
> ),
> 			  'SYMPTOM_ID':( self.LeafTagStart, self.SymptomIDTagEnd ),
> 			  'PARENT_ID':( self.LeafTagStart, self.GeneralTagEnd ),
> 			  'IDENTITY':( self.DictionaryTagStart, self.AddDataAs_ListInDictionary_Item
> ),
> 			  'DIAGNOSIS':( self.DictionaryTagStart, self.AddDataAs_ListInDictionary_Item
> ),
> 			  'DIAGNOSIS_ID':( self.LeafTagStart, self.GeneralTagEnd ),
> 			  'NAME':( self.LeafTagStart, self.GeneralTagEnd ),
> 			  'CASE':( self.ListTagStart, self.AddDataAs_ListInDictionary_Item ),
> 			  'SYMPTOM_TEST':( self.DictionaryTagStart, self.AddDataAs_ListInList_Item
> ),
> 			  'WEIGHT':( self.LeafTagStart, self.GeneralTagEnd ),
> 			  'CORRECTIVE_ACTION':( self.DictionaryTagStart,
> self.AddDataAs_ListInDictionary_Item ),
> 			  'CORRECTIVE_ACTION_ID':( self.LeafTagStart, self.GeneralTagEnd ) }
> 	
>     def handle_starttag( self, tag, method, attributes ):
> 	method( tag, attributes )
> 
>     def handle_data( self, data ):
> 	if self.ReadData:
> 	    self.TagStack[len( self.TagStack ) - 1]['dataStruct'] = data
> 	    self.ReadData = 0
> 
>     def handle_endtag( self, tag, method ):
> 	method( tag )
> 
>     def DictionaryTagStart( self, tag, attributes ):
> 	self.TagStack.append( { 'tagName' : tag, 'dataStruct' : {}, 'attributes' :
> attributes } )
> 
>     def ListTagStart( self, tag, attributes ):
> 	self.TagStack.append( { 'tagName' : tag, 'dataStruct' : [], 'attributes' :
> attributes } )
> 
>     def LeafTagStart( self, tag, attributes ):
> 	self.TagStack.append( { 'tagName' : tag, 'dataStruct' : None, 'attributes' :
> attributes } )
> 	self.ReadData = 1	
> 
>     def GeneralTagEnd( self, tag ):
> 	stackDepth = len( self.TagStack )
> 	tagStructure = self.TagStack[stackDepth - 1]
> 	container = self.TagStack[stackDepth - 2]
> 	containerDataStorage = container['dataStruct']
> 	if type(containerDataStorage) is type( [] ):
> 	    containerDataStorage.append( { 'tag_value' : tagStructure['dataStruct'],
> 'tag_attribute' : tagStructure['attributes'] } )
> 	else:
> 	    containerDataStorage[tagStructure['tagName']] = { 'tag_value' :
> tagStructure['dataStruct'], 'tag_attribute' : tagStructure['attributes'] }
> 	self.TagStack.remove( tagStructure ) 
> 
>     def AddDataAs_ListInDictionary_Item( self, tag ):
> 	stackDepth = len( self.TagStack )
> 	tagStructure = self.TagStack[stackDepth - 1]
> 	container = self.TagStack[stackDepth - 2]
> 	containerDataStorage = container['dataStruct']
> 	if containerDataStorage.has_key( tag ) == 0:
> 	    containerDataStorage[tag] = []
> 	containerDataStorage[tag].append( { 'tag_value' : tagStructure['dataStruct'],
> 'tag_attribute' : tagStructure['attributes'] } )
> 	self.TagStack.remove( tagStructure )
> 
>     def AddDataAs_ListInList_Item( self, tag ):
> 	stackDepth = len( self.TagStack )
> 	tagStructure = self.TagStack[stackDepth - 1]
> 	container = self.TagStack[stackDepth - 2]
> 	containerDataStorage = container['dataStruct']
> 	containerDataStorage.append( { 'tag_value' : tagStructure['dataStruct'],
> 'tag_attribute' : tagStructure['attributes'] } )
> 	self.TagStack.remove( tagStructure )
> 	
>     def KBTagEnd( self, tag ):
> 	self.KB = self.TagStack[0]['dataStruct']
> 	self.TagStack.remove( self.TagStack[0] )
> 
>     def ValueTagEnd( self, tag ):
> 	stackDepth = len( self.TagStack )
> 	container = self.TagStack[stackDepth - 2]
> 	containerName = container['tagName']
> 	if containerName == 'QUESTION' or containerName  == 'EXTERNAL_VARIABLE':
> 	    self.AddDataAs_ListInDictionary_Item( tag )
> 	elif containerName == 'IDENTITY':
> 	    self.GeneralTagEnd( tag )
> 	else:
> 	    pass
> 
>     def ValueSourceTagEnd( self, tag ):
> 	stackDepth = len( self.TagStack )
> 	container = self.TagStack[stackDepth - 2]
> 	containerName = container['tagName']
> 	if containerName == 'QUESTION' or containerName == 'EXTERNAL_VARIABLE' or
> containerName == 'IDENTITY':
> 	    self.GeneralTagEnd( tag )
> 	elif containerName == 'SYMPTOM' or containerName == 'ATTRIBUTE':
> 	    self.AddDataAs_ListInDictionary_Item( 'VALUE_SOURCE' )
> 	else:
> 	    pass	    
> 
>     def SymptomIDTagEnd( self, tag ):
> 	stackDepth = len( self.TagStack )
> 	container = self.TagStack[stackDepth - 2]
> 	containerName = container['tagName']
> 	if containerName == 'SYMPTOM':
> 	    self.GeneralTagEnd( tag )
> 	else:
> 	    self.AddDataAs_ListInDictionary_Item( tag )	    
> 
>     def handle_doctype( self, tag, data, bla1, bla2 ):
> 	pass
> 
>     def unknown_starttag( self, tag, attributes ):
> 	print 'unknown start tag: ' + tag + str( attributes )
> 
>     def unknown_endtag( self, tag ):
> 	print 'unknown end tag: ' + tag
> 
>     def Run( self, filename ):
> 	self.reset()
> 	TagStack = []	
> 	file = open( filename, 'r' )
> 	self.feed( file.read())
> 	self.close()
> 	file.close()
> 	return self.KB
> 
> -------------------------------------------------------------------------
> 
> Here is the XML file:
> 
> -------------------------------------------------------
> <?xml version="1.0"?>
> <!-- DOCTYPE KB SYSTEM "kb.dtd" -->
> 
> <KB>
> 	<QUESTION>
> 		<QUESTION_ID>Q1</QUESTION_ID>
> 		<TEXT>Are there any disturbancies in speed feedback ?</TEXT>
> 		<VALUE>Yes</VALUE>
> 		<VALUE>No</VALUE>
> 	</QUESTION>
> 
> 	<QUESTION>
> 		<QUESTION_ID>Q2</QUESTION_ID>
> 		<TEXT>Are the disturbancies periodic ?</TEXT>
> 		<VALUE>Yes</VALUE>
> 		<VALUE>No</VALUE>
> 	</QUESTION>
> 
> 	<QUESTION>
> 		<QUESTION_ID>Q3</QUESTION_ID>
> 		<TEXT>Is the frequency of oscillation proportional to the line speed ?</TEXT>
> 		<VALUE>Yes</VALUE>
> 		<VALUE>No</VALUE>
> 	</QUESTION>
> 
> 	<QUESTION>
> 		<QUESTION_ID>Q4</QUESTION_ID>
> 		<TEXT>Does the problem disappear when the motor is disconnected from the
> gearbox?</TEXT>
> 		<VALUE>Yes</VALUE>
> 		<VALUE>No</VALUE>
> 	</QUESTION>
> 
> 	<QUESTION>
> 		<QUESTION_ID>Q5</QUESTION_ID>
> 		<TEXT>What frequency matches the frequency of oscillation ?</TEXT>
> 		<VALUE>Motor speed</VALUE>
> 		<VALUE>Motor speed times 2</VALUE>
> 		<VALUE>Gerbox output speed</VALUE>
> 		<VALUE>Gerbox output speed times 2</VALUE>
> 	</QUESTION>
> 
> 	<ATTRIBUTE>
> 		<ATTRIBUTE_ID>A1</ATTRIBUTE_ID>
> 		<QUESTION_ID>Q1</QUESTION_ID>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S1</SYMPTOM_ID>
> 			<PARENT_ID>A1</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q1</QUESTION_ID>
> 				<VALUE>Yes</VALUE>
> 			</IDENTITY>
> 			<QUESTION_ID>Q2</QUESTION_ID>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S2</SYMPTOM_ID>
> 			<PARENT_ID>A1</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q1</QUESTION_ID>
> 				<VALUE>No</VALUE>
> 			</IDENTITY>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S3</SYMPTOM_ID>
> 			<PARENT_ID>S1</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q2</QUESTION_ID>
> 				<VALUE>Yes</VALUE>
> 			</IDENTITY>
> 			<QUESTION_ID>Q3</QUESTION_ID>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S4</SYMPTOM_ID>
> 			<PARENT_ID>S1</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q2</QUESTION_ID>
> 				<VALUE>No</VALUE>
> 			</IDENTITY>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S5</SYMPTOM_ID>
> 			<PARENT_ID>S3</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q3</QUESTION_ID>
> 				<VALUE>Yes</VALUE>
> 			</IDENTITY>
> 			<QUESTION_ID>Q5</QUESTION_ID>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S6</SYMPTOM_ID>
> 			<PARENT_ID>S5</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q5</QUESTION_ID>
> 				<VALUE>Motor speed</VALUE>
> 			</IDENTITY>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S7</SYMPTOM_ID>
> 			<PARENT_ID>S5</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q5</QUESTION_ID>
> 				<VALUE>Motor speed times 2</VALUE>
> 			</IDENTITY>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S8</SYMPTOM_ID>
> 			<PARENT_ID>S5</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q5</QUESTION_ID>
> 				<VALUE>Gerbox output speed</VALUE>
> 			</IDENTITY>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S9</SYMPTOM_ID>
> 			<PARENT_ID>S5</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q5</QUESTION_ID>
> 				<VALUE>Gerbox output speed times 2</VALUE>
> 			</IDENTITY>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S10</SYMPTOM_ID>
> 			<PARENT_ID>S3</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q3</QUESTION_ID>
> 				<VALUE>No</VALUE>
> 			</IDENTITY>
> 		</SYMPTOM>
> 	</ATTRIBUTE>
> 
> 	<ATTRIBUTE TYPE="CONFIG">
> 		<ATTRIBUTE_ID>A2</ATTRIBUTE_ID>
> 		<QUESTION_ID>Q4</QUESTION_ID>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S1</SYMPTOM_ID>
> 			<PARENT_ID>A2</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q4</QUESTION_ID>
> 				<VALUE>Yes</VALUE>
> 			</IDENTITY>
> 		</SYMPTOM>
> 		<SYMPTOM>
> 			<SYMPTOM_ID>S2</SYMPTOM_ID>
> 			<PARENT_ID>A2</PARENT_ID>
> 			<IDENTITY>
> 				<QUESTION_ID>Q4</QUESTION_ID>
> 				<VALUE>No</VALUE>
> 			</IDENTITY>
> 		</SYMPTOM>
> 	</ATTRIBUTE>
> 
> 	<DIAGNOSIS>
> 		<DIAGNOSIS_ID>D1</DIAGNOSIS_ID>
> 		<NAME>Incorrect alignment motor - speed sensor</NAME>
> 		<CASE>
> 			<SYMPTOM_TEST>
> 				<ATTRIBUTE_ID>A1</ATTRIBUTE_ID>
> 				<SYMPTOM_ID>S7</SYMPTOM_ID>
> 				<WEIGHT>0.5</WEIGHT>
> 			</SYMPTOM_TEST>
> 			<SYMPTOM_TEST>
> 				<ATTRIBUTE_ID>A2</ATTRIBUTE_ID>
> 				<SYMPTOM_ID>S1</SYMPTOM_ID>
> 			</SYMPTOM_TEST>
> 		</CASE>
> 	</DIAGNOSIS>
> 	<DIAGNOSIS>
> 		<DIAGNOSIS_ID>D2</DIAGNOSIS_ID>
> 		<NAME>Incorrect alignment motor - gearbox</NAME>
> 		<CASE>
> 			<SYMPTOM_TEST>
> 				<ATTRIBUTE_ID>A1</ATTRIBUTE_ID>
> 				<SYMPTOM_ID>S7</SYMPTOM_ID>
> 				<WEIGHT>0.5</WEIGHT>
> 			</SYMPTOM_TEST>
> 			<SYMPTOM_TEST>
> 				<ATTRIBUTE_ID>A2</ATTRIBUTE_ID>
> 				<SYMPTOM_ID>S2</SYMPTOM_ID>
> 			</SYMPTOM_TEST>
> 		</CASE>
> 	</DIAGNOSIS>
> </KB>
> 
> -------------------------------------------------------------------------
> 
> 
> 
> 
> 

-- Sjoerd Mullender <sjoerd.mullender@oratrix.com>



From guido@cnri.reston.va.us  Mon Jul 19 16:32:27 1999
From: guido@cnri.reston.va.us (guido@cnri.reston.va.us)
Date: Mon, 19 Jul 1999 11:32:27 -0400 (EDT)
Subject: [Python-bugs-list] [Automatic response] Re: Re: testing again (PR#19)
Message-ID: <199907191532.LAA08760@python.org>

Hi there,

This is an automatic response.  You will get at most one of these per
week.

I'm going to be out of the office until July 26.  I will read my email
daily, but I will be slow in responding to or acting on anything
that's not urgent.

For problems with the Python website, write to webmaster@python.org.

If you sent me a Python or audio question, see my help resources
webpage at http://www.python.org/~guido/help.html; if your question is
answered through those resources, don't expect an answer.

If you want to learn to hack, send mail to tutor@python.org.

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



From skip@mojam.com (Skip Montanaro)  Tue Jul 20 17:29:24 1999
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Tue, 20 Jul 1999 11:29:24 -0500 (CDT)
Subject: [Python-bugs-list] compiling long strings crashes (PR#32)
In-Reply-To: <15646156@toto.iv>
Message-ID: <14228.41616.146012.68303@8.chicago-33-34rs.il.dial-access.att.net>

    Ricardo> Running python with this file crashes with the message:
    Ricardo> SystemError: com_addbyte: byte out of range

    Ricardo> We are having this kind of error when compiling big files.
    Ricardo> With other kind of strings the file can be of 1Mb more or less
    Ricardo> to make it crash.

Ricardo,

This is a known limitation of the Python byte code format, which is unlikely
to get lifted before the Python 2.x release (which is far enough off you
shouldn't wait for it to cure this problem).  Offsets are only 16 bits long,
so the largest a .pyc file can be is 64kbytes.  You'll have to modify your
program to either split the files into multiple pieces or initialize the
strings by reading them from a non-bytecode file.that contains the raw
string data, e.g., in bigstring.py you could have:
    
    bigstring = open("bigstring.txt", "rb").read()

Skip Montanaro	| http://www.mojam.com/
skip@mojam.com  | http://www.musi-cal.com/~skip/
847-475-3758


From laik@cs.stanford.edu  Tue Jul 20 19:00:13 1999
From: laik@cs.stanford.edu (laik@cs.stanford.edu)
Date: Tue, 20 Jul 1999 14:00:13 -0400 (EDT)
Subject: [Python-bugs-list] closing a popen file descriptor (PR#33)
Message-ID: <199907201800.OAA10439@python.org>

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.




From laik@cs.stanford.edu  Tue Jul 20 19:00:48 1999
From: laik@cs.stanford.edu (laik@cs.stanford.edu)
Date: Tue, 20 Jul 1999 14:00:48 -0400 (EDT)
Subject: [Python-bugs-list] closing a popen file descriptor (PR#34)
Message-ID: <199907201800.OAA10484@python.org>

Full_Name: Kevin Lai
Version: 1.5.2
OS: Linux 2.2.10
Submission from: palrel4.hp.com (156.153.255.218)


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.




From ddula@alfomc.net  Thu Jul 22 22:01:07 1999
From: ddula@alfomc.net (ddula@alfomc.net)
Date: Thu, 22 Jul 1999 17:01:07 -0400 (EDT)
Subject: [Python-bugs-list] select with dec-threads core dumps (PR#35)
Message-ID: <199907222101.RAA05381@python.org>

Full_Name: David Dula
Version: 1.5.2
OS: Digital Unix (OSF/1) 4.0E with latest patches
Submission from: (NULL) (192.208.45.218)


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



From guido@CNRI.Reston.VA.US  Thu Jul 22 22:46:26 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Thu, 22 Jul 1999 17:46:26 -0400
Subject: [Python-bugs-list] select with dec-threads core dumps (PR#35)
In-Reply-To: Your message of "Thu, 22 Jul 1999 17:01:07 EDT."
 <199907222101.RAA05381@python.org>
References: <199907222101.RAA05381@python.org>
Message-ID: <199907222146.RAA00504@eric.cnri.reston.va.us>

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/)


From guido@CNRI.Reston.VA.US  Thu Jul 22 22:46:32 1999
From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US)
Date: Thu, 22 Jul 1999 17:46:32 -0400 (EDT)
Subject: [Python-bugs-list] select with dec-threads core dumps (PR#35)
Message-ID: <199907222146.RAA06357@python.org>

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/)



From ddula@alfomc.net  Thu Jul 22 23:43:48 1999
From: ddula@alfomc.net (David Dula)
Date: Thu, 22 Jul 1999 18:43:48 -0400
Subject: [Python-bugs-list] select with dec-threads core dumps (PR#35)
References: <199907222101.RAA05381@python.org> <199907222146.RAA00504@eric.cnri.reston.va.us>
Message-ID: <37979EA4.E6399E35@alfomc.net>

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



From ddula@alfomc.net  Thu Jul 22 23:45:38 1999
From: ddula@alfomc.net (ddula@alfomc.net)
Date: Thu, 22 Jul 1999 18:45:38 -0400 (EDT)
Subject: [Python-bugs-list] select with dec-threads core dumps (PR#35)
Message-ID: <199907222245.SAA07777@python.org>

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




From chenna@embl-heidelberg.de  Fri Jul 23 11:51:45 1999
From: chenna@embl-heidelberg.de (chenna@embl-heidelberg.de)
Date: Fri, 23 Jul 1999 06:51:45 -0400 (EDT)
Subject: [Python-bugs-list] PRIVATE: Bug in re module (PR#36)
Message-ID: <199907231051.GAA26414@python.org>

Full_Name: Chenna Ramu
Version: 1.5.1
OS: OSF1
Submission from: shag.embl-heidelberg.de (192.54.41.195)


Hello I get 

Stack overflow: pid 14731, proc emparse1.py, addr 0x11fdfffd8, pc 0x120068cd8
Segmentation fault

when I run the following. The problem is re module unable to search 
for the pattern that is too large, but this is a requirement for my 
application in biology.  I enclose the source code with this.

Please email me the solution as soon as possible

Thanks
Ramu

___________________________


#!/usr/pub/bin/python1.5
#
#
#
#   (C)  Chenna Ramu, EMBL, Heidelberg, Germany
#
#         parser for biological databases
#


import string
import sys
import re


parserDict = {
    'id' : r'((^ID   [^\n]+\n)+)' ,
    'ac' : r'((^AC   [^\n]+\n)+)' ,
    'dt' : r'((^DT   [^\n]+\n)+)' ,
    'de' : r'((^DE   [^\n]+\n)+)' ,
    'gn' : r'((^GN   [^\n]+\n)+)' ,
    'os' : r'((^OS   [^\n]+\n)+)' ,
    'oc' : r'((^OC   [^\n]+\n)+)' ,

    'ref' : r'(('
              r'(^RN   [^\n]+\n)'
              r'((^RP   [^\n]+\n)+)' 
              r'((^RX   [^\n]+\n)?)' 
              r'((^RA   [^\n]+\n)+)' 
              r'((^RT   [^\n]+\n)*)' 
              r'((^RL   [^\n]+\n)+)' 
            r')+)',

    'cc' : r'((^CC   [^\n]+\n)+)' ,
    'dr' : r'((^DR   [^\n]+\n)+)' ,
    'kw' : r'((^KW   [^\n]+\n)+)' ,
    'ft' : r'((^FT   [^\n]+\n)+)' ,
    'sq' : r'(^SQ  [^\n]+\n)' \
           r'((^    [^\n]+\n)+)'
    }


_hrefLink = {'embl':['<A href=%s>%s</A>','^DR   ([^;]+)']} #should be like this

hrefLink = {'EMBL':"<A href=http://www/wgetz?-e+[%s-id:%s]>%s</a>",
            'MIM':"<A href=http://www/wgetz?-e+[%s-id:%s]>%s</a>"}

em_rep = r'(^DR   )(?P<dbase>[^;]+); (?P<id>[^;]+)'



class embl:    
    def __init__(self,parserDict={}):
        self.parserDict = {}
        self.reDict = {}  #keep the compiled re's

        self.fields = []
        if parserDict:
            self.Init(parserDict)

    def Init(self,parserDict):
        self.parserDict = parserDict
        self.fields = parserDict.keys()
        for j in self.fields:
            setattr(self, j, None)
            self.reDict[j] = re.compile(parserDict[j],re.MULTILINE)

            
    def Parse(self,str):
        if not self.parserDict:
            print "No parser specified"
            return
        for k,v in parserDict.items():
##          tmp = re.compile(v,re.MULTILINE)  # move this to __init__
            tmp = self.reDict[k]
            mat = tmp.search(str)
            if mat:
                setattr(self, k, mat.group() )


    def Field(self,name):
        try:
            return getattr(self,name)
        except AttributeError:
            return None


    def PrintFields(self):
        flds = self.fields
        for j in flds:
            print "==> ",j
            print getattr(self,j)
            

    def ReParse(self,str,retToken,pat):
        """ str:string to parse,  retToken:return token, pat:parser """
        _p = re.compile(pat)
        m = _p.search(str)
        if m:
            return m.group(retToken)
        else:
            return None


def Href(match):
    """  Replaces the hrefs """
    dbase = match.group('dbase')
    id = match.group('id')
    try:
        defi = hrefLink[dbase]
    except KeyError:
        defi = None
    if defi:
        tmp = match.group(1) + dbase + '; '+defi %(dbase,id,id)
    else:
        tmp = match.group(1)+ dbase + '; ' + id 
    return tmp


def test(fileName):
    sys.path.insert(0,'/home/chenna/py')
##  from seqFormat import *

    e = embl(parserDict)
#    f = open('acha_mouse.dat','r')
    f = open(fileName,'r')
    a = f.readlines()
    f.close()
    a = string.join(a,'')
    e.Parse(a)
    e.PrintFields()

    import string
    print ' the fields are ',e.fields
##    seq = string.split(e.sq,';')[-1]
##    s = Seq(seq,'test')
##    print 'check===>',s.seq
##    s.SeqPrint('swiss')

    seqLen = e.ReParse(e.sq[0:50],'seqLen',r'^SQ   [^ ]+ *(?P<seqLen>(\d+))')

    print e.sq
    print "length of the sequence ",seqLen
    print e.ref

    dr = e.dr
    print dr

    p = re.compile(em_rep,re.M)
    dr = p.sub(Href,dr)
    print dr
    print e.Field('id')
    print e.Field('dr')
    print e.Field('mm')
    
    return 

def  test1(dumm=None):
    tmp = ['SQ   Sequence 1041931 BP; 8972 A; 5950 C; 6264 G; 8224 T; 0
other;\n']
    for j in range(1,17365):
        t = '     ' + 'tcagtcagtg ' * 6 + '\n'
        tmp.append(t)
    a = string.join(tmp)
    e = embl(parserDict)
    e.Parse(a)
    e.PrintFields()

if __name__ == '__main__':
    try:
        test1(sys.argv[1])
    except:
        test1()






From skip@mojam.com (Skip Montanaro)  Sat Jul 24 06:21:49 1999
From: skip@mojam.com (Skip Montanaro) (Skip Montanaro)
Date: Sat, 24 Jul 1999 00:21:49 -0500 (CDT)
Subject: [Python-bugs-list] Bug in re module (PR#36)
In-Reply-To: <199907240506.BAA17596@python.org>
References: <199907240506.BAA17596@python.org>
Message-ID: <14233.19468.121418.318625@146.chicago-41-42rs.il.dial-access.att.net>

    Chenna> Hello I get 

    Chenna> Stack overflow: pid 14731, proc emparse1.py, addr 0x11fdfffd8, pc 0x120068cd8
    Chenna> Segmentation fault

    Chenna> when I run the following. The problem is re module unable to
    Chenna> search for the pattern that is too large, but this is a
    Chenna> requirement for my application in biology.  I enclose the source
    Chenna> code with this.

    Chenna> Please email me the solution as soon as possible

Well, you could run it on a different machine, I suppose.  I ran it on my
Linux P-II box and got a ton of lines that looked like

      tcagtcagtg tcagtcagtg tcagtcagtg tcagtcagtg tcagtcagtg tcagtcagtg 

followed by

    ==>  cc
    None
    ==>  dr
    None
    ==>  ft
    None
    ==>  ac
    None

My assumption is that since it didn't segfault, I got the right answer. ;-)

For future reference, when posting code that's giving you problems you
should also post the expected output.  It will help others know if they are
getting expected or unexpected behavior.  Also, distilling the problem down
to a simple example (less than 100 lines) is very helpful.  I just glanced
at your regular expressions and didn't see anything particular heinous about 
them.  What makes you think they are the cause of the segfault?

Skip Montanaro	| http://www.mojam.com/
skip@mojam.com  | http://www.musi-cal.com/~skip/
847-475-3758


From laik@cs.stanford.edu  Tue Jul 27 09:42:10 1999
From: laik@cs.stanford.edu (laik@cs.stanford.edu)
Date: Tue, 27 Jul 1999 04:42:10 -0400 (EDT)
Subject: [Python-bugs-list] Re: closing a popen file descriptor (PR#33)
Message-ID: <199907270842.EAA07846@python.org>

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



From pm@webhosting.com  Wed Jul 28 17:12:09 1999
From: pm@webhosting.com (pm@webhosting.com)
Date: Wed, 28 Jul 1999 12:12:09 -0400 (EDT)
Subject: [Python-bugs-list] tell() returning long (PR#37)
Message-ID: <199907281612.MAA17040@python.org>

Full_Name: Paul Mokbel
Version: 1.5.2
OS: FreeBSD 3.2
Submission from: (NULL) (207.236.70.204)


Here is some snippet of code:
---
>>> import anydbm
>>> file = anydbm.open('temp', 'c')
>>> file['asdsa'] = '21'
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.5/dumbdbm.py", line 112, in __setitem__
    (pos, siz) = self._addval(val)
  File "/usr/local/lib/python1.5/dumbdbm.py", line 87, in _addval
    f.write('\0' * ( npos - pos))
TypeError: can't multiply sequence with non-int
---

There is definitly a problem here... On my machine, and on three similar
machines, I have tried it and on all tell() returns a long int, and not an int
that dumbdbm expected.
It tries to multiply '\0' by a long int..  Here is some more proof:

---
>>> file = open('.login')
>>> file.tell()
0L
>>> file.seek(2,0)
>>> file.tell()
2L
---

Definitly a problem with tell()..

.. I have checked the database for similar bugs and have not seen any of this,
(maybe I am missing something).

Thanks,
Paul M




From guido@CNRI.Reston.VA.US  Wed Jul 28 17:25:27 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Wed, 28 Jul 1999 12:25:27 -0400
Subject: [Python-bugs-list] tell() returning long (PR#37)
In-Reply-To: Your message of "Wed, 28 Jul 1999 12:12:09 EDT."
 <199907281612.MAA17040@python.org>
References: <199907281612.MAA17040@python.org>
Message-ID: <199907281625.MAA09350@eric.cnri.reston.va.us>

This was reported and fixed soon after Python 1.5.2 came out.  The fix
tro dumbdbm.oy is available from the CVS archives at
http://www.python.org/download/cvs.html.  I repeat it here for your
convenience:

Index: dumbdbm.py
===================================================================
RCS file: /projects/cvsroot/python/dist/src/Lib/dumbdbm.py,v
retrieving revision 1.3
retrieving revision 1.4
diff -c -r1.3 -r1.4
*** dumbdbm.py	1996/05/28 22:58:40	1.3
--- dumbdbm.py	1999/04/27 12:21:17	1.4
***************
*** 79,85 ****
  	def _addval(self, val):
  		f = _open(self._datfile, 'rb+')
  		f.seek(0, 2)
! 		pos = f.tell()
  ## Does not work under MW compiler
  ##		pos = ((pos + _BLOCKSIZE - 1) / _BLOCKSIZE) * _BLOCKSIZE
  ##		f.seek(pos)
--- 79,85 ----
  	def _addval(self, val):
  		f = _open(self._datfile, 'rb+')
  		f.seek(0, 2)
! 		pos = int(f.tell())
  ## Does not work under MW compiler
  ##		pos = ((pos + _BLOCKSIZE - 1) / _BLOCKSIZE) * _BLOCKSIZE
  ##		f.seek(pos)


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


From guido@CNRI.Reston.VA.US  Wed Jul 28 17:26:10 1999
From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US)
Date: Wed, 28 Jul 1999 12:26:10 -0400 (EDT)
Subject: [Python-bugs-list] tell() returning long (PR#37)
Message-ID: <199907281626.MAA17376@python.org>

This was reported and fixed soon after Python 1.5.2 came out.  The fix
tro dumbdbm.oy is available from the CVS archives at
http://www.python.org/download/cvs.html.  I repeat it here for your
convenience:

Index: dumbdbm.py
===================================================================
RCS file: /projects/cvsroot/python/dist/src/Lib/dumbdbm.py,v
retrieving revision 1.3
retrieving revision 1.4
diff -c -r1.3 -r1.4
*** dumbdbm.py	1996/05/28 22:58:40	1.3
--- dumbdbm.py	1999/04/27 12:21:17	1.4
***************
*** 79,85 ****
  	def _addval(self, val):
  		f = _open(self._datfile, 'rb+')
  		f.seek(0, 2)
! 		pos = f.tell()
  ## Does not work under MW compiler
  ##		pos = ((pos + _BLOCKSIZE - 1) / _BLOCKSIZE) * _BLOCKSIZE
  ##		f.seek(pos)
--- 79,85 ----
  	def _addval(self, val):
  		f = _open(self._datfile, 'rb+')
  		f.seek(0, 2)
! 		pos = int(f.tell())
  ## Does not work under MW compiler
  ##		pos = ((pos + _BLOCKSIZE - 1) / _BLOCKSIZE) * _BLOCKSIZE
  ##		f.seek(pos)


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



From klm@digicool.com  Wed Jul 28 19:04:43 1999
From: klm@digicool.com (klm@digicool.com)
Date: Wed, 28 Jul 1999 14:04:43 -0400 (EDT)
Subject: [Python-bugs-list] pdb exception reports too severely truncated (PR#38)
Message-ID: <199907281804.OAA19551@python.org>

Full_Name: Ken Manheimer
Version: 1.5.2
OS: Linux
Submission from: digitalcreations59.erols.com (216.164.72.59)


When debugging with pdb exceptions are truncated, and useful information is
often lost (at the most frustrating moments).  The problem is that repr.py
is used, and it has pretty severe default values for truncation, and no way
to override them.  The patch included below rectifies this, by (1) changing
the Repr class to take keyword arguments on its initializer (including a handy
'factor', by which all the default values are simply multiplied), and (2)
changing pdb.py to use it's own Repr instance, with a factor of 5 (picked,
after many seconds of deep lack of thought, out of the air) for breathing room.

Ken


*** repr.py	1999/07/28 17:19:49	1.1
--- repr.py	1999/07/28 17:35:45
***************
*** 2,16 ****
  
  import string
  
  class Repr:
! 	def __init__(self):
! 		self.maxlevel = 6
! 		self.maxtuple = 6
! 		self.maxlist = 6
! 		self.maxdict = 4
! 		self.maxstring = 30
! 		self.maxlong = 40
! 		self.maxother = 20
  	def repr(self, x):
  		return self.repr1(x, self.maxlevel)
  	def repr1(self, x, level):
--- 2,32 ----
  
  import string
  
+ MAXLEVEL = 6
+ MAXTUPLE = 6
+ MAXLIST = 6
+ MAXDICT = 4
+ MAXSTRING = 30
+ MAXLONG = 40
+ MAXOTHER = 20
+ 
  class Repr:
! 	def __init__(self,
!                      factor=1,
!                      maxlevel=MAXLEVEL,
!                      maxtuple=MAXTUPLE,
!                      maxlist=MAXLIST,
!                      maxdict=MAXDICT,
!                      maxstring=MAXSTRING,
!                      maxlong=MAXLONG,
!                      maxother=MAXOTHER):
! 		self.maxlevel = maxlevel * factor
! 		self.maxtuple = maxtuple * factor
! 		self.maxlist = maxlist * factor
! 		self.maxdict = maxdict * factor
! 		self.maxstring = maxstring * factor
! 		self.maxlong = maxlong * factor
! 		self.maxother = maxother * factor
  	def repr(self, x):
  		return self.repr1(x, self.maxlevel)
  	def repr1(self, x, level):


*** pdb.py	1999/07/28 17:37:12	1.1
--- pdb.py	1999/07/28 17:44:51
***************
*** 11,16 ****
--- 11,17 ----
  import bdb
  import repr
  
+ myrepr = repr.Repr(factor=5)
  
  # Interaction prompt line will separate file and call info from code
  # text using value of line_prefix string.  A newline and arrow may
***************
*** 60,66 ****
  		if type(exc_type) == type(''):
  			exc_type_name = exc_type
  		else: exc_type_name = exc_type.__name__
! 		print exc_type_name + ':', repr.repr(exc_value)
  		self.interaction(frame, exc_traceback)
  	
  	# General interaction function
--- 61,67 ----
  		if type(exc_type) == type(''):
  			exc_type_name = exc_type
  		else: exc_type_name = exc_type.__name__
! 		print exc_type_name + ':', myrepr.repr(exc_value)
  		self.interaction(frame, exc_traceback)
  	
  	# General interaction function




From piers@cs.su.oz.au  Fri Jul 30 06:34:26 1999
From: piers@cs.su.oz.au (piers@cs.su.oz.au)
Date: Fri, 30 Jul 1999 01:34:26 -0400 (EDT)
Subject: [Python-bugs-list] rfc822.Message getaddr method bug (PR#39)
Message-ID: <199907300534.BAA06418@python.org>

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




From peter.stoehr@weihenstephan.org  Fri Jul 30 06:36:07 1999
From: peter.stoehr@weihenstephan.org (peter.stoehr@weihenstephan.org)
Date: Fri, 30 Jul 1999 01:36:07 -0400 (EDT)
Subject: [Python-bugs-list] Memory leak in Tkinter.py (PR#40)
Message-ID: <199907300536.BAA06541@python.org>

Full_Name: Peter Stoehr
Version: 1.5.2
OS: Linux
Submission from: ppp09.weihenstephan.org (194.95.200.169)


Hi Python-Fans,

Greg McFarlane (the developer of Pmw) and I found a memory leak in
Tkinter.py of Python 1.5.2.

The tag_bind method of the Canvas class maintainece a dict called
self._tagcommands to store lists of function-ids returned from the _bind
call.
As far as I can see, this information not used by any other method.
Furthermore, the lists grow with every call of tag_bind and the memory
is never released.

After removing the
        if sequence and func and res:
block of the tag_bind method, the memory consumption of the enclosed
test program is constant and no longer growing.

Is it okay to remove the 
        if sequence and func and res:
block or did I miss something?

    Greetings
        Peter

#########################################################################################

import Tkinter

def callback(event):
    pass

def autoUpdate():
    buttonId = canvas.bind('<ButtonPress>', callback)
    canvas.unbind('<ButtonPress>', buttonId)
    root.after(10, autoUpdate)

root = Tkinter.Tk()

canvas = Tkinter.Canvas(root)
idn = canvas.create_rectangle(100,100,200,200, fill='green')
canvas.pack()
autoUpdate()

root.mainloop()

##########################################################################################
-- 
---------------------------------------------------------------------------
   Dr. Peter Stoehr --- Teisenbergweg 6 --- 85435 Erding --- 08122/47232
---------------------------------------------------------------------------
                I'm the terror that flaps in the night



From guido@CNRI.Reston.VA.US  Fri Jul 30 13:23:16 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Fri, 30 Jul 1999 08:23:16 -0400
Subject: [Python-bugs-list] Memory leak in Tkinter.py (PR#40)
In-Reply-To: Your message of "Fri, 30 Jul 1999 01:36:07 EDT."
 <199907300536.BAA06541@python.org>
References: <199907300536.BAA06541@python.org>
Message-ID: <199907301223.IAA12253@eric.cnri.reston.va.us>

Thanks for reporting this.  It turns out that that code was
accidentally checked in.  I've fixed it in the CVS archive (Tkinter.py 
rev. 1.131.)

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


From guido@CNRI.Reston.VA.US  Fri Jul 30 13:23:23 1999
From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US)
Date: Fri, 30 Jul 1999 08:23:23 -0400 (EDT)
Subject: [Python-bugs-list] Memory leak in Tkinter.py (PR#40)
Message-ID: <199907301223.IAA16400@python.org>

Thanks for reporting this.  It turns out that that code was
accidentally checked in.  I've fixed it in the CVS archive (Tkinter.py 
rev. 1.131.)

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



From brian@digicool.com  Fri Jul 30 15:10:50 1999
From: brian@digicool.com (brian@digicool.com)
Date: Fri, 30 Jul 1999 10:10:50 -0400 (EDT)
Subject: [Python-bugs-list] Low FD_SETSIZE limit on NT (PR#41)
Message-ID: <199907301410.KAA18554@python.org>

Full_Name: Brian Lloyd
Version: 1.5.2
OS: NT
Submission from: digitalcreations54.erols.com (216.164.72.54)


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 





From guido@CNRI.Reston.VA.US  Fri Jul 30 18:51:47 1999
From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US)
Date: Fri, 30 Jul 1999 13:51:47 -0400 (EDT)
Subject: [Python-bugs-list] Andrew Dalke: [Fwd: bug in regrtest] (PR#42)
Message-ID: <199907301751.NAA22852@python.org>

------- Forwarded Message

Date:    Thu, 22 Jul 1999 00:59:54 -0600
From:    Andrew Dalke <dalke@bioreason.com>
To:      guido@cnri.reston.va.us
Subject: [Fwd: bug in regrtest]

This is a multi-part message in MIME format.
- --------------2F4E5F83965C914E037EBC47
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

  In the last couple of days there were no replies in comp.lang.python
to this post (meaning no one verified that this is or isn't a bug) so
I'm passing it up to you directly.

						Andrew Dalke
						dalke@bioreason.com
- --------------2F4E5F83965C914E037EBC47
Content-Type: message/rfc822
Content-Disposition: inline

Path: news.uswest.net!not-for-mail
Message-ID: <3793F7B6.482F02A3@bioreason.com>
From: Andrew Dalke <dalke@bioreason.com>
Organization: Bioreason, Inc.
X-Mailer: Mozilla 4.05C-SGI [en] (X11; U; IRIX64 6.5 IP30)
MIME-Version: 1.0
Newsgroups: comp.lang.python
Subject: bug in regrtest
Content-Type: text/plain; charset=us-ascii
Date: Mon, 19 Jul 1999 22:14:46 -0600
NNTP-Posting-Host: 207.108.245.3
X-Trace: news.uswest.net 932444214 207.108.245.3 (Mon, 19 Jul 1999 23:16:54 CDT
)
NNTP-Posting-Date: Mon, 19 Jul 1999 23:16:54 CDT
Xref: news.uswest.net comp.lang.python:9034
Content-Transfer-Encoding: 7bit

Hello,

  We use a modified version of regrtest (Lib/test/regrtest.py)
for internal regression tests.  I just tracked down a bug in
our version which seems to be present in the original one.


  The regression run is compared to golden output from a
known, correct file.  This is done in "runtest" using an instance
of the Compare class, which compares each output data with
the corresponding data from the standard.  If they are different,
an exception is raised.

  The problem comes when the regression run is finished while
golden data is still available.  There is a `close' method in the
Compare class which can check for this sort of error and raise
an exception, but it is never called.

  The relevant code from regrtest.runtest looks like (with some
editing for clarity):

     if generate:
         cfp = open(outputfile, "w")
     elif verbose:
         cfp = sys.stdout
     else:
         cfp = Compare(outputfile)
     try:
        save_stdout = sys.stdout
        try:
            if cfp:
                sys.stdout = cfp
                print test              # Output file starts with test name
            __import__(test, globals(), locals(), [])
        finally:
            sys.stdout = save_stdout
     except ....
        return 0
     else:
        return 1


It looks like the easiest, correct fix is to add the following:

            if cfp and not generate and not cfp:
               cfp.close()

just after the __import__ statement.

I tested against the Python 1.5.1 distribution, which has a
slightly older version of regrtest than 1.5.2, although the latest
CVS version still has the flaw.  There are two tests which now fail
the regression tests, test_re and test_select.

I looked more closely at test_select, since it is smaller than
test_re.  The output/test_select file contains output which
agrees with the output of
  python regrtest.py -v test_select.py

*However*, if you look at test_select.py, the proper output will
only be generated when the verbose flag is set, because of constructs
like:

>                 if verbose:
>                         print 'timeout =', tout

In normal tests, test_select.py should generate no output.  This
can be verified by using -g to generate a new output/test_select
file, which will contain only the test name.

So this output difference was masked by the Compare problem
mentioned above.

Looking at the CVS logs, it has been that way for a long time,
1996/12/11.

						Andrew Dalke
						dalke@bioreason.com

- --------------2F4E5F83965C914E037EBC47--


------- End of Forwarded Message




From guido@CNRI.Reston.VA.US  Fri Jul 30 18:53:02 1999
From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US)
Date: Fri, 30 Jul 1999 13:53:02 -0400 (EDT)
Subject: [Python-bugs-list] Reuben Sumner: Py_REF_COUNT (PR#43)
Message-ID: <199907301753.NAA22922@python.org>

------- 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