July 2010 - Wine-devel - list.winehq.org

Re: ws2_32, WS2_send: Avoid error if total bytes sent is 0
by Mike Kaplinskiy 27 Jul '10

27 Jul '10

On Mon, Jul 26, 2010 at 3:05 PM, Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> wrote: > This fixes bug #19397 > > > > I don't think that's the right place for the fix. You should probably put it in WS2_sendto. Also could you add some tests to verify that this is the behavior for all protocols, not just IrDA? Mike.

1 0

Re: ntdll: Use IsEqualGUID instead of memcmp to compare GUIDs.
by Octavian Voicu 27 Jul '10

27 Jul '10

On Tue, Jul 27, 2010 at 2:00 AM, Michael Stefaniuc <mstefani(a)redhat.de> wrote: > - ok(memcmp(&guid, &IID_Endianess, sizeof(guid)) == 0, "Endianess broken\n"); > + ok(!IsEqualGUID(&guid, &IID_Endianess), "Endianess broken\n"); memcmp returns 0 when there is a match, so you should probably use IsEqualGUID without the negation. Octavian

1 0

Re: ntdll: Use IsEqualGUID instead of memcmp to compare GUIDs.
by testbot＠testbot.winehq.org 27 Jul '10

27 Jul '10

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=3928 Your paranoid android. === W2KPROSP4 (32 bit rtlstr) === rtlstr.c:1844: Test failed: Endianess broken === WXPPROSP3 (32 bit rtlstr) === rtlstr.c:1844: Test failed: Endianess broken === W2K3R2SESP2 (32 bit rtlstr) === rtlstr.c:1844: Test failed: Endianess broken === WVISTAADM (32 bit rtlstr) === rtlstr.c:1844: Test failed: Endianess broken === W2K8SE (32 bit rtlstr) === rtlstr.c:1844: Test failed: Endianess broken === W7PRO (32 bit rtlstr) === rtlstr.c:1844: Test failed: Endianess broken === W7PROX64 (32 bit rtlstr) === rtlstr.c:1844: Test failed: Endianess broken === W7PROX64 (64 bit rtlstr) === rtlstr.c:1844: Test failed: Endianess broken

1 0

d3dx9: D3DXCreateMeshFVF and ID3DXMesh... let the criticism begin
by Misha Koshelev 27 Jul '10

27 Jul '10

Dear All: I have worked hard today with Henri on my D3DXCreateSphere patch and appreciate all his help (and all of your help and patience with me and my inability to use email programs and IRC programs ;) ). I am now moving on to implementing D3DXCreateMeshFVF and ID3DXMesh so that we can actually get D3DXCreateSphere, Box, and Cylinder going (and teapot... or a stub). I attached my current versions. I expect a lot of comments/changes: * patch 1 - same patch as I submitted with Henri's blessing. Hopefully this will go in tomorrow. This is just for reference. * patch 2 - add stub for D3DXCreateMeshFVF and basic test. I'm assuming this should go in too if I sent it by itself tomorrow. * patch 3 - enumeration. Also fairly simple. * patch 4 - complete D3DXCreateMeshFVF test. Any criticisms? At the very least, I would like to send patches 2-4 tomorrow, provided patch 1 goes in (I'm assuming so per the Henri blessing part ... fingers crossed) * patch 5 - this is clearly not complete and I hope to get some good feedback on this patch. I've already gotten some feedback from Tony Wasserka (thank you). Specifically, I expect per his comment I must reimplement using declarators http://bugs.winehq.org/show_bug.cgi?id=22918#c39 This means that I must first get a patch committed that implements D3DXDeclaratorFromFVF which is currently a stub in git. Additionally, I realize Tony has, in his private repo, some more work on ID3DXMesh that is somewhat more complete I believe than mine: http://repo.or.cz/w/wine/d3dx9TW.git/blob/Merge:/dlls/d3dx9_36/basemesh.c I have not yet given this detailed scrutiny as, for me, it is easier to start with my own code, and then work from there, potentially integrating Tony's code (thank you) based on your feedback about what is necessary, etc. However, I have currently limited my code to the features that are necessary for ID3DXMesh for D3DXCreateSphere, Cylinder, and Box, as the aim was to fix this bug: http://bugs.winehq.org/show_bug.cgi?id=22918 In any case, I appreciate your attention to these patches and good feedback. I am specifically quite interested in feedback to patches 2-4, as I'd like to (ideally) submit versions of these that go through tomorrow. However, as the bulk of my work tomorrow (and probably for quite a bit afterwards) I expect on patch 5, I'd appreciate, it possible a list of things that are necessary to get such a patch committed. (Please correct me if I am wrong about having to implement D3DXDeclaratorFromFVF.) I chose to put this hard stuff first. Then, quite honestly, I believe adding tests for D3DXCreateBox and Cylinder, as well as the actual implementations, should be fairly simple compared to this part. In any case, I eagerly (anxiously) await constructive criticism/feedback/suggestions. Thank you Misha

1 1

Re: [PATCH 1/1] d3dx9: Complete test for D3DXCreateSphere. (try 5)
by Misha Koshelev 27 Jul '10

27 Jul '10

Ok I am very very sorry email is clearly not my forte. Linking same file in test and main dll: I am not aware of a precedent for this but if there is one of course I would be glad to be shown otherwise. Second comment: please pardon if I am misunderstanding but how is what you suggest not simply moving the lookup table calculation from the helper function which we will also use for, at the very least, the cylinder test, inside the actual compute_sphere function itself? Thank you Misha On Jul 26, 2010 8:40 PM, "Octavian Voicu" <octavian.voicu(a)gmail.com> wrote: On Tue, Jul 27, 2010 at 4:15 AM, Misha Koshelev <misha680(a)gmail.com> wrote: > Why do you ask? > > Ar... That's why I was asking, as I suppose you can't use functions from the test in the implementation, nor have internal functions used in the tests. Only way I see it is to have something like mesh_utils.[ch] which is linked with both the dll and the test, but I'm not sure if that's acceptable. Maybe someone else can answer that. A little observation is that you don't really need to precompute both tables, just the one for phi (if you compute sin and cos of current theta outside the inner loop). Octavian

2 2

Re: [5/5] urlmon/tests: Added some more test URIs
by testbot＠testbot.winehq.org 27 Jul '10

27 Jul '10

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=3926 Your paranoid android. === W98SE (32 bit uri) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit uri) === Timeout === WXPPROSP3 (32 bit uri) === uri.c:2169: Test failed: Expected http://google.com:00035 but got L"http://google.com:35" on uri_tests[60].str_props[2]. uri.c:2387: Test failed: Error: Expected http://google.com:00035 but got L"http://google.com:35" on uri_test[60]. uri.c:2840: Test failed: Error: Expected a length of 23 but got 20 on uri_tests[60].str_props[2]. === WVISTAADM (32 bit uri) === uri.c:2169: Test failed: Expected http://google.com:00035 but got L"http://google.com:35" on uri_tests[60].str_props[2]. uri.c:2387: Test failed: Error: Expected http://google.com:00035 but got L"http://google.com:35" on uri_test[60]. uri.c:2840: Test failed: Error: Expected a length of 23 but got 20 on uri_tests[60].str_props[2]. === W2K8SE (32 bit uri) === uri.c:2169: Test failed: Expected http://google.com:00035 but got L"http://google.com:35" on uri_tests[60].str_props[2]. uri.c:2387: Test failed: Error: Expected http://google.com:00035 but got L"http://google.com:35" on uri_test[60]. uri.c:2840: Test failed: Error: Expected a length of 23 but got 20 on uri_tests[60].str_props[2].

1 0

Re: [4/5] urlmon: Implemented IUri_GetPort
by testbot＠testbot.winehq.org 27 Jul '10

27 Jul '10

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=3925 Your paranoid android. === W98SE (32 bit uri) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit uri) === Timeout

1 0

Re: [2/5] urlmon/tests: Restructured invalid URI tests plus added more test data
by testbot＠testbot.winehq.org 27 Jul '10

27 Jul '10

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=3924 Your paranoid android. === W98SE (32 bit uri) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit uri) === Timeout

1 0

Re: [PATCH 1/1] d3dx9: Complete test for D3DXCreateSphere. (try 5)
by Misha Koshelev 27 Jul '10

27 Jul '10

> On Tue, Jul 27, 2010 at 1:30 AM, Misha Koshelev <misha680 at gmail.com> wrote: > > I have spent quite a bit of time with Henri on IRC re this patch (thank you so much) and it now has his blessing. > > > > Hopefully everyone else's as well :) > > Looks nice, but I have a question. > > When you're going to actually implement D3DXCreateSphere (probably > applies to subsequent mesh functions too), aren't you going to need > big chunks of this code, like the compute_sphere and *_sincos_table > functions? > > Or are you going to use a different approach to compute the meshes in > the actual implementation? > > Octavian > Yes it is going to be fairly similar. A few exceptions: * No mesh structure per se (vertex and index buffer inline in the actual function) * Definitely the sincos_table parts You can see (a rather dated at this point) version here: http://github.com/misha680/wine/blob/master/dlls/d3dx9_36/mesh.c Why do you ask? Are you aware of a good way to share code between tests and the actual function? Thank you Misha p.s. I'm not really aware of another (better) approach to compute.

2 2

Re: ddraw: Ensure fullscreen size of fullscreen windows
by testbot＠testbot.winehq.org 27 Jul '10

27 Jul '10

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=3921 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0