Vincent Povirk wrote:
> This is a fix to a problem I introduced in
> fd5b97bc4d12adc69085b739061c56e9107f8d1f. The expression that checked
> the HTTP version was true for HTTP/1.0 servers, and I treated it as if
> it were true for HTTP/1.1 servers. That means we defaulted to keep-alive
> for HTTP/1
> > visual.c:1194: Test failed: Got color 00efebe7, expected 0080 or
> > near
> > visual.c:1200: Test failed: Got color 00efebe7, expected 00ff or
> > near
> I have run the tests in valgrind, and there's a crash somewhere. Could
> be
> related
It seems that the tests crash in the libglcore.
"Austin English" <[EMAIL PROTECTED]> wrote:
> Thanks for the comments! Here's an updated patch. Passes in Win2K.
This still doesn't look ok to me (missing SetLastError beforehand,
indentation, spacing, braces). There is no need to add a new test,
just add the SetLastError(0xdeadbeef) call before
Hi Austin,
+found = FindWindow("SomeWindowThatDoesNotExist", NULL);
+if(found) {
+ printf("found not NULL");
+}
Please don't use printf in the tests. If you must log something, use
trace, but I don't think it's that useful in this case, since we
really expect it not to be found.
On Wed, Aug 13, 2008 at 10:09 PM, Dmitry Timoshkov
<[EMAIL PROTECTED]> wrote:
> "Austin English" <[EMAIL PROTECTED]> wrote:
>
>> -/* test FindWindow behavior */
>> +SetLastError(0xdeadbeef);
>> +HWND hWnd = FindWindow("SomeWindowThatDoesNotExist", NULL);
>> +if(hWnd) {
>> + pri
> I guess this is http://bugs.winehq.org/show_bug.cgi?id=10221
Ya, as Henri said this is most likely a driver bug and we can't do anything
against it.
> ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p
> ddraw_test.exe.so
> visual.c && touch visual.ok
> fixme:win:EnumDisplayDevicesW (
The d3d9 one is probably a driver bug, not sure about the ddraw one.
If it's much of an issue, it might be worth to run the tests using
Mesa instead.
On Thu, Aug 14, 2008 at 7:37 AM, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> You mentioned sporadic test failures in the d3d9:visual and ddraw:visual
> tests earlier, but I did not have time to look at it back then. Can you send
> me logs of the failures and successes?
>
> I am afraid that the d3d
On Wed, Aug 13, 2008 at 12:18 AM, H. Verbeet <[EMAIL PROTECTED]> wrote:
>> d3d9:visual.c
> What kind of failures are you seeing there, and with which drivers?
> (The test should at least pass with recent Mesa versions as long as
> the GLSL extensions are disabled)
I guess this is http://bugs.wine
On Thu, Aug 14, 2008 at 2:49 AM, Darragh Bailey
<[EMAIL PROTECTED]> wrote:
> I currently use buildbot at work for managing builds, and it looks like
> that it could handle many of your tasks if patchwatcher could be
> integrated into it.
Good idea. Even Mozilla, home of http://www.mozilla.org/tin
> Patchwatcher is online and giving reasonably good
> feedback on the patch stream. The bug that caused
> every patch to be marked 'failed tests' is fixed, and
> the blacklist is expanded enough that false regressions
> seem to be rare.
You mentioned sporadic test failures in the d3d9:visual and d
How did this spam go through?
Moderating mistake or should Mister Nice Guy'sśsubscription be
cancelled?
--
Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/
"Lotto: A tax on people who are bad at math." -- unknown
"Windows: Microsoft's tax on comput
Have you considered using some of the tools out there for automated
builds and looking to integrate patchwatcher to extend them to suit your
purpose.
A number of the features you suggest below are most likely already
implemented within existing automated builds.
I currently use buildbot at work f
13 matches
Mail list logo
