On 29 November 2012 17:04, Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote:
> case WINED3D_TOP_BUMPENVMAP_LUMINANCE:
> lum_map |= 1 << stage;
> + /* fall through */
> case WINED3D_TOP_BUMPENVMAP:
> bump_map |= 1 << stage;
> + /* fall through */
> case WINED3D_TOP_BLEND_TEXTURE_ALPHA:
> case WINED3D_TOP_BLEND_TEXTURE_ALPHA_PM:
> tex_map |= 1 << stage;
I'm not opposed to these if they make it easier to find real bugs
inside the noise with Coverity, but I would also note that it should
be pretty obvious to anyone actually touching this code that the fall
through is intentional.
Charles Davis <cdavis5x(a)gmail.com> writes:
> From: Charles Davis <cdavis(a)mymail.mines.edu>
>
> Autoconf checks for a field of a struct by using it in an if()
> expression. Of course, you can't do this for an aggregate field, so you
> must instead check a field of that aggregate instead. Up until now, the
> conftests for the st_?tim fields were all failing, even on systems that
> had them, because of this.
It does a sizeof, which should work just fine. On what system do you see
a problem?
--
Alexandre Julliard
julliard(a)winehq.org
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=23153
Your paranoid android.
=== WNT4WSSP6 (32 bit) ===
No test summary line found
=== W2KPROSP4 (32 bit) ===
No test summary line found
=== WXPPROSP3 (32 bit) ===
No test summary line found
=== W2K3R2SESP2 (32 bit) ===
No test summary line found
=== WVISTAADM (32 bit) ===
No test summary line found
=== W2K8SE (32 bit) ===
No test summary line found
=== W7PRO (32 bit) ===
No test summary line found
=== W7PROX64 (32 bit) ===
No test summary line found
=== TEST64_W7SP1 (32 bit) ===
No test summary line found
=== W7PROX64 (64 bit) ===
No test summary line found
=== TEST64_W7SP1 (64 bit) ===
No test summary line found
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=23152
Your paranoid android.
=== WNT4WSSP6 (32 bit) ===
No test summary line found
=== W2KPROSP4 (32 bit) ===
No test summary line found
=== WXPPROSP3 (32 bit) ===
No test summary line found
=== W2K3R2SESP2 (32 bit) ===
No test summary line found
=== WVISTAADM (32 bit) ===
No test summary line found
=== W2K8SE (32 bit) ===
No test summary line found
=== W7PRO (32 bit) ===
No test summary line found
=== W7PROX64 (32 bit) ===
No test summary line found
=== TEST64_W7SP1 (32 bit) ===
No test summary line found
=== W7PROX64 (64 bit) ===
No test summary line found
=== TEST64_W7SP1 (64 bit) ===
No test summary line found
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=23151
Your paranoid android.
=== WNT4WSSP6 (32 bit) ===
No test summary line found
=== W2KPROSP4 (32 bit) ===
No test summary line found
=== WXPPROSP3 (32 bit) ===
No test summary line found
=== W2K3R2SESP2 (32 bit) ===
No test summary line found
=== WVISTAADM (32 bit) ===
No test summary line found
=== W2K8SE (32 bit) ===
No test summary line found
=== W7PRO (32 bit) ===
No test summary line found
=== W7PROX64 (32 bit) ===
No test summary line found
=== TEST64_W7SP1 (32 bit) ===
No test summary line found
=== W7PROX64 (64 bit) ===
No test summary line found
=== TEST64_W7SP1 (64 bit) ===
No test summary line found
Hi all,
Since Wine Gecko 1.9 branching, the tip should bump to 1.10, but I think
it's time to clean up the situation a bit. Such things usually don't
bring much attention, but it should be decided in public. Right now we
have three versioning schemes involved in Wine Gecko:
- Wine version that applies to Gecko
- Gecko version (since Firefox 5 and Mozilla's rapid releases it's the
same as Firefox version)
- Wine Gecko version, which is just a growing number, not really
connected with any of above. These numbers currently have no meaning
other that being different for different Wine Gecko releases.
The idea is that Wine Gecko version could be just something based on
other versions, that are more informative. It's not really possible to
use Wine version, because the first version of Wine that will use new
Gecko is not ultimately when Wine Gecko branches. Also multiple Wine
versions use the same Wine Gecko. That leaves us with Gecko (Firefox
version). We don't release on every Firefox release (every 6 weeks), so
if we just used Firefox version, that would look strange (like Wine
Gecko 18 followed by Wine Gecko 20). That can be mitigated by using it
as a minor version. So the next few release would look like:
- 1.9 (that's already in beta and will be the last release using old scheme)
- 2.20 (assuming the next update will be 3 months from 1.9, which means
Firefox 20)
- 2.22 (assuming another 3 moths for the update).
Any suggestions/comments welcomed.
Cheers,
Jacek
2012/11/27 Detlef Riekenberg <wine.dev(a)web.de>:
> While inspecting a test failure, i found only
> 3 possible results for the line test:
> - d3dx9_36.dll not present
> - all tests skipped
> line.c:146: Tests skipped: Failed to create IDirect3DDevice9 object 0x8876086c
> - refcount test failed
> line.c:113: Test failed: Got 5 references to device 0023EA60, expected 2
> (of course with different device pointer)
>
> See: http://test.winehq.org/data/tests/d3dx9_36:line.html
>
> I prefer to mark the refcount as implementation detail and remove the refcount test.
>
> My second way to fix the test failure is the attached patch.
> Since the test was accepted to wine, there must be a machine somewhere
> with a refcount of 2, so i marked that result as broken.
>
I think the test was accepted simply because it passed on Wine while
it wasn't actually executed on WineTestBot. So yeah, removing the
refcount test or adding a todo_wine is probably the way to go, adding
a broken(ref == 2) doesn't seem to make much sense.
Thanks for bringing this up.
> d3d is not my area, so please comment.
>
> --
> By by ... Detlef
> ---
> dlls/d3dx9_36/tests/line.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/dlls/d3dx9_36/tests/line.c b/dlls/d3dx9_36/tests/line.c
> index dc0c747..6ed508b 100644
> --- a/dlls/d3dx9_36/tests/line.c
> +++ b/dlls/d3dx9_36/tests/line.c
> @@ -110,7 +110,9 @@ static void test_create_line(IDirect3DDevice9* device)
> expect_mat(&world, &result);
>
> ref = IDirect3DDevice9_Release(return_device);
> - ok(ref == 2, "Got %x references to device %p, expected 2\n", ref, return_device);
> + todo_wine
> + ok(broken(ref == 2) || ref == 5,
> + "Got %x references to device %p, expected 5\n", ref, return_device);
>
> ref = ID3DXLine_Release(line);
> ok(ref == 0, "Got %x references to line %p, expected 0\n", ref, line);
> --
> 1.7.5.4
>
>
>