Re: [test.winehq.org] Addition of todo on the results page
John Klehm wrote: Bit off topic: One thing that struck me was the difference in test results for the Wine runs. This has most likely to do with old Wine installations running new tests. I will add the Wine version to the infrastructure soon so that these outcomes make more sense. In the same vein of thinking perhaps there should be a registry key or file that records what version of wine created the .wine directory and that information should get recorded into the tests as well. -John Klehm The idea was to use the output of wine --version for this. When I said infrastructure I meant 'test results'. -- Cheers, Paul.
Re: What the web test reports need.
Jakob Eriksson wrote: We need a http://test.winehq.org/data/latest/ Which always points to the latest results. Instead of: http://test.winehq.org/data/200708221000/ etc... Who can fix this? regards, Jakob I was actually discussing this with Jeremy the other day but haven't found the inspiration yet. -- Cheers, Paul.
Re: [test.winehq.org] Addition of todo on the results page
Michael Stefaniuc wrote: Hello, Paul Vriens wrote: While I'm also busy with getting dll information on the page, I'm still adding stuff. This next iteration will add todo information on the pages. Current situation: http://test.winehq.org/data/200708221000/ There are several todo's for the Wine test but this is not shown on the page. New situation: http://www.xs4all.nl/~pvriens/200708221000_new/ The main difference is the yellow border on the left for some of the Wine tests (for the group shown in the Main Summary and individually at the Group 'Wine differences'). dumb question: how do you see if one of the Some tests fail in some reports has some todos too? Would be orange a better color for the left border? I picked orange only as it is a mix of yellow and red (in the subtractive color mixing /nitpick); not sure if somebody would get eye cancer from looking at the result. Hi Michael Thanks for taking to time to have a look. The answer is, you can't with yellow. I've experimented with some colors and went back to yellow all the time. (This mixed results AND todo is only for Wine results by the way.) Here's the one with orange: http://www.xs4all.nl/~pvriens/200708221000_new_orange the old one is now: http://www.xs4all.nl/~pvriens/200708221000_new_yellow/ I just hope we get more reports in in the future otherwise we will never have mixed results ;-). I'm also going to change the text in the legend, some tests need some work to something like implementation need some work. Cheers, Paul
Re: cabinet 4: Don't extract a file if DoExtract is FALSE
James Hawkins [EMAIL PROTECTED] writes: Changelog: * Don't extract a file if DoExtract is FALSE. This one fails make test: ../../../tools/runtest -q -P wine -M advpack.dll -T ../../.. -p advpack_test.exe.so files.c touch files.ok files.c:465: Test failed: Expected dest\testdir to exist files.c:466: Test failed: Expected dest\b.txt to not exist files.c:467: Test failed: Expected dest\testdir\d.txt to not exist files.c:474: Test failed: Expected dest\testdir to exist files.c:475: Test failed: Expected dest\b.txt to not exist files.c:476: Test failed: Expected dest\testdir\d.txt to not exist files.c:483: Test failed: Expected dest\testdir to not exist make[2]: *** [files.ok] Error 7 -- Alexandre Julliard [EMAIL PROTECTED]
Re: user32: static controls should have a clipping region set while sending the WM_CTLCOLORSTATIC (patch)
Mikolaj Zalewski [EMAIL PROTECTED] writes:
+static void setup_clipping(HWND hwnd, HDC hdc)
+{
+RECT rc;
+HRGN hrgn;
+
+/* Native control has always a clipping region set when sending
+ * the WM_CTLCOLORSTATIC and an application depends on it
+ */
+GetClientRect(hwnd, rc);
+hrgn = CreateRectRgn(rc.left, rc.top, rc.right, rc.bottom);
+if (GetClipRgn(hdc, hrgn) == 0)
+SelectClipRgn(hdc, hrgn);
+DeleteObject(hrgn);
+}
You need to set the region in all cases, intersecting with the
existing one if any. Also you need to restore the previous region
after painting.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: [test.winehq.org] Addition of todo on the results page
Paul Vriens wrote: John Klehm wrote: Bit off topic: One thing that struck me was the difference in test results for the Wine runs. This has most likely to do with old Wine installations running new tests. I will add the Wine version to the infrastructure soon so that these outcomes make more sense. In the same vein of thinking perhaps there should be a registry key or file that records what version of wine created the .wine directory and that information should get recorded into the tests as well. -John Klehm The idea was to use the output of wine --version for this. When I said infrastructure I meant 'test results'. Hi, Just to show you the opposite as well: http://test.winehq.org/data/200708241000/wine_2000_0.9.43-431-g0a485b3/cabinet:extract.txt Here can you see that winetest still has the old tests whereas my box was updated to the latest GIT just an hour ago. -- Cheers, Paul.
AMD release developer tools with DX10 support
I hope this is useful for testing DX10 stuff: Snippet: [AMD] has updated its range of game programming tools, adding in DirectX 10 support to its popular suite http://www.theinquirer.net/default.aspx?article=41904 Ian
Win API Stats page broken
The web page indicating the status of the wine API: http://www.winehq.org/site/winapi_stats is corrupted and indicates an SQL error. I assume that there is some information in the database corrupted: Warning: mysql_num_fields(): supplied argument is not a valid MySQL result resource in /home/winehq/opt/tools/winapi_stats.php on line 118 Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /home/winehq/opt/tools/winapi_stats.php on line 129 last modified: Fri Aug 24 9:53:14 CDT 2007 Who deals with it?
Regression at #9443 - caused by winex11: Force a window to managed mode when it is activated
Alexandre Julliard escribió: Module: wine Branch: master Commit: f48eb1581dfe176043cbca5c46400c0f86eb5552 URL: http://source.winehq.org/git/wine.git/?a=commit;h=f48eb1581dfe176043cbca5c46400c0f86eb5552 Author: Alexandre Julliard [EMAIL PROTECTED] Date: Mon Aug 20 22:06:50 2007 +0200 winex11: Force a window to managed mode when it is activated. --- This patch causes a regression in Visual Basic apps that display a drop-down combo - the drop-down is displayed behind the dialog instead of over it. Details and URL of demostration at http://bugs.winehq.org/show_bug.cgi?id=9443 . Just discovered it minutes ago. Reversing this patch fixes the regression. This is one of a series of patches on winex11 committed on August 20. Since they did not pass through wine-patches, I don't really know what are they supposed to fix. This is keeping me from simply submitting a reversal of this patch to wine-patches. Could somebody be so kind as to explain? Alex Villacís Lasso -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
