June 2011 - Wine-Devel - list.winehq.org

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Stefan Dösinger

On Thursday 30 June 2011 21:50:45 Michael Mc Donnell wrote: > I have another question about my test. I've basically copied all the > test data from my ConvertAdjacencyToPointReps test, and then just > inverted the conditions. Should I merge the two tests, put the test > data in a separate function, or just ignore the duplication? IMO keeping the tests separated and as simple as possible is more important than avoiding code duplication here, but I don't think we have a policy about this.

June 30, 2011

Re: wine bug 27600

by wylda＠volny.cz

> Otherwise WINE compilation with 32bit gcc gets broken (not yet > 100% > > confirmed, see the discussion with Wylda on wine-devel mailing > list). > > Small patch to test for the issue - > http://dl.dropbox.com/u/6901628/bug_test.patch Now i can confirm for sure, that simple testcase bug_test.patch fails here as in Austin's case: gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g -O2 -o adsiid.o adsiid.c In file included from bug_test.c:8: ../include/winternl.h:2361: error: expected declaration specifiers or ‘...’ before ‘va_list’ ../include/winternl.h:2531: error: expected declaration specifiers or ‘...’ before ‘va_list’ ../include/winternl.h:2532: error: expected declaration specifiers or ‘...’ before ‘va_list’ In file included from bug_test.c:9: ../include/winbase.h:1578: error: expected declaration specifiers or ‘...’ before ‘va_list’ ../include/winbase.h:1579: error: expected declaration specifiers or ‘...’ before ‘va_list’ make[1]: *** [bug_test.o] Error 1 > Including "winternl.h" before "winbase.h" and "winuser.h" must > have > > caused the issue. Vincas could you open a bug for that? You probably know most about this issue ;) Thanks Vincas & Austin! W.

June 30, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Thu, Jun 30, 2011 at 6:42 PM, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: > On Thu, Jun 30, 2011 at 4:10 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: >> On 30 June 2011 14:49, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: >>> In init_edge_face_map I initialize an array of edge_face structs, and >>> in find_adjacent_face I do a linear search through that array. I would >>> like to replace the array with a hash table, so that the search time >>> becomes constant. I've found a standard list (wine/list.h) and >>> red-black tree implementation (wine/rbtree.h), but not a standard hash >>> table implementation. Is there a standard hash table implementation, >>> should I roll my own or find an LGPL'ed one? >>> >> I'm not sure if a hash table would be faster and how much, but an easy >> way to make the lookup cheaper would be to store the edge -> face map >> as a list for each vertex. >> >> ... >> >> It's then mostly trivial to determine adjacency. This assumes most >> vertices are only part of a handful of edges, but I don't think that's >> unreasonable in practice. > > Thanks for your suggestion. I think you're right that it is safe to > assume that most vertices will only be a part of a few edges. I'll > implement that for now. I've implemented the look-up scheme that you described. I have another question about my test. I've basically copied all the test data from my ConvertAdjacencyToPointReps test, and then just inverted the conditions. Should I merge the two tests, put the test data in a separate function, or just ignore the duplication?

June 30, 2011

Re: wine bug 27600

by Austin English

On Thu, Jun 30, 2011 at 07:57, <wylda(a)volny.cz> wrote: > >> >> $ cd wine-git >> $ wget http://dl.dropbox.com/u/6901628/raw.patch >> $ patch -p1 < raw.patch >> $ ./tools/make_requests >> $ ./configure >> $ make >> >> works here: > > Thanks Austin for testing, but this raw.patch is already modified > and works for me too. I would need to retest the series of nine > individial patches ;) (thoses in wine-patches queue with > status=New). Ah, right. Doing: git clean -dfx git reset --hard origin for i in 75876 75883 75878 75882 75881 75884 75877 75879 75880 do wget http://source.winehq.org/patches/data/$i -O /tmp/raw-$i.patch git apply /tmp/raw-$i.patch done ./tools/make_requests ./configure make gives: make[1]: Entering directory `/home/austin/wine-git/server' gcc -c -I. -I. -I../include -I../include -D__WINESRC__ -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o raw_input.o raw_input.c In file included from raw_input.c:28: ../include/winternl.h:2361: error: expected declaration specifiers or '...' before 'va_list' ../include/winternl.h:2531: error: expected declaration specifiers or '...' before 'va_list' ../include/winternl.h:2532: error: expected declaration specifiers or '...' before 'va_list' In file included from raw_input.c:29: ../include/winbase.h:1578: error: expected declaration specifiers or '...' before 'va_list' ../include/winbase.h:1579: error: expected declaration specifiers or '...' before 'va_list' make[1]: *** [raw_input.o] Error 1 make[1]: Leaving directory `/home/austin/wine-git/server' make: *** [server] Error 2 http://dl.dropbox.com/u/6901628/raw.patch works And the bug test patch: gcc -c -I. -I. -I../include -I../include -D__WINESRC__ -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o bug_test.o bug_test.c In file included from bug_test.c:8: ../include/winternl.h:2361: error: expected declaration specifiers or '...' before 'va_list' ../include/winternl.h:2531: error: expected declaration specifiers or '...' before 'va_list' ../include/winternl.h:2532: error: expected declaration specifiers or '...' before 'va_list' In file included from bug_test.c:9: ../include/winbase.h:1578: error: expected declaration specifiers or '...' before 'va_list' ../include/winbase.h:1579: error: expected declaration specifiers or '...' before 'va_list' make: *** [bug_test.o] Error 1 These tests were on: Linux aw25 2.6.37 #1 SMP Thu Apr 21 17:36:51 PDT 2011 i686 Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz GenuineIntel GNU/Linux (gentoo) -- -Austin

June 30, 2011

Re: [PATCH 5/5] jscript/tests: Add tests with values related to INT_MAX

by Jacek Caban

On 06/28/11 15:47, Detlef Riekenberg wrote: > On Mo, 2011-06-27 at 11:59 +0200, Jacek Caban wrote: > >>> How can we force tests to use VT_UI4? >> It's not JScript builtin type, you need to extend tests host object for >> that. > Sorry, no clue. > Which host object Global host object for tests. See how nullDisp is done in run.c. Jacek

June 30, 2011

Re: gcc 4.6 warning report

by Juan Lang

> David is right, the address is not stored as a pointer but as a DWORD in > place of the chars. Like this: > > gethostbyname("winehq.org"): > wrong: (DWORD) host->h_addr_list[i] = 0x00cbd1c8 = 200.209.203.0 > right: *(DWORD*) host->h_addr_list[i] = 0x86192ed1 = 209.46.25.134 Patch welcome ;) --Juan

June 30, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Thu, Jun 30, 2011 at 4:10 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 30 June 2011 14:49, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: >> In init_edge_face_map I initialize an array of edge_face structs, and >> in find_adjacent_face I do a linear search through that array. I would >> like to replace the array with a hash table, so that the search time >> becomes constant. I've found a standard list (wine/list.h) and >> red-black tree implementation (wine/rbtree.h), but not a standard hash >> table implementation. Is there a standard hash table implementation, >> should I roll my own or find an LGPL'ed one? >> > I'm not sure if a hash table would be faster and how much, but an easy > way to make the lookup cheaper would be to store the edge -> face map > as a list for each vertex. > > So e.g. if you have these faces: > f0: v0, v2, v1 > f1: v1, v4, v3 > f2: v1, v2, v4 > f3: v2, v5, v4 > > You'd build these lists: > v0: {v2:f0} > v1: {v0:f0}, {v4:f1}, {v2:f2} > v2: {v1:f0}, {v4:f2}, {v5:f3} > v3: {v1:f1} > v4: {v3:f1}, {v1:f2}, {v2:f3} > v5: {v4:f3} > > It's then mostly trivial to determine adjacency. This assumes most > vertices are only part of a handful of edges, but I don't think that's > unreasonable in practice. Thanks for your suggestion. I think you're right that it is safe to assume that most vertices will only be a part of a few edges. I'll implement that for now. > We did have a hash table inside wined3d at some point, I suppose you > could also try resurrecting that from git history. I'll stick with your suggestion as it seems easier to implement :-) Btw I just searched source.winehq.org for hash_table and found several hits in different dlls. I think it would be nice if they could all use the same implementation like list.h and rbtree.h. That way it could also later be used for other parts of wine. Should I add it to http://wiki.winehq.org/JanitorialProjects?

June 30, 2011

Re: [PATCH 1/4] shell32: Implement erasing and restoring items from the trash

by Juan Lang

Hi Jay, +HRESULT TRASH_RestoreItem(LPCITEMIDLIST pidl){ Nit: the brace should be on its own line. +HRESULT TRASH_RestoreItem(LPCITEMIDLIST pidl) DECLSPEC_HIDDEN; +HRESULT TRASH_EraseItem(LPCITEMIDLIST pidl) DECLSPEC_HIDDEN; These two functions are never called in this patch, so you're introducing dead code. That's not allowed. Introduce the functions in the patch that uses them, please. If the resulting patch is too large, you must split it another way. --Juan

June 30, 2011

Re: dxgi.idl: Added DXGI_SWAP_CHAIN_FLAG enum declaration and DXGI_MWA_* flags

by Jacek Caban

On 06/30/11 17:44, Henri Verbeet wrote: > On 30 June 2011 17:34, Jacek Caban <jacek(a)codeweavers.com> wrote: >> +cpp_quote("#define DXGI_MWA_NO_WINDOW_CHANGES 0x1") >> +cpp_quote("#define DXGI_MWA_NO_ALT_ENTER 0x2") >> +cpp_quote("#define DXGI_MWA_NO_PRINT_SCREEN 0x4") >> +cpp_quote("#define DXGI_MWA_VALID 0x7") > Aren't those usually done as constants? (I.e., "const UINT > DXGI_MWA_NO_WINDOW_CHANGES = 0x1;") They usually are, but these flags are exception, at least in the PSDK I have. Jacek

June 30, 2011

Re: GSoC: dinput8 Action Mapping

by Lucas Zawacki

Ouch, that is a leftover from an older try at this code. So much for double checking the patches... 2011/6/30 Marcus Meissner <meissner(a)suse.de>: > On Thu, Jun 30, 2011 at 02:56:08AM -0300, Lucas Zawacki wrote: >> Hey guys, how are you doing? I've got some patches for you. >> >> The first is a refactoring of the BuildActionMap implementations for >> keyboard and mouse. I think with 'semantic_to_obj_id' the mapping is >> pretty much correct for keyboard and mouse and it's being done "the >> right way". >> >> The second patch is much like one I sent some time ago, it's >> SetActionMap for keyboard and mouse, this time (hopefully) with the >> dataformat stuff done right too. I've split it up in a third patch, >> which implements the "action mapping" per se. >> >> Anyway, tomorrow I'll code some mouse tests to be sure that this is working. >> >> Cheers > >> From 37e5a1e6d51778ee0d5c0f3081dad8ca1431968f Mon Sep 17 00:00:00 2001 >> From: Lucas Fialho Zawacki <lfzawacki(a)gmail.com> >> Date: Fri, 10 Jun 2011 21:43:53 -0300 >> Subject: dinput: Keyboard and mouse implementation of BuildActionMap (try 4) >> >> >> +DWORD semantic_to_obj_id(IDirectInputDeviceImpl* This, DWORD dwSemantic) >> +{ > ... >> + if (!found) return 0; > > So 0 is the not found case... > >> + DWORD obj_id = semantic_to_obj_id(&This->base, lpdiaf->rgoAction[i].dwSemantic); >> + if (obj_id != -1) > > But here you check for -1. > > >> + DWORD obj_id = semantic_to_obj_id(&This->base, lpdiaf->rgoAction[i].dwSemantic); >> + if (obj_id != -1) > > and here. (both mouse and keyboard code) > > should probably check for 0 there, also as DWORD is unsigned ;) > > Ciao, Marcus >

June 30, 2011