[Python-Dev] Error building 3.0 on OS-X
I have been updating the 3.0 source using bzr and after my latest bzr pull I get an error on make install. I'm running 10.5.3. ./configure --enable-framework make make install ... running install_egg_info Writing /Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib-dynload/Python-3.0a5_-py3.0.egg-info ln -fs "../../../Python" "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/config/libpython3.0.a" cd Mac && make installmacsubtree DESTDIR="" DYLD_FRAMEWORK_PATH=/Users/bmiller/src/python/3.0: ../python.exe ./scripts/cachersrc.py -v /Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/plat-mac /Library/Frameworks/Python.framework/Versions/3.0/Mac/Tools ../python.exe: can't open file './scripts/cachersrc.py': [Errno 2] No such file or directory make[1]: *** [installmacsubtree] Error 2 make: *** [frameworkinstallmaclib] Error 2 Any hints? Thanks, Brad ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Blow your mind
2008/6/16 Barry Warsaw <[EMAIL PROTECTED]>: > A colleague just forward this to me and it blew my fscking mind to > smithereens. It also brings back a lot of memories. Enjoy! Wow! One thing that surprised me was that I never saw Tim appear... Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Epoch and Platform
Any chance of an Official Pronouncement on this topic? It would help us greatly -- even if only to figure out who'll be paying for the next round of beer. On Mon, Jun 16, 2008 at 4:38 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > ISTR that we force the epoch to be 1970 on all major platforms -- or > perhaps it happens to be 1970 even on Windows when using MS's C > runtime. > > On Mon, Jun 16, 2008 at 4:08 PM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote: >> The documentation for the time module says that "the epoch is the point >> where the time starts. On January 1st of that year, at 0 hours, the ``time >> since the epoch'' is zero. For Unix, the epoch is 1970. To find out what the >> epoch is, look at gmtime(0)." This confirms that the epoch is >> platform-specific. As such, the only legal uses of the timestamp should be >> >> 1) comparing with another timestamp to determine elapsed time in seconds >> 2) passing to another standard Python library function which expects a >> timestamp >> 3) as a source of randomness. >> >> However, the following files in the standard library have hardcoded the >> assumption that the Python epoch will always be the same as the Unix epoch: >> In gzip.py, method GzipFile._write_gzip_header >> In tarfile.py, method _Stream._init_write_gz >> In uuid.py, function uuid1 >> >> Additionally, the following files in the standard library have hardcoded the >> assumption that the Python epoch will cause timestamps to fall within the >> range of a 32-bit unsigned integer value: >> In imputil.py, function _compile >> In py_compile.py, function compile >> >> So there's some kind of a potential discrepancy here, albeit a minor one. >> This discrepancy can be resolved in one of at least three ways: >> >> 1) The documentation for the time module is wrong, and the epoch for Python >> (at least versions 2.x) should be the Unix epoch. >> 2) These library functions are slightly wrong and should be modified by >> subtracing an "epoch offset" before doing other calculations. This offset >> can be calculated as "time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - >> time.timezone". >> 3) These library files should be considered part of the platform-specific >> implementation, and an alternate platform should provide its own version of >> these files if necessary. >> >> Any thoughts on this? >> >> From the perspective of implementing IronPython, I'd prefer that the answer >> is 1 or 2 -- but mainly I just want to be as compatible with "the spec" as >> possible, while respecting CLR-specific norms for functionality which is >> left up to individual implementations. >> >> -- >> Curt Hagenlocher >> [EMAIL PROTECTED] >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/guido%40python.org >> >> > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Blow your mind
On Tue, Jun 17, 2008 at 8:54 AM, Paul Moore <[EMAIL PROTECTED]> wrote: > 2008/6/16 Barry Warsaw <[EMAIL PROTECTED]>: >> A colleague just forward this to me and it blew my fscking mind to >> smithereens. It also brings back a lot of memories. Enjoy! > > Wow! > > One thing that surprised me was that I never saw Tim appear... > Paul. He wasn't able to contribute while we were at CNRI (I did the checkins for him) and once we were at SourceForge there were so many people that it was hard to find anyone in particular. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Epoch and Platform
Can you explain why you are so anxious to get this resolved (apart from the beer :-) ? On Tue, Jun 17, 2008 at 9:26 AM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote: > Any chance of an Official Pronouncement on this topic? It would help > us greatly -- even if only to figure out who'll be paying for the next > round of beer. > > On Mon, Jun 16, 2008 at 4:38 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> ISTR that we force the epoch to be 1970 on all major platforms -- or >> perhaps it happens to be 1970 even on Windows when using MS's C >> runtime. >> >> On Mon, Jun 16, 2008 at 4:08 PM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote: >>> The documentation for the time module says that "the epoch is the point >>> where the time starts. On January 1st of that year, at 0 hours, the ``time >>> since the epoch'' is zero. For Unix, the epoch is 1970. To find out what the >>> epoch is, look at gmtime(0)." This confirms that the epoch is >>> platform-specific. As such, the only legal uses of the timestamp should be >>> >>> 1) comparing with another timestamp to determine elapsed time in seconds >>> 2) passing to another standard Python library function which expects a >>> timestamp >>> 3) as a source of randomness. >>> >>> However, the following files in the standard library have hardcoded the >>> assumption that the Python epoch will always be the same as the Unix epoch: >>> In gzip.py, method GzipFile._write_gzip_header >>> In tarfile.py, method _Stream._init_write_gz >>> In uuid.py, function uuid1 >>> >>> Additionally, the following files in the standard library have hardcoded the >>> assumption that the Python epoch will cause timestamps to fall within the >>> range of a 32-bit unsigned integer value: >>> In imputil.py, function _compile >>> In py_compile.py, function compile >>> >>> So there's some kind of a potential discrepancy here, albeit a minor one. >>> This discrepancy can be resolved in one of at least three ways: >>> >>> 1) The documentation for the time module is wrong, and the epoch for Python >>> (at least versions 2.x) should be the Unix epoch. >>> 2) These library functions are slightly wrong and should be modified by >>> subtracing an "epoch offset" before doing other calculations. This offset >>> can be calculated as "time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - >>> time.timezone". >>> 3) These library files should be considered part of the platform-specific >>> implementation, and an alternate platform should provide its own version of >>> these files if necessary. >>> >>> Any thoughts on this? >>> >>> From the perspective of implementing IronPython, I'd prefer that the answer >>> is 1 or 2 -- but mainly I just want to be as compatible with "the spec" as >>> possible, while respecting CLR-specific norms for functionality which is >>> left up to individual implementations. >>> >>> -- >>> Curt Hagenlocher >>> [EMAIL PROTECTED] >>> ___ >>> Python-Dev mailing list >>> Python-Dev@python.org >>> http://mail.python.org/mailman/listinfo/python-dev >>> Unsubscribe: >>> http://mail.python.org/mailman/options/python-dev/guido%40python.org >>> >>> >> >> >> >> -- >> --Guido van Rossum (home page: http://www.python.org/~guido/) >> > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Epoch and Platform
On Mon, Jun 16, 2008 at 6:38 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > ISTR that we force the epoch to be 1970 on all major platforms -- or > perhaps it happens to be 1970 even on Windows when using MS's C > runtime. I can confirm that Python under Windows does indeed use the Unix epoch: Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> time.gmtime(0) (1970, 1, 1, 0, 0, 0, 3, 1, 0) -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Epoch and Platform
ISTR using a Microsoft C compiler in the early/mid 1990s whose runtime library used an unusual epoch. I don't recall any others straying from the Unix way, but then again, I haven't been looking for such quirks. Guido wrote: > > ISTR that we force the epoch to be 1970 on all major platforms -- or > perhaps it happens to be 1970 even on Windows when using MS's C > runtime. > > On Mon, Jun 16, 2008 at 4:08 PM, Curt Hagenlocher <[EMAIL PROTECTED]> > wrote: >> The documentation for the time module says that "the epoch is the point >> where the time starts. On January 1st of that year, at 0 hours, the >> ``time >> since the epoch'' is zero. For Unix, the epoch is 1970. To find out what >> the >> epoch is, look at gmtime(0)." This confirms that the epoch is >> platform-specific. As such, the only legal uses of the timestamp should >> be >> >> 1) comparing with another timestamp to determine elapsed time in seconds >> 2) passing to another standard Python library function which expects a >> timestamp >> 3) as a source of randomness. >> >> However, the following files in the standard library have hardcoded the >> assumption that the Python epoch will always be the same as the Unix >> epoch: >> In gzip.py, method GzipFile._write_gzip_header >> In tarfile.py, method _Stream._init_write_gz >> In uuid.py, function uuid1 >> >> Additionally, the following files in the standard library have hardcoded >> the >> assumption that the Python epoch will cause timestamps to fall within >> the >> range of a 32-bit unsigned integer value: >> In imputil.py, function _compile >> In py_compile.py, function compile >> >> So there's some kind of a potential discrepancy here, albeit a minor >> one. >> This discrepancy can be resolved in one of at least three ways: >> >> 1) The documentation for the time module is wrong, and the epoch for >> Python >> (at least versions 2.x) should be the Unix epoch. >> 2) These library functions are slightly wrong and should be modified by >> subtracing an "epoch offset" before doing other calculations. This >> offset >> can be calculated as "time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - >> time.timezone". >> 3) These library files should be considered part of the >> platform-specific >> implementation, and an alternate platform should provide its own version >> of >> these files if necessary. >> >> Any thoughts on this? >> >> From the perspective of implementing IronPython, I'd prefer that the >> answer >> is 1 or 2 -- but mainly I just want to be as compatible with "the spec" >> as >> possible, while respecting CLR-specific norms for functionality which is >> left up to individual implementations. >> >> -- >> Curt Hagenlocher >> [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Epoch and Platform
I don't *feel* anxious, but my doctor *has* been trying to persuade me to switch to decaf... There's no real urgency. The reason this came up is because I just implemented zlib, which automatically enabled the gzip unit tests. The gzip tests are failing because the current timestamp can't be written as a 32-bit value. In order to checkin my changes, I can't have any failing tests -- so my choices are 1) change the IronPython epoch so that the timestamp works for gzip and tarlib 2) change gzip and tarlib to work with a "less standard" epoch, or 3) disable the failing test(s) ...and I'd rather not resort to #3, if possible. On Tue, Jun 17, 2008 at 10:03 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Can you explain why you are so anxious to get this resolved (apart > from the beer :-) ? > > On Tue, Jun 17, 2008 at 9:26 AM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote: >> Any chance of an Official Pronouncement on this topic? It would help >> us greatly -- even if only to figure out who'll be paying for the next >> round of beer. >> >> On Mon, Jun 16, 2008 at 4:38 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >>> ISTR that we force the epoch to be 1970 on all major platforms -- or >>> perhaps it happens to be 1970 even on Windows when using MS's C >>> runtime. >>> >>> On Mon, Jun 16, 2008 at 4:08 PM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote: The documentation for the time module says that "the epoch is the point where the time starts. On January 1st of that year, at 0 hours, the ``time since the epoch'' is zero. For Unix, the epoch is 1970. To find out what the epoch is, look at gmtime(0)." This confirms that the epoch is platform-specific. As such, the only legal uses of the timestamp should be 1) comparing with another timestamp to determine elapsed time in seconds 2) passing to another standard Python library function which expects a timestamp 3) as a source of randomness. However, the following files in the standard library have hardcoded the assumption that the Python epoch will always be the same as the Unix epoch: In gzip.py, method GzipFile._write_gzip_header In tarfile.py, method _Stream._init_write_gz In uuid.py, function uuid1 Additionally, the following files in the standard library have hardcoded the assumption that the Python epoch will cause timestamps to fall within the range of a 32-bit unsigned integer value: In imputil.py, function _compile In py_compile.py, function compile So there's some kind of a potential discrepancy here, albeit a minor one. This discrepancy can be resolved in one of at least three ways: 1) The documentation for the time module is wrong, and the epoch for Python (at least versions 2.x) should be the Unix epoch. 2) These library functions are slightly wrong and should be modified by subtracing an "epoch offset" before doing other calculations. This offset can be calculated as "time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - time.timezone". 3) These library files should be considered part of the platform-specific implementation, and an alternate platform should provide its own version of these files if necessary. Any thoughts on this? From the perspective of implementing IronPython, I'd prefer that the answer is 1 or 2 -- but mainly I just want to be as compatible with "the spec" as possible, while respecting CLR-specific norms for functionality which is left up to individual implementations. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org >>> >>> >>> >>> -- >>> --Guido van Rossum (home page: http://www.python.org/~guido/) >>> >> > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Error building python3.0 under OS X
I have been updating the 3.0 source using bzr and after my latest bzr pull I get an error on make install. I'm running 10.5.3. ./configure --enable-framework make make install ... running install_egg_info Writing /Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/lib-dynload/Python-3.0a5_-py3.0.egg-info ln -fs "../../../Python" "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/config/libpython3.0.a" cd Mac && make installmacsubtree DESTDIR="" DYLD_FRAMEWORK_PATH=/Users/bmiller/src/python/3.0: ../python.exe ./scripts/cachersrc.py -v /Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/plat-mac /Library/Frameworks/Python.framework/Versions/3.0/Mac/Tools ../python.exe: can't open file './scripts/cachersrc.py': [Errno 2] No such file or directory make[1]: *** [installmacsubtree] Error 2 make: *** [frameworkinstallmaclib] Error 2 Any hints? Thanks, Brad ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Epoch and Platform
On Tue, Jun 17, 2008 at 10:40 AM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote: > I don't *feel* anxious, but my doctor *has* been trying to persuade me > to switch to decaf... > > There's no real urgency. The reason this came up is because I just > implemented zlib, which automatically enabled the gzip unit tests. > The gzip tests are failing because the current timestamp can't be > written as a 32-bit value. Why is that? Is it because your epoch is different? If so, I would much prefer the epoch to be 1970. (Maybe this is the resolution you're seeking?) > In order to checkin my changes, I can't > have any failing tests -- so my choices are > > 1) change the IronPython epoch so that the timestamp works for gzip and tarlib > 2) change gzip and tarlib to work with a "less standard" epoch, or > 3) disable the failing test(s) > > ...and I'd rather not resort to #3, if possible. > > On Tue, Jun 17, 2008 at 10:03 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> Can you explain why you are so anxious to get this resolved (apart >> from the beer :-) ? >> >> On Tue, Jun 17, 2008 at 9:26 AM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote: >>> Any chance of an Official Pronouncement on this topic? It would help >>> us greatly -- even if only to figure out who'll be paying for the next >>> round of beer. >>> >>> On Mon, Jun 16, 2008 at 4:38 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: ISTR that we force the epoch to be 1970 on all major platforms -- or perhaps it happens to be 1970 even on Windows when using MS's C runtime. On Mon, Jun 16, 2008 at 4:08 PM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote: > The documentation for the time module says that "the epoch is the point > where the time starts. On January 1st of that year, at 0 hours, the ``time > since the epoch'' is zero. For Unix, the epoch is 1970. To find out what > the > epoch is, look at gmtime(0)." This confirms that the epoch is > platform-specific. As such, the only legal uses of the timestamp should > be > > 1) comparing with another timestamp to determine elapsed time in seconds > 2) passing to another standard Python library function which expects a > timestamp > 3) as a source of randomness. > > However, the following files in the standard library have hardcoded the > assumption that the Python epoch will always be the same as the Unix > epoch: > In gzip.py, method GzipFile._write_gzip_header > In tarfile.py, method _Stream._init_write_gz > In uuid.py, function uuid1 > > Additionally, the following files in the standard library have hardcoded > the > assumption that the Python epoch will cause timestamps to fall within the > range of a 32-bit unsigned integer value: > In imputil.py, function _compile > In py_compile.py, function compile > > So there's some kind of a potential discrepancy here, albeit a minor one. > This discrepancy can be resolved in one of at least three ways: > > 1) The documentation for the time module is wrong, and the epoch for > Python > (at least versions 2.x) should be the Unix epoch. > 2) These library functions are slightly wrong and should be modified by > subtracing an "epoch offset" before doing other calculations. This offset > can be calculated as "time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - > time.timezone". > 3) These library files should be considered part of the platform-specific > implementation, and an alternate platform should provide its own version > of > these files if necessary. > > Any thoughts on this? > > From the perspective of implementing IronPython, I'd prefer that the > answer > is 1 or 2 -- but mainly I just want to be as compatible with "the spec" as > possible, while respecting CLR-specific norms for functionality which is > left up to individual implementations. > > -- > Curt Hagenlocher > [EMAIL PROTECTED] > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) >>> >> >> >> >> -- >> --Guido van Rossum (home page: http://www.python.org/~guido/) >> > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Epoch and Platform
On Tue, Jun 17, 2008 at 10:56 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Tue, Jun 17, 2008 at 10:40 AM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote: >> >> There's no real urgency. The reason this came up is because I just >> implemented zlib, which automatically enabled the gzip unit tests. >> The gzip tests are failing because the current timestamp can't be >> written as a 32-bit value. > > Why is that? Is it because your epoch is different? If so, I would > much prefer the epoch to be 1970. (Maybe this is the resolution you're > seeking?) Yes! Except that I was hoping for something a little stronger, like "the epoch must be 1970" or "the epoch can be anything you want, but you're utterly retarded if you pick something other than 1970". But I'll definitely settle for "much prefer". :) Thanks, -Curt -- Curt Hagenlocher [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Epoch and Platform
On Tue, Jun 17, 2008 at 11:09 AM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote: > On Tue, Jun 17, 2008 at 10:56 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> On Tue, Jun 17, 2008 at 10:40 AM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote: >>> >>> There's no real urgency. The reason this came up is because I just >>> implemented zlib, which automatically enabled the gzip unit tests. >>> The gzip tests are failing because the current timestamp can't be >>> written as a 32-bit value. >> >> Why is that? Is it because your epoch is different? If so, I would >> much prefer the epoch to be 1970. (Maybe this is the resolution you're >> seeking?) > > Yes! Except that I was hoping for something a little stronger, like > "the epoch must be 1970" or "the epoch can be anything you want, but > you're utterly retarded if you pick something other than 1970". But > I'll definitely settle for "much prefer". :) I could go with the "utterly retarded" wording. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Merging changes before beta
Hello, I am in the process of merging changes from trunk to the py3k branch. (If somebody else is already doing it, please tell me quickly!) IMO it would be better to have the beta versions in sync; the 2.6->3.0 migration should not be a regression! I will integrate the changes that are either simple, or that I can understand, or have unit tests. The changes I will skip are (for the moment): - r64114 (gregory.p.smith): a bunch of checks for integer overflows, contributed by Google. This change has many conflicts, I will do it later. - r63828 (mark.hammond): Fix bdist_wininst --user-access-control for win2k For this it is necessary to recompile the various wininst-*.exe, and not all my compilers have the necessary headers or libraries. - r63955 (ronald.oussoren): MacOS X: Enable 4-way universal builds I may try the merge, but without any way to test the result. OTOH, I could go and trust the buildbots. - 64062,64068-64069,64080 (josiah.carlson): Asynchat I may give a try, but it will be tricky. And I don't even know how asynchat works (I just remember it was hard to get it right for python 3.0) - 63207,63210,63218,63403,63469,63537,63597-63598,63601,63604,63617-63618, 63714,63718,63742,63745,63799 (jesus.cea, gregory.p.smith): bsddb module This is a important list of changes, and may require heavy adaptations to the code. issue2887 has been filed for this task. Do you think these tasks should be considered as Release Blockers? Beta1 is close... -- Amaury Forgeot d'Arc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Merging changes before beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 17, 2008, at 3:44 PM, Amaury Forgeot d'Arc wrote: I am in the process of merging changes from trunk to the py3k branch. (If somebody else is already doing it, please tell me quickly!) BTW, I will be hanging out on #python-dev @ freenode from now until tomorrow night, so if you have questions feel free to ping me. My userid is 'barry' (so creative ) and I keep generally UTC-0400 time. The changes I will skip are (for the moment): - r64114 (gregory.p.smith): a bunch of checks for integer overflows, contributed by Google. This change has many conflicts, I will do it later. Not a blocker. - r63828 (mark.hammond): Fix bdist_wininst --user-access-control for win2k For this it is necessary to recompile the various wininst-*.exe, and not all my compilers have the necessary headers or libraries. Not a blocker. - r63955 (ronald.oussoren): MacOS X: Enable 4-way universal builds I may try the merge, but without any way to test the result. OTOH, I could go and trust the buildbots. Only if you're prepared to back it out if they go red. Not a blocker. - 64062,64068-64069,64080 (josiah.carlson): Asynchat I may give a try, but it will be tricky. And I don't even know how asynchat works (I just remember it was hard to get it right for python 3.0) Hmm. I don't know the details of these. - 63207,63210,63218,63403,63469,63537,63597 -63598,63601,63604,63617-63618, 63714,63718,63742,63745,63799 (jesus.cea, gregory.p.smith): bsddb module This is a important list of changes, and may require heavy adaptations to the code. issue2887 has been filed for this task. Not a blocker. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFgXs3EjvBPtnXfVAQJdiQP8CIahHlmiwep5ljm0gakwYzEI7LJ1e7+0 5HXNqClrhntIP+wjR8BPR9oNTp04D0Y35v8ZZcZDh0t/2LtboP6fySO4eVmYcoma p5/Ld6xPoaSRfy15jVb9xKx4AsegKNZlOdJWpZs9+jkYK5x5mcflns0Nn4KoRKwS r3ExyMj5YIQ= =liS1 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Progress on switching Windows build to Berkeley DB 4.7.25...
Hi all, Jesus, apologies that this has taken so long for me to get back to, I've been completely and utterly swamped with client work the past few weeks. However, thanks to a couple of hours spare at Detroit airport yesterday, I was finally able to make some progress on updating the Windows Berkeley DB build to 4.7.25. I've checked in the work I've done so far to branches/tnelson-trunk-bsddb-47-upgrade. One thing I wanted to double check with you is the following change: Modified: python/branches/tnelson-trunk-bsddb-47-upgrade/Lib/bsddb/test/test_replication.py == --- python/branches/tnelson-trunk-bsddb-47-upgrade/Lib/bsddb/test/test_replication.py (original) +++ python/branches/tnelson-trunk-bsddb-47-upgrade/Lib/bsddb/test/test_replication.py Wed Jun 18 06:13:44 2008 @@ -94,7 +94,7 @@ # The timeout is necessary in BDB 4.5, since DB_EVENT_REP_STARTUPDONE # is not generated if the master has no new transactions. # This is solved in BDB 4.6 (#15542). -timeout = time.time()+2 +timeout = time.time()+10 while (time.time()= (4,6) : Basically, when using +2, the test failed every so often when running the entire test_bsddb3 suite. I picked 10 arbitrarily; it improves things, but it's still not 100%, I still encounter the following failure every so often: == ERROR: test01_basic_replication (bsddb.test.test_replication.DBReplicationManager) -- Traceback (most recent call last): File "s:[EMAIL PROTECTED]", line 101, in setUp self.assertTrue(time.time()http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
