Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=15324
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=15327
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=15326
Your paranoid android
On 8 November 2011 21:33, Stefan Dösinger wrote:
> On Tuesday 08 November 2011 20:48:55 Henri Verbeet wrote:
>> - FIXME("Partial block lock with %s\n",
>> debug_d3dpool(surface->resource.pool));
> I added this fixme because we have to tests for the offset that is returned in
> t
On Tuesday 08 November 2011 21:33:39 Stefan Dösinger wrote:
> I added this fixme because we have to tests for the offset that is returned
> in this case.
Sorry, typo: I meant "because we have no tests".
signature.asc
Description: This is a digitally signed message part.
On Tuesday 08 November 2011 20:48:55 Henri Verbeet wrote:
> -FIXME("Partial block lock with %s\n",
> debug_d3dpool(surface->resource.pool));
I added this fixme because we have to tests for the offset that is returned in
this case. Do you have an application that triggers this f
On Tue, Nov 8, 2011 at 19:41, Michael Ost wrote:
> I have a patch for a bug that I won't be able to shepherd through the patch
> submission process for some time. The bug is that GetFileVersionInfoSize
> doesn't work for files with path names longer than 128 characters.
>
> The patch includes an u
I have a patch for a bug that I won't be able to shepherd through the
patch submission process for some time. The bug is that
GetFileVersionInfoSize doesn't work for files with path names longer
than 128 characters.
The patch includes an untried unit test. And I've confirmed the behavior
in W
Austin English wrote:
> +BOOL WINAPI ApphelpCheckShellObject(REFCLSID ObjectCLSID, BOOL
> ShimIfNecessary, ULONGLONG *pullFlags)
> +{
> +FIXME("stub: %s %p\n", debugstr_guid(ObjectCLSID), pullFlags );
> +return TRUE;
> +}
It's a common convention in Wine to avoid hungarian notation by a
2011/11/7 David Adam :
> Hello,
>
> any problem with this patch
> http://source.winehq.org/patches/data/80433
>
> and this one
> http://source.winehq.org/patches/data/80434
>
> Thanks in advance
>
> David
>
> -- Forwarded message --
> From: David Adam
> Date: 2011/10/30
> Subject:
On Tuesday 08 November 2011 12:08:21 Octavian Voicu wrote:
> It gets a bit harder when you have more than a couple of tests,
> because you have to follow the sequence of flashes, but the message
> from the failures should be descriptive enough.
I do that with things like if(i == 5) Sleep(99). I
This patch is OK, the others need some discussion and work.
signature.asc
Description: This is a digitally signed message part.
Stefan Dösinger writes:
> On Tuesday 08 November 2011 13:45:20 Alexandre Julliard wrote:
>> Adding a range of years in a copyright notice is usually discouraged,
>> because it's only valid if you have actually made significant changes
>> every year, which doesn't seem to be the case here.
> What'
Bernhard Loos writes:
> @@ -864,6 +873,10 @@ VOID WINAPI IoCompleteRequest( IRP *irp, UCHAR
> priority_boost )
>
> iosb = irp->UserIosb;
> status = irp->IoStatus.u.Status;
> +
> +assert( status != STATUS_PENDING );
> +assert( status != 0xdeafbeef );
> +
You can't assert on t
On Tuesday 08 November 2011 13:45:20 Alexandre Julliard wrote:
> Adding a range of years in a copyright notice is usually discouraged,
> because it's only valid if you have actually made significant changes
> every year, which doesn't seem to be the case here.
What's the preferred way? Add separate
Thomas Faber writes:
> +/* no buffer, determine length */
> +SetLastError(0xdeadbeef);
> +ret = pGetDllDirectoryA(0, NULL);
> +error = GetLastError();
> +ok(ret == length + 1, "Expected %u, got %u\n", length + 1, ret);
> +ok(error == 0xdeadbeef, "Er
Stefan Dösinger writes:
> @@ -4,7 +4,7 @@
> * Copyright (C) 2005 Antoine Chavasse (a.chava...@gmail.com)
> * Copyright (C) 2005 Christian Costa
> * Copyright 2005 Ivan Leo Puoti
> - * Copyright (C) 2007 Stefan Dösinger
> + * Copyright (C) 2007-2011 Stefan Dösinger for CodeWeavers
Adding a
Hi David,
Impl:
- Probably you may unlock and free the polygon when allocating the
vertice/index fail, why do you need the vertice at all? Couldn't you
just write directly to "data", since you're holding the lock anyway?
- if locking fails, you're leaking the polygon memory, this happens for
n
On Tue, Nov 8, 2011 at 12:18 PM, Stefan Dösinger wrote:
> On Tuesday 08 November 2011 01:14:22 Octavian Voicu wrote:
>> The idea behind using triangles was to fit everything in one screen so
>> I could debug it visually very easily. I'm thinking I can still have
>> that if I draw full-screen quads
[resent to include wine-devel]
On Tue, Nov 8, 2011 at 1:23 AM, Stefan Dösinger wrote:
> Design-wise I think the 8 triangles and readback grid make the test fairly
> difficult to read. You could set up a structure that contains the d3d
> parameters
> you're changing between the tests and the expe
On Tuesday 08 November 2011 01:14:22 Octavian Voicu wrote:
> The idea behind using triangles was to fit everything in one screen so
> I could debug it visually very easily. I'm thinking I can still have
> that if I draw full-screen quads in a loop, like you suggest, then
> blit one small rectangle
21 matches
Mail list logo
