From noreply@sourceforge.net  Tue Jan  1 18:47:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 Jan 2002 10:47:16 -0800
Subject: [Patches] [ python-Patches-497098 ] build support for GNU/Hurd
Message-ID: <E16LTwS-0006xF-00@usw-sf-web3.sourceforge.net>

Patches item #497098, was opened at 2001-12-27 10:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497098&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Martin v. Löwis (loewis)
Summary: build support for GNU/Hurd

Initial Comment:
Attached is a patch to build python 2.2 on GNU/Hurd. 
The patch was originally submitted by James A Morrison 
<ja2morri@student.math.uwaterloo.ca> to the Debian 
BTS. If wanted, a patch for 2.1.1 can be provided as 
well.


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-01 10:47

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as
acconfig.h 1.59
configure 1.280;
configure.in 1.289
pyconfig.h.in 1.21
ACKS 1.152
NEWS 1.342
thread_cthread.h 2.16

Once a patch czar is declared for 2.2.1, you might want to
approach him for inclusion of this patch into a 2.2 bugfix
release.

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

Comment By: Tim Peters (tim_one)
Date: 2001-12-29 19:01

Message:
Logged In: YES 
user_id=31435

Python doesn't have "maintenance" releases, it has "bugfix" 
releases.  They're solely to fix bugs.  Because Unixish 
config is such a friggin' mess, there's a long history of 
putatively harmless tweaks for new platforms breaking the 
build on established obscure platforms.  So Martin was just 
giving the Party Line here <wink>.  We'll be delighted to 
incorporate GNU/Hurd support for 2.3, though.

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

Comment By: Matthias Klose (doko)
Date: 2001-12-29 12:30

Message:
Logged In: YES 
user_id=60903

I don't insist. However looking at other projects like gcc,
ports to other platforms are considered for inclusion in
maintainance releases.

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

Comment By: Matthias Klose (doko)
Date: 2001-12-29 12:10

Message:
Logged In: YES 
user_id=60903

I don't insist. However looking at other projects like gcc,
ports to other platforms are considered for inclusion in
maintainance releases.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-28 13:53

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me.

There is zero chance, though, that it will be incorporated
into any 2.1 release, and little chance that it will be
incorporated into 2.2 (unless you insist). The patch looks
harmless, but it does add a new feature, strictly speaking
(support for the Hurd).

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497098&group_id=5470


From noreply@sourceforge.net  Tue Jan  1 19:08:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 Jan 2002 11:08:58 -0800
Subject: [Patches] [ python-Patches-494863 ] file.xreadlines() should raise exception
Message-ID: <E16LUHS-0002MM-00@usw-sf-web1.sourceforge.net>

Patches item #494863, was opened at 2001-12-18 17:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494863&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: file.xreadlines() should raise exception

Initial Comment:
file.xreadlines() should raise a ValueError
when the file is closed

All other file methods raise ValueError except close()

there's another patch that tests this feature
and other file methods

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-01 11:08

Message:
Logged In: YES 
user_id=33168

Checked in as:

Misc/NEWS 1.343 
fileobject.c 2.142

Test is in #494867.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-28 15:42

Message:
Logged In: YES 
user_id=21627

Oops, I meant to assign it to you for check-in, not to close
it. I don't think it is a 2.2.1 candidate, since there is no
serious bug involved.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2001-12-28 15:21

Message:
Logged In: YES 
user_id=33168

Martin, did you mean to close this or assign it to me?
Should this be a 2.2.1 candidate?

I don't think it's too important, other than that
it will change behaviour, although for an obscure
condition.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-28 14:27

Message:
Logged In: YES 
user_id=21627

I'd say the patch is correct. Notice that this is a change
in semantics; please add an entry to Misc/NEWS as well (at
the moment, you get back an xreadlines object on which
calling .next() will raise a ValueError).

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494863&group_id=5470


From noreply@sourceforge.net  Tue Jan  1 19:11:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 Jan 2002 11:11:50 -0800
Subject: [Patches] [ python-Patches-494867 ] updated test_file.py
Message-ID: <E16LUKE-0002Ok-00@usw-sf-web1.sourceforge.net>

Patches item #494867, was opened at 2001-12-18 18:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494867&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: updated test_file.py

Initial Comment:
test that file methods raise ValueError when called
after the file has been closed

also test isatty()

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-01 11:11

Message:
Logged In: YES 
user_id=33168

Checked in as test_file.py 1.6

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-28 14:23

Message:
Logged In: YES 
user_id=21627

The patch looks fine, please apply. 

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494867&group_id=5470


From noreply@sourceforge.net  Tue Jan  1 19:15:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 Jan 2002 11:15:54 -0800
Subject: [Patches] [ python-Patches-498109 ] fileobject truncate support for win32
Message-ID: <E16LUOA-00008f-00@usw-sf-web2.sourceforge.net>

Patches item #498109, was opened at 2001-12-31 08:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=498109&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Wolfgang Strobl (strobl)
Assigned to: Tim Peters (tim_one)
Summary: fileobject truncate support for win32

Initial Comment:
python 2.2 has large file support on Windows, but 
f.truncate() throws an overflow exception when f.tell()
>2G. 

I've changed file_truncate in fileobject.c to using 
SetEndOfFile iff truncate is called without a 
parameter, on Win32.

Tested on W2k (Ger), see the diff to test_largfile.py.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-01 11:15

Message:
Logged In: YES 
user_id=21627

Wouldn't it be better to include a header file instead of
declaring a SetEndOfFile prototype?

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

Comment By: Wolfgang Strobl (strobl)
Date: 2001-12-31 11:56

Message:
Logged In: YES 
user_id=311771

Oops. While removing some obsolete personal notes, I 
accidentally removed the leading comment.   

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-31 08:42

Message:
Logged In: YES 
user_id=6380

For Tim.

I presume the chunk of the diff that removes the leading
comment of the file is a mistake?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=498109&group_id=5470


From noreply@sourceforge.net  Tue Jan  1 20:04:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 Jan 2002 12:04:04 -0800
Subject: [Patches] [ python-Patches-494783 ] diffs for Windows CE - Include/Opcode.h
Message-ID: <E16LV8m-0000iK-00@usw-sf-web2.sourceforge.net>

Patches item #494783, was opened at 2001-12-18 14:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470

Category: Core (C code)
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Brad Clements (bkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: diffs for Windows CE - Include/Opcode.h

Initial Comment:
Attached is a diff for Include/opcode.h to allow 
compilation on MS Wince using EVT 3.0

I have quite a lot of little diffs like this that I 
would like to submit, but before generating and 
posting all of them, I'm sending in just this one to 
be sure I've done this correctly.

My original edits were made against 2.2 alpha 1, so I 
am re-updating my local src tree and redoing all the 
diffs.

I also will have some diffs for Novell NetWare in the 
future.

I realize you may not be able to apply these diffs 
anytime soon, but could you let me know if this meets 
your format requirements soon so I can continue to 
submit diffs.

Thanks


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-01 12:04

Message:
Logged In: YES 
user_id=21627

Thanks for the patch, committed as 
opcode.h 2.38
ceval.c 2.303
compile.c 2.235
ACKS 1.153
NEWS 1.344

Please update your code base; this should solve the problem
of sorting out the additional changes.


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

Comment By: Brad Clements (bkc)
Date: 2001-12-31 06:36

Message:
Logged In: YES 
user_id=4631

The opcode.diff file with the description "Include/Opcode.h 
context diff for Wince" should be deleted. I don't have 
rights to delete it.

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

Comment By: Brad Clements (bkc)
Date: 2001-12-31 06:32

Message:
Logged In: YES 
user_id=4631

Here are three updated diff's for ceval.c, compile.c and 
opcode.h  I have removed the errno-macro components of the 
diff. When I go to submit the errno-diffs, will I need to 
remove the diffs that are included here? (lots of editing!)

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-30 16:16

Message:
Logged In: YES 
user_id=21627

Attaching the opcode changes to this report is fine, also
including any other renaming problems into the same patch is
fine.

I'd appreciate if you could separate any errno patches you
may have, since I'd expect some discussion on these, which
shouldn't stop integration of the renamings. To do this, you
could try to edit the universal or context diffs (whatever
you are more familiar with) by hand. Notice that this works
only as long as you are deleting entire hunks; don't try to
modify a hunk (this will normally mess up the line numbers).

If overlapping changes are in a single hunk, you may include
them in the patch as well - I'll have to unedit them out,
then (by applying the patch to a clean copy, and manually
taking out the unrelated changes).

You may wonder about the insistence on separate patches, but
it is really a prerequisite for understanding the rationale
of a change in the coming years.

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

Comment By: Brad Clements (bkc)
Date: 2001-12-30 08:51

Message:
Logged In: YES 
user_id=4631

I have made the suggested changes to the enum, and the 
necessary changes to compile.c and ceval.c

Should I append those three diffs to this patch entry, or 
create a new entry, one for each of those diffs?

compile.c has some other unrelated changes, and some of 
those changes are dependent on diffs to another include.

IE, rather than #ifdef'ing all references to errno, I know 
that NetWare doesn't have errno either. So I've created 
macros GetErrno(), ClearErrno() and SetErrno(). Hope that's 
going to work out.

Also, lots of modules have statements like : goto finally; 
which Metrowerks and EVT don't like because "finally" is a 
reserved word, even when compiling .c modules. So I've had 
to change all of those as well.

When I get regrtests all working, and recompile my code on 
Win32 and Linux, then I'll post all my diffs.

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

Comment By: Brad Clements (bkc)
Date: 2001-12-30 08:51

Message:
Logged In: YES 
user_id=4631

I have made the suggested changes to the enum, and the 
necessary changes to compile.c and ceval.c

Should I append those three diffs to this patch entry, or 
create a new entry, one for each of those diffs?

compile.c has some other unrelated changes, and some of 
those changes are dependent on diffs to another include.

IE, rather than #ifdef'ing all references to errno, I know 
that NetWare doesn't have errno either. So I've created 
macros GetErrno(), ClearErrno() and SetErrno(). Hope that's 
going to work out.

Also, lots of modules have statements like : goto finally; 
which Metrowerks and EVT don't like because "finally" is a 
reserved word, even when compiling .c modules. So I've had 
to change all of those as well.

When I get regrtests all working, and recompile my code on 
Win32 and Linux, then I'll post all my diffs.

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

Comment By: Brad Clements (bkc)
Date: 2001-12-29 10:14

Message:
Logged In: YES 
user_id=4631

Yes, I will change the enum and all uses of it that I can 
find to use a unique prefix as you suggested.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-28 14:40

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me. I wonder whether Python should
stop using these constant names, though, and replace them
with, say, a PyCmp_ prefix, throughout. If there is a
backwards compatibility concern (which I wouldn't expect),
it should be possible to add #defines to the old names when
there is no conflict.

Would you be willing to rewrite this patch to do so?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-19 08:05

Message:
Logged In: YES 
user_id=6380

Standard cautionary note. Sorry.

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

Comment By: Brad Clements (bkc)
Date: 2001-12-19 07:39

Message:
Logged In: YES 
user_id=4631

I used the win CVS "update" command on the entire source 
tree yesterday. I have not specified a particular tag. Are 
you saying that opcode.h rev 2.37 is not current, or 
is "please use the current cvs" a standard cautionary note?

Sorry to be anal, I want this to be seamless for you so I 
feel I have botched it up already.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-18 19:20

Message:
Logged In: YES 
user_id=6380

That looks like a fine context diff to me.

Please be sure to use the current CVS if you can!

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=494783&group_id=5470


From noreply@sourceforge.net  Tue Jan  1 20:21:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 Jan 2002 12:21:24 -0800
Subject: [Patches] [ python-Patches-430706 ] Persistent connections in BaseHTTPServer
Message-ID: <E16LVPY-00085E-00@usw-sf-web3.sourceforge.net>

Patches item #430706, was opened at 2001-06-06 08:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430706&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Lawrence (lordsutch)
Assigned to: Martin v. Löwis (loewis)
Summary: Persistent connections in BaseHTTPServer

Initial Comment:
This patch provides HTTP/1.1 persistent 
connection support in BaseHTTPServer.py.  It is 
not enabled by default (for backwards 
compatibility) because Content-Length headers 
must be supplied for persistent connections to 
work correctly.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-01 12:21

Message:
Logged In: YES 
user_id=21627

Any chance that an updated patch is forthcoming?

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

Comment By: Chris Lawrence (lordsutch)
Date: 2001-09-21 15:01

Message:
Logged In: YES 
user_id=6757

I've tracked that one down and will have an updated patch in
a day or two... basically it just needs another else
condition to handle the empty readline().  There are also
some issues for subclasses that probably need to be
documented to play nicely with bad clients like wget that
claim to be HTTP 1.0 but do HTTP 1.1 stuff.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-09-18 09:36

Message:
Logged In: YES 
user_id=21627

It still doesn't work right. If I access SimpleHTTPServer
from a Netscape client, I get error messages like

localhost - - [18/Sep/2001 18:32:22] code 400, message Bad
request syntax ('')
localhost - - [18/Sep/2001 18:32:22] "" 400 -

These are caused because the client closes the connection
after the first request (likely, after it finds out that the
document it got contains no references to the same server
anymore). However, the server continues to invoke
handle_one_request, which reads the empty line and fails to
recognize that the client has closed the connection.

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

Comment By: Chris Lawrence (lordsutch)
Date: 2001-09-15 01:15

Message:
Logged In: YES 
user_id=6757

I reworked the patch a bit to ensure HTTP 1.1 mode is only 
used if the handler class is in HTTP 1.1 mode, and 
modified the test() functions in the server classes to add 
a "protocol" option.  I also modified SimpleHTTPServer to 
send Content-Length headers for the implemented classes.


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

Comment By: Martin v. Löwis (loewis)
Date: 2001-09-04 04:40

Message:
Logged In: YES 
user_id=21627

The patch in its current form seems to be broken. To see the
problem, please run SimpleHTTPServer on some directory, then
access it with a HTTP/1.1 client (e.g. Netscape 4.7).

The server will use the protocol version HTTP/1.0, but the
client will initially send 1.1, and send a Connection:
Keep-alive header. As a result, self.close_connection is set
to 0, despite using HTTP/1.0. In turn, the HTTP server won't
send a content length, and won't close the connection
either. Netscape waits forever from some completion which
never occurs, since the server waits for the next request on
the same connection.

It might be useful to enhance the SimpleHTTPServer test()
function to optionally operate in HTTP/1.1 mode (including
sending a proper ContentLength). Doing the same for the CGI
HTTP server is probably less useful.


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

Comment By: Chris Lawrence (lordsutch)
Date: 2001-08-29 20:21

Message:
Logged In: YES 
user_id=6757

I have updated the patch against current CVS and have added
documentation.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-08-08 13:43

Message:
Logged In: YES 
user_id=21627

I haven't studied the patch in detail, yet, but I have a 
few comments on the style:

- there is no need to quote all authors of the RFC. Also,
  the reference to long-ago expired HTTP draft should go;
  just replace it with a single reference to the RFC
  number (giving an URL for the RFC might be convenient)
- Where is the documentation? A patch to 
Doc/lib/libbasehttp.tex would be appreciated. If you don't 
speak TeX, don't worry: Just write plain text, we'll do 
the mark-up.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430706&group_id=5470


From noreply@sourceforge.net  Tue Jan  1 20:27:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 Jan 2002 12:27:53 -0800
Subject: [Patches] [ python-Patches-452232 ] timestamp function for time module
Message-ID: <E16LVVp-0003M4-00@usw-sf-web1.sourceforge.net>

Patches item #452232, was opened at 2001-08-17 14:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452232&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gareth Harris (garethharris)
Assigned to: Nobody/Anonymous (nobody)
Summary: timestamp function for time module

Initial Comment:
Timestamp creates timestamp strings 
in ISO or ODBC format in UTC or local timezones. 
It can also add microseconds where needed. 
Timestamps are often needed 
outside database or XML activities, 
so its proposed location is the time module.

timestamp(secs=None,fmt='ISO',TZ=None,fracsec=None):
    '''Make ISO or ODBC timestamp from [current] time.
    Parameters:
    secs= float seconds, else default = time()
    fmt = 'ISO' use ISO 8601 standard format = 
            "YYYY-MM-DDTHH:MM:SS.mmmmmmZ"       Zulu or
            "YYYY-MM-DDTHH:MM:SS.mmmmmm-hh:mm"  local
      else  "YYYY-MM-DD HH:MM:SS.mmmmmm"        ODBC
    TZ      = None=GMT/UTC/Zulu, else local time zone
    fracsec = None, else add microseconds to string
    '''

Any improvement or standardization is welcome.

Gareth Harris
gharris@nrao.edu
2001-08-17T21:36:00Z


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-01 12:27

Message:
Logged In: YES 
user_id=21627

Gareth,

Can you please propose a strategy to advance this patch or
withdraw it? If there is no action, I propose to close it by
Feb 1, 2002.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-06 06:57

Message:
Logged In: YES 
user_id=3066

Another possible alternate home for this would be the Python
Snippet repository on SourceForge:

http://sourceforge.net/snippet/browse.php?by=lang&lang=6

I'm not suggesting that this doesn't belong in the standard
library, however.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-09-19 10:46

Message:
Logged In: YES 
user_id=21627

Nice patch. If you want to see this included, you should 
complete it: Decide on location of the function, provide 
documentation and test cases. As the location, it may be 
that the calendar module could provide a home, but you may 
ask in the newsgroup.

If you merely wanted to publish this code snippet, I 
suggest that you find a better home than the Python patch 
database, e.g. the Cookbook:

http://aspn.activestate.com/ASPN/Cookbook/Python

There are a number of other places that collect Python 
snippets; this is just one option.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452232&group_id=5470


From noreply@sourceforge.net  Wed Jan  2 07:49:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 Jan 2002 23:49:40 -0800
Subject: [Patches] [ python-Patches-498109 ] fileobject truncate support for win32
Message-ID: <E16Lg9c-0000C7-00@usw-sf-web2.sourceforge.net>

Patches item #498109, was opened at 2001-12-31 08:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=498109&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Wolfgang Strobl (strobl)
Assigned to: Tim Peters (tim_one)
Summary: fileobject truncate support for win32

Initial Comment:
python 2.2 has large file support on Windows, but 
f.truncate() throws an overflow exception when f.tell()
>2G. 

I've changed file_truncate in fileobject.c to using 
SetEndOfFile iff truncate is called without a 
parameter, on Win32.

Tested on W2k (Ger), see the diff to test_largfile.py.

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

>Comment By: Wolfgang Strobl (strobl)
Date: 2002-01-01 23:49

Message:
Logged In: YES 
user_id=311771

Right. See the attached diff.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-01 11:15

Message:
Logged In: YES 
user_id=21627

Wouldn't it be better to include a header file instead of
declaring a SetEndOfFile prototype?

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

Comment By: Wolfgang Strobl (strobl)
Date: 2001-12-31 11:56

Message:
Logged In: YES 
user_id=311771

Oops. While removing some obsolete personal notes, I 
accidentally removed the leading comment.   

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-31 08:42

Message:
Logged In: YES 
user_id=6380

For Tim.

I presume the chunk of the diff that removes the leading
comment of the file is a mistake?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=498109&group_id=5470


From noreply@sourceforge.net  Wed Jan  2 16:41:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 02 Jan 2002 08:41:41 -0800
Subject: [Patches] [ python-Patches-452232 ] timestamp function for time module
Message-ID: <E16LoST-0005Zl-00@usw-sf-web3.sourceforge.net>

Patches item #452232, was opened at 2001-08-17 14:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452232&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gareth Harris (garethharris)
Assigned to: Nobody/Anonymous (nobody)
Summary: timestamp function for time module

Initial Comment:
Timestamp creates timestamp strings 
in ISO or ODBC format in UTC or local timezones. 
It can also add microseconds where needed. 
Timestamps are often needed 
outside database or XML activities, 
so its proposed location is the time module.

timestamp(secs=None,fmt='ISO',TZ=None,fracsec=None):
    '''Make ISO or ODBC timestamp from [current] time.
    Parameters:
    secs= float seconds, else default = time()
    fmt = 'ISO' use ISO 8601 standard format = 
            "YYYY-MM-DDTHH:MM:SS.mmmmmmZ"       Zulu or
            "YYYY-MM-DDTHH:MM:SS.mmmmmm-hh:mm"  local
      else  "YYYY-MM-DD HH:MM:SS.mmmmmm"        ODBC
    TZ      = None=GMT/UTC/Zulu, else local time zone
    fracsec = None, else add microseconds to string
    '''

Any improvement or standardization is welcome.

Gareth Harris
gharris@nrao.edu
2001-08-17T21:36:00Z


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

>Comment By: Gareth Harris (garethharris)
Date: 2002-01-02 08:41

Message:
Logged In: YES 
user_id=300900

Back from travel, other projects etc. [2001.01.02]
Thanks for comments thus far.
Maybe I will finally meet some of you in Feb.
---
I proposed to put this in TIME module 
UNLESS someone has an idea for a better location.
Who takes care of that module?
Shall I provide: doc?, test suite?
Is a companion decode function needed?
OTHERWISE I will put it in sourceforge/activestate?
Which is preferred?

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-01 12:27

Message:
Logged In: YES 
user_id=21627

Gareth,

Can you please propose a strategy to advance this patch or
withdraw it? If there is no action, I propose to close it by
Feb 1, 2002.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-06 06:57

Message:
Logged In: YES 
user_id=3066

Another possible alternate home for this would be the Python
Snippet repository on SourceForge:

http://sourceforge.net/snippet/browse.php?by=lang&lang=6

I'm not suggesting that this doesn't belong in the standard
library, however.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-09-19 10:46

Message:
Logged In: YES 
user_id=21627

Nice patch. If you want to see this included, you should 
complete it: Decide on location of the function, provide 
documentation and test cases. As the location, it may be 
that the calendar module could provide a home, but you may 
ask in the newsgroup.

If you merely wanted to publish this code snippet, I 
suggest that you find a better home than the Python patch 
database, e.g. the Cookbook:

http://aspn.activestate.com/ASPN/Cookbook/Python

There are a number of other places that collect Python 
snippets; this is just one option.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=452232&group_id=5470


From cortson@lawyer.com  Wed Jan  2 20:15:11 2002
From: cortson@lawyer.com (cortson@lawyer.com)
Date: Wed, 2 Jan 2002 15:15:11 -0500
Subject: [Patches] (no subject)
Message-ID: <E16Lrlk-00026k-00@mail.python.org>

Bruce Crampton's Sports Performance digital swing capture and analysis system is now available for booking and 
licensing.  Get the highest tech system available anywhere.  Contact PGA Tour Player Manager Mike Cortson at 
cortson@lawyer.com for details or visit our website at www.bc_sportsperformance.com


From noreply@sourceforge.net  Wed Jan  2 23:19:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 02 Jan 2002 15:19:46 -0800
Subject: [Patches] [ python-Patches-450265 ] OS/2 + EMX port - PC directory files
Message-ID: <E16Lufi-0006BG-00@usw-sf-web1.sourceforge.net>

Patches item #450265, was opened at 2001-08-12 04:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450265&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: OS/2 + EMX port - PC directory files

Initial Comment:
The attached patch contains all the changes to the PC directory in the source tree between Python 2.1.1 and the 
010812 release of the OS/2+EMX port.  This comprises changes to PC/getpathp.c and a new subdirectory, 
PC/os2emx, which contains the Makefile, config.[ch], dlfcn.[ch], dllentry.c, python DLL .DEF file and a copy of the 
port's README.os2emx.

At the moment, building dynamic modules is still handled by the supplied Makefile, rather than a DistUtils setup.py 
script.

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

>Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-01-02 15:19

Message:
Logged In: YES 
user_id=250749

I am preparing updated patches against CVS for this and the 
other EMX related patches, and will upload in the next few 
days.

Specifically for this patch, the updated version will just 
add a PC/os2emx subdirectory, and touch no other files in 
the PC directory (as the patch currently attached does).

Would it be better to reject the 4 currently outstanding 
patches and submit new ones for this, or just update the 
current ones?

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-28 14:47

Message:
Logged In: YES 
user_id=21627

Andrew, are you still interested in updating this patch?
Otherwise, I recommend to reject it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-10-01 15:41

Message:
Logged In: YES 
user_id=21627

What kind of action would you like to see on this code? In 
the areas where it changes existing code, there are some 
questionable chunks, which I would not like to see in 
Python:
- removal of comments
- change of control logic without giving a rationale. E.g. 
there was an explicit comment
/* If we have no values, we dont need a ';' */
Your patch changes this to give a ; in all cases. Why?
Why is the addition of a terminating null in wprogpath 
removed?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-12 07:45

Message:
Logged In: YES 
user_id=6380

Andrew, your patch attachment didn't work. Please try again,
making sure you check the "file upload checkbox".

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450265&group_id=5470


From noreply@sourceforge.net  Wed Jan  2 23:20:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 02 Jan 2002 15:20:45 -0800
Subject: [Patches] [ python-Patches-450265 ] OS/2 + EMX port - PC directory files
Message-ID: <E16Lugf-0003lu-00@usw-sf-web2.sourceforge.net>

Patches item #450265, was opened at 2001-08-12 04:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450265&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: OS/2 + EMX port - PC directory files

Initial Comment:
The attached patch contains all the changes to the PC directory in the source tree between Python 2.1.1 and the 
010812 release of the OS/2+EMX port.  This comprises changes to PC/getpathp.c and a new subdirectory, 
PC/os2emx, which contains the Makefile, config.[ch], dlfcn.[ch], dllentry.c, python DLL .DEF file and a copy of the 
port's README.os2emx.

At the moment, building dynamic modules is still handled by the supplied Makefile, rather than a DistUtils setup.py 
script.

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

>Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-01-02 15:20

Message:
Logged In: YES 
user_id=250749

I am preparing updated patches against CVS for this and the 
other EMX related patches, and will upload in the next few 
days.

Specifically for this patch, the updated version will just 
add a PC/os2emx subdirectory, and touch no other files in 
the PC directory (as the patch currently attached does).

Would it be better to reject the 4 currently outstanding 
patches and submit new ones for this, or just update the 
current ones?

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-01-02 15:19

Message:
Logged In: YES 
user_id=250749

I am preparing updated patches against CVS for this and the 
other EMX related patches, and will upload in the next few 
days.

Specifically for this patch, the updated version will just 
add a PC/os2emx subdirectory, and touch no other files in 
the PC directory (as the patch currently attached does).

Would it be better to reject the 4 currently outstanding 
patches and submit new ones for this, or just update the 
current ones?

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-28 14:47

Message:
Logged In: YES 
user_id=21627

Andrew, are you still interested in updating this patch?
Otherwise, I recommend to reject it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-10-01 15:41

Message:
Logged In: YES 
user_id=21627

What kind of action would you like to see on this code? In 
the areas where it changes existing code, there are some 
questionable chunks, which I would not like to see in 
Python:
- removal of comments
- change of control logic without giving a rationale. E.g. 
there was an explicit comment
/* If we have no values, we dont need a ';' */
Your patch changes this to give a ; in all cases. Why?
Why is the addition of a terminating null in wprogpath 
removed?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-12 07:45

Message:
Logged In: YES 
user_id=6380

Andrew, your patch attachment didn't work. Please try again,
making sure you check the "file upload checkbox".

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450265&group_id=5470


From noreply@sourceforge.net  Thu Jan  3 10:45:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 03 Jan 2002 02:45:24 -0800
Subject: [Patches] [ python-Patches-450265 ] OS/2 + EMX port - PC directory files
Message-ID: <E16M5NE-0001ti-00@usw-sf-web3.sourceforge.net>

Patches item #450265, was opened at 2001-08-12 04:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450265&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: OS/2 + EMX port - PC directory files

Initial Comment:
The attached patch contains all the changes to the PC directory in the source tree between Python 2.1.1 and the 
010812 release of the OS/2+EMX port.  This comprises changes to PC/getpathp.c and a new subdirectory, 
PC/os2emx, which contains the Makefile, config.[ch], dlfcn.[ch], dllentry.c, python DLL .DEF file and a copy of the 
port's README.os2emx.

At the moment, building dynamic modules is still handled by the supplied Makefile, rather than a DistUtils setup.py 
script.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-03 02:45

Message:
Logged In: YES 
user_id=21627

If you continue to organize the patches in the same way,
just updating the existing report should be fine. If it is
more convenient for you, creating a new report is fine, as well.

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-01-02 15:20

Message:
Logged In: YES 
user_id=250749

I am preparing updated patches against CVS for this and the 
other EMX related patches, and will upload in the next few 
days.

Specifically for this patch, the updated version will just 
add a PC/os2emx subdirectory, and touch no other files in 
the PC directory (as the patch currently attached does).

Would it be better to reject the 4 currently outstanding 
patches and submit new ones for this, or just update the 
current ones?

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-01-02 15:19

Message:
Logged In: YES 
user_id=250749

I am preparing updated patches against CVS for this and the 
other EMX related patches, and will upload in the next few 
days.

Specifically for this patch, the updated version will just 
add a PC/os2emx subdirectory, and touch no other files in 
the PC directory (as the patch currently attached does).

Would it be better to reject the 4 currently outstanding 
patches and submit new ones for this, or just update the 
current ones?

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-28 14:47

Message:
Logged In: YES 
user_id=21627

Andrew, are you still interested in updating this patch?
Otherwise, I recommend to reject it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-10-01 15:41

Message:
Logged In: YES 
user_id=21627

What kind of action would you like to see on this code? In 
the areas where it changes existing code, there are some 
questionable chunks, which I would not like to see in 
Python:
- removal of comments
- change of control logic without giving a rationale. E.g. 
there was an explicit comment
/* If we have no values, we dont need a ';' */
Your patch changes this to give a ; in all cases. Why?
Why is the addition of a terminating null in wprogpath 
removed?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-12 07:45

Message:
Logged In: YES 
user_id=6380

Andrew, your patch attachment didn't work. Please try again,
making sure you check the "file upload checkbox".

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450265&group_id=5470


From noreply@sourceforge.net  Thu Jan  3 18:33:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 03 Jan 2002 10:33:08 -0800
Subject: [Patches] [ python-Patches-499062 ] Minor typo in test_generators.py
Message-ID: <E16MCfs-00080O-00@usw-sf-web3.sourceforge.net>

Patches item #499062, was opened at 2002-01-03 10:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499062&group_id=5470

Category: Demos and tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Uche Ogbuji (uche)
Assigned to: Nobody/Anonymous (nobody)
Summary: Minor typo in test_generators.py

Initial Comment:
This one caused me a bit of confusion.  Traditionally
"leaves" refer to tree nodes with no children.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499062&group_id=5470


From noreply@sourceforge.net  Fri Jan  4 00:18:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 03 Jan 2002 16:18:11 -0800
Subject: [Patches] [ python-Patches-499062 ] Minor typo in test_generators.py
Message-ID: <E16MI3n-0004Ce-00@usw-sf-web3.sourceforge.net>

Patches item #499062, was opened at 2002-01-03 10:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499062&group_id=5470

>Category: Tests
Group: None
Status: Open
Resolution: None
>Priority: 4
Submitted By: Uche Ogbuji (uche)
>Assigned to: Tim Peters (tim_one)
Summary: Minor typo in test_generators.py

Initial Comment:
This one caused me a bit of confusion.  Traditionally
"leaves" refer to tree nodes with no children.

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

>Comment By: Tim Peters (tim_one)
Date: 2002-01-03 16:18

Message:
Logged In: YES 
user_id=31435

Assigned to me; added a "Tests" category and recategorized 
accordingly.

Uche, if you tried to upload a patch, it didn't work (did 
you remember to check the upload box)?  What is that you 
want to see changed?  s/leaves/labels/?  Note that the 
example in the docstring test is lifted directly out of PEP 
255, so tell me what would shut you up <wink> and I'll make 
the change in both places.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499062&group_id=5470


From noreply@sourceforge.net  Fri Jan  4 00:23:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 03 Jan 2002 16:23:31 -0800
Subject: [Patches] [ python-Patches-499062 ] Minor typo in test_generators.py
Message-ID: <E16MI8x-0004Gd-00@usw-sf-web3.sourceforge.net>

Patches item #499062, was opened at 2002-01-03 10:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499062&group_id=5470

Category: Tests
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Uche Ogbuji (uche)
Assigned to: Tim Peters (tim_one)
Summary: Minor typo in test_generators.py

Initial Comment:
This one caused me a bit of confusion.  Traditionally
"leaves" refer to tree nodes with no children.

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

>Comment By: Uche Ogbuji (uche)
Date: 2002-01-03 16:23

Message:
Logged In: YES 
user_id=38966

It's s/leaves/nodes/.  Maybe I've been working with DOM too
much.  At any rate, I have always thought of leaf nodes as
only those with no children.

It doesn't look as if anything from my patch made it
through: neither the comment nor the patch.  Sometimes I
hate SF.

I'll try again, though it hardly seems necessary...


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

Comment By: Tim Peters (tim_one)
Date: 2002-01-03 16:18

Message:
Logged In: YES 
user_id=31435

Assigned to me; added a "Tests" category and recategorized 
accordingly.

Uche, if you tried to upload a patch, it didn't work (did 
you remember to check the upload box)?  What is that you 
want to see changed?  s/leaves/labels/?  Note that the 
example in the docstring test is lifted directly out of PEP 
255, so tell me what would shut you up <wink> and I'll make 
the change in both places.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499062&group_id=5470


From noreply@sourceforge.net  Fri Jan  4 00:35:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 03 Jan 2002 16:35:39 -0800
Subject: [Patches] [ python-Patches-499062 ] Minor typo in test_generators.py
Message-ID: <E16MIKh-0008Gd-00@usw-sf-web1.sourceforge.net>

Patches item #499062, was opened at 2002-01-03 10:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499062&group_id=5470

Category: Tests
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Uche Ogbuji (uche)
Assigned to: Tim Peters (tim_one)
Summary: Minor typo in test_generators.py

Initial Comment:
This one caused me a bit of confusion.  Traditionally
"leaves" refer to tree nodes with no children.

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

>Comment By: Tim Peters (tim_one)
Date: 2002-01-03 16:35

Message:
Logged In: YES 
user_id=31435

Yes, I think "leaf" == "no kids" is universally accepted.

I don't like changing it to plain "nodes", though, because 
the example code does not generate the nodes, it generates 
only the node labels -- someone confused by the misuse 
of "leaves" here is also likely to be confused by the 
misuse of "nodes" -- and I'm going to reduce the priority 
of this patch every time you argue back <wink>.

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

Comment By: Uche Ogbuji (uche)
Date: 2002-01-03 16:23

Message:
Logged In: YES 
user_id=38966

It's s/leaves/nodes/.  Maybe I've been working with DOM too
much.  At any rate, I have always thought of leaf nodes as
only those with no children.

It doesn't look as if anything from my patch made it
through: neither the comment nor the patch.  Sometimes I
hate SF.

I'll try again, though it hardly seems necessary...


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

Comment By: Tim Peters (tim_one)
Date: 2002-01-03 16:18

Message:
Logged In: YES 
user_id=31435

Assigned to me; added a "Tests" category and recategorized 
accordingly.

Uche, if you tried to upload a patch, it didn't work (did 
you remember to check the upload box)?  What is that you 
want to see changed?  s/leaves/labels/?  Note that the 
example in the docstring test is lifted directly out of PEP 
255, so tell me what would shut you up <wink> and I'll make 
the change in both places.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499062&group_id=5470


From biz@6x6.net  Thu Jan  3 18:27:40 2002
From: biz@6x6.net (biz@6x6.net)
Date: 03 Jan 2002 20:27:40 +0200
Subject: [Patches] ATTENTION! Well-Paid Job in the Internet!
Message-ID: <E16MKKq-00029g-00@mail.python.org>

<!-- saved from url=(0022)http://internet.e-mail -->
<html><head><title>ATTENTION! The Well-Paid Job in the Internet!</title><meta http-equiv="Content-Type" content="text/html; charset=windows-1251"></head><body bgcolor="#FFFFFF"><center><a name="e"><table cellpadding="0" cellspacing="0" border="0" width="660"><tr><td><center><font face="verdana" size="+1"><b>We wish You a pleasant and successful day!</center><div align="right"><font face="verdana" size="+2"><a href="#r"><b>In Russian</a><tr bgcolor="#000066"><td>&nbsp;</table><table width="660" cellpadding="0" cellspacing="0" border="0"><tr><td><table width="518" border="0" cellspacing="0" cellpadding="0"><tr><td><table width="500" cellpadding="0" cellspacing="0" border="0"><tr><td><font face="verdana" size="+1"><center><b>Make money without leaving Your computer!</b></center><p><div align="justify"><br><font size="2">If You show some interest and patience and understand as IT works, You can earn up to <b>$100,000</b> and <b>more!!!</b> During the following 120 days - it depends only on You. DOES  IT SEEMS TO BE IMPOSSIBLE?? Read this document to be sure there is no catch or deceit. If You are completely lazy - we beg Your pardon for the assumption!!!, then this  is not for You!!! You'd better do something like surfing either clicking on banners or not doing anything at all.<p>!!! If the offer hasn't interested You, we bring our apologies and it is not necessary to get angry - "Spam" has its expenses, just as radio and TV, but do not forget, that the first billionaire of the USA, Dale Carnegie said:<p>"I'll better earn 1% as a result of the efforts of 100 men, than 100% as a result of my own efforts."<p><font size="3" color="#000066"><center><br><b>RISE ON THE WAY TO THE FINANCIAL INDEPENDENCE AND FREEDOM!!!</table></table><td width="142" bgcolor="#000066"><table width="142" cellpadding="0" cellspacing="0" border="0"><tr><td bgcolor="#000066"><center><table width="125" cellpadding="0" cellspacing="0" border="0"><tr><td bgcolor="#FFFFCC"><font face="verdana" size="2"><center>Welcome to the <b><font color=red>6<font color=green>X<font color=blue>6</font></font></font>!<tr><td>&nbsp;<tr><td bgcolor="#FFFFCC"><center><table width="115" cellpadding="0" cellspacing="0" border="0"><tr><td><font face="verdana" size="1">It is difficult to believe but nevertheless it is like that! People get richer and richer! Some of them can't recover from the shock which had come together with a heap of crust banknotes even some months later. While the others deliberate and doubt, people that believed in Business System 6X6 bathe now in money!...</table><tr><td>&nbsp;<tr><td bgcolor="#FFFFCC"><tr><td bgcolor="#FFFFCC"><center><table width="115" cellpadding="0" cellspacing="0" border="0"><tr><td><font face="verdana" size="1">In view of prompt rates of development of the Internet and electronic commerce the number of users of the "World Wide Web" grows with the great speed. There are more than 15,000 new people who join the Internet daily...</table></table></table><tr><td colspan="2"><table cellpadding="0" cellspacing="0" border="0" width="660"><tr bgcolor="#000066"><td>&nbsp;</table><br><center><font face="verdana" size="1" color="#555555">Copyright © 2001 6x6 MLM Corporation. All rights reserved.</font><table width="660" cellpadding="0" cellspacing="0" border="0"><tr><td height="60"><tr><td><font face="verdana" size=+1><center><b>Ladies and Gentlemen!<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td><font face=verdana size=+1><center><p><br><b>PLEASE READ THOUGHTFULLY AND ATTENTIVELY, TRYING NOT TO DISTRACT YOUR ATTENTION WITH EXTERNAL NOISES AND IRRITANTS, AND YOU'LL UNDERSTAND WHAT WILL MAKE YOU RATHER RICH AND FREE PEOPLE!!!<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td bgcolor=#ffffcc><p align=justify><br><font face=verdana size=2 color=#000066>It is difficult to believe but nevertheless it is like that! People get richer and richer! Some of them can't recover from the shock which had come together with a heap of crust banknotes even some months later. While the others deliberate and doubt, people that believed in Business System 6X6 bathe now in money! In a literal sense! Have You ever seen how the heap of the $5 bills under which the adult person entirelly finds room looks like?! It is 100 thousand dollars!!! Can You imagine how the heap of $1,000,000 which is earned by each third participant of the superprogram 6X6 looks like?! And what is the feeling when You, not getting troubled with work, start to receive envelopes with six dollars already on the second week and further the profit is much more! And eventually some months later You don't know how to get rid of the money! You even get a bit scary of this avalanches of the money!!!<br>&nbsp;<tr><td height=40><tr><td><font face=verdana size=2 color=#000066><center><b>ALL THAT IT WILL NECESSARY TO DO - TO SEND THE ADVERTISING LETTERS VIA E-MAIL AND FROM TIME TO TIME TO CHECK YOUR MAILBOX OR TO GO TO THE BANK! YOU SHOULDN'T EVEN STRAIN THE BRAIN - THE SUPER COMPUTER BUSINESS SYSTEM 6X6 WILL MAKE EVERYTHING ITSELF!!!<p><b>SINCE THE MOMENT YOU ENTER THIS BUSINESS YOUR PROFIT SNOWBALLS AND BY THE END OF 4TH MONTH YOU'LL GET AS MINIMUM $100,000. BUT IF YOU DON'T STOP THE RESULTS WILL BE ASTRONOMICAL - $1,000,000 FOR 1 YEAR!!!!<tr><td height=40><tr><td bgcolor=#ffffcc><p align=justify><br><font face=verdana size=2 color=#000066>"What is the secret of such dizzy success?" - You ask. This is because there is a new formula in the business system which provides all participants with 100%-s' success due to the account of such special factors which the human brain is simply not capable of grasping. Therefore this excellent program works! And it works brilliantly! This is a prodigy-system in which success is madly infectious! Hurry up to achieve the success too!!!<br>&nbsp;<tr><td height=40><tr><td><font face="verdana" size=+1><center><b>TRY YOURSELF!!!<br>&nbsp;<tr><td bgcolor=#000066>&nbps;<tr><td bgcolor=#ffffcc><p align=justify><font face=verdana size=2 color=#000066><br>Have You ever wondered why the majority of  people achieve nothing in life but only complain? This is because they are ready on a little in their life. They have a ready definitions on everything, but these definitions are formulated not by them and taken from the others. To have Your own opinion is a luxury and rarity. Those who are not afraid to try and work more than doubts very quickly appears at the top of the World! Yes, it is difficult to believe that it is possible to get rich so quickly, difficult to overcome the doubts and find Yourself suddenly fantastically rich. But believe if You will do it, it becomes Your blessing and Your dizzy success! You will not argue that You are worthy of big success and big richness, will You? And so it is vitally necessary for You to do this step to find the financial independence which will bring You co-operation with superprogram 6X6! Your time has come!<br>&nbsp;<tr><td height=40><tr><td><font face="verdana" size=+1><center><b>"Pair words about the system..." - an interview with Igor Tichtchenkov, the founder of the business system<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td bgcolor=#ffffcc><p><div align=justify><font face=verdana size=2><font color=#000066><br><b>- In view of prompt rates of development of the Internet and electronic commerce the number of users of the "World Wide Web" grows with the great speed. There are more than 15,000 new people who join the Internet daily. With the growth of number of the Internet's users the number of different types of business programs also grows. Every day their popularity increases too and it is natural because the electronic commerce is the business of the 21st century. But business system 6X6 surpasses all others on some orders - it is possible to judge it by  looking at the success it brings to all its participants. What is its advantage above the other business programs of similar type? Why does 6X6 bring success to all its participants - not only for its founder and the people who stand near him?</font></b><p>- Yes, You are absolutely right about the prompt development of electronic commerce and the occurrence of many business systems similar to 6X6.<p>Before the development of the program 6X6 I had closely studied all systems existing at concurrently and understood the way they had appeared. Probably everyone remembers those bonds which were so popular in 90-s. And so with the development of the Internet someone who knows nothing about computer technologies and of the principles of the "World Wide Web" simply transferred this program with bonds to the network. Yes, the idea is ingenious especially for those times - without the Internet You will hardly find 5 clients, in the network there are millions of users and it is possible to send thousands of advertising letters and find a lot of clients. But this system had setbacks: absence of the description of how to send a bulk mailing of advertising letters, where to take thousands of e-mail addresses etc. The most important deficiency was that this system was designed for extremely honest people. In the advertising letter there was a form similar to our business-table according to which the person who entered that business system had to buy its commodity units (each at the different participant). When he bought them he had to put his postal address for payment opposite to the first commodity unit and shift all other addresses one level below. If nobody supervised him he could change the table somehow. For example if he opened some P.O. boxes with various names at different post offices of the city and put the requisitions of these so-called "dead souls" to the table instead of the previous participants and the process stopped that way. Thus the system worked only at 100% at the first level, 1% -at the second, 0,1% - at the third and 0% at the fourth. Actually the profit came only from the first level, i.e. from direct sales. If You sent about 3,000 advertising letters per day You earned about $300 - $400 per month. But the idea of such kind of business systems - was to bring a maximum of the profit due to the last two levels, i.e. You send a party of letters, for example 10,000, receive 30 orders for the first level commodity unit and further the system works for You for several years. But many people earn these $300 - $400 per month sending 3,000 letters per day, having opened some P.O. boxes and put their requisitions everywhere where only it was possible. The commodity units also didn't contain useful information, excepting the names in the advertising letter. Therefore when You worked with such system You deceived the clients.<p>Probably, there is no sense to describe all other similar kinds of business systems because they are the copies of previous in literal sense. All they appeared that way - the essence was copied and secondary factors such as the names of commodity units, ways of payment, the contents of the advertising letter etc. were changed. It is possible to tell one about all of them: they are "created" (if it is possible to apply this word to pure plagiarism) by amateurs, that are distant  from business in general (what is electronic commerce - they simply don't know!) as well as from computer technologies. But the idea to create such business systems is genious. Especially at our time – a  time of the cutting edge Internet development and electronic commerce. Excluding the deficiencies of this system it is invaluable! Can You imagine what will the Internet look like in five years!<p>Even though the task was very difficult I developed such a business system.<p><font color=#000066>The absence of the description of how to send a bulk mailing of advertising letters, where to take thousands of e-mail addresses and other technical details, I compensated with a specially developed software for automation of this process, that allowed one to send 5,000 to 20,000 advertising letters per day having spent only 30-40 minutes of the time, and with the very detailed description of work with this software, written in language which is comprehensible for users of any level and a plenty of advices and recommendations. I managed to do two things at once: to considerably increase productivity of the business system and to make the commondity units not only useful - required for the every participant of the business system, because they contain this special software and the description of work with it.<p>I stopped the dishonesty of participants by an obligatory registration at the main office of 6X6 MLM Corporation.<p>Because the system does not break I have added 2 additional levels and now the system has 6 levels (and the commodity unit of every level costs $6 - therefore and the name "6X6").<p>I made a more flexible system of the payment for the orders. Now the commodity units can be paid both by the "traditional" first class mail and can be transferred on the bank account. But I forbade to specify P.O. boxes as the address for payment for avoidance of a deceit and that the business system don't lose its attractiveness. Proceeding from the same reasons I forbade WebMoney.<p>I concluded the contract with iWin Loto Ltd. So with registration in our main office You are automatically included in a lottery and Your chances to win are directly proportional to the amount of sold Chapter#1.<br>&nbsp;<tr><td height=60><tr><td><font face="verdana" size=+1><center><b>The responses of our partners<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td><p align=justify><font face=verdana size=2><br>My name is Jerry Proctor. Two years ago, the corporation I worked at for the past fifteen years down-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life and I am writing to share the experience in hopes that this will change Your life FOREVER FINANCIALLY!!! In mid December, I received this program via e-mail. Six month's prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year ...it didn't tell me I'd have to write a book to make it! But like I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, without putting me further into debt. After I got a pencil and paper and figured it out, I would at least get my money back. But like most of You I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." Initially I sent out 30,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, the only expense is my time. I am telling You like it is, I hope it doesn't turn You off, but I promised myself that I would not "rip-off" anyone, no matter how much money it cost me. In less than two weeks, I was starting to receive orders for CHAPTER#1. By January 13, I had received 36 orders for CHAPTER#1. Your goal is to "RECEIVE at least 30 ORDERS FOR CHAPTER#1" My first step in making $100,000 in 120 days was done. By January 30, I had received 246 orders for CHAPTER#2. Your goal is to "RECEIVE AT LEAST 150 ORDERS FOR CHAPTER#2. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 150 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $100,000 GOAL." Well, I had 246 orders for CHAPTER#2, 96 more than I needed. So I sat back and relaxed. By March 30, of my e-mailing of 30,000, I received $118,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car. Please take time to read this program, IT WILL CHANGE YOUR LIFE FOREVER!!! Remember, it won't work if You don't try it. This program does work, but You must follow it EXACTLY! In order for this program to work, You must meet Your goal of 30+ orders for CHAPTER#1, and 150+ orders for CHAPTER#2 and You will make $100,000 or more in 120 days. I AM LIVING PROOF THAT IT WORKS!!! If You choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to You. If You choose to participate, follow the program and You will be on Your way to financial security. If You are a fellow business owner and are if financial trouble like I was, or You want to start Your own business, consider this a sign. I DID!</p><p align=right><font face=verdana size=2>Sincerely, Jerry Proctor.<tr><td height=40><tr><td bgcolor=#000066>&nbsp;<tr><td><p align=justify><font face=verdana size=2><br>This program really works. I live outside the US, in Europe and at first I had doubts, I wasn't sure if it would work and so I didn't take it very seriously. But after a while I figured "Why not?". After all, I can't loose much. I sended the requests for the Chapters (I did everything just like I had to because I wanted to do everything right, so if it wouldn't work it wouldn't be my fault, but the program's) and waited. After a while the Chapters arrived by e-mail and I read them several times, they gave me precise information on how to let the program work and after I knew it all, I started my work. I started searching e-mail addresses everywhere (sites, magazines,...) and made long lists (I really enjoyed this because it was like a new hobby and I had nothing to loose). like crazy I started sending e-mail to people all over the world. I kept doing this and checked the mail every day. After two weeks orders started to arrive. I remember the moment when I went to the mailbox and I found the first order for Chapter#1. I just stood there for a moment and I said to myself: "this works, this thing f..... works!!!" I was so happy that I started sending even more e-mails. The next day, nothing in the mail, I thought "maybe this is it" and I was a bit dissapointed but the next day I received 3 orders for Chapter#1. I sended the Chapters to those people so they could start making money too (for them and for me). Two weeks later I was sitting almost 30 minutes a day before my computer sending Chapters to people that had ordered them. In these two weeks I received 39 orders for Chapter#1. Profit so far: about 240 dollars. After that orders came faster and faster, every week I got hundreds of orders and the dollars kept coming. In total I received 124'000 dollars. can You believe this??? Last week I bought a new motorcycle and I owe it all to this program. if You're reading this letter right now and You're not sure whether to participate or not I can only say one thing: TRY IT, You won't regret. This is Your chance, take it now or You will be sorry for the rest of Your live.</p><p align=right><font face=verdana size=2>H.J. Moines, France.<tr><td height=40><tr><td bgcolor=#000066>&nbsp;<tr><td><p align=justify><font face=verdana size=2><br>The main reason for this letter is to convince You that this system is honest, lawful, extremely profitable, and is a way to get a large amount of money in a short time. I was approached several times before I checked this out. I joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received $136,470 in the first 14 weeks, with money still coming in.</p><p align=right><font face=verdana size=2>Charles Morris, Esq.<tr><td height=40><tr><td bgcolor=#000066>&nbsp;<tr><td><p align=justify><font face=verdana size=2><br>Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. Boy, was I surprised when I found my medium-size mailbox crammed with orders! For awhile, it got so overloaded that I had to start picking up my mail at the window. I'll make more money this year than any 10 years of my life before. The nice thing about this deal is that it doesn't matter where people live. There simply isn't a better investment with a faster return.</p><p align=right><font face=verdana size=2>Paige Willis, Des Moines, IA.<tr><td height=40><tr><td bgcolor=#000066>&nbsp;<tr><td><p align=justify><font face=verdana size=2><br>I had received this program before. I deleted it, but later I wondered if I shouldn't have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed another program, ...11 months passed then it came... I didn't delete this one! I made more than $141,000 on the first try!!</p><p align=right><font face=verdana size=2>Violet Wilson, Johnstown, PA.<tr><td height=40><tr><td bgcolor=#000066>&nbsp;<tr><td><p align=justify><font face=verdana size=2><br>This is my third time to participate in this plan. We have quit our jobs, and will soon buy a home on the beach and live off the interest on our money. The only way on earth that this plan will work for You is if You do it. For Your sake, and for Your family's sake don't pass up this golden opportunity. Good luck and happy spending!</p><p align=right><font face=verdana size=2>Kerry Ford, Centerport, NY.<tr><td height=50><tr><td><font face=verdana size=2><b>We wait for Your responses. Send them to the main office.<tr><td height=50><tr><td><font face="verdana" size=+1><center><b>What is the 6X6?<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td bgcolor=#ffffcc><p><div align=justify><font face=verdana size=2><br>So, let’s start earning heaps of  money without leaving the house! "This is my chance!", - You exclaim  having realized that is not necessary to go anywhere and to persuade somebody - only send advertising letters and receive profits! "And what is necessary to do for this purpose?" - the question is inevitable. Earning a heap of money - from $100,000 up to $1,000,000 - for the beginning You must  be registered at the main office of the 6X6 MLM Corporation and receive a personal registration number. Having entered in 6X6, You become the distributor of the Chapters - detailed descriptions of work with business system 6X6 and optimization the computer. Clients of Your business become the people that will be interested in these Chapters. And the Chapters should interest them! People will be interested in business itself and all this is a guaranty that people certainly shall respond to Your letter. What is this letter? This is the advertising letter which You'll receive from the main office of the 6X6 MLM Corporation after the registration (it differs from the letter which You are reading now by the presence of Your registration number in the business table). You simply send it to a lot of people. How to find the endless amount of e-mails, how automatically send the advertising letter to them and many other things You will find out in the Chapters. If You  are worried where to find so many e-mail addresses don’t bother. There are more than 15,000 new people connecting to the Internet daily!!! It'll be enough for everybody!!! After You send the application for registration, a letter will be sent to You, containing:<blockquote><blockquote><p>1) Your registration number,<p>2) The advertising letter with Your registration number in the business table. In the future You'll send this letter to thousands of recipients,<p>3) Postal addresses or bank accounts of other participants of the business system. It is necessary for You to order the Chapters from them, each Chapter from different participant (excepting the Master) according to the deciphered business table, that You had an opportunity to sell them to the customers.</blockquote></blockquote><p>Together with it You will also receive other instructions. Well the thing You'll have to do now is to catch the essence of the algorithm below. So, You have all Chapters and You have to send the letter which contains the foreword to these surprising Chapters as the advertisement. Having read it, the person who has received the letter from You will certainly want to enter to the business system 6X6 and read all Chapters. But even if suddenly he will not want to read the Chapters he'll certainly become interested in a unique opportunity to earn millions practically without any expenses, both on money and on time! I agree, it is just impossible to refuse it! Approximately in 2 weeks from the date of Your first mailing You will receive orders for the first Chapter and a payment for it ($6 for each Chapter) from 30 persons or even more. Thus, Your first income will be $180 or more. This is only the beginning! At registration You will be automatically included in a lottery from iWin Lotto - one of the most popular companies engaged in lotto-business in the World, the main prize is $5,000,000 (it is also played 5 prizes on $1,000,000, 100 prizes on $100,000 and more than 5,000 branded T-shirts from 6X6 MLM Corp., draws are carried out every month) – as much orders You get  on Chapter#1, as much  chances to win the main prize. Do You see?!!! All that is required of You is to send more advertising letters. All Your work will be to go to the bank from time to time or check Your mailbox for cash, and  at home, in silence to count up everytime increasing profit! The guarantor of Your dizzy success and reliable ally becomes the most grandiose in the world computer superprogram 6X6!!!<br>&nbsp;<tr><td height=40><tr><td><font face="verdana" size=+1><center><b>THE CHAPTERS<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td bgcolor=#ffffcc><p><div align=justify><font face=verdana size=2><br>The Chapters are the most detailed description of the business system 6X6, they are advices about the way to optimize the work with the system and adjust the computer for it. Having read them You will understand how to improve a connection with the Internet, how to find 5,000 to 20,000 e-mail addresses per day, to sort them, to send 5,000 to 20,000 advertising letters per day, how to increase productivity of the computer on 50% and many others interesting things, not applying special efforts.<p>The Chapters are written in language that is clear for the users of any levels, therefore for working with the business system 6X6 You don't need to be a programmer or even have computer experience. Moreover, if You have begun to work with the computer just yesterday and don't know anything about it, You should read attentively the Chapters and work some time with the business system 6X6. Thus You will soon become an advanced user who knows everything about Windows and the Internet. In addition You also get the special software with each Chapter that is necessary for work and certain amount of e-mail addresses.<blockquote><blockquote><blockquote><p><b>The list of the Chapters:</b></blockquote><p><b>Chapter#1</b> “Introduction to business system 6Õ6. Optimization of the Internet connection. How to use the Internet much more effectively.”<p><i>+20,000 e-mails<br>+software for automatic reconnecting to the Internet and its complete description.</i><p><b>Chapter#2</b> “How to find 5,000 to 20,000 e-mails per day, working about 30-40 minutes.”<p><i>+10,000 e-mails<br>+software for automatic inclusion/deenergizing of the program for e-mails searching at connection/break of connection with the Internet described in the previous Chapter.</i><p><b>Chapter#3</b> “How to sort e-mails.”<p><i>+10,000 e-mails<br>+software for automatic e-mails searching described in the previous Chapter.</i><p><b>Chapter#4</b> “How to send 5,000 to 20,000 thousand advertising letters per day, working the same 30-40 minutes.”<p><i>+10,000 e-mails<br>+software for fast e-mails sorting described in the previous Chapter.</i><p><b>Chapter#5</b> “The most effective algorithm of the work with the business system 6X6.”<p><i>+80,000 e-mails (!)<br>+software for automatic sending a huge amount of the advertising letters with attachments described in the previous Chapter.</i><p><b>Chapter#6</b> “Optimize Your computer, raise its productivity on 50%.”<p><i>+100,000 e-mails (!)<br>+the server part of the software for automatic sending a huge amount of the advertising letters with attachments.</blockquote></blockquote><tr><td height=40><tr><td><font face="verdana" size=+1><center><b>THE RULES OF THE PARTICIPATION IN THE BUSINESS SYSTEM 6X6<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td><p><font face=verdana size=2><br><blockquote><blockquote><blockquote><b>The terms:</b></blockquote></blockquote><p><b>The master</b> – Igor Tichtchenkov, the founder of the business system;<p><b>referrer</b> – the participant of 6X6 from that You have received this advertising letter and should order the Chapter;<p><b>client</b> – the owner of e-mail address where You send the advertising letter;<p><b>referral</b> – the participant of 6X6 who has ordered from You the Chapter.</blockquote><tr><td height=30><tr><td><font face="verdana" size=+1><center><b>How does the business system 6X6 work<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td bgcolor=#ffffcc><p><div align=justify><font face=verdana size=2><br>The following system was developed to earn not only from the direct sales (i.e. when You sell the Chapter#1 to Your referrals) but also from the sales of the referrals (i.e. when Your referrals bring to You buyers on Chapter#2 - Chapter#6). There is a following table (so-called the business table) in the advertising letter:<blockquote><blockquote><blockquote><p>Chapter#1...............referrer nr.1<br>Chapter#2...............referrer nr.2<br>Chapter#3...............referrer nr.3<br>Chapter#4...............referrer nr.4<br>Chapter#5...............referrer nr.5<br>Chapter#6...............referrer nr.6</blockquote></blockquote><p>Opposite to each Chapter there is the essential elements of different participants, i.e. You will buy the Chapter#1 from referrer nr.1, Chapter#2 from referrer nr.2, Chapter#3 from referrer nr.3, Chapter#4 from referrer nr.4, Chapter#5 from referrer nr.5, Chapter#6 from referrer nr.6. When You will be registered You'll receive the advertising letter with the business table changed as follows:<blockquote><blockquote><p>Chapter#1...............You<br>Chapter#2...............referrer nr.1<br>Chapter#3...............referrer nr.2<br>Chapter#4...............referrer nr.3<br>Chapter#5...............referrer nr.4<br>Chapter#6...............referrer nr.5</blockquote></blockquote><p>Then You begin to send the advertising letter with such business table. I.e. Your referrals will buy the Chapter#1 from You, Chapter#2 from referrer nr.1, Chapter#3 from referrer nr.2, Chapter#4 from referrer nr.3, Chapter#5 from referrer nr.4, Chapter#6 from referrer nr.5. Your referrals nr.1 (they who will buy Chapter#1 from You) will get similarly transformed business table:<blockquote><blockquote><p>Chapter#1...............referral nr.1<br>Chapter#2...............You<br>Chapter#3...............referrer nr.1<br>Chapter#4...............referrer nr.2<br>Chapter#5...............referrer nr.3<br>Chapter#6...............referrer nr.4</blockquote></blockquote><p>Then they begin to send the advertising letter with such business table. I.e. their referrals nr.1 (Your referrals nr.2) will buy the Chapter#1 from them (from Your referrals nr.1), Chapter#2 from You, Chapter#3 from referrer nr.1, Chapter#4 from referrer nr.2, Chapter#5 from referrer nr.3, Chapter#6 from referrer nr.4. And etc...<p><font color=#000066>Thus Your referrals involve the clients to the Chapter#1 for themselves and also involve the clients to the other Chapters for You. That means that a direct task of each participant of business system 6X6 - to get as more as possible orders for Chapter#1.<p>Let's just count up how much money You will earn if each participant involves 10 referrals nr.1:<blockquote><p><div align=left><font color=red>You......................10 X $6 = $60<br>Your referrals nr.1...10 X 10 X $6 = $600<br>Your referrals nr.2...10 X 10 X 10 X $6 = $6,000<br>Your referrals nr.3...10 X 10 X 10 X 10 X $6 = $60,000<br>Your referrals nr.4...10 X 10 X 10 X 10 X 10 X $6 = $600,000<br>Your referrals nr.5...10 X 10 X 10 X 10 X 10 X 10 X $6 = $6,000,0000<p><b>Total You will earn $6,666,660!</b></blockquote><p><font color=#000066>The figure is not small and therefore You may have doubts. - Try to figure Yourself and You'll get the same result!</blockquote><tr><td height=40><tr><td><font face="verdana" size=+1><center><b>Protection against the fraud<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td bgcolor=#ffffcc><p><div align=justify><font face=verdana size=2><br>The following protection was developed to exclude breaking of the system.<blockquote><p>In the advertising letter there is such business table:<blockquote><p>Chapter#1...............reg. nr. of the 1st referrer<br>Chapter#2...............reg. nr. of the 2nd referrer<br>Chapter#3...............reg. nr. of the 3rd referrer<br>Chapter#4...............reg. nr. of the 4th referrer<br>Chapter#5...............reg. nr. of the 5th referrer<br>Chapter#6...............reg. nr. of the 6th referrer</blockquote><p>The client who has received this advertising letter knows only registration numbers of the referrers from that he must buy the Chapters. He can't buy all their Chapters directly because he doesn't know their requisitions.<p>Further he registers at the main office of 6X6 MLM Corporation and gets:<blockquote><p>1) His registration number;<p>2) Addresses and bank accounts of all referrers at that he must buy the Chapters;<p>3) The advertising letter with the changed business table likes that:<p>Chapter#1...............His reg. nr.<br>Chapter#2...............reg. nr. of the 1st referrer<br>Chapter#3...............reg. nr. of the 2nd referrer<br>Chapter#4...............reg. nr. of the 3rd referrer<br>Chapter#5...............reg. nr. of the 4th referrer<br>Chapter#6...............reg. nr. of the 5th referrer</blockquote><p>buys all of the Chapters and begins to send this letter.</blockquote><p><font color=#000066>Due to this protection he can't stop the process and leave their own referrers without their profit. The process can be stopped only if their requisitions will not be in the business table. It is possible only if he will replace requisitions of all five referrers with his requisitios. But he can't do that because for this purpose it will come to register 6 times, whereas it is possible to register only once.<br>&nbsp;<tr><td height=60><tr><td><font face="verdana" size=+1><center><b>ARE YOU READY TO START WITH THE BUSINESS SYSTEM 6X6! LET'S START!<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td bgcolor=#ffffcc><p align=justify><font face=verdana size=2 color=red><br><blockquote><b>Attention! There is an enormous amount of referrals who enter the business system 6X6 and that's why from the 1st of September 2000 the registration costs $5.</b><font color=#000066><blockquote><blockquote><p><font color=#000066><b>WHAT YOU NEED TO DO:</b></blockquote></blockquote><p><b>a) Register at the main office of 6X6 MLM Corporation:</b><p>1) Write on a sheet of paper:<blockquote><p>1) Your name;<br>2) Your postal address for payment;<br>3) Your bank account for payment <i>(optional)</i>;<br>4) Your e-mail - write legibly and use it only for communication with the main office;<br>5) The business table which is below;<br>6) The date.</blockquote><p>2) Put $5 in this sheet of paper and send by the <b>first class mail</b> to the 6x6 MLM Corporation's main office:<blockquote><p><b>Igor Tichtchenkov, Laanemere 20-96, 13913 Tallinn, Estonia.</b></blockquote><p>3) Within one week You'll receive (via e-mail You have written in the registration form) the letter containing:<blockquote><p>1) Your registration number;<br>2) Addresses of the referrers from that You should buy the Chapters;<br>3) The advertising letter with Your registration number for mailing;<br>4) The instructions that is necessary for beginning.</blockquote><p><b>b) Buy all of the Chapters according to the business table:</b><p><center><table width="60%" border="1" cellspacing="0" cellpadding="0"><tr><td><center><b><font face=verdana color="#000066">Chapter Nr.</td><td><center><b><font face=verdana color="#000066">Referrer's reg. nr.<tr><td><center><font face=verdana color="#000066">Chapter#1</td><td><center><b><font face=verdana color="#FF0000"> 6x6-000002-z-302<tr><td><center><font face=verdana color="#000066">Chapter#2</td><td><center><b><font face=verdana color="#FF0000">6x6-000002-z-115<tr><td><center><font face=verdana color="#000066">Chapter#3</td><td><center><b><font face=verdana color="#FF0000">6x6-000000-z-001<tr><td><center><font face=verdana color="#000066">Chapter#4</td><td><center><b><font face=verdana color="#FF0000">Master 6x6<tr><td><center><font face=verdana color="#000066">Chapter#5</td><td><center><b><font face=verdana color="#FF0000">Master 6x6<tr><td><center><font face=verdana color="#000066">Chapter#6</td><td><center><b><font face=verdana color="#FF0000">Master 6x6</table></center><font color=red><p align=justify><b>THE NOTE! If several or even all registration numbers are "Master 6X6" - there isn't any mistake. When You join You'll be at the begining of the system and undoubtedly earn the enormous amount of money! Your chances to the success are maximal!</blockquote><tr><td height=40><tr><td><div align=justify><font face=verdana size=2>As soon as You do this, start sending the advertising letters (more detailed information about the way to do it You will find at the Chapters). In general You should involve about 30 referrals - i.e. to sell 30 Chapters #1. But the more referrals You involve the more Your profit will be!<p>Try to send 3,000 or more advertising letters per day - it is very easy to do with the special software which You'll get together with the Chapters. If You can send more - do it! Remember as many advertising letters You send the more orders You will get!<p>The entire process lasts approximately for 4 months. If You precisely follow all the rules, You undoubtedly will be the owner of several hundreds thousand dollars! We know that it will be like that and we congratulate You!!!<tr><td height=60><tr><td><font face="verdana" size=+1><center><b>And now let's start!<p><font color=#000066 size=5><b>We wish You Great Success!!!<tr>
<td height=40><tr><td bgcolor=#ffffcc>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td><br><center><font face="verdana" size="1" color="#555555">Copyright © 2001 6x6 MLM Corporation. All rights reserved.</font><tr><td height=400><tr><td></table></table><center><a name="r"><table cellpadding="0" cellspacing="0" border="0" width="660"><tr><td><center><font face="verdana" size="+1"><b>Æåëàåì Âàì ïðèÿòíîãî è óñïåøíîãî äíÿ!</center><div align="right"><font face="verdana" size="+2"><a href="#e"><b>In English</a><tr bgcolor="#000066"><td>&nbsp;</table><table width="660" cellpadding="0" cellspacing="0" border="0"><tr><td><table width="518" border="0" cellspacing="0" cellpadding="0"><tr><td><table width="500" cellpadding="0" cellspacing="0" border="0"><tr><td><font face="verdana" size="+1"><center><b>Ýòî çàðàáîòîê áåç îòðûâà îò ìîíèòîðà!</b></center><p><div align="justify"><br><font size="2">Åñëè Âû ïðîÿâèòå íåêîòîðûé èíòåðåñ è òåðïåíèå, à ãëàâíîå, ðàçáåðåòåñü, êàê ÝÒÎ ðàáîòàåò, Âû ìîæåòå õîðîøî çàðàáîòàòü â òå÷åíèå ñëåäóþùèõ 120 äíåé - äî <b>$100.000</b> è <b>áîëåå!!!</b>, ýòî çàâèñèò òîëüêî îò Âàñ. ÊÀÆÅÒÑß ÍÅÂÎÇÌÎÆÍÛÌ?? Ïðî÷èòàéòå äàííûé äîêóìåíò è Âû óáåäèòåñü, ÷òî â ýòîì íåò íèêàêîé êàâåðçû èëè îáìàíà. Åñëè Âû ïîëíûé ëåíòÿé - ïðîñèì ïðîùåíèå çà ïðåäëîæåíèå!!!,- òî ýòî íå äëÿ Âàñ!!! Ëó÷øå çàíèìàéòåñü ñåðôèíãîì èëè êëèêàéòå ïî áàííåðàì èëè æå íå çàíèìàéòåñü íè÷åì.<p>!!!Åñëè ïðåäëîæåíèå Âàñ íè÷åì íå çàèíòåðåñîâàëî, ïðèíîñèì ñâîè èçâèíåíèÿ è íå íàäî ñåðäèòüñÿ. "Ñïàì" èìååò ñâîè èçäåðæêè, òàê æå êàê ðàäèî è TV, íî íå çàáûâàéòå, ÷òî ñêàçàë ïåðâûé ìèëëèàðäåð ÑØÀ Äåéë Êàðíåãè:<p>"ß ëó÷øå áóäó çàðàáàòûâàòü 1% â ðåçóëüòàòå óñèëèé 100 ÷åëîâåê, ÷åì 100% â ðåçóëüòàòå ñâîèõ ñîáñòâåííûõ óñèëèé."<p><font size="3" color="#000066"><center><br><b>ÂÑÒÀÍÜÒÅ ÍÀ ÏÓÒÜ Ê ÔÈÍÀÍÑÎÂÎÉ ÍÅÇÀÂÈÑÈÌÎÑÒÈ È ÑÂÎÁÎÄÅ!!!</table></table><td width="142" bgcolor="#000066"><table width="142" cellpadding="0" cellspacing="0" border="0"><tr><td bgcolor="#000066"><center><table width="125" cellpadding="0" cellspacing="0" border="0"><tr><td bgcolor="#FFFFCC"><font face="verdana" size="2"><center>Äîáðî ïîæàëîâàòü â <b><font color=red>6<font color=green>X<font color=blue>6</font></font></font>!<tr><td>&nbsp;<tr><td bgcolor="#FFFFCC"><center><table width="115" cellpadding="0" cellspacing="0" border="0"><tr><td><font face="verdana" size="1"> ýòî òðóäíî ïîâåðèòü, íî, òåì íå ìåíåå, ýòî ñâåðøèâøèéñÿ ôàêò! Ëþäè áîãàòåþò íà ãëàçàõ! Íåêîòîðûå äàæå ìåñÿöû ñïóñòÿ íå ìîãóò îïðàâèòüñÿ îò øîêà, ïðèøåäøåãî âìåñòå ñ êó÷åé õðóñòÿùèõ áàíêíîò! Ïîêà îñòàëüíûå ðàçäóìûâàþò è ñîìíåâàþòñÿ, ïîâåðèâøèå â ÷óäî Áèçíåñ Ñèñòåìû 6Õ6 êóïàþòñÿ â äåíüãàõ!...</table><tr><td>&nbsp;<tr><td bgcolor="#FFFFCC"><tr><td bgcolor="#FFFFCC"><center><table width="115" cellpadding="0" cellspacing="0" border="0"><tr><td><font face="verdana" size="1">×èñëî ïîëüçîâàòåëåé "âñåìèðíîé ïàóòèíû" ðàñòåò ñ ìîëíèåíîñíîé áûñòðîòîé. Óæå ñåé÷àñ òîëüêî â Ðîññèè ê ñåòè Èíòåðíåò åæåäíåâíî ïîäêëþ÷àþòñÿ áîëåå 2000 ÷åëîâåê, íà Çàïàäå è â ÑØÀ ýòà öèôðà â íåñêîëüêî ðàç áîëüøå...</table></table></table><tr><td colspan="2"><table cellpadding="0" cellspacing="0" border="0" width="660"><tr bgcolor="#000066"><td>&nbsp;</table><br><center><font face="verdana" size="1" color="#555555">Copyright © 2001 6x6 MLM Corporation. All rights reserved.</font><table width="660" cellpadding="0" cellspacing="0" border="0"><tr><td height="60"><tr><td><font face="verdana" size=+1><center><b>ÄÀÌÛ È ÃÎÑÏÎÄÀ!<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td><font face=verdana size=+1><center><p><br><b>ÏÐÎ×ÒÈÒÅ ÝÒÎ ÂÄÓÌ×ÈÂÎ, ÂÍÈÌÀÒÅËÜÍÎ, ÍÅ ÎÒÂËÅÊÀßÑÜ ÍÀ ÂÍÅØÍÈÅ ØÓÌÛ È ÐÀÇÄÐÀÆÈÒÅËÈ, È ÂÛ ÏÎÉÌÅÒÅ, ×ÒÎ ÑÄÅËÀÅÒ ÂÀÑ ÏÎ-ÍÀÑÒÎßÙÅÌÓ ÁÎÃÀÒÛÌÈ È ÑÂÎÁÎÄÍÛÌÈ ËÞÄÜÌÈ!!!<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td bgcolor=#ffffcc><p align=justify><br><font face=verdana size=2 color=#000066> ýòî òðóäíî ïîâåðèòü, íî, òåì íå ìåíåå, ýòî ñâåðøèâøèéñÿ ôàêò! Ëþäè áîãàòåþò íà ãëàçàõ! Íåêîòîðûå äàæå ìåñÿöû ñïóñòÿ íå ìîãóò îïðàâèòüñÿ îò øîêà, ïðèøåäøåãî âìåñòå ñ êó÷åé õðóñòÿùèõ áàíêíîò! Ïîêà îñòàëüíûå ðàçäóìûâàþò è ñîìíåâàþòñÿ, ïîâåðèâøèå â ÷óäî Áèçíåñ Ñèñòåìû 6Õ6 êóïàþòñÿ â äåíüãàõ!  áóêâàëüíîì ñìûñëå ñëîâà! Âû êîãäà-íèáóäü âèäåëè, êàê âûãëÿäèò âîðîõ ñîòåííûõ êóïþð, ïîä êîòîðûì öåëèêîì óìåùàåòñÿ âçðîñëûé ÷åëîâåê?! Ýòî 100 òûñÿ÷ äîëëàðîâ! Ìîæåòå ñåáå ïðåäñòàâèòü, êàê áû âûãëÿäåëà êó÷à èç ìèëëèîíà äîëëàðîâ, êîòîðûå çàðàáàòûâàåò êàæäûé òðåòèé ó÷àñòíèê ñóïåðïðîãðàììû 6Õ6? À êàêîâî îùóùåíèå, êîãäà òû, îñîáî íå óòðóæäàÿ ñåáÿ ðàáîòîé, óæå íà âòîðîé íåäåëå íà÷èíàåøü ïîëó÷àòü êîíâåðòû ñ øåñòüþ äîëëàðàìè, è ÷åì äàëüøå, òåì áîëüøå! À, â êîíöå êîíöîâ, íà 3-ì, íà 4-ì ìåñÿöå òû óæå íå çíàåøü, êóäà îò íèõ äåâàòüñÿ! Äàæå äóõ çàõâàòûâàåò îò ýòîé ëàâèíû äåíåã!<br>&nbsp;<tr><td height=40><tr><td><font face=verdana size=2 color=#000066><center><b>ÂÑÅ, ×ÒÎ ÂÀÌ ÍÓÆÍÎ ÁÓÄÅÒ ÄÅËÀÒÜ, ÝÒÎ ÐÀÑÑÛËÀÒÜ ÃÎÒÎÂÛÅ ÏÈÑÜÌÀ ÏÎ E-MAIL È ÂÐÅÌß ÎÒ ÂÐÅÌÅÍÈ ÕÎÄÈÒÜ ÍÀ ÏÎ×ÒÓ ÈËÈ Â ÁÀÍÊ ÇÀ ÄÅÍÜÃÀÌÈ! ÂÀÌ ÄÀÆÅ ÍÅ ÍÀÄÎ ÍÀÏÐßÃÀÒÜ ÑÂÎÉ ÌÎÇà – ÇÀ ÂÀÑ ÂÑÅ ÑÄÅËÀÅÒ ÊÎÌÏÜÞÒÅÐÍÀß ÑÓÏÅÐ ÁÈÇÍÅÑ ÑÈÑÒÅÌÀ 6Õ6!<p><b>Ñ ÌÎÌÅÍÒÀ ÂÀØÅÃÎ ÂÑÒÓÏËÅÍÈß Â ÁÈÇÍÅÑ ÏÐÈÁÛËÜ ÍÀÐÀÑÒÀÅÒ, ÊÀÊ ÑÍÅÆÍÛÉ ÊÎÌ, È Ê ÊÎÍÖÓ 4-ÃÎ ÌÅÑßÖÀ ÂÛ ÏÎËÓ×ÈÒÅ ÊÀÊ ÌÈÍÈÌÓÌ 100.000 ÄÎËËÀÐÎÂ. À ÅÑËÈ ÂÛ ÍÅ ÎÑÒÀÍÎÂÈÒÅÑÜ ÍÀ ÄÎÑÒÈÃÍÓÒÎÌ, ÒÎ ÐÅÇÓËÜÒÀÒÎÌ ÁÓÄÓÒ ÀÑÒÐÎÍÎÌÈ×ÅÑÊÈÅ 1.000.000 ÄÎËËÀÐΠÇÀ ÃÎÄ!<tr><td height=40><tr><td bgcolor=#ffffcc><p align=justify><br><font face=verdana size=2 color=#000066>“ ×ÅÌ ÑÅÊÐÅÒ ÒÀÊÎÃÎ ÃÎËÎÂÎÊÐÓÆÈÒÅËÜÍÎÃÎ ÓÑÏÅÕÀ?”, – ÑÏÐÎÑÈÒÅ ÂÛ. ÄÅËÎ Â ÒÎÌ, ×ÒÎ Â ÏÐÎÃÐÀÌÌÅ 6Õ6 ÇÀËÎÆÅÍÀ ÍÎÂÀß ÔÎÐÌÓËÀ, ÊÎÒÎÐÀß ÎÁÅÑÏÅ×ÈÂÀÅÒ 100%-ÍÛÉ ÓÑÏÅÕ ÂÑÅÌ Ó×ÀÑÒÍÈÊÀÌ ÁÈÇÍÅÑÀ ÇÀ Ñ×ÅÒ Ó×ÅÒÀ ÒÀÊÈÕ ÓÒÎÍ×ÅÍÍÛÕ ÔÀÊÒÎÐÎÂ, ÊÎÒÎÐÛÅ ×ÅËÎÂÅ×ÅÑÊÈÉ ÌÎÇà ÏÐÎÑÒÎ ÍÅ ÑÏÎÑÎÁÅÍ ÎÕÂÀÒÈÒÜ. ÏÎÝÒÎÌÓ ÏÐÎÃÐÀÌÌÀ ÐÀÁÎÒÀÅÒ! È ÐÀÁÎÒÀÅÒ ÁËÅÑÒßÙÅ! ÝÒÎ – ×ÓÄÎ-ÑÈÑÒÅÌÀ,  ÊÎÒÎÐÎÉ ÓÑÏÅÕ ÁÅÇÓÌÍÎ ÇÀÐÀÇÅÍ! ÑÏÅØÈÒÅ ÇÀÐÀÇÈÒÜÑß È ÂÛ!<br>&nbsp;<tr><td height=40><tr><td><font face="verdana" size=+1><center><b>ÂÍÈÌÀÍÈÅ!!!<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td bgcolor=#ffffcc><p align=justify><br><font face=verdana size=2> ËÀÁÎÐÀÒÎÐÈÈ ÑÎÖÈÎËÎÃÈ×ÅÑÊÈÕ ÈÑÑËÅÄÎÂÀÍÈÉ Â ÑØÀ ÁÛË ÏÐÎÂÅÄÅÍ ÝÊÑÏÅÐÈÌÅÍÒ: ÏÐÎÃÐÀÌÌÀ 6Õ6 ÁÛËÀ ÇÀÏÓÙÅÍÀ 16 ÐÀÇ Â ÑÀÌÛÕ ÐÀÇËÈ×ÍÛÕ ÓÑËÎÂÈßÕ È Ñ ÑÀÌÛÌÈ ÐÀÇÍÛÌÈ ËÞÄÜÌÈ Â ÊÀ×ÅÑÒÂÅ Ó×ÀÑÒÍÈÊΠÁÈÇÍÅÑÀ, È ÂÑÅ 16 ÐÀÇ ÎÍÀ ÏÐÈÍÎÑÈËÀ ÎÄÈÍÀÊÎÂÛÉ ÓÑÏÅÕ, È ÍÅ ÁÛËÎ ÍÈ ÎÄÍÎÃÎ ×ÅËÎÂÅÊÀ, ÊÎÒÎÐÛÉ ÁÛ ×ÓÂÑÒÂÎÂÀË ÑÅÁß ÎÁÄÅËÅÍÍÛÌ È ÎÁÈÆÅÍÍÛÌ. ÒÀÊÆÅ ÑÏÅÖÈÀËÈÑÒÛ ÏÐÎÈÇÂÅËÈ ÍÀÓ×ÍÛÉ ÀÍÀËÈÇ ÔÅÍÎÌÅÍÀ 6Õ6 È ÓÑÒÀÍÎÂÈËÈ, ×ÒÎ, ÍÅÑÌÎÒÐß ÍÀ ÂÍÅØÍÅÅ ÑÕÎÄÑÒÂÎ, ÏÎ ÑÂÎÅÉ ÌÈÊÐÎÑÒÐÓÊÒÓÐÅ ÎÍÀ  ÊÎÐÍÅ ÎÒËÈ×ÀÅÒÑß ÎÒ ÑÅÒÅÂÎÃÎ ÌÀÐÊÅÒÈÍÃÀ È ÏÐÈÂÎÄÈÒ Ê ÍÅÑÐÀÂÍÈÌÎ ÁÎËÅÅ ÂÛÑÎÊÈÌ, À ÑÀÌÎÅ ÃËÀÂÍÎÅ – ÄÅÌÎÊÐÀÒÈ×ÍÛÌ ÐÅÇÓËÜÒÀÒÀÌ, Ò.Ê. ÂÑÅ Ó×ÀÑÒÍÈÊÈ ÝÒÎÃÎ ÁÈÇÍÅÑÀ ÈÌÅÞÒ ÄÎÕÎÄ. ÑÐÅÄÈ ÀÌÅÐÈÊÀÍÑÊÈÕ ÁÈÇÍÅÑÌÅÍΠÝÒÀ ÑÓÏÅÐÏÐÎÃÐÀÌÌÀ ÏÐÎÈÇÂÅËÀ ÍÀÑÒÎßÙÈÉ ÔÓÐÎÐ: ÎÍÈ ÏÐÎÇÂÀËÈ ÅÅ <font color=#000066><b>“DIAMOND STREAM”</b></font>, ×ÒÎ ÏÅÐÅÂÎÄÈÒÑß ÊÀÊ <font color=#000066><b>“ÀËÌÀÇÍÛÉ ÏÎÒÎÊ”</b></font>. “ÏÎÒÎÊ” – ÏÎÒÎÌÓ ×ÒÎ ÄÅÍÜÃÈ ÒÅÊÓÒ ÐÅÊÎÉ, À “ÀËÌÀÇÍÛÉ” – ÏÎÒÎÌÓ ×ÒÎ ÝÒÎÒ ÓÑÏÅÕ ÒÀÊÎÉ ÆÅ ÏÐÎ×ÍÛÉ È ÍÅÇÛÁËÅÌÛÉ, ÊÀÊ ÀËÌÀÇ!” – ÎÒÂÅÒÈË ÎÄÈÍ ÈÇ ÁÈÇÍÅÑÌÅÍΠÍÀ ÂÎÏÐÎÑ ÊÎÐÐÅÑÏÎÍÄÅÍÒÀ “NEW-YORK TIMES”.<br>&nbsp;<tr><td height=40><tr><td bgcolor=#000066>&nbps;<tr><td bgcolor=#ffffcc><p align=justify><font face=verdana size=2 color=#000066><br>Âû íèêîãäà íå çàäóìûâàëèñü, ïî÷åìó áîëüøèíñòâî ëþäåé íè÷åãî íå äîñòèãàþò â æèçíè, à òîëüêî ñåòóþò? Äà ïîòîìó ÷òî îíè ìàëî íà ÷òî â æèçíè ðåøàþòñÿ. Íà âñå ó íèõ åñòü ãîòîâûå îïðåäåëåíèÿ, ïðè÷åì ñôîðìóëèðîâàííûå íå èìè ñàìèìè, à óñëûøàííûå îò äðóãèõ. Íî èìåòü ñâîå ïðîâåðåííîå ìíåíèå – ýòî áîëüøàÿ ðîñêîøü è ðåäêîñòü. Òå æå, êòî íå áîèòñÿ ïðîáîâàòü è æèâåò áîëüøå äåéñòâèÿìè, ÷åì ñîìíåíèÿìè, î÷åíü áûñòðî îêàçûâàþòñÿ íà âåðøèíå ìèðà! Äà, òðóäíî ïîâåðèòü, ÷òî ìîæíî òàê áûñòðî ðàçáîãàòåòü, òðóäíî ïðåîäîëåòü ñâîè ñîìíåíèÿ, òðóäíî ïðåäñòàâèòü ñåáÿ âäðóã ñêàçî÷íî áîãàòûì. Íî ïîâåðüòå, åñëè Âû ýòî ñäåëàåòå, ýòî ñòàíåò âàøèì áëàãîì è âàøèì ãîëîâîêðóæèòåëüíûì óñïåõîì! Âû âåäü íå áóäåòå ñïîðèòü ñ òåì, ÷òî Âû äîñòîéíû áîëüøîãî óñïåõà è áîëüøîãî áîãàòñòâà? È ïîýòîìó Âàì æèçíåííî íåîáõîäèìî ñäåëàòü ýòîò øàã íà âñòðå÷ó ê ôèíàíñîâîé íåçàâèñèìîñòè, ê êîòîðîé ïðèâåäåò Âàñ ñîòðóäíè÷åñòâî ñ ñóïåðïðîãðàììîé 6Õ6! Ïîòîìó ÷òî âàøå âðåìÿ íàñòàëî!<br>&nbsp;<tr><td height=40><tr><td><font face="verdana" size=+1><center><b>"Ïàðà ñëîâ î ñèñòåìå..." - èíòåðâüþ ñ îñíîâàòåëåì áèçíåñ ñèñòåìû 6Õ6, Òèùåíêîâûì È.À.<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td bgcolor=#ffffcc><p><div align=justify><font face=verdana size=2><font color=#000066><br><b>- Ââèäó ñòðåìèòåëüíûõ òåìïîâ ðàçâèòèÿ ñåòè Èíòåðíåò è ýëåêòðîííîé êîììåðöèè ÷èñëî ïîëüçîâàòåëåé "âñåìèðíîé ïàóòèíû" ðàñòåò ñ ìîëíèåíîñíîé áûñòðîòîé. Óæå ñåé÷àñ òîëüêî â Ðîññèè ê ñåòè Èíòåðíåò åæåäíåâíî ïîäêëþ÷àþòñÿ áîëåå 2000 ÷åëîâåê, íà Çàïàäå è â ÑØÀ ýòà öèôðà â íåñêîëüêî ðàç áîëüøå. Ñ ðîñòîì ÷èñëà ïîëüçîâàòåëåé Èíòåðíåò ðàñòåò è êîëè÷åñòâî ðàçëè÷íîãî òèïà áèçíåñ ïðîãðàìì. Ñ êàæäûì äíåì îíè ïîëüçóþòñÿ âñå áîëüøåé ïîïóëÿðíîñòüþ è ýòî åñòåñòâåííî, âåäü ýëåêòðîííàÿ êîììåðöèÿ - áèçíåñ 21 âåêà. Íî áèçíåñ ñèñòåìà 6Õ6 ïðåâîñõîäèò âñå îñòàëüíûå íà íåñêîëüêî ïîðÿäêîâ - îá ýòîì ìîæíî ñóäèòü ãëÿäÿ íà òî êàêîé óñïåõ îíà ïðèíîñèò âñåì åå êîìïàíüîíàì. È âñå æå â ÷åì åå ïðåèìóùåñòâî íàä äðóãèìè áèçíåñ ïðîãðàììàìè àíàëîãè÷íîãî òèïà, ïî÷åìó îíà ïðèíîñèò óñïåõ âñåì åå ó÷àñòíèêàì, à íå òîëüêî åå îñíîâàòåëþ è òåì êòî "ñòîèò ó èñòîêîâ"?</font></b><p>- Äà, Âû ñîâåðøåííî ïðàâû íàñ÷åò ñòðåìèòåëüíîãî ðàçâèòèÿ ýëåêòðîííîé êîììåðöèè è ïîÿâëåíèÿ áîëüøîãî êîëè÷åñòâà áèçíåñ ñèñòåì àíàëîãè÷íûõ 6Õ6.<p>Ïðåæäå ÷åì ðàçðàáîòàòü ïðîãðàììó 6Õ6 ÿ âíèìàòåëüíî èçó÷èë âñå ñóùåñòâóþùèå íà äàííûé ìîìåíò ñèñòåìû è ïîíÿë êàê îíè ïîÿâèëèñü. Íàâåðíîå âñå ïîìíÿò òå îáëèãàöèè, êîòîðûå áûëè òàê ïîïóëÿðíû ó íàñ â 90-å ãîäû. Òàê âîò ñ ðàçâèòèåì Èíòåðíåò êòî-òî äàëåêèé îò êîìïüþòåðíûõ òåõíîëîãèé è çíàíèé ïðèíöèïà ðàáîòû "âñåìèðíîé ïàóòèíû" ïðîñòî ïåðåíåñ ýòó ïðîãðàììó ñ îáëèãàöèÿìè â ñåòü. Äà, èäåÿ ãåíèàëüíà, îñîáåííî äëÿ òåõ âðåìåí - òàê Âû âðÿä ëè íàéäåòå è 5 êëèåíòîâ, â ñåòè æå ìîæíî ðàññûëàòü òûñÿ÷è ðåêëàìíûõ ïèñåì. Íî ýòà ñèñòåìà èìåëà ìíîæåñòâî íåäîñòàòêîâ: íåäîêóìåíòèðîâàííîñòü òîãî, êàê ðàññûëàòü áîëüøîå êîëè÷åñòâî ðåêëàìû, ãäå áðàòü òûñÿ÷è àäðåñîâ ýëåêòðîííîé ïî÷òû è ò.ä. Ñàìûì ãëàâíûì íåäîñòàòêîì áûëî òî, ÷òî ýòà ïðîãðàììà áûëà ðàññ÷èòàíà íà ñëèøêîì ÷åñòíûõ ëþäåé.  ðåêëàìíîì ïèñüìå ñîäåðæàëàñü ôîðìà, àíàëîãè÷íàÿ íàøåé áèçíåñ-òàáëèöå, ñîãëàñíî êîòîðîé âñòóïàâøèå â ñèñòåìó äîëæíû áûëè ïîêóïàòü òîâàðíûå åäèíèöû ñèñòåìû (êàæäóþ ó ðàçíîãî ó÷àñòíèêà). Êóïèâ èõ îíè äîëæíû áûëè ñòàâèòü ñâîè ðåêâèçèòû íàïðîòèâ ïåðâîé òîâàðíîé åäèíèöû, à âñåõ îñòàëüíûõ ñäâèãàòü íà îäèí óðîâåíü íèæå. Òàê êàê èõ íèêòî íå êîíòðîëèðîâàë â èõ âîëå áûëî èçìåíÿòü òàáëèöó êàê óãîäíî. Îíè îòêðûâàëè íåñêîëüêî àáîíåíòíûõ ÿùèêîâ íà ðàçëè÷íûå èìåíà â ðàçíûõ ïî÷òîâûõ îòäåëåíèÿõ ãîðîäà è ñòàâèëè ðåêâèçèòû ýòèõ ò.í. "ìåðòâûõ äóø" â òàáëèöó âìåñòî ïðåäûäóùèõ ó÷àñòíèêîâ, ò.å. ñèñòåìà îáðûâàëàñü. Èç-çà ýòîãî îíà ðàáîòàëà òîëüêî íà 100% íà ïåðâîì óðîâíå, 1% - íà âòîðîì, 0,1% - íà òðåòüåì è 0% - íà ÷åòâåðòîì. Ïðàêòè÷åñêè çàðàáîòîê øåë òîëüêî ñ ïåðâîãî óðîâíÿ, ò.å. ñ ïðÿìûõ ïðîäàæ, ÷òî ïðè ðàññûëêå 3.000 ðåêëàìíûõ ïèñåì â äåíü ñîñòàâëÿëî îêîëî $300 - $400 â ìåñÿö. Íî ñóòü áèçíåñ ñèñòåì òàêîãî òèïà - ïðèíîñèòü ìàêñèìóì ïðèáûëè çà ñ÷åò 2-õ ïîñëåäíèõ óðîâíåé. Ò.å. Âû ðàññûëàåòå ïàðòèþ ïèñåì ñ ðåêëàìîé, íàïðèìåð, 10.000 øò., ïîëó÷àåòå 30 çàêàçîâ íà òîâàðíóþ åäèíèöó ïåðâîãî óðîâíÿ è äàëüøå â òå÷åíèå íåñêîëüêèõ ëåò ñèñòåìà ðàáîòàåò íà Âàñ. Íî ìíîãèõ óñòðàèâàëè ýòè $300 - $400 â ìåñÿö, è îíè ðàññûëàëè ïî 3.000 ïèñåì â äåíü, îòêðûâ íåñêîëüêî àáîíåíòíûõ ÿùèêîâ è ïîñòàâèâ ñâîè ðåêâèçèòû âåçäå, ãäå òîëüêî ìîæíî. Òàê êàê òîâàðíûå åäèíèöû ïî ñâîåé ñóòè íè÷åãî íå ñîäåðæàëè, êðîìå íàçâàíèÿ â ðåêëàìíîì ïèñüìå, òî ïîëó÷àëîñü, ÷òî ðàáîòàÿ ñ òàêîé ñèñòåìîé Âû, êî âñåìó ïðî÷åìó, åùå è îáìàíûâàëè ñâîèõ êëèåíòîâ.<p>Íàâåðíîå, íåò ñìûñëà îïèñûâàòü âñå îñòàëüíûå àíàëîãè÷íîãî òèïà áèçíåñ ñèñòåìû - ò.ê. îíè â áóêâàëüíîì ñìûñëå ÿâëÿþòñÿ êîïèÿìè ïðåäûäóùåé. Äà, èìåííî òàê îíè è ïîÿâèëèñü - êîïèðîâàëàñü ñóòü è èçìåíÿëèñü âòîðîñòåïåííûå ôàêòîðû, òàêèå êàê, íàçâàíèÿ òîâàðíûõ åäèíèö, ñïîñîáû îïëàòû, ñîäåðæàíèå ðåêëàìíîãî ïèñüìà è ò.ä. Î íèõ âñåõ ìîæíî ñêàçàòü îäíî: âñå îíè "ñîçäàíû" (åñëè ìîæíî ïðèìåíèòü ýòî ñëîâî ê ÷èñòîé âîäû ïëàãèàòó) íåïðîôåññèîíàëàìè, ëþäüìè äàëåêèìè êàê îò áèçíåñà âîîáùå (÷òî òàêîå ýëåêòðîííàÿ êîììåðöèÿ - îíè è ïîíÿòèÿ íå èìåþò!), òàê è îò êîìïüþòåðíûõ òåõíîëîãèé è ñåòè Èíòåðíåò. Íî ñàìà èäåÿ ñîçäàòü òàêîãî ðîäà áèçíåñ ñèñòåìó - ãåíèàëüíà. Îñîáåííî â íàøå âðåìÿ - âðåìÿ áóðíîãî ðàçâèòèÿ ñåòè Èíòåðíåò è ýëåêòðîííîé êîììåðöèè. È åñëè èñêëþ÷èòü íåäîñòàòêè, òî òàêîé ñèñòåìå öåíû íåò! Âû òîëüêî ïðåäñòàâüòå ñåáå ÷åì áóäåò Èíòåðíåò õîòÿ áû ëåò ÷åðåç ïÿòü!<p>È ïóñòü çàäà÷à áûëà íåëåãêîé, âñå æå ìíå óäàëîñü ðàçðàáîòàòü èìåííî òàêóþ áèçíåñ ñèñòåìó.<p><font color=#000066>Íåäîêóìåíòèðîâàííîñòü òîãî ãäå è êàê íàõîäèòü àäðåñà ýëåêòðîííîé ïî÷òû, êàê íà íèõ ðàññûëàòü îãðîìíîå êîëè÷åñòâî ðåêëàìíûõ ïèñåì è ïðî÷èå òåõíè÷åñêèå äåòàëè ÿ êîìïåíñèðîâàë ñïåöèàëüíî ðàçðàáîòàííûìè ïðîãðàììàìè äëÿ àâòîìàòèçàöèè ýòîãî ïðîöåññà, ïîçâîëèâøèìè ðàññûëàòü 5-20 òûñÿ÷ ðåêëàìíûõ ïèñåì â äåíü, çàòðàòèâ âñåãî 30-40 ìèíóò ñîáñòâåííîãî âðåìåíè, íàèïîäðîáíåéøèì îïèñàíèåì ðàáîòû ñ íèìè, íàïèñàííûì ÿçûêîì ïîíÿòíûì äëÿ ïîëüçîâàòåëÿ ëþáîãî óðîâíÿ è áîëüøèì êîëè÷åñòâîì ñîâåòîâ è ðåêîìåíäàöèé. ×åì ïî ñóòè óáèë ñðàçó äâóõ çàéöåâ: çíà÷èòåëüíî ïîâûñèë ïðîèçâîäèòåëüíîñòü áèçíåñ ñèñòåìû è ñäåëàë òîâàðíûå åäèíèöû íå òî ÷òî ïîëåçíûìè - ïðîñòî íåîáõîäèìûìè äëÿ ó÷àñòíèêà áèçíåñ ñèñòåìû (âïðî÷åì, êàê è äëÿ ëþáîãî çàíèìàþùåãîñÿ ðåêëàìîé â ñåòè Èíòåðíåò), ò.ê. èìåííî îíè ñîäåðæàò ñïåöèàëüíûå ïðîãðàììû è îïèñàíèå ðàáîòû ñ íèìè.<p>Íå÷åñòíîñòü ó÷àñòíèêîâ ïðåñåê îáÿçàòåëüíîé ðåãèñòðàöèåé â ãëàâíîé êîíòîðå 6X6 MLM Corporation (ïîäðîáíåå â ðàçäåëå "Çàùèòà îò îáìàíà").<p>Ò.ê. ñèñòåìà íå îáðûâàåòñÿ, äîáàâèë åùå 2 óðîâíÿ, ò.å. âñåãî â ñèñòåìå 6 óðîâíåé (ïî $6 çà òîâàðíóþ åäèíèöó êàæäîãî óðîâíÿ - îòñþäà è íàçâàíèå "6X6").<p>Ñäåëàë áîëåå ãèáêîé ñèñòåìó îïëàòû çàêàçîâ. Òåïåðü òîâàðíûå åäèíèöû ìîæíî îïëà÷èâàòü êàê "òðàäèöèîííûì" çàêàçíûì àâèàïèñüìîì, òàê è ïåðåâîäîì íà áàíêîâñêèé ñ÷åò. Íî çàïðåòèë óêàçûâàòü â êà÷åñòâå àäðåñà äëÿ îïëàòû àáîíåíòíûå ÿùèêè - âî-ïåðâûõ, äëÿ èçáåæàíèÿ îáìàíà, âî-âòîðûõ, ÷òîáû áèçíåñ ñèñòåìà íå òåðÿëà ñâîåé ïðèâëåêàòåëüíîñòè. Èñõîäÿ èç òàêèõ æå ñîîáðàæåíèé, çàïðåòèë ñèñòåìó îïëàòû WebMoney.<p>Çàêëþ÷èë äîãîâîð ñ iWin Loto Ltd. Òàê ÷òî ïðè ðåãèñòðàöèè â íàøåé ãëàâíîé êîíòîðå Âû àâòîìàòè÷åñêè âêëþ÷àåòåñü â ëîòåðåþ, ïðè÷åì Âàøè øàíñû âûèãðàòü ïðÿìî ïðîïîðöèîíàëüíû êîëè÷åñòâó ïðîäàííûõ Chapter#1.<br>&nbsp;<tr><td height=60><tr><td><font face="verdana" size=+1><center><b>Îòçûâû íàøèõ êîìïàíüîíîâ<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td><p align=justify><font face=verdana size=2><br>Âñåì ïðèâåò! Ñïåøó ïîäåëèòüñÿ ñ Âàìè âïå÷àòëåíèåì îò ïðîãðàììû 6Õ6, ÷òîáû Âû, íå äàé Áîã, íå ïðîøëè ìèìî. Ïèñüìî ïðèøëî íà e-mail ìîåìó ìóæó. Îí ðåøèë ïîâåñåëèòü ìåíÿ è ïîçâàë ïî÷èòàòü, “êàêóþ ëàïøó ñåé÷àñ íà óøè âåøàþò”. ß íå îñîáî âíèêëà â ñèñòåìó, äà îñîáî è íå ñòàðàëàñü ÷òî-òî ïîíÿòü, ïîòîìó ÷òî íå âåðèëà â òàêîãî ðîäà ñïîñîáû çàðàáîòêà, ò.å. íå çàõîòåëà çàðàáîòàòü 100.000 äîëëàðîâ. Íî, ê ìîåìó ñ÷àñòüþ, ýòà öèôðà âñå êðóòèëàñü â ìîåì ìîçãó è íå äàâàëà ñïàòü. È âñå-òàêè, â êîíöå êîíöîâ, ÿ ðåøèëà îòâàæíî áðîñèòüñÿ íà ïèñüìî. Ê ñ÷àñòüþ, ìóæ åãî åùå íå ñòåð. Ê ñâîåìó óäèâëåíèþ, ÷èòàÿ 2-é ðàç, ÿ âñå ïîíèìàëà. À ñàìîå ãëàâíîå, ÷òî ÿ óÿñíèëà, ýòî òî, ÷òî íàïðÿãàòüñÿ-òî ïî÷òè íå íàäî! È âðåìåíè è äåíåæåê ñâîèõ òîæå ïî÷òè òðàòèòü íå íàäî. Ê òîìó æå ìåíÿ, êàê è Âàñ, ïðèâëåêëî òî, ÷òî âñå äåëàåò êîìïüòåð è ÷òî íå íóæíî íè÷åìó ó÷èòüñÿ, ò.ê. àëãîðèòì ðàáîòû ïîäðîáíî îïèñàí â Chapter`àõ!  îáùåì, ðåøèëà ÿ, áûëà – íå áûëà. Ïîïðîáóþ! Çà äâå íåäåëè ÿ ðàçîñëàëà îêîëî 30.000 ïèñåì è ðåøèëà, ÷òî ñ ìåíÿ õâàòèò. ×åðåç íåñêîëüêî äíåé ñòàëè ïðèõîäèòü çàêàçû – ïðèøåë 31 çàêàç íà 1-óþ ÷àñòü è $186 äî êîíöà ìåñÿöà. “Íó, - äóìàþ, - ïîøëî äåëî”.  òå÷åíèå ñëåäóþùèõ äâóõ ìåñÿöåâ ïðèõîäèëè åùå çàêàçû íà 1 ÷àñòü è ïðèøëî îêîëî 5.000 çàêàçîâ íà 2,3,4 è 5 ÷àñòè è $30.000! ÎÃÎ! Ìåñÿö ñïóñòÿ ó ìåíÿ áûëî óæå áîëåå $110.000! Íó, à ïîòîì ñòàëî ñîâñåì êëàññíî – ê íûíåøíåìó ìîìåíòó äåíüãè ïðîäîëæàþò ïðèáûâàòü, à ó ìåíÿ îäíà ïðîáëåìà – êóäà áû èõ äåòü?! ß äóìàþ, ôàíòàçèÿ ó Âàñ ðàáîòàåò, è Âû ìîæåòå ñåáå ïðåäñòàâèòü, ñêîëüêî óäîâîëüñòâèé ìîæíî äîñòàâëÿòü ñåáå, èìåÿ òàêèå äåíüãè!</p><p align=right><font face=verdana size=2>Âàëåíòèíà, ã. Ìîñêâà.<tr><td height=40><tr><td bgcolor=#000066>&nbsp;<tr><td><p align=justify><font face=verdana size=2><br>Çäðàâñòâóéòå, óâàæàåìûå ãîñïîäà è äàìû! Íå òàê äàâíî – ïîëãîäà íàçàä ÿ, òàê æå êàê è Âû, ñèäåë è ÷èòàë ïèñüìî, ïðèøåäøåå íà ìîé e-mail. È, êàê áîëüøèíñòâî èç Âàñ, ÿ òåðçàëñÿ ñîìíåíèÿìè. Õîòÿ, åñëè ïîñìîòðåòü òðåçâî – íåïîíÿòíî ïî÷åìó. Âèäíî, òàê ïðèâûê ÷åëîâåê, âñåãî áîÿòüñÿ è ñòðàøèòüñÿ. Äà, âåëèêè áûëè ãëàçà ó ìîåãî ñòðàõà, íî ÿ ðåøèë ïîïðîáîâàòü. Âåäü â ñàìîì óæàñíîì ñëó÷àå ÿ íè÷åãî íå ïîòåðÿþ, êðîìå íåñêîëüêèõ ÷àñîâ âðåìåíè, êîòîðîå è òàê ó ìåíÿ òðàòèòüñÿ áåññìûñëåííî, à òîëüêî óçíàþ ïîáîëüøå î ðàáîòå êîìïüþòåðà è åãî îïòèìèçàöèè. Ê òîìó æå ÿ ïîäóìàë, ÷òî õîòü îäíîãî ÷åëîâåêà ÿ òî÷íî íàéäó, ÷òîáû âåðíóòü ñâîè $6 çà ïåðâóþ ÷àñòü. Íå áóäó óòîìëÿòü Âàñ ïîäðîáíîñòÿìè. ß ïðîñòî ÷åòêî è äîñêîíàëüíî âûïîëíÿë âñå ïðàâèëà áèçíåñ ñèñòåìû 6Õ6. È â òå÷åíèå 4-õ ìåñÿöåâ ÿ çàðàáîòàë 120.000 äîëëàðîâ! È ýòî â ìîè 25 ëåò! Òåïåðü ÿ áóäó êîëëåêöèîíèðîâàòü ïðîèçâåäåíèÿ èñêóññòâà! Îá ýòîì âñåãäà ÿ ìå÷òàë. Íó à ñåé÷àñ ÿ åäó, íå ñìåéòåñü, íà Ìàëüîðêó â ñâàäåáíîå ïóòåøåñòâèå ñ ëþáèìîé, êîòîðàÿ íå óñòîÿëà ïåðåä ìîèì áîãàòñòâîì. Òåïåðü – âñÿ æèçíü âïåðåäè! Êðàñèâàÿ è ñ÷àñòëèâàÿ, â áîãàòñòâå è ðîñêîøè ñ 6Õ6!!!</p><p align=right><font face=verdana size=2>Àëåêñàíäð, ã. Ñàíêò-Ïåòåðáóðã.<tr><td height=40><tr><td bgcolor=#000066>&nbsp;<tr><td><p align=justify><font face=verdana size=2><br> ïåðâûé ðàç ÿ êîíêðåòíî ñòîðìîçèë, óäàëèâ ïèñüìî î ïðîãðàììå 6Õ6. ß åùå ïîñìåÿëñÿ íàä òåì, ÷òî êòî-òî âäðóã ñòàíåò ìíå ñëàòü äåíüãè. È êàê æå ÿ ïðîêëèíàë ñâîþ íåäîâåð÷èâîñòü, êîãäà ïîçâîíèë áðàò èç Íîâîðîññèéñêà è ðàññêàçàë ìíå êàê ðàç îá ýòîì áèçíåñå è î òîì, êàêàÿ ýòî êëàññíàÿ øòóêà! Êàêîé ÿ äóðàê! Âåäü ÿ æå ñàì ìå÷òàë ñòàòü áîãàòûì, êàê æå åùå ÿ ìîãó áûñòðî ðàçáîãàòåòü, åñëè íå ñ ïîìîùüþ âîò òàêîãî áèçíåñà? È êîãäà ÷åðåç ìåñÿö ïèñüìî ñíîâà íàøëî ìåíÿ, ÿ óæå áûë óìíåå. Òóò æå âçÿëñÿ çà äåëî è ðàçîñëàë îêîëî 70 òûñÿ÷ ïèñåì ïî ýëåêòðîííîé ïî÷òå. Îòêëèê áûë ïî÷òè ìãíîâåííûì (åñòü åùå óìíûå ëþäè íà ñâåòå!). À îò Chapter`îâ ñ îïèñàíèåì ÿ âîîáùå îáàëäåë, îñîáåííî îò ïîñëåäíåãî! Ìàëî òîãî ÷òî ÿ ñðàçó ïîíÿë êàê ðàáîòàòü ñ ñèñòåìîé, òåïåðü – ìîé Celeron 300 ðàáîòàåò áûñòðåå, ÷åì Celeron 466 ìîåãî äðóãà! Ýòî óäèâèòåëüíî – òðàòèøü íå áîëüøå ïîëó÷àñà â äåíü íà ðàáîòó ñ 6Õ6 è ïîëó÷àåøü òàêèå äåíüãè!!! Êîðî÷å, äàëüøå âñå ïîøëî êàê ïî ìàñëó. Åæåäíåâíî ïî÷òàëüîí ïðèíîñèë ïî 10 - 15 êîíâåðòîâ, â êàæäîì èç êîòîðûõ ïî $6! Yes-s! Ýòà øòóêà çàðàáîòàëà!!! À ÿ åùå íå âåðèë! Âîò, áëèí, ïåíü! Ïðàâ áûë áðàòåëëà! À ÷òî íà÷àëîñü ïîòîì! Êîãäà ÿ ñòàë ïðîäàâàòü 2 ÷àñòü, êàæäûé äåíü ìíå ïðèíîñèëè ïî 20-30 êîíâåðòîâ ñ êóïþðàìè. Íó, à êîãäà ÿ çàíÿëñÿ 3, 4, 5 è 6 ÷àñòÿìè, ÿ ïðîñòî íå çíàë êóäà îò íèõ äåâàòüñÿ! Íà ïðîøëîé íåäåëå ÿ êóïèë ñåáå íîâûé “Lincoln Navigator”. Êëàññíûé äæèï! Âñåãäà ìå÷òàë î òàêîì!  êàêîì áû äóðíîì íàñòðîåíèè ÿ íè ïðîñíóëñÿ óòðîì, ñòîèò ìíå âñïîìíèòü î ìîåì ñâåðêàþùåì íà ñîëíöå äæèïå, ÿ íà÷èíàþ ÷óâñòâîâàòü ñåáÿ ñàìûì ñ÷àñòëèâûì ÷åëîâåêîì íà Ñâåòå! È âñå – áëàãîäàðÿ ñóïåðïðîãðàììå 6Õ6!!! Ïèøó ýòî ñ íàäåæäîé, ÷òî ìîé óðîê íåâåðèÿ ïîéäåò Âàì íà ïîëüçó, è âû íå ñòàíåòå, êàê ÿ â ïåðâûé ðàç, óäàëÿòü èç ñâîåãî êîìïüþòåðà ýòî ïèñüìî, êîòîðîå èìååò ïðèÿòíîå ñâîéñòâî ïðåâðàùàòüñÿ â íåîãðàíè÷åííîå êîëè÷åñòâî äåíåã! Óäà÷è Âàì!</p><p align=right><font face=verdana size=2>Èãîðü, ã. Âîëãîãðàä.<tr><td height=40><tr><td bgcolor=#000066>&nbsp;<tr><td><p align=justify><font face=verdana size=2><br>ß ñðàçó ñåðäöåì îùóòèëà, ÷òî ýòî ìîé øàíñ! Íàêîíåö-òî èñïîëíèòñÿ çàâåòíàÿ ìå÷òà ìîåãî äåòñòâà – ñúåçäèòü â Àìåðèêó! ß ñ óäîâîëüñòâèåì ïðèíÿëàñü ó÷àñòâîâàòü â ïðîãðàììå 6Õ6. Íî ïî íà÷àëó ñîìíåâàëàñü, óäàñòüñÿ ëè ìíå íàéòè òàê ìíîãî àäðåñîâ e-mail. Îäíàêî, êîãäà ïðèøëè Chapter`û ñ îïèñàíèåì, òî âìåñòå ñ íèìè ïðèøëî îáúÿñíåíèå, êàê ëåãêî, áåç âñÿêèõ ïðîáëåì ìîæíî íàéòè ñêîëüêî óãîäíî àäðåñîâ ýëåêòðîííîé ïî÷òû. Çà ìåñÿö ÿ ðàçîñëàëà áîëåå 150.000 ïèñåì, è ýôôåêò íå çàñòàâèë ñåáÿ äîëãî æäàòü – ÿ ïîëó÷èëà 68 çàêàçîâ íà ïåðâóþ ãëàâó!  êîíöå êîíöîâ, ÿ çàðàáîòàëà 170 òûñÿ÷ äîëëàðîâ!!! Òåïåðü ÿ, ïîæàëóé, ïåðåáåðóñü â Àìåðèêó íà ñîâñåì. Ñáûëàñü ìîÿ ãîëóáàÿ ìå÷òà! Ñïàñèáî, äîðîãàÿ 6Õ6! À åùå ñïàñèáî çà óäèâèòåëüíîå îïèñàíèå ðàáîòû ñ ñèñòåìîé. Æåëàþ âñåì Âàì ñòàòü òàêèìè æå ñ÷àñòëèâûìè, êàê è ÿ, áëàãîäàðÿ ñóïåðïðîãðàììå 6Õ6!</p><p align=right><font face=verdana size=2>Ìàðèíà, ã. Ðèãà.<tr><td height=50><tr><td><font face=verdana size=2><b>Æäåì Âàøèõ îòçûâîâ. Ïðèñûëàéòå èõ íà àäðåñ ãëàâíîé êîíòîðû.<tr><td height=50><tr><td><font face="verdana" size=+1><center><b>×ÒÎ ÆÅ ÒÀÊÎÅ 6Õ6?<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td bgcolor=#ffffcc><p><div align=justify><font face=verdana size=2><br>Èòàê, çàðàáàòûâàòü êó÷è äåíåã, íå âûõîäÿ èç äîìà! “Âîò ýòî øàíñ!”, – âîñêëèêíèòå Âû, îñîçíàâ, ÷òî íèêóäà íå íóæíî õîäèòü, íèêîãî íå íóæíî óãîâàðèâàòü, à òîëüêî çíàé ñåáå – ïîñûëàé e-mail`û è ïîëó÷àé ïðèáûëü! “À ÷òî æå äëÿ ýòîãî íóæíî äåëàòü?” – íåèçáåæåí âîïðîñ. Äëÿ òîãî, ÷òîá çàðàáîòàòü êó÷ó äåíåã, à èìåííî – 100.000 äîëëàðîâ è áîëåå, äëÿ íà÷àëà Âàì íóæíî áóäåò çàðåãèñòðèðîâàòüñÿ â ãëàâíîé êîíòîðå 6Õ6 MLM Corporation è ïîëó÷èòü ñâîé ëè÷íûé ðåãèñòðàöèîííûé íîìåð. Âñòóïèâ â 6Õ6, Âû ñòàíîâèòåñü ðàñïðîñòðàíèòåëåì ïî Èíòåðíåòó Chapter`îâ (ãëàâ) ñ íàèïîäðîáíåéøèì îïèñàíèåì ðàáîòû ñ áèçíåñ ñèñòåìîé 6Õ6 è îïòèìèçàöèè êîìïüþòåðà (ïîäðîáíåå î íèõ â ñëåäóþùåì ðàçäåëå). Êëèåíòàìè Âàøåãî áèçíåñà ñòàíîâÿòñÿ ëþäè, êîòîðûõ ýòè ãëàâû çàèíòåðåñóþò. À ãëàâû ïðîñòî íå ìîãóò íå çàèíòåðåñîâàòü - îíè ñîäåðæàò óíèêàëüíóþ èíôîðìàöèþ, ïðîñòî íåîáõîäèìóþ äëÿ ëþáîãî, êòî õî÷åò äîáèòüñÿ óñïåõà â ñåòåâîì ìàðêåòèíãå! Êðîìå òîãî, ëþäåé çàèíòåðåñóåò ñàì áèçíåñ, è âñå ýòî ÿâëÿåòñÿ ãàðàíòèåé òîãî, ÷òî ëþäè íåïðåìåííî áóäóò îòêëèêàòüñÿ íà Âàøå ïèñüìî. ×òî ýòî çà ïèñüìî? Ýòî – òî ñàìîå ïèñüìî, êîòîðîå Âû ïîëó÷èòå ïîñëå ðåãèñòðàöèè â ãëàâíîé êîíòîðå 6Õ6 MLM Corporation (îòëè÷àåòñÿ îò ïèñüìà, êîòîðîå Âû ñåé÷àñ ÷èòàåòå, ïðèñóòñòâèåì Âàøåãî ðåãèñòðàöèîííîãî íîìåðà â áèçíåñ-òàáëèöå). Âû ïðîñòî îòïðàâëÿåòå åãî êàê ìîæíî áîëüøåìó êîëè÷åñòâó ëþäåé. Ïîäðîáíåå î òîì, êàê íàéòè áåñêîíå÷íîå êîëè÷åñòâî e-mail`îâ, àâòîìàòè÷åñêè ðàçîñëàòü íà íèõ ðåêëàìíîå ïèñüìî è ìíîãîå äðóãîå Âû óçíàåòå íåïîñðåäñòâåííî â ñàìèõ ãëàâàõ. Åñëè Âû äóìàåòå: “Îòêóäà âîçüìåòñÿ òàê ìíîãî àäðåñîâ?”, òî ýòî íå ñòîèò òîãî, ÷òîáû áåñïîêîèòüñÿ. Åæåäíåâíî òîëüêî â Ðîññèè ê Èíòåðíåòó ïîäêëþ÷àþòñÿ ìèíèìóì 2000 íîâûõ ïîëüçîâàòåëåé!!! Íà âñåõ õâàòèò! Ïîñëå òîãî êàê Âû îòïðàâèòå çàÿâêó íà ðåãèñòðàöèþ, Âàì ïðèéäåò ïèñüìî, ñîäåðæàùåå:<blockquote><blockquote><p>1) Âàø ðåãèñòðàöèîííûé íîìåð,<p>2) Ðåêëàìíîå ïèñüìî ñ Âàøèì ðåãèñòðàöèîííûì íîìåðîì â áèçíåñ-òàáëèöå, êîòîðîå Âû áóäåòå ðàññûëàòü,<p>3) Ðåêâèçèòû îñòàëüíûõ ó÷àñòíèêîâ áèçíåñ ñèñòåìû 6Õ6, ó êîòîðûõ Âàì íåîáõîäèìî çàêàçàòü Chapter`û, êàæäûé ó ðàçíîãî (èñêëþ÷åíèå ñîñòàâëÿåò òîëüêî ìàñòåð) â ñîîòâåòñòâèè ñ ðàñøèôðîâàííîé áèçíåñ-òàáëèöåé, ÷òîáû Âû ñàìè èìåëè âîçìîæíîñòü ïðîäàâàòü èõ ñâîèì çàêàç÷èêàì.</blockquote></blockquote><p>Âìåñòå ñ ýòèì Âû ïîëó÷èòå òàêæå è äàëüíåéøèå óêàçàíèÿ ïðîãðàììû 6Õ6. Íó à òî, ÷òî Âàì íóæíî áóäåò ñäåëàòü ñðàçó ñåé÷àñ, îïèñàíî íèæå â âèäå ÷åòêîãî àëãîðèòìà, ïîýòîìó ïîêà ïðîñòî óëîâèòå ñóòü. Èòàê, Âû îáëàäàåòå âñåìè ãëàâàìè è ðàññûëàåòå ïèñüìî, â êîòîðîì â êà÷åñòâå ðåêëàìû ñîäåðæèòñÿ ïðåäèñëîâèå ê ýòèì óäèâèòåëüíûì ãëàâàì. Ïðî÷èòàâ åãî, ÷åëîâåê, ïîëó÷èâøèé îò Âàñ ïèñüìî, íåïðåìåííî çàõî÷åò âñòóïèòü â áèçíåñ ñèñòåìó 6Õ6 è ïðî÷èòàòü âñå ãëàâû. Íî äàæå åñëè âäðóã îí íå çàõî÷åò ÷èòàòü Chapter`û, îí íàâåðíÿêà çàèíòåðåñóåòñÿ óíèêàëüíîé âîçìîæíîñòüþ çàðàáîòàòü ìèëëèîíû ïðàêòè÷åñêè áåç âñÿêèõ çàòðàò, êàê ïî äåíüãàì, òàê è ïî âðåìåíè! Ñîãëàñèòåñü, îò ýòîãî ïðîñòî íåâîçìîæíî îòêàçàòüñÿ! Ïðèìåðíî ÷åðåç 2 íåäåëè ñî äíÿ íà÷àëà ðàññûëêè Âû ïîëó÷èòå çàêàçû íà ïåðâóþ ãëàâó è ïëàòó çà íåå (â ðàçìåðå 6 äîëëàðîâ ÑØÀ) îò 30-òè ÷åëîâåê è áîëåå. Òàêèì îáðàçîì, Âàø ïåðâûé äîõîä ñîñòàâèò ìèíèìóì – $180. È ýòî – òîëüêî íà÷àëî! Ïðè ðåãèñòðàöèè Âû áóäåòå àâòîìàòè÷åñêè âêëþ÷åíû â ëîòåðåþ îò iWin Loto - îäíîé èç ñàìûõ ïîïóëÿðíûõ íà Çàïàäå è â ÑØÀ êîìïàíèé çàíèìàþùèõñÿ ëîòî-áèçíåñîì, ãëàâíûé ïðèç êîòîðîé - $5.000.000 (òàêæå ðàçûãðûâàåòñÿ 5 ïðèçîâ ïî $1.000.000, 100 ïðèçîâ ïî $100.000 è áîëåå 5 òûñÿ÷ ôèðìåííûõ ôóòáîëîê îò 6Õ6 MLM Corporation, ðîçûãðûøè ïðîâîäÿòñÿ êàæäûé ìåñÿö) – ÷åì áîëüøå Âû ïîëó÷èòå çàêàçîâ íà Chapter#1, òåì áîëüøå øàíñîâ âûèãðàòü ãëàâíûé ïðèç. Âû âèäèòå?!!! Âñå, ÷òî îò Âàñ òðåáóåòñÿ, ýòî ðàçîñëàòü ïîáîëüøå ðåêëàìíûõ ïèñåì. Âñÿ Âàøà ðàáîòà áóäåò çàêëþ÷àòüñÿ òîëüêî â òîì, ÷òîáû âðåìÿ îò âðåìåíè ïðîâåðÿòü ñâîé ïî÷òîâûé ÿùèê èëè õîäèòü â áàíê çà íàëè÷íûìè è äîìà, â òèøèíå ïîäñ÷èòûâàòü âñå íàðàñòàþùóþ ïðèáûëü! Ãàðàíòîì Âàøåãî ãîëîâîêðóæèòåëüíîãî óñïåõà è íàäåæíûì ñîþçíèêîì ñòàíîâèòñÿ ñàìàÿ ãðàíäèîçíàÿ â ìèðå êîìïüþòåðíàÿ ñóïåðïðîãðàììà 6Õ6!!!<br>&nbsp;<tr><td height=40><tr><td><font face="verdana" size=+1><center><b>CHAPTER`Û<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td bgcolor=#ffffcc><p><div align=justify><font face=verdana size=2><br>Chapter`û (èëè ãëàâû) – ýòî ïîäðîáíåéøåå îïèñàíèå áèçíåñ ñèñòåìû 6Õ6, ñîâåòû î òîì êàê îïòèìàëüíî ðàáîòàòü ñ ñèñòåìîé è íàñòðîèòü äëÿ ýòîãî ñâîé êîìïüþòåð. Ïðî÷èòàâ èõ Âû ïîéìåòå êàê íå ïðèëàãàÿ îñîáûõ óñèëèé óëó÷øèòü ñâÿçü ñ Èíòåðíåò, íàõîäèòü ïî 5-20 òûñ. e-mail`îâ â äåíü, îáðàáàòûâàòü èõ, ðàññûëàòü ïî 5-20 ðåêëàìíûõ ïèñåì â äåíü, ïîâûñèòü ïðîèçâîäèòåëüíîñòü ñâîåãî êîìïüþòåðà íà 50% è ìíîãîå äðóãîå.<p>Chapter`û íàïèñàíû ÿçûêîì ïîíÿòíûì äëÿ ïîëüçîâàòåëÿ ëþáîãî óðîâíÿ, ïîýòîìó äëÿ ðàáîòû ñ áèçíåñ ñèñòåìîé 6Õ6 Âàì íå íóæíî áûòü ïðîãðàììèñòîì èëè èìåòü îïûò ðàáîòû ñ êîìïüþòåðîì. Áîëåå òîãî, åñëè Âû òîëüêî â÷åðà ñåëè çà êîìïüþòåð è âîîáùå íå çíàåòå íè÷åãî î ðàáîòå ñ íèì, òî ïðî÷èòàâ âíèìàòåëüíî ãëàâû è ïîðàáîòàâ íåêîòîðîå âðåìÿ ñ áèçíåñ ñèñòåìîé 6Õ6 Âû âñêîðå ñòàíåòå ïðîäâèíóòûì ïîëüçîâàòåëåì, çíàþùèì âñå îá îïåðàöèîííîé ñèñòåìå Windows è Èíòåðíåòå. Êðîìå òîãî ê êàæäîé ãëàâå ïðèëàãàåòñÿ ïðîãðàììà äëÿ ðàáîòû ñ ñèñòåìîé 6Õ6 è íåêîòîðîå êîëè÷åñòâî e-mail`îâ.<blockquote><blockquote><blockquote><p><b>Ñïèñîê Chapter`îâ:</b></blockquote><p><b>Chapter#1</b> “Ââåäåíèå â áèçíåñ ñèñòåìó 6Õ6. Îïòèìèçàöèÿ èíòåðíåò ñîåäèíåíèÿ. Ðàöèîíàëüíîå èñïîëüçîâàíèå èíòåðíåò âðåìåíè.”<p><i>+20.000 e-mail àäðåñîâ<br>+ïðîãðàììà äëÿ ïîääåðæêè ñòàáèëüíîãî ñîåäèíåíèÿ ñ Èíòåðíåò, àâòîìàòè÷åñêîãî âîññòàíîâëåíèÿ ñâÿçè ïðè åå îáðûâàõ, äîçâîíå/ðàçðûâå ñâÿçè â çàäàííîå âðåìÿ è çàïóñêå äîïîëíèòåëüíûõ ïðîãðàì ïðè íà÷àëå ñîåäèíåíèÿ è ðàçðûâàõ ñâÿçè/ïåðåçâîíàõ, è ïîëíîå îïèñàíèå ðàáîòû ñ ïðîãðàììîé.</i><p><b>Chapter#2</b> “Êàê íàõîäèòü 5-20 òûñÿ÷ e-mail àäðåñîâ â äåíü, ñèäÿ çà êîìïüþòåðîì 30-40 ìèíóò.”<p><i>+10.000 e-mail àäðåñîâ<br>+ïðîãðàììà äëÿ àâòîìàòè÷åñêîãî âêëþ÷åíèÿ/âûêëþ÷åíèÿ ïðîãðàììû äëÿ ïîèñêà e-mail`îâ ïðè ñîåäèíåíèè/ðàçðûâå ñâÿçè ñ Èíòåðíåò, ïîäðîáíî îïèñàííàÿ â ïðåäûäóùåé ãëàâå.</i><p><b>Chapter#3</b> “Êàê îáðàáàòûâàòü íàéäåííûå e-mail àäðåñà.”<p><i>+10.000 e-mail àäðåñîâ<br>+ïðîãðàììà äëÿ àâòîìàòè÷åñêîãî ïîèñêà e-mail àäðåñîâ, ïîäðîáíî îïèñàííàÿ â ïðåäûäóùåé ãëàâå.</i><p><b>Chapter#4</b> “Êàê ðàññûëàòü ïî 5-20 òûñÿ÷ ðåêëàìíûõ ïèñåì â äåíü, ñèäÿ çà êîìïüþòåðîì âñå òå æå 30-40 ìèíóò.”<p><i>+10.000 e-mail àäðåñîâ<br>+ïðîãðàììà äëÿ áûñòðîé îáðàáîòêè e-mail àäðåñîâ, ïîäðîáíî îïèñàííàÿ â ïðåäûäóùåé ãëàâå.</i><p><b>Chapter#5</b> “Àëãîðèòì ðàáîòû, èëè êàê íàèáîëåå ýôôåêòèâíî èñïîëüçîâàòü áèçíåñ ñèñòåìó 6Õ6.”<p><i>+80.000 e-mail àäðåñîâ (!)<br>+ïðîãðàììà äëÿ àâòîìàòè÷åñêîé ðàññûëêè îãðîìíîãî êîëè÷åñòâà ðåêëàìíûõ ïèñåì ñ âëîæåíèÿìè, ïîäðîáíî îïèñàííàÿ â ïðåäûäóùåé ãëàâå.</i><p><b>Chapter#6</b> “Îïòèìèçèðóåì Âàø êîìïüþòåð, ïîâûøàåì åãî ïðîèçâîäèòåëüíîñòü íà 50%, èëè êàê çàñòàâèòü Pentium 166 ðàáîòàòü êàê Pentium II-300.”<p><i>+100.000 e-mail àäðåñîâ (!)<br>+Ñåðâåðíàÿ ÷àñòü ïðîãðàììû äëÿ àâòîìàòè÷åñêîé ðàññûëêè îãðîìíîãî êîëè÷åñòâà ðåêëàìíûõ ïèñåì ñ âëîæåíèÿìè, ïîäðîáíî îïèñàííàÿ â 4-îé ãëàâå.</blockquote></blockquote><tr><td height=40><tr><td><font face="verdana" size=+1><center><b>ÏÐÀÂÈËÀ Ó×ÀÑÒÈß Â ÏÐÎÃÐÀÌÌÅ 6Õ6<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td><p><font face=verdana size=2><br><blockquote><blockquote><blockquote><b>Òåðìèíû:</b></blockquote></blockquote><p><b>Ìàñòåð</b> – Òèùåíêîâ Èãîðü Àëåêñàíäðîâè÷, îñíîâàòåëü áèçíåñ ñèñòåìû;<p><b>ðåôåðåð</b> – ó÷àñòíèê 6Õ6, îò êîòîðîãî Âû ïîëó÷èëè ýòî ïèñüìî è ó êîòîðîãî Âû äîëæíû çàêàçàòü Chapter;<p><b>êëèåíò</b> – õîçÿèí e-mail, íà êîòîðûé Âû îòïðàâëÿåòå ïèñüìî;<p><b>ðåôåðàë</b> – ó÷àñòíèê 6Õ6, êîòîðûé çàêàçàë ó Âàñ Chapter.</blockquote><tr><td height=30><tr><td><font face="verdana" size=+1><center><b>Êàê ðàáîòàåò áèçíåñ ñèñòåìà 6Õ6<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td bgcolor=#ffffcc><p><div align=justify><font face=verdana size=2><br>Äëÿ òîãî, ÷òîáû çàðàáàòûâàòü íå òîëüêî ñ ïðÿìûõ ïðîäàæ (ò.å. êîãäà Âû ñàìè ïðîäàåòå Chapter#1 ñâîè ðåôåðàëàì), íî è ñ ïðîäàæ ñâîèõ ðåôåðàëîâ (ò.å. êîãäà Âàøè ðåôåðàëû ïðèâîäÿò Âàì ïîêóïàòåëåé íà Chapter#2 - Chapter#6) áûëà ðàçðàáîòàíà ñëåäóþùàÿ ñèñòåìà – â ðåêëàìíîì ïèñüìå ñîäåðæèòñÿ òàêàÿ òàáëèöà (ò.í. áèçíåñ-òàáëèöà):<blockquote><blockquote><blockquote><p>Chapter#1...............ðåôåðåð ¹1<br>Chapter#2...............ðåôåðåð ¹2<br>Chapter#3...............ðåôåðåð ¹3<br>Chapter#4...............ðåôåðåð ¹4<br>Chapter#5...............ðåôåðåð ¹5<br>Chapter#6...............ðåôåðåð ¹6</blockquote></blockquote><p>Íàïðîòèâ êàæäîãî Chapter`à ñòîÿò ðåêâèçèòû ðàçíûõ ëþäåé, ò.å. Âû áóäåòå ïîêóïàòü Chapter#1 ó ðåôåðåðà ¹1, Chapter#2 ó ðåôåðåðà ¹2, Chapter#3 ó ðåôåðåðà ¹3, Chapter#4 ó ðåôåðåðà ¹4, Chapter#5 ó ðåôåðåðà ¹5, Chapter#6 ó ðåôåðåðà ¹6. Çàðåãèñòðèðîâàâøèñü Âû ïîëó÷èòå ðåêëàìíîå ïèñüìî ñ áèçíåñ-òàáëèöåé, èçìåíåííîé ñëåäóþùèì îáðàçîì:<blockquote><blockquote><p>Chapter#1...............Âû<br>Chapter#2...............ðåôåðåð ¹1<br>Chapter#3...............ðåôåðåð ¹2<br>Chapter#4...............ðåôåðåð ¹3<br>Chapter#5...............ðåôåðåð ¹4<br>Chapter#6...............ðåôåðåð ¹5</blockquote></blockquote><p>È íà÷íåòå ðàññûëàòü ðåêëàìíîå ïèñüìî ñ òàêîé áèçíåñ-òàáëèöåé. Ò.å. Âàøè ðåôåðàëû áóäóò ïîêóïàòü ó Âàñ Chapter#1, ó ðåôåðåðà ¹1 – Chapter#2, ó ðåôåðåðà ¹2 – Chapter#3, ó ðåôåðåðà ¹3 – Chapter#4, ó ðåôåðåðà ¹4 – Chapter#5, ó ðåôåðåðà ¹5 – Chapter#6. Âàøè ðåôåðàëû ¹1 (òå, êòî êóïÿò ó Âàñ Chapter#1) ïðè ðåãèñòðàöèè ïîëó÷àò ðåêëàìíîå ïèñüìî ñ àíàëîãè÷íî ïðåîáðàçîâàííîé áèçíåñ-òàáëèöåé:<blockquote><blockquote><p>Chapter#1...............ðåôåðàë ¹1<br>Chapter#2...............Âû<br>Chapter#3...............ðåôåðåð ¹1<br>Chapter#4...............ðåôåðåð ¹2<br>Chapter#5...............ðåôåðåð ¹3<br>Chapter#6...............ðåôåðåð ¹4</blockquote></blockquote><p>È íà÷íóò ðàññûëàòü ðåêëàìíîå ïèñüìî ñ òàêîé áèçíåñ-òàáëèöåé. Ò.å. èõ ðåôåðàëû ¹1 (Âàøè ðåôåðàëû ¹2) áóäóò ïîêóïàòü Chapter#1 ó íèõ (Âàøèõ ðåôåðàëîâ ¹1), Chapter#2 – ó Âàñ, Chapter#3 – ó ðåôåðåðà ¹1, Chapter#4 – ó ðåôåðåðà ¹2, Chapter#5 – ó ðåôåðåðà ¹3, Chapter#6 – ó ðåôåðåðà ¹4. È ò.ä...<p><font color=#000066>Ò.å. òàêèì âîò îáðàçîì Âàøè ðåôåðàëû, ïðèâëåêàÿ ñåáå êëèåíòîâ íà Chapter#1 áóäóò îäíîâðåìåííî ïðèâëåêàòü Âàì êëèåíòîâ íà Chapter#2 - Chapter#6. Îòñþäà ñëåäóåò, ÷òî ïðÿìîé çàäà÷åé êàæäîãî ó÷àñòíèêà áèçíåñ ñèñòåìû 6Õ6 ÿâëÿåòñÿ ïðèâëå÷åíèå ïîêóïàòåëåé íà Chapter#1 – ðåôåðàëîâ ¹1.<p>Òåïåðü äàâàéòå ïðîñòî ïðèêèíåì, ñêîëüêî äåíåã Âû çàðàáîòàåòå åñëè êàæäûé ó÷àñòíèê ïðèâëå÷åò ïî 10 ðåôåðàëîâ ¹1:<blockquote><p><div align=left><font color=red>Âû...........................10 Õ $6 = $60<br>Âàøè ðåôåðàëû ¹1...10 X 10 X $6 = $600<br>Âàøè ðåôåðàëû ¹2...10 X 10 X 10 X $6 = $6.000<br>Âàøè ðåôåðàëû ¹3...10 X 10 X 10 X 10 X $6 = $60.000<br>Âàøè ðåôåðàëû ¹4...10 X 10 X 10 X 10 X 10 X $6 = $600.000<br>Âàøè ðåôåðàëû ¹5...10 X 10 X 10 X 10 X 10 X 10 X $6 = $6.000.0000<p><b>Ò.å. âñåãî Âû çàðàáîòàåòå $6.666.660!</b></blockquote><p><font color=#000066>Öèôðà íå ìàëàÿ è âîçìîæíî ïîýòîìó ó Âàñ âîçíèêíóò ñîìíåíèÿ. - Âíèêíèòå â ðàññ÷åòû è â ñóòü ðàáîòû ñèñòåìû, ïðîñ÷èòàéòå âñå ñàìè è Âû ïîëó÷èòå òîò æå ðåçóëüòàò!</blockquote><tr><td height=40><tr><td><font face="verdana" size=+1><center><b>Çàùèòà îò îáìàíà<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td bgcolor=#ffffcc><p><div align=justify><font face=verdana size=2><br>Äëÿ òîãî, ÷òîáû èñêëþ÷èòü îáðûâàåìîñòü ñèñòåìû áûëà ðàçðàáîòàíà ñëåäóþùàÿ çàùèòà:<blockquote><p> ðåêëàìíîå ïèñüìî ïîìåùàåòñÿ òàêàÿ áèçíåñ-òàáëèöà:<blockquote><p>Chapter#1...............ðåãèñòð. íîìåð ðåôåðåðà ¹1<br>Chapter#2...............ðåãèñòð. íîìåð ðåôåðåðà ¹2<br>Chapter#3...............ðåãèñòð. íîìåð ðåôåðåðà ¹3<br>Chapter#4...............ðåãèñòð. íîìåð ðåôåðåðà ¹4<br>Chapter#5...............ðåãèñòð. íîìåð ðåôåðåðà ¹5<br>Chapter#6...............ðåãèñòð. íîìåð ðåôåðåðà ¹6</blockquote><p>Ò.å. êëèåíò ê êîòîðîìó ïðèøëî ýòî ðåêëàìíîå ïèñüìî çíàåò òîëüêî ðåãèñòðàöèîííûå íîìåðà ðåôåðåðîâ ó êîòîðûõ îí äîëæåí êóïèòü Chapter`û. Êóïèòü âñå Chapter`û ó íèõ íàïðÿìóþ â äàííûé ìîìåíò îí íå ìîæåò òàê êàê íå çíàåò èõ ðåêâèçèòîâ.<p>Äàëåå îí ðåãèñòðèðóåòñÿ â ãëàâíîé êîíòîðå 6Õ6 MLM Corporation è ïîëó÷àåò:<blockquote><p>1) Câîé ðåãèñòðàöèîííûé íîìåð.<p>2) Àäðåñà âñåõ ðåôåðåðîâ, ó êîòîðûõ äîëæåí êóïèòü Chapter#1 - Chapter#6.<p>3) Ðåêëàìíîå ïèñüìî äëÿ ðàññûëêè ñ èçìåíåííîé áèçíåñ-òàáëèöåé ñëåäóþùåãî âèäà:<p>Chapter#1...............ðåãèñòð. íîìåð äàííîãî êëèåíòà<br>Chapter#2...............ðåãèñòð. íîìåð ðåôåðåðà ¹1<br>Chapter#3...............ðåãèñòð. íîìåð ðåôåðåðà ¹2<br>Chapter#4...............ðåãèñòð. íîìåð ðåôåðåðà ¹3<br>Chapter#5...............ðåãèñòð. íîìåð ðåôåðåðà ¹4<br>Chapter#6...............ðåãèñòð. íîìåð ðåôåðåðà ¹5</blockquote><p>ïîêóïàåò âñå Chapter`û è íà÷èíàåò ðàññûëêó.</blockquote><p><font color=#000066>Áëàãîäàðÿ ýòîé çàùèòå, îí ïðîñòî íå ìîæåò îáîðâàòü öåïü è îñòàâèòü ñâîèõ ðåôåðåðîâ áåç ïðè÷èòàþùåéñÿ èì ïðèáûëè. Âåäü öåïü ìîæåò îáîðâàòüñÿ òîëüêî òîãäà, êîãäà èõ ðåêâèçèòîâ íå áóäåò â áèçíåñ-òàáëèöå. ×òî âîçìîæíî, òîëüêî åñëè îí çàìåíèò ðåêâèçèòû âñåõ ïÿòè ðåôåðåðîâ ñâîèìè ðåêâèçèòàìè. ×åãî îí ñäåëàòü ïðîñòî íå ìîæåò, ò.ê. äëÿ ýòîãî åìó ïðèäåòñÿ çàðåãèñòðèðîâàòüñÿ åùå ïÿòü ðàç, òîãäà êàê ðåãèñòðèðîâàòüñÿ ìîæíî òîëüêî îäèí ðàç.<br>&nbsp;<tr><td height=60><tr><td><font face="verdana" size=+1><center><b>ÂÛ ÃÎÒÎÂÛ ÍÀ×ÀÒÜ ÁÈÇÍÅÑ Ñ 6Õ6?!<br>ÈÒÀÊ, ÏÐÈÑÒÓÏÀÅÌ!<br>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td bgcolor=#ffffcc><p><font face=verdana size=2 color=red><br><blockquote><b>Âíèìàíèå!  ñâÿçè ñ îãðîìíûì ïðèòîêîì ðåôåðàëîâ ñ 1/IX-2000 ðåãèñòðàöèÿ ñòàëà ïëàòíîé è ñòîèò 5 äîëëàðîâ ÑØÀ.</b><font color=#000066><blockquote><blockquote><p><font color=#000066><b>×ÒÎ ÂÀÌ ÍÅÎÁÕÎÄÈÌÎ ÑÄÅËÀÒÜ:</b></blockquote></blockquote><p><b>à) Çàðåãèñòðèðóéòåñü â ãëàâíîé êîíòîðå 6Õ6 MLM Corporation:</b><p>1) Íàïèøèòå íà ëèñòå áóìàãè (<font color=red><b>àíãëèéñêèìè áóêâàìè</b></font>):<blockquote><p>1) Âàøè Ô.È.Î.,<br>2) Ïî÷òîâûé àäðåñ äëÿ îïëàòû,<br>3) Áàíêîâñêèå ðåêâèçèòû äëÿ îïëàòû <i>(íåîáÿçàòåëüíî)</i>,<br>4) Âàø e-mail - ïèøèòå ðàçáîð÷èâî è â äàëüíåéøåì èñïîëüçóéòå åãî òîëüêî äëÿ ñâÿçè ñ ãëàâíîé êîíòîðîé 6Õ6,<br>5) Íàõîäÿùóþñÿ íèæå áèçíåñ-òàáëèöó â ðåãèñòðàöèîííî-íîìåðíîì âèäå,<br>6) Äàòó îòïðàâëåíèÿ ïèñüìà.</blockquote><p>2) Âëîæèòå â íåãî $5 è îòïðàâüòå ïî ïî÷òå <b>çàêàçíûì àâèàïèñüìîì</b> íà àäðåñ ãëàâíîé êîíòîðû 6x6 MLM Corporation:<blockquote><p><b>Igor Tichtchenkov, Laanemere 20-96, 13913 Tallinn, Estonia.</b></blockquote><p>3)  òå÷åíèå íåäåëè Âàì ïðèéäåò (íà e-mail, êîòîðûé Âû óêàçàëè â ðåãèñòðàöèîííîé ôîðìå) ïèñüìî, ñîäåðæàùåå:<blockquote><p>1) Âàø ðåãèñòðàöèîííûé íîìåð.<br>2) Àäðåñà âñåõ ðåôåðåðîâ, ó êîòîðûõ Âû äîëæíû êóïèòü Chapter`û.<br>3) Ðåêëàìíîå ïèñüìî ñ èçìåíåííîé áèçíåñ-òàáëèöåé, ñîäåðæàùåé Âàø ðåãèñòðàöèîííûé íîìåð, êîòîðîå Âû áóäåòå ðàññûëàòü.<br>4) Íåîáõîäèìûå äëÿ íà÷àëà ðàáîòû èíñòðóêöèè.</blockquote><p><b>á) Ñðàçó êóïèòå Chapter`û â ñîîòâåòñòâèè ñ áèçíåñ-òàáëèöåé:</b><p><center><table width="60%" border="1" cellspacing="0" cellpadding="0"><tr><td><center><b><font face=verdana color="#000066">Ãëàâà ¹</td><td><center><b><font face=verdana color="#000066">Ðåã. ¹ Ðåôåðåðà<tr><td><center><font face=verdana color="#000066">Chapter#1</td><td><center><b><font face=verdana color="#FF0000"> 6x6-000002-z-302<tr><td><center><font face=verdana color="#000066">Chapter#2</td><td><center><b><font face=verdana color="#FF0000">6x6-000002-z-115<tr><td><center><font face=verdana color="#000066">Chapter#3</td><td><center><b><font face=verdana color="#FF0000">6x6-000000-z-001<tr><td><center><font face=verdana color="#000066">Chapter#4</td><td><center><b><font face=verdana color="#FF0000">Master 6x6<tr><td><center><font face=verdana color="#000066">Chapter#5</td><td><center><b><font face=verdana color="#FF0000">Master 6x6<tr><td><center><font face=verdana color="#000066">Chapter#6</td><td><center><b><font face=verdana color="#FF0000">Master 6x6</table></center><font color=red><p align=justify><b>ÏÐÈÌÅ×ÀÍÈÅ! Åñëè â áèçíåñ-òàáëèöå íåñêîëüêî èëè äàæå âñå ðåãèòðàöèîííûå íîìåðà - Master 6x6, òî íèêàêîé îøèáêè â ýòîì íåò, ïðîñòî Âàì ïîâåçëî ò.ê. ïðèñîåäèíèâøèñü Âû áóäåòå â ñàìîì íà÷àëå áèçíåñ ñèñòåìû - ò.å. Âàøè øàíñû íà óñïåõ ìàêñèìàëüíû.</blockquote><tr><td height=40><tr><td><div align=justify><font face=verdana size=2>Êàê òîëüêî Âû ýòî ñäåëàåòå ñðàçó íà÷èíàéòå ðàññûëêó. Ïîäðîáíåå îá ýòîì Âû óçíàåòå íåïîñðåäñòâåííî èç Chapter`îâ. Âñåãî Âàì æåëàòåëüíî ïðèâëå÷ü îêîëî 30 ðåôåðàëîâ ¹1 - ò.å. ïðîäàòü 30 Chapter#1. Õîòÿ ÷åì áîëüøå Âû èõ ïðèâëå÷åòå, òåì áîëüøå ïðèáûëè ïîëó÷èòå.<p>Ïîñòàðàéòåñü ðàññûëàòü íå ìåíåå 3.000 ðåêëàìíûõ ïèñåì â äåíü (ñî ñïåöèàëüíûìè ïðîãðàììàìè, êîòîðûå Âû ïîëó÷èòå âìåñòå ñ Chapter`àìè, íå ñîñòàâèò òðóäà ðàññûëàòü è ïî 20.000 ïèñåì â äåíü). Åñëè ìîæåòå áîëüøå, ðàññûëàéòå áîëüøå (ïîäðîáíåå â Chapter#5).<p>Î äàëüíåéøèõ øàãàõ Âû óçíàåòå â Chapter`àõ. Âåñü ïðîöåññ ðàñòÿãèâàåòñÿ ïðèìåðíî íà 4 ìåñÿöà ñî äíÿ íà÷àëà áèçíåñà. Åñëè Âû áóäåòå ÷åòêî ñëåäîâàòü âñåì ïðàâèëàì, òî âíå âñÿêèõ ñîìíåíèé áóäåòå îáëàäàòåëåì íåñêîëüêèõ ñîòåí òûñÿ÷ äîëëàðîâ! Ìû çíàåì, ÷òî ýòî áóäåò èìåííî òàê, è íàì îñòàåòñÿ òîëüêî ïîçäðàâèòü Âàñ!<tr><td height=60><tr><td><font face="verdana" size=+1><center><b>À òåïåðü çà äåëî!<p><font color=#000066 size=5><b>Æåëàåì Âàì îãðîìíûõ óñïåõîâ!!!<tr><td height=40><tr><td bgcolor=#ffffcc>&nbsp;<tr><td bgcolor=#000066>&nbsp;<tr><td><br><center><font face="verdana" size="1" color="#555555">Copyright © 2001 6x6 MLM Corporation. All rights reserved.</font></table></table></center></body></html>



From noreply@sourceforge.net  Fri Jan  4 02:50:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 03 Jan 2002 18:50:05 -0800
Subject: [Patches] [ python-Patches-462754 ] no '_d' ending for mingw32
Message-ID: <E16MKQn-0001Mr-00@usw-sf-web1.sourceforge.net>

Patches item #462754, was opened at 2001-09-18 20:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462754&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Häring (ghaering)
Assigned to: Nobody/Anonymous (nobody)
Summary: no '_d' ending for mingw32

Initial Comment:
This patch prevents distutils from naming the extension
modules <extname>_d.pyd when compiled with mingw32 on
Windows in debug mode. Instead, the extension modules
will get the normal name <extname>.pyd. Technically,
the patch doesn't prevent the behaviour for mingw32,
but only adds the _d for MS Visual C++ and Borland
compilers (though I don't know about the Borland case).

The reason for this? Adding "_d" doesn't make any sense
for GNU compilers. I think it's just a MS Visual C++
madness. If you want to debug an extension module that
was compiled with gcc, you have to use gdb anyway,
because the debugging symbols of MSVC++ and gcc are
incompatible. So you normally use a release Python
version (from the python.org binary download) and
compile your extensions with mingw32.

To put it shortly:

The current state is that you do a
"setup.py build --compiler=mingw32 --debug" and then
rename the extension modules, removing the _d. Then
fire up gdb to debug your module.

With this patch, the renaming isn't necessary anymore.

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

>Comment By: Gerhard Häring (ghaering)
Date: 2002-01-03 18:50

Message:
Logged In: YES 
user_id=163326

mingw links with msvcrt.dll. I've plans to add mingw32
support to the autoconf build process (hopefully soon enough
for 2.3).

The GNU and MS debugger symbols are incompatible, though, so
I think that mingw32 shouldn't link to the debug version of
msrcrt (gdb doesn't understand the Microsoft debugger
symbols; and the Visual Studio debugger has no idea what the
debugging symbols of gcc are all about; isn't cross-platform
and cross-compiler programming fun?).


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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-30 05:13

Message:
Logged In: YES 
user_id=21627

How does the mingw port interact with the debugging
libraries? With MSVC, the debug build will link to the debug
versions of the CRT. What C library will mingw link with (I
hope it won't use crtdll.dll)?

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

Comment By: Gerhard Häring (ghaering)
Date: 2001-09-28 14:28

Message:
Logged In: YES 
user_id=163326

Yes. But mingw32 isn't emulating Unix under Windows (that
would be Cygwin). It's just a version of gcc and friends
that targets native win32. It links against msvcrt (not a
Posix emulation library like Cygwin does).

This is a bit hypothetical because I didn't yet hack the
autoconf build process for native win32 with mingw32.

Currently, you cannot build a complete Python with mingw32,
but you *can* build extension modules against an existing
Python (compiled with M$ VC++).

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

Comment By: Tim Peters (tim_one)
Date: 2001-09-28 13:43

Message:
Logged In: YES 
user_id=31435

All else being equal, a system emulating Unix under Windows 
should strive to make life comfortable for Unix folks.  The 
question is thus whether all else is in fact equal <wink -- 
but I don't know, as I don't yet use the system under 
discussion>.

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

Comment By: Gerhard Häring (ghaering)
Date: 2001-09-28 11:37

Message:
Logged In: YES 
user_id=163326

Hmm. I don't like the _d endings at all. But if the policy
on win32 is that debug executables and libraries get a "_d"
ending, then I'm unsure wether this patch should be applied.

I have plans to hack the autoconf madness to build a native
win32 Python with mingw32. But that won't be ready by
tomorror. And I don't think that I'll add "_d" endings there
for debugging, because that would be inconsistent with the
normal autoconf builds on Unix.

I'm glad that *I* don't have to decide wether this patch is
a Good Thing. Being consistent with Python win32 build or
with GNU (gcc/autoconf). Take your pick :-)


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

Comment By: Tim Peters (tim_one)
Date: 2001-09-18 20:46

Message:
Logged In: YES 
user_id=31435

FYI, MSVC never adds _d on its own -- Mark Hammond and/or 
Guido forced it to do that.  I don't remember why, but one 
of them explained it to me long ago and it made good sense 
at the time <wink>.

MSCV normally compiles debug and release builds into 
distinct subdirectories, and uses the same names in both.  
But *our* MSVC setup forces it to compile both flavors of 
build directly into the PCbuild directory, so has to give 
the resulting DLLs and executables different names (else 
the second build would overwrite the results of the first 
build).

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462754&group_id=5470


From noreply@sourceforge.net  Fri Jan  4 04:06:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 03 Jan 2002 20:06:39 -0800
Subject: [Patches] [ python-Patches-499062 ] Minor typo in test_generators.py
Message-ID: <E16MLct-0002Ey-00@usw-sf-web1.sourceforge.net>

Patches item #499062, was opened at 2002-01-03 10:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499062&group_id=5470

Category: Tests
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Uche Ogbuji (uche)
Assigned to: Tim Peters (tim_one)
Summary: Minor typo in test_generators.py

Initial Comment:
This one caused me a bit of confusion.  Traditionally
"leaves" refer to tree nodes with no children.

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

>Comment By: Uche Ogbuji (uche)
Date: 2002-01-03 20:06

Message:
Logged In: YES 
user_id=38966

No more argument.  s/leaves/labels it is.  Thanks.

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

Comment By: Tim Peters (tim_one)
Date: 2002-01-03 16:35

Message:
Logged In: YES 
user_id=31435

Yes, I think "leaf" == "no kids" is universally accepted.

I don't like changing it to plain "nodes", though, because 
the example code does not generate the nodes, it generates 
only the node labels -- someone confused by the misuse 
of "leaves" here is also likely to be confused by the 
misuse of "nodes" -- and I'm going to reduce the priority 
of this patch every time you argue back <wink>.

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

Comment By: Uche Ogbuji (uche)
Date: 2002-01-03 16:23

Message:
Logged In: YES 
user_id=38966

It's s/leaves/nodes/.  Maybe I've been working with DOM too
much.  At any rate, I have always thought of leaf nodes as
only those with no children.

It doesn't look as if anything from my patch made it
through: neither the comment nor the patch.  Sometimes I
hate SF.

I'll try again, though it hardly seems necessary...


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

Comment By: Tim Peters (tim_one)
Date: 2002-01-03 16:18

Message:
Logged In: YES 
user_id=31435

Assigned to me; added a "Tests" category and recategorized 
accordingly.

Uche, if you tried to upload a patch, it didn't work (did 
you remember to check the upload box)?  What is that you 
want to see changed?  s/leaves/labels/?  Note that the 
example in the docstring test is lifted directly out of PEP 
255, so tell me what would shut you up <wink> and I'll make 
the change in both places.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499062&group_id=5470


From noreply@sourceforge.net  Fri Jan  4 11:52:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 Jan 2002 03:52:07 -0800
Subject: [Patches] [ python-Patches-462754 ] no '_d' ending for mingw32
Message-ID: <E16MStL-0007pt-00@usw-sf-web1.sourceforge.net>

Patches item #462754, was opened at 2001-09-18 20:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462754&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Häring (ghaering)
Assigned to: Nobody/Anonymous (nobody)
Summary: no '_d' ending for mingw32

Initial Comment:
This patch prevents distutils from naming the extension
modules <extname>_d.pyd when compiled with mingw32 on
Windows in debug mode. Instead, the extension modules
will get the normal name <extname>.pyd. Technically,
the patch doesn't prevent the behaviour for mingw32,
but only adds the _d for MS Visual C++ and Borland
compilers (though I don't know about the Borland case).

The reason for this? Adding "_d" doesn't make any sense
for GNU compilers. I think it's just a MS Visual C++
madness. If you want to debug an extension module that
was compiled with gcc, you have to use gdb anyway,
because the debugging symbols of MSVC++ and gcc are
incompatible. So you normally use a release Python
version (from the python.org binary download) and
compile your extensions with mingw32.

To put it shortly:

The current state is that you do a
"setup.py build --compiler=mingw32 --debug" and then
rename the extension modules, removing the _d. Then
fire up gdb to debug your module.

With this patch, the renaming isn't necessary anymore.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-04 03:52

Message:
Logged In: YES 
user_id=21627

The rationale for using the debugging version of MSVCRT are
not the debugging information alone, but also the additional
functionalities, like heap consistency checks and other
assertions. So it is not obvious that you do not want to use
the debugging version of this library in a debug build.

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

Comment By: Gerhard Häring (ghaering)
Date: 2002-01-03 18:50

Message:
Logged In: YES 
user_id=163326

mingw links with msvcrt.dll. I've plans to add mingw32
support to the autoconf build process (hopefully soon enough
for 2.3).

The GNU and MS debugger symbols are incompatible, though, so
I think that mingw32 shouldn't link to the debug version of
msrcrt (gdb doesn't understand the Microsoft debugger
symbols; and the Visual Studio debugger has no idea what the
debugging symbols of gcc are all about; isn't cross-platform
and cross-compiler programming fun?).


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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-30 05:13

Message:
Logged In: YES 
user_id=21627

How does the mingw port interact with the debugging
libraries? With MSVC, the debug build will link to the debug
versions of the CRT. What C library will mingw link with (I
hope it won't use crtdll.dll)?

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

Comment By: Gerhard Häring (ghaering)
Date: 2001-09-28 14:28

Message:
Logged In: YES 
user_id=163326

Yes. But mingw32 isn't emulating Unix under Windows (that
would be Cygwin). It's just a version of gcc and friends
that targets native win32. It links against msvcrt (not a
Posix emulation library like Cygwin does).

This is a bit hypothetical because I didn't yet hack the
autoconf build process for native win32 with mingw32.

Currently, you cannot build a complete Python with mingw32,
but you *can* build extension modules against an existing
Python (compiled with M$ VC++).

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

Comment By: Tim Peters (tim_one)
Date: 2001-09-28 13:43

Message:
Logged In: YES 
user_id=31435

All else being equal, a system emulating Unix under Windows 
should strive to make life comfortable for Unix folks.  The 
question is thus whether all else is in fact equal <wink -- 
but I don't know, as I don't yet use the system under 
discussion>.

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

Comment By: Gerhard Häring (ghaering)
Date: 2001-09-28 11:37

Message:
Logged In: YES 
user_id=163326

Hmm. I don't like the _d endings at all. But if the policy
on win32 is that debug executables and libraries get a "_d"
ending, then I'm unsure wether this patch should be applied.

I have plans to hack the autoconf madness to build a native
win32 Python with mingw32. But that won't be ready by
tomorror. And I don't think that I'll add "_d" endings there
for debugging, because that would be inconsistent with the
normal autoconf builds on Unix.

I'm glad that *I* don't have to decide wether this patch is
a Good Thing. Being consistent with Python win32 build or
with GNU (gcc/autoconf). Take your pick :-)


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

Comment By: Tim Peters (tim_one)
Date: 2001-09-18 20:46

Message:
Logged In: YES 
user_id=31435

FYI, MSVC never adds _d on its own -- Mark Hammond and/or 
Guido forced it to do that.  I don't remember why, but one 
of them explained it to me long ago and it made good sense 
at the time <wink>.

MSCV normally compiles debug and release builds into 
distinct subdirectories, and uses the same names in both.  
But *our* MSVC setup forces it to compile both flavors of 
build directly into the PCbuild directory, so has to give 
the resulting DLLs and executables different names (else 
the second build would overwrite the results of the first 
build).

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462754&group_id=5470


From noreply@sourceforge.net  Fri Jan  4 18:22:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 Jan 2002 10:22:00 -0800
Subject: [Patches] [ python-Patches-499513 ] robotparser.py fails on some URLs
Message-ID: <E16MYye-0000pM-00@usw-sf-web3.sourceforge.net>

Patches item #499513, was opened at 2002-01-04 10:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499513&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bastian Kleineidam (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: robotparser.py fails on some URLs

Initial Comment:
I am using Python 2.1.1.

The URL http://www.chaosreigns.com/robots.txt results
in an empty RobotParser object.
Reason is that the file object returned from the
URLOpener does not have a readlines() attribute.

I patched the robotparser.py to use readline() instead
of readlines().
Furthermore I removed the unnecessary redirection limit
code which is already in FancyURLopener.


Greetings, Bastian


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499513&group_id=5470


From noreply@sourceforge.net  Fri Jan  4 18:49:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 Jan 2002 10:49:45 -0800
Subject: [Patches] [ python-Patches-499513 ] robotparser.py fails on some URLs
Message-ID: <E16MZPV-0001Ba-00@usw-sf-web3.sourceforge.net>

Patches item #499513, was opened at 2002-01-04 10:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499513&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bastian Kleineidam (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: robotparser.py fails on some URLs

Initial Comment:
I am using Python 2.1.1.

The URL http://www.chaosreigns.com/robots.txt results
in an empty RobotParser object.
Reason is that the file object returned from the
URLOpener does not have a readlines() attribute.

I patched the robotparser.py to use readline() instead
of readlines().
Furthermore I removed the unnecessary redirection limit
code which is already in FancyURLopener.


Greetings, Bastian


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-04 10:49

Message:
Logged In: YES 
user_id=6380

I'll gladly apply your patch.

Would you mind to also supply a patch for the copyright
statement?
It says "Python 2.0 open source license" but that's no
longer the current license. How about the PSF license
agreement for Python 2.2?


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499513&group_id=5470


From noreply@sourceforge.net  Fri Jan  4 18:50:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 Jan 2002 10:50:00 -0800
Subject: [Patches] [ python-Patches-499513 ] robotparser.py fails on some URLs
Message-ID: <E16MZPk-0001CE-00@usw-sf-web3.sourceforge.net>

Patches item #499513, was opened at 2002-01-04 10:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499513&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bastian Kleineidam (calvin)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: robotparser.py fails on some URLs

Initial Comment:
I am using Python 2.1.1.

The URL http://www.chaosreigns.com/robots.txt results
in an empty RobotParser object.
Reason is that the file object returned from the
URLOpener does not have a readlines() attribute.

I patched the robotparser.py to use readline() instead
of readlines().
Furthermore I removed the unnecessary redirection limit
code which is already in FancyURLopener.


Greetings, Bastian


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-04 10:49

Message:
Logged In: YES 
user_id=6380

I'll gladly apply your patch.

Would you mind to also supply a patch for the copyright
statement?
It says "Python 2.0 open source license" but that's no
longer the current license. How about the PSF license
agreement for Python 2.2?


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499513&group_id=5470


From noreply@sourceforge.net  Fri Jan  4 19:02:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 Jan 2002 11:02:11 -0800
Subject: [Patches] [ python-Patches-499513 ] robotparser.py fails on some URLs
Message-ID: <E16MZbX-00055n-00@usw-sf-web1.sourceforge.net>

Patches item #499513, was opened at 2002-01-04 10:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499513&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bastian Kleineidam (calvin)
Assigned to: Guido van Rossum (gvanrossum)
Summary: robotparser.py fails on some URLs

Initial Comment:
I am using Python 2.1.1.

The URL http://www.chaosreigns.com/robots.txt results
in an empty RobotParser object.
Reason is that the file object returned from the
URLOpener does not have a readlines() attribute.

I patched the robotparser.py to use readline() instead
of readlines().
Furthermore I removed the unnecessary redirection limit
code which is already in FancyURLopener.


Greetings, Bastian


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

>Comment By: Bastian Kleineidam (calvin)
Date: 2002-01-04 11:02

Message:
Logged In: YES 
user_id=9205

Updated patch with copyright

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-04 10:49

Message:
Logged In: YES 
user_id=6380

I'll gladly apply your patch.

Would you mind to also supply a patch for the copyright
statement?
It says "Python 2.0 open source license" but that's no
longer the current license. How about the PSF license
agreement for Python 2.2?


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499513&group_id=5470


From noreply@sourceforge.net  Sat Jan  5 01:54:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 Jan 2002 17:54:23 -0800
Subject: [Patches] [ python-Patches-497951 ] Typo in rfc822 library docs.
Message-ID: <E16Mg2R-0006mv-00@usw-sf-web3.sourceforge.net>

Patches item #497951, was opened at 2001-12-30 14:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497951&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Sean Reifschneider (jafo)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Typo in rfc822 library docs.

Initial Comment:
There's a typo in the rfc822:

>timestamp.  It the timezone item in the tuple is
\code{None}, assume


"It" should be "If"?

Anyway, here's a patch against the latest CVS.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-01-04 17:54

Message:
Logged In: YES 
user_id=3066

No patch attached (probably needed to check the "Attach
File" box in the submission form).

Fixed in Doc/lib/librfc822.tex revisions 1.31.2.3,
1.38.14.1, and 1.39.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497951&group_id=5470


From noreply@sourceforge.net  Sat Jan  5 03:41:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 Jan 2002 19:41:49 -0800
Subject: [Patches] [ python-Patches-496705 ] Additions & corrections to libmacui.tex
Message-ID: <E16MhiP-0002z0-00@usw-sf-web1.sourceforge.net>

Patches item #496705, was opened at 2001-12-25 18:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496705&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dean Draayer (draayer)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Additions & corrections to libmacui.tex

Initial Comment:
Includes a thorough description of the relatively new GetArgv function.

Greatly expanded the description of the ProgressBar class, as well as updating the description to reflect recent changes to this class.

Numerous minor changes - mostly grammatical - made throughout the document.


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-01-04 19:41

Message:
Logged In: YES 
user_id=3066

Excellent!

What version of MacPython introduced the GetArgv() function?
 I'd like to add a version annotation and back-port the
portions of the patch that belong in the Python 2.1.2 and
2.2.1 documentation.

Thanks for the contribution!

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496705&group_id=5470


From noreply@sourceforge.net  Sat Jan  5 03:53:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 Jan 2002 19:53:32 -0800
Subject: [Patches] [ python-Patches-496705 ] Additions & corrections to libmacui.tex
Message-ID: <E16Mhtk-00036I-00@usw-sf-web1.sourceforge.net>

Patches item #496705, was opened at 2001-12-25 18:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496705&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dean Draayer (draayer)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Additions & corrections to libmacui.tex

Initial Comment:
Includes a thorough description of the relatively new GetArgv function.

Greatly expanded the description of the ProgressBar class, as well as updating the description to reflect recent changes to this class.

Numerous minor changes - mostly grammatical - made throughout the document.


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-01-04 19:53

Message:
Logged In: YES 
user_id=3066

Attached a revised version of the patch (minor changes only,
plus fix one markup error).

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-01-04 19:41

Message:
Logged In: YES 
user_id=3066

Excellent!

What version of MacPython introduced the GetArgv() function?
 I'd like to add a version annotation and back-port the
portions of the patch that belong in the Python 2.1.2 and
2.2.1 documentation.

Thanks for the contribution!

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496705&group_id=5470


From noreply@sourceforge.net  Sat Jan  5 04:03:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 Jan 2002 20:03:40 -0800
Subject: [Patches] [ python-Patches-497951 ] Typo in rfc822 library docs.
Message-ID: <E16Mi3Y-0000Is-00@usw-sf-web2.sourceforge.net>

Patches item #497951, was opened at 2001-12-30 14:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497951&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Sean Reifschneider (jafo)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Typo in rfc822 library docs.

Initial Comment:
There's a typo in the rfc822:

>timestamp.  It the timezone item in the tuple is
\code{None}, assume


"It" should be "If"?

Anyway, here's a patch against the latest CVS.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-01-04 17:54

Message:
Logged In: YES 
user_id=3066

No patch attached (probably needed to check the "Attach
File" box in the submission form).

Fixed in Doc/lib/librfc822.tex revisions 1.31.2.3,
1.38.14.1, and 1.39.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497951&group_id=5470


From Multiactive Software <crmguarantee@multiactive.com>  Sat Jan  5 17:59:38 2002
From: Multiactive Software <crmguarantee@multiactive.com> (Multiactive Software)
Date: Sat, 05 Jan 2002 09:59:38 -0800
Subject: [Patches] Follow up
Message-ID: <200201051758.JAA22485@mail.multiactive.com>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html>
<head>
	<title>Multiactive CRM Success Guarantee</title>
	<link rel=3D"stylesheet" href=3D"http://www.multiactive.com/productinfo/=
crmguarantee2/campaignStyle.css" type=3D"text/css">
</head>

<body topmargin=3D"0" leftmargin=3D"0" marginheight=3D"0" marginwidth=3D"=
0" bgcolor=3D"#ffffff">
<font face=3D"Verdana" size=3D"2">Hi Again,</font>
<p><font face=3D"Verdana" size=3D"2">We emailed you about two weeks ago, =
and hope
you've had a chance to visit us and read about our new &quot;CRM Success
Guarantee&quot; program. If not, we'd like to invite you to do so at your
earliest convenience. Enclosed is a copy of the original message in case =
you
lost it or deleted it by accident.<br><br>
</font>
<table width=3D"100%" cellspacing=3D"0" cellpadding=3D"0" border=3D"0">
	<tr>
		<td bgcolor=3D"#000000" align=3D"center" width=3D"166">
			<img src=3D"http://www.multiactive.com/productinfo/crmguarantee2/image=
s/msi_logo_CRMEX1.gif" width=3D"166" height=3D"29" >
		</td>
		<td bgcolor=3D"#000000">
			&nbsp;
		</td>
	</tr>
	<tr>
		<td><img src=3D"http://www.multiactive.com/productinfo/crmguarantee2/im=
ages/blue_bar.gif" width=3D"166" height=3D"14"></td>
		<td bgcolor=3D"#5A96E3">&nbsp;</td>
	</tr>
</table>

<table width=3D"798" cellpadding=3D"4">
	<tr>
		<td width=3D"5">
			&nbsp;
		</td>
		<td align=3D"center" width=3D"658">
            <h4>
			<br><font size=3D"3" color=3D"#D11F1F">&nbsp;Increase Profitability an=
d&nbsp;<br>
            <b> Improve</b> Customer Loyalty in 25 Days or Less.</font></=
h4>
            <h4>
            <font size=3D"3" color=3D"#D11F1F">Guaranteed.</font></h4>
		</td>
		<td align=3D"center" width=3D"105">
		</td>
	</tr>
	<tr>
		<td width=3D"5"></td>
		<td align=3D"left" width=3D"658">
			Dear Business Professional,
            <p>Implementing a Customer Relationship Management solution c=
an seem daunting. But increasing
            revenues and improving sales force efficiency is still a prio=
rity
            for you. So Multiactive Software is taking the risk out of im=
plementing a CRM solution
            for your sales, marketing, and customer service operations wi=
th the new <a href=3D"http://cygnet.multiactive.com/OneToOne/ScriptPublis=
her/ScrptPub.dll?ESPW=3DMSI_DATA&ESPJNP=3DCRM_Success_Guarantee2&ESPTP=3D=
1000002893&CID=3D20011207-002875&CN=3D0&targetID=3Dlanding" target=3D"new=
"><b>CRM
            Success Guarantee</b></a> that <b> guarantees rapid implement=
ation and
            results at a fixed price</b>. How are we so confident that we=
 can help
            your business? Multiactive has been a leader in CRM solutions=
 since
            1987, and our software has already helped over a million user=
s
            worldwide.</p>
            <p><a href=3D"http://cygnet.multiactive.com/OneToOne/ScriptPu=
blisher/ScrptPub.dll?ESPW=3DMSI_DATA&ESPJNP=3DCRM_Success_Guarantee2&ESPT=
P=3D1000002893&CID=3D20011207-002875&CN=3D0&targetID=3Dlanding" target=3D=
"new">Find out how
            you can take advantage of this offer now.</a></p>
            <h4><font color=3D"#D11F1F">WE GUARANTEE:</font></h4>
            <ul>
              <li>
                <p style=3D"line-height: 150%"><b><font size=3D"2">Implem=
entation in
                14 days or less</font></b></li>
              <li>
                <p style=3D"line-height: 150%"><b><font size=3D"2">Return=
 on
                Investment (ROI) beginning in 25 days</font></b></li>
              <li>
                <p style=3D"line-height: 150%"><b><font size=3D"2">Fixed =
Price for
                the consultation, software, training, and support</font><=
/b></li>
              <li>
                <p style=3D"line-height: 150%"><font size=3D"2"><b>Succes=
sful
                Results</b></font></li>
            </ul>
            <h4><font color=3D"#D11F1F">YOU GET:</font></h4>
            <ul>
              <li><b>Professional Services</b>
                <ul>
                  <li>Goals and needs assessment</li>
                  <li>Consultation on database design</li>
                  <li>Project documentation</li>
                </ul>
              </li>
              <li><b>Software Licenses, Installation, and Configuration</=
b>
                <ul>
                  <li>Server and workstation software installation</li>
                  <li>Remote synchronization setup</li>
                  <li>Initial data migration</li>
                </ul>
              </li>
              <li><b>Training on-site for administrators and end-users</b=
></li>
              <li><b>Technical Support </b>for one year</li>
            </ul>
            PLUS the <b>flexibility and scalability</b> to grow as your b=
usiness
            grows.
            <p><a href=3D"http://cygnet.multiactive.com/OneToOne/ScriptPu=
blisher/ScrptPub.dll?ESPW=3DMSI_DATA&ESPJNP=3DCRM_Success_Guarantee2&ESPT=
P=3D1000002893&CID=3D20011207-002875&CN=3D0&targetID=3Dcalculator" target=
=3D"new">Click here to
            get an instant quote based on your CRM goals.</a> <img src=3D=
"http://www.multiactive.com/productinfo/crmguarantee/images/CRMGuaranteet=
racking.gif"></p>
            <p>&nbsp;</p>
			<h4>
            <font color=3D"#D11F1F">What can <a href=3D"http://cygnet.mul=
tiactive.com/OneToOne/ScriptPublisher/ScrptPub.dll?ESPW=3DMSI_DATA&ESPJNP=
=3DCRM_Success_Guarantee2&ESPTP=3D1000002893&CID=3D20011207-002875&CN=3D0=
&targetID=3Dlanding" target=3D"new"><font size=3D"3" color=3D"#D11F1F"><b=
> Multiactive's CRM Solutions</b></font></a> do for
            your business?</font></h4>
            <p>Whatever your business, Multiactive's CRM Solutions - Maxi=
mizer
            Enterprise and Entice! - have the strength and flexibility yo=
u need
            to exceed your customers' expectations.&nbsp; And we are comm=
itted
            to helping you reach your CRM goals&nbsp; - <b> without spend=
ing
            millions of dollars, and without waiting months to see
            results.&nbsp;</b><p>Maximizer Enterprise and Entice! are ide=
al CRM
            solutions for small and medium-sized businesses that want to =
get up
            and running right away so you can:
                  <ul>
                    <li>
                      <p style=3D"line-height: 150%"><b>Increase revenue<=
/b><br>
                      Shorten your sales cycle and close more deals by
                      efficiently managing every sales opportunity.</li>
                    <li>
                      <p style=3D"line-height: 150%"><b>Improve customer
                      satisfaction</b><br>
                      Cultivate long-lasting relationships and provide
                      exceptional service by tracking every interaction.<=
/li>
                    <li>
                      <p style=3D"line-height: 150%"><b>Increase retentio=
n and
                      loyalty</b><br>
                      Segment your customers and keep in contact with the=
m
                      regularly with Marketing Automation features.</li>
                  </ul>
                  <p style=3D"line-height: 150%"><b>PLUS:</b></p>
                  <ul>
                    <li>
                      <p style=3D"line-height: 150%">Use the Web to gener=
ate and
                      track your leads&nbsp;</li>
                    <li>
                      <p style=3D"line-height: 150%">Easily track and pro=
cess
                      sales orders in real-time</li>
                    <li>
                      <p style=3D"line-height: 150%">Access and update in=
formation
                      from anywhere, anytime</li>
                    <li>
                      <p style=3D"line-height: 150%">Generate custom sale=
s reports</li>
                    <li>
                      <p style=3D"line-height: 150%">Customize and integr=
ate with
                      your other systems</li>
                  </ul>
            <p style=3D"line-height: 150%"><font color=3D"#D11F1F"><a hre=
f=3D"http://cygnet.multiactive.com/OneToOne/ScriptPublisher/ScrptPub.dll?=
ESPW=3DMSI_DATA&ESPJNP=3DCRM_Success_Guarantee2&ESPTP=3D1000002893&CID=3D=
20011207-002875&CN=3D0&targetID=3Dlanding" target=3D"new"><b><font color=3D=
"#D11F1F" size=3D"2">All at
                  an affordable fixed price</font></b></a><b><font color=3D=
"#666699" size=3D"2">, implemented in 14 days or less, so
                  you can see a Return on your Investment starting in und=
er 25 days.
            Guaranteed.</font></b>
            </font>
            <h4 align=3D"center"><b><font size=3D"3" color=3D"#D11F1F">DO=
N'T WAIT.</font></b></h4>
            <p align=3D"center">This unprecedented offer is available onl=
y for a
            LIMITED TIME.&nbsp;<br>
            Don't let this guarantee for immediate ROI on a CRM Solution =
pass
            you by.<p align=3D"center">If you're ready to see rapid resul=
ts with a CRM
            Solution, contact us today:<h4 align=3D"center"><a href=3D"ht=
tp://cygnet.multiactive.com/OneToOne/ScriptPublisher/ScrptPub.dll?ESPW=3D=
MSI_DATA&ESPJNP=3DCRM_Success_Guarantee2&ESPTP=3D1000002893&CID=3D2001120=
7-002875&CN=3D0&targetID=3Dlanding" target=3D"new"><font size=3D"3"><b>Vi=
sit
            Multiactive for more details on this offer.</b></font></a></h=
4>
            <h4 align=3D"center">Call our Info Center: 1-888-535-4012</h4=
>
            <p align=3D"center"><a href=3D"mailto:crmguarantee@multiactiv=
e.com?Subject=3DPlease send me a CRM Success Guarantee information packag=
e by return email" target=3D"new"><font size=3D"3"><b>Request
            more information by email.</b></font></a><h4 align=3D"center"=
><a href=3D"http://cygnet.multiactive.com/OneToOne/ScriptPublisher/ScrptP=
ub.dll?ESPW=3DMSI_DATA&ESPJNP=3DCRM_Success_Guarantee2&ESPTP=3D1000002893=
&CID=3D20011207-002875&CN=3D0&targetID=3Dlanding" target=3D"new"><font co=
lor=3D"#D11F1F" size=3D"3"><b>CRM
            Success - Guaranteed.</b></font></a></h4>
		=09
			<hr width=3D"100%" size=3D"1" noshade>
            <p>
        <font size=3D"-2" color=3D"#666699">Multiactive Software, the CRM=
 Company, a leading provider of innovative customer relationship manageme=
nt (CRM) and eBusiness solutions, is the maker of Maximizer, Maximizer En=
terprise, Entice!, ecBuilder, and Personal PageBuilder. Established in 19=
88, Multiactive's offices in the U.S., Canada, Hong Kong, Australia, the =
U.K., and Singapore support over 1 million customers. Copyright  =A92001
Multiactive Software Inc. All rights reserved. Give us your feedback. Max=
imizer product information: 1-888-535-4012. General information about Mul=
tiactive Software Inc.:
        <A href=3D"http://www.multiactive.com/" target=3D"new"><font size=
=3D"-2">www.multiactive.com</font></A> or <A href=3D"mailto:info@multiact=
ive.com" target=3D"new"><font size=3D"-2">info@multiactive.com</font></A>
</font>
            </p>
<p>
<font size=3D"-2">
 If you do not want to receive future emails
from Multiactive Software, simply click on the following link:=09
		</font>

 <A href=3D"http://cygnet.multiactive.com/OneToOne/ScriptPublisher/ScrptP=
ub.dll?ESPJNP=3DUnsubscribe_CRMGuarantee2&ESPW=3DMSI_DATA&CID=3D20011207-=
002875&CN=3D0"><font size=3D"-2">Remove</font></A>

		</td>
		<td align=3D"left" width=3D"105" valign=3D"top">
            <div align=3D"center">
              <center>
              <table border=3D"0" cellpadding=3D"6" cellspacing=3D"0" wid=
th=3D"158%">
                <tr>
                  <td width=3D"100%">
				  	<a href=3D"http://cygnet.multiactive.com/OneToOne/ScriptPublisher/=
ScrptPub.dll?ESPW=3DMSI_DATA&ESPJNP=3DCRM_Success_Guarantee2&ESPTP=3D1000=
002893&CID=3D20011207-002875&CN=3D0&targetID=3Dlanding" target=3D"new"><i=
mg border=3D"0" src=3D"http://www.multiactive.com/productinfo/crmguarante=
e/images/nav_crm.gif" width=3D"166" height=3D"64"></a>
                    <a href=3D"http://cygnet.multiactive.com/OneToOne/Scr=
iptPublisher/ScrptPub.dll?ESPW=3DMSI_DATA&ESPJNP=3DCRM_Success_Guarantee2=
&ESPTP=3D1000002893&CID=3D20011207-002875&CN=3D0&targetID=3Dcalculator" t=
arget=3D"new"><img border=3D"0" src=3D"http://www.multiactive.com/product=
info/crmguarantee/images/nav_calculator.gif" width=3D"166" height=3D"61">=
</a>
                    <a href=3D"http://www.multiactive.com/productinfo/crm=
guarantee2/download.html" target=3D"new"><img border=3D"0" src=3D"http://=
www.multiactive.com/productinfo/crmguarantee/images/nav_info.gif" width=3D=
"166" height=3D"61"></a></td>
                </tr>
              </table>
              </center>
            </div>
            <p align=3D"right">&nbsp;</p>
            <p>&nbsp;</p>
            <p>&nbsp;</p>
            <p>&nbsp;</p>
            <p>&nbsp;</p>
            <p>&nbsp;</p>
            <p>&nbsp;</p>
            <p>&nbsp;</p>
            <p>&nbsp;</p>
            <p>&nbsp;</p>
            <p><br>
            <br>
            </p>
            <p>&nbsp;</p>
            <table border=3D"0" cellspacing=3D"3" width=3D"167" cellpaddi=
ng=3D"3">
              <tr>
                <td width=3D"159" bgcolor=3D"#5A96E3" valign=3D"middle"><=
font color=3D"#FFFFFF" size=3D"1"><br>
                  Maximizer Enterprise or Entice!<br>
                  Which one is right for you?<br>
                  </font><a href=3D"http://www.multiactive.com/productinf=
o/crmguarantee2/software.html" target=3D"new"><font size=3D"1" color=3D"#=
FFFFFF">Find
                  out more...<br>
                  <br>
                  </font></a></td>
              </tr>
              <tr>
                <td width=3D"159" bgcolor=3D"#666699" valign=3D"middle"><=
br>
                  <font size=3D"1" color=3D"#FFFFFF">
                  &quot;Maximizer Enterprise is fantastic - it has direct=
ly
                  contributed to the success of our company! It enables u=
s to
                  better manage our data and synchronize information betw=
een our
                  account executives across the country, while also integ=
rating
                  with our other software. We rely heavily on its outstan=
ding
                  capabilities.&quot;&nbsp;<br>
                  <br>
                  - <i>Signy Freysen, National Speakers Bureau
                  </i></font>
                  <p>&nbsp;</td>
              </tr>
              <tr>
                <td width=3D"159" bgcolor=3D"#666699" valign=3D"middle"><=
font size=3D"1" color=3D"#FFFFFF"><br>
                  &quot;Entice! is a lifesaver for tracking multiple sale=
s
                  cycles and assisting in client relationship management.=
 The
                  features are easy to use, and our staff can access them=
 from
                  home or the office. The Campaign Manager enables us to =
reach
                  out to hundreds of prospects and clients on a continuin=
g basis
                  to improve customer retention and loyalty.&quot;&nbsp;<=
br>
                  <br>
                  - <i>Cindy Preger, VP Marketing, MindBlaze.com
                  </i></font>
                  <p>&nbsp;</td>
              </tr>
            </table>

		</td>
	</tr>
</table>

</body>
</html>


From noreply@sourceforge.net  Sat Jan  5 20:23:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 05 Jan 2002 12:23:17 -0800
Subject: [Patches] [ python-Patches-499939 ] Fix for buggy https servers.
Message-ID: <E16MxLZ-0002cn-00@usw-sf-web3.sourceforge.net>

Patches item #499939, was opened at 2002-01-05 12:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499939&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michel Van den Bergh (vdbergh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for buggy https servers.

Initial Comment:
Python 2.2. Tested on RH 7.1.

This a workaround for, 

http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=494762

The problem is that some https servers close an ssl
connection without properly resetting it first. In the
above bug description it is suggested that this
only occurs for IIS but apparently some  (modified)
Apache servers also suffer from it (see
telemeter.telenet.be).

One of the suggested workarounds is to modify
httplib.py so as to ignore the combination of
err[0]==SSL_ERROR_SYSCALL and 
err[1]=="EOF occurred in violation of protocol".
However I think one should never compare error strings
since in principle they may depend on language etc...

So I decided to modify _socket.c slightly so that
it becomes possible to return error codes which
are not in in ssl.h. You will see that I did this
in a portable way, which is independent of the
explicit error numbers in ssl.h.

When an ssl-connection is closed without reset I now
return the error code SSL_ERROR_EOF. Then I ignore
this (apparently benign) error in httplib.py.

In addition I fixed what I think was an error in
PySSL_SetError(SSL *ssl, int ret) in socketmodule.c.

Originally there was:

	case SSL_ERROR_SSL:
	{
		unsigned long e = ERR_get_error();
		if (e == 0) {
			/* an EOF was observed that violates the protocol */
			errstr = "EOF occurred in violation of protocol";

etc... 
but if I understand the documentation for
SSL_get_error then the test should be: e==0 && ret==0.
A similar error occurs a few lines later.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499939&group_id=5470


From noreply@sourceforge.net  Sat Jan  5 20:26:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 05 Jan 2002 12:26:41 -0800
Subject: [Patches] [ python-Patches-499940 ] Work around for buggy https servers
Message-ID: <E16MxOr-0005vm-00@usw-sf-web1.sourceforge.net>

Patches item #499940, was opened at 2002-01-05 12:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499940&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michel Van den Bergh (vdbergh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Work around for buggy https servers

Initial Comment:
Python 2.2. Tested on RH 7.1.

This a workaround for, 

http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=494762

The problem is that some https servers close an ssl
connection without properly resetting it first. In the
above bug description it is suggested that this
only occurs for IIS but apparently some  (modified)
Apache servers also suffer from it (see
telemeter.telenet.be).

One of the suggested workarounds is to modify
httplib.py so as to ignore the combination of
err[0]==SSL_ERROR_SYSCALL and 
err[1]=="EOF occurred in violation of protocol".
However I think one should never compare error strings
since in principle they may depend on language etc...

So I decided to modify _socket.c slightly so that
it becomes possible to return error codes which
are not in in ssl.h. You will see that I did this
in a portable way, which is independent of the
explicit error numbers in ssl.h.

When an ssl-connection is closed without reset I now
return the error code SSL_ERROR_EOF. Then I ignore
this (apparently benign) error in httplib.py.

In addition I fixed what I think was an error in
PySSL_SetError(SSL *ssl, int ret) in socketmodule.c.

Originally there was:

	case SSL_ERROR_SSL:
	{
		unsigned long e = ERR_get_error();
		if (e == 0) {
			/* an EOF was observed that violates the protocol */
			errstr = "EOF occurred in violation of protocol";

etc... 
but if I understand the documentation for
SSL_get_error then the test should be: e==0 && ret==0.
A similar error occurs a few lines later.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499940&group_id=5470


From noreply@sourceforge.net  Sun Jan  6 00:45:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 05 Jan 2002 16:45:03 -0800
Subject: [Patches] [ python-Patches-500002 ] Fix for  #221791
Message-ID: <E16N1Qt-0005rT-00@usw-sf-web2.sourceforge.net>

Patches item #500002, was opened at 2002-01-05 16:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500002&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for  #221791

Initial Comment:
This patch adds file and line output if a bad \x escape
was found in the source. It does so with the following
modifications:

- PyErr_Display now recognizes syntax errors not by
their class, but by an attribute print_file_and_line
- this attribute is set for all SyntaxError instances
- PyErr_SyntaxLocation is enhanced to set all attributes
expected for a syntax error, even if the current
exception has a different class.
- compile.c now invokes PyErr_SyntaxLocation for all
non-syntax exceptions also, mostly through com_error.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500002&group_id=5470


From noreply@sourceforge.net  Sun Jan  6 13:27:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 06 Jan 2002 05:27:34 -0800
Subject: [Patches] [ python-Patches-500136 ] Update ext build documentation
Message-ID: <E16NDKo-0005qA-00@usw-sf-web3.sourceforge.net>

Patches item #500136, was opened at 2002-01-06 05:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500136&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Update ext build documentation

Initial Comment:
The attached file documents how extensions are build
using distutils. It is intended to replace atleast 
unix.tex, and possible also windows.tex.

Fred, if this is ok, I would like to check it in as
ext/building.tex, and remove ext/unix.tex. I would then
add a comment on top of windows.tex that the build
procedure using distutils should work out of the box on
Windows as well.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500136&group_id=5470


From noreply@sourceforge.net  Mon Jan  7 08:49:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 Jan 2002 00:49:28 -0800
Subject: [Patches] [ python-Patches-500311 ] Work around for buggy https servers
Message-ID: <E16NVTE-00007k-00@usw-sf-web3.sourceforge.net>

Patches item #500311, was opened at 2002-01-07 00:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500311&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michel Van den Bergh (vdbergh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Work around for buggy https servers

Initial Comment:
Python 2.2. Tested on RH 7.1.

This a workaround for, 

http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=494762

The problem is that some https servers close an ssl
connection without properly resetting it first. In the
above bug description it is suggested that this
only occurs for IIS but apparently some  (modified)
Apache servers also suffer from it (see
telemeter.telenet.be).

One of the suggested workarounds is to modify
httplib.py so as to ignore the combination of
err[0]==SSL_ERROR_SYSCALL and 
err[1]=="EOF occurred in violation of protocol".
However I think one should never compare error strings
since in principle they may depend on language etc...

So I decided to modify _socket.c slightly so that
it becomes possible to return error codes which
are not in in ssl.h.

When an ssl-connection is closed without reset I now
return the error code SSL_ERROR_EOF. Then I ignore
this (apparently benign) error in httplib.py.

In addition I fixed what I think was an error in
PySSL_SetError(SSL *ssl, int ret) in socketmodule.c.

Originally there was:

	case SSL_ERROR_SSL:
	{
		unsigned long e = ERR_get_error();
		if (e == 0) {
			/* an EOF was observed that violates the protocol */
			errstr = "EOF occurred in violation of protocol";

etc... 
but if I understand the documentation for
SSL_get_error then the test should be: e==0 && ret==0.
A similar error occurs a few lines later.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500311&group_id=5470


From noreply@sourceforge.net  Mon Jan  7 16:34:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 Jan 2002 08:34:44 -0800
Subject: [Patches] [ python-Patches-500447 ] native win32 threading primitives
Message-ID: <E16NcjU-0005uR-00@usw-sf-web2.sourceforge.net>

Patches item #500447, was opened at 2002-01-07 08:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500447&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Orendorff (jorend)
Assigned to: Nobody/Anonymous (nobody)
Summary: native win32 threading primitives

Initial Comment:
The "threading" module provides five synchronization
primitives: Lock, RLock, Condition, Semaphore, and
Event.

This patch is a module, "winthreading", that provides
native C implementations (using Win32 directly) of
these objects.  Benchmark code runs several times
to several hundred times faster using winthreading.

winthreading.c is intended as a drop-in replacement
for these five pieces of threading.py:

  # At the end of threading.py; replace
  # Python synch primitives with native version,
  # if available.
  try:
      from winthreading import *
  except ImportError:
      pass


The ZIP file attached includes source and MSVC6
project files.  The source is compatible with
Python 2.2.

A prebuilt .PYD will follow.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500447&group_id=5470


From noreply@sourceforge.net  Mon Jan  7 16:37:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 Jan 2002 08:37:21 -0800
Subject: [Patches] [ python-Patches-500447 ] native win32 threading primitives
Message-ID: <E16Ncm1-0005xQ-00@usw-sf-web2.sourceforge.net>

Patches item #500447, was opened at 2002-01-07 08:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500447&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Orendorff (jorend)
Assigned to: Nobody/Anonymous (nobody)
Summary: native win32 threading primitives

Initial Comment:
The "threading" module provides five synchronization
primitives: Lock, RLock, Condition, Semaphore, and
Event.

This patch is a module, "winthreading", that provides
native C implementations (using Win32 directly) of
these objects.  Benchmark code runs several times
to several hundred times faster using winthreading.

winthreading.c is intended as a drop-in replacement
for these five pieces of threading.py:

  # At the end of threading.py; replace
  # Python synch primitives with native version,
  # if available.
  try:
      from winthreading import *
  except ImportError:
      pass


The ZIP file attached includes source and MSVC6
project files.  The source is compatible with
Python 2.2.

A prebuilt .PYD will follow.

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

>Comment By: Jason Orendorff (jorend)
Date: 2002-01-07 08:37

Message:
Logged In: YES 
user_id=18139

Prebuilt .PYD file, as promised.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500447&group_id=5470


From noreply@sourceforge.net  Mon Jan  7 17:20:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 Jan 2002 09:20:10 -0800
Subject: [Patches] [ python-Patches-500447 ] native win32 threading primitives
Message-ID: <E16NdRS-0006nq-00@usw-sf-web3.sourceforge.net>

Patches item #500447, was opened at 2002-01-07 08:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500447&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Orendorff (jorend)
Assigned to: Nobody/Anonymous (nobody)
Summary: native win32 threading primitives

Initial Comment:
The "threading" module provides five synchronization
primitives: Lock, RLock, Condition, Semaphore, and
Event.

This patch is a module, "winthreading", that provides
native C implementations (using Win32 directly) of
these objects.  Benchmark code runs several times
to several hundred times faster using winthreading.

winthreading.c is intended as a drop-in replacement
for these five pieces of threading.py:

  # At the end of threading.py; replace
  # Python synch primitives with native version,
  # if available.
  try:
      from winthreading import *
  except ImportError:
      pass


The ZIP file attached includes source and MSVC6
project files.  The source is compatible with
Python 2.2.

A prebuilt .PYD will follow.

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

>Comment By: Jason Orendorff (jorend)
Date: 2002-01-07 09:20

Message:
Logged In: YES 
user_id=18139

Test cases attached.

To run them, put winthreading.pyd in your PYTHONPATH
and run (for example)

 python test_rlock.py

Each test takes a few seconds to a minute to run
on my box; there's a lot of mysterious output,
followed by:

  threading: [2.5829999446868896, ...]
  average: 2.62159998417
  winthreading: [0.12999999523162842, ...]
  average: 0.122199988365
  performance gain: 95.339%
  winthreading is 21.5 times faster!

If you are brave, try modifying test_condition_2.py
a bit.  Change access.wait() to access.wait(50000)
on lines 25 and 39; and see what happens.  (If you
are not quite that brave, you might want to adjust
nloops, on line 46, down to about 500.)


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

Comment By: Jason Orendorff (jorend)
Date: 2002-01-07 08:37

Message:
Logged In: YES 
user_id=18139

Prebuilt .PYD file, as promised.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500447&group_id=5470


From noreply@sourceforge.net  Mon Jan  7 19:39:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 Jan 2002 11:39:52 -0800
Subject: [Patches] [ python-Patches-430706 ] Persistent connections in BaseHTTPServer
Message-ID: <E16Nfce-0008Ob-00@usw-sf-web2.sourceforge.net>

Patches item #430706, was opened at 2001-06-06 08:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430706&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Lawrence (lordsutch)
Assigned to: Martin v. Löwis (loewis)
Summary: Persistent connections in BaseHTTPServer

Initial Comment:
This patch provides HTTP/1.1 persistent 
connection support in BaseHTTPServer.py.  It is 
not enabled by default (for backwards 
compatibility) because Content-Length headers 
must be supplied for persistent connections to 
work correctly.

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

>Comment By: Chris Lawrence (lordsutch)
Date: 2002-01-07 11:39

Message:
Logged In: YES 
user_id=6757

Here's my current version of the patch; the main change is that errors now result in closing the connection.  A cleaner approach for HTTP 1.1 would be to use Chunked Transfer Encoding for this, so the connection could remain available.

I still get spurious IOErrors (due to SIGPIPEs) that result from clients closing connections.  I believe this is because a lot of clients aren't well-behaved; i.e. they read the HTTP/1.1 response line then close the connection immediately.  Using TCP_CORK on Linux for sockets might help there, but it's not a general solution.  Also, I'm not really sure if these exceptions should be caught here or just left to subclasses to deal with...

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-01 12:21

Message:
Logged In: YES 
user_id=21627

Any chance that an updated patch is forthcoming?

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

Comment By: Chris Lawrence (lordsutch)
Date: 2001-09-21 15:01

Message:
Logged In: YES 
user_id=6757

I've tracked that one down and will have an updated patch in
a day or two... basically it just needs another else
condition to handle the empty readline().  There are also
some issues for subclasses that probably need to be
documented to play nicely with bad clients like wget that
claim to be HTTP 1.0 but do HTTP 1.1 stuff.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-09-18 09:36

Message:
Logged In: YES 
user_id=21627

It still doesn't work right. If I access SimpleHTTPServer
from a Netscape client, I get error messages like

localhost - - [18/Sep/2001 18:32:22] code 400, message Bad
request syntax ('')
localhost - - [18/Sep/2001 18:32:22] "" 400 -

These are caused because the client closes the connection
after the first request (likely, after it finds out that the
document it got contains no references to the same server
anymore). However, the server continues to invoke
handle_one_request, which reads the empty line and fails to
recognize that the client has closed the connection.

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

Comment By: Chris Lawrence (lordsutch)
Date: 2001-09-15 01:15

Message:
Logged In: YES 
user_id=6757

I reworked the patch a bit to ensure HTTP 1.1 mode is only 
used if the handler class is in HTTP 1.1 mode, and 
modified the test() functions in the server classes to add 
a "protocol" option.  I also modified SimpleHTTPServer to 
send Content-Length headers for the implemented classes.


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

Comment By: Martin v. Löwis (loewis)
Date: 2001-09-04 04:40

Message:
Logged In: YES 
user_id=21627

The patch in its current form seems to be broken. To see the
problem, please run SimpleHTTPServer on some directory, then
access it with a HTTP/1.1 client (e.g. Netscape 4.7).

The server will use the protocol version HTTP/1.0, but the
client will initially send 1.1, and send a Connection:
Keep-alive header. As a result, self.close_connection is set
to 0, despite using HTTP/1.0. In turn, the HTTP server won't
send a content length, and won't close the connection
either. Netscape waits forever from some completion which
never occurs, since the server waits for the next request on
the same connection.

It might be useful to enhance the SimpleHTTPServer test()
function to optionally operate in HTTP/1.1 mode (including
sending a proper ContentLength). Doing the same for the CGI
HTTP server is probably less useful.


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

Comment By: Chris Lawrence (lordsutch)
Date: 2001-08-29 20:21

Message:
Logged In: YES 
user_id=6757

I have updated the patch against current CVS and have added
documentation.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-08-08 13:43

Message:
Logged In: YES 
user_id=21627

I haven't studied the patch in detail, yet, but I have a 
few comments on the style:

- there is no need to quote all authors of the RFC. Also,
  the reference to long-ago expired HTTP draft should go;
  just replace it with a single reference to the RFC
  number (giving an URL for the RFC might be convenient)
- Where is the documentation? A patch to 
Doc/lib/libbasehttp.tex would be appreciated. If you don't 
speak TeX, don't worry: Just write plain text, we'll do 
the mark-up.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=430706&group_id=5470


From noreply@sourceforge.net  Tue Jan  8 06:49:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 Jan 2002 22:49:21 -0800
Subject: [Patches] [ python-Patches-500447 ] native win32 threading primitives
Message-ID: <E16Nq4X-0000K0-00@usw-sf-web3.sourceforge.net>

Patches item #500447, was opened at 2002-01-07 08:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500447&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Orendorff (jorend)
Assigned to: Nobody/Anonymous (nobody)
Summary: native win32 threading primitives

Initial Comment:
The "threading" module provides five synchronization
primitives: Lock, RLock, Condition, Semaphore, and
Event.

This patch is a module, "winthreading", that provides
native C implementations (using Win32 directly) of
these objects.  Benchmark code runs several times
to several hundred times faster using winthreading.

winthreading.c is intended as a drop-in replacement
for these five pieces of threading.py:

  # At the end of threading.py; replace
  # Python synch primitives with native version,
  # if available.
  try:
      from winthreading import *
  except ImportError:
      pass


The ZIP file attached includes source and MSVC6
project files.  The source is compatible with
Python 2.2.

A prebuilt .PYD will follow.

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

>Comment By: Jason Orendorff (jorend)
Date: 2002-01-07 22:49

Message:
Logged In: YES 
user_id=18139

Better source distribution attached.

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

Comment By: Jason Orendorff (jorend)
Date: 2002-01-07 09:20

Message:
Logged In: YES 
user_id=18139

Test cases attached.

To run them, put winthreading.pyd in your PYTHONPATH
and run (for example)

 python test_rlock.py

Each test takes a few seconds to a minute to run
on my box; there's a lot of mysterious output,
followed by:

  threading: [2.5829999446868896, ...]
  average: 2.62159998417
  winthreading: [0.12999999523162842, ...]
  average: 0.122199988365
  performance gain: 95.339%
  winthreading is 21.5 times faster!

If you are brave, try modifying test_condition_2.py
a bit.  Change access.wait() to access.wait(50000)
on lines 25 and 39; and see what happens.  (If you
are not quite that brave, you might want to adjust
nloops, on line 46, down to about 500.)


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

Comment By: Jason Orendorff (jorend)
Date: 2002-01-07 08:37

Message:
Logged In: YES 
user_id=18139

Prebuilt .PYD file, as promised.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500447&group_id=5470


From noreply@sourceforge.net  Tue Jan  8 16:42:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 Jan 2002 08:42:16 -0800
Subject: [Patches] [ python-Patches-496705 ] Additions & corrections to libmacui.tex
Message-ID: <E16NzKK-00089h-00@usw-sf-web3.sourceforge.net>

Patches item #496705, was opened at 2001-12-25 18:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496705&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dean Draayer (draayer)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Additions & corrections to libmacui.tex

Initial Comment:
Includes a thorough description of the relatively new GetArgv function.

Greatly expanded the description of the ProgressBar class, as well as updating the description to reflect recent changes to this class.

Numerous minor changes - mostly grammatical - made throughout the document.


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

>Comment By: Dean Draayer (draayer)
Date: 2002-01-08 08:42

Message:
Logged In: YES 
user_id=307112

I don't know which version introduced GetArgv().  I think it was 2.0, but since it wasn't documented I never saw it until 2.1.

As far as the barber-pole style progress bars, that will be new in 2.2.  So you may want to anotate the appropriate material with a version number there as well.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-01-04 19:53

Message:
Logged In: YES 
user_id=3066

Attached a revised version of the patch (minor changes only,
plus fix one markup error).

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-01-04 19:41

Message:
Logged In: YES 
user_id=3066

Excellent!

What version of MacPython introduced the GetArgv() function?
 I'd like to add a version annotation and back-port the
portions of the patch that belong in the Python 2.1.2 and
2.2.1 documentation.

Thanks for the contribution!

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496705&group_id=5470


From noreply@sourceforge.net  Tue Jan  8 19:45:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 Jan 2002 11:45:03 -0800
Subject: [Patches] [ python-Patches-500981 ] thread_nt.h weird prototype
Message-ID: <E16O2BD-0002En-00@usw-sf-web3.sourceforge.net>

Patches item #500981, was opened at 2002-01-08 11:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500981&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Orendorff (jorend)
Assigned to: Nobody/Anonymous (nobody)
Summary: thread_nt.h weird prototype

Initial Comment:
Python/thread_nt.h gives a prototype of 
InterlockedCompareExchange that (strangely) disagrees 
with the MSDN definition of the API.

In python/dist/src/Python/thread_nt.h, line 19:
  typedef PVOID WINAPI interlocked_cmp_xchg_t(PVOID 
*dest, PVOID exc, PVOID comperand) ;

But:
  // According to MSDN
  LONG InterlockedCompareExchange( 
    LPLONG volatile Destination,  // destination 
address
    LONG Exchange,                // exchange value
    LONG Comperand                // value to compare
  );

Later on in the file, when the function actually gets 
called, the code contains a bunch of casts to 
compensate for the fact that the prototype is wrong!  
How weird is that?

I've attached a patch that fixes the wacky prototype 
in question.  (I built Python with it and ran the 
regression tests; everything works.)


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500981&group_id=5470


From noreply@sourceforge.net  Tue Jan  8 20:13:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 Jan 2002 12:13:54 -0800
Subject: [Patches] [ python-Patches-500981 ] thread_nt.h weird prototype
Message-ID: <E16O2d8-0002k7-00@usw-sf-web3.sourceforge.net>

Patches item #500981, was opened at 2002-01-08 11:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500981&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Orendorff (jorend)
Assigned to: Nobody/Anonymous (nobody)
Summary: thread_nt.h weird prototype

Initial Comment:
Python/thread_nt.h gives a prototype of 
InterlockedCompareExchange that (strangely) disagrees 
with the MSDN definition of the API.

In python/dist/src/Python/thread_nt.h, line 19:
  typedef PVOID WINAPI interlocked_cmp_xchg_t(PVOID 
*dest, PVOID exc, PVOID comperand) ;

But:
  // According to MSDN
  LONG InterlockedCompareExchange( 
    LPLONG volatile Destination,  // destination 
address
    LONG Exchange,                // exchange value
    LONG Comperand                // value to compare
  );

Later on in the file, when the function actually gets 
called, the code contains a bunch of casts to 
compensate for the fact that the prototype is wrong!  
How weird is that?

I've attached a patch that fixes the wacky prototype 
in question.  (I built Python with it and ran the 
regression tests; everything works.)


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

>Comment By: Tim Peters (tim_one)
Date: 2002-01-08 12:13

Message:
Logged In: YES 
user_id=31435

Whatever MSDN may say, the prototype in the code matches 
what's actually in MS's winbase.h (at least under MSVC 6).  
This makes it too confused for me to even want to think 
about it -- maybe one of the thread_nt.h authors (listed at 
the top of the file) could be provoked into explaining what 
they believe.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500981&group_id=5470


From noreply@sourceforge.net  Wed Jan  9 04:17:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 Jan 2002 20:17:19 -0800
Subject: [Patches] [ python-Patches-500981 ] thread_nt.h weird prototype
Message-ID: <E16OAAx-0003j1-00@usw-sf-web1.sourceforge.net>

Patches item #500981, was opened at 2002-01-08 11:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500981&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Orendorff (jorend)
Assigned to: Nobody/Anonymous (nobody)
Summary: thread_nt.h weird prototype

Initial Comment:
Python/thread_nt.h gives a prototype of 
InterlockedCompareExchange that (strangely) disagrees 
with the MSDN definition of the API.

In python/dist/src/Python/thread_nt.h, line 19:
  typedef PVOID WINAPI interlocked_cmp_xchg_t(PVOID 
*dest, PVOID exc, PVOID comperand) ;

But:
  // According to MSDN
  LONG InterlockedCompareExchange( 
    LPLONG volatile Destination,  // destination 
address
    LONG Exchange,                // exchange value
    LONG Comperand                // value to compare
  );

Later on in the file, when the function actually gets 
called, the code contains a bunch of casts to 
compensate for the fact that the prototype is wrong!  
How weird is that?

I've attached a patch that fixes the wacky prototype 
in question.  (I built Python with it and ran the 
regression tests; everything works.)


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

>Comment By: Jason Orendorff (jorend)
Date: 2002-01-08 20:17

Message:
Logged In: YES 
user_id=18139

Thanks for checking into this, tim.  Maybe I can provoke 
you into
thinking about it just a bit more.  I'll send e-mail to 
both the
authors asking them to take a look at this page, too.

I see declarations of InterlockedCompareExchange() on lines 
1007,
1036, 1093, and 1161 of winbase.h.  But they are consistent 
with MSDN,
*not* with thread_nt.h.  Right?

It *is* quite messy in winbase.h, messy enough to confuse 
Visual
Studio's tooltip feature.  So perhaps you will not 
immediately believe
my assertion above.  Believe this, then:

/* This program compiles without a hitch... */
#include <windows.h>
void main() {
    LONG x = 0, a = 1, b = 0;
    InterlockedCompareExchange(&x, a, b);
}

/* ...but this generates warnings about parameter types. */
#include <windows.h>
void main() {
    PVOID x = NULL, a = NULL, b = NULL;
    InterlockedCompareExchange(&x, a, b);
}

I'm using Visual C++ 6.0 on Windows 2000, on a vanilla 
Intel 32-bit system.


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

Comment By: Tim Peters (tim_one)
Date: 2002-01-08 12:13

Message:
Logged In: YES 
user_id=31435

Whatever MSDN may say, the prototype in the code matches 
what's actually in MS's winbase.h (at least under MSVC 6).  
This makes it too confused for me to even want to think 
about it -- maybe one of the thread_nt.h authors (listed at 
the top of the file) could be provoked into explaining what 
they believe.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500981&group_id=5470


From noreply@sourceforge.net  Wed Jan  9 05:59:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 Jan 2002 21:59:19 -0800
Subject: [Patches] [ python-Patches-500981 ] thread_nt.h weird prototype
Message-ID: <E16OBlf-000121-00@usw-sf-web2.sourceforge.net>

Patches item #500981, was opened at 2002-01-08 11:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500981&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Orendorff (jorend)
Assigned to: Nobody/Anonymous (nobody)
Summary: thread_nt.h weird prototype

Initial Comment:
Python/thread_nt.h gives a prototype of 
InterlockedCompareExchange that (strangely) disagrees 
with the MSDN definition of the API.

In python/dist/src/Python/thread_nt.h, line 19:
  typedef PVOID WINAPI interlocked_cmp_xchg_t(PVOID 
*dest, PVOID exc, PVOID comperand) ;

But:
  // According to MSDN
  LONG InterlockedCompareExchange( 
    LPLONG volatile Destination,  // destination 
address
    LONG Exchange,                // exchange value
    LONG Comperand                // value to compare
  );

Later on in the file, when the function actually gets 
called, the code contains a bunch of casts to 
compensate for the fact that the prototype is wrong!  
How weird is that?

I've attached a patch that fixes the wacky prototype 
in question.  (I built Python with it and ran the 
regression tests; everything works.)


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

>Comment By: Tim Peters (tim_one)
Date: 2002-01-08 21:59

Message:
Logged In: YES 
user_id=31435

Our copies of winbase.h don't match.  I'm using VC6 SP5.  
Strange!

OK, according to
<http://support.microsoft.com/default.aspx?scid=kb;EN-
US;Q292752>

MS changed the signature of InterlockedCompareExchange in 
an incompatible way after VC6 was released.  Best guess is 
that you picked up a newer winbase.h from a platform SDK 
download specific to Win 2000.  But that isn't yet 
reflected in a service pack for VC 6 (SP5 is the most 
recent).  I really don't want to change Python until the 
new prototype ships with the compiler (or its service 
packs).

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

Comment By: Jason Orendorff (jorend)
Date: 2002-01-08 20:17

Message:
Logged In: YES 
user_id=18139

Thanks for checking into this, tim.  Maybe I can provoke 
you into
thinking about it just a bit more.  I'll send e-mail to 
both the
authors asking them to take a look at this page, too.

I see declarations of InterlockedCompareExchange() on lines 
1007,
1036, 1093, and 1161 of winbase.h.  But they are consistent 
with MSDN,
*not* with thread_nt.h.  Right?

It *is* quite messy in winbase.h, messy enough to confuse 
Visual
Studio's tooltip feature.  So perhaps you will not 
immediately believe
my assertion above.  Believe this, then:

/* This program compiles without a hitch... */
#include <windows.h>
void main() {
    LONG x = 0, a = 1, b = 0;
    InterlockedCompareExchange(&x, a, b);
}

/* ...but this generates warnings about parameter types. */
#include <windows.h>
void main() {
    PVOID x = NULL, a = NULL, b = NULL;
    InterlockedCompareExchange(&x, a, b);
}

I'm using Visual C++ 6.0 on Windows 2000, on a vanilla 
Intel 32-bit system.


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

Comment By: Tim Peters (tim_one)
Date: 2002-01-08 12:13

Message:
Logged In: YES 
user_id=31435

Whatever MSDN may say, the prototype in the code matches 
what's actually in MS's winbase.h (at least under MSVC 6).  
This makes it too confused for me to even want to think 
about it -- maybe one of the thread_nt.h authors (listed at 
the top of the file) could be provoked into explaining what 
they believe.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500981&group_id=5470


From noreply@sourceforge.net  Wed Jan  9 10:25:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 Jan 2002 02:25:45 -0800
Subject: [Patches] [ python-Patches-500311 ] Work around for buggy https servers
Message-ID: <E16OFvV-0008DW-00@usw-sf-web1.sourceforge.net>

Patches item #500311, was opened at 2002-01-07 00:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500311&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michel Van den Bergh (vdbergh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Work around for buggy https servers

Initial Comment:
Python 2.2. Tested on RH 7.1.

This a workaround for, 

http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=494762

The problem is that some https servers close an ssl
connection without properly resetting it first. In the
above bug description it is suggested that this
only occurs for IIS but apparently some  (modified)
Apache servers also suffer from it (see
telemeter.telenet.be).

One of the suggested workarounds is to modify
httplib.py so as to ignore the combination of
err[0]==SSL_ERROR_SYSCALL and 
err[1]=="EOF occurred in violation of protocol".
However I think one should never compare error strings
since in principle they may depend on language etc...

So I decided to modify _socket.c slightly so that
it becomes possible to return error codes which
are not in in ssl.h.

When an ssl-connection is closed without reset I now
return the error code SSL_ERROR_EOF. Then I ignore
this (apparently benign) error in httplib.py.

In addition I fixed what I think was an error in
PySSL_SetError(SSL *ssl, int ret) in socketmodule.c.

Originally there was:

	case SSL_ERROR_SSL:
	{
		unsigned long e = ERR_get_error();
		if (e == 0) {
			/* an EOF was observed that violates the protocol */
			errstr = "EOF occurred in violation of protocol";

etc... 
but if I understand the documentation for
SSL_get_error then the test should be: e==0 && ret==0.
A similar error occurs a few lines later.

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

>Comment By: Michel Van den Bergh (vdbergh)
Date: 2002-01-09 02:25

Message:
Logged In: YES 
user_id=10252

Due to some problems with sourceforge and incompetence on my
part I submitted this several times.
Please see patch 500311. 

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500311&group_id=5470


From noreply@sourceforge.net  Wed Jan  9 10:28:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 Jan 2002 02:28:11 -0800
Subject: [Patches] [ python-Patches-499940 ] Work around for buggy https servers
Message-ID: <E16OFxr-0008F8-00@usw-sf-web1.sourceforge.net>

Patches item #499940, was opened at 2002-01-05 12:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499940&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michel Van den Bergh (vdbergh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Work around for buggy https servers

Initial Comment:
Python 2.2. Tested on RH 7.1.

This a workaround for, 

http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=494762

The problem is that some https servers close an ssl
connection without properly resetting it first. In the
above bug description it is suggested that this
only occurs for IIS but apparently some  (modified)
Apache servers also suffer from it (see
telemeter.telenet.be).

One of the suggested workarounds is to modify
httplib.py so as to ignore the combination of
err[0]==SSL_ERROR_SYSCALL and 
err[1]=="EOF occurred in violation of protocol".
However I think one should never compare error strings
since in principle they may depend on language etc...

So I decided to modify _socket.c slightly so that
it becomes possible to return error codes which
are not in in ssl.h. You will see that I did this
in a portable way, which is independent of the
explicit error numbers in ssl.h.

When an ssl-connection is closed without reset I now
return the error code SSL_ERROR_EOF. Then I ignore
this (apparently benign) error in httplib.py.

In addition I fixed what I think was an error in
PySSL_SetError(SSL *ssl, int ret) in socketmodule.c.

Originally there was:

	case SSL_ERROR_SSL:
	{
		unsigned long e = ERR_get_error();
		if (e == 0) {
			/* an EOF was observed that violates the protocol */
			errstr = "EOF occurred in violation of protocol";

etc... 
but if I understand the documentation for
SSL_get_error then the test should be: e==0 && ret==0.
A similar error occurs a few lines later.

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

>Comment By: Michel Van den Bergh (vdbergh)
Date: 2002-01-09 02:28

Message:
Logged In: YES 
user_id=10252

Due to some problems with sourceforge and incompetence on my
part I seem to have submitted several times. See patch
500311.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499940&group_id=5470


From noreply@sourceforge.net  Wed Jan  9 10:29:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 Jan 2002 02:29:49 -0800
Subject: [Patches] [ python-Patches-499939 ] Fix for buggy https servers.
Message-ID: <E16OFzR-0008Gc-00@usw-sf-web1.sourceforge.net>

Patches item #499939, was opened at 2002-01-05 12:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499939&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michel Van den Bergh (vdbergh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for buggy https servers.

Initial Comment:
Python 2.2. Tested on RH 7.1.

This a workaround for, 

http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=494762

The problem is that some https servers close an ssl
connection without properly resetting it first. In the
above bug description it is suggested that this
only occurs for IIS but apparently some  (modified)
Apache servers also suffer from it (see
telemeter.telenet.be).

One of the suggested workarounds is to modify
httplib.py so as to ignore the combination of
err[0]==SSL_ERROR_SYSCALL and 
err[1]=="EOF occurred in violation of protocol".
However I think one should never compare error strings
since in principle they may depend on language etc...

So I decided to modify _socket.c slightly so that
it becomes possible to return error codes which
are not in in ssl.h. You will see that I did this
in a portable way, which is independent of the
explicit error numbers in ssl.h.

When an ssl-connection is closed without reset I now
return the error code SSL_ERROR_EOF. Then I ignore
this (apparently benign) error in httplib.py.

In addition I fixed what I think was an error in
PySSL_SetError(SSL *ssl, int ret) in socketmodule.c.

Originally there was:

	case SSL_ERROR_SSL:
	{
		unsigned long e = ERR_get_error();
		if (e == 0) {
			/* an EOF was observed that violates the protocol */
			errstr = "EOF occurred in violation of protocol";

etc... 
but if I understand the documentation for
SSL_get_error then the test should be: e==0 && ret==0.
A similar error occurs a few lines later.

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

>Comment By: Michel Van den Bergh (vdbergh)
Date: 2002-01-09 02:29

Message:
Logged In: YES 
user_id=10252

Due to some problems with sourceforge and incompetence on my
part I seem to have submitted several times. See patch
500311.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499939&group_id=5470


From noreply@sourceforge.net  Wed Jan  9 20:12:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 Jan 2002 12:12:24 -0800
Subject: [Patches] [ python-Patches-500981 ] thread_nt.h weird prototype
Message-ID: <E16OP5E-0003Ze-00@usw-sf-web2.sourceforge.net>

Patches item #500981, was opened at 2002-01-08 11:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500981&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Orendorff (jorend)
Assigned to: Nobody/Anonymous (nobody)
Summary: thread_nt.h weird prototype

Initial Comment:
Python/thread_nt.h gives a prototype of 
InterlockedCompareExchange that (strangely) disagrees 
with the MSDN definition of the API.

In python/dist/src/Python/thread_nt.h, line 19:
  typedef PVOID WINAPI interlocked_cmp_xchg_t(PVOID 
*dest, PVOID exc, PVOID comperand) ;

But:
  // According to MSDN
  LONG InterlockedCompareExchange( 
    LPLONG volatile Destination,  // destination 
address
    LONG Exchange,                // exchange value
    LONG Comperand                // value to compare
  );

Later on in the file, when the function actually gets 
called, the code contains a bunch of casts to 
compensate for the fact that the prototype is wrong!  
How weird is that?

I've attached a patch that fixes the wacky prototype 
in question.  (I built Python with it and ran the 
regression tests; everything works.)


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

>Comment By: Jason Orendorff (jorend)
Date: 2002-01-09 12:12

Message:
Logged In: YES 
user_id=18139

Ah.  Makes perfect sense.  I do have a later platform SDK
installed.  Ater reading the support article, I am 
satisfied.

Bill me for your wasted time. :)


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

Comment By: Tim Peters (tim_one)
Date: 2002-01-08 21:59

Message:
Logged In: YES 
user_id=31435

Our copies of winbase.h don't match.  I'm using VC6 SP5.  
Strange!

OK, according to
<http://support.microsoft.com/default.aspx?scid=kb;EN-
US;Q292752>

MS changed the signature of InterlockedCompareExchange in 
an incompatible way after VC6 was released.  Best guess is 
that you picked up a newer winbase.h from a platform SDK 
download specific to Win 2000.  But that isn't yet 
reflected in a service pack for VC 6 (SP5 is the most 
recent).  I really don't want to change Python until the 
new prototype ships with the compiler (or its service 
packs).

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

Comment By: Jason Orendorff (jorend)
Date: 2002-01-08 20:17

Message:
Logged In: YES 
user_id=18139

Thanks for checking into this, tim.  Maybe I can provoke 
you into
thinking about it just a bit more.  I'll send e-mail to 
both the
authors asking them to take a look at this page, too.

I see declarations of InterlockedCompareExchange() on lines 
1007,
1036, 1093, and 1161 of winbase.h.  But they are consistent 
with MSDN,
*not* with thread_nt.h.  Right?

It *is* quite messy in winbase.h, messy enough to confuse 
Visual
Studio's tooltip feature.  So perhaps you will not 
immediately believe
my assertion above.  Believe this, then:

/* This program compiles without a hitch... */
#include <windows.h>
void main() {
    LONG x = 0, a = 1, b = 0;
    InterlockedCompareExchange(&x, a, b);
}

/* ...but this generates warnings about parameter types. */
#include <windows.h>
void main() {
    PVOID x = NULL, a = NULL, b = NULL;
    InterlockedCompareExchange(&x, a, b);
}

I'm using Visual C++ 6.0 on Windows 2000, on a vanilla 
Intel 32-bit system.


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

Comment By: Tim Peters (tim_one)
Date: 2002-01-08 12:13

Message:
Logged In: YES 
user_id=31435

Whatever MSDN may say, the prototype in the code matches 
what's actually in MS's winbase.h (at least under MSVC 6).  
This makes it too confused for me to even want to think 
about it -- maybe one of the thread_nt.h authors (listed at 
the top of the file) could be provoked into explaining what 
they believe.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500981&group_id=5470


From cinthia@anovaluz.com.br  Wed Jan  9 23:15:51 2002
From: cinthia@anovaluz.com.br (NovaLuz)
Date: Wed, 09 Jan 2002 21:15:51 -0200
Subject: [Patches] =?iso-8859-1?Q?Don=B4t_stay_in_the_dark?=
Message-ID: <E16OTMa-0007Rm-00@mail.python.org>

This is a Multipart MIME message.

------=_NextPart_000_001__5527629_76551,74
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_002__5527629_76551,74"


------=_NextPart_001_002__5527629_76551,74
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit


------=_NextPart_001_002__5527629_76551,74
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiDQp4bWxuczpv
PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiDQp4bWxuczp3PSJ1
cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIg0KeG1sbnM9Imh0dHA6Ly93
d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9
Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD13aW5kb3dzLTEyNTIi
Pg0KPG1ldGEgbmFtZT1Qcm9nSWQgY29udGVudD1Xb3JkLkRvY3VtZW50Pg0KPG1ldGEgbmFt
ZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgOSI+DQo8bWV0YSBuYW1lPU9y
aWdpbmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgOSI+DQo8bGluayByZWw9RmlsZS1M
aXN0IGhyZWY9Ii4vSW5nbGVzJTIwLSUyME5MNTVDRF9hcnF1aXZvcy9maWxlbGlzdC54bWwi
Pg0KPGxpbmsgcmVsPUVkaXQtVGltZS1EYXRhIGhyZWY9Ii4vSW5nbGVzJTIwLSUyME5MNTVD
RF9hcnF1aXZvcy9lZGl0ZGF0YS5tc28iPg0KPCEtLVtpZiAhbXNvXT4NCjxzdHlsZT4NCnZc
Oioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9yOnVybCgj
ZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCi5z
aGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT4NCjwhW2VuZGlm
XS0tPg0KPHRpdGxlPk7jbyBGaXF1ZSBubyBFc2N1cm88L3RpdGxlPg0KPCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQogPG86RG9jdW1lbnRQcm9wZXJ0aWVzPg0KICA8bzpBdXRob3I+Q0lO
VEhJQTwvbzpBdXRob3I+DQogIDxvOlRlbXBsYXRlPk5vcm1hbDwvbzpUZW1wbGF0ZT4NCiAg
PG86TGFzdEF1dGhvcj5DaW50aGlhIEFsbWVpZGEgZGUgU291emE8L286TGFzdEF1dGhvcj4N
CiAgPG86UmV2aXNpb24+MjwvbzpSZXZpc2lvbj4NCiAgPG86VG90YWxUaW1lPjA8L286VG90
YWxUaW1lPg0KICA8bzpDcmVhdGVkPjIwMDItMDEtMDdUMjI6MzA6MDBaPC9vOkNyZWF0ZWQ+
DQogIDxvOkxhc3RTYXZlZD4yMDAyLTAxLTA3VDIyOjMwOjAwWjwvbzpMYXN0U2F2ZWQ+DQog
IDxvOlBhZ2VzPjI8L286UGFnZXM+DQogIDxvOldvcmRzPjEyMTwvbzpXb3Jkcz4NCiAgPG86
Q2hhcmFjdGVycz42OTA8L286Q2hhcmFjdGVycz4NCiAgPG86Q29tcGFueT5Ob3ZhIGx1ejwv
bzpDb21wYW55Pg0KICA8bzpMaW5lcz41PC9vOkxpbmVzPg0KICA8bzpQYXJhZ3JhcGhzPjE8
L286UGFyYWdyYXBocz4NCiAgPG86Q2hhcmFjdGVyc1dpdGhTcGFjZXM+ODQ3PC9vOkNoYXJh
Y3RlcnNXaXRoU3BhY2VzPg0KICA8bzpWZXJzaW9uPjkuMjgxMjwvbzpWZXJzaW9uPg0KIDwv
bzpEb2N1bWVudFByb3BlcnRpZXM+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCiA8dzpXb3JkRG9jdW1lbnQ+DQogIDx3Okh5cGhlbmF0aW9uWm9uZT4y
MTwvdzpIeXBoZW5hdGlvblpvbmU+DQogPC93OldvcmREb2N1bWVudD4NCjwveG1sPjwhW2Vu
ZGlmXS0tPg0KPHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250
LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvcHBycGxHb3RoIEJkIEJUIjsNCglwYW5vc2UtMToy
IDE0IDcgNSAyIDIgMyAyIDQgNDsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVy
aWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNv
LWZvbnQtc2lnbmF0dXJlOjcgMCAwIDAgMTcgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OiJNb25vdHlwZSBDb3JzaXZhIjsNCglwYW5vc2UtMTozIDEgMSAxIDEgMiAxIDEgMSAx
Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpzY3Jp
cHQ7DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOjY0
NyAwIDAgMCAxNTkgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJMdWNpZGEgU2Fu
cyBVbmljb2RlIjsNCglwYW5vc2UtMToyIDExIDYgMiAzIDUgNCAyIDIgNDsNCgltc28tZm9u
dC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZv
bnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOjY3OTEgMCAwIDAgNjMg
MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBdmFudEdhcmRlIE1kIEJUIjsNCglw
YW5vc2UtMToyIDExIDYgMiAyIDIgMiAyIDIgNDsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJ
bXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFi
bGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOjcgMCAwIDAgMTcgMDt9DQogLyogU3R5bGUgRGVm
aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN
Cgl7bXNvLXN0eWxlLXBhcmVudDoiIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tZmFyZWFzdC1m
b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpoMQ0KCXttc28tc3R5bGUtbmV4dDpO
b3JtYWw7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1h
bGlnbjpjZW50ZXI7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCXBhZ2UtYnJl
YWstYWZ0ZXI6YXZvaWQ7DQoJbXNvLW91dGxpbmUtbGV2ZWw6MTsNCglmb250LXNpemU6MTgu
MHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Ik1vbm90
eXBlIENvcnNpdmEiOw0KCW1zby1mb250LWtlcm5pbmc6MHB0Ow0KCWZvbnQtd2VpZ2h0Om5v
cm1hbDt9DQpoMg0KCXttc28tc3R5bGUtbmV4dDpOb3JtYWw7DQoJbWFyZ2luOjBjbTsNCglt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpjZW50ZXI7DQoJbXNvLXBhZ2lu
YXRpb246d2lkb3ctb3JwaGFuOw0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJbXNvLW91
dGxpbmUtbGV2ZWw6MjsNCglmb250LXNpemU6MTQuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6
ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJZm9udC13ZWln
aHQ6bm9ybWFsO30NCnAuTXNvQ2FwdGlvbiwgbGkuTXNvQ2FwdGlvbiwgZGl2Lk1zb0NhcHRp
b24NCgl7bXNvLXN0eWxlLW5leHQ6Tm9ybWFsOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJv
dHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNp
emU6MTIuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6
IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5l
dyBSb21hbiI7DQoJY29sb3I6IzVGNUY1Rjt9DQpwLk1zb1RpdGxlLCBsaS5Nc29UaXRsZSwg
ZGl2Lk1zb1RpdGxlDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K
CXRleHQtYWxpZ246Y2VudGVyOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglm
b250LXNpemU6MjAuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m
YW1pbHk6Ikx1Y2lkYSBTYW5zIFVuaWNvZGUiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOiMzMzMzQ0M7fQ0KcC5Nc29Cb2R5VGV4dCwg
bGkuTXNvQm9keVRleHQsIGRpdi5Nc29Cb2R5VGV4dA0KCXttYXJnaW46MGNtOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9u
dC1zaXplOjE0LjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1l
cyBOZXcgUm9tYW4iO30NCnAuTXNvQm9keVRleHRJbmRlbnQsIGxpLk1zb0JvZHlUZXh0SW5k
ZW50LCBkaXYuTXNvQm9keVRleHRJbmRlbnQNCgl7bWFyZ2luLXRvcDowY207DQoJbWFyZ2lu
LXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDoyODMuMnB0
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4
dC1pbmRlbnQ6MzUuNHB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250
LXNpemU6MTQuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p
bHk6IkF2YW50R2FyZGUgTWQgQlQiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1l
cyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i
Ow0KCWNvbG9yOiM5OUNDMDA7DQoJZm9udC13ZWlnaHQ6Ym9sZDsNCgltc28tYmlkaS1mb250
LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTppdGFsaWM7DQoJbXNvLWJpZGktZm9udC1z
dHlsZTpub3JtYWw7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xl
O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5n
bGU7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu
OjcwLjlwdCA0Mi41NXB0IDcwLjlwdCA0Mi41NXB0Ow0KCW1zby1oZWFkZXItbWFyZ2luOjM1
LjQ1cHQ7DQoJbXNvLWZvb3Rlci1tYXJnaW46MzUuNDVwdDsNCgltc28tcGFwZXItc291cmNl
OjA7fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0K
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp
dCIgc3BpZG1heD0iMjA1MCIvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv
IDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2
OmV4dD0iZWRpdCIgZGF0YT0iMSIvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1QVC1CUiBsaW5rPWJsdWUgdmxpbms9cHVy
cGxlIHN0eWxlPSd0YWItaW50ZXJ2YWw6MzUuNHB0Jz4NCg0KPGRpdiBjbGFzcz1TZWN0aW9u
MT4NCg0KPHAgY2xhc3M9TXNvVGl0bGU+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWFu
c2ktbGFuZ3VhZ2U6RU4tVVMnPkRvbrR0IHN0YXkNCmluIHRoZSBkYXJrPG86cD48L286cD48
L3NwYW4+PC9wPg0KDQo8aDE+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjIy
LjBwdDttc28tYmlkaS1mb250LXNpemU6MTIuMHB0Ow0KY29sb3I6cmVkO21zby1hbnNpLWxh
bmd1YWdlOkVOLVVTJz5FbWVyZ2VuY3kgTGlnaHQ8c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVu
Og0KeWVzIj6gIDwvc3Bhbj6WIE5vdmFMdXo8bzpwPjwvbzpwPjwvc3Bhbj48L2gxPg0KDQo8
cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjE0
LjBwdDttc28tYmlkaS1mb250LXNpemU6DQoxMi4wcHQ7Zm9udC1mYW1pbHk6IkNvcHBycGxH
b3RoIEJkIEJUIjttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+PCFbaWYgIXN1cHBvcnRFbXB0
eVBhcmFzXT4mbmJzcDs8IVtlbmRpZl0+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8aDI+
PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjE1LjBwdDttc28tYmlkaS1mb250
LXNpemU6MTIuMHB0Ow0KZm9udC1mYW1pbHk6IkNvcHBycGxHb3RoIEJkIEJUIjttc28tYW5z
aS1sYW5ndWFnZTpFTi1VUyc+TW9kZWwgTkwgNTUgQ0QgliBIaWdoDQpQb3dlciBJbmRlcGVu
ZGVudCBVbml0PG86cD48L286cD48L3NwYW4+PC9oMj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs
IGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFuIGxhbmc9RU4t
VVMNCnN0eWxlPSdtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+QXV0b21hdGljIGFuZCBpbnN0
YW50YW5lb3VzIHN3aXRjaGluZyBpbiBjYXNlDQpvZiBlbGVjdHJpY2FsIHBvd2VyIHNob3J0
YWdlPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8aDI+PHNwYW4gbGFuZz1FTi1VUyBzdHls
ZT0nbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPjwhW2lmICFzdXBwb3J0RW1wdHlQYXJhc10+
Jm5ic3A7PCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvaDI+DQoNCjxwIGNsYXNzPU1z
b05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28tYW5zaS1sYW5ndWFnZTpFTi1V
Uyc+PCFbaWYgIXN1cHBvcnRFbXB0eVBhcmFzXT4mbmJzcDs8IVtlbmRpZl0+PG86cD48L286
cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxl
PSdtYXJnaW4tbGVmdDoxNDEuNnB0O3RleHQtYWxpZ246Y2VudGVyJz48IS0tW2lmIGd0ZSB2
bWwgMV0+PHY6c2hhcGV0eXBlDQogaWQ9Il94MDAwMF90NzUiIGNvb3Jkc2l6ZT0iMjE2MDAs
MjE2MDAiIG86c3B0PSI3NSIgbzpwcmVmZXJyZWxhdGl2ZT0idCINCiBwYXRoPSJtQDRANWxA
NEAxMUA5QDExQDlANXhlIiBmaWxsZWQ9ImYiIHN0cm9rZWQ9ImYiPg0KIDx2OnN0cm9rZSBq
b2luc3R5bGU9Im1pdGVyIi8+DQogPHY6Zm9ybXVsYXM+DQogIDx2OmYgZXFuPSJpZiBsaW5l
RHJhd24gcGl4ZWxMaW5lV2lkdGggMCIvPg0KICA8djpmIGVxbj0ic3VtIEAwIDEgMCIvPg0K
ICA8djpmIGVxbj0ic3VtIDAgMCBAMSIvPg0KICA8djpmIGVxbj0icHJvZCBAMiAxIDIiLz4N
CiAgPHY6ZiBlcW49InByb2QgQDMgMjE2MDAgcGl4ZWxXaWR0aCIvPg0KICA8djpmIGVxbj0i
cHJvZCBAMyAyMTYwMCBwaXhlbEhlaWdodCIvPg0KICA8djpmIGVxbj0ic3VtIEAwIDAgMSIv
Pg0KICA8djpmIGVxbj0icHJvZCBANiAxIDIiLz4NCiAgPHY6ZiBlcW49InByb2QgQDcgMjE2
MDAgcGl4ZWxXaWR0aCIvPg0KICA8djpmIGVxbj0ic3VtIEA4IDIxNjAwIDAiLz4NCiAgPHY6
ZiBlcW49InByb2QgQDcgMjE2MDAgcGl4ZWxIZWlnaHQiLz4NCiAgPHY6ZiBlcW49InN1bSBA
MTAgMjE2MDAgMCIvPg0KIDwvdjpmb3JtdWxhcz4NCiA8djpwYXRoIG86ZXh0cnVzaW9ub2s9
ImYiIGdyYWRpZW50c2hhcGVvaz0idCIgbzpjb25uZWN0dHlwZT0icmVjdCIvPg0KIDxvOmxv
Y2sgdjpleHQ9ImVkaXQiIGFzcGVjdHJhdGlvPSJ0Ii8+DQo8L3Y6c2hhcGV0eXBlPjx2OnNo
YXBlIGlkPSJfeDAwMDBfczEwMjgiIHR5cGU9IiNfeDAwMDBfdDc1Ig0KIGhyZWY9Imh0dHA6
Ly93d3cuYW5vdmFsdXouY29tLmJyLyIgc3R5bGU9J3Bvc2l0aW9uOmFic29sdXRlO2xlZnQ6
MDsNCiB0ZXh0LWFsaWduOmxlZnQ7bWFyZ2luLWxlZnQ6MDttYXJnaW4tdG9wOjA7d2lkdGg6
MTE0cHQ7aGVpZ2h0OjExOS4xNXB0Ow0KIHotaW5kZXg6MTttc28td3JhcC1lZGl0ZWQ6Zjtt
c28tcG9zaXRpb24taG9yaXpvbnRhbDpsZWZ0Ow0KIG1zby1wb3NpdGlvbi12ZXJ0aWNhbDp0
b3A7bXNvLXBvc2l0aW9uLXZlcnRpY2FsLXJlbGF0aXZlOmxpbmUnIHdyYXBjb29yZHM9Ii0x
NDIgMCAtMTQyIDIxNDY0IDIxNjAwIDIxNDY0IDIxNjAwIDAgLTE0MiAwIg0KIG86YWxsb3dv
dmVybGFwPSJmIiBvOmJ1dHRvbj0idCI+DQogPHY6ZmlsbCBvOmRldGVjdG1vdXNlY2xpY2s9
InQiLz4NCiA8djppbWFnZWRhdGEgc3JjPSJjaWQ6NTUyNzY0NDE2NjEzQGltYWdlMDAxLmdp
ZiIgbzp0aXRsZT0ibmw1NWNkY2FwYSIvPg0KIDx3OndyYXAgdHlwZT0ic3F1YXJlIiBhbmNo
b3J4PSJwYWdlIi8+DQo8L3Y6c2hhcGU+PCFbZW5kaWZdLS0+PCFbaWYgIXZtbF0+PGEgaHJl
Zj0iaHR0cDovL3d3dy5hbm92YWx1ei5jb20uYnIvIj48aW1nDQpib3JkZXI9MCB3aWR0aD0x
NTIgaGVpZ2h0PTE1OSBzcmM9ImNpZDo1NTI3NjQ0MTY2MTNAaW1hZ2UwMDEuZ2lmIg0KYWxp
Z249bGVmdCBoc3BhY2U9MTIgdjpzaGFwZXM9Il94MDAwMF9zMTAyOCI+PC9hPjwhW2VuZGlm
XT48YQ0KaHJlZj0iaHR0cDovL3d3dy5hbm92YWx1ei5jb20uYnIvIj48L2E+PGEgaHJlZj0i
aHR0cDovL3d3dy5hbm92YWx1ei5jb20uYnIvIj48L2E+PHNwYW4NCmxhbmc9RU4tVVMgc3R5
bGU9J21zby1hbnNpLWxhbmd1YWdlOkVOLVVTJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN
CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdtc28tYW5zaS1s
YW5ndWFnZTpFTi1VUyc+Kg0KT3BlcmFudGluZyBSYWdlOiAzICwgNCBvciA1IGhvdXJzPG86
cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F
Ti1VUyBzdHlsZT0nbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPjwhW2lmICFzdXBwb3J0RW1w
dHlQYXJhc10+Jm5ic3A7PCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg
Y2xhc3M9TXNvTm9ybWFsPiogQ292ZXJlZCDhcmVhOiAzMDAgbTIuPC9wPg0KDQo8cCBjbGFz
cz1Nc29Ob3JtYWw+PCFbaWYgIXN1cHBvcnRFbXB0eVBhcmFzXT4mbmJzcDs8IVtlbmRpZl0+
PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT
IHN0eWxlPSdtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+Kg0KTWFpbnRlbmFuY2UgZnJlZSBz
ZWFsZWQgYmF0dGVyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y
bWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J21zby1hbnNpLWxhbmd1YWdlOkVOLVVTJz48
IVtpZiAhc3VwcG9ydEVtcHR5UGFyYXNdPiZuYnNwOzwhW2VuZGlmXT48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl
PSdtc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+KiBNYWRlIGluDQpCcmF6aWwgliBCeSBOb3Zh
THV6PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g
bGFuZz1FTi1VUyBzdHlsZT0nbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPjwhW2lmICFzdXBw
b3J0RW1wdHlQYXJhc10+Jm5ic3A7PCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
Cg0KPHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpj
ZW50ZXInPjxzcGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdmb250LXNpemU6MTQuMHB0O21zby1i
aWRpLWZvbnQtc2l6ZToxMi4wcHQ7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPjwhW2lmICFz
dXBwb3J0RW1wdHlQYXJhc10+Jm5ic3A7PCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGln
bjpjZW50ZXInPjxzcGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdmb250LXNpemU6MTQuMHB0O21z
by1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPjwhW2lm
ICFzdXBwb3J0RW1wdHlQYXJhc10+Jm5ic3A7PCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1h
bGlnbjpjZW50ZXInPjxzcGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdmb250LXNpemU6MTQuMHB0
O21zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPkNv
bnN1bHQNCnRoaXMgYW5kIG90aGVyIG1vZGVscywgdmlzaXQgb3VyIHdlYnNpdGU8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5
bGU9J3RleHQtYWxpZ246Y2VudGVyJz48c3BhbiBsYW5nPUVOLVVTDQpzdHlsZT0nZm9udC1z
aXplOjE2LjBwdDttc28tYmlkaS1mb250LXNpemU6MTIuMHB0O21zby1hbnNpLWxhbmd1YWdl
OkVOLVVTJz48YQ0KaHJlZj0iaHR0cDovL3d3dy5hbm92YWx1ei5jb20uYnIvc2l0ZW5vdmFs
dXoyL0luZ2xlcy9ocC11c2EuaHRtIj5odHRwOi8vd3d3LmFub3ZhbHV6LmNvbS5ici9zaXRl
bm92YWx1ejIvSW5nbGVzL2hwLXVzYS5odG08L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K
DQo8cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNl
bnRlcic+PHNwYW4gbGFuZz1FTi1VUw0Kc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7bXNvLWJp
ZGktZm9udC1zaXplOjEyLjBwdDttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+PCFbaWYgIXN1
cHBvcnRFbXB0eVBhcmFzXT4mbmJzcDs8IVtlbmRpZl0+PG86cD48L286cD48L3NwYW4+PC9w
Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWdu
OmNlbnRlcic+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTQuMHB0O21zby1iaWRpLWZvbnQt
c2l6ZToxMi4wcHQnPjwhLS1baWYgZ3RlIHZtbCAxXT48djpzaGFwZQ0KIGlkPSJfeDAwMDBf
aTEwMjYiIHR5cGU9IiNfeDAwMDBfdDc1IiBzdHlsZT0nd2lkdGg6MTM1Ljc1cHQ7aGVpZ2h0
OjQ2LjVwdCc+DQogPHY6aW1hZ2VkYXRhIHNyYz0iY2lkOjU1Mjc2NjUyNzY3NUBpbWFnZTAw
Mi5naWYiIG86dGl0bGU9ImxvZ290aXBvIi8+DQo8L3Y6c2hhcGU+PCFbZW5kaWZdLS0+PCFb
aWYgIXZtbF0+PGltZyBib3JkZXI9MCB3aWR0aD0xODEgaGVpZ2h0PTYyDQpzcmM9ImNpZDo1
NTI3NjY1Mjc2NzVAaW1hZ2UwMDIuZ2lmIiB2OnNoYXBlcz0iX3gwMDAwX2kxMDI2Ij48IVtl
bmRpZl0+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgYWxp
Z249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4gbGFuZz1FTi1VUw0K
c3R5bGU9J2ZvbnQtc2l6ZToxMy4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDttc28t
YW5zaS1sYW5ndWFnZTpFTi1VUyc+UGhvbmU6DQo1NSCWIDExIJYgNDM2OCA3NzgyPHNwYW4g
c3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj6goKAgPC9zcGFuPkZheDogNTUgliAxMSCWDQo0
MzY4IDg2MDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBh
bGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48c3Bhbg0Kc3R5bGU9J2Zv
bnQtc2l6ZToxMy4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdCc+ZS1tYWlsPHNwYW4N
CnN0eWxlPSdjb2xvcjojMzM2NkZGJz46IDwvc3Bhbj48Yj48c3BhbiBzdHlsZT0nY29sb3I6
I0ZGNjYwMCc+PGENCmhyZWY9Im1haWx0bzpub3ZhbHV6QGFub3ZhbHV6LmNvbS5iciI+PHNw
YW4gc3R5bGU9J2NvbG9yOiNGRjY2MDA7dGV4dC1kZWNvcmF0aW9uOg0Kbm9uZTt0ZXh0LXVu
ZGVybGluZTpub25lJz5leHRlcmlvckBhbm92YWx1ei5jb20uYnI8L3NwYW4+PC9hPiA8bzpw
PjwvbzpwPjwvc3Bhbj48L2I+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIGFs
aWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxiPjxzcGFuDQpzdHlsZT0n
Zm9udC1zaXplOjEzLjBwdDttc28tYmlkaS1mb250LXNpemU6MTIuMHB0O2NvbG9yOiNGRjY2
MDAnPjwhW2lmICFzdXBwb3J0RW1wdHlQYXJhc10+Jm5ic3A7PCFbZW5kaWZdPjxvOnA+PC9v
OnA+PC9zcGFuPjwvYj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjE0LjBwdDttc28tYmlkaS1mb250LXNpemU6MTIuMHB0Jz48IVtpZiAhc3Vw
cG9ydEVtcHR5UGFyYXNdPiZuYnNwOzwhW2VuZGlmXT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjE0LjBwdDtt
c28tYmlkaS1mb250LXNpemU6MTIuMHB0Jz48IVtpZiAhc3VwcG9ydEVtcHR5UGFyYXNdPiZu
YnNwOzwhW2VuZGlmXT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05v
cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjE0LjBwdDttc28tYmlkaS1mb250LXNpemU6
MTIuMHB0Jz48IVtpZiAhc3VwcG9ydEVtcHR5UGFyYXNdPiZuYnNwOzwhW2VuZGlmXT48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjE0LjBwdDttc28tYmlkaS1mb250LXNpemU6MTIuMHB0Jz48IVtpZiAhc3Vw
cG9ydEVtcHR5UGFyYXNdPiZuYnNwOzwhW2VuZGlmXT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjE0LjBwdDtt
c28tYmlkaS1mb250LXNpemU6MTIuMHB0Jz48IVtpZiAhc3VwcG9ydEVtcHR5UGFyYXNdPiZu
YnNwOzwhW2VuZGlmXT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05v
cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjE0LjBwdDttc28tYmlkaS1mb250LXNpemU6
MTIuMHB0Jz48IVtpZiAhc3VwcG9ydEVtcHR5UGFyYXNdPiZuYnNwOzwhW2VuZGlmXT48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjE0LjBwdDttc28tYmlkaS1mb250LXNpemU6MTIuMHB0Jz48IVtpZiAhc3Vw
cG9ydEVtcHR5UGFyYXNdPiZuYnNwOzwhW2VuZGlmXT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjE0LjBwdDtt
c28tYmlkaS1mb250LXNpemU6MTIuMHB0Jz48IVtpZiAhc3VwcG9ydEVtcHR5UGFyYXNdPiZu
YnNwOzwhW2VuZGlmXT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05v
cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjE0LjBwdDttc28tYmlkaS1mb250LXNpemU6
MTIuMHB0Jz48IVtpZiAhc3VwcG9ydEVtcHR5UGFyYXNdPiZuYnNwOzwhW2VuZGlmXT48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQoNCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2Vu
dGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6
MTQuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Z3JheSc+DQoNCjxociBz
aXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlcj4NCg0KPC9zcGFuPjwvZGl2Pg0KDQoN
CjxwIGNsYXNzPU1zb0NhcHRpb24+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1mYW1p
bHk6QXJpYWw7bXNvLWFuc2ktbGFuZ3VhZ2U6DQpFTi1VUyc+SW4gY2FzZSB5b3UgZG8gbm90
IGRlc2lyZSB0byByZWNlaXZlIG1vcmUgZS1tYWlscywgcGxlYXNlIGFuc3dlciB0aGlzDQpt
ZXNzYWdlIHBsYWNpbmcgaW4gdGhlIHN1YmplY3Q6IFJFTU9WRTwvc3Bhbj48c3BhbiBsYW5n
PUVOLVVTIHN0eWxlPSdtc28tYW5zaS1sYW5ndWFnZToNCkVOLVVTJz48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxl
PSdmb250LXNpemU6MTQuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToNCjEyLjBwdDttc28tYW5z
aS1sYW5ndWFnZTpFTi1VUyc+PCFbaWYgIXN1cHBvcnRFbXB0eVBhcmFzXT4mbmJzcDs8IVtl
bmRpZl0+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw
YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjE0LjBwdDttc28tYmlkaS1mb250LXNp
emU6DQoxMi4wcHQ7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPjwhW2lmICFzdXBwb3J0RW1w
dHlQYXJhc10+Jm5ic3A7PCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9k
aXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K

------=_NextPart_001_002__5527629_76551,74--

------=_NextPart_000_001__5527629_76551,74
Content-Type: image/gif; name="image001.gif"
Content-Transfer-Encoding: base64
Content-ID: <552764416613@image001.gif>

R0lGODlhmACfAPUbACgoJkE5OkNIOFFRT2JiW3Fwb3p7hGNrzm93zmOMEHuEe3uEh3uEzoha
JYl6cZKKeo+MipaMhZuViZ6XqKaYj7ClmbWwrpOUxq2xxsa4t8bGvcDAwMbGxsbGztDO3ubn
88DAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C01TT0ZGSUNF
OS4wGAAAAAxtc09QTVNPRkZJQ0U5LjBAaUuUKgAh/ghHaWYgTHViZQAh/wtNU09GRklDRTku
MBgAAAAMY21QUEpDbXAwNzEyAAAAA0gAc7wAIfkEAQAAIAAsAAAAAJgAnwAABv/Ay2FILBqP
yKRyyWw6n9DoUyitWq/YrNZ56Xq/4LB4TC6bz+i0en0uXkDwuHxOr9vv+Lx+z+/78VRDb3+E
hYaHiIlzgQeDcBcIQwiOipWWl5hxjI6QFxgYnZmio6R7m48IGHIYjaWur6SnIJN0kLC3uImy
B6pzrLnAwXy7vasHwsjJi25wvHS/ytHCu0rS1rmyn9rbxdfescxwoKuU3+aY2c5xGLTn7pay
XbUI7/W64e3G3fb8w+HqcwD2G5hHVr51AgkqrBUO0j5bCyMyJDKIXSpxQvZJjCgLhAUGBxCA
vLixJIiOGD2ZXIlypUtN4V7KPBlzpsuWNkviBAFKZc7/fvF6MRCJgOTPesROXrRw8Oi5pAwc
QXPqLqk8cceoVv03aagqDEO1bqWYMpKqohrFStv5yILapzXXdUn7VllQOEOHGq279p8qhx6b
8vVoobAFDhosVLAgAQIECREcF1YEVWpWtYc5KK4AocCAz6AHCABAurRpCG4PWbWck4Nmzo4p
cPb8ubQA0AICCBh9O/SA0gM4qOZ6wSvPsDItFKAd2rZo36CBRzdtmsBwsjy7mJ2195zmyXkk
AB9N+jOB8+gHEPBd3jyB5ep9Xxd050JqYIbz56/AH3KB8wVUoNkdEAAwwGzovbfccgkWoIBj
nS2Y4HrQzddKModt1t9/FJr3/xl51PE2AAR2ZFAgARAMICFzE77XIoAFLABBBP+5N4CF5ZSi
WWMQ8FcjdLgZGJqCHaoIAQUKSJABHcqNuCCD60U5oXoGFPDYBLJRIAEFEUQG2noF4AiLBQoM
6VuHwCloZWedObDcAxA6VkAEBFTA5HmdSQDll1ZyiGcFEgQKGYQRPBjBlwNEIGYpGFRQHnm3
vRfnk8s9FoEEbkro4pwRrnfpnShCsJ6onoEZWY14CiqnjI49KAGA69lpCFsYIWIBAD1Glulj
Wnb2opqUUlolgyNSQAcHeIqKInRyuidBBRPAFuGCjxFQ5Wf3EUIrT5cVUsEAXD4mZ3rnqddg
jDxCIP/jsNQCquyRx6rXmYrMmdcYbdY+2yu+CXb6nnCzxuVLt4RU8F6gEEIJI6Vxihvsgu6m
yqS8Ng4QgHmzmfsYwvWa2yeYSi5qx1TeEqCAmlW6CKMBBsgJWWS8ItzlpY4tZjABERg7hwX0
mkthpOpZ6XG5FgdA2sWffcwpXab8U80hFQiNmo8wAjitpI3da6mgWgY6wbU9wqFZBspJaC6Q
8aFtMQC9AfBefChqsCg33CASdYoSFKYnhx7Pa14Be6Nn5aWCNtbyfw7sJ9uTUqoNGuAQpFwv
aT8mjUg8ZNi9bN4WkEqhpPD93djnnMZ5apUzPsCfbPxlWrXjSXvgwSekgnb/MZ1Jq3d5OAz0
7vtQQ2ieYo+dF6lgq/9VmiKfM8Is53+p81cB6w8wCDidxodungUfdO/BtY//6FmYIsthgRDd
/WFwiihOUC+Rnbnr2NvMN9wZy5hGMH2WFVTPIbGhgc95WvYsDMhudhMQVe7K5RkJ7A47q4iE
fRJhsHuhiG82QtEnGPMx5jlPXJJ6gOqmJz3XQa9UX7KaqwCVLsfw6HPlypa2agKKkDBNDxwg
mwUoQAAJPMBNAELUl+KEgQm4j18OgFlknkUbwEmPhP5jkAU9lLQ12W9V8/PZiAAWMAiy40J/
yCHZVgeoHgYtPVSk4nlm54Gv9csxXeqRlsD0AMVQ/2CHFaCRhAKFr/8BqGXicuEEDPe/5HGx
i/ShSfrywAGb7e+Rr9Ja5Vo0JA907wPLs1qcGKMnAiTxjiTsn6Y0tbAFETByqIPAg0R4x8Jk
4Ib+wM4S8mAB/YXyiTxkk69SGKUhFaADsuuAAvvmQhYi7lnSo94DpPSrYH3pATN7gA9lSJlw
0G0b4XGihvijGBSdR18wFNyCEGa/J+mySgYAECiTSYFwKeAB74SACCPwABAJwJMFMI0D4NSl
B2iJAkuCh8D8wAFM+ZObjqSAld5TmAoY4G/WGxahXJgwal3tPbZM5vQCRc9+ilCEDqCOi0pD
gI9+tKN5O2T5CKGBAvxQdf/bVMxCC9DQVwXNT4ezomMWUACW+ZRlkesX69pJVB92FKQOyFQB
QKSi85D0YQVwgAIUQM1CbEsPFUjqPBezzZkWLkLDYllPgRonnooTjoa6FFFDWVR6fvSdT/oN
dUzjM2a+xwEQCOgDE2kIeu4zqcjcn0KXB1VKndUx/tsn4ba0VtYhlJ2QSar1EjRXuvbyXO/M
2z0gSAgMUOCvH3WsbOCUPD8th10cWmV8gFM4oraTm/pRzA4hE0WVobGy5VmYVk9ax83yVS4h
8UkdOPDSl35SsEg6FcP4SQCSPkA0zQUOl9YqPVdaIAM63AyXfgjEF62WOkn76IzGK15pqvQP
LWH/hycsQhcLgLa4OVudlqA5s0t5VAJyFdJ58FqaArSTsY6MrXwD9UPGnYtS7+ySoKIpzwZ3
VJ7n9UNLrhKYHMEBU399b0az5Nqi/jOftilpoUbTw8L1k2sd7jBtRaiApO52sa6FzMvGCzNo
NhiaNN0rGJvRjeLYwaD7NOk+ASrgaG0XAq4DEWmYqlRKKXZLAOZwUQvXWihzlJ43jgw/4STP
yPRTZ4jc8Sx6zIDhfhakJmXldQ3Dzf+6WKn5rexlzwVNafLviXgWLJQvlWYHNy+O9U0dPR24
UsDwRDAeeW9xf8i5orK4yZTFLduaGVU7V1c/ehaUNE16407DactaBrQ8/ykQ4Vj+NjCTEIKF
QZBVRae5nW7tLrnOFmfwPunFW+IqLv9JZQrw9tPy/HSd/UzfP9d5iaVuGmfhcL6orLqgQU6z
SQlc21+lpzcem5NarfxaXv93wT7smghlLM1Bj1uEnX5wqPnpZXomWw9XtYMFjCvtaTeGu06W
Kn0Z22ESqrhrVK4ylzgqTR8aFd0IDza6H8zu1HX507KyqtOSUAf31rveU26ta/0d40ANXMZc
yxmUed1rwtG3zj78tFsR60NPd9nYJ57bNT9R8d1ePLQDjvG3Az5ywk1X5Pb1ONe2JHKDR9Pc
DodmyhXuYIZ7WnUrzU4jaD4HDnw22jcveM5m9v8yGP/7ZfbWkshJPvCB85naKK+z2peO7mAf
ldg3JnWYy6HeSbBChsTNepq5LXb79jNOCijsnLoGcMILncDitu/JyZ1yPjMdy8CGvMoh8G5A
xEUeUQFB5sW2Q5vr/fBrQq3gDzeskR/e8Fb2OJ+PevCVlxexCX+9Wz9dVWWf2hmZ9zEcMsDn
rM++4P6kUdXul9PITauJgEO98oU+3637mvVK//S91R5sl7c92GBGb1xakfsyi82fvs566uxc
bs+4rY9RLRf9bAS40wu96Gbf7qCPau76R5/gD/e0WxU890XQIyqs4AjzBmUXp3DQJHZcYn5p
cybr4Ta10VwDoABFx23/qkeBJudr4TZ/aWdu89SBwrZl5SZCEad9y8YURTEUlKAZB/V7nKZl
Q6dH4qEiEnAxRFMjpgUgh0eBOph4ikdPz7dpBpd20jd5Gnh/eiVhAtNsFBYHGZBE0+OBwIZy
ZQeDBqI0yYNXSGZ8PbUcjLWD7tdz/3RsQLhp9GdULZdmbkVbaXgYJHhqeqAY0gQo7BZ7i0V0
pyUsx/cwrjJ0XqiDVxaErbdpP5hyB6dyRjdPucZNbXghszQHTXgkeQR5DRZspqdHDwNHHsc6
smUYO7d8RMdtzheE0GdugbhyTGdpsDU9tVcf1vQJaFFDOcIYdsYlDIdlE9h8avVal4ZH/PN1
/6j3fqhHOKs3hvaXhpumcFyDZ462inaAEoZ2Et63M0q3Q7NXY9sGcA0lZf8FcDzHjRToif8k
csRIhuOIjAC2a2LXgcxYByixeVhRcfzkQ28SR/T1cabnjQJ3j97mhxb4cfK3ekYliR9lcIm4
a6IYgr2FhJzljkphZnXGIDbGbqaXet5GdnwYcMu3fBPYeGmXcuMGYNv0X713YnV2R5U3Eb9l
aOolbw/pJn82aIWXg9xIdoa3j334hVunhiY1aOeoIW11Ur72fCd2kuwYFygICQhQexngUjSS
RP3kZXwYkxMpk1QJjn6IgIB4jo81ZR7Yg1p2YyOokG7YBVGxinknT//PYlRdZpFfyHxuKZVf
OJOQQYs8qYtc1VAbtWIoFX3RNE8etY6suGx9oAGN0VGy8XfwF5VDJ5VsOZGeqGCJaF1stj8E
RojEyHURAETLUX9EWZSCWUN2NzLhl1nUCJOL+Y0XmZEU2Y2ysYlkk12ZdnAZWG6KV2BE8x4n
pzqwFJinpl6uuEgeAU2BZ0u+tjEkV2Wp2ZbI6Vj6AZsDpmlrd2yK12J+UhvY5lIHB5i8KWYU
xhTPBk1u0iX9cYCoWZNTeXprlR+vmV121DXDKIYE5pW2WS4G0h5ng52bpp3NuH1kZgdWV2Az
kiUFd5E811q7mF2vqTgZ954+WIybVj1E0xz/bEMvRKIiRyV3/ScHe6F7deAfVhKHszWT/7Rx
u3hdCTqZ8sWNtSmIGuhR9ARAv2ExcANRfkIhDkBt+rmfy6aSiAYH/eMmC4BXzIlnbBZbeMlO
Oydj9Kd2tCmdYuhlDjAd+qUgogcfkVJSQRiWi1gOJqgdq/Z98JROILpm+zGZKkZlR7ekJtdR
fWlsELJleuJLpWU9JxNXVTgnISg3UaeEXyo2erJMA5BEiXime5aGShqdgJib9RV5Sbd/x7Y3
D8NMUcU4E1ppKYehGfo7mhqNPwZEFnpiYKdgTOqRA7l6bEp/5AV3CLeXQRhFK4IqAkSpQZNE
/pSQixJcYpAHUbMc/25CjudmmQBZXy46h+12bDcmbIilpgcIofcEJaVSSMGSKZnlbr51IZBw
AAywm3LQUpX2UmdYf633lCfnZXDETy9Hriq3qk6aqDQiAAnQVNkmeMlTUseWozr6W6BQFMKF
B43Srbz1kqeqbuj6dqH2cK+HrOQIfSnnADByfKUUV+6hduCxp9fao3JQUG8iXk/pZ7Y4bFGo
ZfOUf7mJjE86jjkDRADAhb4SJQsSPvV5HqLamZYnmOIwEnugHDbXZV+5pDQWhcIGsiILJ2eI
lvDZkZtGAALQADgTr0/SXyCmIgOQndW0bPnaCH1qPn+KsA5mY5Q4bPn3leT4GBEZhUQriv9m
eIBAlFRqAivw4bS9JKj+JLPbyQkjsa97wAGVVo2gRoci+3ZqaH0C6aCk6E8uhk/EYli3QSx3
RYj2OrdwoK/aWnFR04Eim6pvp7PpGpHJ+nceG3uyuXg/1AAB4ABaAqvB8jnRx1UCJUtPswca
kJkL97Ue62Uh67GCJmjpSrTAl2VwGoIEMLoKszCoC5QDgg6tOHN+kLXUx6i0a65EqG42NjOI
Nb0di5j0xWdqCyywul9oBiiN2wfx5gdL2XZziLvtxrvWZ76aC3dsWrIuFngsu19d4ib/9b1b
mgmT65db1jzp1jzjSmNNV2OCJom1KK6QOryxFiByW61Xy1JZm2X/L+e8txu9oUa7BctlDSe9
1/uoHxVkfoUa3xEM4fsH84ZX5ytqGgxo4kqutQiw1Vts1yuuIjhbFqCnyDDCJKxYEVnBmnvB
L3m9PTvBf8a/IIhusPUNOExQmMK/LExjKIyuROxwLKzCmKt0EWAYrvEOSewHk6umlft2xcam
QUy29JRgg5YZ9ivCA1UJGFtsTgxHTEzELzyJY/uRKcWGC7HFfqAcApyuYJx05YpwA8kjs4UB
aewNetwHyuG1kwjH1bdwaEZtz3IYr5kTicwHhYGFZCtteCVk0lTD+SEWl9wHBtViwtZimVJH
WGwYg/EIa3wJ6rkZMXXIlvzKrYzItnzLktYwyroMC7zcy67wy8AMDjQ7zH1RzMZsF7mczGqM
zMw8Dcv8zLggzNJcCdRczQyMzcfshtoMDNfczRLnzOAczNE8zqLwzeYMvuWczpeAzuwMb+v8
zlPLzfI8Cu5cz/cqZvhsz/G8z+FMz/68ugAd0PNstWxw0Aid0Aq90AwdBlvw0BAd0RK9BYww
0RZ90RhN0UEAADs=

------=_NextPart_000_001__5527629_76551,74
Content-Type: image/gif; name="image002.gif"
Content-Transfer-Encoding: base64
Content-ID: <552766527675@image002.gif>

R0lGODlhtQA+AHcAACH/C01TT0ZGSUNFOS4wGAAAAAxtc09QTVNPRkZJQ0U5LjCA8i9WmgAh
/wtNU09GRklDRTkuMBgAAAAMY21QUEpDbXAwNzEyAAAAA0gAc7wAIfkEAQAAQAAsAAAAALUA
PgCG//////j/8Pfw8PDw7+/v7+jv4Ofg4ODg39/f39jf0NfQ0NDQz8/Pz8jPwMfAwMDAv7+/
v7i/sLewsLCwr6+vr6ivoKegoKCgn5+fn5ifkJeQkJCQj4+Pj4iPgIeAgICAf39/f3h/cHdw
cHBwb29vb2hvYGdgYGBgX19fX1hfUFdQUFBQT09PT0hPQEdAQEBAPz8/Pzg/MDcwMDAwLy8v
LygvICcgICAgHx8fHxgfEBcQEBAQDw8PDwgPAAcAAAAAwMDAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAB/+AAIKDGio2h4iJiouMjY6PkJGSk5SVlpAyJg6DnIMGJjw+oqOkpaanqKmq
q6ytrq+wsa08OiACnYIcoiYeGL6/wMHCw8TFxsfIycrLzM3HGh4uPjqbnCQ+KAwEBtzd3t/g
4eLj5OXm5+jp6uvoBA46PASDBD48CgYK+fr7/P3+/wADChxIsKDBgwgNIjCgwQeHQRB8YECg
gGLCixgzatzIMaFFA4YMCELhg0HHkyhTqlzZDwEBDzyqeSjJsqbNmzhbvvRhIRfNfBZTBq04
NKfRowoJ6KLg0yTQcgiKEgSHtKrVgC6XNiXKwITXr2BFMJAqEAEHEyRMoOBA9qpbo1n/fTAF
oMupAQerVBBAiEDaKBr43gpGGndu3Xx3Q6mSEHggRQMsSMFoPLiyzcJb7zFQrGps232PI4+a
XHnhQnyfLXtUKjezgc2sXBhIDfSeaFGkBUdV4cKFirGqT2Km+/M1Z1UOKP8LLVm5VQMYRqGY
Hbzj8MOaj6eSARyr7ea6KSjWQb06x+vFYbci4Zwf81GyBRPw60MDbfMF0dtV3wpCe33viRKf
UPfdg5coLAT1WVRRKcRgRg2uphVx+2mnigyztRWgD7kx+CBBFEkVIUCQjZIcYv6ECBqILf3j
zVAFLseaYelZqIoFBGh4jwrNUQSDDjjoIOSQRBYJz1gGSECL/5A8uCCQAboguNc9GBQplwJK
LckDCP89BcqQPrBX1F1A4oDDRPkQgMGSRrZJjUX6IcYfKiaQIsOI7u3YowI0yOKDAwtJUIoM
AhHQpygShGiADqZQgOVMo5jQZUUGkETKdGMeKIp99yiAQyzdxZndKg5cMwoL/z3G42jUHRoL
oEmWAgNALpnqgwl7LQRpKYmyNgp7T1oaqXN3kTIRRa6+AihQM7o25ykQIHCcBe2pumeyPtCg
FgrccmuCDKTAKqhktEKgGA0VVcSADaf0GqUowAZUaSmS9lPsKMdi4EK3/HaLlnahNkuhnDaS
IgEBIpCCA1F5gnRtKbZs481OJgYq6/9yBtCnQWAG2MprXL9Oeo+wu5Snz72ioHnaxBMzIGtj
cS70rCm9riqKCibv4zCr+WArgogghGsxuS0hYK4ogDHoMirukhIviSTf6hwCmkpEm0UwkMJD
tAAKjB3VBY+S6GuMmlitzRwGBi4pP7cUdMUIjDuaizajWVHUpFCw0LthXh11ve5VzemT0TlN
magELK0KBAIYIEDhonAn8cT0+SCDADmy63Tj3wiQ8ChYChCRneFQfKvEprcrD98kcD6OAH8D
AE7ixk4uDu2k0EDA7txE5TVNCLCgAgQOFG/88Q6w0JsLMFjAwPMMSLD89C5gAD0DGMDQmwTX
MwCC9tTDwAH/9A7w5gIJ3VOgPPUoOPC8AjCsDwMExBOvAfIoKO8B9ApoQP3/vbmf8RjgPwCa
gAHFY0A0ADi95pFPAebrDQz09jtK+QAHt8AFJzQnChR0Ym2lgAAnNIWATvCNFBrgxNpg0AkE
nIIEhCCFCzhhgRSqUBQPGQQFWjEXHaKChYN4myriwQlPlcI+UGoNcSjFAxtkUIOC8BknEFA2
UohwEHJTQCd2VYocAkAAa2NBJxSgHR3IAwAKKIUWB+EDD3Qia22kIQ87scNTAFEQQkyFGzkB
R2PtTYm6YKIToTgIbEmEE6MzGCeyuEVU2PCLYRxjFXEoCAH00Qci4ETQvCgIOO5R/xAWmOMi
f6jJVbDgiQCoGr4MUMGFNBGVGjSkD9YoiDopEouga+QpHglGBEmSFDY4IxlH88SlcRIAnpQj
K3ooiDqa4o4AyOMpqlFJEBqLlRMKpCsHSUgAyNIGnZikBEYpCloKgosoHEQvfSDGIopzEJW7
YicpyUdRfBIAoVwmHUkZRFXMkBOfMwUGsAnIWW4TlriQZX1GeEtBMJIT6BwFLyPpzlGoIIaj
kAE5HfJGeypzFcwEgDNlVUpU2KCE80jFQFtpgFd205upYKYQx4nLcurSFBP1ZUXrUY1FjYIH
NAUAAj5Fz0EkcxD5BOk+7VjSUxzzhNdkqUu7qdB6iGQQZf8LKgAeOoiIbkqdFB2EAsoGgn6O
oqyDINkxjwrKVvSEEyOVTFNNMUZVrDSbBm0pNwlZVXYWk1Hy3GouIepIsOp0EOrJYEtJcVUA
KO6r9YwjUt3aiaSS1Kw47QTaBEpQGgkSoZ3oK0dxGViunrOw1TysIGADw9OO4p6bRatRPTpZ
Vry1ts+c61/OKAhVclaqe4WiaEvCCRfcVrA2JewuDcvOTmwGBhl0AGdO6QkSgEAE2BVBYJFJ
27batrL8xCO0OmrXzvrksy8dLjgRW9rBdhW1kFStY30gT5JR86Wzlax3V3FcfIY3mqbQaBFZ
cdeCopeqrZAtLkwLAK8uNLXNHaH/gJGLNPzigq3+/e5HLyveUqC0kps9RYE9e9D0uqK/NZ3l
TY/I3HaKlQGVJGo9YDwPfjyvsfPUb4b5C16mYraDPV7FiM9bYgS3AoMaZLA0JdpiQkLuVm9k
E5B00F8MWzYV/X1y7nSrVQBYU6XmXeJCdBBcXAiAg6zI5ILd20wUgMUrKAiqAA7l4k4IgDPB
vfIoqtxdNHqAA4AOdKA1cI3+KuDPguZAL+ba2kE4AC0kiLSkJS0CcA1ZzHoFrTrRzAoTrDm5
FlYnnaHIRWaOFRV81jF+64RiC+cRA6HmREMurU0DXFDTg5CxK8xJYV5bWABEhaajt8wJvOEr
tH1+aRp5/xJrgJLimBaeyUSSSGIEeOCRhISGB7bN7W53W9GwLiIIto3jWEMDBK3GALfPwm0Q
YEDRiv42CGg8CHWDYLvdhMC4k+OhfvubQRL4swdAcN9QO+DeMTPNvz3EDtQAZWWpWfjKlMMg
bhDAskAlx5h6Ryt/c9wjL5K4yDP0O5PESOT/rg2A8OQRlgMIH7r2wJQWvnIIhQjlNE+XRkSF
H40QII/2cHnPz1PyoWckVqTwgMiMfpHhNMQpTD+IS6x5pxhFPT+seSsooH71qchtxlbvumN+
Tl9BNIRrYh+IA9CMgimlnegk0AFK6YGhsBsdASKI3/q68/adG00HHkyrD0CgcIucG/7wiE/8
7hafo8Q7/vGQf/xr+mROQ/lABdzLR/c2z/nOe/7zoAe95kNP+tKb/vSo37wDNMAuT+NCBIzi
gexnT/va2/72uM+97nfP+977/vfAD37vRaEDfM/DAt9joPKXz/zmO//50I++9KdPfReYgANd
brb2t8/97nv/++APv/jHT/7ym//82w8EADs=

------=_NextPart_000_001__5527629_76551,74--



From noreply@sourceforge.net  Thu Jan 10 10:28:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 Jan 2002 02:28:07 -0800
Subject: [Patches] [ python-Patches-501713 ] compileall.py -d errors
Message-ID: <E16OcRL-0001n9-00@usw-sf-web1.sourceforge.net>

Patches item #501713, was opened at 2002-01-10 02:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=501713&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bastian Kleineidam (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: compileall.py -d errors

Initial Comment:
the option -d is not handled properly, the
compileall.py script generates files in the
wrong directory.

Patch is for Python 2.1.1.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=501713&group_id=5470


From noreply@sourceforge.net  Thu Jan 10 12:40:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 Jan 2002 04:40:31 -0800
Subject: [Patches] [ python-Patches-481080 ] Read Me file Patch for Python 2.1.2
Message-ID: <E16OeVT-0007Rq-00@usw-sf-web2.sourceforge.net>

Patches item #481080, was opened at 2001-11-12 14:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481080&group_id=5470

Category: Documentation
Group: Python 2.1.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dan Wolfe (dkwolfe)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Read Me file Patch for Python 2.1.2

Initial Comment:
The following paragraph replaces the existing Mac 
OS X v10.1 paragraph.  It assumes that patches 
481060 and 481075 are taken.

- Dan

Mac OS X 10.1: Run configure with ./configure --
with-suffix=.x  --with-dyld".  This generates 
executable file: 'python.x'  (it cannot be named 
'python' on an HFS or HFS+ disk as the file name 
clashes with directory 'Python').
        
        The makefile is set up to correctly handle two-
level namespaces for Mac OS X v10.1 and 10.0.x 
systems. However, running the prebinding tool on 
Mac OS X 10.0.x again will cause the tool to break 
as it cannot handle two level namespaces.
        
        The default Mac OS X has a default stacksize 
of 512K which  causes the regular expression 
tests (RE and SRE) to SEGV. To  temporarily 
increase the stacksize, type 'limit stacksize 2M' in 
the terminal window before running 'make test'.
        
        The test_largefile test will work on HFS+ and 
UFS filesystem, providing you have enough space 
and time.
        
        After sudo 'make installation', do the following 
commands:
        cd /usr/local/bin/
        sudo mv python.x python
        sudo mv python2.1.x python2.1

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

Comment By: Jack Jansen (jackjansen)
Date: 2001-12-05 06:47

Message:
Logged In: YES 
user_id=45365

Let 481075 rest for now, I need to do this for the trunk too. I'll flag the checkin message.

If you apply my new 489388 then everything should be fine for 2.1.2 for OSX.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2001-12-04 23:01

Message:
Logged In: YES 
user_id=29957

481060 is in, but not 481075 - I don't have access to Mac OS X
for easy testing of this. 
Hm, or does cf.sf.net have OS X boxes?


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

Comment By: Jack Jansen (jackjansen)
Date: 2001-12-02 16:03

Message:
Logged In: YES 
user_id=45365

This sounds pretty reasonable to me.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-11-28 23:25

Message:
Logged In: YES 
user_id=3066

Assigned to the Mac OS expert for evaluation and integration.

Jack, note that this is for the release21-maint branch.  Thanks!

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=481080&group_id=5470


From noreply@sourceforge.net  Thu Jan 10 20:33:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 Jan 2002 12:33:21 -0800
Subject: [Patches] [ python-Patches-502023 ] Correct LFS compilation documentation
Message-ID: <E16Olt3-0005Ct-00@usw-sf-web2.sourceforge.net>

Patches item #502023, was opened at 2002-01-10 12:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502023&group_id=5470

Category: Documentation
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Martin v. Löwis (loewis)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Correct LFS compilation documentation

Initial Comment:
As discussed, the current LFS instructions break in
some shells. Attached is a patch that uses Barry's
proposal of always setting CC.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502023&group_id=5470


From noreply@sourceforge.net  Thu Jan 10 22:33:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 Jan 2002 14:33:37 -0800
Subject: [Patches] [ python-Patches-502080 ] BaseHTTPServer send_error bug fix
Message-ID: <E16OnlR-0006cx-00@usw-sf-web2.sourceforge.net>

Patches item #502080, was opened at 2002-01-10 14:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502080&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Gardner (jgardn)
Assigned to: Nobody/Anonymous (nobody)
Summary: BaseHTTPServer send_error bug fix

Initial Comment:
BaseHTTPServer's send_error function didn't send 
"Content-Type: text/html". While this was okay for 
Mozilla 0.9.7, Konqueror 2.2.2 rendered it as plain 
text.

I added one line to send the Content-Type and 
everything works great. A BETTER solution would be to 
figure out what kind of document the error message 
is, but that is left as an exercise for a beefier 
HTTP server, which is not what BaseHTTPServer is 
intended to be.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502080&group_id=5470


From noreply@sourceforge.net  Thu Jan 10 22:38:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 Jan 2002 14:38:53 -0800
Subject: [Patches] [ python-Patches-502023 ] Correct LFS compilation documentation
Message-ID: <E16OnqX-0007WK-00@usw-sf-web3.sourceforge.net>

Patches item #502023, was opened at 2002-01-10 12:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502023&group_id=5470

Category: Documentation
Group: Python 2.1.2
>Status: Closed
>Resolution: Accepted
Priority: 7
Submitted By: Martin v. Löwis (loewis)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Correct LFS compilation documentation

Initial Comment:
As discussed, the current LFS instructions break in
some shells. Attached is a patch that uses Barry's
proposal of always setting CC.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-01-10 14:38

Message:
Logged In: YES 
user_id=3066

Checked in as Doc/lib/libposix.tex revision 1.56.4.3.  This
is going into Python 2.1.2 *only*; the trunk and 2.2.*
branch are unaffected.

Thanks!

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502023&group_id=5470


From noreply@sourceforge.net  Thu Jan 10 23:33:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 Jan 2002 15:33:38 -0800
Subject: [Patches] [ python-Patches-496705 ] Additions & corrections to libmacui.tex
Message-ID: <E16OohW-0007M4-00@usw-sf-web2.sourceforge.net>

Patches item #496705, was opened at 2001-12-25 18:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496705&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dean Draayer (draayer)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Additions & corrections to libmacui.tex

Initial Comment:
Includes a thorough description of the relatively new GetArgv function.

Greatly expanded the description of the ProgressBar class, as well as updating the description to reflect recent changes to this class.

Numerous minor changes - mostly grammatical - made throughout the document.


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-01-10 15:33

Message:
Logged In: YES 
user_id=3066

Checked in the GetArgv() docs for Python 2.1.2
(Doc/mac/libmacui.tex revision 1.16.6.1); there just wasn't
time to worry about making sure I had the ProgressBar docs
right (due to the 2.2 addition of the indeterminate
version), so I punted on that for 2.1.2.

I still need to do the "right thing" for 2.2.* and the
trunk.  It shouldn't take long, but I can't right now.

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

Comment By: Dean Draayer (draayer)
Date: 2002-01-08 08:42

Message:
Logged In: YES 
user_id=307112

I don't know which version introduced GetArgv().  I think it was 2.0, but since it wasn't documented I never saw it until 2.1.

As far as the barber-pole style progress bars, that will be new in 2.2.  So you may want to anotate the appropriate material with a version number there as well.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-01-04 19:53

Message:
Logged In: YES 
user_id=3066

Attached a revised version of the patch (minor changes only,
plus fix one markup error).

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-01-04 19:41

Message:
Logged In: YES 
user_id=3066

Excellent!

What version of MacPython introduced the GetArgv() function?
 I'd like to add a version annotation and back-port the
portions of the patch that belong in the Python 2.1.2 and
2.2.1 documentation.

Thanks for the contribution!

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496705&group_id=5470


From noreply@sourceforge.net  Fri Jan 11 01:46:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 Jan 2002 17:46:08 -0800
Subject: [Patches] [ python-Patches-487906 ] update inline docs in stringobject.c
Message-ID: <E16Oqlk-0000aU-00@usw-sf-web2.sourceforge.net>

Patches item #487906, was opened at 2001-12-01 12:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470

Category: None
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Zooko Ozoko (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: update inline docs in stringobject.c

Initial Comment:
--- Objects/stringobject.c      2001/11/28 20:27:42   
 2.141
+++ Objects/stringobject.c      2001/12/01 20:40:09
@@ -19,19 +19,26 @@
 #endif
 
 /*
-   Newsizedstringobject() and newstringobject() try in
certain cases
+   PyString_FromStringAndSize() and
PyString_FromString() try in certain cases
    to share string objects.  When the size of the
string is zero,
    these routines always return a pointer to the same
string object;
    when the size is one, they return a pointer to an
already existing
    object if the contents of the string is known.  For
-   newstringobject() this is always the case, for
-   newsizedstringobject() this is the case when the
first argument in
+   PyString_FromString() this is always the case, for
+   PyString_FromStringAndSize() this is the case when
the first argument in
    not NULL.
-   A common practice to allocate a string and then
fill it in or
-   change it must be done carefully.  It is only
allowed to change the
-   contents of the string if the obect was gotten from
-   newsizedstringobject() with a NULL first argument,
because in the
+   A common practice of allocating a string and then
filling it in or
+   changing it must be done carefully.  It is only
allowed to change the
+   contents of the string if the object was gotten from
+   PyString_FromStringAndSize() with a NULL first
argument, because in the
    future these routines may try to do even more
sharing of objects.
+
+   The parameter `size' denotes number of characters
in the string, not number 
+   of bytes requires to store it, and does not count
the null terminating 
+   character.
+
+   On the other hand, the member `op->ob_size' denotes
the number of bytes 
+   used for storing the string, including the null
terminating character.
 */
 PyObject *
 PyString_FromStringAndSize(const char *str, int size)
@@ -58,7 +65,7 @@


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

>Comment By: Zooko Ozoko (zooko)
Date: 2002-01-10 17:46

Message:
Logged In: YES 
user_id=52562

Hi, I have updated these docs one last time, throwing out
all the original docs and rewriting.  Now I am happy with them.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-03 00:25

Message:
Logged In: YES 
user_id=21627

Even though this comment is right, it now reads as a
contradiction, since two sentences later, it says

If the `str' argument is not NULL, then it must point to a
null-terminated string of length `size'.
I've reformulated this somewhat, and commmitted your text.

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

Comment By: Zooko Ozoko (zooko)
Date: 2001-12-02 10:50

Message:
Logged In: YES 
user_id=52562

Here's one more addition to the in-line docs.  I was trying
to optimize `PyString_FromStringAndSize()' and I broke it
because I didn't realize this fact, so I added this fact to
the docs.  :-)

(pasted and attached)

--- Objects/stringobject.c	2001/12/02 18:09:41	2.142
+++ Objects/stringobject.c	2001/12/02 18:47:48
@@ -33,6 +33,10 @@
    a NULL first argument, because in the future these
routines may try to do 
    even more sharing of objects.
 
+   The string in the  `str' parameter does not have to be
null-character 
+   terminated.  (Therefore it is safe to construct a
substring by using 
+   `PyString_FromStringAndSize(origstring, substrlen)'.)
+
    The parameter `size' denotes number of characters to
allocate, not counting 
    the null terminating character.  If the `str' argument
is not NULL, then it 
    must point to a null-terminated string of length `size'.


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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-02 10:10

Message:
Logged In: YES 
user_id=21627

It's not just upload that is difficult; download has its
speed bumps as well. Mozilla insists to call all files
downloaded from SF "download.php", no matter what filename
SF has recorded...

Thanks for the patch; it is in stringobject.c 2.142.

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

Comment By: Zooko Ozoko (zooko)
Date: 2001-12-02 08:47

Message:
Logged In: YES 
user_id=52562

Heh heh heh.  I can't wait for the day that we can remotely
collaborate with something other than a web browser as the
user interface.  Okay, sorry, here is a newer version of the
patch.



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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-02 07:34

Message:
Logged In: YES 
user_id=21627

There is currently nothing attached.

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

Comment By: Zooko Ozoko (zooko)
Date: 2001-12-01 12:44

Message:
Logged In: YES 
user_id=52562

Okay I guess that's all mangled.  DAMN, I hate trying to use
a web browser for anything other than browsing.

Anyway, I've attached the same patch.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470


From noreply@sourceforge.net  Fri Jan 11 01:48:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 Jan 2002 17:48:50 -0800
Subject: [Patches] [ python-Patches-487906 ] update inline docs in stringobject.c
Message-ID: <E16OqoM-0001ck-00@usw-sf-web3.sourceforge.net>

Patches item #487906, was opened at 2001-12-01 12:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470

Category: None
Group: None
>Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Zooko Ozoko (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: update inline docs in stringobject.c

Initial Comment:
--- Objects/stringobject.c      2001/11/28 20:27:42   
 2.141
+++ Objects/stringobject.c      2001/12/01 20:40:09
@@ -19,19 +19,26 @@
 #endif
 
 /*
-   Newsizedstringobject() and newstringobject() try in
certain cases
+   PyString_FromStringAndSize() and
PyString_FromString() try in certain cases
    to share string objects.  When the size of the
string is zero,
    these routines always return a pointer to the same
string object;
    when the size is one, they return a pointer to an
already existing
    object if the contents of the string is known.  For
-   newstringobject() this is always the case, for
-   newsizedstringobject() this is the case when the
first argument in
+   PyString_FromString() this is always the case, for
+   PyString_FromStringAndSize() this is the case when
the first argument in
    not NULL.
-   A common practice to allocate a string and then
fill it in or
-   change it must be done carefully.  It is only
allowed to change the
-   contents of the string if the obect was gotten from
-   newsizedstringobject() with a NULL first argument,
because in the
+   A common practice of allocating a string and then
filling it in or
+   changing it must be done carefully.  It is only
allowed to change the
+   contents of the string if the object was gotten from
+   PyString_FromStringAndSize() with a NULL first
argument, because in the
    future these routines may try to do even more
sharing of objects.
+
+   The parameter `size' denotes number of characters
in the string, not number 
+   of bytes requires to store it, and does not count
the null terminating 
+   character.
+
+   On the other hand, the member `op->ob_size' denotes
the number of bytes 
+   used for storing the string, including the null
terminating character.
 */
 PyObject *
 PyString_FromStringAndSize(const char *str, int size)
@@ -58,7 +65,7 @@


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

>Comment By: Zooko Ozoko (zooko)
Date: 2002-01-10 17:48

Message:
Logged In: YES 
user_id=52562

reopening for new version of docs


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

Comment By: Zooko Ozoko (zooko)
Date: 2002-01-10 17:46

Message:
Logged In: YES 
user_id=52562

Hi, I have updated these docs one last time, throwing out
all the original docs and rewriting.  Now I am happy with them.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-03 00:25

Message:
Logged In: YES 
user_id=21627

Even though this comment is right, it now reads as a
contradiction, since two sentences later, it says

If the `str' argument is not NULL, then it must point to a
null-terminated string of length `size'.
I've reformulated this somewhat, and commmitted your text.

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

Comment By: Zooko Ozoko (zooko)
Date: 2001-12-02 10:50

Message:
Logged In: YES 
user_id=52562

Here's one more addition to the in-line docs.  I was trying
to optimize `PyString_FromStringAndSize()' and I broke it
because I didn't realize this fact, so I added this fact to
the docs.  :-)

(pasted and attached)

--- Objects/stringobject.c	2001/12/02 18:09:41	2.142
+++ Objects/stringobject.c	2001/12/02 18:47:48
@@ -33,6 +33,10 @@
    a NULL first argument, because in the future these
routines may try to do 
    even more sharing of objects.
 
+   The string in the  `str' parameter does not have to be
null-character 
+   terminated.  (Therefore it is safe to construct a
substring by using 
+   `PyString_FromStringAndSize(origstring, substrlen)'.)
+
    The parameter `size' denotes number of characters to
allocate, not counting 
    the null terminating character.  If the `str' argument
is not NULL, then it 
    must point to a null-terminated string of length `size'.


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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-02 10:10

Message:
Logged In: YES 
user_id=21627

It's not just upload that is difficult; download has its
speed bumps as well. Mozilla insists to call all files
downloaded from SF "download.php", no matter what filename
SF has recorded...

Thanks for the patch; it is in stringobject.c 2.142.

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

Comment By: Zooko Ozoko (zooko)
Date: 2001-12-02 08:47

Message:
Logged In: YES 
user_id=52562

Heh heh heh.  I can't wait for the day that we can remotely
collaborate with something other than a web browser as the
user interface.  Okay, sorry, here is a newer version of the
patch.



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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-02 07:34

Message:
Logged In: YES 
user_id=21627

There is currently nothing attached.

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

Comment By: Zooko Ozoko (zooko)
Date: 2001-12-01 12:44

Message:
Logged In: YES 
user_id=52562

Okay I guess that's all mangled.  DAMN, I hate trying to use
a web browser for anything other than browsing.

Anyway, I've attached the same patch.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470


From noreply@sourceforge.net  Fri Jan 11 06:26:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 Jan 2002 22:26:43 -0800
Subject: [Patches] [ python-Patches-502205 ] Fix webbrowser running on MachoPython
Message-ID: <E16Ov9H-0004qd-00@usw-sf-web3.sourceforge.net>

Patches item #502205, was opened at 2002-01-10 22:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502205&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven J. Burr (sburrious)
Assigned to: Jack Jansen (jackjansen)
Summary: Fix webbrowser running on MachoPython

Initial Comment:
Allows webbrowser.open call in the Unix version of python running on Mac OS X to open a url in Internet Explorer.  Presently, a call to webbrowser.open on this platform either runs a terminal-based browser, such as lynx, if available, or fails.

The patch is a context diff against version 1.27 of webbrowser, which appears to be the latest version in CVS.  It adds a MacOSX browser class and a test for Mac OS X systems running the Unix version of python.  I have tested it successfully several times on my Mac OS X system.

I included:

    assert url not in "'"

from the 1.27 version in the MacOSX open method, even though the method calls os.popen rather than os.system to launch the browser.  It seemed likely os.popen would raise similar security concerns.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502205&group_id=5470


From noreply@sourceforge.net  Fri Jan 11 08:27:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 Jan 2002 00:27:48 -0800
Subject: [Patches] [ python-Patches-487906 ] update inline docs in stringobject.c
Message-ID: <E16Ox2S-0006HM-00@usw-sf-web3.sourceforge.net>

Patches item #487906, was opened at 2001-12-01 12:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Zooko Ozoko (zooko)
>Assigned to: Martin v. Löwis (loewis)
Summary: update inline docs in stringobject.c

Initial Comment:
--- Objects/stringobject.c      2001/11/28 20:27:42   
 2.141
+++ Objects/stringobject.c      2001/12/01 20:40:09
@@ -19,19 +19,26 @@
 #endif
 
 /*
-   Newsizedstringobject() and newstringobject() try in
certain cases
+   PyString_FromStringAndSize() and
PyString_FromString() try in certain cases
    to share string objects.  When the size of the
string is zero,
    these routines always return a pointer to the same
string object;
    when the size is one, they return a pointer to an
already existing
    object if the contents of the string is known.  For
-   newstringobject() this is always the case, for
-   newsizedstringobject() this is the case when the
first argument in
+   PyString_FromString() this is always the case, for
+   PyString_FromStringAndSize() this is the case when
the first argument in
    not NULL.
-   A common practice to allocate a string and then
fill it in or
-   change it must be done carefully.  It is only
allowed to change the
-   contents of the string if the obect was gotten from
-   newsizedstringobject() with a NULL first argument,
because in the
+   A common practice of allocating a string and then
filling it in or
+   changing it must be done carefully.  It is only
allowed to change the
+   contents of the string if the object was gotten from
+   PyString_FromStringAndSize() with a NULL first
argument, because in the
    future these routines may try to do even more
sharing of objects.
+
+   The parameter `size' denotes number of characters
in the string, not number 
+   of bytes requires to store it, and does not count
the null terminating 
+   character.
+
+   On the other hand, the member `op->ob_size' denotes
the number of bytes 
+   used for storing the string, including the null
terminating character.
 */
 PyObject *
 PyString_FromStringAndSize(const char *str, int size)
@@ -58,7 +65,7 @@


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

Comment By: Zooko Ozoko (zooko)
Date: 2002-01-10 17:48

Message:
Logged In: YES 
user_id=52562

reopening for new version of docs


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

Comment By: Zooko Ozoko (zooko)
Date: 2002-01-10 17:46

Message:
Logged In: YES 
user_id=52562

Hi, I have updated these docs one last time, throwing out
all the original docs and rewriting.  Now I am happy with them.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-03 00:25

Message:
Logged In: YES 
user_id=21627

Even though this comment is right, it now reads as a
contradiction, since two sentences later, it says

If the `str' argument is not NULL, then it must point to a
null-terminated string of length `size'.
I've reformulated this somewhat, and commmitted your text.

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

Comment By: Zooko Ozoko (zooko)
Date: 2001-12-02 10:50

Message:
Logged In: YES 
user_id=52562

Here's one more addition to the in-line docs.  I was trying
to optimize `PyString_FromStringAndSize()' and I broke it
because I didn't realize this fact, so I added this fact to
the docs.  :-)

(pasted and attached)

--- Objects/stringobject.c	2001/12/02 18:09:41	2.142
+++ Objects/stringobject.c	2001/12/02 18:47:48
@@ -33,6 +33,10 @@
    a NULL first argument, because in the future these
routines may try to do 
    even more sharing of objects.
 
+   The string in the  `str' parameter does not have to be
null-character 
+   terminated.  (Therefore it is safe to construct a
substring by using 
+   `PyString_FromStringAndSize(origstring, substrlen)'.)
+
    The parameter `size' denotes number of characters to
allocate, not counting 
    the null terminating character.  If the `str' argument
is not NULL, then it 
    must point to a null-terminated string of length `size'.


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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-02 10:10

Message:
Logged In: YES 
user_id=21627

It's not just upload that is difficult; download has its
speed bumps as well. Mozilla insists to call all files
downloaded from SF "download.php", no matter what filename
SF has recorded...

Thanks for the patch; it is in stringobject.c 2.142.

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

Comment By: Zooko Ozoko (zooko)
Date: 2001-12-02 08:47

Message:
Logged In: YES 
user_id=52562

Heh heh heh.  I can't wait for the day that we can remotely
collaborate with something other than a web browser as the
user interface.  Okay, sorry, here is a newer version of the
patch.



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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-02 07:34

Message:
Logged In: YES 
user_id=21627

There is currently nothing attached.

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

Comment By: Zooko Ozoko (zooko)
Date: 2001-12-01 12:44

Message:
Logged In: YES 
user_id=52562

Okay I guess that's all mangled.  DAMN, I hate trying to use
a web browser for anything other than browsing.

Anyway, I've attached the same patch.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470


From evsnew@email.ru  Fri Jan 11 15:23:18 2002
From: evsnew@email.ru (VISA SUPPORT)
Date: Fri, 11 Jan 2002 18:23:18 +0300
Subject: [Patches] ÂÈÇÎÂÛÅ ÓÑËÓÃÈ, VIP-Øåðåìåòüåâî-2 / VISA SUPPORT, VIP-services
Message-ID: <200201111632.g0BGVsg15140@card.co.ru>

DQrCyMfOwtvFINPRy9PDyA0KDQrO9O7w7Ovl7ejlIO/w6OPr4Pjl7ejpIOTr/yDIzc7R0tDA
zdbFwiDiINDu8fHo/i4NCs7k7e7q8ODy7e7lIO3gIDEg7OXx//YgLSAkIDI1DQrM7e7j7urw
4PLt7uUg7eAgMSDj7uQtICQgMTUwDQoNCirP8ODi7uL75SDi7u/w7vH7IO7y7e7x6PLl6/zt
7iDv8OXh++Lg7ej/IOjt7vHy8ODt7fv1IOPw4Obk4O0g7eAg8uXw8Ojy7vDo6CDQ1CwNCiDv
8O7h6+Xs7fvlIPHr8/fg6C4NCirC7u/w7vH7IOL75efk4CDQztHRyN/NIOfgIPDz4eXmLCDu
9O7w7Ovl7ejlIO3g5Ovl5uD56PUg5O7q8+zl7fLu4g0KICjCyMfbKS4NCg0KDQpWLkkuUC4g
zsHRy9PGyMLAzcjFIMIgwN3Qzs/O0NLA1Q0KKNjl8OXs5fL85eLuIDEsMiAsIMTu7O7k5eTu
4u4sIMLt8+ru4u4pOg0KDQrO8OPg7ejn4Pbo/yDi8fLw5fcg6CDv8O7i7uTu4iD35fDl5yBW
LkkuUC4t5+Dr+yDg/fDu7+7w8u7iOg0KtyDu8uTl6/zt++kg7+7j8ODt6Pft++kg6u7t8vDu
6/wNCrcg7+Xw8e7t4Ov87e7lIO7h8evz5uji4O3o5SDi7eUg7vfl8OXk6A0KtyDq7uz07vDy
4OHl6/zt++Ug7+7s5fnl7ej/DQq3IOLu5+zu5u3u8fL8IOLx8vDl9+gg8yDy8ODv4CDx4Ozu
67jy4A0KtyDy8ODt8fTl8A0KDQoNCs7UztDMy8XNyMUgx8DD0MDNz8DRz87Q0s7CDQoo1uXt
+yDz6uDn4O37IOTr/yDm6PLl6+XpIMzu8eri+yDoIMzu8eouIO7h6+Dx8ugpDQoNCjM1IPDg
4S7k7eXpIC0gJDcwDQoyMS0yMyDw4OEu5O3l6SAtICQxNDANCjE1LTE3IPDg4S7k7eXpIC0g
JDE4MA0KMTAtMTIg8ODhLuTt5ekgLSAkMjYwDQo4LTkg8ODhLiDk7eXpIC0gJDMzMA0KNi03
IPDg4S4g5O3l6SAtICQzOTANCg0Kz+4gwuD45ezzIOfg7/Du8fMg4vv46+XsIOru7O/r5ery
IO3l7uH17uTo7Pv1DQrk7urz7OXt8u7iIOTr/yDu9O7w7Ovl7ej/IOfg4/Dg7e/g8e/u8PLg
Lg0KDQrBxdHPy8DSzdvJIMLbxcfEIMrT0NzF0MAgyiDCwMwgwiDO1MjRIMIgz9DFxMXLwNUg
4y4gzM7RysLbDQoNCtLFyy4v1MDK0TogKDA5NSkgNzk3LTA0LTgyLCAgNzk3LTA0LTA4LCAg
MTA3LTc4LTU4DQpFLW1haWw6IGV2c25ld0BlbWFpbC5ydQ0KDQoNClZJU0EgU1VQUE9SVA0K
DQpMZWdhbGl6YXRpb24gb2YgdGhlIFJ1c3NpYW4gdmlzYS1pbnZpdGF0aW9ucyBmb3IgZm9y
ZWlnbiBjaXRpemVucy4NCg0KU2luZ2xlIGVudHJ5IGZvciAxIG1vbnRoLW9ubHkgJDI1DQpN
dWx0aXBsZSBlbnRyeSBmb3IgMSB5ZWFyLW9ubHkgICQxNTANCg0KKlNvbHV0aW9uIG9mIGxl
Z2FsIG1hdHRlcnMgY29uY2VybmluZyBmb3JlaWduIGNpdGl6ZW5zIHN0YXkNCm9uIHRoZSB0
ZXJyaXRvcnkgb2YgUnVzc2lhbiBGZWRlcmF0aW9uLCBxdWVzdGlvbmFibGUgaXNzdWVzLg0K
DQoqQXNzaXN0YW5jZSBpbiB2aXNhcyByZWdpc3RyYXRpb24gZm9yIHRoZQ0KZm9yZWlnbiBj
aXRpemVucyBpbiBSdXNzaWEuDQoNCipTb2x1dGlvbiBvZiB0aGUgcHJvYmxlbXMgY29uY2Vy
bmluZyBSVVNTSUFODQpjaXRpemVucyBkZXBhcnR1cmUgYWJyb2FkLCByZWdpc3RyYXRpb24N
Cm9mIHRoZSBwcm9wZXIgZG9jdW1lbnRzOiBmb3JlaWduIHBhc3Nwb3J0cyBhbmQgdmlzYXMu
DQoNCg0KVi5JLlAuIFNFUlZJQ0VTICBBVCBBSVJQT1JUUw0KT3JnYW5pemF0aW9uIG9mIHdl
bGNvbWVzIGFuZCBzZWVpbmctb2ZmcyB0aHJvdWdoIHRoZSBWLkkuUC4gaGFsbHMNCmluIHRo
ZSBhaXJwb3J0cyAoU2hlcmVtZXR5ZXZvIDEsMiwgRG9tb2RlZG92bywgVm5vdWtvdm8pOg0K
DQq3IHNlcGFyYXRlIGJvdW5kYXJ5IGNvbnRyb2wNCrcgcGVyc29uYWwgc2VydmljZSBvdXQg
b2YgdHVybg0KtyBjb21mb3J0YWJsZSBhcGFydG1lbnRzDQq3IHdlbGNvbWUgYXQgdGhlIGxh
ZGRlciBvZiBhbiBhaXJwbGFuZQ0KtyB0cmFuc2Zlcg0KDQpURUwuL0ZBWDogKzcgKDA5NSkg
MTA3LTc4LTU4LCA3OTctMDQtMDgsIDc5Ny0wNC04Mg0KRS1tYWlsOiBldnNuZXdAZW1haWwu
cnUNCg==


From noreply@sourceforge.net  Fri Jan 11 18:07:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 Jan 2002 10:07:48 -0800
Subject: [Patches] [ python-Patches-502415 ] optimize attribute lookups
Message-ID: <E16P65k-0005a7-00@usw-sf-web3.sourceforge.net>

Patches item #502415, was opened at 2002-01-11 10:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502415&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko Ozoko (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: optimize attribute lookups

Initial Comment:
This patch optimizes the string comparisons in
class_getattr(), class_setattr(), instance_getattr1(),
and instance_setattr().

I pulled out the relevant section of class_setattr()
and measured its performance, yielding the following
results:

 * in the case that the argument does *not* begin with
"__", then the new version is 1.03 times as fast as the
old.  (This is a mystery to me, as the path through the
code looks the same, in C.  I examined the assembly
that GCC v3.0.3 generated in -O3 mode, and it is true
that the assembly for the new version is
smaller/faster, although I don't really understand why.)

 * in the case that the argument is a string of random
length between 1 and 19 inclusive, and it begins with
"__" and ends with "X_" (where X is a random alphabetic
character), then the new version 1.12 times as fast as
the old.

 * in the case that the argument is a string of random
length between 1 and 19 inclusive, and it begins with
"__" and does *not* end with "_", then the new version
1.16 times as fast as the old.

 * in the case that the argument is (randomly) one of
the six special names, then the new version is 2.7
times as fast as the old.

 * in the case that the argument is a string of random
length between 1 and 19 inclusive, and it begins with
"__" and ends with "__" (but is not one of the six
special names), then the new version is 3.7 times as
fast as the old.



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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502415&group_id=5470


From noreply@sourceforge.net  Sat Jan 12 11:28:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 12 Jan 2002 03:28:34 -0800
Subject: [Patches] [ python-Patches-414775 ] Add --skip-build option to bdist command
Message-ID: <E16PMKw-0000o8-00@usw-sf-web3.sourceforge.net>

Patches item #414775, was opened at 2001-04-08 18:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414775&group_id=5470

Category: Distutils and setup.py
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Robert Kern (kern)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add --skip-build option to bdist command

Initial Comment:
Whenever one uses a non-default compiler to build an
extension, the bdist command will try to rebuild the
package with the default compiler and fail. 

The install command has a --skip-build option to
manually skip the re-building part of the install. I
adapted that code to add a similar --skip-build option
to the bdist, bdist_dumb, and bdist_wininst commands.
I'm not familiar enough with the bdist_rpm command's
code to see where it would work in there.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-12 03:28

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as

bdist.py 1.22
bdist_dumb.py 1.17
bdist_wininst.py 1.28
ACKS 1.155
NEWS 1.351


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

Comment By: Martin v. Löwis (loewis)
Date: 2001-06-06 22:28

Message:
Logged In: YES 
user_id=21627

I recommend to approve this patch.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414775&group_id=5470


From noreply@sourceforge.net  Sat Jan 12 11:35:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 12 Jan 2002 03:35:09 -0800
Subject: [Patches] [ python-Patches-454790 ] Have getopt handle optional short args
Message-ID: <E16PMRJ-0000t8-00@usw-sf-web3.sourceforge.net>

Patches item #454790, was opened at 2001-08-23 17:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454790&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Nobody/Anonymous (nobody)
Summary: Have getopt handle optional short args

Initial Comment:
The GNU getopt implementation allows optional args to 
short arguments - two colons mean an option takes an 
optional arg; if there is text in the current 
argv-element, it is returned in optarg, otherwise 
optarg is set to zero. The attached patch implements 
this behaviour.



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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-12 03:35

Message:
Logged In: YES 
user_id=21627

If there is no further action on this patch, I recommend to
close it by May 1, 2002. We really do need documentation and
test cases, and it seems that nobody is providing these, so
the patch must be rejected.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-09-19 10:55

Message:
Logged In: YES 
user_id=21627

Adding this feature sounds like a good thing. A shallow 
review of the patch reveals two major problems with it, 
though: no patches to the documentation, no patches to 
test_getopt.

Would you consider providing these missing pieces?


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454790&group_id=5470


From noreply@sourceforge.net  Sat Jan 12 11:35:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 12 Jan 2002 03:35:51 -0800
Subject: [Patches] [ python-Patches-477750 ] Use METH_ constants in Modules
Message-ID: <E16PMRz-0000tV-00@usw-sf-web3.sourceforge.net>

Patches item #477750, was opened at 2001-11-03 02:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477750&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use METH_ constants in Modules

Initial Comment:
This patch addes METH_OLDARGS and METH_VARARGS into
every method table (except for curses, for which a
separate patch is upcoming).

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-12 03:35

Message:
Logged In: YES 
user_id=21627

Jeremy, any objection to applying this now?

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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-12-04 08:19

Message:
Logged In: YES 
user_id=31392

We should probably wait until after 2.2 to make all these
changes.  I expect they're harmless, but it's a lot of code
to change at the last minute.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477750&group_id=5470


From noreply@sourceforge.net  Mon Jan 14 03:50:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 Jan 2002 19:50:42 -0800
Subject: [Patches] [ python-Patches-502205 ] Fix webbrowser running on MachoPython
Message-ID: <E16Py8w-0007r6-00@usw-sf-web1.sourceforge.net>

Patches item #502205, was opened at 2002-01-10 22:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502205&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven J. Burr (sburrious)
Assigned to: Jack Jansen (jackjansen)
Summary: Fix webbrowser running on MachoPython

Initial Comment:
Allows webbrowser.open call in the Unix version of python running on Mac OS X to open a url in Internet Explorer.  Presently, a call to webbrowser.open on this platform either runs a terminal-based browser, such as lynx, if available, or fails.

The patch is a context diff against version 1.27 of webbrowser, which appears to be the latest version in CVS.  It adds a MacOSX browser class and a test for Mac OS X systems running the Unix version of python.  I have tested it successfully several times on my Mac OS X system.

I included:

    assert url not in "'"

from the 1.27 version in the MacOSX open method, even though the method calls os.popen rather than os.system to launch the browser.  It seemed likely os.popen would raise similar security concerns.

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

>Comment By: Steven J. Burr (sburrious)
Date: 2002-01-13 19:50

Message:
Logged In: YES 
user_id=322368

I have submitted a new patch which adds the following functionality:
-Uses default browser selected in System Preferences if no browser specified.
-Allows user to choose any of the following installed browsers:  OmniWeb, iCab, Netscape, Opera, Internet Explorer, links, lynx, w3m.
-Tests for OS X running without window server as well as Darwin without OS X.  (Note that even without this test, use of the module without the window server did not crash Python, but instead generated the following error message:  "KCGErrorFailure:  initCGDisplayState: No display interlock.")
-Opens url in new window with open_new function or method, if the browser supports this behavior.
-Adds support for the Unix Dillo browser.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502205&group_id=5470


From noreply@sourceforge.net  Mon Jan 14 05:47:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 Jan 2002 21:47:57 -0800
Subject: [Patches] [ python-Patches-503202 ] backward compat. on calendar.py
Message-ID: <E16PzyP-00069K-00@usw-sf-web3.sourceforge.net>

Patches item #503202, was opened at 2002-01-13 21:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=503202&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Nobody/Anonymous (nobody)
Summary: backward compat. on calendar.py

Initial Comment:
Many applications fails on 2.2 by this problem:

under 2.1.1 ---
>>> import calendar
>>> for n in calendar.day_abbr:
...     print n,
... 
Mon Tue Wed Thu Fri Sat Sun
>>> calendar.month_abbr[7:]
['Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec']


2.2 ---
>>> import calendar
>>> for n in calendar.day_abbr:
...     print n,
... 
Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat 
Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri 
Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu 
Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed 
Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue 
Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon 
Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun 
Mon Tue Wed Thu Fri Sat Sun Mon Tue
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/pkg/lib/python2.2/calendar.py", line 31, 
in __getitem__
    return strftime(self.format, (item,)*9).capitalize
()
ValueError: year out of range
>>> calendar.month_abbr[7:]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/pkg/lib/python2.2/calendar.py", line 31, 
in __getitem__
    return strftime(self.format, (item,)*9).capitalize
()
TypeError: an integer is required
>>> 

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=503202&group_id=5470


From noreply@sourceforge.net  Mon Jan 14 06:18:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 Jan 2002 22:18:08 -0800
Subject: [Patches] [ python-Patches-503202 ] backward compat. on calendar.py
Message-ID: <E16Q0Rc-000169-00@usw-sf-web1.sourceforge.net>

Patches item #503202, was opened at 2002-01-13 21:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=503202&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Hye-Shik Chang (perky)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: backward compat. on calendar.py

Initial Comment:
Many applications fails on 2.2 by this problem:

under 2.1.1 ---
>>> import calendar
>>> for n in calendar.day_abbr:
...     print n,
... 
Mon Tue Wed Thu Fri Sat Sun
>>> calendar.month_abbr[7:]
['Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec']


2.2 ---
>>> import calendar
>>> for n in calendar.day_abbr:
...     print n,
... 
Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat 
Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri 
Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu 
Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed 
Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue 
Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon 
Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun 
Mon Tue Wed Thu Fri Sat Sun Mon Tue
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/pkg/lib/python2.2/calendar.py", line 31, 
in __getitem__
    return strftime(self.format, (item,)*9).capitalize
()
ValueError: year out of range
>>> calendar.month_abbr[7:]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/pkg/lib/python2.2/calendar.py", line 31, 
in __getitem__
    return strftime(self.format, (item,)*9).capitalize
()
TypeError: an integer is required
>>> 

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-13 22:18

Message:
Logged In: YES 
user_id=6380

You're right. Assigned to Barry.

I propose that the test suite should be changed to test for
this.

This would be a 2.2.1 bugfix candidate!

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=503202&group_id=5470


From noreply@sourceforge.net  Mon Jan 14 23:04:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 14 Jan 2002 15:04:20 -0800
Subject: [Patches] [ python-Patches-503592 ] Add method readfile() to class ZipFile
Message-ID: <E16QG9M-0002i8-00@usw-sf-web3.sourceforge.net>

Patches item #503592, was opened at 2002-01-14 15:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=503592&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Branko Cibej (brane)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add method readfile() to class ZipFile

Initial Comment:
The ZipFile class doesn't provide a method to read
bytes from the
archive directly to a disk-based file. That's
unfortunate, because
reading large files from a zip file using the read()
method will burn
about twice the file size amount of RAM. This patch
adds a readfile()
method that reads small chunks of the archived file and
writes them
directly to disk.


Changes to class ZipFile (src/Lib/zipfile.py):

- New attribute _chunk_size: readfile() and write() use
this to
  calculate the read/write buffer sizes.

- New method _readcheck: Like _writecheck, but used for
error checking
  before reading from the archive.

- Changes to read(): Factor out error checking and call
_readcheck().

- Changes to write(): Use self._chunk_size as the read
size instead
  of a hard-coded value.

- New method readfile().


Changes to the docs (src/Doc/lib/libzipfile.tex):

- Document ZipFile.readfile().


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=503592&group_id=5470


From noreply@sourceforge.net  Wed Jan 16 04:43:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 15 Jan 2002 20:43:08 -0800
Subject: [Patches] [ python-Patches-504215 ] Remove PyThread_*_sema() APIs
Message-ID: <E16Qhum-0003Hw-00@usw-sf-web1.sourceforge.net>

Patches item #504215, was opened at 2002-01-15 20:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504215&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Remove PyThread_*_sema() APIs

Initial Comment:
This patch removes the unused PyThread_*_sema()
routines and the WAIT_SEMA and NOWAIT_SEMA constants.

Patch created against CVS.
Tested on Mandrake 7.1 with glibc 2.1.3.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504215&group_id=5470


From noreply@sourceforge.net  Wed Jan 16 06:04:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 15 Jan 2002 22:04:54 -0800
Subject: [Patches] [ python-Patches-504224 ] add plan9 threads include to thread.c
Message-ID: <E16QjBu-00013T-00@usw-sf-web3.sourceforge.net>

Patches item #504224, was opened at 2002-01-15 22:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504224&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russ Cox (rsc)
Assigned to: Nobody/Anonymous (nobody)
Summary: add plan9 threads include to thread.c

Initial Comment:
Adds the usual #ifdef and #include.
I still haven't submitted any of the Plan 9 specific 
files (e.g., thread-plan9.h) since they're still in 
flux.



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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504224&group_id=5470


From noreply@sourceforge.net  Wed Jan 16 06:08:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 15 Jan 2002 22:08:30 -0800
Subject: [Patches] [ python-Patches-504225 ] add plan9 ifdef to timemodule floatsleep
Message-ID: <E16QjFO-00016K-00@usw-sf-web3.sourceforge.net>

Patches item #504225, was opened at 2002-01-15 22:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504225&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russ Cox (rsc)
Assigned to: Nobody/Anonymous (nobody)
Summary: add plan9 ifdef to timemodule floatsleep

Initial Comment:
The patch adds a plan9-ifdefed implementation
to floatsleep.

Rather than add yet another level of nesting
to the #ifdef nest, I rewrote the various #else
#if's to use #elif.

Both a context diff and the raw function are attached 
(the context diff is fairly hard to read).



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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504225&group_id=5470


From noreply@sourceforge.net  Wed Jan 16 10:54:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 16 Jan 2002 02:54:43 -0800
Subject: [Patches] [ python-Patches-487906 ] update inline docs in stringobject.c
Message-ID: <E16QniN-0007o7-00@usw-sf-web1.sourceforge.net>

Patches item #487906, was opened at 2001-12-01 12:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470

Category: None
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Zooko Ozoko (zooko)
Assigned to: Martin v. Löwis (loewis)
Summary: update inline docs in stringobject.c

Initial Comment:
--- Objects/stringobject.c      2001/11/28 20:27:42   
 2.141
+++ Objects/stringobject.c      2001/12/01 20:40:09
@@ -19,19 +19,26 @@
 #endif
 
 /*
-   Newsizedstringobject() and newstringobject() try in
certain cases
+   PyString_FromStringAndSize() and
PyString_FromString() try in certain cases
    to share string objects.  When the size of the
string is zero,
    these routines always return a pointer to the same
string object;
    when the size is one, they return a pointer to an
already existing
    object if the contents of the string is known.  For
-   newstringobject() this is always the case, for
-   newsizedstringobject() this is the case when the
first argument in
+   PyString_FromString() this is always the case, for
+   PyString_FromStringAndSize() this is the case when
the first argument in
    not NULL.
-   A common practice to allocate a string and then
fill it in or
-   change it must be done carefully.  It is only
allowed to change the
-   contents of the string if the obect was gotten from
-   newsizedstringobject() with a NULL first argument,
because in the
+   A common practice of allocating a string and then
filling it in or
+   changing it must be done carefully.  It is only
allowed to change the
+   contents of the string if the object was gotten from
+   PyString_FromStringAndSize() with a NULL first
argument, because in the
    future these routines may try to do even more
sharing of objects.
+
+   The parameter `size' denotes number of characters
in the string, not number 
+   of bytes requires to store it, and does not count
the null terminating 
+   character.
+
+   On the other hand, the member `op->ob_size' denotes
the number of bytes 
+   used for storing the string, including the null
terminating character.
 */
 PyObject *
 PyString_FromStringAndSize(const char *str, int size)
@@ -58,7 +65,7 @@


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-16 02:54

Message:
Logged In: YES 
user_id=21627

Thanks, committed as stringobject.c 2.148. Please do use
context or unified diffs (-c/-u) in the future.

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

Comment By: Zooko Ozoko (zooko)
Date: 2002-01-10 17:48

Message:
Logged In: YES 
user_id=52562

reopening for new version of docs


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

Comment By: Zooko Ozoko (zooko)
Date: 2002-01-10 17:46

Message:
Logged In: YES 
user_id=52562

Hi, I have updated these docs one last time, throwing out
all the original docs and rewriting.  Now I am happy with them.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-03 00:25

Message:
Logged In: YES 
user_id=21627

Even though this comment is right, it now reads as a
contradiction, since two sentences later, it says

If the `str' argument is not NULL, then it must point to a
null-terminated string of length `size'.
I've reformulated this somewhat, and commmitted your text.

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

Comment By: Zooko Ozoko (zooko)
Date: 2001-12-02 10:50

Message:
Logged In: YES 
user_id=52562

Here's one more addition to the in-line docs.  I was trying
to optimize `PyString_FromStringAndSize()' and I broke it
because I didn't realize this fact, so I added this fact to
the docs.  :-)

(pasted and attached)

--- Objects/stringobject.c	2001/12/02 18:09:41	2.142
+++ Objects/stringobject.c	2001/12/02 18:47:48
@@ -33,6 +33,10 @@
    a NULL first argument, because in the future these
routines may try to do 
    even more sharing of objects.
 
+   The string in the  `str' parameter does not have to be
null-character 
+   terminated.  (Therefore it is safe to construct a
substring by using 
+   `PyString_FromStringAndSize(origstring, substrlen)'.)
+
    The parameter `size' denotes number of characters to
allocate, not counting 
    the null terminating character.  If the `str' argument
is not NULL, then it 
    must point to a null-terminated string of length `size'.


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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-02 10:10

Message:
Logged In: YES 
user_id=21627

It's not just upload that is difficult; download has its
speed bumps as well. Mozilla insists to call all files
downloaded from SF "download.php", no matter what filename
SF has recorded...

Thanks for the patch; it is in stringobject.c 2.142.

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

Comment By: Zooko Ozoko (zooko)
Date: 2001-12-02 08:47

Message:
Logged In: YES 
user_id=52562

Heh heh heh.  I can't wait for the day that we can remotely
collaborate with something other than a web browser as the
user interface.  Okay, sorry, here is a newer version of the
patch.



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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-02 07:34

Message:
Logged In: YES 
user_id=21627

There is currently nothing attached.

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

Comment By: Zooko Ozoko (zooko)
Date: 2001-12-01 12:44

Message:
Logged In: YES 
user_id=52562

Okay I guess that's all mangled.  DAMN, I hate trying to use
a web browser for anything other than browsing.

Anyway, I've attached the same patch.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=487906&group_id=5470


From noreply@sourceforge.net  Wed Jan 16 11:05:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 16 Jan 2002 03:05:55 -0800
Subject: [Patches] [ python-Patches-504225 ] add plan9 ifdef to timemodule floatsleep
Message-ID: <E16QntD-0004mq-00@usw-sf-web3.sourceforge.net>

Patches item #504225, was opened at 2002-01-15 22:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504225&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Russ Cox (rsc)
Assigned to: Nobody/Anonymous (nobody)
Summary: add plan9 ifdef to timemodule floatsleep

Initial Comment:
The patch adds a plan9-ifdefed implementation
to floatsleep.

Rather than add yet another level of nesting
to the #ifdef nest, I rewrote the various #else
#if's to use #elif.

Both a context diff and the raw function are attached 
(the context diff is fairly hard to read).



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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-16 03:05

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Notice that it had an error: the
sleep() version was the fall-back, not the RISCOS version;
you code now had two RISCOS versions. Corrected and
committed as timemodule.c 2.120.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504225&group_id=5470


From noreply@sourceforge.net  Wed Jan 16 11:44:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 16 Jan 2002 03:44:18 -0800
Subject: [Patches] [ python-Patches-503592 ] Add method readfile() to class ZipFile
Message-ID: <E16QoUM-0005Iq-00@usw-sf-web3.sourceforge.net>

Patches item #503592, was opened at 2002-01-14 15:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=503592&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Branko Cibej (brane)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add method readfile() to class ZipFile

Initial Comment:
The ZipFile class doesn't provide a method to read
bytes from the
archive directly to a disk-based file. That's
unfortunate, because
reading large files from a zip file using the read()
method will burn
about twice the file size amount of RAM. This patch
adds a readfile()
method that reads small chunks of the archived file and
writes them
directly to disk.


Changes to class ZipFile (src/Lib/zipfile.py):

- New attribute _chunk_size: readfile() and write() use
this to
  calculate the read/write buffer sizes.

- New method _readcheck: Like _writecheck, but used for
error checking
  before reading from the archive.

- Changes to read(): Factor out error checking and call
_readcheck().

- Changes to write(): Use self._chunk_size as the read
size instead
  of a hard-coded value.

- New method readfile().


Changes to the docs (src/Doc/lib/libzipfile.tex):

- Document ZipFile.readfile().


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-16 03:44

Message:
Logged In: YES 
user_id=21627

I'd rather prefer a different solution: create a .open()
method on ZipFile opjects, which return file-like objects.
With that, you can shutils.copyfileobj to achive what you want.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=503592&group_id=5470


From noreply@sourceforge.net  Wed Jan 16 11:47:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 16 Jan 2002 03:47:27 -0800
Subject: [Patches] [ python-Patches-500981 ] thread_nt.h weird prototype
Message-ID: <E16QoXP-0005LO-00@usw-sf-web3.sourceforge.net>

Patches item #500981, was opened at 2002-01-08 11:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500981&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Jason Orendorff (jorend)
Assigned to: Nobody/Anonymous (nobody)
Summary: thread_nt.h weird prototype

Initial Comment:
Python/thread_nt.h gives a prototype of 
InterlockedCompareExchange that (strangely) disagrees 
with the MSDN definition of the API.

In python/dist/src/Python/thread_nt.h, line 19:
  typedef PVOID WINAPI interlocked_cmp_xchg_t(PVOID 
*dest, PVOID exc, PVOID comperand) ;

But:
  // According to MSDN
  LONG InterlockedCompareExchange( 
    LPLONG volatile Destination,  // destination 
address
    LONG Exchange,                // exchange value
    LONG Comperand                // value to compare
  );

Later on in the file, when the function actually gets 
called, the code contains a bunch of casts to 
compensate for the fact that the prototype is wrong!  
How weird is that?

I've attached a patch that fixes the wacky prototype 
in question.  (I built Python with it and ran the 
regression tests; everything works.)


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-16 03:47

Message:
Logged In: YES 
user_id=21627

I take it that it can be closed, then?

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

Comment By: Jason Orendorff (jorend)
Date: 2002-01-09 12:12

Message:
Logged In: YES 
user_id=18139

Ah.  Makes perfect sense.  I do have a later platform SDK
installed.  Ater reading the support article, I am 
satisfied.

Bill me for your wasted time. :)


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

Comment By: Tim Peters (tim_one)
Date: 2002-01-08 21:59

Message:
Logged In: YES 
user_id=31435

Our copies of winbase.h don't match.  I'm using VC6 SP5.  
Strange!

OK, according to
<http://support.microsoft.com/default.aspx?scid=kb;EN-
US;Q292752>

MS changed the signature of InterlockedCompareExchange in 
an incompatible way after VC6 was released.  Best guess is 
that you picked up a newer winbase.h from a platform SDK 
download specific to Win 2000.  But that isn't yet 
reflected in a service pack for VC 6 (SP5 is the most 
recent).  I really don't want to change Python until the 
new prototype ships with the compiler (or its service 
packs).

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

Comment By: Jason Orendorff (jorend)
Date: 2002-01-08 20:17

Message:
Logged In: YES 
user_id=18139

Thanks for checking into this, tim.  Maybe I can provoke 
you into
thinking about it just a bit more.  I'll send e-mail to 
both the
authors asking them to take a look at this page, too.

I see declarations of InterlockedCompareExchange() on lines 
1007,
1036, 1093, and 1161 of winbase.h.  But they are consistent 
with MSDN,
*not* with thread_nt.h.  Right?

It *is* quite messy in winbase.h, messy enough to confuse 
Visual
Studio's tooltip feature.  So perhaps you will not 
immediately believe
my assertion above.  Believe this, then:

/* This program compiles without a hitch... */
#include <windows.h>
void main() {
    LONG x = 0, a = 1, b = 0;
    InterlockedCompareExchange(&x, a, b);
}

/* ...but this generates warnings about parameter types. */
#include <windows.h>
void main() {
    PVOID x = NULL, a = NULL, b = NULL;
    InterlockedCompareExchange(&x, a, b);
}

I'm using Visual C++ 6.0 on Windows 2000, on a vanilla 
Intel 32-bit system.


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

Comment By: Tim Peters (tim_one)
Date: 2002-01-08 12:13

Message:
Logged In: YES 
user_id=31435

Whatever MSDN may say, the prototype in the code matches 
what's actually in MS's winbase.h (at least under MSVC 6).  
This makes it too confused for me to even want to think 
about it -- maybe one of the thread_nt.h authors (listed at 
the top of the file) could be provoked into explaining what 
they believe.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500981&group_id=5470


From noreply@sourceforge.net  Wed Jan 16 22:47:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 16 Jan 2002 14:47:54 -0800
Subject: [Patches] [ python-Patches-476814 ] foreign-platform newline support
Message-ID: <E16QyqY-0000sA-00@usw-sf-web1.sourceforge.net>

Patches item #476814, was opened at 2001-10-31 08:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476814&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: foreign-platform newline support

Initial Comment:
This patch enables Python to interpret all known
newline conventions,
CR, LF or CRLF, on all platforms.

This support is enabled by configuring with
--with-universal-newlines
(so by default it is off, and everything should behave
as usual).

With universal newline support enabled two things
happen:
- When importing or otherwise parsing .py files any
newline convention
  is accepted.
- Python code can pass a new "t" mode parameter to
open() which
  reads files with any newline convention. "t" cannot
be combined with
  any other mode flags like "w" or "+", for obvious
reasons.

File objects have a new attribute "newlines" which
contains the type of
newlines encountered in the file (or None when no
newline has been seen,
or "mixed" if there were various types of newlines).

Also included is a test script which tests both file
I/O and parsing.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2002-01-16 14:47

Message:
Logged In: YES 
user_id=45365

This version of the patch addresses the bug in Py_UniversalNewlineFread and fixes up some minor details. Tim's other issues are addressed (at least: I think they are:-) in a forthcoming PEP.

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

Comment By: Tim Peters (tim_one)
Date: 2001-12-13 15:57

Message:
Logged In: YES 
user_id=31435

Back to Jack -- and sorry for sitting on it so long.  
Clearly this isn't making it into 2.2 in the core.  As I 
said on Python-Dev, I believe this needs a PEP:  the design 
decisions are debatable, so *should* be debated outside the 
Mac community too.  Note, though, that I can't stop you 
from adding it to the 2.2 Mac distribution (if you want it 
badly enough there).

If a PEP won't be written, I suggest finding someone else 
to review it again; maybe Guido.  Note that the patch needs 
doc changes too.  The patch to regrtest.py doesn't belong 
here (I assume it just slipped in).  There seems a lot of 
code in support of the f_newlinetypes member, and the value 
of that member isn't clear -- I can't imagine a good use 
for it (maybe it's a Mac thing?).  The implementation of 
Py_UniversalNewlineFread appears incorrect to me:  it reads 
n bytes *every* time around the outer loop, no matter how 
few characters are still required, and n doesn't change 
inside the loop.  The business about the GIL may be due to 
the lack of docs:  are, or are not, people supposed to 
release the GIL themselves around calls to these guys?  
It's not documented, and it appears your intent differed 
from my guess.  Finally, it would be better to call ferror
() after calling fread() instead of before it <wink>.

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

Comment By: Jack Jansen (jackjansen)
Date: 2001-11-14 07:13

Message:
Logged In: YES 
user_id=45365

Here's a new version of the patch. To address your issues
one by one:
- get_line and Py_UniversalNewlineFgets are too difficult to
integrate, at leat,
I don't see how I could do it. The storage management of
get_line gets in the way.

- The global lock comment I don't understand. The
Universal... routines are
replacements for fgets() and fread(), so have nothing to do
with the interpreter lock.

- The logic of all three routines (get_line too) has changed
and I've put comments in.
I hope this addresses some of the points.

- If universal_newline is false for a certain PyFileObject
we now immedeately take
a quick exit via fgets() or fread().

There's also a new test script, that tests some more border
cases (like lines longer
than 100 characters, and a lone CR just before end of file).

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

Comment By: Tim Peters (tim_one)
Date: 2001-11-05 00:16

Message:
Logged In: YES 
user_id=31435

It would be better if get_line just called 
Py_UniversalNewlineFgets (when appropriate) instead of 
duplicating its logic inline.

Py_UniversalNewlineFgets and Py_UniversalNewlineFread 
should deal with releasing the global lock themselves -- 
the correct granularity for lock release/reacquire is 
around the C-level input routines (esp. for fread).

The new routines never check for I/O errors!  Why not?  It 
seems essential.

The new Fgets checks for EOF at the end of the loop instead 
of the top.  This is surprising, and I stared a long time 
in vain trying to guess why.  Setting

newlinetypes |= NEWLINE_CR;

immediately after seeing an '\r' would be as fast (instead 
of waiting to see EOF and then inferring the prior 
existence of '\r' indirectly from the state of the 
skipnextlf flag).

Speaking of which <wink>, the fobj tests in the inner loop 
waste cycles.  Set the local flag vrbls whether or not fobj 
is NULL.  When you're *out* of the inner loop you can 
simply decline to store the new masks when fobj is NULL 
(and you're already doing the latter anyway).  A test and 
branch inside the loop is much more expensive than or'ing 
in a flag bit inside the loop, ditto harder to understand.

Floating the univ_newline test out of the loop (and 
duplicating the loop body, one way for univ_newline true 
and the other for it false) would also save a test and 
branch on every character.

Doing fread one character at a time is very inefficient.  
Since you know you need to obtain n characters in the end, 
and that these transformations require reading at least n 
characters, you could very profitably read n characters in 
one gulp at the start, then switch to k at a time where k 
is the number of \r\n pairs seen since the last fread 
call.  This is easier to code than it sounds <wink>.

It would be fine by me if you included (and initialized) 
the new file-object fields all the time, whether or not 
universal newlines are configured.  I'd rather waste a few 
bytes in a file object than see #ifdefs spread thru the 
code.

I'll be damned if I can think of a quick way to do this 
stuff on Windows -- native Windows fgets() is still the 
only Windows handle we have on avoiding crushing thread 
overhead inside MS's C library.  I'll think some more about 
it (the thrust still being to eliminate the 't' mode flag, 
as whined about <wink> on Python-Dev).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-31 09:38

Message:
Logged In: YES 
user_id=6380

Tim, can you review this or pass it on to someone else who
has time?

Jack developed this patch after a discussion in which I was
involved in some of the design, but I won't have time to
look at it until December.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476814&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 02:52:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 16 Jan 2002 18:52:04 -0800
Subject: [Patches] [ python-Patches-504714 ] hasattr catches only AttributeError
Message-ID: <E16R2eq-00040R-00@usw-sf-web1.sourceforge.net>

Patches item #504714, was opened at 2002-01-16 18:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504714&group_id=5470

Category: Core (C code)
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Quinn Dunkan (quinn_dunkan)
Assigned to: Nobody/Anonymous (nobody)
Summary: hasattr catches only AttributeError

Initial Comment:
Curse me for a fool.  I reported this exact same thing
in getattr but failed to
look 30 lines down to notice hasattr.

hasattr(foo, 'bar') catches all exceptions.  I think it
should only catch 
AttributeError.  Example:

>>> class Foo:
...     def __getattr__(self, attr):
...         assert 0
... 
>>> f = Foo()
>>> hasattr(f, 'bar')
0               # should have gotten an AssertionError
>>>

This patch makes hasattr only catch AttributeError.  I
changed the 
docstring to reflect that, and also changed the getattr
docstring
to read a little more naturally.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504714&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 15:02:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 07:02:20 -0800
Subject: [Patches] [ python-Patches-504889 ] make setup.py less chatty by default
Message-ID: <E16RE3Y-0003eN-00@usw-sf-web2.sourceforge.net>

Patches item #504889, was opened at 2002-01-17 07:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Nobody/Anonymous (nobody)
Summary: make setup.py less chatty by default

Initial Comment:
I don't like the amount of output that setup.py
produces by default, and I don't like the way that -q
and -v affect the amount of output.  In general, I want
setup.py to tell me what it is doing and not what it is
skippping.  It's fine to say nothing with -q, but it
shouldn't say more without -v.

The attached patch is a bit of a kludge, but I'm not
familiar enough with distutils to do any better.  One
problem is that -v/--verbose has previously handled as
a flag, either on or off.  (There is a curiously large
amount of code that compares this boolean to see if
it's greater than some number!)  I had the options
processor to treat self.verbose as a count of -v
options.  So -vv is more verbose than -v.

Then I change the specific prints and announcements
that I've seen with setup.py that I didn't want to see.
 The messages I don't want to see (unless verbose is
high) are about skipping builds of Extensions and not
copying files that are already up-to-date.

With this patch in place, setup.py tells me only the
extensions is actually builds and files it actually copies.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 15:49:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 07:49:27 -0800
Subject: [Patches] [ python-Patches-504889 ] make setup.py less chatty by default
Message-ID: <E16REn9-0004Ih-00@usw-sf-web2.sourceforge.net>

Patches item #504889, was opened at 2002-01-17 07:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Nobody/Anonymous (nobody)
Summary: make setup.py less chatty by default

Initial Comment:
I don't like the amount of output that setup.py
produces by default, and I don't like the way that -q
and -v affect the amount of output.  In general, I want
setup.py to tell me what it is doing and not what it is
skippping.  It's fine to say nothing with -q, but it
shouldn't say more without -v.

The attached patch is a bit of a kludge, but I'm not
familiar enough with distutils to do any better.  One
problem is that -v/--verbose has previously handled as
a flag, either on or off.  (There is a curiously large
amount of code that compares this boolean to see if
it's greater than some number!)  I had the options
processor to treat self.verbose as a count of -v
options.  So -vv is more verbose than -v.

Then I change the specific prints and announcements
that I've seen with setup.py that I didn't want to see.
 The messages I don't want to see (unless verbose is
high) are about skipping builds of Extensions and not
copying files that are already up-to-date.

With this patch in place, setup.py tells me only the
extensions is actually builds and files it actually copies.


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

>Comment By: Michael Hudson (mwh)
Date: 2002-01-17 07:49

Message:
Logged In: YES 
user_id=6656

Um, context diff?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 15:51:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 07:51:09 -0800
Subject: [Patches] [ python-Patches-420565 ] makes setup.py search sys.prefix
Message-ID: <E16REon-0004Kb-00@usw-sf-web2.sourceforge.net>

Patches item #420565, was opened at 2001-05-01 14:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420565&group_id=5470

Category: Distutils and setup.py
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Michael Hudson (mwh)
Summary: makes setup.py search sys.prefix 

Initial Comment:
It's useful to have setup.py search the lib and include
directories in sys.prefix before it checks /usr/local.
That way, if you are building Python into a custom
location and want it to use the the libraries installed
there rather than the system defaults, you can give the
--prefix option to configure and setup.py will search
that path first.

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

>Comment By: Michael Hudson (mwh)
Date: 2002-01-17 07:51

Message:
Logged In: YES 
user_id=6656

Right, I've checked something similar in, as revision 1.75
of setup.py.

I did this yesterday, but sf was playing silly buggers.

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

Comment By: Michael Hudson (mwh)
Date: 2001-12-23 14:02

Message:
Logged In: YES 
user_id=6656




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

Comment By: Michael Hudson (mwh)
Date: 2001-12-10 08:10

Message:
Logged In: YES 
user_id=6656

Umm, yeah sure.

I think I'd rather use sysconfig.get_config_var("LIBDIR")
than sys.prefix+"/lib", though.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-10 07:59

Message:
Logged In: YES 
user_id=6380

Michael, can you have a look at this for Python 2.3 (or
2.2.1)?

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-06-01 08:19

Message:
Logged In: NO 

I totally agree. I'm building for hard hat linux on a 
debian host, and the implicit search in /usr/lib is 
totally the wrong thing to do in this case.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=420565&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 16:32:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 08:32:35 -0800
Subject: [Patches] [ python-Patches-504889 ] make setup.py less chatty by default
Message-ID: <E16RFSt-00026N-00@usw-sf-web3.sourceforge.net>

Patches item #504889, was opened at 2002-01-17 07:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Nobody/Anonymous (nobody)
Summary: make setup.py less chatty by default

Initial Comment:
I don't like the amount of output that setup.py
produces by default, and I don't like the way that -q
and -v affect the amount of output.  In general, I want
setup.py to tell me what it is doing and not what it is
skippping.  It's fine to say nothing with -q, but it
shouldn't say more without -v.

The attached patch is a bit of a kludge, but I'm not
familiar enough with distutils to do any better.  One
problem is that -v/--verbose has previously handled as
a flag, either on or off.  (There is a curiously large
amount of code that compares this boolean to see if
it's greater than some number!)  I had the options
processor to treat self.verbose as a count of -v
options.  So -vv is more verbose than -v.

Then I change the specific prints and announcements
that I've seen with setup.py that I didn't want to see.
 The messages I don't want to see (unless verbose is
high) are about skipping builds of Extensions and not
copying files that are already up-to-date.

With this patch in place, setup.py tells me only the
extensions is actually builds and files it actually copies.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 08:32

Message:
Logged In: YES 
user_id=31392

Er, context diff.


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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 07:49

Message:
Logged In: YES 
user_id=6656

Um, context diff?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 16:45:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 08:45:17 -0800
Subject: [Patches] [ python-Patches-504889 ] make setup.py less chatty by default
Message-ID: <E16RFfB-0006EQ-00@usw-sf-web1.sourceforge.net>

Patches item #504889, was opened at 2002-01-17 07:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Nobody/Anonymous (nobody)
Summary: make setup.py less chatty by default

Initial Comment:
I don't like the amount of output that setup.py
produces by default, and I don't like the way that -q
and -v affect the amount of output.  In general, I want
setup.py to tell me what it is doing and not what it is
skippping.  It's fine to say nothing with -q, but it
shouldn't say more without -v.

The attached patch is a bit of a kludge, but I'm not
familiar enough with distutils to do any better.  One
problem is that -v/--verbose has previously handled as
a flag, either on or off.  (There is a curiously large
amount of code that compares this boolean to see if
it's greater than some number!)  I had the options
processor to treat self.verbose as a count of -v
options.  So -vv is more verbose than -v.

Then I change the specific prints and announcements
that I've seen with setup.py that I didn't want to see.
 The messages I don't want to see (unless verbose is
high) are about skipping builds of Extensions and not
copying files that are already up-to-date.

With this patch in place, setup.py tells me only the
extensions is actually builds and files it actually copies.


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

>Comment By: Michael Hudson (mwh)
Date: 2002-01-17 08:45

Message:
Logged In: YES 
user_id=6656

Hokay, next question: why the "assert 0" in cmd.py?  Are you
sure you've finished?

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 08:32

Message:
Logged In: YES 
user_id=31392

Er, context diff.


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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 07:49

Message:
Logged In: YES 
user_id=6656

Um, context diff?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 16:49:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 08:49:58 -0800
Subject: [Patches] [ python-Patches-501713 ] compileall.py -d errors
Message-ID: <E16RFji-00058t-00@usw-sf-web2.sourceforge.net>

Patches item #501713, was opened at 2002-01-10 02:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=501713&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bastian Kleineidam (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: compileall.py -d errors

Initial Comment:
the option -d is not handled properly, the
compileall.py script generates files in the
wrong directory.

Patch is for Python 2.1.1.


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

>Comment By: Bastian Kleineidam (calvin)
Date: 2002-01-17 08:49

Message:
Logged In: YES 
user_id=9205

I updated the patch to correct the case where dfile is None

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=501713&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 16:50:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 08:50:06 -0800
Subject: [Patches] [ python-Patches-504889 ] make setup.py less chatty by default
Message-ID: <E16RFjq-0002Kl-00@usw-sf-web3.sourceforge.net>

Patches item #504889, was opened at 2002-01-17 07:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Nobody/Anonymous (nobody)
Summary: make setup.py less chatty by default

Initial Comment:
I don't like the amount of output that setup.py
produces by default, and I don't like the way that -q
and -v affect the amount of output.  In general, I want
setup.py to tell me what it is doing and not what it is
skippping.  It's fine to say nothing with -q, but it
shouldn't say more without -v.

The attached patch is a bit of a kludge, but I'm not
familiar enough with distutils to do any better.  One
problem is that -v/--verbose has previously handled as
a flag, either on or off.  (There is a curiously large
amount of code that compares this boolean to see if
it's greater than some number!)  I had the options
processor to treat self.verbose as a count of -v
options.  So -vv is more verbose than -v.

Then I change the specific prints and announcements
that I've seen with setup.py that I didn't want to see.
 The messages I don't want to see (unless verbose is
high) are about skipping builds of Extensions and not
copying files that are already up-to-date.

With this patch in place, setup.py tells me only the
extensions is actually builds and files it actually copies.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 08:50

Message:
Logged In: YES 
user_id=31392



The distutils package is a maze of twisty little passages
that all look the same <wink>.  I added an assert 0 to make
sure that the execution path that generated the output
wasn't the one with the assert 0.  (It wasn't.)  Didn't
intend for the patch to make it in.

But I'd still be surprised if this patch is the right thing.
 More likely that it demonstrates good behavior that could
be implemented more cleanly.

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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 08:45

Message:
Logged In: YES 
user_id=6656

Hokay, next question: why the "assert 0" in cmd.py?  Are you
sure you've finished?

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 08:32

Message:
Logged In: YES 
user_id=31392

Er, context diff.


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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 07:49

Message:
Logged In: YES 
user_id=6656

Um, context diff?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 16:50:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 08:50:27 -0800
Subject: [Patches] [ python-Patches-504943 ] call warnings.warn with Warning instance
Message-ID: <E16RFkB-00059P-00@usw-sf-web2.sourceforge.net>

Patches item #504943, was opened at 2002-01-17 08:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504943&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: call warnings.warn with Warning instance

Initial Comment:
This patch makes it possible to pass Warning instances 
as the first argument to warnings.warn. In this case 
the category argument will be ignored. The message
text used will be str(warninginstance). This makes it 
possible to implement special logic in a custom 
Warning class by implemening the __str__ method.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504943&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 17:25:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 09:25:07 -0800
Subject: [Patches] [ python-Patches-504889 ] make setup.py less chatty by default
Message-ID: <E16RGHj-0002pK-00@usw-sf-web3.sourceforge.net>

Patches item #504889, was opened at 2002-01-17 07:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Nobody/Anonymous (nobody)
Summary: make setup.py less chatty by default

Initial Comment:
I don't like the amount of output that setup.py
produces by default, and I don't like the way that -q
and -v affect the amount of output.  In general, I want
setup.py to tell me what it is doing and not what it is
skippping.  It's fine to say nothing with -q, but it
shouldn't say more without -v.

The attached patch is a bit of a kludge, but I'm not
familiar enough with distutils to do any better.  One
problem is that -v/--verbose has previously handled as
a flag, either on or off.  (There is a curiously large
amount of code that compares this boolean to see if
it's greater than some number!)  I had the options
processor to treat self.verbose as a count of -v
options.  So -vv is more verbose than -v.

Then I change the specific prints and announcements
that I've seen with setup.py that I didn't want to see.
 The messages I don't want to see (unless verbose is
high) are about skipping builds of Extensions and not
copying files that are already up-to-date.

With this patch in place, setup.py tells me only the
extensions is actually builds and files it actually copies.


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

>Comment By: Michael Hudson (mwh)
Date: 2002-01-17 09:25

Message:
Logged In: YES 
user_id=6656

You're not wrong :|

The "assert 0" is on the install path though.

Right.  I'm currently fighting emacs to let me print source
duplex, but I want to understand distutils' innards at some
point, might as well be now.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 08:50

Message:
Logged In: YES 
user_id=31392



The distutils package is a maze of twisty little passages
that all look the same <wink>.  I added an assert 0 to make
sure that the execution path that generated the output
wasn't the one with the assert 0.  (It wasn't.)  Didn't
intend for the patch to make it in.

But I'd still be surprised if this patch is the right thing.
 More likely that it demonstrates good behavior that could
be implemented more cleanly.

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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 08:45

Message:
Logged In: YES 
user_id=6656

Hokay, next question: why the "assert 0" in cmd.py?  Are you
sure you've finished?

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 08:32

Message:
Logged In: YES 
user_id=31392

Er, context diff.


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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 07:49

Message:
Logged In: YES 
user_id=6656

Um, context diff?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 17:36:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 09:36:37 -0800
Subject: [Patches] [ python-Patches-477752 ] Drop old-style getargs from curses
Message-ID: <E16RGSr-00030R-00@usw-sf-web3.sourceforge.net>

Patches item #477752, was opened at 2001-11-03 02:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477752&group_id=5470

Category: Modules
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Martin v. Löwis (loewis)
Summary: Drop old-style getargs from curses

Initial Comment:
This patch converts _cursesmodule and _curses_panel
into using ParseTuple, METH_VARARGS, METH_NOARGS, and
METH_O throughout.

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

>Comment By: Michael Hudson (mwh)
Date: 2002-01-17 09:36

Message:
Logged In: YES 
user_id=6656

Patch no longer applies cleanly; don't really understand why.

Fix that and check it in?  I haven't checked each line of
the patch, but it looks innocuous enough.  Changing
resolution to "Accepted" on the grounds that noone else is
likely to care, but feel free to leap in if you do.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477752&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 17:49:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 09:49:21 -0800
Subject: [Patches] [ python-Patches-458898 ] --python-build for install
Message-ID: <E16RGfB-0005zC-00@usw-sf-web2.sourceforge.net>

Patches item #458898, was opened at 2001-09-05 13:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458898&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
>Assigned to: Michael Hudson (mwh)
Summary: --python-build for install

Initial Comment:
Sometimes, being able to install python tools without
having python installed is desirable. When building an
RPM package of python, for example, one may want to
build/install IDLE as well, including it in a
subpackage. Indeed, we're doing this with a couple of
python tools here at Conectiva. Unfortunately, we have
a egg-chicken problem when doing this. You need python
installed in your system before you install tools. This
limitation may be observed in the file
Lib/distutils/sysconfig.py. It looks for Makefile in
the final installation directory, for example.

This patch adds a new option to dist-utils' install
command: --python-build. When used, python will look
for these files in the python build directory specified
trough the option.



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

>Comment By: Michael Hudson (mwh)
Date: 2002-01-17 09:49

Message:
Logged In: YES 
user_id=6656

Hey!  This patch is less than six months old.  Virtually
fresh :|

Some comments:  are you sure you can get away with only
honouring --python-build in install?  I think build_scripts
needs it too (now, anyway, maybe not when you wrote the patch).

Also, the mod to install.finalize_options() is in the wrong
place wrt. the surrouding comments.  Can you fix this?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458898&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 17:53:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 09:53:52 -0800
Subject: [Patches] [ python-Patches-457892 ] sys module feature patch - modify_argv()
Message-ID: <E16RGjY-000635-00@usw-sf-web2.sourceforge.net>

Patches item #457892, was opened at 2001-09-02 19:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=457892&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Cinege (dcinege)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys module feature patch - modify_argv()

Initial Comment:
sys module feature patch - modify_argv()

Feature enhancment patch to sys module. 
(Python/sysmodule.c) 

modify_argv(string,[start],[amount]) 

Modify the absolute argv (process listing) elements 
of the python process. 


NOTE: You may wish view the thread
of the python mailing list below.
It's been mentioned a more appropreate place for
this might be the posix module. (However I still think
sys is the right place) I'm willing to implement this 
as the core team desires, if it is to be included.

Subject: [PATCH] sys.modify_argv()
Date:  Fri, 24 Aug 2001 22:19:34 -0400
To: Python <python-list@python.org>

keywords: modify argv change process listing argv[0] 
ps output

This patch adds a new feature to the sys module, 
modify_argv().
As you might have guessed this allows one to change 
to absolute
argv values of the python process itself. (It is of 
great wonder
to me why this functionality is not already 
available...)

I have intentionally left the patch with minimal 
sanity
checking. Ignorance of detail could lead to dangerous
results. Stronger bountries may be desirable in a 
final
implementation.

The patch is against Python 2.1.1. Adding this 
function to another
module or placing it in your own module should be a 
trvial task.
It is self contained using Py_GetArgcArgv() to grab 
the location
of argv, already present in the python core.

This patch has been submitted for inclusion into core 
python.

Documentation on it's use is in the patch itself.

I hereby place this code into the public domain. 

'Diesel' Dave 'Kill a Cop' Cinege
-----------------------------------------------------
Subject: Re: [PATCH] sys.modify_argv()
Date: Fri, 24 Aug 2001 23:53:04 -0400
To: Ignacio Vazquez-Abrams <ignacio@openservices.net>
CC: Python <python-list@python.org>

> Instead of making a whole new function for this, 
why not add write
capability
> to sys.argv?

Why I didn't do this:

1) From what I've looked at, the current sys code 
would change
dramatically as it's already dealing in copies of 
argv initialized
at python startup, and not by accessing  
Py_GetArgcArgv() dynamically.
What I did is less intrusive and portable outside of 
sys.

2) Even though one clears the absolute argv, you 
probably still want
it's values available internally. Thus clearing the 
sys.argv copies
adds a layer of complexity that is really unneeded 
and probably undesirable.

3) It's not yet exactly clear (to me) to what extent 
you can alter argv
and not impeed portability. This is probably reason 
enough to segregate this
functionality. (On linux it stacks argv elements 
concurrently in memory and
it's safe to use that total space anyway you want. 
Who knows
how other OS's deal with it...)

4) sys.argv[0] == argv[1]. How do we get to the real 
argv[0] in a
sane way? sys.argv[-1] Might break old code as the 
current implementation
ignores negatives and uses absolute values. Also 
making process
listing follow sys.agrv assignment might break old 
code. And then
we have to deal with the lengths of the orginial argv 
elements again...


This is the first time I've ever even looked at the 
python source,
and am hardly close to being a python guru myself. 
There might be
a better solution then what I've done, though I've 
tried to put a bit
of thought into it. At least this patch is usable by 
people
now and will hopefully lead to SOME sort of standard 
argv modification
support in the near future.

Dave




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

>Comment By: Michael Hudson (mwh)
Date: 2002-01-17 09:53

Message:
Logged In: YES 
user_id=6656

Excuse me for being dense, but what purpose does this patch
serve?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=457892&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 17:58:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 09:58:15 -0800
Subject: [Patches] [ python-Patches-463656 ] setup.py, --with-includepath, and LD_LIB
Message-ID: <E16RGnn-00067H-00@usw-sf-web2.sourceforge.net>

Patches item #463656, was opened at 2001-09-21 12:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463656&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py, --with-includepath, and LD_LIB

Initial Comment:
This patch improves the module detection capability in
setup.py.

The following improvements are implemented:

- directories listed in LD_LIBRARY_PATH are also
searched for shared libraries.

- the --with-includepath option has been added to
configure, to specify additional  non-standard
directories where the include files are to be searched
for.

The corresponding changes were added to setup.py (new
function detect_include(),  find_library_file()
augmented, detect_tkinter() improved)

I retroceeded manually the changes from configure into
configure.in, but I did not run autoconf; you might
want to double-check this.

Sample aplication:
./configure --prefix=/something
--with-includepath='/mgl/apps/include:/mgl/share/include'

With this patch, I get Tkinter to build correctly
without editing the Setup files, with non-standard
tckl/tk 8.0 to 8.3 installations. where the only tcl.h
file is in /mgl/share/include/tcl8.0 (therefore,
tkinter is build with tcl8.0 on this configuration).

FG

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

>Comment By: Michael Hudson (mwh)
Date: 2002-01-17 09:58

Message:
Logged In: YES 
user_id=6656

You do know that you can pass -I and -L options to setup.py?
 That might be a less involved way of doing what you want.

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

Comment By: Frederic Giacometti (giacometti)
Date: 2001-09-27 17:17

Message:
Logged In: YES 
user_id=93657

I moved the functions
  find_library_file() and  detect_include()
to distutils.sysconfig(), so that they can be reused for
configuring third party modules too (e.g.: PyOpenGL...).

Let me know if you wish a patch for this.

Frederic Giacometti



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

Comment By: Frederic Giacometti (giacometti)
Date: 2001-09-26 15:56

Message:
Logged In: YES 
user_id=93657

I'm replacing the patch with an improved version (against
main line as of 09/26/01).

New features:

- configure is generated from configure.in, with autoconf

- detect_tkinter also checks the version number inside the
tcl.h and tk.h files (#define TCL_VERSION, #define
TK_VERSION...).

The 'tk_detect' improvement is in this same patch as the
'--include-patch' feature; since the second one was written
to get the first one working.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=463656&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 18:01:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 10:01:33 -0800
Subject: [Patches] [ python-Patches-495688 ] Make site.py more friendly to PDAs
Message-ID: <E16RGqz-00069v-00@usw-sf-web2.sourceforge.net>

Patches item #495688, was opened at 2001-12-20 16:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=495688&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phil Thompson (philthompson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make site.py more friendly to PDAs

Initial Comment:
site.py requires distutils and pydoc which are both
unfriendly to devices with little memory like PDAs.

This patch makes site.py cope with distutils and pydoc
not being installed.

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

>Comment By: Michael Hudson (mwh)
Date: 2002-01-17 10:01

Message:
Logged In: YES 
user_id=6656

Hmm.  Semi-approve of the pydoc change.  The distutils
change seems pointless though -- you're not likely to build
Python on a PDA anytime soon, are you?  Or are folders call
Modules/ very common on PDAs?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=495688&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 18:02:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 10:02:37 -0800
Subject: [Patches] [ python-Patches-499940 ] Work around for buggy https servers
Message-ID: <E16RGs1-0006Ar-00@usw-sf-web2.sourceforge.net>

Patches item #499940, was opened at 2002-01-05 12:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499940&group_id=5470

Category: Modules
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Michel Van den Bergh (vdbergh)
>Assigned to: Michael Hudson (mwh)
Summary: Work around for buggy https servers

Initial Comment:
Python 2.2. Tested on RH 7.1.

This a workaround for, 

http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=494762

The problem is that some https servers close an ssl
connection without properly resetting it first. In the
above bug description it is suggested that this
only occurs for IIS but apparently some  (modified)
Apache servers also suffer from it (see
telemeter.telenet.be).

One of the suggested workarounds is to modify
httplib.py so as to ignore the combination of
err[0]==SSL_ERROR_SYSCALL and 
err[1]=="EOF occurred in violation of protocol".
However I think one should never compare error strings
since in principle they may depend on language etc...

So I decided to modify _socket.c slightly so that
it becomes possible to return error codes which
are not in in ssl.h. You will see that I did this
in a portable way, which is independent of the
explicit error numbers in ssl.h.

When an ssl-connection is closed without reset I now
return the error code SSL_ERROR_EOF. Then I ignore
this (apparently benign) error in httplib.py.

In addition I fixed what I think was an error in
PySSL_SetError(SSL *ssl, int ret) in socketmodule.c.

Originally there was:

	case SSL_ERROR_SSL:
	{
		unsigned long e = ERR_get_error();
		if (e == 0) {
			/* an EOF was observed that violates the protocol */
			errstr = "EOF occurred in violation of protocol";

etc... 
but if I understand the documentation for
SSL_get_error then the test should be: e==0 && ret==0.
A similar error occurs a few lines later.

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

Comment By: Michel Van den Bergh (vdbergh)
Date: 2002-01-09 02:28

Message:
Logged In: YES 
user_id=10252

Due to some problems with sourceforge and incompetence on my
part I seem to have submitted several times. See patch
500311.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499940&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 18:17:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 10:17:10 -0800
Subject: [Patches] [ python-Patches-504889 ] make setup.py less chatty by default
Message-ID: <E16RH66-0006OV-00@usw-sf-web2.sourceforge.net>

Patches item #504889, was opened at 2002-01-17 07:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Nobody/Anonymous (nobody)
Summary: make setup.py less chatty by default

Initial Comment:
I don't like the amount of output that setup.py
produces by default, and I don't like the way that -q
and -v affect the amount of output.  In general, I want
setup.py to tell me what it is doing and not what it is
skippping.  It's fine to say nothing with -q, but it
shouldn't say more without -v.

The attached patch is a bit of a kludge, but I'm not
familiar enough with distutils to do any better.  One
problem is that -v/--verbose has previously handled as
a flag, either on or off.  (There is a curiously large
amount of code that compares this boolean to see if
it's greater than some number!)  I had the options
processor to treat self.verbose as a count of -v
options.  So -vv is more verbose than -v.

Then I change the specific prints and announcements
that I've seen with setup.py that I didn't want to see.
 The messages I don't want to see (unless verbose is
high) are about skipping builds of Extensions and not
copying files that are already up-to-date.

With this patch in place, setup.py tells me only the
extensions is actually builds and files it actually copies.


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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-01-17 10:17

Message:
Logged In: YES 
user_id=38388

Jeremy, the patch touches the distutils code, but what you really 
want is to change the behaviour in one single use-case (the setup.py
which Python uses).

The "right" way to fix this would be to subclass the various distutils
classes to implement the change. If this becomes too complicated,
then distutils ought to be tweaked to make this easier in way that
doesn't break existing code (e.g. I don't want to miss the skip
notices for my stuff).

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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 09:25

Message:
Logged In: YES 
user_id=6656

You're not wrong :|

The "assert 0" is on the install path though.

Right.  I'm currently fighting emacs to let me print source
duplex, but I want to understand distutils' innards at some
point, might as well be now.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 08:50

Message:
Logged In: YES 
user_id=31392



The distutils package is a maze of twisty little passages
that all look the same <wink>.  I added an assert 0 to make
sure that the execution path that generated the output
wasn't the one with the assert 0.  (It wasn't.)  Didn't
intend for the patch to make it in.

But I'd still be surprised if this patch is the right thing.
 More likely that it demonstrates good behavior that could
be implemented more cleanly.

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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 08:45

Message:
Logged In: YES 
user_id=6656

Hokay, next question: why the "assert 0" in cmd.py?  Are you
sure you've finished?

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 08:32

Message:
Logged In: YES 
user_id=31392

Er, context diff.


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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 07:49

Message:
Logged In: YES 
user_id=6656

Um, context diff?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 18:17:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 10:17:24 -0800
Subject: [Patches] [ python-Patches-504889 ] make setup.py less chatty by default
Message-ID: <E16RH6K-0003at-00@usw-sf-web3.sourceforge.net>

Patches item #504889, was opened at 2002-01-17 07:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Nobody/Anonymous (nobody)
Summary: make setup.py less chatty by default

Initial Comment:
I don't like the amount of output that setup.py
produces by default, and I don't like the way that -q
and -v affect the amount of output.  In general, I want
setup.py to tell me what it is doing and not what it is
skippping.  It's fine to say nothing with -q, but it
shouldn't say more without -v.

The attached patch is a bit of a kludge, but I'm not
familiar enough with distutils to do any better.  One
problem is that -v/--verbose has previously handled as
a flag, either on or off.  (There is a curiously large
amount of code that compares this boolean to see if
it's greater than some number!)  I had the options
processor to treat self.verbose as a count of -v
options.  So -vv is more verbose than -v.

Then I change the specific prints and announcements
that I've seen with setup.py that I didn't want to see.
 The messages I don't want to see (unless verbose is
high) are about skipping builds of Extensions and not
copying files that are already up-to-date.

With this patch in place, setup.py tells me only the
extensions is actually builds and files it actually copies.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 10:17

Message:
Logged In: YES 
user_id=31392

If I had to guess, I'd say cleaning up and rationalizing the
use of self.verbose and print vs self.announce() vs the
other methods that print things would teach you a lot about
the internals.

Hey, and reformat the code while you're at it <wink>.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-01-17 10:17

Message:
Logged In: YES 
user_id=38388

Jeremy, the patch touches the distutils code, but what you really 
want is to change the behaviour in one single use-case (the setup.py
which Python uses).

The "right" way to fix this would be to subclass the various distutils
classes to implement the change. If this becomes too complicated,
then distutils ought to be tweaked to make this easier in way that
doesn't break existing code (e.g. I don't want to miss the skip
notices for my stuff).

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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 09:25

Message:
Logged In: YES 
user_id=6656

You're not wrong :|

The "assert 0" is on the install path though.

Right.  I'm currently fighting emacs to let me print source
duplex, but I want to understand distutils' innards at some
point, might as well be now.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 08:50

Message:
Logged In: YES 
user_id=31392



The distutils package is a maze of twisty little passages
that all look the same <wink>.  I added an assert 0 to make
sure that the execution path that generated the output
wasn't the one with the assert 0.  (It wasn't.)  Didn't
intend for the patch to make it in.

But I'd still be surprised if this patch is the right thing.
 More likely that it demonstrates good behavior that could
be implemented more cleanly.

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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 08:45

Message:
Logged In: YES 
user_id=6656

Hokay, next question: why the "assert 0" in cmd.py?  Are you
sure you've finished?

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 08:32

Message:
Logged In: YES 
user_id=31392

Er, context diff.


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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 07:49

Message:
Logged In: YES 
user_id=6656

Um, context diff?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 18:25:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 10:25:10 -0800
Subject: [Patches] [ python-Patches-504889 ] make setup.py less chatty by default
Message-ID: <E16RHDq-0003im-00@usw-sf-web3.sourceforge.net>

Patches item #504889, was opened at 2002-01-17 07:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Nobody/Anonymous (nobody)
Summary: make setup.py less chatty by default

Initial Comment:
I don't like the amount of output that setup.py
produces by default, and I don't like the way that -q
and -v affect the amount of output.  In general, I want
setup.py to tell me what it is doing and not what it is
skippping.  It's fine to say nothing with -q, but it
shouldn't say more without -v.

The attached patch is a bit of a kludge, but I'm not
familiar enough with distutils to do any better.  One
problem is that -v/--verbose has previously handled as
a flag, either on or off.  (There is a curiously large
amount of code that compares this boolean to see if
it's greater than some number!)  I had the options
processor to treat self.verbose as a count of -v
options.  So -vv is more verbose than -v.

Then I change the specific prints and announcements
that I've seen with setup.py that I didn't want to see.
 The messages I don't want to see (unless verbose is
high) are about skipping builds of Extensions and not
copying files that are already up-to-date.

With this patch in place, setup.py tells me only the
extensions is actually builds and files it actually copies.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 10:25

Message:
Logged In: YES 
user_id=31392

MAL, I really want to change distutils not Python's
setup.py.  I use distutils for all sorts of projects and the
default chattiness is always a nuisance.  When I'm doing
development, I invariable have to wade through hundreds of
lines of useless output to find the one or two lines that
confirm a change was made.

You could still get the skip notices for your stuff, you'd
just have to run in extra verbose mode.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 10:17

Message:
Logged In: YES 
user_id=31392

If I had to guess, I'd say cleaning up and rationalizing the
use of self.verbose and print vs self.announce() vs the
other methods that print things would teach you a lot about
the internals.

Hey, and reformat the code while you're at it <wink>.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-01-17 10:17

Message:
Logged In: YES 
user_id=38388

Jeremy, the patch touches the distutils code, but what you really 
want is to change the behaviour in one single use-case (the setup.py
which Python uses).

The "right" way to fix this would be to subclass the various distutils
classes to implement the change. If this becomes too complicated,
then distutils ought to be tweaked to make this easier in way that
doesn't break existing code (e.g. I don't want to miss the skip
notices for my stuff).

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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 09:25

Message:
Logged In: YES 
user_id=6656

You're not wrong :|

The "assert 0" is on the install path though.

Right.  I'm currently fighting emacs to let me print source
duplex, but I want to understand distutils' innards at some
point, might as well be now.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 08:50

Message:
Logged In: YES 
user_id=31392



The distutils package is a maze of twisty little passages
that all look the same <wink>.  I added an assert 0 to make
sure that the execution path that generated the output
wasn't the one with the assert 0.  (It wasn't.)  Didn't
intend for the patch to make it in.

But I'd still be surprised if this patch is the right thing.
 More likely that it demonstrates good behavior that could
be implemented more cleanly.

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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 08:45

Message:
Logged In: YES 
user_id=6656

Hokay, next question: why the "assert 0" in cmd.py?  Are you
sure you've finished?

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 08:32

Message:
Logged In: YES 
user_id=31392

Er, context diff.


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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 07:49

Message:
Logged In: YES 
user_id=6656

Um, context diff?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 18:29:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 10:29:46 -0800
Subject: [Patches] [ python-Patches-502415 ] optimize attribute lookups
Message-ID: <E16RHII-0003n1-00@usw-sf-web3.sourceforge.net>

Patches item #502415, was opened at 2002-01-11 10:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502415&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko Ozoko (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: optimize attribute lookups

Initial Comment:
This patch optimizes the string comparisons in
class_getattr(), class_setattr(), instance_getattr1(),
and instance_setattr().

I pulled out the relevant section of class_setattr()
and measured its performance, yielding the following
results:

 * in the case that the argument does *not* begin with
"__", then the new version is 1.03 times as fast as the
old.  (This is a mystery to me, as the path through the
code looks the same, in C.  I examined the assembly
that GCC v3.0.3 generated in -O3 mode, and it is true
that the assembly for the new version is
smaller/faster, although I don't really understand why.)

 * in the case that the argument is a string of random
length between 1 and 19 inclusive, and it begins with
"__" and ends with "X_" (where X is a random alphabetic
character), then the new version 1.12 times as fast as
the old.

 * in the case that the argument is a string of random
length between 1 and 19 inclusive, and it begins with
"__" and does *not* end with "_", then the new version
1.16 times as fast as the old.

 * in the case that the argument is (randomly) one of
the six special names, then the new version is 2.7
times as fast as the old.

 * in the case that the argument is a string of random
length between 1 and 19 inclusive, and it begins with
"__" and ends with "__" (but is not one of the six
special names), then the new version is 3.7 times as
fast as the old.



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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 10:29

Message:
Logged In: YES 
user_id=31392

This seems to add a lot of complexity for a few special
cases.  How important are these particular attributes?  Do
you have any benchmark applications that show real
improvement?  It seems like microbenchmarks overstate the
benefit, since we don't know how often these attributes are
looked up by most applications.

It would also be interesting to see how much of the benefit
for non __ names is the result of the PyString_AS_STRING()
macro.  Maybe that's all the change we really need :-).


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502415&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 20:33:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 12:33:44 -0800
Subject: [Patches] [ python-Patches-502415 ] optimize attribute lookups
Message-ID: <E16RJEG-00011Y-00@usw-sf-web1.sourceforge.net>

Patches item #502415, was opened at 2002-01-11 10:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502415&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko Ozoko (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: optimize attribute lookups

Initial Comment:
This patch optimizes the string comparisons in
class_getattr(), class_setattr(), instance_getattr1(),
and instance_setattr().

I pulled out the relevant section of class_setattr()
and measured its performance, yielding the following
results:

 * in the case that the argument does *not* begin with
"__", then the new version is 1.03 times as fast as the
old.  (This is a mystery to me, as the path through the
code looks the same, in C.  I examined the assembly
that GCC v3.0.3 generated in -O3 mode, and it is true
that the assembly for the new version is
smaller/faster, although I don't really understand why.)

 * in the case that the argument is a string of random
length between 1 and 19 inclusive, and it begins with
"__" and ends with "X_" (where X is a random alphabetic
character), then the new version 1.12 times as fast as
the old.

 * in the case that the argument is a string of random
length between 1 and 19 inclusive, and it begins with
"__" and does *not* end with "_", then the new version
1.16 times as fast as the old.

 * in the case that the argument is (randomly) one of
the six special names, then the new version is 2.7
times as fast as the old.

 * in the case that the argument is a string of random
length between 1 and 19 inclusive, and it begins with
"__" and ends with "__" (but is not one of the six
special names), then the new version is 3.7 times as
fast as the old.



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

>Comment By: Zooko Ozoko (zooko)
Date: 2002-01-17 12:33

Message:
Logged In: YES 
user_id=52562

Yeah, the optimized version is less readable that the original.

I'll try to come up with a benchmark application.  Any
ideas?  Maybe some unit tests from Zope that use attribute
lookups heavily?

My guess is that the actual results in an application will
be "marginal", like maybe between 0.5% to 3% improvement.



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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 10:29

Message:
Logged In: YES 
user_id=31392

This seems to add a lot of complexity for a few special
cases.  How important are these particular attributes?  Do
you have any benchmark applications that show real
improvement?  It seems like microbenchmarks overstate the
benefit, since we don't know how often these attributes are
looked up by most applications.

It would also be interesting to see how much of the benefit
for non __ names is the result of the PyString_AS_STRING()
macro.  Maybe that's all the change we really need :-).


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502415&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 23:09:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 15:09:30 -0800
Subject: [Patches] [ python-Patches-477752 ] Drop old-style getargs from curses
Message-ID: <E16RLf0-0007WN-00@usw-sf-web3.sourceforge.net>

Patches item #477752, was opened at 2001-11-03 02:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477752&group_id=5470

Category: Modules
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Martin v. Löwis (loewis)
Summary: Drop old-style getargs from curses

Initial Comment:
This patch converts _cursesmodule and _curses_panel
into using ParseTuple, METH_VARARGS, METH_NOARGS, and
METH_O throughout.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-17 15:09

Message:
Logged In: YES 
user_id=21627

Committed as py_curses.h 1.4, _curses_panel.c 1.9,
_cursesmodule.c 2.64.

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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 09:36

Message:
Logged In: YES 
user_id=6656

Patch no longer applies cleanly; don't really understand why.

Fix that and check it in?  I haven't checked each line of
the patch, but it looks innocuous enough.  Changing
resolution to "Accepted" on the grounds that noone else is
likely to care, but feel free to leap in if you do.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477752&group_id=5470


From noreply@sourceforge.net  Thu Jan 17 23:18:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 15:18:26 -0800
Subject: [Patches] [ python-Patches-477750 ] Use METH_ constants in Modules
Message-ID: <E16RLne-0007dc-00@usw-sf-web3.sourceforge.net>

Patches item #477750, was opened at 2001-11-03 02:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477750&group_id=5470

Category: Modules
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use METH_ constants in Modules

Initial Comment:
This patch addes METH_OLDARGS and METH_VARARGS into
every method table (except for curses, for which a
separate patch is upcoming).

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-17 15:18

Message:
Logged In: YES 
user_id=21627

Committed as

_codecsmodule.c 2.11
_tkinter.c 1.122
audioop.c 1.48
bsddbmodule.c 1.32
cdmodule.c 1.27
clmodule.c 2.26
dlmodule.c 2.20
flmodule.c 1.48
fmmodule.c 1.19
fpectlmodule.c 2.15
fpetestmodule.c 2.7
imageop.c 2.26
imgfile.c 1.29
mmapmodule.c 2.37
mpzmodule.c 2.39
nismodule.c 2.22
pcremodule.c 2.31
puremodule.c 2.5
regexmodule.c 1.46
resource.c 2.21
rgbimgmodule.c 2.24
rotormodule.c 2.32
sgimodule.c 1.18
socketmodule.c 1.203
sunaudiodev.c 1.28
svmodule.c 2.19
timingmodule.c 2.9


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-12 03:35

Message:
Logged In: YES 
user_id=21627

Jeremy, any objection to applying this now?

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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-12-04 08:19

Message:
Logged In: YES 
user_id=31392

We should probably wait until after 2.2 to make all these
changes.  I expect they're harmless, but it's a lot of code
to change at the last minute.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=477750&group_id=5470


From noreply@sourceforge.net  Fri Jan 18 00:22:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 Jan 2002 16:22:00 -0800
Subject: [Patches] [ python-Patches-502415 ] optimize attribute lookups
Message-ID: <E16RMnA-00043Y-00@usw-sf-web1.sourceforge.net>

Patches item #502415, was opened at 2002-01-11 10:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502415&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko Ozoko (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: optimize attribute lookups

Initial Comment:
This patch optimizes the string comparisons in
class_getattr(), class_setattr(), instance_getattr1(),
and instance_setattr().

I pulled out the relevant section of class_setattr()
and measured its performance, yielding the following
results:

 * in the case that the argument does *not* begin with
"__", then the new version is 1.03 times as fast as the
old.  (This is a mystery to me, as the path through the
code looks the same, in C.  I examined the assembly
that GCC v3.0.3 generated in -O3 mode, and it is true
that the assembly for the new version is
smaller/faster, although I don't really understand why.)

 * in the case that the argument is a string of random
length between 1 and 19 inclusive, and it begins with
"__" and ends with "X_" (where X is a random alphabetic
character), then the new version 1.12 times as fast as
the old.

 * in the case that the argument is a string of random
length between 1 and 19 inclusive, and it begins with
"__" and does *not* end with "_", then the new version
1.16 times as fast as the old.

 * in the case that the argument is (randomly) one of
the six special names, then the new version is 2.7
times as fast as the old.

 * in the case that the argument is a string of random
length between 1 and 19 inclusive, and it begins with
"__" and ends with "__" (but is not one of the six
special names), then the new version is 3.7 times as
fast as the old.



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

>Comment By: Zooko Ozoko (zooko)
Date: 2002-01-17 16:22

Message:
Logged In: YES 
user_id=52562

Okay I've done some "mini benchmarks".  The earlier reported
micro-benchmarks were the result of running the inner loop
itself, in C.  These mini benchmarks are the result of
running this Python script:

class A:
    def __init__(self):
        self.a = 0

a = A()
for i in xrange(2**20):
    a.a = i

print a.a

and then using different attribute names in place of `a'.
The results are as expected: the optimized version is faster
than the current one, depending on the shape of the
attribute name, and dampened by the fact that there is now
other work being done.  The case that shows the smallest
difference is when the attribute name neither begins nor
ends with an '_'.  In that case the above script runs about
2% faster with the optimizations.  The case that shows the
biggest difference is when the attribute begins and ends
with '__', as in `__a__'.  Then the above script runs about
15% faster.

This still isn't a *real* application benchmark.  I'm
looking for one that is a reasonable case for real Python
users but that also uses attribute lookups heavily.


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

Comment By: Zooko Ozoko (zooko)
Date: 2002-01-17 12:33

Message:
Logged In: YES 
user_id=52562

Yeah, the optimized version is less readable that the original.

I'll try to come up with a benchmark application.  Any
ideas?  Maybe some unit tests from Zope that use attribute
lookups heavily?

My guess is that the actual results in an application will
be "marginal", like maybe between 0.5% to 3% improvement.



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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 10:29

Message:
Logged In: YES 
user_id=31392

This seems to add a lot of complexity for a few special
cases.  How important are these particular attributes?  Do
you have any benchmark applications that show real
improvement?  It seems like microbenchmarks overstate the
benefit, since we don't know how often these attributes are
looked up by most applications.

It would also be interesting to see how much of the benefit
for non __ names is the result of the PyString_AS_STRING()
macro.  Maybe that's all the change we really need :-).


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502415&group_id=5470


From noreply@sourceforge.net  Fri Jan 18 09:05:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 Jan 2002 01:05:53 -0800
Subject: [Patches] [ python-Patches-504889 ] make setup.py less chatty by default
Message-ID: <E16RUy9-0000JQ-00@usw-sf-web2.sourceforge.net>

Patches item #504889, was opened at 2002-01-17 07:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Nobody/Anonymous (nobody)
Summary: make setup.py less chatty by default

Initial Comment:
I don't like the amount of output that setup.py
produces by default, and I don't like the way that -q
and -v affect the amount of output.  In general, I want
setup.py to tell me what it is doing and not what it is
skippping.  It's fine to say nothing with -q, but it
shouldn't say more without -v.

The attached patch is a bit of a kludge, but I'm not
familiar enough with distutils to do any better.  One
problem is that -v/--verbose has previously handled as
a flag, either on or off.  (There is a curiously large
amount of code that compares this boolean to see if
it's greater than some number!)  I had the options
processor to treat self.verbose as a count of -v
options.  So -vv is more verbose than -v.

Then I change the specific prints and announcements
that I've seen with setup.py that I didn't want to see.
 The messages I don't want to see (unless verbose is
high) are about skipping builds of Extensions and not
copying files that are already up-to-date.

With this patch in place, setup.py tells me only the
extensions is actually builds and files it actually copies.


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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-01-18 01:05

Message:
Logged In: YES 
user_id=38388

Jeremy, if that's what you want you should at least post
to the distutils list before going ahead and change things.

E.g. I can't see why "skip" notices are any less important
than "building..." notices: they tell you that distutils has
found some components up-to-date and that may sometimes
not be what you'd really expect.

We should first discuss, what distutils developers want as
default and then go ahead and fixup distutils to meet those
demands.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 10:25

Message:
Logged In: YES 
user_id=31392

MAL, I really want to change distutils not Python's
setup.py.  I use distutils for all sorts of projects and the
default chattiness is always a nuisance.  When I'm doing
development, I invariable have to wade through hundreds of
lines of useless output to find the one or two lines that
confirm a change was made.

You could still get the skip notices for your stuff, you'd
just have to run in extra verbose mode.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 10:17

Message:
Logged In: YES 
user_id=31392

If I had to guess, I'd say cleaning up and rationalizing the
use of self.verbose and print vs self.announce() vs the
other methods that print things would teach you a lot about
the internals.

Hey, and reformat the code while you're at it <wink>.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-01-17 10:17

Message:
Logged In: YES 
user_id=38388

Jeremy, the patch touches the distutils code, but what you really 
want is to change the behaviour in one single use-case (the setup.py
which Python uses).

The "right" way to fix this would be to subclass the various distutils
classes to implement the change. If this becomes too complicated,
then distutils ought to be tweaked to make this easier in way that
doesn't break existing code (e.g. I don't want to miss the skip
notices for my stuff).

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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 09:25

Message:
Logged In: YES 
user_id=6656

You're not wrong :|

The "assert 0" is on the install path though.

Right.  I'm currently fighting emacs to let me print source
duplex, but I want to understand distutils' innards at some
point, might as well be now.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 08:50

Message:
Logged In: YES 
user_id=31392



The distutils package is a maze of twisty little passages
that all look the same <wink>.  I added an assert 0 to make
sure that the execution path that generated the output
wasn't the one with the assert 0.  (It wasn't.)  Didn't
intend for the patch to make it in.

But I'd still be surprised if this patch is the right thing.
 More likely that it demonstrates good behavior that could
be implemented more cleanly.

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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 08:45

Message:
Logged In: YES 
user_id=6656

Hokay, next question: why the "assert 0" in cmd.py?  Are you
sure you've finished?

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 08:32

Message:
Logged In: YES 
user_id=31392

Er, context diff.


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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 07:49

Message:
Logged In: YES 
user_id=6656

Um, context diff?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470


From noreply@sourceforge.net  Fri Jan 18 14:01:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 Jan 2002 06:01:03 -0800
Subject: [Patches] [ python-Patches-505375 ] Make doc strings optional
Message-ID: <E16RZZn-0001LC-00@usw-sf-web3.sourceforge.net>

Patches item #505375, was opened at 2002-01-18 06:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505375&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make doc strings optional

Initial Comment:
As discussed in python-dev, documentation strings are 
responsible for 10% of python's executable footprint. 
This patch tries to merge everyone's idea about how 
documentation strings should be optional.

Please note that, for now, only sysmodule.c is using 
the new macros. When this patch get in, I (and 
others, maybe) will gradually implement these macros 
in all documentation strings available in python's 
code.

Reference:
http://mail.python.org/pipermail/python-dev/2002-January/019392.html


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505375&group_id=5470


From noreply@sourceforge.net  Fri Jan 18 14:53:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 Jan 2002 06:53:44 -0800
Subject: [Patches] [ python-Patches-504889 ] make setup.py less chatty by default
Message-ID: <E16RaOm-0006CC-00@usw-sf-web1.sourceforge.net>

Patches item #504889, was opened at 2002-01-17 07:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Nobody/Anonymous (nobody)
Summary: make setup.py less chatty by default

Initial Comment:
I don't like the amount of output that setup.py
produces by default, and I don't like the way that -q
and -v affect the amount of output.  In general, I want
setup.py to tell me what it is doing and not what it is
skippping.  It's fine to say nothing with -q, but it
shouldn't say more without -v.

The attached patch is a bit of a kludge, but I'm not
familiar enough with distutils to do any better.  One
problem is that -v/--verbose has previously handled as
a flag, either on or off.  (There is a curiously large
amount of code that compares this boolean to see if
it's greater than some number!)  I had the options
processor to treat self.verbose as a count of -v
options.  So -vv is more verbose than -v.

Then I change the specific prints and announcements
that I've seen with setup.py that I didn't want to see.
 The messages I don't want to see (unless verbose is
high) are about skipping builds of Extensions and not
copying files that are already up-to-date.

With this patch in place, setup.py tells me only the
extensions is actually builds and files it actually copies.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-18 06:53

Message:
Logged In: YES 
user_id=31392

Good suggestion.  I hadn't planned to change anything, but
wanted to capture the feature request and share the code.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-01-18 01:05

Message:
Logged In: YES 
user_id=38388

Jeremy, if that's what you want you should at least post
to the distutils list before going ahead and change things.

E.g. I can't see why "skip" notices are any less important
than "building..." notices: they tell you that distutils has
found some components up-to-date and that may sometimes
not be what you'd really expect.

We should first discuss, what distutils developers want as
default and then go ahead and fixup distutils to meet those
demands.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 10:25

Message:
Logged In: YES 
user_id=31392

MAL, I really want to change distutils not Python's
setup.py.  I use distutils for all sorts of projects and the
default chattiness is always a nuisance.  When I'm doing
development, I invariable have to wade through hundreds of
lines of useless output to find the one or two lines that
confirm a change was made.

You could still get the skip notices for your stuff, you'd
just have to run in extra verbose mode.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 10:17

Message:
Logged In: YES 
user_id=31392

If I had to guess, I'd say cleaning up and rationalizing the
use of self.verbose and print vs self.announce() vs the
other methods that print things would teach you a lot about
the internals.

Hey, and reformat the code while you're at it <wink>.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-01-17 10:17

Message:
Logged In: YES 
user_id=38388

Jeremy, the patch touches the distutils code, but what you really 
want is to change the behaviour in one single use-case (the setup.py
which Python uses).

The "right" way to fix this would be to subclass the various distutils
classes to implement the change. If this becomes too complicated,
then distutils ought to be tweaked to make this easier in way that
doesn't break existing code (e.g. I don't want to miss the skip
notices for my stuff).

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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 09:25

Message:
Logged In: YES 
user_id=6656

You're not wrong :|

The "assert 0" is on the install path though.

Right.  I'm currently fighting emacs to let me print source
duplex, but I want to understand distutils' innards at some
point, might as well be now.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 08:50

Message:
Logged In: YES 
user_id=31392



The distutils package is a maze of twisty little passages
that all look the same <wink>.  I added an assert 0 to make
sure that the execution path that generated the output
wasn't the one with the assert 0.  (It wasn't.)  Didn't
intend for the patch to make it in.

But I'd still be surprised if this patch is the right thing.
 More likely that it demonstrates good behavior that could
be implemented more cleanly.

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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 08:45

Message:
Logged In: YES 
user_id=6656

Hokay, next question: why the "assert 0" in cmd.py?  Are you
sure you've finished?

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-01-17 08:32

Message:
Logged In: YES 
user_id=31392

Er, context diff.


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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 07:49

Message:
Logged In: YES 
user_id=6656

Um, context diff?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470


From noreply@sourceforge.net  Fri Jan 18 17:49:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 Jan 2002 09:49:25 -0800
Subject: [Patches] [ python-Patches-505464 ] fix (??) bug in `gc.get_referrers()'
Message-ID: <E16Rd8n-0004Z2-00@usw-sf-web3.sourceforge.net>

Patches item #505464, was opened at 2002-01-18 09:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505464&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko Ozoko (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix (??) bug in `gc.get_referrers()'

Initial Comment:
This eliminates the symptoms of bug "[ #505453 ] bug in
gc.get_referrers()".

As documented in that bug report, I urge you to leave
the bug open until someone (me, if necessary) examines
the unexplained behavior.



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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505464&group_id=5470


From noreply@sourceforge.net  Fri Jan 18 20:50:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 Jan 2002 12:50:54 -0800
Subject: [Patches] [ python-Patches-505464 ] fix (??) bug in `gc.get_referrers()'
Message-ID: <E16RfyQ-0002c1-00@usw-sf-web1.sourceforge.net>

Patches item #505464, was opened at 2002-01-18 09:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505464&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko Ozoko (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix (??) bug in `gc.get_referrers()'

Initial Comment:
This eliminates the symptoms of bug "[ #505453 ] bug in
gc.get_referrers()".

As documented in that bug report, I urge you to leave
the bug open until someone (me, if necessary) examines
the unexplained behavior.



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

>Comment By: Zooko Ozoko (zooko)
Date: 2002-01-18 12:50

Message:
Logged In: YES 
user_id=52562

Whoops.  The unexplained behavior of the bug that I
described in the bug report "[ #505453 ] bug in
gc.get_referrers()" was in fact just my misinterpreting the
results.

I believe that this patch fixes that bug.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505464&group_id=5470


From noreply@sourceforge.net  Sat Jan 19 00:02:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 Jan 2002 16:02:05 -0800
Subject: [Patches] [ python-Patches-458898 ] --python-build for install
Message-ID: <E16RixR-0003Wc-00@usw-sf-web2.sourceforge.net>

Patches item #458898, was opened at 2001-09-05 13:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458898&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
Assigned to: Michael Hudson (mwh)
Summary: --python-build for install

Initial Comment:
Sometimes, being able to install python tools without
having python installed is desirable. When building an
RPM package of python, for example, one may want to
build/install IDLE as well, including it in a
subpackage. Indeed, we're doing this with a couple of
python tools here at Conectiva. Unfortunately, we have
a egg-chicken problem when doing this. You need python
installed in your system before you install tools. This
limitation may be observed in the file
Lib/distutils/sysconfig.py. It looks for Makefile in
the final installation directory, for example.

This patch adds a new option to dist-utils' install
command: --python-build. When used, python will look
for these files in the python build directory specified
trough the option.



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

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-01-18 16:02

Message:
Logged In: YES 
user_id=7887

Here is a new patch including your suggestions.

Thank you!!


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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 09:49

Message:
Logged In: YES 
user_id=6656

Hey!  This patch is less than six months old.  Virtually
fresh :|

Some comments:  are you sure you can get away with only
honouring --python-build in install?  I think build_scripts
needs it too (now, anyway, maybe not when you wrote the patch).

Also, the mod to install.finalize_options() is in the wrong
place wrt. the surrouding comments.  Can you fix this?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458898&group_id=5470


From noreply@sourceforge.net  Sat Jan 19 09:21:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 19 Jan 2002 01:21:39 -0800
Subject: [Patches] [ python-Patches-505705 ] Remove eval in pickle
Message-ID: <E16Rrgx-0002tx-00@usw-sf-web1.sourceforge.net>

Patches item #505705, was opened at 2002-01-19 01:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505705&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove eval in pickle

Initial Comment:
This patch removes the use of eval in pickle and cPickle.

It does so by:
- moving the actual parsing from compile.c:parsestr to
PyString_DecodeEscape
- introducing a new codec string-escape
- removing the code that checks that a
string-to-unpickle is properly escaped throughout, and
replaces this with a check whether it is properly quoted,
- unquoting the string in load_string, then passing it
to the codec.

This fixes #502503.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505705&group_id=5470


From noreply@sourceforge.net  Sat Jan 19 09:25:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 19 Jan 2002 01:25:27 -0800
Subject: [Patches] [ python-Patches-505705 ] Remove eval in pickle
Message-ID: <E16Rrkd-0002wY-00@usw-sf-web1.sourceforge.net>

Patches item #505705, was opened at 2002-01-19 01:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505705&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove eval in pickle

Initial Comment:
This patch removes the use of eval in pickle and cPickle.

It does so by:
- moving the actual parsing from compile.c:parsestr to
PyString_DecodeEscape
- introducing a new codec string-escape
- removing the code that checks that a
string-to-unpickle is properly escaped throughout, and
replaces this with a check whether it is properly quoted,
- unquoting the string in load_string, then passing it
to the codec.

This fixes #502503.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-19 01:25

Message:
Logged In: YES 
user_id=21627

BTW, this patch has #500002 as a prerequisite.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505705&group_id=5470


From noreply@sourceforge.net  Sat Jan 19 10:01:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 19 Jan 2002 02:01:55 -0800
Subject: [Patches] [ python-Patches-459381 ] Unambiguous import for encodings
Message-ID: <E16RsJv-0003MC-00@usw-sf-web1.sourceforge.net>

Patches item #459381, was opened at 2001-09-06 18:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459381&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mikhail Zabaluev (mzabaluev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unambiguous import for encodings

Initial Comment:
The __import__ call in encodings/__init__.py does not
specify module hierarchy explicitly. This results in
misleading error tracebacks (try
"codecs.lookup('codecs')"). Worse, it results in an
error when one is trying to lookup a codec and the
encoding's name fires some top-level module, e.g
'base64', despite that a codec for this encoding may
actually be registered in the system.


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-19 02:01

Message:
Logged In: YES 
user_id=21627

I'm in favour of integrating this patch, even though it
means that some codecs that are currently found won't be
found anymore. Authors of such codecs would need to register
a search function.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=459381&group_id=5470


From noreply@sourceforge.net  Sat Jan 19 10:23:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 19 Jan 2002 02:23:44 -0800
Subject: [Patches] [ python-Patches-497102 ] building a shared python library
Message-ID: <E16Rsf2-000233-00@usw-sf-web2.sourceforge.net>

Patches item #497102, was opened at 2001-12-27 10:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497102&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: building a shared python library

Initial Comment:
This patch allows builing of libpython.so in addition 
to build libpython.a. The patch currently is used for 
building the python package on Debian GNU/Linux, so it 
needs to be cleaned up for other architectures. 
However python already has support for building shared 
libs, so this should not be a major problem. Feedback 
for a cleanup of the patch is appreciated.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-01-19 02:23

Message:
Logged In: NO 

It would be really helpful to have this patch applied. 
Certain uses of python are impossible without a python
shared library (usually involving a combination of extension
modules and embedding python).

The PyXPCOM bindings are one such example.  It looks like we
might run into a similar problem when writing bindings for
gnome-vfs.

In the gnome-vfs case, it allows loadable modules that
implement file systems.  One such module might be a wrapper
that passes on all gnome-vfs requests to python code.  It
would be a shared library, embedding a python interpreter,
and running python code.  This module would then be loaded
by any gnome-vfs using application when certain paths are
requested.  As there is no libpython.so, this vfs module
would be staticly linked to libpython, so it contains a copy
of the interpreter.

Now the gnome-vfs library would also be useful in python
applications (especially gnome ones, so that it uses the
same filesystem space as other apps).  This support would be
implemented as an extension for python.

Things get interesting when a python application uses
gnome-vfs to access a file handled by the python vfs module.
 There is one copy of the interpreter in the the main python
executable, and another in the vfs module.  This means
different bits of code may end up using different copies of
the interpreter (and we get two global interpreter locks,
etc, etc).  This leads to all kinds of problems.

With a shared libpython, both the vfs module and python
executable will be using the same interpreter, and all these
problems disapear.

Getting this patch into python distribution would be _very_
useful.

James Henstridge <james at daa dot com dot au>


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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-28 13:43

Message:
Logged In: YES 
user_id=21627

The patch looks good (it is the third or so of its kind, but
I'm optimistic that it can be integrated this time).

Would you like to take another round of cleanup? Specifically:

- Building libpython as a shared library MUST be a
configuration-time option, this is not negotiable. On many
systems, building libpython as a shared library will cause
problems, since the directory containing libpython won't be
in the standard search path of the dynamic linker (e.g. in
/usr/local/lib on Solaris). Adding -R options helps, but not
much, since the binaries won't be relocatable with such
options. The options should default to "off" (static
linking); this is negotiable.
 
- It seems that the patch has a few unrelated changes. What
system is GNU* (I assume the Hurd?) Those should come in a
separate patch.

- Library versioning needs discussion. It seems that this
patch will give the library a name of libpython2.2.so.0.0.
Under which conditions should the SONAME be changed? If
2.2.1 comes along, how should the SOVERSION change? To 0.1?
Or to 1.0? I'd prefer to start with 1.0, anyway - procedures
to bump the SOVERSION still need to be discussed (I assume
bumping the minor version for Python micro releases should
be ok).

- If the option for building as a shared library is
activated, assume, by default, that the procedure on all
systems is identical, i.e. don't try to write Linux-specific
code. We can test it on many systems, and on others, users
simply can't activate the option. Please put assignments to
LDLIBRARY all in one place (there is already a section that
does so for dgux/beos/cygwin).

- What is the value of building both PIC and non-PIC
objects? If libpython is a shared library, I'd suggest to
put PIC objects into libpython.a, anyway. That would allow
to get rid of the pic_o objects. If some Debian policy says
a .a library must not contain PIC objects, I could live with
two compilations per source file.

- Put the computation of system-dependent options all in
configure.in. In particular, passing -soname should be done
in configure.in; that should probably be the same on all
systems building a shared libpython using GCC.

- Please don't use LD_PRELOAD. Using LD_LIBRARY_PATH seems
more sensible, IMO.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497102&group_id=5470


From noreply@sourceforge.net  Sat Jan 19 15:32:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 19 Jan 2002 07:32:57 -0800
Subject: [Patches] [ python-Patches-497102 ] building a shared python library
Message-ID: <E16RxUH-0005bx-00@usw-sf-web2.sourceforge.net>

Patches item #497102, was opened at 2001-12-27 10:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497102&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: building a shared python library

Initial Comment:
This patch allows builing of libpython.so in addition 
to build libpython.a. The patch currently is used for 
building the python package on Debian GNU/Linux, so it 
needs to be cleaned up for other architectures. 
However python already has support for building shared 
libs, so this should not be a major problem. Feedback 
for a cleanup of the patch is appreciated.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-19 07:32

Message:
Logged In: YES 
user_id=21627

In the current form, the patch is simply unacceptable. There
is no doubt that this feature has its applications; and
there is no need to lobby for it. Instead, fixing the
problems in the implementation of the feature would make a
difference.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-01-19 02:23

Message:
Logged In: NO 

It would be really helpful to have this patch applied. 
Certain uses of python are impossible without a python
shared library (usually involving a combination of extension
modules and embedding python).

The PyXPCOM bindings are one such example.  It looks like we
might run into a similar problem when writing bindings for
gnome-vfs.

In the gnome-vfs case, it allows loadable modules that
implement file systems.  One such module might be a wrapper
that passes on all gnome-vfs requests to python code.  It
would be a shared library, embedding a python interpreter,
and running python code.  This module would then be loaded
by any gnome-vfs using application when certain paths are
requested.  As there is no libpython.so, this vfs module
would be staticly linked to libpython, so it contains a copy
of the interpreter.

Now the gnome-vfs library would also be useful in python
applications (especially gnome ones, so that it uses the
same filesystem space as other apps).  This support would be
implemented as an extension for python.

Things get interesting when a python application uses
gnome-vfs to access a file handled by the python vfs module.
 There is one copy of the interpreter in the the main python
executable, and another in the vfs module.  This means
different bits of code may end up using different copies of
the interpreter (and we get two global interpreter locks,
etc, etc).  This leads to all kinds of problems.

With a shared libpython, both the vfs module and python
executable will be using the same interpreter, and all these
problems disapear.

Getting this patch into python distribution would be _very_
useful.

James Henstridge <james at daa dot com dot au>


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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-28 13:43

Message:
Logged In: YES 
user_id=21627

The patch looks good (it is the third or so of its kind, but
I'm optimistic that it can be integrated this time).

Would you like to take another round of cleanup? Specifically:

- Building libpython as a shared library MUST be a
configuration-time option, this is not negotiable. On many
systems, building libpython as a shared library will cause
problems, since the directory containing libpython won't be
in the standard search path of the dynamic linker (e.g. in
/usr/local/lib on Solaris). Adding -R options helps, but not
much, since the binaries won't be relocatable with such
options. The options should default to "off" (static
linking); this is negotiable.
 
- It seems that the patch has a few unrelated changes. What
system is GNU* (I assume the Hurd?) Those should come in a
separate patch.

- Library versioning needs discussion. It seems that this
patch will give the library a name of libpython2.2.so.0.0.
Under which conditions should the SONAME be changed? If
2.2.1 comes along, how should the SOVERSION change? To 0.1?
Or to 1.0? I'd prefer to start with 1.0, anyway - procedures
to bump the SOVERSION still need to be discussed (I assume
bumping the minor version for Python micro releases should
be ok).

- If the option for building as a shared library is
activated, assume, by default, that the procedure on all
systems is identical, i.e. don't try to write Linux-specific
code. We can test it on many systems, and on others, users
simply can't activate the option. Please put assignments to
LDLIBRARY all in one place (there is already a section that
does so for dgux/beos/cygwin).

- What is the value of building both PIC and non-PIC
objects? If libpython is a shared library, I'd suggest to
put PIC objects into libpython.a, anyway. That would allow
to get rid of the pic_o objects. If some Debian policy says
a .a library must not contain PIC objects, I could live with
two compilations per source file.

- Put the computation of system-dependent options all in
configure.in. In particular, passing -soname should be done
in configure.in; that should probably be the same on all
systems building a shared libpython using GCC.

- Please don't use LD_PRELOAD. Using LD_LIBRARY_PATH seems
more sensible, IMO.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=497102&group_id=5470


From noreply@sourceforge.net  Sat Jan 19 19:24:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 19 Jan 2002 11:24:52 -0800
Subject: [Patches] [ python-Patches-505826 ] demo warning for expressions w/no effect
Message-ID: <E16S16i-0001mF-00@usw-sf-web1.sourceforge.net>

Patches item #505826, was opened at 2002-01-19 11:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505826&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: demo warning for expressions w/no effect

Initial Comment:
This patch is not meant to be applied as is.  
It is for discussion purposes.

It modifies the compiler to warn about statements that
have no effect.  It does a printf() when it determines
an expression has no effect.  The sample definition is:
 a POP_TOP preceded by a BINARY_* or a LOAD_* operation.



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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505826&group_id=5470


From noreply@sourceforge.net  Sat Jan 19 20:13:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 19 Jan 2002 12:13:55 -0800
Subject: [Patches] [ python-Patches-505846 ] pyport.h, Wince and errno getter/setter
Message-ID: <E16S1sB-0002Sg-00@usw-sf-web1.sourceforge.net>

Patches item #505846, was opened at 2002-01-19 12:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brad Clements (bkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyport.h, Wince and errno getter/setter

Initial Comment:
Most of the remaining Windows CE diffs are due to the 
lack of errno on Windows CE. There are other OS's that 
do not have errno (but they have a workalike method).

At first I had simply commented out all references in 
the code to errno, but that quickly became unworkable. 

Wince and NetWare use a function to set the per-
thread "errno" value. Although errno #defines  (like 
ERANGE) are not defined for Wince, they are defined 
for NetWare. Removing references to errno would 
artificially hobble the NetWare port.

These platforms also use a function to retrieve the 
current errno value.

The attached diff for pyport.h attempts to standardize 
the access method for errno (or it's work-alike) by 
providing SetErrno(), ClearErrno() and GetErrno() 
macros.

ClearErrno() is SetErrno(0)

I've found and changed all direct references to errno 
to use these macros. This patch must be submitted 
before the patches for other modules.

--

I see two negatives with this approach:

1. It will be a pain to think GetErrno() instead 
of "errno" when modifying/writing new code.

2. Extension modules will need access to pyport.h for 
the target platform.

In the worst case, directly referencing errno instead 
of using the macros will break only those platforms 
for which the macros do something different. That is, 
Wince and NetWare.

--

An alternative spelling/capitalization of these macros 
might make them more appealing. Feel free to make a 
suggestion.


--

It's probably incorrect for me to use SetErrno() as a 
function, such as

   SetErrno(1);

I think the semi-colon is not needed, but wasn't 
entirely certain. On better advice, I will fix these 
statements in the remaining source files if this patch 
is accepted.



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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470


From noreply@sourceforge.net  Sat Jan 19 20:28:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 19 Jan 2002 12:28:13 -0800
Subject: [Patches] [ python-Patches-505846 ] pyport.h, Wince and errno getter/setter
Message-ID: <E16S261-0000xi-00@usw-sf-web2.sourceforge.net>

Patches item #505846, was opened at 2002-01-19 12:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brad Clements (bkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyport.h, Wince and errno getter/setter

Initial Comment:
Most of the remaining Windows CE diffs are due to the 
lack of errno on Windows CE. There are other OS's that 
do not have errno (but they have a workalike method).

At first I had simply commented out all references in 
the code to errno, but that quickly became unworkable. 

Wince and NetWare use a function to set the per-
thread "errno" value. Although errno #defines  (like 
ERANGE) are not defined for Wince, they are defined 
for NetWare. Removing references to errno would 
artificially hobble the NetWare port.

These platforms also use a function to retrieve the 
current errno value.

The attached diff for pyport.h attempts to standardize 
the access method for errno (or it's work-alike) by 
providing SetErrno(), ClearErrno() and GetErrno() 
macros.

ClearErrno() is SetErrno(0)

I've found and changed all direct references to errno 
to use these macros. This patch must be submitted 
before the patches for other modules.

--

I see two negatives with this approach:

1. It will be a pain to think GetErrno() instead 
of "errno" when modifying/writing new code.

2. Extension modules will need access to pyport.h for 
the target platform.

In the worst case, directly referencing errno instead 
of using the macros will break only those platforms 
for which the macros do something different. That is, 
Wince and NetWare.

--

An alternative spelling/capitalization of these macros 
might make them more appealing. Feel free to make a 
suggestion.


--

It's probably incorrect for me to use SetErrno() as a 
function, such as

   SetErrno(1);

I think the semi-colon is not needed, but wasn't 
entirely certain. On better advice, I will fix these 
statements in the remaining source files if this patch 
is accepted.



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-19 12:28

Message:
Logged In: YES 
user_id=33168

Typically, the semi-colon problem is dealt with as in
Py_SET_ERANGE_IF_OVERFLOW.

So, 

#define SetErrno(X) do { SetLastError(X); } while (0)

I don't think (but can't remember if) there is any problem
for single statements like you have.  You could probably do:

#ifndef MS_WINCE
#define SetErrno(X) errno = (X)     /* note no ; */
#else
#define SetErrno(X) SetLastError(X) /* note no ; */
#endif


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470


From noreply@sourceforge.net  Sat Jan 19 20:52:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 19 Jan 2002 12:52:11 -0800
Subject: [Patches] [ python-Patches-505846 ] pyport.h, Wince and errno getter/setter
Message-ID: <E16S2TD-0001Fm-00@usw-sf-web2.sourceforge.net>

Patches item #505846, was opened at 2002-01-19 12:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brad Clements (bkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyport.h, Wince and errno getter/setter

Initial Comment:
Most of the remaining Windows CE diffs are due to the 
lack of errno on Windows CE. There are other OS's that 
do not have errno (but they have a workalike method).

At first I had simply commented out all references in 
the code to errno, but that quickly became unworkable. 

Wince and NetWare use a function to set the per-
thread "errno" value. Although errno #defines  (like 
ERANGE) are not defined for Wince, they are defined 
for NetWare. Removing references to errno would 
artificially hobble the NetWare port.

These platforms also use a function to retrieve the 
current errno value.

The attached diff for pyport.h attempts to standardize 
the access method for errno (or it's work-alike) by 
providing SetErrno(), ClearErrno() and GetErrno() 
macros.

ClearErrno() is SetErrno(0)

I've found and changed all direct references to errno 
to use these macros. This patch must be submitted 
before the patches for other modules.

--

I see two negatives with this approach:

1. It will be a pain to think GetErrno() instead 
of "errno" when modifying/writing new code.

2. Extension modules will need access to pyport.h for 
the target platform.

In the worst case, directly referencing errno instead 
of using the macros will break only those platforms 
for which the macros do something different. That is, 
Wince and NetWare.

--

An alternative spelling/capitalization of these macros 
might make them more appealing. Feel free to make a 
suggestion.


--

It's probably incorrect for me to use SetErrno() as a 
function, such as

   SetErrno(1);

I think the semi-colon is not needed, but wasn't 
entirely certain. On better advice, I will fix these 
statements in the remaining source files if this patch 
is accepted.



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

>Comment By: Tim Peters (tim_one)
Date: 2002-01-19 12:52

Message:
Logged In: YES 
user_id=31435

All identifiers defined in pyport.h must begin with "Py_".  
pyport.h is (and must be) #include'd by extension modules, 
and we need the prefix to avoid stomping on their 
namespace, and to make clear (to them and to us) that the 
gimmicks are part of Python's portability layer.  A name 
like "SetErrno" is certain to conflict with some other 
package's attempt to worm around errno problems; Py_SetErrno
() is not.  Agree with Neal's final suggestion about 
dealing with  semicolons.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-19 12:28

Message:
Logged In: YES 
user_id=33168

Typically, the semi-colon problem is dealt with as in
Py_SET_ERANGE_IF_OVERFLOW.

So, 

#define SetErrno(X) do { SetLastError(X); } while (0)

I don't think (but can't remember if) there is any problem
for single statements like you have.  You could probably do:

#ifndef MS_WINCE
#define SetErrno(X) errno = (X)     /* note no ; */
#else
#define SetErrno(X) SetLastError(X) /* note no ; */
#endif


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470


From noreply@sourceforge.net  Sat Jan 19 21:47:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 19 Jan 2002 13:47:16 -0800
Subject: [Patches] [ python-Patches-505846 ] pyport.h, Wince and errno getter/setter
Message-ID: <E16S3KW-0001vi-00@usw-sf-web2.sourceforge.net>

Patches item #505846, was opened at 2002-01-19 12:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brad Clements (bkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyport.h, Wince and errno getter/setter

Initial Comment:
Most of the remaining Windows CE diffs are due to the 
lack of errno on Windows CE. There are other OS's that 
do not have errno (but they have a workalike method).

At first I had simply commented out all references in 
the code to errno, but that quickly became unworkable. 

Wince and NetWare use a function to set the per-
thread "errno" value. Although errno #defines  (like 
ERANGE) are not defined for Wince, they are defined 
for NetWare. Removing references to errno would 
artificially hobble the NetWare port.

These platforms also use a function to retrieve the 
current errno value.

The attached diff for pyport.h attempts to standardize 
the access method for errno (or it's work-alike) by 
providing SetErrno(), ClearErrno() and GetErrno() 
macros.

ClearErrno() is SetErrno(0)

I've found and changed all direct references to errno 
to use these macros. This patch must be submitted 
before the patches for other modules.

--

I see two negatives with this approach:

1. It will be a pain to think GetErrno() instead 
of "errno" when modifying/writing new code.

2. Extension modules will need access to pyport.h for 
the target platform.

In the worst case, directly referencing errno instead 
of using the macros will break only those platforms 
for which the macros do something different. That is, 
Wince and NetWare.

--

An alternative spelling/capitalization of these macros 
might make them more appealing. Feel free to make a 
suggestion.


--

It's probably incorrect for me to use SetErrno() as a 
function, such as

   SetErrno(1);

I think the semi-colon is not needed, but wasn't 
entirely certain. On better advice, I will fix these 
statements in the remaining source files if this patch 
is accepted.



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

>Comment By: Brad Clements (bkc)
Date: 2002-01-19 13:47

Message:
Logged In: YES 
user_id=4631

Here is an amended diff with the suggested changes. I've 
tested the semi-colon handling on EVT, it works as 
suggested.

--

Question: What is the prefered style, #ifdef xyz or #if 
defined(xyz) ?

I try to use #ifdef xyz, but sometimes there's multiple 
possibilities and #if defined(x) || defined(y) is needed. 
Is that okay?

--

Upcoming issue (hoping you address in your reply). There 
are many "goto finally" statements in various modules. 
Unfortunately EVT treats "finally" as a reserved word, even 
when compiling in non C++ mode.  Also, Metrowerks does the 
same.

I've changed all of these to "goto my_finally" as a quick 
work-around. I know "my_finally" sounds yucky, what's your 
recommendation for this? 

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

Comment By: Tim Peters (tim_one)
Date: 2002-01-19 12:52

Message:
Logged In: YES 
user_id=31435

All identifiers defined in pyport.h must begin with "Py_".  
pyport.h is (and must be) #include'd by extension modules, 
and we need the prefix to avoid stomping on their 
namespace, and to make clear (to them and to us) that the 
gimmicks are part of Python's portability layer.  A name 
like "SetErrno" is certain to conflict with some other 
package's attempt to worm around errno problems; Py_SetErrno
() is not.  Agree with Neal's final suggestion about 
dealing with  semicolons.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-19 12:28

Message:
Logged In: YES 
user_id=33168

Typically, the semi-colon problem is dealt with as in
Py_SET_ERANGE_IF_OVERFLOW.

So, 

#define SetErrno(X) do { SetLastError(X); } while (0)

I don't think (but can't remember if) there is any problem
for single statements like you have.  You could probably do:

#ifndef MS_WINCE
#define SetErrno(X) errno = (X)     /* note no ; */
#else
#define SetErrno(X) SetLastError(X) /* note no ; */
#endif


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470


From noreply@sourceforge.net  Sat Jan 19 22:07:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 19 Jan 2002 14:07:06 -0800
Subject: [Patches] [ python-Patches-504215 ] Remove PyThread_*_sema() APIs
Message-ID: <E16S3di-0007qp-00@usw-sf-web3.sourceforge.net>

Patches item #504215, was opened at 2002-01-15 20:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504215&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Remove PyThread_*_sema() APIs

Initial Comment:
This patch removes the unused PyThread_*_sema()
routines and the WAIT_SEMA and NOWAIT_SEMA constants.

Patch created against CVS.
Tested on Mandrake 7.1 with glibc 2.1.3.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-01-19 14:07

Message:
Logged In: YES 
user_id=3066

Checked in since there was no objection from python-dev.

Include/pythread.h 2.19
Python/thread_beos.h 2.9
Python/thread_cthread.h 2.17
Python/thread_foobar.h 2.13
Python/thread_lwp.h 2.16
Python/thread_nt.h 2.21
Python/thread_os2.h 2.13
Python/thread_pth.h 2.9
Python/thread_pthread.h 2.38
Python/thread_sgi.h 2.16
Python/thread_solaris.h 2.18


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504215&group_id=5470


From noreply@sourceforge.net  Sat Jan 19 22:57:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 19 Jan 2002 14:57:40 -0800
Subject: [Patches] [ python-Patches-505846 ] pyport.h, Wince and errno getter/setter
Message-ID: <E16S4Qe-0002kE-00@usw-sf-web2.sourceforge.net>

Patches item #505846, was opened at 2002-01-19 12:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brad Clements (bkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyport.h, Wince and errno getter/setter

Initial Comment:
Most of the remaining Windows CE diffs are due to the 
lack of errno on Windows CE. There are other OS's that 
do not have errno (but they have a workalike method).

At first I had simply commented out all references in 
the code to errno, but that quickly became unworkable. 

Wince and NetWare use a function to set the per-
thread "errno" value. Although errno #defines  (like 
ERANGE) are not defined for Wince, they are defined 
for NetWare. Removing references to errno would 
artificially hobble the NetWare port.

These platforms also use a function to retrieve the 
current errno value.

The attached diff for pyport.h attempts to standardize 
the access method for errno (or it's work-alike) by 
providing SetErrno(), ClearErrno() and GetErrno() 
macros.

ClearErrno() is SetErrno(0)

I've found and changed all direct references to errno 
to use these macros. This patch must be submitted 
before the patches for other modules.

--

I see two negatives with this approach:

1. It will be a pain to think GetErrno() instead 
of "errno" when modifying/writing new code.

2. Extension modules will need access to pyport.h for 
the target platform.

In the worst case, directly referencing errno instead 
of using the macros will break only those platforms 
for which the macros do something different. That is, 
Wince and NetWare.

--

An alternative spelling/capitalization of these macros 
might make them more appealing. Feel free to make a 
suggestion.


--

It's probably incorrect for me to use SetErrno() as a 
function, such as

   SetErrno(1);

I think the semi-colon is not needed, but wasn't 
entirely certain. On better advice, I will fix these 
statements in the remaining source files if this patch 
is accepted.



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-19 14:57

Message:
Logged In: YES 
user_id=33168

Need to change the // comment to /* */.  gcc accepts this
for C, but it's non-standard (at least it was, it may have
changed in C99).

You can have 1 Py_SET_ERANGE_IF_OVERFLOW for both platforms
if you do this:

#ifndef ERANGE
#define ERANGE 1
#endif

#define Py_SET_ERANGE_IF_OVERFLOW(X) \
    do { \
        if (Py_GetErrno() == 0 && ((X) == Py_HUGE_VAL || \
                                   (X) == -Py_HUGE_VAL))  \
             Py_SetErrno(ERANGE); \
    } while(0)
I'm not sure of the usefulness of Py_ClearErrno(), since
it's the same on all platforms.  If errno might be set to
something other than 0 in the future, it would be good to
make the change now.

I would suggest changing finally to cleanup.

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

Comment By: Brad Clements (bkc)
Date: 2002-01-19 13:47

Message:
Logged In: YES 
user_id=4631

Here is an amended diff with the suggested changes. I've 
tested the semi-colon handling on EVT, it works as 
suggested.

--

Question: What is the prefered style, #ifdef xyz or #if 
defined(xyz) ?

I try to use #ifdef xyz, but sometimes there's multiple 
possibilities and #if defined(x) || defined(y) is needed. 
Is that okay?

--

Upcoming issue (hoping you address in your reply). There 
are many "goto finally" statements in various modules. 
Unfortunately EVT treats "finally" as a reserved word, even 
when compiling in non C++ mode.  Also, Metrowerks does the 
same.

I've changed all of these to "goto my_finally" as a quick 
work-around. I know "my_finally" sounds yucky, what's your 
recommendation for this? 

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

Comment By: Tim Peters (tim_one)
Date: 2002-01-19 12:52

Message:
Logged In: YES 
user_id=31435

All identifiers defined in pyport.h must begin with "Py_".  
pyport.h is (and must be) #include'd by extension modules, 
and we need the prefix to avoid stomping on their 
namespace, and to make clear (to them and to us) that the 
gimmicks are part of Python's portability layer.  A name 
like "SetErrno" is certain to conflict with some other 
package's attempt to worm around errno problems; Py_SetErrno
() is not.  Agree with Neal's final suggestion about 
dealing with  semicolons.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-19 12:28

Message:
Logged In: YES 
user_id=33168

Typically, the semi-colon problem is dealt with as in
Py_SET_ERANGE_IF_OVERFLOW.

So, 

#define SetErrno(X) do { SetLastError(X); } while (0)

I don't think (but can't remember if) there is any problem
for single statements like you have.  You could probably do:

#ifndef MS_WINCE
#define SetErrno(X) errno = (X)     /* note no ; */
#else
#define SetErrno(X) SetLastError(X) /* note no ; */
#endif


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470


From Boris_Lipner <v2004@nm.ru>  Sun Jan 20 12:49:52 2002
From: Boris_Lipner <v2004@nm.ru> (Boris_Lipner)
Date: Sun, 20 Jan 2002 15:49:52 +0300
Subject: [Patches] cooperation
Message-ID: <8515280648.20020120154952@nm.ru>

        Dear Sirs,

 For some technical reasons we have partially lost our Data Bank of art galleries.
 Please, write the address of your website, so that we could continue our
 cooperation.
 Our site is http://www.gallery-a.ru/

 Best regards,
 Boris_Lipner                                 v2004@nm.ru



From noreply@sourceforge.net  Sun Jan 20 15:54:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 20 Jan 2002 07:54:37 -0800
Subject: [Patches] [ python-Patches-505846 ] pyport.h, Wince and errno getter/setter
Message-ID: <E16SKIn-00009A-00@usw-sf-web1.sourceforge.net>

Patches item #505846, was opened at 2002-01-19 12:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brad Clements (bkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyport.h, Wince and errno getter/setter

Initial Comment:
Most of the remaining Windows CE diffs are due to the 
lack of errno on Windows CE. There are other OS's that 
do not have errno (but they have a workalike method).

At first I had simply commented out all references in 
the code to errno, but that quickly became unworkable. 

Wince and NetWare use a function to set the per-
thread "errno" value. Although errno #defines  (like 
ERANGE) are not defined for Wince, they are defined 
for NetWare. Removing references to errno would 
artificially hobble the NetWare port.

These platforms also use a function to retrieve the 
current errno value.

The attached diff for pyport.h attempts to standardize 
the access method for errno (or it's work-alike) by 
providing SetErrno(), ClearErrno() and GetErrno() 
macros.

ClearErrno() is SetErrno(0)

I've found and changed all direct references to errno 
to use these macros. This patch must be submitted 
before the patches for other modules.

--

I see two negatives with this approach:

1. It will be a pain to think GetErrno() instead 
of "errno" when modifying/writing new code.

2. Extension modules will need access to pyport.h for 
the target platform.

In the worst case, directly referencing errno instead 
of using the macros will break only those platforms 
for which the macros do something different. That is, 
Wince and NetWare.

--

An alternative spelling/capitalization of these macros 
might make them more appealing. Feel free to make a 
suggestion.


--

It's probably incorrect for me to use SetErrno() as a 
function, such as

   SetErrno(1);

I think the semi-colon is not needed, but wasn't 
entirely certain. On better advice, I will fix these 
statements in the remaining source files if this patch 
is accepted.



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

>Comment By: Brad Clements (bkc)
Date: 2002-01-20 07:54

Message:
Logged In: YES 
user_id=4631

I can post a new diff for the // or would you be willing to 
just change the patch you have?

I cannot use the same macros for Py_SET_ERANGE_IF_OVERFLOW
(X) because Wince doesn't have ERANGE. You'll note the use 
of Py_SetErrno(1) which is frankly bogus. This is related 
to your comment on Py_ClearErrno()

Using (errno == 0) as meaning "no error" seems to me to be 
a python source "convention" forced on it by (mostly) 
floating point side effects. Because the math routines are 
indicating overflow errors through the side effect of 
setting errno (rather than returning an explicit NaN that 
works on all platforms), we must set errno = 0 before 
calling these math functions. 

I suppose it's possible that on some platform "clearing the 
last error value" wouldn't be done this way, but rather 
might be an explicit function call. Since I was going 
through the source looking for all errno's, I felt it was 
clearer to say Py_ClearErrno() rather than Py_SetErrno(0), 
even though in the end they do the same thing on currently 
supported platforms.

I'm easy, if you want to replace Py_ClearErrno() with 
Py_SetErrno(0) I can do that too.

--

Regarding goto targets.. is it likely that "cleanup" might 
also collide with local variables? would _cleanup or 
__cleanup work for you?




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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-19 14:57

Message:
Logged In: YES 
user_id=33168

Need to change the // comment to /* */.  gcc accepts this
for C, but it's non-standard (at least it was, it may have
changed in C99).

You can have 1 Py_SET_ERANGE_IF_OVERFLOW for both platforms
if you do this:

#ifndef ERANGE
#define ERANGE 1
#endif

#define Py_SET_ERANGE_IF_OVERFLOW(X) \
    do { \
        if (Py_GetErrno() == 0 && ((X) == Py_HUGE_VAL || \
                                   (X) == -Py_HUGE_VAL))  \
             Py_SetErrno(ERANGE); \
    } while(0)
I'm not sure of the usefulness of Py_ClearErrno(), since
it's the same on all platforms.  If errno might be set to
something other than 0 in the future, it would be good to
make the change now.

I would suggest changing finally to cleanup.

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

Comment By: Brad Clements (bkc)
Date: 2002-01-19 13:47

Message:
Logged In: YES 
user_id=4631

Here is an amended diff with the suggested changes. I've 
tested the semi-colon handling on EVT, it works as 
suggested.

--

Question: What is the prefered style, #ifdef xyz or #if 
defined(xyz) ?

I try to use #ifdef xyz, but sometimes there's multiple 
possibilities and #if defined(x) || defined(y) is needed. 
Is that okay?

--

Upcoming issue (hoping you address in your reply). There 
are many "goto finally" statements in various modules. 
Unfortunately EVT treats "finally" as a reserved word, even 
when compiling in non C++ mode.  Also, Metrowerks does the 
same.

I've changed all of these to "goto my_finally" as a quick 
work-around. I know "my_finally" sounds yucky, what's your 
recommendation for this? 

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

Comment By: Tim Peters (tim_one)
Date: 2002-01-19 12:52

Message:
Logged In: YES 
user_id=31435

All identifiers defined in pyport.h must begin with "Py_".  
pyport.h is (and must be) #include'd by extension modules, 
and we need the prefix to avoid stomping on their 
namespace, and to make clear (to them and to us) that the 
gimmicks are part of Python's portability layer.  A name 
like "SetErrno" is certain to conflict with some other 
package's attempt to worm around errno problems; Py_SetErrno
() is not.  Agree with Neal's final suggestion about 
dealing with  semicolons.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-19 12:28

Message:
Logged In: YES 
user_id=33168

Typically, the semi-colon problem is dealt with as in
Py_SET_ERANGE_IF_OVERFLOW.

So, 

#define SetErrno(X) do { SetLastError(X); } while (0)

I don't think (but can't remember if) there is any problem
for single statements like you have.  You could probably do:

#ifndef MS_WINCE
#define SetErrno(X) errno = (X)     /* note no ; */
#else
#define SetErrno(X) SetLastError(X) /* note no ; */
#endif


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470


From noreply@sourceforge.net  Sun Jan 20 19:21:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 20 Jan 2002 11:21:56 -0800
Subject: [Patches] [ python-Patches-505846 ] pyport.h, Wince and errno getter/setter
Message-ID: <E16SNXQ-0002g2-00@usw-sf-web1.sourceforge.net>

Patches item #505846, was opened at 2002-01-19 12:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brad Clements (bkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyport.h, Wince and errno getter/setter

Initial Comment:
Most of the remaining Windows CE diffs are due to the 
lack of errno on Windows CE. There are other OS's that 
do not have errno (but they have a workalike method).

At first I had simply commented out all references in 
the code to errno, but that quickly became unworkable. 

Wince and NetWare use a function to set the per-
thread "errno" value. Although errno #defines  (like 
ERANGE) are not defined for Wince, they are defined 
for NetWare. Removing references to errno would 
artificially hobble the NetWare port.

These platforms also use a function to retrieve the 
current errno value.

The attached diff for pyport.h attempts to standardize 
the access method for errno (or it's work-alike) by 
providing SetErrno(), ClearErrno() and GetErrno() 
macros.

ClearErrno() is SetErrno(0)

I've found and changed all direct references to errno 
to use these macros. This patch must be submitted 
before the patches for other modules.

--

I see two negatives with this approach:

1. It will be a pain to think GetErrno() instead 
of "errno" when modifying/writing new code.

2. Extension modules will need access to pyport.h for 
the target platform.

In the worst case, directly referencing errno instead 
of using the macros will break only those platforms 
for which the macros do something different. That is, 
Wince and NetWare.

--

An alternative spelling/capitalization of these macros 
might make them more appealing. Feel free to make a 
suggestion.


--

It's probably incorrect for me to use SetErrno() as a 
function, such as

   SetErrno(1);

I think the semi-colon is not needed, but wasn't 
entirely certain. On better advice, I will fix these 
statements in the remaining source files if this patch 
is accepted.



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

>Comment By: Tim Peters (tim_one)
Date: 2002-01-20 11:21

Message:
Logged In: YES 
user_id=31435

Brad, errno is required by ANSI C, which also defines the 
semantics of a 0 value.  Setting errno to 0, and taking 
errno==0 as meaning "no error", are 100% portable across 
platforms with a standard-conforming C implementation.  If 
this platform doesn't support standard C, I have to 
question whether the core should even try to cater to it:  
the changes needed make no sense to C programmers, so may 
become a maintenance nightmare.

I don't think putting a layer around errno is going to be 
hard to live with, provided that it merely tries to emulate 
standard behavior.  For that reason, setting errno to 0 is 
correct, but inventing a new ClearErrno concept is wrong 
(the latter makes no sense to anyone except its inventor 
<wink>).

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

Comment By: Brad Clements (bkc)
Date: 2002-01-20 07:54

Message:
Logged In: YES 
user_id=4631

I can post a new diff for the // or would you be willing to 
just change the patch you have?

I cannot use the same macros for Py_SET_ERANGE_IF_OVERFLOW
(X) because Wince doesn't have ERANGE. You'll note the use 
of Py_SetErrno(1) which is frankly bogus. This is related 
to your comment on Py_ClearErrno()

Using (errno == 0) as meaning "no error" seems to me to be 
a python source "convention" forced on it by (mostly) 
floating point side effects. Because the math routines are 
indicating overflow errors through the side effect of 
setting errno (rather than returning an explicit NaN that 
works on all platforms), we must set errno = 0 before 
calling these math functions. 

I suppose it's possible that on some platform "clearing the 
last error value" wouldn't be done this way, but rather 
might be an explicit function call. Since I was going 
through the source looking for all errno's, I felt it was 
clearer to say Py_ClearErrno() rather than Py_SetErrno(0), 
even though in the end they do the same thing on currently 
supported platforms.

I'm easy, if you want to replace Py_ClearErrno() with 
Py_SetErrno(0) I can do that too.

--

Regarding goto targets.. is it likely that "cleanup" might 
also collide with local variables? would _cleanup or 
__cleanup work for you?




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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-19 14:57

Message:
Logged In: YES 
user_id=33168

Need to change the // comment to /* */.  gcc accepts this
for C, but it's non-standard (at least it was, it may have
changed in C99).

You can have 1 Py_SET_ERANGE_IF_OVERFLOW for both platforms
if you do this:

#ifndef ERANGE
#define ERANGE 1
#endif

#define Py_SET_ERANGE_IF_OVERFLOW(X) \
    do { \
        if (Py_GetErrno() == 0 && ((X) == Py_HUGE_VAL || \
                                   (X) == -Py_HUGE_VAL))  \
             Py_SetErrno(ERANGE); \
    } while(0)
I'm not sure of the usefulness of Py_ClearErrno(), since
it's the same on all platforms.  If errno might be set to
something other than 0 in the future, it would be good to
make the change now.

I would suggest changing finally to cleanup.

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

Comment By: Brad Clements (bkc)
Date: 2002-01-19 13:47

Message:
Logged In: YES 
user_id=4631

Here is an amended diff with the suggested changes. I've 
tested the semi-colon handling on EVT, it works as 
suggested.

--

Question: What is the prefered style, #ifdef xyz or #if 
defined(xyz) ?

I try to use #ifdef xyz, but sometimes there's multiple 
possibilities and #if defined(x) || defined(y) is needed. 
Is that okay?

--

Upcoming issue (hoping you address in your reply). There 
are many "goto finally" statements in various modules. 
Unfortunately EVT treats "finally" as a reserved word, even 
when compiling in non C++ mode.  Also, Metrowerks does the 
same.

I've changed all of these to "goto my_finally" as a quick 
work-around. I know "my_finally" sounds yucky, what's your 
recommendation for this? 

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

Comment By: Tim Peters (tim_one)
Date: 2002-01-19 12:52

Message:
Logged In: YES 
user_id=31435

All identifiers defined in pyport.h must begin with "Py_".  
pyport.h is (and must be) #include'd by extension modules, 
and we need the prefix to avoid stomping on their 
namespace, and to make clear (to them and to us) that the 
gimmicks are part of Python's portability layer.  A name 
like "SetErrno" is certain to conflict with some other 
package's attempt to worm around errno problems; Py_SetErrno
() is not.  Agree with Neal's final suggestion about 
dealing with  semicolons.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-19 12:28

Message:
Logged In: YES 
user_id=33168

Typically, the semi-colon problem is dealt with as in
Py_SET_ERANGE_IF_OVERFLOW.

So, 

#define SetErrno(X) do { SetLastError(X); } while (0)

I don't think (but can't remember if) there is any problem
for single statements like you have.  You could probably do:

#ifndef MS_WINCE
#define SetErrno(X) errno = (X)     /* note no ; */
#else
#define SetErrno(X) SetLastError(X) /* note no ; */
#endif


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470


From noreply@sourceforge.net  Sun Jan 20 20:17:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 20 Jan 2002 12:17:48 -0800
Subject: [Patches] [ python-Patches-505846 ] pyport.h, Wince and errno getter/setter
Message-ID: <E16SOPU-0003Mm-00@usw-sf-web1.sourceforge.net>

Patches item #505846, was opened at 2002-01-19 12:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brad Clements (bkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyport.h, Wince and errno getter/setter

Initial Comment:
Most of the remaining Windows CE diffs are due to the 
lack of errno on Windows CE. There are other OS's that 
do not have errno (but they have a workalike method).

At first I had simply commented out all references in 
the code to errno, but that quickly became unworkable. 

Wince and NetWare use a function to set the per-
thread "errno" value. Although errno #defines  (like 
ERANGE) are not defined for Wince, they are defined 
for NetWare. Removing references to errno would 
artificially hobble the NetWare port.

These platforms also use a function to retrieve the 
current errno value.

The attached diff for pyport.h attempts to standardize 
the access method for errno (or it's work-alike) by 
providing SetErrno(), ClearErrno() and GetErrno() 
macros.

ClearErrno() is SetErrno(0)

I've found and changed all direct references to errno 
to use these macros. This patch must be submitted 
before the patches for other modules.

--

I see two negatives with this approach:

1. It will be a pain to think GetErrno() instead 
of "errno" when modifying/writing new code.

2. Extension modules will need access to pyport.h for 
the target platform.

In the worst case, directly referencing errno instead 
of using the macros will break only those platforms 
for which the macros do something different. That is, 
Wince and NetWare.

--

An alternative spelling/capitalization of these macros 
might make them more appealing. Feel free to make a 
suggestion.


--

It's probably incorrect for me to use SetErrno() as a 
function, such as

   SetErrno(1);

I think the semi-colon is not needed, but wasn't 
entirely certain. On better advice, I will fix these 
statements in the remaining source files if this patch 
is accepted.



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

>Comment By: Brad Clements (bkc)
Date: 2002-01-20 12:17

Message:
Logged In: YES 
user_id=4631

I've eliminated Py_ClearErrno() and updated all the source 
to use Py_SetErrno(0).  Attached is an updated diff for 
pyport.h



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

Comment By: Tim Peters (tim_one)
Date: 2002-01-20 11:21

Message:
Logged In: YES 
user_id=31435

Brad, errno is required by ANSI C, which also defines the 
semantics of a 0 value.  Setting errno to 0, and taking 
errno==0 as meaning "no error", are 100% portable across 
platforms with a standard-conforming C implementation.  If 
this platform doesn't support standard C, I have to 
question whether the core should even try to cater to it:  
the changes needed make no sense to C programmers, so may 
become a maintenance nightmare.

I don't think putting a layer around errno is going to be 
hard to live with, provided that it merely tries to emulate 
standard behavior.  For that reason, setting errno to 0 is 
correct, but inventing a new ClearErrno concept is wrong 
(the latter makes no sense to anyone except its inventor 
<wink>).

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

Comment By: Brad Clements (bkc)
Date: 2002-01-20 07:54

Message:
Logged In: YES 
user_id=4631

I can post a new diff for the // or would you be willing to 
just change the patch you have?

I cannot use the same macros for Py_SET_ERANGE_IF_OVERFLOW
(X) because Wince doesn't have ERANGE. You'll note the use 
of Py_SetErrno(1) which is frankly bogus. This is related 
to your comment on Py_ClearErrno()

Using (errno == 0) as meaning "no error" seems to me to be 
a python source "convention" forced on it by (mostly) 
floating point side effects. Because the math routines are 
indicating overflow errors through the side effect of 
setting errno (rather than returning an explicit NaN that 
works on all platforms), we must set errno = 0 before 
calling these math functions. 

I suppose it's possible that on some platform "clearing the 
last error value" wouldn't be done this way, but rather 
might be an explicit function call. Since I was going 
through the source looking for all errno's, I felt it was 
clearer to say Py_ClearErrno() rather than Py_SetErrno(0), 
even though in the end they do the same thing on currently 
supported platforms.

I'm easy, if you want to replace Py_ClearErrno() with 
Py_SetErrno(0) I can do that too.

--

Regarding goto targets.. is it likely that "cleanup" might 
also collide with local variables? would _cleanup or 
__cleanup work for you?




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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-19 14:57

Message:
Logged In: YES 
user_id=33168

Need to change the // comment to /* */.  gcc accepts this
for C, but it's non-standard (at least it was, it may have
changed in C99).

You can have 1 Py_SET_ERANGE_IF_OVERFLOW for both platforms
if you do this:

#ifndef ERANGE
#define ERANGE 1
#endif

#define Py_SET_ERANGE_IF_OVERFLOW(X) \
    do { \
        if (Py_GetErrno() == 0 && ((X) == Py_HUGE_VAL || \
                                   (X) == -Py_HUGE_VAL))  \
             Py_SetErrno(ERANGE); \
    } while(0)
I'm not sure of the usefulness of Py_ClearErrno(), since
it's the same on all platforms.  If errno might be set to
something other than 0 in the future, it would be good to
make the change now.

I would suggest changing finally to cleanup.

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

Comment By: Brad Clements (bkc)
Date: 2002-01-19 13:47

Message:
Logged In: YES 
user_id=4631

Here is an amended diff with the suggested changes. I've 
tested the semi-colon handling on EVT, it works as 
suggested.

--

Question: What is the prefered style, #ifdef xyz or #if 
defined(xyz) ?

I try to use #ifdef xyz, but sometimes there's multiple 
possibilities and #if defined(x) || defined(y) is needed. 
Is that okay?

--

Upcoming issue (hoping you address in your reply). There 
are many "goto finally" statements in various modules. 
Unfortunately EVT treats "finally" as a reserved word, even 
when compiling in non C++ mode.  Also, Metrowerks does the 
same.

I've changed all of these to "goto my_finally" as a quick 
work-around. I know "my_finally" sounds yucky, what's your 
recommendation for this? 

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

Comment By: Tim Peters (tim_one)
Date: 2002-01-19 12:52

Message:
Logged In: YES 
user_id=31435

All identifiers defined in pyport.h must begin with "Py_".  
pyport.h is (and must be) #include'd by extension modules, 
and we need the prefix to avoid stomping on their 
namespace, and to make clear (to them and to us) that the 
gimmicks are part of Python's portability layer.  A name 
like "SetErrno" is certain to conflict with some other 
package's attempt to worm around errno problems; Py_SetErrno
() is not.  Agree with Neal's final suggestion about 
dealing with  semicolons.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-19 12:28

Message:
Logged In: YES 
user_id=33168

Typically, the semi-colon problem is dealt with as in
Py_SET_ERANGE_IF_OVERFLOW.

So, 

#define SetErrno(X) do { SetLastError(X); } while (0)

I don't think (but can't remember if) there is any problem
for single statements like you have.  You could probably do:

#ifndef MS_WINCE
#define SetErrno(X) errno = (X)     /* note no ; */
#else
#define SetErrno(X) SetLastError(X) /* note no ; */
#endif


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470


From noreply@sourceforge.net  Mon Jan 21 01:12:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 20 Jan 2002 17:12:33 -0800
Subject: [Patches] [ python-Patches-503592 ] Add method readfile() to class ZipFile
Message-ID: <E16ST0j-00055K-00@usw-sf-web2.sourceforge.net>

Patches item #503592, was opened at 2002-01-14 15:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=503592&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Branko Cibej (brane)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add method readfile() to class ZipFile

Initial Comment:
The ZipFile class doesn't provide a method to read
bytes from the
archive directly to a disk-based file. That's
unfortunate, because
reading large files from a zip file using the read()
method will burn
about twice the file size amount of RAM. This patch
adds a readfile()
method that reads small chunks of the archived file and
writes them
directly to disk.


Changes to class ZipFile (src/Lib/zipfile.py):

- New attribute _chunk_size: readfile() and write() use
this to
  calculate the read/write buffer sizes.

- New method _readcheck: Like _writecheck, but used for
error checking
  before reading from the archive.

- Changes to read(): Factor out error checking and call
_readcheck().

- Changes to write(): Use self._chunk_size as the read
size instead
  of a hard-coded value.

- New method readfile().


Changes to the docs (src/Doc/lib/libzipfile.tex):

- Document ZipFile.readfile().


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

>Comment By: Branko Cibej (brane)
Date: 2002-01-20 17:12

Message:
Logged In: YES 
user_id=427248

Yes, that would make sense, for both reading and writing.
The exitsing methods could even be reimplemented on top of
such a file-like object.

And it would be nice to have a way to _replace_ the contents
of an entry in the zip file.

If only i had enough time for all that ... but since I don't,
and I needed a way to reduce my script's memory footprint
from 60 megs to 6, this patch is the result.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-16 03:44

Message:
Logged In: YES 
user_id=21627

I'd rather prefer a different solution: create a .open()
method on ZipFile opjects, which return file-like objects.
With that, you can shutils.copyfileobj to achive what you want.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=503592&group_id=5470


From noreply@sourceforge.net  Mon Jan 21 09:10:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 Jan 2002 01:10:37 -0800
Subject: [Patches] [ python-Patches-503592 ] Add method readfile() to class ZipFile
Message-ID: <E16SaTN-0002P3-00@usw-sf-web2.sourceforge.net>

Patches item #503592, was opened at 2002-01-14 15:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=503592&group_id=5470

Category: Library (Lib)
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Branko Cibej (brane)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add method readfile() to class ZipFile

Initial Comment:
The ZipFile class doesn't provide a method to read
bytes from the
archive directly to a disk-based file. That's
unfortunate, because
reading large files from a zip file using the read()
method will burn
about twice the file size amount of RAM. This patch
adds a readfile()
method that reads small chunks of the archived file and
writes them
directly to disk.


Changes to class ZipFile (src/Lib/zipfile.py):

- New attribute _chunk_size: readfile() and write() use
this to
  calculate the read/write buffer sizes.

- New method _readcheck: Like _writecheck, but used for
error checking
  before reading from the archive.

- Changes to read(): Factor out error checking and call
_readcheck().

- Changes to write(): Use self._chunk_size as the read
size instead
  of a hard-coded value.

- New method readfile().


Changes to the docs (src/Doc/lib/libzipfile.tex):

- Document ZipFile.readfile().


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-21 01:10

Message:
Logged In: YES 
user_id=21627

Ok, I'll reject this patch, then. If you ever find time for
this issue, please submit a new patch.

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

Comment By: Branko Cibej (brane)
Date: 2002-01-20 17:12

Message:
Logged In: YES 
user_id=427248

Yes, that would make sense, for both reading and writing.
The exitsing methods could even be reimplemented on top of
such a file-like object.

And it would be nice to have a way to _replace_ the contents
of an entry in the zip file.

If only i had enough time for all that ... but since I don't,
and I needed a way to reduce my script's memory footprint
from 60 megs to 6, this patch is the result.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-16 03:44

Message:
Logged In: YES 
user_id=21627

I'd rather prefer a different solution: create a .open()
method on ZipFile opjects, which return file-like objects.
With that, you can shutils.copyfileobj to achive what you want.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=503592&group_id=5470


From noreply@sourceforge.net  Mon Jan 21 10:45:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 Jan 2002 02:45:33 -0800
Subject: [Patches] [ python-Patches-458898 ] --python-build for install
Message-ID: <E16SbxF-0005O9-00@usw-sf-web1.sourceforge.net>

Patches item #458898, was opened at 2001-09-05 13:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458898&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
Assigned to: Michael Hudson (mwh)
Summary: --python-build for install

Initial Comment:
Sometimes, being able to install python tools without
having python installed is desirable. When building an
RPM package of python, for example, one may want to
build/install IDLE as well, including it in a
subpackage. Indeed, we're doing this with a couple of
python tools here at Conectiva. Unfortunately, we have
a egg-chicken problem when doing this. You need python
installed in your system before you install tools. This
limitation may be observed in the file
Lib/distutils/sysconfig.py. It looks for Makefile in
the final installation directory, for example.

This patch adds a new option to dist-utils' install
command: --python-build. When used, python will look
for these files in the python build directory specified
trough the option.



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

>Comment By: Michael Hudson (mwh)
Date: 2002-01-21 02:45

Message:
Logged In: YES 
user_id=6656

Ta.  Some random comments:
(1) it's not obvious from this page which of the two patches
attached is the newer.  This may be sf's fault, but...
(2) might it be better to make this a global distutils
option?  It seems a bit fragile at the moment -- we'd need
to change things if, say, build_ext started to depend on
python_build.
Would, say
$ python setup.py --python-build install
be better?

I dunno, I don't really understand how options chase around
distutils yet... 

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

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-01-18 16:02

Message:
Logged In: YES 
user_id=7887

Here is a new patch including your suggestions.

Thank you!!


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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 09:49

Message:
Logged In: YES 
user_id=6656

Hey!  This patch is less than six months old.  Virtually
fresh :|

Some comments:  are you sure you can get away with only
honouring --python-build in install?  I think build_scripts
needs it too (now, anyway, maybe not when you wrote the patch).

Also, the mod to install.finalize_options() is in the wrong
place wrt. the surrouding comments.  Can you fix this?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458898&group_id=5470


From noreply@sourceforge.net  Mon Jan 21 13:39:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 Jan 2002 05:39:03 -0800
Subject: [Patches] [ python-Patches-506436 ] GETCONST/GETNAME/GETNAMEV speedup
Message-ID: <E16Sef9-0003CQ-00@usw-sf-web3.sourceforge.net>

Patches item #506436, was opened at 2002-01-21 05:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=506436&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Tim Peters (tim_one)
Summary: GETCONST/GETNAME/GETNAMEV speedup

Initial Comment:
The attached patch redefines the GETCONST, GETNAME &
GETNAMEV 
macros to do the following:

  * access the code object's consts 
and names through
    local variables instead of the long chain from 
f

  * use access macros to index the tuples and get
    the C string 
names

The code appears correct, and I've had no trouble
with 
it.  It only provides the most trivial of
improvement on pystone 
(around 1% when I see
anything), but it's all those little things 
that
add up, right?

Skip


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=506436&group_id=5470


From noreply@sourceforge.net  Mon Jan 21 13:47:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 Jan 2002 05:47:38 -0800
Subject: [Patches] [ python-Patches-506436 ] GETCONST/GETNAME/GETNAMEV speedup
Message-ID: <E16SenS-0007mD-00@usw-sf-web1.sourceforge.net>

Patches item #506436, was opened at 2002-01-21 05:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=506436&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Tim Peters (tim_one)
Summary: GETCONST/GETNAME/GETNAMEV speedup

Initial Comment:
The attached patch redefines the GETCONST, GETNAME &
GETNAMEV 
macros to do the following:

  * access the code object's consts 
and names through
    local variables instead of the long chain from 
f

  * use access macros to index the tuples and get
    the C string 
names

The code appears correct, and I've had no trouble
with 
it.  It only provides the most trivial of
improvement on pystone 
(around 1% when I see
anything), but it's all those little things 
that
add up, right?

Skip


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

>Comment By: Skip Montanaro (montanaro)
Date: 2002-01-21 05:47

Message:
Logged In: YES 
user_id=44345

Whoops...  Make the "observed" speedup 0.1%...


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=506436&group_id=5470


From noreply@sourceforge.net  Mon Jan 21 21:52:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 Jan 2002 13:52:38 -0800
Subject: [Patches] [ python-Patches-496096 ] Mach-O MacPython IDE!
Message-ID: <E16SmMo-00043c-00@usw-sf-web2.sourceforge.net>

Patches item #496096, was opened at 2001-12-22 05:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496096&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Donovan Preston (dsposx)
Assigned to: Jack Jansen (jackjansen)
Summary: Mach-O MacPython IDE!

Initial Comment:
Here it is... the moment we've all been waiting for... 
the MacPython IDE running in a bundle under Unix 
Python!

It's a beautiful thing. Most everything works 
flawlessly. One major point though... it's always 
asking you to convert UNIX line endings to mac 
line endings! Heh.

p.s. Jack: I took the quick route and assumed 
paths passed to FSSpec_New were slash-
delimited. It works at least, and the ability to specify 
the delimiter can be added later. I wanted to get 
this in CVS ASAP.

Donovan

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

>Comment By: Jack Jansen (jackjansen)
Date: 2002-01-21 13:52

Message:
Logged In: YES 
user_id=45365

Donovan,
I can't apply your patches: something seems to have gone wrong with tabs and spaces.

I'll apply the most important ones manually (those in IDE, mainly) insofar as I didn't have a similar patch myself already.

If you could later try to regenerate your patch for the other files that would be great!

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496096&group_id=5470


From noreply@sourceforge.net  Mon Jan 21 22:33:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 Jan 2002 14:33:37 -0800
Subject: [Patches] [ python-Patches-496096 ] Mach-O MacPython IDE!
Message-ID: <E16Sn0T-00027N-00@usw-sf-web3.sourceforge.net>

Patches item #496096, was opened at 2001-12-22 05:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496096&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Donovan Preston (dsposx)
Assigned to: Jack Jansen (jackjansen)
Summary: Mach-O MacPython IDE!

Initial Comment:
Here it is... the moment we've all been waiting for... 
the MacPython IDE running in a bundle under Unix 
Python!

It's a beautiful thing. Most everything works 
flawlessly. One major point though... it's always 
asking you to convert UNIX line endings to mac 
line endings! Heh.

p.s. Jack: I took the quick route and assumed 
paths passed to FSSpec_New were slash-
delimited. It works at least, and the ability to specify 
the delimiter can be added later. I wanted to get 
this in CVS ASAP.

Donovan

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

>Comment By: Jack Jansen (jackjansen)
Date: 2002-01-21 14:33

Message:
Logged In: YES 
user_id=45365

Donovan,
I can't apply your patches: something seems to have gone wrong with tabs and spaces.

I'll apply the most important ones manually (those in IDE, mainly) insofar as I didn't have a similar patch myself already.

If you could later try to regenerate your patch for the other files that would be great!

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-01-21 13:52

Message:
Logged In: YES 
user_id=45365

Donovan,
I can't apply your patches: something seems to have gone wrong with tabs and spaces.

I'll apply the most important ones manually (those in IDE, mainly) insofar as I didn't have a similar patch myself already.

If you could later try to regenerate your patch for the other files that would be great!

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=496096&group_id=5470


From noreply@sourceforge.net  Tue Jan 22 01:05:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 Jan 2002 17:05:17 -0800
Subject: [Patches] [ python-Patches-503592 ] Add method readfile() to class ZipFile
Message-ID: <E16SpNF-0008Dk-00@usw-sf-web1.sourceforge.net>

Patches item #503592, was opened at 2002-01-14 15:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=503592&group_id=5470

Category: Library (Lib)
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Branko Cibej (brane)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add method readfile() to class ZipFile

Initial Comment:
The ZipFile class doesn't provide a method to read
bytes from the
archive directly to a disk-based file. That's
unfortunate, because
reading large files from a zip file using the read()
method will burn
about twice the file size amount of RAM. This patch
adds a readfile()
method that reads small chunks of the archived file and
writes them
directly to disk.


Changes to class ZipFile (src/Lib/zipfile.py):

- New attribute _chunk_size: readfile() and write() use
this to
  calculate the read/write buffer sizes.

- New method _readcheck: Like _writecheck, but used for
error checking
  before reading from the archive.

- Changes to read(): Factor out error checking and call
_readcheck().

- Changes to write(): Use self._chunk_size as the read
size instead
  of a hard-coded value.

- New method readfile().


Changes to the docs (src/Doc/lib/libzipfile.tex):

- Document ZipFile.readfile().


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

>Comment By: Branko Cibej (brane)
Date: 2002-01-21 17:05

Message:
Logged In: YES 
user_id=427248

O.K.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-21 01:10

Message:
Logged In: YES 
user_id=21627

Ok, I'll reject this patch, then. If you ever find time for
this issue, please submit a new patch.

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

Comment By: Branko Cibej (brane)
Date: 2002-01-20 17:12

Message:
Logged In: YES 
user_id=427248

Yes, that would make sense, for both reading and writing.
The exitsing methods could even be reimplemented on top of
such a file-like object.

And it would be nice to have a way to _replace_ the contents
of an entry in the zip file.

If only i had enough time for all that ... but since I don't,
and I needed a way to reduce my script's memory footprint
from 60 megs to 6, this patch is the result.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-16 03:44

Message:
Logged In: YES 
user_id=21627

I'd rather prefer a different solution: create a .open()
method on ZipFile opjects, which return file-like objects.
With that, you can shutils.copyfileobj to achive what you want.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=503592&group_id=5470


From noreply@sourceforge.net  Wed Jan 23 07:39:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 Jan 2002 23:39:53 -0800
Subject: [Patches] [ python-Patches-505464 ] fix (??) bug in `gc.get_referrers()'
Message-ID: <E16TI0f-0005rc-00@usw-sf-web1.sourceforge.net>

Patches item #505464, was opened at 2002-01-18 09:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505464&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko Ozoko (zooko)
>Assigned to: Martin v. Löwis (loewis)
Summary: fix (??) bug in `gc.get_referrers()'

Initial Comment:
This eliminates the symptoms of bug "[ #505453 ] bug in
gc.get_referrers()".

As documented in that bug report, I urge you to leave
the bug open until someone (me, if necessary) examines
the unexplained behavior.



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

Comment By: Zooko Ozoko (zooko)
Date: 2002-01-18 12:50

Message:
Logged In: YES 
user_id=52562

Whoops.  The unexplained behavior of the bug that I
described in the bug report "[ #505453 ] bug in
gc.get_referrers()" was in fact just my misinterpreting the
results.

I believe that this patch fixes that bug.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505464&group_id=5470


From noreply@sourceforge.net  Wed Jan 23 07:59:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 Jan 2002 23:59:08 -0800
Subject: [Patches] [ python-Patches-500136 ] Update ext build documentation
Message-ID: <E16TIJI-0001MW-00@usw-sf-web3.sourceforge.net>

Patches item #500136, was opened at 2002-01-06 05:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500136&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Update ext build documentation

Initial Comment:
The attached file documents how extensions are build
using distutils. It is intended to replace atleast 
unix.tex, and possible also windows.tex.

Fred, if this is ok, I would like to check it in as
ext/building.tex, and remove ext/unix.tex. I would then
add a comment on top of windows.tex that the build
procedure using distutils should work out of the box on
Windows as well.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-22 23:59

Message:
Logged In: YES 
user_id=21627

This fixes bugs #497695, #500115, #506545, 

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500136&group_id=5470


From noreply@sourceforge.net  Wed Jan 23 08:34:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 23 Jan 2002 00:34:33 -0800
Subject: [Patches] [ python-Patches-500136 ] Update ext build documentation
Message-ID: <E16TIrZ-0006ZI-00@usw-sf-web1.sourceforge.net>

Patches item #500136, was opened at 2002-01-06 05:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500136&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Update ext build documentation

Initial Comment:
The attached file documents how extensions are build
using distutils. It is intended to replace atleast 
unix.tex, and possible also windows.tex.

Fred, if this is ok, I would like to check it in as
ext/building.tex, and remove ext/unix.tex. I would then
add a comment on top of windows.tex that the build
procedure using distutils should work out of the box on
Windows as well.

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

>Comment By: Skip Montanaro (montanaro)
Date: 2002-01-23 00:34

Message:
Logged In: YES 
user_id=44345

This looks good.  I had written a short replacement file
called 
build.tex and was going to submit it this morning,
but yours looks 
better.  Presuming Distutils gets rid of
the need for Windows-specific 
build solutions, I agree both
unix.tex and windows.tex should be 
replaced.

One phrase didn't make sense to me.  Near the top it says

  
(known as related to Makefile.pre.in, and Setup files)

I don't know 
what that means.  I would just zap any
reference to the old build 
method.

Skip



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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-22 23:59

Message:
Logged In: YES 
user_id=21627

This fixes bugs #497695, #500115, #506545, 

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500136&group_id=5470


From noreply@sourceforge.net  Thu Jan 24 17:04:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 24 Jan 2002 09:04:45 -0800
Subject: [Patches] [ python-Patches-508038 ] can't say "char digit": digit is a type!
Message-ID: <E16TnIr-0006Kr-00@usw-sf-web3.sourceforge.net>

Patches item #508038, was opened at 2002-01-24 09:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=508038&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russ Cox (rsc)
Assigned to: Nobody/Anonymous (nobody)
Summary: can't say "char digit": digit is a type!

Initial Comment:
digit is typedefed in longintrepr.h, but longobject.c
contains a declaration "char digit", which, due to the
typedef, is not legal.

patch changes digit to cdigit.



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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=508038&group_id=5470


From noreply@sourceforge.net  Fri Jan 25 18:05:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 25 Jan 2002 10:05:23 -0800
Subject: [Patches] [ python-Patches-500002 ] Fix for  #221791 (bad \x escape)
Message-ID: <E16UAj5-0005BG-00@usw-sf-web1.sourceforge.net>

Patches item #500002, was opened at 2002-01-05 16:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500002&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Fix for  #221791 (bad \x escape)

Initial Comment:
This patch adds file and line output if a bad \x escape
was found in the source. It does so with the following
modifications:

- PyErr_Display now recognizes syntax errors not by
their class, but by an attribute print_file_and_line
- this attribute is set for all SyntaxError instances
- PyErr_SyntaxLocation is enhanced to set all attributes
expected for a syntax error, even if the current
exception has a different class.
- compile.c now invokes PyErr_SyntaxLocation for all
non-syntax exceptions also, mostly through com_error.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500002&group_id=5470


From aazmace@aazbooks.com  Sat Jan 26 02:03:36 2002
From: aazmace@aazbooks.com (AaZbooks.com)
Date: Sat, 26 Jan 2002 03:03:36 +0100
Subject: [Patches] Nouvelles acquisitions / New online
Message-ID: <200201260203.DAA16014@www.olm.fr>


Chers bibliophiles,

Cette semaine nous vous proposons nos nouvelles acquisitions (plus de 500). Vous y trouverez par exemple:

SAINTE BEUVE C.A.
MADAME DESBORDES VALMORE SA VIE ET SA CORRESPONDANCE
Edition originale (rare). Ouvrage contenant un catalogue de Michl Lévy, libraire éditeur, de 36 p.Broché.IN8. LEVY Paris 1870 
Réf.: 18337 (107,00 €)

ou bien encore:

FALLET RENE
BANLIEUE SUD EST
Roman. Edition originale (rare). DOMAT Paris 1947
Réf.: 18313 (45,00 €)

En vous souhaitant bonne lecture

Toute l'équipe de AaZbooks.com

-------------------------------------------------------
Dear bibliophiles,

This week new online 500 books, for example:

SAINTE BEUVE C.A.
MADAME DESBORDES VALMORE SA VIE ET SA CORRESPONDANCE
Edition originale (rare). Ouvrage contenant un catalogue de Michl Lévy, libraire éditeur, de 36 p.Broché.IN8. LEVY Paris 1870 
Réf.: 18337 (107,00 €)

FALLET RENE
BANLIEUE SUD EST
Roman. Edition originale (rare). DOMAT Paris 1947
Réf.: 18313 (45,00 €)

Regards

AaZbooks' Team

 ----------------------------------------------------------
AaZbooks.com - BP N°1 - La grande Bruyère - F72320 St-Maixent
Tel.: +33 (0)2 43 71 00 70  - Fax: +33 (0)2 43 71 29 16 
http://www.aazbooks.com 
 ----------------------------------------------------------
Pour vous désinscrire cliquez ci-dessous 
http://www.aazbooks.com\lnews\desinscription.php


From noreply@sourceforge.net  Sat Jan 26 20:13:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 26 Jan 2002 12:13:58 -0800
Subject: [Patches] [ python-Patches-505464 ] fix (??) bug in `gc.get_referrers()'
Message-ID: <E16UZD4-0006Sf-00@usw-sf-web1.sourceforge.net>

Patches item #505464, was opened at 2002-01-18 09:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505464&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Zooko Ozoko (zooko)
Assigned to: Martin v. Löwis (loewis)
Summary: fix (??) bug in `gc.get_referrers()'

Initial Comment:
This eliminates the symptoms of bug "[ #505453 ] bug in
gc.get_referrers()".

As documented in that bug report, I urge you to leave
the bug open until someone (me, if necessary) examines
the unexplained behavior.



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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-26 12:13

Message:
Logged In: YES 
user_id=21627

Rejecting this patch, accepting the one in #505453.

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

Comment By: Zooko Ozoko (zooko)
Date: 2002-01-18 12:50

Message:
Logged In: YES 
user_id=52562

Whoops.  The unexplained behavior of the bug that I
described in the bug report "[ #505453 ] bug in
gc.get_referrers()" was in fact just my misinterpreting the
results.

I believe that this patch fixes that bug.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505464&group_id=5470


From noreply@sourceforge.net  Sun Jan 27 05:33:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 26 Jan 2002 21:33:51 -0800
Subject: [Patches] [ python-Patches-435381 ] Distutils patches for OS/2+EMX support
Message-ID: <E16Uhwt-0001pn-00@usw-sf-web2.sourceforge.net>

Patches item #435381, was opened at 2001-06-22 01:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435381&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Distutils patches for OS/2+EMX support

Initial Comment:
The attached patch file is against the code released
with Python 2.1.

The changes are included in the binary installation
package of the OS/2+EMX port of Python 2.1 I released
on June 17, 2001.

With these changes, I have successfully built and
installed the  Numeric 20.0.0 extention, and created a
bdist_dumb distribution package of it. The installed
extention tests successfully using the supplied test
routines.

Particular items of note:-
- OS/2 limits DLLs to 8.3 filenames :-( :-(
- ld is not used to link, instead gcc is used with the
-Zomf option
  which invokes the LINK386 linker native to OS/2
- I haven't made any attempt to merge cloned code back
into the 
  parent code where it would make sense, which I think
is in a few     places.

Feedback appreciated.

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

>Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-01-26 21:33

Message:
Logged In: YES 
user_id=250749

The updated patch against post-2.2 CVS has had some minor cleanups, compared to the earlier versions.

emxccompiler is still standalone, on the basis that it works and is independent of any changes that might happen in the 
Cygwin/MinGW support, given that EMX is not changing much (and not likely to).

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

Comment By: Rene Liebscher (rliebscher)
Date: 2001-08-29 01:39

Message:
Logged In: YES 
user_id=28463

Would it be possible to subclass cygwinccomplier 
(as mingwcompiler does?)

Or maybe create a better class structure like this

           GCCCompiler
         /             \
        /               \
 CygwinCCompiler    EMXCCompiler
      /
     /
MinGWCCompiler

GCCCompiler would never be used directly by anyone,
it only collects all common code.
The other class would only configure the 
GCCCompiler class in their __init__ methods.
(And maybe override some [small] methods if really
necessary.)

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2001-08-12 04:01

Message:
Logged In: YES 
user_id=250749

The only real change in this updated patch is the compiler optimisation switches in emxccompiler.py.

No attempted merging of changes.  Suggestions/advice in this regard sought.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-03 21:38

Message:
Logged In: YES 
user_id=3066

The third item in the list of issues at the end of the
initial comment indicates that the patch isn't ready for
inclusion.  Assigning to Greg Ward for review.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435381&group_id=5470


From noreply@sourceforge.net  Sun Jan 27 05:42:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 26 Jan 2002 21:42:13 -0800
Subject: [Patches] [ python-Patches-450265 ] OS/2 + EMX port - PC directory files
Message-ID: <E16Ui4z-0001vm-00@usw-sf-web2.sourceforge.net>

Patches item #450265, was opened at 2001-08-12 04:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450265&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: OS/2 + EMX port - PC directory files

Initial Comment:
The attached patch contains all the changes to the PC directory in the source tree between Python 2.1.1 and the 
010812 release of the OS/2+EMX port.  This comprises changes to PC/getpathp.c and a new subdirectory, 
PC/os2emx, which contains the Makefile, config.[ch], dlfcn.[ch], dllentry.c, python DLL .DEF file and a copy of the 
port's README.os2emx.

At the moment, building dynamic modules is still handled by the supplied Makefile, rather than a DistUtils setup.py 
script.

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

>Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-01-26 21:42

Message:
Logged In: YES 
user_id=250749

This updated patch against post-2.2 CVS adds a PC/os2emx directory, which contains all the build related files for the EMX 
port.  No changes are made to any of the other files in the PC directory.

The optional extensions that I support in the binary package are disabled by default in the makefile, as most of the 
dependencies need rebuilding to match the build environment of the Python port (typically enabling multithreading support).

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-03 02:45

Message:
Logged In: YES 
user_id=21627

If you continue to organize the patches in the same way,
just updating the existing report should be fine. If it is
more convenient for you, creating a new report is fine, as well.

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-01-02 15:20

Message:
Logged In: YES 
user_id=250749

I am preparing updated patches against CVS for this and the 
other EMX related patches, and will upload in the next few 
days.

Specifically for this patch, the updated version will just 
add a PC/os2emx subdirectory, and touch no other files in 
the PC directory (as the patch currently attached does).

Would it be better to reject the 4 currently outstanding 
patches and submit new ones for this, or just update the 
current ones?

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-01-02 15:19

Message:
Logged In: YES 
user_id=250749

I am preparing updated patches against CVS for this and the 
other EMX related patches, and will upload in the next few 
days.

Specifically for this patch, the updated version will just 
add a PC/os2emx subdirectory, and touch no other files in 
the PC directory (as the patch currently attached does).

Would it be better to reject the 4 currently outstanding 
patches and submit new ones for this, or just update the 
current ones?

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-28 14:47

Message:
Logged In: YES 
user_id=21627

Andrew, are you still interested in updating this patch?
Otherwise, I recommend to reject it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-10-01 15:41

Message:
Logged In: YES 
user_id=21627

What kind of action would you like to see on this code? In 
the areas where it changes existing code, there are some 
questionable chunks, which I would not like to see in 
Python:
- removal of comments
- change of control logic without giving a rationale. E.g. 
there was an explicit comment
/* If we have no values, we dont need a ';' */
Your patch changes this to give a ; in all cases. Why?
Why is the addition of a terminating null in wprogpath 
removed?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-12 07:45

Message:
Logged In: YES 
user_id=6380

Andrew, your patch attachment didn't work. Please try again,
making sure you check the "file upload checkbox".

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450265&group_id=5470


From noreply@sourceforge.net  Sun Jan 27 05:56:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 26 Jan 2002 21:56:23 -0800
Subject: [Patches] [ python-Patches-450266 ] OS/2 + EMX port - library changes
Message-ID: <E16UiIh-0004oi-00@usw-sf-web1.sourceforge.net>

Patches item #450266, was opened at 2001-08-12 04:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450266&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: OS/2 + EMX port - library changes

Initial Comment:
The attached patch contains the changes to the Lib directory in the sourc tree between Python 2.1.1 and the 
010812 release of the OS/2+EMX port.

It also includes an additional directory - Etc - which is home to a couple of example passwd/group files.  This 
directory can be dropped or relocated as appropriate.

An additional subdirectory of Lib is added - plat-os2emx.

The included os2path.py should probably be refactored into ntpath.py - suggestions/advice on this appreciated.

A couple of small changes to Lib/test - test_fcntl.py and test_longexp.py - to handle OS/2+EMX specific issues.

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

>Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-01-26 21:56

Message:
Logged In: YES 
user_id=250749

The 3 patches submitted (Lib/, Lib/plat-os2emx/, Lib/test/) are against CVS of 27Jan02.

The Lib patch implements the approach with os2emxpath.py discussed on python-dev. It also touches popen2.py to 
properly support the Win32 like popen[234]() support added to posixmodule.c.

I'm not sure whether several of the files in plat-os2emx (IN.py, SOCKET.py) are still needed, but they don't appear to don 
any harm.

The changes in the test suite are to cope with EMX platform issues:
- unless you have lots of real memory, test_longexp is likely to take the system down (malloc() behaviour issue)
- EMX's fcntl is only a partial implementation

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450266&group_id=5470


From noreply@sourceforge.net  Sun Jan 27 06:19:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 26 Jan 2002 22:19:36 -0800
Subject: [Patches] [ python-Patches-450267 ] OS/2+EMX port - changes to Python core
Message-ID: <E16UifA-00054R-00@usw-sf-web1.sourceforge.net>

Patches item #450267, was opened at 2001-08-12 04:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450267&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Nobody/Anonymous (nobody)
Summary: OS/2+EMX port - changes to Python core

Initial Comment:
The attached patch incorporates the changes to the source tree between Python 2.1.1 and the 010812 release 
of the OS/2+EMX port.

It includes changes to files in Include/, Modules/, Objects/ and Python/.

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

>Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-01-26 22:19

Message:
Logged In: YES 
user_id=250749

I have split the original approach into patches for each of the Include, Modules, Objects and Python directories.

Of particular note:
- the patches to import.c are general to both VACPP and EMX ports, and have been trialled by Michael Muller with 
satisfactory results.
- Modules/unicodedata.c has a name clash between its internally defined _getname() and an EMX routine of the same 
name defined in <stdlib.h>.  Is the solution in the patch acceptable?
- both Objects/stringobject.c and Objects/unicodeobject.c have changes to deal with EMX's runtime not producing a desired 
"0X" prefix in response to a "%X" format specifier (it produces "0x" instead).

The patched source tree has been built and regression tested on both EMX and FreeBSD 4.4, with no unexpected results.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-10-01 15:59

Message:
Logged In: YES 
user_id=21627

Please review this patch carefully again, asking in each 
case whether this chunk *really* belongs to this patch. Do 
so by asking "is it specific to the port of Python to 
os2emx?" There are some changes that are desirable, but 
are unrelated (like the whitespace changes in 
PyThread_down_sema). Please submit those in a separate 
patch. There are also changes that don't belong here at 
all, like the inclusion of a Modules/Setup.

If you are revising this patch, you may also split it into 
a part that is absolutely necessary, and a part that is 
nice-to-have. E.g. the termios changes are probably 
system-specific, but I guess the port would work well 
without them.

Without going in small steps, it seems that we won't move 
at all. You may consider making use of your checkin 
permissions for uncritical operations. If you need help in 
CVS operations, please let me know.


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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2001-08-13 06:21

Message:
Logged In: YES 
user_id=250749

Thanks for the feedback.  At this stage of the game, I'd prefer to work with a "supervisor" rather than take on CVS commit 
privs, though I realise that "supervisors" are a scarce resource.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-12 07:53

Message:
Logged In: YES 
user_id=6380

Hi Andrew,

Thanks for the patches.

There's a lot of code (here and in the two previous
patches). I'm going to see if we can give you CVS commit
permission so you can apply the changes yourself.

Note that commit permission (if you get it) doesn't mean
that the patch is automatically approved -- I've seen some
changes in your diffs that look questionable. You probably
know which ones. :-)

In general, the guidelines are that you can make changes
freely (a) in code you own because it's in a file or
directory that's specific to your port; (b) in code specific
to your port that's inside #ifdefs for your port (this
includes adding); (c) to fix an *obvious* small typo or
buglet that bothers your compiler (example: if your compiler
warns about an unused variable, feel free to delete it, as
long as the unusedness isn't dependent on an #ifdef).

For other changes we all appreciate it if you discuss them
on python-dev or on the SF patch manager first.

Oh, and if you ever check something in that breaks the build
on another platform or causes the test suite to fail, people
will demand very quick remedies or the checkin will be
reversed. :-)

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450267&group_id=5470


From offers@f1trading.com  Mon Jan 28 07:40:10 2002
From: offers@f1trading.com (offers@f1trading.com)
Date: Mon, 28 Jan 2002 02:40:10 -0500
Subject: [Patches] Trade for $4.95 per Trade
Message-ID: <E16V5Sr-0004Ps-00@mail.python.org>

<html>
<head>
<title>offer</title>
<meta http-equiv="Content-Type" content="text/html;">
<meta name="description" content="FW4 DW4 HTML">
<!-- Fireworks 4.0  Dreamweaver 4.0 target.  Created Sun Jan 27 22:49:20 GMT-0500 (Eastern Standard Time) 2002-->
</head>
<body bgcolor="#ffffff">
<!-------------------------- BEGIN COPYING THE HTML HERE ---------------------------->
<font size="1"><hr noshade>
If You feel you are receiving this e-mail in error
or If you prefer not to receive future offer 
messages from us,<BR> please reply to this message with the word remove in the subject line.<hr noshade></font><br><br>
<img name="offer" src="http://www.f1trading.com/images/offer.gif" width="476" height="600" border="0" usemap="#m_offer"><!-- fwtable fwsrc="Untitled" fwbase="offer" fwstyle="Dreamweaver" fwdocid = "742308039" fwnested="0" -->
<map name="m_offer">
<area shape="rect" coords="44,310,201,346" href="http://www.f1trading.com/access.htm" >
</map>
<!--------------------------- STOP COPYING THE HTML HERE --------------------------->
</body>
</html>


From noreply@sourceforge.net  Mon Jan 28 23:19:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 28 Jan 2002 15:19:27 -0800
Subject: [Patches] [ python-Patches-505846 ] pyport.h, Wince and errno getter/setter
Message-ID: <E16VL3f-0004dL-00@usw-sf-web3.sourceforge.net>

Patches item #505846, was opened at 2002-01-19 12:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brad Clements (bkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyport.h, Wince and errno getter/setter

Initial Comment:
Most of the remaining Windows CE diffs are due to the 
lack of errno on Windows CE. There are other OS's that 
do not have errno (but they have a workalike method).

At first I had simply commented out all references in 
the code to errno, but that quickly became unworkable. 

Wince and NetWare use a function to set the per-
thread "errno" value. Although errno #defines  (like 
ERANGE) are not defined for Wince, they are defined 
for NetWare. Removing references to errno would 
artificially hobble the NetWare port.

These platforms also use a function to retrieve the 
current errno value.

The attached diff for pyport.h attempts to standardize 
the access method for errno (or it's work-alike) by 
providing SetErrno(), ClearErrno() and GetErrno() 
macros.

ClearErrno() is SetErrno(0)

I've found and changed all direct references to errno 
to use these macros. This patch must be submitted 
before the patches for other modules.

--

I see two negatives with this approach:

1. It will be a pain to think GetErrno() instead 
of "errno" when modifying/writing new code.

2. Extension modules will need access to pyport.h for 
the target platform.

In the worst case, directly referencing errno instead 
of using the macros will break only those platforms 
for which the macros do something different. That is, 
Wince and NetWare.

--

An alternative spelling/capitalization of these macros 
might make them more appealing. Feel free to make a 
suggestion.


--

It's probably incorrect for me to use SetErrno() as a 
function, such as

   SetErrno(1);

I think the semi-colon is not needed, but wasn't 
entirely certain. On better advice, I will fix these 
statements in the remaining source files if this patch 
is accepted.



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

>Comment By: Brad Clements (bkc)
Date: 2002-01-28 15:19

Message:
Logged In: YES 
user_id=4631

Hi folks, just wondering if this patch is going to be 
rejected, or if you're all too busy and I have to be more 
patient ;-)

I have a passle of Python-CE folks waiting on me to finish 
checking in patches. This is the worst one, I promise!

Let me know what you want me to do, when you get a chance. 
Thanks


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

Comment By: Brad Clements (bkc)
Date: 2002-01-20 12:17

Message:
Logged In: YES 
user_id=4631

I've eliminated Py_ClearErrno() and updated all the source 
to use Py_SetErrno(0).  Attached is an updated diff for 
pyport.h



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

Comment By: Tim Peters (tim_one)
Date: 2002-01-20 11:21

Message:
Logged In: YES 
user_id=31435

Brad, errno is required by ANSI C, which also defines the 
semantics of a 0 value.  Setting errno to 0, and taking 
errno==0 as meaning "no error", are 100% portable across 
platforms with a standard-conforming C implementation.  If 
this platform doesn't support standard C, I have to 
question whether the core should even try to cater to it:  
the changes needed make no sense to C programmers, so may 
become a maintenance nightmare.

I don't think putting a layer around errno is going to be 
hard to live with, provided that it merely tries to emulate 
standard behavior.  For that reason, setting errno to 0 is 
correct, but inventing a new ClearErrno concept is wrong 
(the latter makes no sense to anyone except its inventor 
<wink>).

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

Comment By: Brad Clements (bkc)
Date: 2002-01-20 07:54

Message:
Logged In: YES 
user_id=4631

I can post a new diff for the // or would you be willing to 
just change the patch you have?

I cannot use the same macros for Py_SET_ERANGE_IF_OVERFLOW
(X) because Wince doesn't have ERANGE. You'll note the use 
of Py_SetErrno(1) which is frankly bogus. This is related 
to your comment on Py_ClearErrno()

Using (errno == 0) as meaning "no error" seems to me to be 
a python source "convention" forced on it by (mostly) 
floating point side effects. Because the math routines are 
indicating overflow errors through the side effect of 
setting errno (rather than returning an explicit NaN that 
works on all platforms), we must set errno = 0 before 
calling these math functions. 

I suppose it's possible that on some platform "clearing the 
last error value" wouldn't be done this way, but rather 
might be an explicit function call. Since I was going 
through the source looking for all errno's, I felt it was 
clearer to say Py_ClearErrno() rather than Py_SetErrno(0), 
even though in the end they do the same thing on currently 
supported platforms.

I'm easy, if you want to replace Py_ClearErrno() with 
Py_SetErrno(0) I can do that too.

--

Regarding goto targets.. is it likely that "cleanup" might 
also collide with local variables? would _cleanup or 
__cleanup work for you?




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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-19 14:57

Message:
Logged In: YES 
user_id=33168

Need to change the // comment to /* */.  gcc accepts this
for C, but it's non-standard (at least it was, it may have
changed in C99).

You can have 1 Py_SET_ERANGE_IF_OVERFLOW for both platforms
if you do this:

#ifndef ERANGE
#define ERANGE 1
#endif

#define Py_SET_ERANGE_IF_OVERFLOW(X) \
    do { \
        if (Py_GetErrno() == 0 && ((X) == Py_HUGE_VAL || \
                                   (X) == -Py_HUGE_VAL))  \
             Py_SetErrno(ERANGE); \
    } while(0)
I'm not sure of the usefulness of Py_ClearErrno(), since
it's the same on all platforms.  If errno might be set to
something other than 0 in the future, it would be good to
make the change now.

I would suggest changing finally to cleanup.

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

Comment By: Brad Clements (bkc)
Date: 2002-01-19 13:47

Message:
Logged In: YES 
user_id=4631

Here is an amended diff with the suggested changes. I've 
tested the semi-colon handling on EVT, it works as 
suggested.

--

Question: What is the prefered style, #ifdef xyz or #if 
defined(xyz) ?

I try to use #ifdef xyz, but sometimes there's multiple 
possibilities and #if defined(x) || defined(y) is needed. 
Is that okay?

--

Upcoming issue (hoping you address in your reply). There 
are many "goto finally" statements in various modules. 
Unfortunately EVT treats "finally" as a reserved word, even 
when compiling in non C++ mode.  Also, Metrowerks does the 
same.

I've changed all of these to "goto my_finally" as a quick 
work-around. I know "my_finally" sounds yucky, what's your 
recommendation for this? 

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

Comment By: Tim Peters (tim_one)
Date: 2002-01-19 12:52

Message:
Logged In: YES 
user_id=31435

All identifiers defined in pyport.h must begin with "Py_".  
pyport.h is (and must be) #include'd by extension modules, 
and we need the prefix to avoid stomping on their 
namespace, and to make clear (to them and to us) that the 
gimmicks are part of Python's portability layer.  A name 
like "SetErrno" is certain to conflict with some other 
package's attempt to worm around errno problems; Py_SetErrno
() is not.  Agree with Neal's final suggestion about 
dealing with  semicolons.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-19 12:28

Message:
Logged In: YES 
user_id=33168

Typically, the semi-colon problem is dealt with as in
Py_SET_ERANGE_IF_OVERFLOW.

So, 

#define SetErrno(X) do { SetLastError(X); } while (0)

I don't think (but can't remember if) there is any problem
for single statements like you have.  You could probably do:

#ifndef MS_WINCE
#define SetErrno(X) errno = (X)     /* note no ; */
#else
#define SetErrno(X) SetLastError(X) /* note no ; */
#endif


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470


From noreply@sourceforge.net  Mon Jan 28 23:39:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 28 Jan 2002 15:39:33 -0800
Subject: [Patches] [ python-Patches-505846 ] pyport.h, Wince and errno getter/setter
Message-ID: <E16VLN7-0004tU-00@usw-sf-web3.sourceforge.net>

Patches item #505846, was opened at 2002-01-19 12:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brad Clements (bkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyport.h, Wince and errno getter/setter

Initial Comment:
Most of the remaining Windows CE diffs are due to the 
lack of errno on Windows CE. There are other OS's that 
do not have errno (but they have a workalike method).

At first I had simply commented out all references in 
the code to errno, but that quickly became unworkable. 

Wince and NetWare use a function to set the per-
thread "errno" value. Although errno #defines  (like 
ERANGE) are not defined for Wince, they are defined 
for NetWare. Removing references to errno would 
artificially hobble the NetWare port.

These platforms also use a function to retrieve the 
current errno value.

The attached diff for pyport.h attempts to standardize 
the access method for errno (or it's work-alike) by 
providing SetErrno(), ClearErrno() and GetErrno() 
macros.

ClearErrno() is SetErrno(0)

I've found and changed all direct references to errno 
to use these macros. This patch must be submitted 
before the patches for other modules.

--

I see two negatives with this approach:

1. It will be a pain to think GetErrno() instead 
of "errno" when modifying/writing new code.

2. Extension modules will need access to pyport.h for 
the target platform.

In the worst case, directly referencing errno instead 
of using the macros will break only those platforms 
for which the macros do something different. That is, 
Wince and NetWare.

--

An alternative spelling/capitalization of these macros 
might make them more appealing. Feel free to make a 
suggestion.


--

It's probably incorrect for me to use SetErrno() as a 
function, such as

   SetErrno(1);

I think the semi-colon is not needed, but wasn't 
entirely certain. On better advice, I will fix these 
statements in the remaining source files if this patch 
is accepted.



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-28 15:39

Message:
Logged In: YES 
user_id=33168

Tim, I can check in or do whatever else needs to be done 
to check this in and move this forward.  How do you want to
procede?

Brad, I think most people are pretty busy right now.

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

Comment By: Brad Clements (bkc)
Date: 2002-01-28 15:19

Message:
Logged In: YES 
user_id=4631

Hi folks, just wondering if this patch is going to be 
rejected, or if you're all too busy and I have to be more 
patient ;-)

I have a passle of Python-CE folks waiting on me to finish 
checking in patches. This is the worst one, I promise!

Let me know what you want me to do, when you get a chance. 
Thanks


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

Comment By: Brad Clements (bkc)
Date: 2002-01-20 12:17

Message:
Logged In: YES 
user_id=4631

I've eliminated Py_ClearErrno() and updated all the source 
to use Py_SetErrno(0).  Attached is an updated diff for 
pyport.h



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

Comment By: Tim Peters (tim_one)
Date: 2002-01-20 11:21

Message:
Logged In: YES 
user_id=31435

Brad, errno is required by ANSI C, which also defines the 
semantics of a 0 value.  Setting errno to 0, and taking 
errno==0 as meaning "no error", are 100% portable across 
platforms with a standard-conforming C implementation.  If 
this platform doesn't support standard C, I have to 
question whether the core should even try to cater to it:  
the changes needed make no sense to C programmers, so may 
become a maintenance nightmare.

I don't think putting a layer around errno is going to be 
hard to live with, provided that it merely tries to emulate 
standard behavior.  For that reason, setting errno to 0 is 
correct, but inventing a new ClearErrno concept is wrong 
(the latter makes no sense to anyone except its inventor 
<wink>).

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

Comment By: Brad Clements (bkc)
Date: 2002-01-20 07:54

Message:
Logged In: YES 
user_id=4631

I can post a new diff for the // or would you be willing to 
just change the patch you have?

I cannot use the same macros for Py_SET_ERANGE_IF_OVERFLOW
(X) because Wince doesn't have ERANGE. You'll note the use 
of Py_SetErrno(1) which is frankly bogus. This is related 
to your comment on Py_ClearErrno()

Using (errno == 0) as meaning "no error" seems to me to be 
a python source "convention" forced on it by (mostly) 
floating point side effects. Because the math routines are 
indicating overflow errors through the side effect of 
setting errno (rather than returning an explicit NaN that 
works on all platforms), we must set errno = 0 before 
calling these math functions. 

I suppose it's possible that on some platform "clearing the 
last error value" wouldn't be done this way, but rather 
might be an explicit function call. Since I was going 
through the source looking for all errno's, I felt it was 
clearer to say Py_ClearErrno() rather than Py_SetErrno(0), 
even though in the end they do the same thing on currently 
supported platforms.

I'm easy, if you want to replace Py_ClearErrno() with 
Py_SetErrno(0) I can do that too.

--

Regarding goto targets.. is it likely that "cleanup" might 
also collide with local variables? would _cleanup or 
__cleanup work for you?




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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-19 14:57

Message:
Logged In: YES 
user_id=33168

Need to change the // comment to /* */.  gcc accepts this
for C, but it's non-standard (at least it was, it may have
changed in C99).

You can have 1 Py_SET_ERANGE_IF_OVERFLOW for both platforms
if you do this:

#ifndef ERANGE
#define ERANGE 1
#endif

#define Py_SET_ERANGE_IF_OVERFLOW(X) \
    do { \
        if (Py_GetErrno() == 0 && ((X) == Py_HUGE_VAL || \
                                   (X) == -Py_HUGE_VAL))  \
             Py_SetErrno(ERANGE); \
    } while(0)
I'm not sure of the usefulness of Py_ClearErrno(), since
it's the same on all platforms.  If errno might be set to
something other than 0 in the future, it would be good to
make the change now.

I would suggest changing finally to cleanup.

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

Comment By: Brad Clements (bkc)
Date: 2002-01-19 13:47

Message:
Logged In: YES 
user_id=4631

Here is an amended diff with the suggested changes. I've 
tested the semi-colon handling on EVT, it works as 
suggested.

--

Question: What is the prefered style, #ifdef xyz or #if 
defined(xyz) ?

I try to use #ifdef xyz, but sometimes there's multiple 
possibilities and #if defined(x) || defined(y) is needed. 
Is that okay?

--

Upcoming issue (hoping you address in your reply). There 
are many "goto finally" statements in various modules. 
Unfortunately EVT treats "finally" as a reserved word, even 
when compiling in non C++ mode.  Also, Metrowerks does the 
same.

I've changed all of these to "goto my_finally" as a quick 
work-around. I know "my_finally" sounds yucky, what's your 
recommendation for this? 

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

Comment By: Tim Peters (tim_one)
Date: 2002-01-19 12:52

Message:
Logged In: YES 
user_id=31435

All identifiers defined in pyport.h must begin with "Py_".  
pyport.h is (and must be) #include'd by extension modules, 
and we need the prefix to avoid stomping on their 
namespace, and to make clear (to them and to us) that the 
gimmicks are part of Python's portability layer.  A name 
like "SetErrno" is certain to conflict with some other 
package's attempt to worm around errno problems; Py_SetErrno
() is not.  Agree with Neal's final suggestion about 
dealing with  semicolons.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-19 12:28

Message:
Logged In: YES 
user_id=33168

Typically, the semi-colon problem is dealt with as in
Py_SET_ERANGE_IF_OVERFLOW.

So, 

#define SetErrno(X) do { SetLastError(X); } while (0)

I don't think (but can't remember if) there is any problem
for single statements like you have.  You could probably do:

#ifndef MS_WINCE
#define SetErrno(X) errno = (X)     /* note no ; */
#else
#define SetErrno(X) SetLastError(X) /* note no ; */
#endif


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470


From noreply@sourceforge.net  Tue Jan 29 00:47:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 28 Jan 2002 16:47:54 -0800
Subject: [Patches] [ python-Patches-509965 ] PropertyType is not defined in types.py
Message-ID: <E16VMRG-00084H-00@usw-sf-web2.sourceforge.net>

Patches item #509965, was opened at 2002-01-28 16:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=509965&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: PropertyType is not defined in types.py

Initial Comment:
types.py doesn't define PropertyType.
The attached patch defines it.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=509965&group_id=5470


From noreply@sourceforge.net  Tue Jan 29 01:32:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 28 Jan 2002 17:32:10 -0800
Subject: [Patches] [ python-Patches-509975 ] make python-mode play nice with gdb
Message-ID: <E16VN86-0006H1-00@usw-sf-web3.sourceforge.net>

Patches item #509975, was opened at 2002-01-28 17:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=509975&group_id=5470

Category: Demos and tools
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex Coventry (alex_coventry)
Assigned to: Nobody/Anonymous (nobody)
Summary: make python-mode play nice with gdb

Initial Comment:
if you run gdb (and presumably other debuggers) while
python-mode is loaded, the little arrow it uses to 
indicate the current position in the source code fails
to appear.  this is because the comint hook
py-pdbtrack-track-stack-file wipes it out regardless of
whether the current buffer process comes from python.

hth.
alex

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=509975&group_id=5470


From noreply@sourceforge.net  Tue Jan 29 19:13:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 Jan 2002 11:13:25 -0800
Subject: [Patches] [ python-Patches-510288 ] Emacs auto-detect J/Python mode
Message-ID: <E16Vdh7-0006Jd-00@usw-sf-web1.sourceforge.net>

Patches item #510288, was opened at 2002-01-29 11:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=510288&group_id=5470

Category: Demos and tools
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin J. Butler (kevinbutler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Emacs auto-detect J/Python mode

Initial Comment:
Modify python-mode.el (v. 4.6) to auto-detect the 
interpreter based on:

- #! line  (a la 'get-auto-mode')
- import of Java-specific packages (defaults to (java 
javax org com)
- default to cpython (not py-default-interpreter, 
because the import test can only
detect jpython packages)

I'm not an elisp expert, so review and feedback is 
welcome!

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=510288&group_id=5470


From noreply@sourceforge.net  Wed Jan 30 13:21:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 Jan 2002 05:21:38 -0800
Subject: [Patches] [ python-Patches-510695 ] cycle profiler for VM opcodes
Message-ID: <E16VugE-00035X-00@usw-sf-web1.sourceforge.net>

Patches item #510695, was opened at 2002-01-30 05:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=510695&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Jeremy Hylton (jhylton)
Summary: cycle profiler for VM opcodes

Initial Comment:
This is just some code I'm noodling around with.  It
counts the number of cycles each Python VM opcode takes
to execute, using the Pentium timestamp counter.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=510695&group_id=5470


From noreply@sourceforge.net  Wed Jan 30 15:01:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 Jan 2002 07:01:25 -0800
Subject: [Patches] [ python-Patches-500002 ] Fix for  #221791 (bad \x escape)
Message-ID: <E16VwEn-0007tW-00@usw-sf-web3.sourceforge.net>

Patches item #500002, was opened at 2002-01-05 16:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500002&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for  #221791 (bad \x escape)

Initial Comment:
This patch adds file and line output if a bad \x escape
was found in the source. It does so with the following
modifications:

- PyErr_Display now recognizes syntax errors not by
their class, but by an attribute print_file_and_line
- this attribute is set for all SyntaxError instances
- PyErr_SyntaxLocation is enhanced to set all attributes
expected for a syntax error, even if the current
exception has a different class.
- compile.c now invokes PyErr_SyntaxLocation for all
non-syntax exceptions also, mostly through com_error.

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

>Comment By: Michael Hudson (mwh)
Date: 2002-01-30 07:01

Message:
Logged In: YES 
user_id=6656

This doesn't compile --with-pydebug (he suddenly notices).

There's an assert(val == NULL) in compile.c, but no variable
val.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=500002&group_id=5470


From noreply@sourceforge.net  Wed Jan 30 18:15:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 Jan 2002 10:15:33 -0800
Subject: [Patches] [ python-Patches-510825 ] PTHREAD_SCOPE_SYSTEM support for HP-UX
Message-ID: <E16VzGf-00079b-00@usw-sf-web1.sourceforge.net>

Patches item #510825, was opened at 2002-01-30 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=510825&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: The Written Word (Albert Chin) (tww-china)
Assigned to: Nobody/Anonymous (nobody)
Summary: PTHREAD_SCOPE_SYSTEM support for HP-UX

Initial Comment:
PTHREAD_SCOPE_SYSTEM is supported as an argument to
pthread_attr_setscope() on HP-UX 11.00. However, it is
not detected successfully because HP-UX returns EINVAL
if the first argument to pthread_create is NULL.

Patch attached against Python 2.2. Will work for 2.1.2
as well.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=510825&group_id=5470


From noreply@sourceforge.net  Wed Jan 30 18:16:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 Jan 2002 10:16:45 -0800
Subject: [Patches] [ python-Patches-510825 ] PTHREAD_SCOPE_SYSTEM support for HP-UX
Message-ID: <E16VzHp-0007AC-00@usw-sf-web1.sourceforge.net>

Patches item #510825, was opened at 2002-01-30 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=510825&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: The Written Word (Albert Chin) (tww-china)
Assigned to: Nobody/Anonymous (nobody)
Summary: PTHREAD_SCOPE_SYSTEM support for HP-UX

Initial Comment:
PTHREAD_SCOPE_SYSTEM is supported as an argument to
pthread_attr_setscope() on HP-UX 11.00. However, it is
not detected successfully because HP-UX returns EINVAL
if the first argument to pthread_create is NULL.

Patch attached against Python 2.2. Will work for 2.1.2
as well.

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

>Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2002-01-30 10:16

Message:
Logged In: YES 
user_id=119770

Oops, forgot to attach patch.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=510825&group_id=5470


From noreply@sourceforge.net  Wed Jan 30 22:49:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 Jan 2002 14:49:05 -0800
Subject: [Patches] [ python-Patches-509965 ] PropertyType is not defined in types.py
Message-ID: <E16W3XN-0007wD-00@usw-sf-web2.sourceforge.net>

Patches item #509965, was opened at 2002-01-28 16:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=509965&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: PropertyType is not defined in types.py

Initial Comment:
types.py doesn't define PropertyType.
The attached patch defines it.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-01-30 14:49

Message:
Logged In: YES 
user_id=21627

What would be wrong with

PropertyType = property

In the light of the new-style builtins, is that even needed?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=509965&group_id=5470


From noreply@sourceforge.net  Thu Jan 31 02:32:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 Jan 2002 18:32:03 -0800
Subject: [Patches] [ python-Patches-509965 ] PropertyType is not defined in types.py
Message-ID: <E16W719-0002Lc-00@usw-sf-web2.sourceforge.net>

Patches item #509965, was opened at 2002-01-28 16:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=509965&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: PropertyType is not defined in types.py

Initial Comment:
types.py doesn't define PropertyType.
The attached patch defines it.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-30 18:32

Message:
Logged In: YES 
user_id=33168

I did this thinking about things the old way (pre-2.2)
and trying to keep consistency.

After thinking about it, I don't think it's worthwhile
to implement this patch, so I'm closing it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-30 14:49

Message:
Logged In: YES 
user_id=21627

What would be wrong with

PropertyType = property

In the light of the new-style builtins, is that even needed?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=509965&group_id=5470


From heather@pti-inc.com  Thu Jan 31 04:41:49 2002
From: heather@pti-inc.com (Heather Wilson)
Date: 30 Jan 02 22:41:49 -0600
Subject: [Patches] Adv: MEMS and Semiconductor Training Courses
Message-ID: <200201310550.AAA21198@parmenion.hosting.swbell.net>

PTI Seminars is presenting the following courses for semiconductor
personnel....

 For more details call 636-343-1333 and ask for Heather Wilson.
http://www.ptiseminars.com

 FUNDAMENTALS of MEMS DESIGN & FABRICATION
 April 10,2002  San Jose, CA
 July 24,2002 San Francisco, CA

This course covers:
 MEMS Fabrication
 Surface Micromachining
 Bulk Micromachining
 MEMS Design
 Micromechanics & Electrostatics
 MEMS Applications
 Accelerometers & Gyros
 Micro Optics
 Fiber Switches
 Projection Displays
 Wireless Sensor Networks
 CAD for MEMS
___________________________________________________

 INTRO to OPTICAL MEMS (For Bio-Sensing & Communications)
 April 11, 2002 San Jose, CA

 Course Covers:
 MEMS Overview
 MEMS Applications
 Micromachining Processes
 Micromachining Materials
 Micromachining Modeling
___________________________________________________

 ABCs of IC DESIGN & FABRICATION

  February 20, 2002 San Jose, CA
  March 11, 2002 Portland, OR
  March 18, 2002 Singapore
  April 9, 2002 Boston, MA
  April 19, 2002 Munich, Germany
  April 30, 2002   Phoenix, AZ
 
This course describes in simple terms a sequential format of   
information that constitutes the major fabrication processes and design  
for integrated devices. This one (1) day seminar gives you a 
comprehensive overview of the semiconductor industry & technology. 
The course will give you the background you need to understand the 
basics of semiconductor devices, how they work, the processing 
technologies & equipment to produce them, and circuit design techniques.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ABCs of BASIC ELECTRONICS AND DEVICES
 March 18, 2002   San Jose, CA

ADVANCED TOPICS IN CMP Chemical Mechanical Planarization
 March 21-22, 2002   San Jose, CA

DEFECT ISOLATION for MULTI LEVEL FAILURE ANALYSIS
 March 25-26, 2002   San Jose, CA

DEVICE PHYSICS MADE EASY
  April 8, 2002  San Jose, CA
 
Fundamentals of CHEMICAL MECHANICAL PROCESSING
  March 6, 2002   San Jose, CA

Fundamentals of CHEMICAL VAPOR DEPOSITION
  April 3, 2002   San Jose, CA

Fundamentals of ION IMPLANTATION
 April 2, 2002   San Jose, CA

Fundamentals of MEMS DESIGN & FABRICATION 
 April 10, 2002   San Jose, CA
 July 24, 2002  San Francisco, CA

Fundamentals of METALLIZATION
 April 4, 2002   San Jose, CA

Fundamental RF Plasma Generation for Semiconductor Equipment 
 April 4, 2002   San Jose, CA
 July 24-25, 2002  San Francisco, CA

Fundamentals of WET & DRY ETCH
 March 7, 2002   San Jose, CA

Fundamentals of PHOTOLITHOGRAPHY
 March 19, 2002   San Jose, CA

Fundamentals of THERMAL PROCESSING 
 March 12, 2002   San Jose, CA

INTELLECTUAL PROPERTY STRATEGIES 
for SEMICONDUCTOR INDUSTRY COMPANIES
 February 18-19, 2002 San Jose, CA
 July 24-25, 2002  San Francisco, CA

Intro to CMOS LAYOUT 
 May 6-7, 2002  San Jose, CA

Intro to Optical MEMS for Bio Sensing and Communications 
 April 11, 2002   San Jose, CA
 
INTEGRATED YIELD MANAGEMENT
 March 4-5, 2002   San Jose, CA
 April 18-19, 2002  Munich, Germany
 May 6-7, 2002  Singapore 

Intro to STATISTICAL PROCESSING CONTROL  (SPC)
 April 9, 2002  San Jose, CA

 Intro to FLIP CHIP, WLCSP and MICROVIA TECHNOLOGIES
  April 8, 2002  San Jose, CA
  April 15, 2002  Munich, Germany
  May 6, 2002  Singapore
  July 19, 2002  San Francisco, CA

PRODUCT MARKETING for the Semiconductor Industry
  February 27, 2002  San Jose, CA
  April 18, 2002  Munich, Germany

RF WIRELESS FUNDAMENTALS
 February 25-26, 2002  San Jose, CA

CHECK OUR WEB SITE FOR ADDITIONAL COURSES !!
 http://www.ptiseminars.com

 For a FULL TRAINING SCHEDULE of "open" course dates visit 
  http://www.pti-inc.com/schedule.htm

TO REGISTER Go To
 https://secure.hosting.swbell.net/www.pti-inc.com/registration.html

 TO SPEAK:
    * to an account manager about ATTENDING these courses or having them
 ONSITE
    contact us at (636) 343-1333 in the USA.  Ask for HEATHER WILSON.
    * Fax  (636) 343-8642
    * Email: heather@pti-inc.com

 PTI SEMINARS, INC.  "We Exceed Your Expectations!"

 * To unsubscribe please reply to heather@pti-inc.com and in the subject
 "Unsubscribe".  We apologize for any inconvenience.





From noreply@sourceforge.net  Thu Jan 31 10:41:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Jan 2002 02:41:49 -0800
Subject: [Patches] [ python-Patches-435381 ] Distutils patches for OS/2+EMX support
Message-ID: <E16WEf7-0008EG-00@usw-sf-web2.sourceforge.net>

Patches item #435381, was opened at 2001-06-22 01:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435381&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Distutils patches for OS/2+EMX support

Initial Comment:
The attached patch file is against the code released
with Python 2.1.

The changes are included in the binary installation
package of the OS/2+EMX port of Python 2.1 I released
on June 17, 2001.

With these changes, I have successfully built and
installed the  Numeric 20.0.0 extention, and created a
bdist_dumb distribution package of it. The installed
extention tests successfully using the supplied test
routines.

Particular items of note:-
- OS/2 limits DLLs to 8.3 filenames :-( :-(
- ld is not used to link, instead gcc is used with the
-Zomf option
  which invokes the LINK386 linker native to OS/2
- I haven't made any attempt to merge cloned code back
into the 
  parent code where it would make sense, which I think
is in a few     places.

Feedback appreciated.

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

>Comment By: Michael Hudson (mwh)
Date: 2002-01-31 02:41

Message:
Logged In: YES 
user_id=6656

Are you going to get to this soon, Marc?

Assign it to me if you want rid of it :)

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-01-26 21:33

Message:
Logged In: YES 
user_id=250749

The updated patch against post-2.2 CVS has had some minor cleanups, compared to the earlier versions.

emxccompiler is still standalone, on the basis that it works and is independent of any changes that might happen in the 
Cygwin/MinGW support, given that EMX is not changing much (and not likely to).

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

Comment By: Rene Liebscher (rliebscher)
Date: 2001-08-29 01:39

Message:
Logged In: YES 
user_id=28463

Would it be possible to subclass cygwinccomplier 
(as mingwcompiler does?)

Or maybe create a better class structure like this

           GCCCompiler
         /             \
        /               \
 CygwinCCompiler    EMXCCompiler
      /
     /
MinGWCCompiler

GCCCompiler would never be used directly by anyone,
it only collects all common code.
The other class would only configure the 
GCCCompiler class in their __init__ methods.
(And maybe override some [small] methods if really
necessary.)

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2001-08-12 04:01

Message:
Logged In: YES 
user_id=250749

The only real change in this updated patch is the compiler optimisation switches in emxccompiler.py.

No attempted merging of changes.  Suggestions/advice in this regard sought.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-03 21:38

Message:
Logged In: YES 
user_id=3066

The third item in the list of issues at the end of the
initial comment indicates that the patch isn't ready for
inclusion.  Assigning to Greg Ward for review.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435381&group_id=5470


From noreply@sourceforge.net  Thu Jan 31 12:32:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Jan 2002 04:32:27 -0800
Subject: [Patches] [ python-Patches-435381 ] Distutils patches for OS/2+EMX support
Message-ID: <E16WGOB-0003qJ-00@usw-sf-web1.sourceforge.net>

Patches item #435381, was opened at 2001-06-22 01:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435381&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 5
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Distutils patches for OS/2+EMX support

Initial Comment:
The attached patch file is against the code released
with Python 2.1.

The changes are included in the binary installation
package of the OS/2+EMX port of Python 2.1 I released
on June 17, 2001.

With these changes, I have successfully built and
installed the  Numeric 20.0.0 extention, and created a
bdist_dumb distribution package of it. The installed
extention tests successfully using the supplied test
routines.

Particular items of note:-
- OS/2 limits DLLs to 8.3 filenames :-( :-(
- ld is not used to link, instead gcc is used with the
-Zomf option
  which invokes the LINK386 linker native to OS/2
- I haven't made any attempt to merge cloned code back
into the 
  parent code where it would make sense, which I think
is in a few     places.

Feedback appreciated.

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-01-31 04:32

Message:
Logged In: YES 
user_id=38388

The last patch looks good to me. I don't have OS/2 installed anywhere,
so can't test the patch, but the approach looks reasonable.

Andrew, will you be able to maintain this port to OS/2 ?

About the refactoring of the compiler classes: 
I think we need to go a little further on this one, since it should
be possible to override the compiler classes in setup.py. Currently
this is only possible by hacking the raw classes -- that's not
a good design.

Let's discuss these bits on the mailing list.

If there are no objections and the patch applies cleanly to current
CVS, I'll check it in later today.

Thanks, Andrew !

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

Comment By: Michael Hudson (mwh)
Date: 2002-01-31 02:41

Message:
Logged In: YES 
user_id=6656

Are you going to get to this soon, Marc?

Assign it to me if you want rid of it :)

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-01-26 21:33

Message:
Logged In: YES 
user_id=250749

The updated patch against post-2.2 CVS has had some minor cleanups, compared to the earlier versions.

emxccompiler is still standalone, on the basis that it works and is independent of any changes that might happen in the 
Cygwin/MinGW support, given that EMX is not changing much (and not likely to).

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

Comment By: Rene Liebscher (rliebscher)
Date: 2001-08-29 01:39

Message:
Logged In: YES 
user_id=28463

Would it be possible to subclass cygwinccomplier 
(as mingwcompiler does?)

Or maybe create a better class structure like this

           GCCCompiler
         /             \
        /               \
 CygwinCCompiler    EMXCCompiler
      /
     /
MinGWCCompiler

GCCCompiler would never be used directly by anyone,
it only collects all common code.
The other class would only configure the 
GCCCompiler class in their __init__ methods.
(And maybe override some [small] methods if really
necessary.)

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2001-08-12 04:01

Message:
Logged In: YES 
user_id=250749

The only real change in this updated patch is the compiler optimisation switches in emxccompiler.py.

No attempted merging of changes.  Suggestions/advice in this regard sought.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-03 21:38

Message:
Logged In: YES 
user_id=3066

The third item in the list of issues at the end of the
initial comment indicates that the patch isn't ready for
inclusion.  Assigning to Greg Ward for review.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435381&group_id=5470


From noreply@sourceforge.net  Thu Jan 31 13:27:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Jan 2002 05:27:17 -0800
Subject: [Patches] [ python-Patches-511193 ] Implement killpg in posixmodule
Message-ID: <E16WHFF-0008FT-00@usw-sf-web3.sourceforge.net>

Patches item #511193, was opened at 2002-01-31 05:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511193&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Implement killpg in posixmodule

Initial Comment:
killpg is currently not accessible from python 
standard library. Since process group handling 
functions are accessible (setsid, setpgrp, getpgrp,
setpgid), this one should probably be there as well.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511193&group_id=5470


From noreply@sourceforge.net  Thu Jan 31 14:18:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Jan 2002 06:18:04 -0800
Subject: [Patches] [ python-Patches-458898 ] --python-build for install
Message-ID: <E16WI2O-0005ES-00@usw-sf-web1.sourceforge.net>

Patches item #458898, was opened at 2001-09-05 13:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458898&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
Assigned to: Michael Hudson (mwh)
Summary: --python-build for install

Initial Comment:
Sometimes, being able to install python tools without
having python installed is desirable. When building an
RPM package of python, for example, one may want to
build/install IDLE as well, including it in a
subpackage. Indeed, we're doing this with a couple of
python tools here at Conectiva. Unfortunately, we have
a egg-chicken problem when doing this. You need python
installed in your system before you install tools. This
limitation may be observed in the file
Lib/distutils/sysconfig.py. It looks for Makefile in
the final installation directory, for example.

This patch adds a new option to dist-utils' install
command: --python-build. When used, python will look
for these files in the python build directory specified
trough the option.



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

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-01-31 06:18

Message:
Logged In: YES 
user_id=7887

About..

1) Sorry.. I'll take care to add comments to the file next 
time. The bottom one is newer.

2) For now, a local option seems to be ok. If other 
commands start using it (what seems unprobable right now), 
we may turn it into a global option without any drawbacks, 
since global options are acceptable anywhere.


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

Comment By: Michael Hudson (mwh)
Date: 2002-01-21 02:45

Message:
Logged In: YES 
user_id=6656

Ta.  Some random comments:
(1) it's not obvious from this page which of the two patches
attached is the newer.  This may be sf's fault, but...
(2) might it be better to make this a global distutils
option?  It seems a bit fragile at the moment -- we'd need
to change things if, say, build_ext started to depend on
python_build.
Would, say
$ python setup.py --python-build install
be better?

I dunno, I don't really understand how options chase around
distutils yet... 

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

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-01-18 16:02

Message:
Logged In: YES 
user_id=7887

Here is a new patch including your suggestions.

Thank you!!


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

Comment By: Michael Hudson (mwh)
Date: 2002-01-17 09:49

Message:
Logged In: YES 
user_id=6656

Hey!  This patch is less than six months old.  Virtually
fresh :|

Some comments:  are you sure you can get away with only
honouring --python-build in install?  I think build_scripts
needs it too (now, anyway, maybe not when you wrote the patch).

Also, the mod to install.finalize_options() is in the wrong
place wrt. the surrouding comments.  Can you fix this?

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=458898&group_id=5470


From noreply@sourceforge.net  Thu Jan 31 14:55:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Jan 2002 06:55:56 -0800
Subject: [Patches] [ python-Patches-511219 ] suppress type restrictions on locals()
Message-ID: <E16WId2-0005iJ-00@usw-sf-web1.sourceforge.net>

Patches item #511219, was opened at 2002-01-31 06:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511219&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Cesar Douady (douady)
Assigned to: Nobody/Anonymous (nobody)
Summary: suppress type restrictions on locals()

Initial Comment:
This patch suppresses the restriction that global and
local dictionaries do not access overloaded __getitem__
and __setitem__ if passed an object derived from class
dict.

An exception is made for the builtin insertion and
reference in the global dict to make sure this object
exists and to suppress the need for the derived class
to take care of this implementation dependent detail.

The behavior of eval and exec has been updated for code
objects which have the CO_NEWLOCALS flag set : if
explicitely passed a local dict, a new local dict is
not generated. This allows one to pass an explicit
local dict to the code object of a function (which
otherwise cannot be achieved). If this cannot be done
for backward compatibility problems, then an
alternative would consist in using the "new" module to
create a code object from a function with CO_NEWLOCALS
reset but it seems logical to me to use the information
explicitely provided.

Free and cell variables are not managed in this
version. If the patch is accepted, I am willing to
finish the job and implement free and cell variables,
but this requires a serious rework of the Cell object:
free variables should be accessed using the method of
the dict in which they relies and today, this dict is
not accessible from the Cell object.

Robustness : Currently, the plain test suite passes
(with a modification of test_desctut which precisely
verifies that the suppressed restriction is enforced).
 I have introduced a new test (test_subdict.py) which
verifies the new behavior.

Because of performance, the plain case (when the local
dict is a plain dict) is optimized so that differences
in performance are not measurable (within 1%) when run
on the test suite (i.e. I timed make test).


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511219&group_id=5470


From noreply@sourceforge.net  Thu Jan 31 18:56:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Jan 2002 10:56:15 -0800
Subject: [Patches] [ python-Patches-435381 ] Distutils patches for OS/2+EMX support
Message-ID: <E16WMNb-0004IK-00@usw-sf-web3.sourceforge.net>

Patches item #435381, was opened at 2001-06-22 01:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435381&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Distutils patches for OS/2+EMX support

Initial Comment:
The attached patch file is against the code released
with Python 2.1.

The changes are included in the binary installation
package of the OS/2+EMX port of Python 2.1 I released
on June 17, 2001.

With these changes, I have successfully built and
installed the  Numeric 20.0.0 extention, and created a
bdist_dumb distribution package of it. The installed
extention tests successfully using the supplied test
routines.

Particular items of note:-
- OS/2 limits DLLs to 8.3 filenames :-( :-(
- ld is not used to link, instead gcc is used with the
-Zomf option
  which invokes the LINK386 linker native to OS/2
- I haven't made any attempt to merge cloned code back
into the 
  parent code where it would make sense, which I think
is in a few     places.

Feedback appreciated.

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-01-31 10:56

Message:
Logged In: YES 
user_id=38388

Checked in.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-01-31 04:32

Message:
Logged In: YES 
user_id=38388

The last patch looks good to me. I don't have OS/2 installed anywhere,
so can't test the patch, but the approach looks reasonable.

Andrew, will you be able to maintain this port to OS/2 ?

About the refactoring of the compiler classes: 
I think we need to go a little further on this one, since it should
be possible to override the compiler classes in setup.py. Currently
this is only possible by hacking the raw classes -- that's not
a good design.

Let's discuss these bits on the mailing list.

If there are no objections and the patch applies cleanly to current
CVS, I'll check it in later today.

Thanks, Andrew !

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

Comment By: Michael Hudson (mwh)
Date: 2002-01-31 02:41

Message:
Logged In: YES 
user_id=6656

Are you going to get to this soon, Marc?

Assign it to me if you want rid of it :)

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-01-26 21:33

Message:
Logged In: YES 
user_id=250749

The updated patch against post-2.2 CVS has had some minor cleanups, compared to the earlier versions.

emxccompiler is still standalone, on the basis that it works and is independent of any changes that might happen in the 
Cygwin/MinGW support, given that EMX is not changing much (and not likely to).

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

Comment By: Rene Liebscher (rliebscher)
Date: 2001-08-29 01:39

Message:
Logged In: YES 
user_id=28463

Would it be possible to subclass cygwinccomplier 
(as mingwcompiler does?)

Or maybe create a better class structure like this

           GCCCompiler
         /             \
        /               \
 CygwinCCompiler    EMXCCompiler
      /
     /
MinGWCCompiler

GCCCompiler would never be used directly by anyone,
it only collects all common code.
The other class would only configure the 
GCCCompiler class in their __init__ methods.
(And maybe override some [small] methods if really
necessary.)

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2001-08-12 04:01

Message:
Logged In: YES 
user_id=250749

The only real change in this updated patch is the compiler optimisation switches in emxccompiler.py.

No attempted merging of changes.  Suggestions/advice in this regard sought.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-03 21:38

Message:
Logged In: YES 
user_id=3066

The third item in the list of issues at the end of the
initial comment indicates that the patch isn't ready for
inclusion.  Assigning to Greg Ward for review.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435381&group_id=5470


From noreply@sourceforge.net  Thu Jan 31 18:59:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Jan 2002 10:59:15 -0800
Subject: [Patches] [ python-Patches-432401 ] unicode encoding error callbacks
Message-ID: <E16WMQV-0004Kr-00@usw-sf-web3.sourceforge.net>

Patches item #432401, was opened at 2001-06-12 06:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: Postponed
>Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode encoding error callbacks

Initial Comment:
This patch adds unicode error handling callbacks to the
encode functionality. With this patch it's possible to
not only pass 'strict', 'ignore' or 'replace' as the
errors argument to encode, but also a callable
function, that will be called with the encoding name,
the original unicode object and the position of the
unencodable character. The callback must return a
replacement unicode object that will be encoded instead
of the original character.

For example replacing unencodable characters with XML
character references can be done in the following way.

u"aäoöuüß".encode(
   "ascii",
   lambda enc, uni, pos: u"&#x%x;" % ord(uni[pos])
)




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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-09-20 03:38

Message:
Logged In: YES 
user_id=38388

I am postponing this patch until the PEP process has started. This feature won't make it into Python 2.2. 

Walter, you may want to reference this patch in the PEP.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-16 03:53

Message:
Logged In: YES 
user_id=38388

I think we ought to summarize these changes in a PEP to get some more feedback and testing from others as 
well.

I'll look into this after I'm back from vacation on the 10.09.

Given the release schedule I am not sure whether this feature will make it into 2.2. The size of the patch is huge 
and probably needs a lot of testing first.

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

Comment By: Walter Dörwald (doerwalter)
Date: 2001-07-26 20:55

Message:
Logged In: YES 
user_id=89016

Changing the decoding API is done now. There 
are new functions
codec.register_unicodedecodeerrorhandler and
codec.lookup_unicodedecodeerrorhandler. 
Only the standard handlers for 'strict', 
'ignore' and 'replace' are preregistered.

There may be many reasons for decoding errors 
in the byte string, so I added an additional
argument to the decoding API: reason, which 
gives the reason for the failure, e.g.:

>>> "\U1111111".decode("unicode_escape")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: encoding 'unicodeescape' can't decode byte 
0x31 in position 8: truncated \UXXXXXXXX escape
>>> "\U11111111".decode("unicode_escape")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: encoding 'unicodeescape' can't decode byte 
0x31 in position 9: illegal Unicode character

For symmetry I added this to the encoding API too:
>>> u"\xff".encode("ascii")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: encoding 'ascii' can't decode byte 0xff in 
position 0: ordinal not in range(128)

The parameters passed to the callbacks now are:
encoding, unicode, position, reason, state.

The encoding and decoding API for strings has been 
adapted too, so now the new API should be usable 
everywhere:

>>> unicode("a\xffb\xffc", "ascii", 
...    lambda enc, uni, pos, rea, sta: (u"<?>", pos+1))
u'a<?>b<?>c'
>>> "a\xffb\xffc".decode("ascii",
...    lambda enc, uni, pos, rea, sta: (u"<?>", 
pos+1))            
u'a<?>b<?>c'

I had a problem with the decoding API: all the 
functions in _codecsmodule.c used the t# format 
specifier. I changed that to O! with 
&PyString_Type, because otherwise we would have 
the problem that the decoding API would must pass
buffer object around instead of strings, and 
the callback would have to call str() on the 
buffer anyway to access a specific character, so 
this wouldn't be any faster than calling str() 
on the buffer before decoding. It seems that 
buffers  aren't used anyway. 

I changed all the old function to call the new 
ones so bugfixes don't have to be done in two 
places. There are two exceptions: I didn't 
change PyString_AsEncodedString and 
PyString_AsDecodedString because they are 
documented as deprecated anyway (although they 
are called in a few spots) This means that I 
duplicated part of their functionality in 
PyString_AsEncodedObjectEx and 
PyString_AsDecodedObjectEx.

There are still a few spots that call the old API:
E.g. PyString_Format still calls PyUnicode_Decode 
(but with strict decoding) because it passes the 
rest of the format string to PyUnicode_Format 
when it encounters a Unicode object.

Should we switch to the new API everywhere even 
if strict encoding/decoding is used?

The size of this patch begins to scare me. I 
guess we need an extensive test script for all the 
new features and documentation. I hope you have time 
to do that, as I'll be busy with other projects in
the next weeks. (BTW, I have't touched 
PyUnicode_TranslateCharmap yet.)


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

Comment By: Walter Dörwald (doerwalter)
Date: 2001-07-23 10:03

Message:
Logged In: YES 
user_id=89016

New version of the patch with the error handling callback 
registry. 

> > OK, done, now there's a
> > PyCodec_EscapeReplaceUnicodeEncodeErrors/
> > codecs.escapereplace_unicodeencode_errors
> > that uses \u (or \U if x>0xffff (with a wide build
> > of Python)).
> 
> Great!

Now PyCodec_EscapeReplaceUnicodeEncodeErrors uses \x
in addition to \u and \U where appropriate.

> > [...] 
> > But for special one-shot error handlers, it might still 
be
> > useful to pass the error handler directly, so maybe we
> > should leave error as PyObject *, but implement the
> > registry anyway?
> 
> Good idea !
> 
> One minor nit: codecs.registerError() should be named
> codecs.register_errorhandler() to be more inline with
> the Python coding style guide.

OK, but these function are specific to unicode encoding,
so now the functions are called:
   codecs.register_unicodeencodeerrorhandler
   codecs.lookup_unicodeencodeerrorhandler

Now all callbacks (including the new 
ones: "xmlcharrefreplace" 
and "escapereplace") are registered in the 
codecs.c/_PyCodecRegistry_Init so using them is really 
simple: u"gürk".encode("ascii", "xmlcharrefreplace")


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-07-13 04:26

Message:
Logged In: YES 
user_id=38388

> > >    > > BTW, I guess PyUnicode_EncodeUnicodeEscape
> > >    > > could be reimplemented as PyUnicode_EncodeASCII
> > >    > > with \uxxxx replacement callback.
> > >    >
> > >    > Hmm, wouldn't that result in a slowdown ? If so,
> > >    > I'd rather leave the special encoder in place,
> > >    > since it is being used a lot in Python and
> > >    > probably some applications too.
> > >
> > >    It would be a slowdown. But callbacks open many
> > >    possiblities.
> >
> > True, but in this case I believe that we should stick with
> > the native implementation for "unicode-escape". Having
> > a standard callback error handler which does the \uXXXX
> > replacement would be nice to have though, since this would
> > also be usable with lots of other codecs (e.g. all the
> > code page ones).
> 
> OK, done, now there's a
> PyCodec_EscapeReplaceUnicodeEncodeErrors/
> codecs.escapereplace_unicodeencode_errors
> that uses \u (or \U if x>0xffff (with a wide build
> of Python)).

Great !
 
> > [...]
> > >    Should the old TranslateCharmap map to the new
> > >    TranslateCharmapEx and inherit the
> > >    "multicharacter replacement" feature,
> > >    or should I leave it as it is?
> >
> > If possible, please also add the multichar replacement
> > to the old API. I think it is very useful and since the
> > old APIs work on raw buffers it would be a benefit to have
> > the functionality in the old implementation too.
> 
> OK! I will try to find the time to implement that in the
> next days.

Good.
 
> > [Decoding error callbacks]
> >
> > About the return value:
> >
> > I'd suggest to always use the same tuple interface, e.g.
> >
> >     callback(encoding, input_data, input_position,
> state) ->
> >         (output_to_be_appended, new_input_position)
> >
> > (I think it's better to use absolute values for the
> > position rather than offsets.)
> >
> > Perhaps the encoding callbacks should use the same
> > interface... what do you think ?
> 
> This would make the callback feature hypergeneric and a
> little slower, because tuples have to be created, but it
> (almost) unifies the encoding and decoding API. ("almost"
> because, for the encoder output_to_be_appended will be
> reencoded, for the decoder it will simply be appended.),
> so I'm for it.

That's the point. 

Note that I don't think the tuple creation
will hurt much (see the make_tuple() API in codecs.c)
since small tuples are cached by Python internally.
 
> I implemented this and changed the encoders to only
> lookup the error handler on the first error. The UCS1
> encoder now no longer uses the two-item stack strategy.
> (This strategy only makes sense for those encoder where
> the encoding itself is much more complicated than the
> looping/callback etc.) So now memory overflow tests are
> only done, when an unencodable error occurs, so now the
> UCS1 encoder should be as fast as it was without
> error callbacks.
> 
> Do we want to enforce new_input_position>input_position,
> or should jumping back be allowed?

No; moving backwards should be allowed (this may be useful
in order to resynchronize with the input data).
 
> Here's is the current todo list:
> 1. implement a new TranslateCharmap and fix the old.
> 2. New encoding API for string objects too.
> 3. Decoding
> 4. Documentation
> 5. Test cases
> 
> I'm thinking about a different strategy for implementing
> callbacks
> (see http://mail.python.org/pipermail/i18n-sig/2001-
> July/001262.html)
> 
> We coould have a error handler registry, which maps names
> to error handlers, then it would be possible to keep the
> errors argument as "const char *" instead of "PyObject *".
> Currently PyCodec_UnicodeEncodeHandlerForObject is a
> backwards compatibility hack that will never go away,
> because
> it's always more convenient to type
>    u"...".encode("...", "strict")
> instead of
>    import codecs
>    u"...".encode("...", codecs.raise_encode_errors)
> 
> But with an error handler registry this function would
> become the official lookup method for error handlers.
> (PyCodec_LookupUnicodeEncodeErrorHandler?)
> Python code would look like this:
> ---
> def xmlreplace(encoding, unicode, pos, state):
>    return (u"&#%d;" % ord(uni[pos]), pos+1)
> 
> import codec
> 
> codec.registerError("xmlreplace",xmlreplace)
> ---
> and then the following call can be made:
>         u"äöü".encode("ascii", "xmlreplace")
> As soon as the first error is encountered, the encoder uses
> its builtin error handling method if it recognizes the name
> ("strict", "replace" or "ignore") or looks up the error
> handling function in the registry if it doesn't. In this way
> the speed for the backwards compatible features is the same
> as before and "const char *error" can be kept as the
> parameter to all encoding functions. For speed common error
> handling names could even be implemented in the encoder
> itself.
> 
> But for special one-shot error handlers, it might still be
> useful to pass the error handler directly, so maybe we
> should leave error as PyObject *, but implement the
> registry anyway?

Good idea !

One minor nit: codecs.registerError() should be named
codecs.register_errorhandler() to be more inline with
the Python coding style guide.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2001-07-12 04:03

Message:
Logged In: YES 
user_id=89016

> >    [...]
> >    so I guess we could change the replace handler
> >    to always return u'?'. This would make the
> >    implementation a little bit simpler, but the 
> >    explanation of the callback feature *a lot* 
> >    simpler. 
> 
> Go for it.

OK, done!

> [...]
> >    > Could you add these docs to the Misc/unicode.txt
> >    > file ? I will eventually take that file and turn 
> >    > it into a PEP which will then serve as general 
> >    > documentation for these things.
> > 
> >    I could, but first we should work out how the 
> >    decoding callback API will work.
> 
> Ok. BTW, Barry Warsaw already did the work of converting
> the unicode.txt to PEP 100, so the docs should eventually 
> go there.

OK. I guess it would be best to do this when everything 
is finished.

> >    > > BTW, I guess PyUnicode_EncodeUnicodeEscape
> >    > > could be reimplemented as PyUnicode_EncodeASCII 
> >    > > with \uxxxx replacement callback.
> >    >
> >    > Hmm, wouldn't that result in a slowdown ? If so,
> >    > I'd rather leave the special encoder in place, 
> >    > since it is being used a lot in Python and 
> >    > probably some applications too.
> > 
> >    It would be a slowdown. But callbacks open many 
> >    possiblities.
> 
> True, but in this case I believe that we should stick with
> the native implementation for "unicode-escape". Having
> a standard callback error handler which does the \uXXXX
> replacement would be nice to have though, since this would
> also be usable with lots of other codecs (e.g. all the
> code page ones).

OK, done, now there's a 
PyCodec_EscapeReplaceUnicodeEncodeErrors/
codecs.escapereplace_unicodeencode_errors
that uses \u (or \U if x>0xffff (with a wide build
of Python)).

> >    For example:
> > 
> >       Why can't I print u"gürk"?
> > 
> >    is probably one of the most frequently asked
> >    questions in comp.lang.python. For printing 
> >    Unicode stuff, print could be extended the use an 
> >    error handling callback for Unicode strings (or 
> >    objects where __str__ or tp_str returns a Unicode 
> >    object) instead of using str() which always 
> >    returns an 8bit string and uses strict encoding. 
> >    There might even be a
> >    sys.setprintencodehandler()/sys.getprintencodehandler
()
> 
> There already is a print callback in Python (forgot the
> name of the hook though), so this should be possible by 
> providing the encoding logic in the hook.

True: sys.displayhook

> [...]
> >    Should the old TranslateCharmap map to the new 
> >    TranslateCharmapEx and inherit the 
> >    "multicharacter replacement" feature,
> >    or should I leave it as it is?
> 
> If possible, please also add the multichar replacement
> to the old API. I think it is very useful and since the
> old APIs work on raw buffers it would be a benefit to have
> the functionality in the old implementation too.

OK! I will try to find the time to implement that in the 
next days.

> [Decoding error callbacks]
>
> About the return value:
> 
> I'd suggest to always use the same tuple interface, e.g.
> 
>     callback(encoding, input_data, input_position, 
state) -> 
>         (output_to_be_appended, new_input_position)
> 
> (I think it's better to use absolute values for the 
> position rather than offsets.)
> 
> Perhaps the encoding callbacks should use the same 
> interface... what do you think ?

This would make the callback feature hypergeneric and a
little slower, because tuples have to be created, but it
(almost) unifies the encoding and decoding API. ("almost" 
because, for the encoder output_to_be_appended will be 
reencoded, for the decoder it will simply be appended.), 
so I'm for it.

I implemented this and changed the encoders to only 
lookup the error handler on the first error. The UCS1 
encoder now no longer uses the two-item stack strategy. 
(This strategy only makes sense for those encoder where 
the encoding itself is much more complicated than the 
looping/callback etc.) So now memory overflow tests are 
only done, when an unencodable error occurs, so now the 
UCS1 encoder should be as fast as it was without 
error callbacks.

Do we want to enforce new_input_position>input_position,
or should jumping back be allowed?

> >    > > One additional note: It is vital that errors
> >    > > is an assignable attribute of the StreamWriter.
> >    >
> >    > It is already !
> > 
> >    I know, but IMHO it should be documented that an
> >    assignable errors attribute must be supported 
> >    as part of the official codec API.
> > 
> >    Misc/unicode.txt is not clear on that:
> >    """
> >    It is not required by the Unicode implementation
> >    to use these base classes, only the interfaces must 
> >    match; this allows writing Codecs as extension types.
> >    """
> 
> Good point. I'll add that to the PEP 100.

OK.

Here's is the current todo list:
1. implement a new TranslateCharmap and fix the old.
2. New encoding API for string objects too.
3. Decoding
4. Documentation
5. Test cases

I'm thinking about a different strategy for implementing 
callbacks
(see http://mail.python.org/pipermail/i18n-sig/2001-
July/001262.html)

We coould have a error handler registry, which maps names 
to error handlers, then it would be possible to keep the 
errors argument as "const char *" instead of "PyObject *". 
Currently PyCodec_UnicodeEncodeHandlerForObject is a 
backwards compatibility hack that will never go away, 
because 
it's always more convenient to type
   u"...".encode("...", "strict")
instead of
   import codecs
   u"...".encode("...", codecs.raise_encode_errors)

But with an error handler registry this function would 
become the official lookup method for error handlers. 
(PyCodec_LookupUnicodeEncodeErrorHandler?)
Python code would look like this:
---
def xmlreplace(encoding, unicode, pos, state):
   return (u"&#%d;" % ord(uni[pos]), pos+1)

import codec

codec.registerError("xmlreplace",xmlreplace)
---
and then the following call can be made:
	u"äöü".encode("ascii", "xmlreplace")
As soon as the first error is encountered, the encoder uses
its builtin error handling method if it recognizes the name 
("strict", "replace" or "ignore") or looks up the error 
handling function in the registry if it doesn't. In this way
the speed for the backwards compatible features is the same 
as before and "const char *error" can be kept as the 
parameter to all encoding functions. For speed common error 
handling names could even be implemented in the encoder 
itself.

But for special one-shot error handlers, it might still be 
useful to pass the error handler directly, so maybe we 
should leave error as PyObject *, but implement the 
registry anyway?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-07-10 05:29

Message:
Logged In: YES 
user_id=38388

Ok, here we go...

>    > > raise an exception). U+FFFD characters in the 
>    replacement
>    > > string will be replaced with a character that the 
>    encoder
>    > > chooses ('?' in all cases).
>    >
>    > Nice.
> 
>    But the special casing of U+FFFD makes the interface 
>    somewhat
>    less clean than it could be. It was only done to be 100%
>    backwards compatible. With the original "replace"
>    error
>    handling the codec chose the replacement character. But as
>    far as I can tell none of the codecs uses anything other
>    than '?', 

True.

>    so I guess we could change the replace handler
>    to always return u'?'. This would make the implementation a
>    little bit simpler, but the explanation of the callback
>    feature *a lot* simpler. 

Go for it.

>    And if you still want to handle
>    an unencodable U+FFFD, you can write a special callback for
>    that, e.g.
> 
>    def FFFDreplace(enc, uni, pos):
>    if uni[pos] == "\ufffd":
>    return u"?"
>    else:
>    raise UnicodeError(...)
>
>    > ...docs...
>    >
>    > Could you add these docs to the Misc/unicode.txt file ? I
>    > will eventually take that file and turn it into a PEP 
>    which
>    > will then serve as general documentation for these things.
> 
>    I could, but first we should work out how the decoding
>    callback API will work.

Ok. BTW, Barry Warsaw already did the work of converting the
unicode.txt to PEP 100, so the docs should eventually go there.
 
>    > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be
>    > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx
>    > > replacement callback.
>    >
>    > Hmm, wouldn't that result in a slowdown ? If so, I'd 
>    rather
>    > leave the special encoder in place, since it is being 
>    used a
>    > lot in Python and probably some applications too.
> 
>    It would be a slowdown. But callbacks open many 
>    possiblities.

True, but in this case I believe that we should stick with
the native implementation for "unicode-escape". Having
a standard callback error handler which does the \uXXXX
replacement would be nice to have though, since this would
also be usable with lots of other codecs (e.g. all the code page
ones).
 
>    For example:
> 
>       Why can't I print u"gürk"?
> 
>    is probably one of the most frequently asked questions in
>    comp.lang.python. For printing Unicode stuff, print could be
>    extended the use an error handling callback for Unicode 
>    strings (or objects where __str__ or tp_str returns a 
>    Unicode object) instead of using str() which always returns 
>    an 8bit string and uses strict encoding. There might even 
>    be a
>    sys.setprintencodehandler()/sys.getprintencodehandler()

There already is a print callback in Python (forgot the name of the
hook though), so this should be possible by providing the
encoding logic in the hook.
 
>    > > I have not touched PyUnicode_TranslateCharmap yet,
>    > > should this function also support error callbacks? Why
>    > > would one want the insert None into the mapping to
>    call
>    > > the callback?
>    >
>    > 1. Yes.
>    > 2. The user may want to e.g. restrict usage of certain
>    > character ranges. In this case the codec would be used to
>    > verify the input and an exception would indeed be useful
>    > (e.g. say you want to restrict input to Hangul + ASCII).
> 
>    OK, do we want TranslateCharmap to work exactly like 
>    encoding,
>    i.e. in case of an error should the returned replacement
>    string again be mapped through the translation mapping or
>    should it be copied to the output directly? The former would
>    be more in line with encoding, but IMHO the latter would
>    be much more useful.

It's better to take the second approach (copy the callback
output directly to the output string) to avoid endless
recursion and other pitfalls.

I suppose this will also simplify the implementation somewhat.
 
>    BTW, when I implement it I can implement patch #403100
>    ("Multicharacter replacements in 
>    PyUnicode_TranslateCharmap")
>    along the way.

I've seen it; will comment on it later.
 
>    Should the old TranslateCharmap map to the new 
>    TranslateCharmapEx
>    and inherit the "multicharacter replacement" feature,
>    or
>    should I leave it as it is?

If possible, please also add the multichar replacement
to the old API. I think it is very useful and since the
old APIs work on raw buffers it would be a benefit to have
the functionality in the old implementation too.
 
[Decoding error callbacks]

>    > > A remaining problem is how to implement decoding error
>    > > callbacks. In Python 2.1 encoding and decoding errors 
>    are
>    > > handled in the same way with a string value. But with
>    > > callbacks it doesn't make sense to use the same
>    callback
>    > > for encoding and decoding (like 
>    codecs.StreamReaderWriter
>    > > and codecs.StreamRecoder do). Decoding callbacks have
>    a
>    > > different API. Which arguments should be passed to the
>    > > decoding callback, and what is the decoding callback
>    > > supposed to do?
>    >
>    > I'd suggest adding another set of PyCodec_UnicodeDecode...
>    ()
>    > APIs for this. We'd then have to augment the base classes 
>    of
>    > the StreamCodecs to provide two attributes for .errors 
>    with
>    > a fallback solution for the string case (i.s. "strict"
>    can
>    > still be used for both directions).
> 
>    Sounds good. Now what is the decoding callback supposed to 
>    do?
>    I guess it will be called in the same way as the encoding
>    callback, i.e. with encoding name, original string and
>    position of the error. It might returns a Unicode string
>    (i.e. an object of the decoding target type), that will be
>    emitted from the codec instead of the one offending byte. Or
>    it might return a tuple with replacement Unicode object and
>    a resynchronisation offset, i.e. returning (u"?", 1)
>    means
>    emit a '?' and skip the offending character. But to make
>    the offset really useful the callback has to know something
>    about the encoding, perhaps the codec should be allowed to
>    pass an additional state object to the callback?
> 
>    Maybe the same should be added to the encoding callbacks to?
>    Maybe the encoding callback should be able to tell the
>    encoder if the replacement returned should be reencoded
>    (in which case it's a Unicode object), or directly emitted
>    (in which case it's an 8bit string)?

I like the idea of having an optional state object (basically
this should be a codec-defined arbitrary Python object)
which then allow the callback to apply additional tricks.
The object should be documented to be modifyable in place
(simplifies the interface).

About the return value:

I'd suggest to always use the same tuple interface, e.g.

    callback(encoding, input_data, input_position, state) -> 
        (output_to_be_appended, new_input_position)

(I think it's better to use absolute values for the position 
rather than offsets.)

Perhaps the encoding callbacks should use the same 
interface... what do you think ?

>    > > One additional note: It is vital that errors is an
>    > > assignable attribute of the StreamWriter.
>    >
>    > It is already !
> 
>    I know, but IMHO it should be documented that an assignable
>    errors attribute must be supported as part of the official
>    codec API.
> 
>    Misc/unicode.txt is not clear on that:
>    """
>    It is not required by the Unicode implementation to use 
>    these base classes, only the interfaces must match; this 
>    allows writing Codecs as extension types.
>    """

Good point. I'll add that to the PEP 100.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-06-22 13:51

Message:
Logged In: YES 
user_id=38388

Sorry to keep you waiting, Walter. I will look into this
again next week -- this week was way too busy...

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-06-13 10:00

Message:
Logged In: YES 
user_id=38388

On your comment about the non-Unicode codecs: let's keep
this separated from the current patch.

Don't have much time today. I'll comment on the other things
tomorrow.

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

Comment By: Walter Dörwald (doerwalter)
Date: 2001-06-13 08:49

Message:
Logged In: YES 
user_id=89016

Guido van Rossum wrote in python-dev:

> True, the "codec" pattern can be used for other 
> encodings than Unicode.  But it seems to me that the
> entire codecs architecture is rather strongly geared
> towards en/decoding Unicode, and it's not clear
> how well other codecs fit in this pattern (e.g. I 
> noticed that all the non-Unicode codecs ignore the 
> error handling parameter or assert that
> it is set to 'strict').

I noticed that too. asserting that errors=='strict' would 
mean that the encoder is not able to deal in any other way 
with unencodable stuff than by raising an error. But that 
is not the problem here, because for zlib, base64, quopri, 
hex and uu encoding there can be no unencodable characters. 
The encoders can simply ignore the errors parameter. Should 
I remove the asserts from those codecs and change the 
docstrings accordingly, or will this be done separately?


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

Comment By: Walter Dörwald (doerwalter)
Date: 2001-06-13 06:57

Message:
Logged In: YES 
user_id=89016

> > [...]
> > raise an exception). U+FFFD characters in the 
replacement
> > string will be replaced with a character that the 
encoder
> > chooses ('?' in all cases).
>
> Nice.

But the special casing of U+FFFD makes the interface 
somewhat
less clean than it could be. It was only done to be 100%
backwards compatible. With the original "replace" error
handling the codec chose the replacement character. But as
far as I can tell none of the codecs uses anything other
than '?', so I guess we could change the replace handler
to always return u'?'. This would make the implementation a
little bit simpler, but the explanation of the callback
feature *a lot* simpler. And if you still want to handle
an unencodable U+FFFD, you can write a special callback for
that, e.g.

def FFFDreplace(enc, uni, pos):
if uni[pos] == "\ufffd":
return u"?"
else:
raise UnicodeError(...)

> > The implementation of the loop through the string is 
done
> > in the following way. A stack with two strings is kept
> > and the loop always encodes a character from the string
> > at the stacktop. If an error is encountered and the 
stack
> > has only one entry (during encoding of the original 
string)
> > the callback is called and the unicode object returned 
is
> > pushed on the stack, so the encoding continues with the
> > replacement string. If the stack has two entries when an
> > error is encountered, the replacement string itself has
> > an unencodable character and a normal exception raised.
> > When the encoder has reached the end of it's current 
string
> > there are two possibilities: when the stack contains two
> > entries, this was the replacement string, so the 
replacement
> > string will be poppep from the stack and encoding 
continues
> > with the next character from the original string. If the
> > stack had only one entry, encoding is finished.
>
> Very elegant solution !

I'll put it as a comment in the source.

> > (I hope that's enough explanation of the API and
> implementation)
>
> Could you add these docs to the Misc/unicode.txt file ? I
> will eventually take that file and turn it into a PEP 
which
> will then serve as general documentation for these things.

I could, but first we should work out how the decoding
callback API will work.

> > I have renamed the static ...121 function to all 
lowercase
> > names.
>
> Ok.
>
> > BTW, I guess PyUnicode_EncodeUnicodeEscape could be
> > reimplemented as PyUnicode_EncodeASCII with a \uxxxx
> > replacement callback.
>
> Hmm, wouldn't that result in a slowdown ? If so, I'd 
rather
> leave the special encoder in place, since it is being 
used a
> lot in Python and probably some applications too.

It would be a slowdown. But callbacks open many 
possiblities.

For example:

   Why can't I print u"gürk"?

is probably one of the most frequently asked questions in
comp.lang.python. For printing Unicode stuff, print could be
extended the use an error handling callback for Unicode 
strings (or objects where __str__ or tp_str returns a 
Unicode object) instead of using str() which always returns 
an 8bit string and uses strict encoding. There might even 
be a
sys.setprintencodehandler()/sys.getprintencodehandler()

> [...]
> I think it would be worthwhile to rename the callbacks to
> include "Unicode" somewhere, e.g.
> PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, 
but
> then it points out the application field of the callback
> rather well. Same for the callbacks exposed through the
> _codecsmodule.

OK, done (and PyCodec_XMLCharRefReplaceUnicodeEncodeErrors
really is a long name ;))

> > I have not touched PyUnicode_TranslateCharmap yet,
> > should this function also support error callbacks? Why
> > would one want the insert None into the mapping to call
> > the callback?
>
> 1. Yes.
> 2. The user may want to e.g. restrict usage of certain
> character ranges. In this case the codec would be used to
> verify the input and an exception would indeed be useful
> (e.g. say you want to restrict input to Hangul + ASCII).

OK, do we want TranslateCharmap to work exactly like 
encoding,
i.e. in case of an error should the returned replacement
string again be mapped through the translation mapping or
should it be copied to the output directly? The former would
be more in line with encoding, but IMHO the latter would
be much more useful.

BTW, when I implement it I can implement patch #403100
("Multicharacter replacements in 
PyUnicode_TranslateCharmap")
along the way.

Should the old TranslateCharmap map to the new 
TranslateCharmapEx
and inherit the "multicharacter replacement" feature, or
should I leave it as it is?

> > A remaining problem is how to implement decoding error
> > callbacks. In Python 2.1 encoding and decoding errors 
are
> > handled in the same way with a string value. But with
> > callbacks it doesn't make sense to use the same callback
> > for encoding and decoding (like 
codecs.StreamReaderWriter
> > and codecs.StreamRecoder do). Decoding callbacks have a
> > different API. Which arguments should be passed to the
> > decoding callback, and what is the decoding callback
> > supposed to do?
>
> I'd suggest adding another set of PyCodec_UnicodeDecode...
()
> APIs for this. We'd then have to augment the base classes 
of
> the StreamCodecs to provide two attributes for .errors 
with
> a fallback solution for the string case (i.s. "strict" can
> still be used for both directions).

Sounds good. Now what is the decoding callback supposed to 
do?
I guess it will be called in the same way as the encoding
callback, i.e. with encoding name, original string and
position of the error. It might returns a Unicode string
(i.e. an object of the decoding target type), that will be
emitted from the codec instead of the one offending byte. Or
it might return a tuple with replacement Unicode object and
a resynchronisation offset, i.e. returning (u"?", 1) means
emit a '?' and skip the offending character. But to make
the offset really useful the callback has to know something
about the encoding, perhaps the codec should be allowed to
pass an additional state object to the callback?

Maybe the same should be added to the encoding callbacks to?
Maybe the encoding callback should be able to tell the
encoder if the replacement returned should be reencoded
(in which case it's a Unicode object), or directly emitted
(in which case it's an 8bit string)?

> > One additional note: It is vital that errors is an
> > assignable attribute of the StreamWriter.
>
> It is already !

I know, but IMHO it should be documented that an assignable
errors attribute must be supported as part of the official
codec API.

Misc/unicode.txt is not clear on that:
"""
It is not required by the Unicode implementation to use 
these base classes, only the interfaces must match; this 
allows writing Codecs as extension types.
"""

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-06-13 01:05

Message:
Logged In: YES 
user_id=38388

> How the callbacks work:
> 
> A PyObject * named errors is passed in. This may by NULL,
> Py_None, 'strict', u'strict', 'ignore', u'ignore',
> 'replace', u'replace' or a callable object.
> PyCodec_EncodeHandlerForObject maps all of these objects
to
> one of the three builtin error callbacks
> PyCodec_RaiseEncodeErrors (raises an exception),
> PyCodec_IgnoreEncodeErrors (returns an empty replacement
> string, in effect ignoring the error),
> PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode
> replacement character to signify to the encoder that it
> should choose a suitable replacement character) or
directly
> returns errors if it is a callable object. When an
> unencodable character is encounterd the error handling
> callback will be called with the encoding name, the
original
> unicode object and the error position and must return a
> unicode object that will be encoded instead of the
offending
> character (or the callback may of course raise an
> exception). U+FFFD characters in the replacement string
will
> be replaced with a character that the encoder chooses ('?'
> in all cases).

Nice.
 
> The implementation of the loop through the string is done
in
> the following way. A stack with two strings is kept and
the
> loop always encodes a character from the string at the
> stacktop. If an error is encountered and the stack has
only
> one entry (during encoding of the original string) the
> callback is called and the unicode object returned is
pushed
> on the stack, so the encoding continues with the
replacement
> string. If the stack has two entries when an error is
> encountered, the replacement string itself has an
> unencodable character and a normal exception raised. When
> the encoder has reached the end of it's current string
there
> are two possibilities: when the stack contains two
entries,
> this was the replacement string, so the replacement string
> will be poppep from the stack and encoding continues with
> the next character from the original string. If the stack
> had only one entry, encoding is finished.

Very elegant solution !
 
> (I hope that's enough explanation of the API and
implementation)

Could you add these docs to the Misc/unicode.txt file ? I
will eventually take that file and turn it into a PEP which
will then serve as general documentation for these things.
 
> I have renamed the static ...121 function to all lowercase
> names.

Ok.
 
> BTW, I guess PyUnicode_EncodeUnicodeEscape could be
> reimplemented as PyUnicode_EncodeASCII with a \uxxxx
> replacement callback.

Hmm, wouldn't that result in a slowdown ? If so, I'd rather
leave the special encoder in place, since it is being used a
lot in Python and probably some applications too.
 
> PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors,
> PyCodec_ReplaceEncodeErrors are globally visible because
> they have to be available in _codecsmodule.c to wrap them
as
> Python function objects, but they can't be implemented in
> _codecsmodule, because they need to be available to the
> encoders in unicodeobject.c (through
> PyCodec_EncodeHandlerForObject), but importing the codecs
> module might result in an endless recursion, because
> importing a module requires unpickling of the bytecode,
> which might require decoding utf8, which ... (but this
will
> only happen, if we implement the same mechanism for the
> decoding API)

I think that codecs.c is the right place for these APIs.
_codecsmodule.c is only meant as Python access wrapper for
the internal codecs and nothing more. 

One thing I noted about the callbacks: they assume that they
will always get Unicode objects as input. This is certainly
not true in the general case (it is for the codecs you touch
in the patch). 

I think it would be worthwhile to rename the callbacks to
include "Unicode" somewhere, e.g.
PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but
then it points out the application field of the callback
rather well. Same for the callbacks exposed through the
_codecsmodule.

> I have not touched PyUnicode_TranslateCharmap yet,
> should this function also support error callbacks? Why
would
> one want the insert None into the mapping to call the
callback?

1. Yes.
2. The user may want to e.g. restrict usage of certain
character ranges. In this case the codec would be used to
verify the input and an exception would indeed be useful
(e.g. say you want to restrict input to Hangul + ASCII).
 
> A remaining problem is how to implement decoding error
> callbacks. In Python 2.1 encoding and decoding errors are
> handled in the same way with a string value. But with
> callbacks it doesn't make sense to use the same callback
for
> encoding and decoding (like codecs.StreamReaderWriter and
> codecs.StreamRecoder do). Decoding callbacks have a
> different API. Which arguments should be passed to the
> decoding callback, and what is the decoding callback
> supposed to do?

I'd suggest adding another set of PyCodec_UnicodeDecode...()
APIs for this. We'd then have to augment the base classes of
the StreamCodecs to provide two attributes for .errors with
a fallback solution for the string case (i.s. "strict" can
still be used for both directions).

> One additional note: It is vital that errors is an
> assignable attribute of the StreamWriter.

It is already !
 
> Consider the XML example: For writing an XML DOM tree one
> StreamWriter object is used. When a text node is written,
> the error handling has to be set to
> codecs.xmlreplace_encode_errors, but inside a comment or
> processing instruction replacing unencodable characters
with
> charrefs is not possible, so here
codecs.raise_encode_errors
> should be used (or better a custom error handler that
raises
> an error that says "sorry, you can't have unencodable
> characters inside a comment")

Sure.
 
> BTW, should we continue the discussion in the i18n SIG
> mailing list? An email program is much more comfortable
than
> a HTML textarea! ;)

I'd rather keep the discussions on this patch here --
forking it off to the i18n sig will make it very hard to
follow up on it. (This HTML area is indeed damn small ;-)
 


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

Comment By: Walter Dörwald (doerwalter)
Date: 2001-06-12 12:18

Message:
Logged In: YES 
user_id=89016

One additional note: It is vital that errors is an
assignable attribute of the StreamWriter. 

Consider the XML example: For writing an XML DOM tree one
StreamWriter object is used. When a text node is written,
the error handling has to be set to
codecs.xmlreplace_encode_errors, but inside a comment or
processing instruction replacing unencodable characters with
charrefs is not possible, so here codecs.raise_encode_errors
should be used (or better a custom error handler that raises
an error that says "sorry, you can't have unencodable
characters inside a comment")

BTW, should we continue the discussion in the i18n SIG
mailing list? An email program is much more comfortable than
a HTML textarea! ;)



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

Comment By: Walter Dörwald (doerwalter)
Date: 2001-06-12 11:59

Message:
Logged In: YES 
user_id=89016

How the callbacks work:

A PyObject * named errors is passed in. This may by NULL,
Py_None, 'strict', u'strict', 'ignore', u'ignore',
'replace', u'replace' or a callable object.
PyCodec_EncodeHandlerForObject maps all of these objects to
one of the three builtin error callbacks
PyCodec_RaiseEncodeErrors (raises an exception),
PyCodec_IgnoreEncodeErrors (returns an empty replacement
string, in effect ignoring the error),
PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode
replacement character to signify to the encoder that it
should choose a suitable replacement character) or directly
returns errors if it is a callable object. When an
unencodable character is encounterd the error handling
callback will be called with the encoding name, the original
unicode object and the error position and must return a
unicode object that will be encoded instead of the offending
character (or the callback may of course raise an
exception). U+FFFD characters in the replacement string will 
be replaced with a character that the encoder chooses ('?'
in all cases).

The implementation of the loop through the string is done in
the following way. A stack with two strings is kept and the
loop always encodes a character from the string at the
stacktop. If an error is encountered and the stack has only
one entry (during encoding of the original string) the
callback is called and the unicode object returned is pushed
on the stack, so the encoding continues with the replacement
string. If the stack has two entries when an error is
encountered, the replacement string itself has an
unencodable character and a normal exception raised. When
the encoder has reached the end of it's current string there
are two possibilities: when the stack contains two entries,
this was the replacement string, so the replacement string
will be poppep from the stack and encoding continues with
the next character from the original string. If the stack
had only one entry, encoding is finished.

(I hope that's enough explanation of the API and implementation)

I have renamed the static ...121 function to all lowercase
names.

BTW, I guess PyUnicode_EncodeUnicodeEscape could be
reimplemented as PyUnicode_EncodeASCII with a \uxxxx
replacement callback.

PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors,
PyCodec_ReplaceEncodeErrors are globally visible because
they have to be available in _codecsmodule.c to wrap them as
Python function objects, but they can't be implemented in
_codecsmodule, because they need to be available to the
encoders in unicodeobject.c (through
PyCodec_EncodeHandlerForObject), but importing the codecs
module might result in an endless recursion, because
importing a module requires unpickling of the bytecode,
which might require decoding utf8, which ... (but this will
only happen, if we implement the same mechanism for the
decoding API)

I have not touched PyUnicode_TranslateCharmap yet, 
should this function also support error callbacks? Why would
one want the insert None into the mapping to call the callback?

A remaining problem is how to implement decoding error
callbacks. In Python 2.1 encoding and decoding errors are
handled in the same way with a string value. But with
callbacks it doesn't make sense to use the same callback for
encoding and decoding (like codecs.StreamReaderWriter and
codecs.StreamRecoder do). Decoding callbacks have a
different API. Which arguments should be passed to the
decoding callback, and what is the decoding callback
supposed to do?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-06-12 11:00

Message:
Logged In: YES 
user_id=38388

About the Py_UNICODE*data, int size APIs:
Ok, point taken.

In general, I think we ought to keep the callback feature as
open as possible, so passing in pointers and sizes would not
be very useful.

BTW, could you summarize how the callback works in a few
lines ?

About _Encode121: I'd name this _EncodeUCS1 since that's
what it is ;-)

About the new functions: I was referring to the new static
functions which you gave PyUnicode_... names. If these are
not supposed to turn into non-static functions, I'd rather
have them use lower case names (since that's how the Python
internals work too -- most of the times).



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

Comment By: Walter Dörwald (doerwalter)
Date: 2001-06-12 09:56

Message:
Logged In: YES 
user_id=89016

> One thing which I don't like about your API change is that
> you removed the Py_UNICODE*data, int size style arguments
> --
> this makes it impossible to use the new APIs on non-Python
> data or data which is not available as Unicode object.

Another problem is, that the callback requires a Python
object, so in the PyObject *version, the refcount is
incref'd and the object is passed to the callback. The
Py_UNICODE*/int version would have to create a new Unicode
object from the data.


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

Comment By: Walter Dörwald (doerwalter)
Date: 2001-06-12 09:32

Message:
Logged In: YES 
user_id=89016

> * please don't place more than one C statement on one line
> like in:
> """
> +               unicode = unicode2; unicodepos =
> unicode2pos;
> +               unicode2 = NULL; unicode2pos = 0;
> """

OK, done!

> * Comments should start with a capital letter and be
> prepended
> to the section they apply to

Fixed!

> * There should be spaces between arguments in compares
> (a == b) not (a==b)

Fixed!

> * Where does the name "...Encode121" originate ?

encode one-to-one, it implements both ASCII and latin-1
encoding.

> * module internal APIs should use lower case names (you
> converted some of these to  PyUnicode_...() -- this is
> normally reserved for APIs which are either marked as
> potential candidates for the public API or are very
> prominent in the code)

Which ones? I introduced a new function for every old one,
that had a "const char *errors" argument, and a few new ones
in codecs.h, of those PyCodec_EncodeHandlerForObject is
vital, because it is used to map for old string arguments to
the new function objects. PyCodec_RaiseEncodeErrors can be
used in the encoder implementation to raise an encode error,
but it could be made static in unicodeobject.h so only those
encoders implemented there have access to it.

> One thing which I don't like about your API change is that
> you removed the Py_UNICODE*data, int size style arguments > --
> this makes it impossible to use the new APIs on non-Python
> data or data which is not available as Unicode object.

I look through the code and found no situation where the
Py_UNICODE*/int version is really used and having two
(PyObject *)s (the original and the replacement string),
instead of UNICODE*/int and PyObject * made the
implementation a little easier, but I can fix that.

> Please separate the errors.c patch from this patch -- it
> seems totally unrelated to Unicode.

PyCodec_RaiseEncodeErrors uses this the have a \Uxxxx with
four hex digits. I removed it.

I'll upload a revised patch as soon as it's done.



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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-06-12 07:29

Message:
Logged In: YES 
user_id=38388

Thanks for the patch -- it looks very impressive !.

I'll give it a try later this week. 

Some first cosmetic tidbits:
* please don't place more than one C statement on one line
like in:
"""
+               unicode = unicode2; unicodepos =
unicode2pos;
+               unicode2 = NULL; unicode2pos = 0;
"""

* Comments should start with a capital letter and be
prepended
to the section they apply to

* There should be spaces between arguments in compares
(a == b) not (a==b)

* Where does the name "...Encode121" originate ?

* module internal APIs should use lower case names (you
converted some of these to  PyUnicode_...() -- this is
normally reserved for APIs which are either marked as
potential candidates for the public API or are very
prominent in the code)

One thing which I don't like about your API change is that
you removed the Py_UNICODE*data, int size style arguments --
this makes it impossible to use the new APIs on non-Python
data or data which is not available as Unicode object.

Please separate the errors.c patch from this patch -- it
seems totally unrelated to Unicode.

Thanks.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470


From noreply@sourceforge.net  Thu Jan 31 18:59:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Jan 2002 10:59:30 -0800
Subject: [Patches] [ python-Patches-415227 ] Solaris pkgtool bdist command
Message-ID: <E16WMQk-0004LB-00@usw-sf-web3.sourceforge.net>

Patches item #415227, was opened at 2001-04-10 12:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415227&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
>Priority: 5
Submitted By: Mark Alexander (mwa)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Solaris pkgtool bdist command

Initial Comment:
The bdist_pktool command is based on bdist_packager and
provides support for the Solaris
pkgadd and pkgrm commands. In most cases, no additional
options beyond the PEP 241 options are required. An 
exception is if the package name is >9 characters, a
--pkg-abrev option is required because that's all
pkgtool
will handle. It makes listing the packages on the
system
a pain, but the actual package files produced do match
name-version-revision-pyvers.pkg format. By default,
bdist_pkgtool provides request, postinstall, preremove,
and postremove scripts that will properly relocate
modules to the site-packages directory and recompile
all .py modules on the target machine. An author
can provide a custom request script and either have
it auto-relocate by merging the scripts, or inhibit
auto-relocation with --no-autorelocate.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-11-20 06:00

Message:
Logged In: YES 
user_id=38388

Hijacking this patch to take load off of Andrew. This patch should be reviewed after the Python 2.2 feature freeze.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-06-06 22:39

Message:
Logged In: YES 
user_id=21627

Should there also be some Makefile machinery to create a 
Solaris package for python itself? There is a 1.6a2 
package on sunfreeware; it would surely help if building 
Solaris packages was supported by the Python core itself.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415227&group_id=5470


From noreply@sourceforge.net  Thu Jan 31 18:59:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Jan 2002 10:59:42 -0800
Subject: [Patches] [ python-Patches-415228 ] HP-UX packaging command
Message-ID: <E16WMQw-0004LN-00@usw-sf-web3.sourceforge.net>

Patches item #415228, was opened at 2001-04-10 12:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415228&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
>Priority: 5
Submitted By: Mark Alexander (mwa)
Assigned to: M.-A. Lemburg (lemburg)
Summary: HP-UX packaging command

Initial Comment:
The bdist_sdux (SD-UX is HP's packager) command is
based on bdist_packager and provides the same
functionality
as the bdist_pkgtool command, except the resulting
packages
cannot auto-relocate. Instead, a checkinstall script
is included by default that determines of the target
machines python installation matches that of the 
creating machine. If not, it bails out and provides
the installer with the correct version of the swinstall
command to place it in the proper directory.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-11-20 06:01

Message:
Logged In: YES 
user_id=38388

Hijacking this patch to take load off of Andrew. This patch should be reviewed after the Python 2.2 feature freeze.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 14:18

Message:
Logged In: YES 
user_id=6380

Please select the proper category when submitting patches!

This is clearly a distutils thing.

Assigned to Andrew.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415228&group_id=5470


From noreply@sourceforge.net  Thu Jan 31 19:00:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Jan 2002 11:00:32 -0800
Subject: [Patches] [ python-Patches-485572 ] Distutils -- set runtime library path
Message-ID: <E16WMRk-0004Lx-00@usw-sf-web3.sourceforge.net>

Patches item #485572, was opened at 2001-11-26 04:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485572&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
>Priority: 5
Submitted By: Richard Everson (reverson)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Distutils -- set runtime library path

Initial Comment:
The runtime libraries option to Distutils Extension
currently fails with gcc (on Linux at least) because,
despite what "info gcc" says, 

gcc -R/run/time/lib/path  

doesn't get relayed to the loader to set the runtime
libraries search
path.  In order to correctly pass the -R to the loader
you need

gcc -Wl,-R/run/time/lib/path

There is something mentioning the -Wl, option in
cygwinccompiler.py but it is commented out.  The
attached patch works for me on a Linux or Solaris box,
but I haven't tested it more extensively than that. It
is against $Id: extension.py,v 1.8 2001/03/22 03:48:31
akuchling Exp $ from the python-2.1.1 distribution.

Also I'm not sure of the "correct" way of deducing what
compiler is
being used -- I hope the get_config_var() route is
acceptable.


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

Comment By: Richard Everson (reverson)
Date: 2001-11-26 05:43

Message:
Logged In: YES 
user_id=385419

Sorry about the lack of the patch -- I pressed submit too
soon.

It should now be attached.




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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-11-26 05:15

Message:
Logged In: YES 
user_id=38388

I'll look into this after the Python 2.2 feature freeze. Thanks.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-11-26 05:14

Message:
Logged In: YES 
user_id=38388

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=485572&group_id=5470


From noreply@sourceforge.net  Thu Jan 31 19:53:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Jan 2002 11:53:39 -0800
Subject: [Patches] [ python-Patches-511380 ] add CGIHTTPServer error supt for Win32
Message-ID: <E16WNH9-0001Gc-00@usw-sf-web1.sourceforge.net>

Patches item #511380, was opened at 2002-01-31 11:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511380&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Wesley J. Chun (wesc)
Assigned to: Nobody/Anonymous (nobody)
Summary: add CGIHTTPServer error supt for Win32

Initial Comment:
Patch suggestion for CGIHTTPServer.py in the Python 
Standard Library:

"add CGIHTTPServer error supt for Win32"
by Wesley J. Chun (wesc@rocketmail.com)

Python 2.2: Win32 and Unix (Solaris 2.8)

Description
===========
The CGIHTTPServer module uses the fork() mechanism 
provided by Unix
to run the CGI script, however, since the Win32 
platform does not
support fork(), CGIHTTPServer relies on os.popen2() to 
execute the
process and to retrieve the results.

This all works however, when you are debugging CGI 
applications, the
information provided by os.popen2() does not suffice 
because execution
errors (i.e., Python tracebacks) are sent to standard 
error, which are
ignored by os.popen2().

The suggested patch is to check first if os.popen3() 
is available to
us (otherwise do the normal check for os.popen2()).  
If we have access
to os.popen3(), use it instead and log any errors 
which appear via the
child's stderr.

Without the patch, it makes it much more difficult to 
debug the same
CGI application when run on Win32 because no errors 
are made apparent
in the error log.  Examples below -- first a 
successful call is made
(200), followed by a failed call due to a Python 
error, resulting in a
500 (ISE) appearing back on the web client.

The patch would bring the Win32 execution of 
CGIHTTPServer much closer
to its Unix counterpart.  A 3-line diff of the changes 
is available just
below the examples.  (This patch is valid for all 2.x 
releases and may
be backported to the 2.[012].x releases if necessary.)


Unix
====
** NO PATCH NEEDED **

# cgihttpd.py			# from CGIHTTPServer 
import test; test()
Serving HTTP on port 8000 ...
localhost - - [30/Jan/2002 10:13:20] "GET /cgi-
bin/rwrl.py?admin=1 HTTP/1.0" 200 -
Traceback (most recent call last):
  File "/home/wesc/public_html/cgi-bin/rwrl.py", line 
177, in ?
    main()
  File "/home/wesc/public_html/cgi-bin/rwrl.py", line 
153, in main
    cd = tag % ('date', title, 'date')
UnboundLocalError: local variable 'title' referenced 
before assignment
localhost - - [30/Jan/2002 10:13:20] CGI script exit 
status 0x100


Windoze
=======
** BEFORE PATCH **

C:\dev>python cgihttpd.py
Serving HTTP on 0.0.0.0 port 8000 ...
solo - - [30/Jan/2002 21:37:27] "GET /cgi-bin/rwrl.py?
admin=-1 HTTP/1.1" 200 -
solo - - [30/Jan/2002 21:37:27] command: c:\python22
\python.exe -u C:\dev\cgi-bin\rwrl.py
solo - - [30/Jan/2002 21:37:28] CGI script exit status 
0x1


** AFTER PATCH **

C:\dev>python cgihttpd.py
Serving HTTP on 0.0.0.0 port 8000 ...
solo - - [30/Jan/2002 21:46:22] "GET /cgi-bin/rwrl.py?
admin=-1 HTTP/1.1" 200 -
solo - - [30/Jan/2002 21:46:22] command: c:\python22
\python.exe -u C:\dev\cgi-bin\rwrl.py
solo - - [30/Jan/2002 21:46:23] Traceback (most recent 
call last):
  File "C:\dev\cgi-bin\rwrl.py", line 178, in ?
    main()
  File "C:\dev\cgi-bin\rwrl.py", line 160, in main
    cd = tag % ('date', title, 'date')
UnboundLocalError: local variable 'title' referenced 
before assignment

solo - - [30/Jan/2002 21:46:23] CGI script exit status 
0x1

DIFF -C3
========

% diff -C3 CGIHTTPServer.py.CVS CGIHTTPServer.py.new
*** CGIHTTPServer.py.CVS	Fri Oct 26 03:38:14 
2001 UTC
--- CGIHTTPServer.py.new	Thu Jan 31 10:58:16 
2002 PST
***************
*** 41,46 ****
--- 41,47 ----
      # Determine platform specifics
      have_fork = hasattr(os, 'fork')
      have_popen2 = hasattr(os, 'popen2')
+     have_popen3 = hasattr(os, 'popen3')
  
      # Make rfile unbuffered -- we need to read one 
line and then pass
      # the rest to a subprocess, so we can't use 
buffered input.
***************
*** 123,129 ****
              return
          ispy = self.is_python(scriptname)
          if not ispy:
!             if not (self.have_fork or 
self.have_popen2):
                  self.send_error(403, "CGI script is 
not a Python script (%s)" %
                                  `scriptname`)
                  return
--- 124,130 ----
              return
          ispy = self.is_python(scriptname)
          if not ispy:
!             if not (self.have_fork or 
self.have_popen2 or self.have_popen3):
                  self.send_error(403, "CGI script is 
not a Python script (%s)" %
                                  `scriptname`)
                  return
***************
*** 214,222 ****
                  self.server.handle_error
(self.request, self.client_address)
                  os._exit(127)
  
!         elif self.have_popen2:
!             # Windows -- use popen2 to create a 
subprocess
              import shutil
              os.environ.update(env)
              cmdline = scriptfile
              if self.is_python(scriptfile):
--- 215,227 ----
                  self.server.handle_error
(self.request, self.client_address)
                  os._exit(127)
  
!         elif self.have_popen3 or self.have_popen2:
!             # Windows -- use popen2 or popen3 to 
create a subprocess
              import shutil
+             if self.have_popen3:
+ 		cmd = os.popen3
+             else:
+ 		cmd = os.popen2
              os.environ.update(env)
              cmdline = scriptfile
              if self.is_python(scriptfile):
***************
*** 232,238 ****
                  nbytes = int(length)
              except:
                  nbytes = 0
!             fi, fo = os.popen2(cmdline, 'b')
              if self.command.lower() == "post" and 
nbytes > 0:
                  data = self.rfile.read(nbytes)
                  fi.write(data)
--- 237,247 ----
                  nbytes = int(length)
              except:
                  nbytes = 0
!             files = cmd(cmdline, 'b')
!             fi = files[0]
!             fo = files[1]
!             if self.have_popen3:
! 		fe = files[2]
              if self.command.lower() == "post" and 
nbytes > 0:
                  data = self.rfile.read(nbytes)
                  fi.write(data)
***************
*** 239,244 ****
--- 248,258 ----
              fi.close()
              shutil.copyfileobj(fo, self.wfile)
+             if self.have_popen3:
+ 		anyerr = fe.read()
+ 		fe.close()
+ 		if anyerr:
+ 		    self.log_error('%s', anyerr)
              sts = fo.close()
              if sts:
                  self.log_error("CGI script exit 
status %#x", sts)
              else:


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511380&group_id=5470


From noreply@sourceforge.net  Thu Jan 31 22:16:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 Jan 2002 14:16:33 -0800
Subject: [Patches] [ python-Patches-511449 ] PyBuffer_New double alignment bugfix
Message-ID: <E16WPVR-0003HF-00@usw-sf-web1.sourceforge.net>

Patches item #511449, was opened at 2002-01-31 14:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511449&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jay T Miller (jaytmiller)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyBuffer_New double alignment bugfix

Initial Comment:
PyBuffer_New performs a single malloc to allocate a
buffer object and its associated storage.  In
Python-2.2 the object is double aligned, but the
storage is not guaranteed to be double aligned.  See
bug #472568 by Frederic Giacometti.

This patch adds a padding double to the buffer object
and code which truncates the storage pointer to a
double aligned boundary within the padding.  Frederic's
original suggestion was cleaner, but appeared to
require an extra compiler switch to get double
alignment for gcc i386.   Since the info page for gcc
-malign-double warns: 

*Warning:* if you use the `-malign-double' switch,
structures containing the above types will be aligned
differently than the published application binary
interface specifications for the 386.

I figured the switch was a bad idea,  so I used
truncating division instead of Frederic's clean pointer
trick.


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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511449&group_id=5470