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

Re: d3dx9: Implement D3DXDeclaratorFromFVF with tests
by winetestbot＠geldorp.nl 12 Apr '10

12 Apr '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://winetestbot.geldorp.nl/JobDetails.pl?Key=1361 Your paranoid android. === WINEBUILD (Wine build VM) === Make failed

1 0

WineTestBot: phase 3 implemented
by Greg Geldorp 11 Apr '10

11 Apr '10

I'm happy to announce that WineTestBot (http://winetestbot.geldorp.nl) is now actively scanning wine-patches submissions for changes to tests. If it finds a test change, it will apply the changes, build the affected test executables and run them on the base VMs. Results will be mailed back to the submitter. It will also try to determine if new failures were introduced, by comparing the test results to the most recent run using winetest.exe from WineHQ. If it thinks there are new failures, a message is sent to the author with a copy to wine-devel. The bot will only process complete series, so it will queue up patches that appear to be part of a series. Then when the series is complete, it generates one big patch file by adding all the individual patches from the series together before submitting it. We'll have to see how robust this is, it is quite possible to mess up this algorithm. Only patches that contain changes to tests are run. It checks to see if any dlls/<dllname>/tests/* files were changed, if so it is deemed a change to the tests. This should cover most cases, but again is not 100% correct all the time (if you only change a file in include/ then the tests depending on the header files don't get run). In the end we still have the daily run that's done when Alexandre publishes a new winetest.exe. There's a new item in the WineTestBot menu, "Wine-patches". It will show which patches have been received via the mailing list and what the bot has done with them. Of course, you'll still be able to manually submit a patch to the bot too. These run at higher priority than the jobs generated from wine-patches submissions. Happy testing, Ge.

2 1

Re: loader: Fix French translation of wine manpage
by Nicolas Le Cam 09 Apr '10

09 Apr '10

Le 9 avril 2010 13:37, Frédéric Delanoy <frederic.delanoy(a)gmail.com> a écrit : > 2010/4/9 Nicolas Le Cam <niko.lecam(a)gmail.com>: >> Hi Frédéric, >> >>>+\fIwineserver\fR dans le chemin système ou quelques autres emplacements vraisemblables. >>>[...] >>>+"wine" dans le chemin système ou quelques autres emplacements vraisemblables. >> Even if "likely" literally means "vraisemblable" I think the previous >> use of "potentiel" or even "possible" suits better. > > See my comments in the mail "wineserver: Fix French manpage" >> >>>+n'est spécifiée, le caractère + peut être omis. Notez que les espaces ne sont pas >>>+autorisées dans cette chaîne de caractères. >> Should be "autorisés" > > "espace" is feminine when talking about the typographical sign (cf > http://fr.wikipedia.org/wiki/Espace_typographique) > Now if \t or similar had been relevant in that sentence, it would have > been "caractères d'espacement". Oh didn't know that. Thanks for the explanation. >> >>>+Définit le type de remplacement et l'ordre de chargement des DLL utilisées lors du >>>+processus de chargement d'une DLL. Le comportement par défaut est spécifié dans le >>>+fichier de configuration. Deux types de bibliothèques peuvent actuellement être chargées >>>+dans l'espace d'adressage d'un processus : les DLL natives de >>>+Windows >> Should be "chargés" > > What's loaded? The types or the libraries? I think the latter... It's the "two types of libraries" that can be loaded. -- Nicolas Le Cam

1 0

Re: [PATCH 01/10] server: allow polling for no events in set_fd_events
by Alexandre Julliard 09 Apr '10

09 Apr '10

Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> writes: > Remove the fd from the poll list so we don't get POLLHUP/POLLERR > messages when we ask for no events This is wrong, even when selecting for no events you want to receive POLLHUP/POLLERR. If you really don't want any events you have to use -1 to remove the fd from the loop. But in general ignoring POLLHUP/POLLERR is a bug. -- Alexandre Julliard julliard(a)winehq.org

2 7

new icons
by wylda＠volny.cz 09 Apr '10

09 Apr '10

Hi, this will be just a short note... I noticed some new icons and i like them! W.

2 1

re: winetricks failed, expecting "system32" where I have "System32" and so on
by Dan Kegel 09 Apr '10

09 Apr '10

Helge wrote: > I happen to have Windows/System32. Hang on right there. Why? Once I understand that, the rest will be easier. Winetricks does handle the case where users renamed windows/fonts to windows/Fonts, because it was observed happening in the wild (one can imagine users doing thiis when manually installing fonts). But this is the first I've heard of a System32 rather than a system32. - Dan

3 3

Re: kernel32: Add tests for lstrcmpW
by Dmitry Timoshkov 09 Apr '10

09 Apr '10

André Hentschel <nerv(a)dawncrow.de> wrote: > +#define TESTMARKER(w) \ > + markerW[2] = w; \ > + ok(!lstrcmpW(markerW,nomarkerW), "expected the character 0x%x to be ignored within the string\n", w); > + > +static void test_lstrcmpW(void) > +{ > + static const WCHAR nomarkerW[] = {'t','e','s','t',0}; > + static WCHAR markerW[] = {'t','e','r','s','t',0}; > + > + todo_wine > + { > + TESTMARKER(0x034f); > + TESTMARKER(0x0378); What this test is supposed to show? Is there a bug that prevents real world application not to function properly under Wine? Besides, lstrcmpW() is just a wrapper for CompareStringW(), and there is a bunch of tests for it already. Testing explicit unicode values is not useful, Wine uses different unicode tables than Windows does. -- Dmitry.

1 0

Re: [PATCH 6/7] wined3d: Add an initial fbo_blit_supported implementation.
by Henri Verbeet 09 Apr '10

09 Apr '10

On 8 April 2010 22:49, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > + /* Source and/or destination need to be on the GL side */ > + if (src_pool == WINED3DPOOL_SYSTEMMEM || dst_pool == WINED3DPOOL_SYSTEMMEM) > + return FALSE; ... > + if (!is_identity_fixup(src_format_desc->color_fixup) || > + !is_identity_fixup(dst_format_desc->color_fixup)) > + return FALSE; These weren't in the original function. Perhaps they should but, but as separate patches, please. > + if (!(src_format_desc->format == dst_format_desc->format > + || (is_identity_fixup(src_format_desc->color_fixup) > + && is_identity_fixup(dst_format_desc->color_fixup)))) > + return FALSE; This entire check would be redundant after the is_identity_fixup() checks above.

1 0

Re: kernel32: Add tests for lstrcmpW
by Paul Vriens 09 Apr '10

09 Apr '10

On 04/09/2010 01:12 PM, André Hentschel wrote: > +#define TESTMARKER(w) \ > + markerW[2] = w; \ > + ok(!lstrcmpW(markerW,nomarkerW), "expected the character 0x%x to be ignored within the string\n", w); Hi André, lstrcmpW is not implemented on Win95/98/Me so these tests will always succeed. You should probably add a lstrcmpW call at the beginning and skip when not implemented, something like: SetLastError(0xdeadbeef); lstrcmpW(markerW, nomarkerW); if (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED) { win_skip("lstrcmpW is not implemented\n"); return; } -- Cheers, Paul.

1 0

Re: [PATCH] d3dx9_36: Beginning of constants parsing + tests (based on work from Luis Busquets) (try 3) (resend)
by Alexandre Julliard 09 Apr '10

09 Apr '10

Christian Costa <titan.costa(a)wanadoo.fr> writes: > @@ -650,6 +650,29 @@ HRESULT WINAPI D3DXCompileShader(LPCSTR pSrcData, > return D3DERR_INVALIDCALL; > } > > +typedef struct ctab_constant ctab_constant; > + > +struct ctab_constant { > + D3DXCONSTANT_DESC desc; > + ctab_constant* members; > +}; > + > +inline ctab_constant* get_constant(D3DXHANDLE ptr) > +{ > + if (!ptr) return NULL; > + return (ctab_constant*)~((UINT_PTR)ptr); > +} > + > +inline D3DXHANDLE get_handle(ctab_constant* ptr) > +{ > + return (D3DXHANDLE)~((UINT_PTR)ptr); > +} > + > +inline BOOL isstring(D3DXHANDLE ptr) > +{ > + return !(((UINT_PTR)ptr) & (1 << (sizeof(UINT_PTR)*8-1))); > +} This is broken, you can't make assumptions about the high bit of pointer values. The handle management needs more thought. -- Alexandre Julliard julliard(a)winehq.org

2 1