Eric Smith wrote:
> Eric Smith wrote:
>> Guido van Rossum wrote:
>>> If this is Py3k, perhaps the result should be a PyUnicode instead?
>> Probably so, yes.
>>
>> But I can't reproduce this on a Fedora Core 6 box. I'm compiling under
>> Windows now to see if I can reproduce it there. I'll change
Eric Smith wrote:
> Guido van Rossum wrote:
>> If this is Py3k, perhaps the result should be a PyUnicode instead?
>
> Probably so, yes.
>
> But I can't reproduce this on a Fedora Core 6 box. I'm compiling under
> Windows now to see if I can reproduce it there. I'll change it to
> PyUnicode_Ch
Guido van Rossum wrote:
> If this is Py3k, perhaps the result should be a PyUnicode instead?
Probably so, yes.
But I can't reproduce this on a Fedora Core 6 box. I'm compiling under
Windows now to see if I can reproduce it there. I'll change it to
PyUnicode_Check shortly, even if I can't repr
If this is Py3k, perhaps the result should be a PyUnicode instead?
On Sun, Feb 24, 2008 at 1:19 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > test_types is triggering an assertion error::
> >
> > Objects/stringlib/string_format.h:497: failed assertion
> > `PyString_Chec
Brett Cannon wrote:
> test_types is triggering an assertion error::
>
> Objects/stringlib/string_format.h:497: failed assertion
> `PyString_Check(result)'
>
> A *really* quick session with gdb would seem to suggest that 'result'
> is actually a str, so I don't know what is going on. Don't have
test_types is triggering an assertion error::
Objects/stringlib/string_format.h:497: failed assertion
`PyString_Check(result)'
A *really* quick session with gdb would seem to suggest that 'result'
is actually a str, so I don't know what is going on. Don't have time
to dig any deeper right now.
Martin v. Löwis schrieb:
>> Any suggestions?
>
> I've now backed out my first patch, and implemented an extension
> to msvcrt, as well as a command line option for regrtest. Let's
> see how this works.
>
> Regards,
> Martin
At least the tests on the win32 buildbot now do not hang any longer
if I
> Any suggestions?
I've now backed out my first patch, and implemented an extension
to msvcrt, as well as a command line option for regrtest. Let's
see how this works.
Regards,
Martin
___
Python-3000 mailing list
Python-3000@python.org
http://mail.pytho
Martin v. Löwis schrieb:
>> Agreed, thus my original suggestion of a standalone wrapper executable
>> (or using ctypes).
>
> That doesn't work well, either - how do we get this wrapper onto the
> build slaves? It would work if such wrapper shipped with the
> operating system.
>
>> I just think th
> Agreed, thus my original suggestion of a standalone wrapper executable
> (or using ctypes).
That doesn't work well, either - how do we get this wrapper onto the
build slaves? It would work if such wrapper shipped with the
operating system.
> I just think that if someone needs the functionality
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> However, we can't use pywin32 on the buildbot slaves - it's not
> installed.
Agreed, thus my original suggestion of a standalone wrapper executable
(or using ctypes). But for end users of Python on Windows, this is a
direct Windows-specific API wra
> For SetErrorMode, if you're just looking for a non-ctypes wrapping,
> it's already covered by pywin32's win32api, which seems simple enough
> to obtain (and likely to already be present) if you're working at this
> level with Win32 calls as a user of Python. Nor is ctypes very
> complicated as a
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>> So, an environment variable would be useful, but maybe there should also be
>> a Python function available that calls set_error_mode().
>> sys.set_error_mode()?
>
> Even though this would be somewhat lying - I'd put it into
> msvcrt.set_error_mode
> But unlike Unix, these text messages are guaranteed to be lost.
Not really. We are probably talking about release builds primarily,
where the only such message is the system error (as the assertions
aren't compiled in, anyway). If such an error occurs, the message
is lost - but an error code is
Martin v. Löwis schrieb:
>> So, an environment variable would be useful, but maybe there should also be
>> a Python function available that calls set_error_mode().
>> sys.set_error_mode()?
>
> Even though this would be somewhat lying - I'd put it into
> msvcrt.set_error_mode. For the _CrtSet fun
Martin v. Löwis wrote:
>>> It should still require an environment variable, say
>>> PYTHONNOERRORWINDOW, whether or not it should be considered only
>>> in debug releases, I don't know. One place to put it would be
>>> Modules/main.c (where all the other environment variables are
>>> considered).
>
>> It should still require an environment variable, say
>> PYTHONNOERRORWINDOW, whether or not it should be considered only
>> in debug releases, I don't know. One place to put it would be
>> Modules/main.c (where all the other environment variables are
>> considered).
>
> It should also not be us
Martin v. Löwis wrote:
>> New patch (still detects the debug build because the name of the C runtime
>> dll depends on it):
>
> I know it will be difficult to talk you into not using ctypes :-),
> but...
>
> I think this should go into the interpreter code itself. One problem
> with your patch is
> So, an environment variable would be useful, but maybe there should also be
> a Python function available that calls set_error_mode().
> sys.set_error_mode()?
Even though this would be somewhat lying - I'd put it into
msvcrt.set_error_mode. For the _CrtSet functions, one might
expose them as-i
Martin v. Löwis schrieb:
>> New patch (still detects the debug build because the name of the C runtime
>> dll depends on it):
>
> I know it will be difficult to talk you into not using ctypes :-),
> but...
>
> I think this should go into the interpreter code itself. One problem
> with your patch
> New patch (still detects the debug build because the name of the C runtime
> dll depends on it):
I know it will be difficult to talk you into not using ctypes :-),
but...
I think this should go into the interpreter code itself. One problem
with your patch is that it breaks if Python is build wi
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
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
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
> 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);
>
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
> 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
Unfortunately, I read nearly all my mailing lists through gmane with nntp
- and gmane is down currently (it doesn't deliver new messages any more).
So I cannot write a reply in the original thread :-(
Neal:
> > We got 'em. Let the spam begin! :-)
> >
> > This page is not linked from the web anyw
Unfortunately, I read nearly all my mailing lists through gmane with nntp
- and gmane is down currently (it doesn't deliver new messages any more).
So I cannot write a reply in the original thread :-(
Neal:
> We got 'em. Let the spam begin! :-)
>
> This page is not linked from the web anywhere:
Thomas Heller schrieb:
> Martin v. Löwis schrieb:
>>> Since the tests fail on the trunk (on the windows machines),
>>> the 'clean' step is not run.
>>
>> No. The 'clean' step is run even if the test step failed.
>>
>> The problem must be somewhere else: for some reason, the
>> connection breaks d
> Since the tests fail on the trunk (on the windows machines),
> the 'clean' step is not run.
No. The 'clean' step is run even if the test step failed.
The problem must be somewhere else: for some reason, the
connection breaks down/times out; this causes the build
to abort.
Can you check the sla
> * Add the branch in the buildbot master.cfg file. 2 places need to be
> updated.
> * Add new rules in the apache default configuration file (2 lines).
> Make sure to use the same port number in both the changes.
> * Check in the buildbot master config. apache config too?
* Edit pydotorg:bu
Unfortunately, I read nearly all my mailing lists through gmane with nntp
- and gmane is down currently (it doesn't deliver new messages any more).
So I cannot write a reply in the original thread :-(
Neal:
> > We got 'em. Let the spam begin! :-)
> >
> > This page is not linked from the web anyw
Neal Norwitz wrote:
> There are several other known warnings on various platforms:
...
> Python/../Objects/stringlib/unicodedefs.h:26: warning: 'STRINGLIB_CMP'
> defined but not used
I fixed this warning in r57613. Unfortunately I had to change from an
inline function to a macro, but I don't see
We got 'em. Let the spam begin! :-)
This page is not linked from the web anywhere:
http://python.org/dev/buildbot/3.0/
I'm not expecting a lot of signal out of them at the beginning. All
but one has successfully compiled py3k though. I noticed there were
many warnings on windows. I wonder i
41 matches
Mail list logo
