Martin v. Löwis schrieb:
>> I suggest to apply this patch, which sets an environment variable in the
>> Tools\buildbot\test.bat script, detects the Windows debug build, and calls
>> SetErrorMode(7) as David suggested:
>
> Sounds fine with me - although I would leave out the test for debug
> build,
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Are you saying that calling SetErrorMode also makes the VC _ASSERT
> message boxes go away?
I don't believe it should, no. The assert message boxes are from the VC
runtime, whereas the OS error dialogs are from, well, the OS :-)
Certainly in my ma
> I suggest to apply this patch, which sets an environment variable in the
> Tools\buildbot\test.bat script, detects the Windows debug build, and calls
> SetErrorMode(7) as David suggested:
Sounds fine with me - although I would leave out the test for debug
build, and just check the environment va
Thomas Heller schrieb:
>
> I suggest to apply this patch, which sets an environment variable in the
> Tools\buildbot\test.bat script, detects the Windows debug build, and calls
> SetErrorMode(7) as David suggested:
If noone objects, I would like to apply this patch first, see if it avoids
the tes
David Bolen schrieb:
> David Bolen <[EMAIL PROTECTED]> writes:
>
>> "Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>>
These messageboxes of course hang the tests on the windows build servers,
so probably it would be good if they could be disabled completely.
>>>
>>> I think this will be v
> Can someone familiar with building Py3k on Windows add a section on
> how to build it on Windows to the new README?
Done, by pointing to PCbuild/readme.txt.
Regards,
Martin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/ma
On 8/29/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Aug 29, 2007, at 11:28 PM, Guido van Rossum wrote:
> > No, I don't think I can recover the changes. Would it work to just
> > copy the files over from the sandbox, forcing Lib/email in the py3k
> > branch to be identical to emailpkg/5_0-exp/e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 29, 2007, at 11:28 PM, Guido van Rossum wrote:
> No, I don't think I can recover the changes. Would it work to just
> copy the files over from the sandbox, forcing Lib/email in the py3k
> branch to be identical to emailpkg/5_0-exp/email in the
No, I don't think I can recover the changes. Would it work to just
copy the files over from the sandbox, forcing Lib/email in the py3k
branch to be identical to emailpkg/5_0-exp/email in the sandbox?
On 8/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/29/07, Barry Warsaw <[EMAIL PROTECT
On 8/29/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> Guido, do you remember which revision from the sandbox you merged/
> copied? It looks like it was missing some stuff I committed last
> night. If you know which revision you merged it'll make it easy for
> me to copy the latest stuff over. Sa
In preparation of the release Friday, I put the email package back,
from Barry's sandbox.
This breaks a few things. Please help clean these up!
Also a few things were disabled to cope with its temporary demise. If
you remember doing one of these, please undo them!
--
--Guido van Rossum (home pa
On Aug 29, 2007, at 10:19 PM, [EMAIL PROTECTED] wrote:
> You can achieve these sorts of effects by assigning an object to
> sys.modules[modulename].
Only for imports that haven't happened yet, which tends to be fragile.
-Fred
--
Fred Drake
_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 29, 2007, at 10:02 PM, Guido van Rossum wrote:
> Great! The more you can fix up by Friday the better, but I figured
> it's better to have a little lead time so we can fix up other things
> depending on it, and have a little test time.
Guido, d
skip> You can achieve these sorts of effects by assigning an object to
skip> sys.modules[modulename].
I forgot you should always be able to assign to the module's __dict__
attribute as well:
>>> import os
>>> os.__dict__['foo'] = 'a'
>>> os.foo
'a'
S
Collin> When thinking about these kinds of optimizations and
Collin> restrictions, keep in mind their effect on testing. For example,
Collin> I work on code that makes use of the ability to tinker with
Collin> another module's view of os.path in order to simulate error
Collin>
Great! The more you can fix up by Friday the better, but I figured
it's better to have a little lead time so we can fix up other things
depending on it, and have a little test time.
On 8/29/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Aug 29,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 29, 2007, at 9:15 PM, guido.van.rossum wrote:
> Author: guido.van.rossum
> Date: Thu Aug 30 03:15:14 2007
> New Revision: 57691
>
> Added:
>python/branches/py3k/Lib/email/
> - copied from r57592, sandbox/trunk/emailpkg/5_0-exp/email/
I'm inclined to let this one wait for 3.0a2, I'm out of python time for the
week and will be out of town (but online) until next Thursday. Pairing up to
finish it later on would be nice if needed. I'm happy if the immutable
support is dropped, I just figured I'd include it as an example once I
rea
On 8/29/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
> Am I the only one seeing a refleak in test_io?
I know of leaks in 4 modules, but they all may point to the same one
you identified:
test_io leaked [62, 62] references, sum=124
test_urllib leaked [122, 122] references, sum=244
test_urllib2_
That's a huge patch to land so close before a release. I'm not sure I
like the immutability API -- it won't be useful unless we add a hash
method, and then we have all sorts of difficulties again -- the
distinction between a hashable and an unhashable object should be made
by type, not by value (tu
Am I the only one seeing a refleak in test_io?
timberwolf:~/python/python/py3k > ./python -E -tt Lib/test/regrtest.py -R::
test_io
test_io
beginning 9 repetitions
123456789
.
test_io leaked [62, 62, 62, 62] references, sum=248
1 test OK.
It's in this particular piece of code:
def tes
Attached is what I've come up with so far. Only a single field is
added to the PyBytesObject struct. This adds support to the bytes
object for PyBUF_LOCKDATA buffer API operation. bytes objects can be
marked temporarily read-only for use while the buffer api has handed
them off to something whic
On 8/29/07, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Neal Norwitz]
> > ...
> > We have 4 windows buildbots IIRC, but 2 are offline and there are
> > various problems. Given all the slight variations of Windows, I
> > think it would be good to get another Windows bot.
>
> FYI, my bot is offline now
[Neal Norwitz]
> ...
> We have 4 windows buildbots IIRC, but 2 are offline and there are
> various problems. Given all the slight variations of Windows, I
> think it would be good to get another Windows bot.
FYI, my bot is offline now just because I'm having major HW problems
(endless spontaneous
Can someone familiar with building Py3k on Windows add a section on
how to build it on Windows to the new README? (Do a svn up first; I've
rewritten most of it.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 mailing li
On 8/29/07, David Bolen <[EMAIL PROTECTED]> wrote:
>
> There's an offer of mine to host an additional Windows (win32)
> buildbot, for whatever versions are helpful, in the moderator queue
> for python-dev.
Hmm, that's odd.
> Although in looking at the current 3.0 buildbot
> status page there woul
On 8/29/07, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> I see additional errors like "can't use str as char buffer". I suppose
> it is because of the recent stricter distinction between bytes and
> str.
Indeed. It typically means that something is using
PyObject_AsCharBuffer() instead of PyU
"Amaury Forgeot d'Arc" <[EMAIL PROTECTED]> writes:
> Note that there is currently only one Windows buildbot to watch - and
> it is a win64. Most tests that fail there pass on my machine.
> Nevertheless, the log is much smaller than before.
There's an offer of mine to host an additional Windows (w
2007/8/29, Guido van Rossum <[EMAIL PROTECTED]>:
> I've checked all those in except the change that prevents closing fds
> 0, 1, 2. Watch the buildbots, I have no Windows access myself.
Oops, the 0,1,2 fds stuff was not supposed to leave my workspace. I
agree that it should be done differently.
N
On 8/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > If I
> > remember correctly the error mode is inherited, so an independent
> > small exec module could reset the mode, and execute the normal test
> > sequence as a child process.
>
> It would also be possible to put that into the interpr
>>> These messageboxes of course hang the tests on the windows build servers,
>>> so probably it would be good if they could be disabled completely.
>> I think this will be very difficult to achieve.
>
> Could the tests be run beneath a shim process that used SetErrorMode()
> to disable all the OS
On 8/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
[snip]
> I certainly wasn't expecting something to be available for review now or in
> the near future. I was actually mostly thinking about language syntax and
> semantics when I started writing that email. I think those are more likely
>
David Bolen <[EMAIL PROTECTED]> writes:
> "Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>
>>> These messageboxes of course hang the tests on the windows build servers,
>>> so probably it would be good if they could be disabled completely.
>>
>> I think this will be very difficult to achieve.
>
> C
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>> These messageboxes of course hang the tests on the windows build servers,
>> so probably it would be good if they could be disabled completely.
>
> I think this will be very difficult to achieve.
Could the tests be run beneath a shim process that u
I've checked all those in except the change that prevents closing fds
0, 1, 2. Watch the buildbots, I have no Windows access myself.
On 8/29/07, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I recently created patches that correct some problems in py3k on Windows.
> They are:
>
> -
> If I insert these statements into Modules\posixmodule.c:
>
> _CrtSetReportMode(_CRT_WARN, _CRTDBG_MODE_FILE);
> _CrtSetReportFile(_CRT_WARN, _CRTDBG_FILE_STDERR);
> _CrtSetReportMode(_CRT_ERROR, _CRTDBG_MODE_FILE);
> _CrtSetReportFile(_CRT_ERROR, _CRTDBG_FILE_STDERR);
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 28, 2007, at 11:21 AM, Guido van Rossum wrote:
>> Nope. So what would bytes(s) do?
>
> Raise TypeError (when s is a str). The argument to bytes() must be
> either an int (then it creates a zero-filled bytes bytes array of that
> length) or an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 29, 2007, at 1:31 PM, Jeremy Hylton wrote:
> I made a local change to my bytesobject.c to raise an exception
> whenever it is compared to a PyUnicode_Object.
+1. I hit several silent errors in the email package because of
this. A TypeError
>> Is Python 3 likely to change in any way so as to make future
>> performance optimization work more fruitful?
Martin> In particular, people have repeatedly requested that the GIL be
Martin> removed for Python 3. There is nothing remotely resembling a
Martin> patch implementi
Never mind. This was an optimized build. When I did a make clean and
rebuilt, it went away.
Jeremy
On 8/29/07, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> I'm seeing a bunch of C extensions crash on my box. I'm uncertain
> about a few issues, but I think I'm running 32-bit binary on a 64-bit
>
Martin v. Löwis schrieb:
>> Do you know if it is possible to configure windows so that debug assertions
>> do NOT
>> display a message box (it is very convenient for interactive testing, but
>> not so
>> for automatic tests)?
>
> You can use _set_error_mode(_OUT_TO_STDERR) to make assert() go to
>> Because the pointer may change? There is a (silent) promise that for
>> a given PyUnicodeObject, the Py_UNICODE* will never change.
>
> Right, it's the pointer changing that I'm worried about. Should I not
> bother with changing my code, then?
Correct. If you think this promise should be give
Thanks! I simply forgot about this. Can yuo check in the change to
bytesobject.c? We'll deal with the fallout shortly.
On 8/29/07, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> As I was cleaning up the http libraries, I noticed a lot of code that
> has comparisons with string literals. As we change
Hello,
I recently created patches that correct some problems in py3k on Windows.
They are:
- http://bugs.python.org/issue1029 io.StringIO used to transform \n into \r\n.
This problem must be fixed, if you want the stdout comparisons and
doctests to succeed.
- http://bugs.python.org/issue1047 con
> Is Python 3 likely to change in any way so as to make future performance
> optimization work more fruitful?
I think Python 3 is likely what you see in subversion today, plus any
PEPs that have been accepted and not yet implemented (there are only
few of these). So any higher-reaching goal must w
Martin v. Löwis wrote:
>> I keep Py_UNICODE* pointers into this PyUnicodeObject in my iterator
>> object, and I access these pointers on subsequent calls to my next()
>> method. Is this an error? The more I think about it the more convinced
>> I am it's an error.
>
> Because the pointer may c
> I keep Py_UNICODE* pointers into this PyUnicodeObject in my iterator
> object, and I access these pointers on subsequent calls to my next()
> method. Is this an error? The more I think about it the more convinced
> I am it's an error.
Because the pointer may change? There is a (silent) prom
At various times in the past Python's highly dynamic nature has gotten in
the way of various optimizations (consider optimizing access to globals
which a number of us have taken cracks at). I believe Guido has said on
more than one occasion that he could see Python becoming a bit less dynamic
to a
As part of the PEP 3101 stuff, I have an iterator that I've written in
C. It has a PyUnicodeObject* in it, which holds the string I'm parsing.
I do some parsing, return a result, do some more parsing on the next
call, etc. This code is callable from Python code.
I keep Py_UNICODE* pointers
As I was cleaning up the http libraries, I noticed a lot of code that
has comparisons with string literals. As we change code to return
bytes instead of strings, these comparisons start to fail silently.
When you're lucky, you have a test that catches the failure. In the
httplib case, there were
Oh wow. I see, very clever and useful. It found a real bug! (Except it
was transparent since these variables were only used to pass to
another "uu" format, canceling out the type.) Fixed. Committed
revision 57665.
--Guido
On 8/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > On some buildb
> On some buildbots I see this failure to build the datetime module:
See also bugs.python.org/1055.
> error: Invalid type for 'u' argument 3
>
> The source line is this:
>
> if (!PyArg_ParseTuple(args, "uu:strptime", &string, &format))
and string and format are of type char*; for "u", th
Guido van Rossum schrieb:
> Never mind. Amaury pointed out that the code already includes
> PY_FORMAT_SIZE_T, but that particular platform doesn't support %zd.
> Maybe PY_FORMAT_SIZE_T should be "l" instead on that platform? (As
> it's not Windows I'm pretty sure sizeof(long) == sizeof(void*)...)
On some buildbots I see this failure to build the datetime module:
building 'datetime' extension
gcc -pthread -fPIC -fno-strict-aliasing -g -Wall -Wstrict-prototypes
-I. -I/home2/buildbot/slave/3.0.loewis-linux/build/./Include
-I./Include -I. -I/usr/local/include
-I/home2/buildbot/slave/3.0.loewis
Never mind. Amaury pointed out that the code already includes
PY_FORMAT_SIZE_T, but that particular platform doesn't support %zd.
Maybe PY_FORMAT_SIZE_T should be "l" instead on that platform? (As
it's not Windows I'm pretty sure sizeof(long) == sizeof(void*)...)
--Guido
On 8/29/07, Guido van Ros
I'm seeing a bunch of C extensions crash on my box. I'm uncertain
about a few issues, but I think I'm running 32-bit binary on a 64-bit
linux box. The crash I see in ctypes is the following:
#0 0x080a483e in PyUnicodeUCS2_FromString (u=0x5 )
at ../Objects/unicodeobject.c:471
#1 0xf7cd4f8e
Stop, I already fixed it. Sorry!
On 8/29/07, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> On 8/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 8/28/07, Lars Gustäbel <[EMAIL PROTECTED]> wrote:
> > > On Mon, Aug 27, 2007 at 05:16:37PM -0700, Guido van Rossum wrote:
> > > > As anyone followi
> Do you know if it is possible to configure windows so that debug assertions
> do NOT
> display a message box (it is very convenient for interactive testing, but not
> so
> for automatic tests)?
You can use _set_error_mode(_OUT_TO_STDERR) to make assert() go to
stderr rather than to a message b
On 8/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/28/07, Lars Gustäbel <[EMAIL PROTECTED]> wrote:
> > On Mon, Aug 27, 2007 at 05:16:37PM -0700, Guido van Rossum wrote:
> > > As anyone following the py3k checkins should have figured out by now,
> > > I'm on a mission to require all code
I noticed this failed with a traceback from distutils, caused by a bug
in an exception handler; which I fixed.
I also noticed that there were a *lot* of warnings like this:
Objects/object.c:193: warning: format '%d' expects type 'int', but
argument 7 has type 'Py_ssize_t'
These can be fixed usin
The URL is getting mangled, it should be:
http://www.python.org/dev/buildbot/all/S-390%20Debian%203.0/builds/9
[EMAIL PROTECTED] wrote:
> The Buildbot has detected a new failure of S-390 Debian 3.0.
> Full details are available at:
> http://www.python.org/dev/buildbot/all/S-390%2520Debian%25203.0
61 matches
Mail list logo
