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

Re: 80135: [PATCH 05/10] gdi32: Implement SetPixel.

by Huw Davies

On Wed, Oct 19, 2011 at 06:46:49AM -0700, Dan Kegel wrote: > Patches 5-7 failed on WINEDEBUG=warn+heap here: > > ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p > gdi32_test.exe.so palette.c && touch palette.ok > ... > palette.c:104: Test failed: getColor=00280000 > > Might be flaky; patch 8 passed. patches 9 and 10 aren't done testing yet. It's because I wanted to move SetPixel and GetPixel in separate patches. I added a temporary todo_wine in patch 5 (SetPixel) to prevent this test failure, which then got removed in patch 8 (GetPixel). Huw.

Oct. 19, 2011

Re: Regression testing breakthrough

by Marcus Meissner

On Wed, Oct 19, 2011 at 02:42:29PM +0100, Ken Sharp wrote: > > > On 19/10/11 13:43, Frédéric Delanoy wrote: > >On Wed, Oct 19, 2011 at 14:08, Joel Holdsworth<joel(a)airwebreathe.org.uk> wrote: > >>Alternatively, have you considered doing a .tar.gz of every build snapshot, > >>and placing that on a server somewhere? > >> > >>e.g. a folder full of 36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files? > > > >tar.xz would compress better > > tar.lzma? Having tars of all builds would be way larger I guess. GIT compresses and shares objects that are the same. Ciao, Marcus

Oct. 19, 2011

Re: 80135: [PATCH 05/10] gdi32: Implement SetPixel.

by Dan Kegel

Patches 5-7 failed on WINEDEBUG=warn+heap here: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so palette.c && touch palette.ok ... palette.c:104: Test failed: getColor=00280000 Might be flaky; patch 8 passed. patches 9 and 10 aren't done testing yet. On Wed, Oct 19, 2011 at 6:18 AM, <buildbot(a)kegel.com> wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-heaptest while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-heaptest/builds/673 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine gdi32_test.exe.so palette.c > palette.c:104: Test failed: getColor=00280000 > make: *** [palette.ok] Error 1 > * Call to xpconnect wrapped JSObject produced this error: * > * Call to xpconnect wrapped JSObject produced this error: * > GnuTLS error: A TLS packet with unexpected length was received. > >

Oct. 19, 2011

Re: Regression testing breakthrough

by Ken Sharp

On 19/10/11 13:43, Frédéric Delanoy wrote: > On Wed, Oct 19, 2011 at 14:08, Joel Holdsworth<joel(a)airwebreathe.org.uk> wrote: >> Alternatively, have you considered doing a .tar.gz of every build snapshot, >> and placing that on a server somewhere? >> >> e.g. a folder full of 36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files? > > tar.xz would compress better tar.lzma?

Oct. 19, 2011

Re: Anyone wants to ban spammer on forum

by Ken Sharp

On 19/10/11 03:37, Vitaliy Margolen wrote: > On 10/18/2011 07:37 PM, Vitaliy Margolen wrote: >> So any admins actually watching and want to bad roberbdib3a on forum? >> >> Also why aren't every moderator has these rights to block spammers, >> since we >> have only one forum. >> > So no takers? I'm guessing we need more forum admins then, so more > timezones can be covered. I rarely use the forums but if it's that bad I would happily look in a few times a day. UTC+1 > > Vitaliy. > > >

Oct. 19, 2011

Re: [PATCH 1/2] gdi32: Add a string table resource for the translation.

by Alexandre Julliard

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > On Tue, 18 Oct 2011 16:14:36 +0200, Alexandre Julliard wrote: >> Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: >> >> > @@ -1,7 +1,7 @@ >> > EXTRADEFS = -D_GDI32_ >> > MODULE = gdi32.dll >> > IMPORTLIB = gdi32 >> > -IMPORTS = advapi32 >> > +IMPORTS = advapi32 user32 >> >> You don't want to import user32 from gdi32. > > LoadStringW is in user32.dll. Should I use DELAYIMPORTS instead? No, you should do it by hand using kernel32 resource functions. And you should do that only when needed, not on every startup. -- Alexandre Julliard julliard(a)winehq.org

Oct. 19, 2011

Re: Regression testing breakthrough

by Frédéric Delanoy

On Wed, Oct 19, 2011 at 14:08, Joel Holdsworth <joel(a)airwebreathe.org.uk> wrote: > Alternatively, have you considered doing a .tar.gz of every build snapshot, > and placing that on a server somewhere? > > e.g. a folder full of 36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files? tar.xz would compress better > Then one could write a simple wine regression bisect tool that implements > similar semantics to git bisect, but would essentially wrap wget. Then in > your server you could have an index file which is a list of the sha commit > ids. > > This would save the user having to clone a 26Gb repository when most of the > commits will be irrelevant. Cloning a multi-gig repository is a no-go for many (most?) people, especially for a regression testing they might do only once or twice... > > Extra bonus points for doing a better job of compressing the small deltas > between binaries*, rather than compressing full wine builds. Maybe you could use stuff like xdelta or bsdiff, but then you may have some issues IMO: - (not sure) you should use them on non-compressed files (e.g. .tar) to get small diffs - the total size of individual diffs to download could exceed a single, full, download (especially for old regressions) To make regression faster/easier, we could (in a script of some sort) - phase 1: detect the "release range failure" (failed between wine-1.X.N and wine-1.X.N+1) using only release binaries [or instruct people to do that first using their distrib packages, like RegressionTesting does IIRC] - phase 2: perform bisect between these two releases Just my 2 ¢ Frédéric

Oct. 19, 2011

Re: [3/7] d3d9/tests: Add a test for locking partial blocks (try 2)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 19.10.2011 um 11:49 schrieb Henri Verbeet: > On 18 October 2011 17:37, Henri Verbeet <hverbeet(a)gmail.com> wrote: >> patch 3/7". The point is that test_lockrect_offset() is about the >> offset calculation, not so much about what valid rectangles for block >> based formats are. Tbh I don't see the point in separating those two since both are determined by the block size, but OK. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJOnsGzAAoJEN0/YqbEcdMw3TkP/Rbg9Of3+rt2VGa+5WfEMQm+ 9RMhEEKczrRESh2vqDTpgufsIvGOwrbAmeDG7s89KpUwIBKawyoJhg2lR84/hwH5 DCyUxqKqYDbZzQt84AxHhEUfSvqCa7K4myLIT4BK1IFksI81NSVDTuYL/DtOWuFN KCx2J+z/BlZsURpJM2bGOmDbdy3iLuTYtSNuZFmjNbYVKYKSF3vGXQ1gUEmAdOFn i4BT+WhpFaVBN/YxXIlmwQ7lWuwiJwWDZZAiIAyTZAp+n9H0VE6P49y4kpH8otab AC3p5VV2QlmQyG2iir6WkYX4N/9z8cq6Mv/FRC87IZsIWPAS05XlJdAdWUlaAvO6 Gm81Gxd3WILnKtYvp9g2xhqesd4ZSVQyXNonglcLmKLIbR7hEGm7MWW+V7gyZrCF pjLDMlsg9h8ket7Dcpi9hA/q/8ChYh/dw7LKR8fbAcujgiCQaS3aork/O3CnVenu GO6rZtqFOj19gDcClbD07h8bDnPvKLMeCXNt7S4QIUhrQ8LAzLG1YDHogDxmNAau EDdq4dkfuabbJkMSiDeRAGsMHY99fSk+7fB8pOsEx2AgP2GnfynePboshsDVp3ri 0pKMklL4/2EsYZjca4x6ejqh2+iTdwlWiddIQa60vV9XolEHp4/TM4tIKCUdzfzJ fT3zosKQ6ZakgJ3KopoS =XwMm -----END PGP SIGNATURE-----

Oct. 19, 2011

Re: Anyone wants to ban spammer on forum

by L. Rahyen

On 2011-10-19 (October, Wednesday) 02:37:41 Vitaliy Margolen wrote: > On 10/18/2011 07:37 PM, Vitaliy Margolen wrote: > > So any admins actually watching and want to bad roberbdib3a on forum? > > > > Also why aren't every moderator has these rights to block spammers, since > > we have only one forum. > > So no takers? I'm guessing we need more forum admins then, so more > timezones can be covered. I agree. I and other morerators have deleted spam messages, but the spammer kept using the same account to post more. Inability to ban spammer's account is frustrating. I would happely volonteer to be forum admin so I can ban spammers.

Oct. 19, 2011

Re: Regression testing breakthrough

by Joel Holdsworth

Alternatively, have you considered doing a .tar.gz of every build snapshot, and placing that on a server somewhere? e.g. a folder full of36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files? Then one could write a simple wine regression bisect tool that implements similar semantics to git bisect, but would essentially wrap wget. Then in your server you could have an index file which is a list of the sha commit ids. This would save the user having to clone a 26Gb repository when most of the commits will be irrelevant. Extra bonus points for doing a better job of compressing the small deltas between binaries*, rather than compressing full wine builds. Joel * Are binaries deterministic like this? or do they tend to be completely scrambled? On 18 October 2011 at 09:45 Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > Hi > > Since the beginning, I've had issues with regression testing. Despite the > fact it's very useful, it takes forever, it's easy to make a mistake > (especially during "reverse regression testing"), users find it too long and > technical, and only a small minority of regressions are ever bisected. And > several patches need backporting to allow older versions of Wine to compile > and run on today's make, gcc, and libraries - this is the case even for the > 1.0.x releases from less than 3 years ago! > > The problem is of course compilation. "configure" takes at least 40 seconds, > without any way to speed it up on multi-core CPUs. "make" takes > 5 minutes, > and it's only taking longer as Wine gets bigger. Compilation is > fundamentally complex and technical to users. > > But what if we had precompiled binaries, and regression testing consisted of > just running different versions of Wine? > > Wine binaries take up about 122 MB and take over 5 minutes to compile. > There's now 35770 commits between 36def4af0ca85a1d0e66b5207056775bcb3b09ff > (Release 1.0) and "origin". That's about 4.4 terrabytes of storage and over > 4 months of compilation, if each of those versions had to be compiled and > installed into its own prefix, way beyond what most users are willing or > able to store or do. Most patches however end up affecting only a few binary > files in the end, and compiling successive versions allows "make" to be very > quick. > > So I've written a tool that compiles Wine and adds each commit's binaries > into a Git repository. It knows how to compile old versions of Wine > (currently as far back as 1.0). It knows that commits affecting only > ANNOUNCE, .gitignore, and files in dll/ or programs/ ending with .c and such > don't need to go through the endlessly slow "configure", only "make". It is > stateless: if interrupted, it can resume from the last successful commit. It > works around bugs in GNU make (you won't believe how many there are...). > > This tool compiled all 35000 or so commits from Wine 1.0 to around 4th > October 2011 in only 7 days, generating a Git repository of Wine binaries > that's only 26 gigabytes in size. Regression testing with binaries is a > pleasure: it takes only a few seconds :-) on each bisection. I bisected a 16 > step regression in just 20 minutes, and most of that time was spent running > the application and dealing with 2 X-server crashes. > > I haven't figured out how to make the binaries available to users. Few users > can clone a 26 gigabyte repository, and even fewer places can serve that > much to multiple users. Maybe Git can compress it further? The other idea I > had is that users should be able to regression test through a GUI tool. > Maybe the GUI tool can just download and run the +/- 122 MB binary snapshots > for specific commits, instead of having the entire binary repository > locally? > > Any other ideas? Would you like to see this tool? Can I send an attachment > with it? > > Thank you > Damjan Jovanovic

Oct. 19, 2011

Re: [3/7] d3d9/tests: Add a test for locking partial blocks (try 2)

by Henri Verbeet

On 18 October 2011 17:37, Henri Verbeet <hverbeet(a)gmail.com> wrote: > patch 3/7". The point is that test_lockrect_offset() is about the > offset calculation, not so much about what valid rectangles for block > based formats are.

Oct. 19, 2011

Re: [PATCH] kernel32: Output message to stderr in UTF-8

by Dmitry Timoshkov

Alex Henrie <alexhenrie24(a)gmail.com> wrote: > - WideCharToMultiByte( CP_ACP, 0, msgW, -1, msg, sizeof(msg), NULL, NULL ); > + WideCharToMultiByte( CP_UTF8, 0, msgW, -1, msg, sizeof(msg), NULL, NULL ); > MESSAGE( "wine: %s", msg ); Try CP_UNIXCP intead. -- Dmitry.

Oct. 19, 2011

Re: [PATCH 1/2] gdi32: Add a string table resource for the translation.

by Akihiro Sagawa

On Tue, 18 Oct 2011 16:14:36 +0200, Alexandre Julliard wrote: > Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > > > @@ -1,7 +1,7 @@ > > EXTRADEFS = -D_GDI32_ > > MODULE = gdi32.dll > > IMPORTLIB = gdi32 > > -IMPORTS = advapi32 > > +IMPORTS = advapi32 user32 > > You don't want to import user32 from gdi32. LoadStringW is in user32.dll. Should I use DELAYIMPORTS instead? -- Akihiro Sagawa

Oct. 19, 2011

Re: Anyone wants to ban spammer on forum

by Vitaliy Margolen

On 10/18/2011 07:37 PM, Vitaliy Margolen wrote: > So any admins actually watching and want to bad roberbdib3a on forum? > > Also why aren't every moderator has these rights to block spammers, since we > have only one forum. > So no takers? I'm guessing we need more forum admins then, so more timezones can be covered. Vitaliy.

Oct. 18, 2011

Anyone wants to ban spammer on forum

by Vitaliy Margolen

So any admins actually watching and want to bad roberbdib3a on forum? Also why aren't every moderator has these rights to block spammers, since we have only one forum. - Vitaliy

Oct. 18, 2011

Fix Bug 23124 with an "ln -s"

by Ken Sharp

http://bugs.winehq.org/show_bug.cgi?id=23124 Could someone tell me if the attached patch would actually work? It does compile and works correctly with LANG=en_PH.utf-8 but I'm don't know that: 1. Using an "ln -s" is acceptable, nor if it will work given some file systems may be unable to use soft links. 2. I have correctly edited configure, configure.ac and LINGUAS, or even if I need to edit both. Thanks all, Ken

Oct. 18, 2011

Re: 80121: aclocal.m4: fix compiles on systems that don't support ln -s

by Austin English

On Tue, Oct 18, 2011 at 16:34, <buildbot(a)kegel.com> wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/678 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_2 > > Errors: > make[1]: *** [avifile.dll16.so] Error 2 > make: *** [dlls/avifile.dll16] Error 2 > make: *** Waiting for unfinished jobs.... Hm, worked here, though trying it again with plain make rather than make -jX, fails. Needs more investigation. Please don't commit. -- -Austin

Oct. 18, 2011

Re: [3/7] d3d9/tests: Add a test for locking partial blocks (try 2)

by Stefan Dösinger

On Tuesday 18 October 2011 20:12:35 Stefan Dösinger wrote: > On Tuesday 18 October 2011 19:36:33 Stefan Dösinger wrote: > > I felt that merging the tests to test all format and pool combinations > > would cause needlessly complicated > > With a few simplifications like skipping all tests without dynamic textures > it turns out okish. It's not too pretty. There are still a bunch of checks > for caps and pools, but it should be readable. This is a version of the patch with both tests merged into one that tests all format-pool combinations. I'll resend the patches tomorrow unless you have further suggestions. I changed the d3d8 patch in a similar way.

Oct. 18, 2011

Odd valgrind warning on ubuntu 11.10 related to set_wm_hints

by Dan Kegel

I've added a suppression for this already to http://code.google.com/p/winezeug/source/browse/trunk/valgrind/valgrind-sup… It looks benign, but it's annoying because the suppression it needs is so wide. I wonder if the gcc bug on ubuntu 11.10 is why there's no useful backtrace there... Syscall param writev(vector[...]) points to uninitialised byte(s) at writev (writev.c:51) by 0x40004: ??? Address 0x4598748 is 160 bytes inside a block of size 16,384 alloc'd at calloc (vg_replace_malloc.c:467) by XOpenDisplay (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0) by x11drv_init_thread_data (x11drv_main.c:689) by thread_init_display (x11drv.h:580) by X11DRV_create_win_data (window.c:2030) by X11DRV_WindowPosChanging (window.c:2429) by set_window_pos (winpos.c:1951) by USER_SetWindowPos (winpos.c:2077) by SetWindowPos (winpos.c:2151) by show_window (winpos.c:1088) by ShowWindow (winpos.c:1186) by WIN_CreateWindowEx (win.c:1498) by CreateWindowExA (win.c:1550) by init (comboex.c:505) by func_comboex (comboex.c:598) by run_test (test.h:556) by main (test.h:624) Uninitialised value was created by a stack allocation at set_wm_hints (window.c:1128)

Oct. 18, 2011

Re: registry keys of serial ports

by Stefan Leichter

Am Dienstag 18 Oktober 2011, 22:28:26 schrieb Uwe Bonnes: > Hello, > > while hunting down why a drop down box didn't offer me the serial port I > configured, I stumbled across Stefans proposal from Summer 09. The patch > still applied cleanly, and after setting up hal and the hal development > library, the progarm worked as expected. > > What is the status of that proposal? > > Thanks > Hello Uwe, all, looks like i forgot about the stuff for some reason. This is the first bad message. The second one is, that i do not have time to look into this before the end of the year. So if you or anybody else like to work on this stuff, feel free .. Stefan

Oct. 18, 2011

Re: Regression testing breakthrough

by Damjan Jovanovic

2011/10/18 André Hentschel <nerv(a)dawncrow.de> > Am 18.10.2011 10:45, schrieb Damjan Jovanovic: > > This tool compiled all 35000 or so commits from Wine 1.0 to around 4th > October 2011 in only 7 days, generating a Git repository of Wine binaries > that's only 26 gigabytes in size. Regression testing with binaries is a > pleasure: it takes only a few seconds :-) on each bisection. I bisected a 16 > step regression in just 20 minutes, and most of that time was spent running > the application and dealing with 2 X-server crashes. > > I already love it. > > Thank you :) > > I haven't figured out how to make the binaries available to users. Few > users can clone a 26 gigabyte repository, and even fewer places can serve > that much to multiple users. Maybe Git can compress it further? The other > idea I had is that users should be able to regression test through a GUI > tool. Maybe the GUI tool can just download and run the +/- 122 MB binary > snapshots for specific commits, instead of having the entire binary > repository locally? > > tried compressing the .git directory. or maybe "git gc" can help > > > Would you like to see this tool? Can I send an attachment with it? > > If the tool is not too big and is textual, why not > > I've opened a Google Code project: http://raisinrefinery.googlecode.com No releases yet, but you can: svn co http://raisinrefinery.googlecode.com/svn/trunk/RaisinRefinery cd RaisinRefinery mvn package java -jar RaisinRefinery/target/RetroRaisinCellar-0.1-SNAPSHOT.jar 8a7bc4c727fe6330efdfbbb24e6666ee39364c0d..origin /path/to/wine-git /path/to/binary-repository to compile the last 5 commits in today's Git.

Oct. 18, 2011

Re: registry keys of serial ports

by Uwe Bonnes

Hello, while hunting down why a drop down box didn't offer me the serial port I configured, I stumbled across Stefans proposal from Summer 09. The patch still applied cleanly, and after setting up hal and the hal development library, the progarm worked as expected. What is the status of that proposal? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Oct. 18, 2011

Re: po: Update English (US) translation

by Ken Sharp

On 18/10/11 6:35 PM, Alexandre Julliard wrote: > Ken Sharp<kennybobs(a)o2.co.uk> writes: > >> So any changes made should be in both the .rc files AND the .po files >> to keep them in sync? > I resynchronize en_US.po when committing, so you don't need to submit > that part. http://source.winehq.org/patches/data/79974 This should be right then?

Oct. 18, 2011

Re: po: Update English (US) translation

by Ken Sharp

On 18/10/11 6:35 PM, Alexandre Julliard wrote: > Ken Sharp<kennybobs(a)o2.co.uk> writes: > >> So any changes made should be in both the .rc files AND the .po files >> to keep them in sync? > I resynchronize en_US.po when committing, so you don't need to submit > that part. > Excellent, thanks Alexandre, that's what I was looking for. I'll resubmit.

Oct. 18, 2011

Re: Regression testing breakthrough

by André Hentschel

Am 18.10.2011 10:45, schrieb Damjan Jovanovic: > This tool compiled all 35000 or so commits from Wine 1.0 to around 4th October 2011 in only 7 days, generating a Git repository of Wine binaries that's only 26 gigabytes in size. Regression testing with binaries is a pleasure: it takes only a few seconds :-) on each bisection. I bisected a 16 step regression in just 20 minutes, and most of that time was spent running the application and dealing with 2 X-server crashes. I already love it. > I haven't figured out how to make the binaries available to users. Few users can clone a 26 gigabyte repository, and even fewer places can serve that much to multiple users. Maybe Git can compress it further? The other idea I had is that users should be able to regression test through a GUI tool. Maybe the GUI tool can just download and run the +/- 122 MB binary snapshots for specific commits, instead of having the entire binary repository locally? tried compressing the .git directory. or maybe "git gc" can help > Would you like to see this tool? Can I send an attachment with it? If the tool is not too big and is textual, why not -- Best Regards, André Hentschel

Oct. 18, 2011

Re: [3/7] d3d9/tests: Add a test for locking partial blocks (try 2)

by Stefan Dösinger

On Tuesday 18 October 2011 19:36:33 Stefan Dösinger wrote: > I felt that merging the tests to test all format and pool combinations > would cause needlessly complicated With a few simplifications like skipping all tests without dynamic textures it turns out okish. It's not too pretty. There are still a bunch of checks for caps and pools, but it should be readable.

Oct. 18, 2011

Re: [3/7] d3d9/tests: Add a test for locking partial blocks (try 2)

by Stefan Dösinger

On Tuesday 18 October 2011 17:37:09 Henri Verbeet wrote: > That's not really what I meant with "make this part of the test in > patch 3/7". The point is that test_lockrect_offset() is about the > offset calculation, not so much about what valid rectangles for block > based formats are. And it probably wouldn't hurt to run > test_partial_block_lock() on the other formats like e.g. ATI2N anyway. I felt that merging the tests to test all format and pool combinations would cause needlessly complicated code because some format-pool combinations require surfaces, some require dynamic textures, some require normal textures and some are unsupported. That's why I introduced the new test that loops only over the pools. On the other hand we may at some point care about the offset returned by a allowed partial block lock, which is why putting the per-format test in test_partial_block_lock correct imo. Strictly speaking the test now verifies the block sizes directly instead of just verifying them indirectly as a side product of testing the stride, so we might as well rename it. ATI2N is a good point though. The locking behavior matches the 1x1 "block" definition in the d3d9 test. I'll change the test to verify that we can indeed lock single pixels in formats that are supposedly block-free(and that we can lock single lines in YUY2/UYVY)

Oct. 18, 2011

Re: po: Update English (US) translation

by Alexandre Julliard

Ken Sharp <kennybobs(a)o2.co.uk> writes: > So any changes made should be in both the .rc files AND the .po files > to keep them in sync? I resynchronize en_US.po when committing, so you don't need to submit that part. -- Alexandre Julliard julliard(a)winehq.org

Oct. 18, 2011

Re: Regression testing breakthrough

by Austin English

On Tue, Oct 18, 2011 at 10:26, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Austin English <austinenglish(a)gmail.com> wrote: > > >> > Reverting a patch in latest git is not always possible, instead it's >> > a very useful test to revert the patch at the suspected regression point >> > and see if that really helps. >> >> That still doesn't require a full regression test, just: >> $ git checkout -f $SHA1SUM >> $ ./configure && make -j4 >> # test >> $ git show $SHA1SUM | patch -p1 -R >> $ ./configure && make -j4 >> # retest > > How do you know that $SHA1SUM without a regression test? I was referring to the case you pointed out: > Moreover, often users get asked 'does reverting commit xxxx' help? Without > performing a proper regression test it's impossible to asnwer that question. If a developer asks about a specific commit, then of course you know which one to try :). Otherwise, of course a full regression test is required. -- -Austin

Oct. 18, 2011

Re: Regression testing breakthrough

by Dmitry Timoshkov

Austin English <austinenglish(a)gmail.com> wrote: > > Reverting a patch in latest git is not always possible, instead it's > > a very useful test to revert the patch at the suspected regression point > > and see if that really helps. > > That still doesn't require a full regression test, just: > $ git checkout -f $SHA1SUM > $ ./configure && make -j4 > # test > $ git show $SHA1SUM | patch -p1 -R > $ ./configure && make -j4 > # retest How do you know that $SHA1SUM without a regression test? -- Dmitry.

Oct. 18, 2011

Re: Regression testing breakthrough

by Austin English

On Tue, Oct 18, 2011 at 09:01, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: >> > Moreover, often users get asked 'does reverting commit xxxx' help? Without >> > performing a proper regression test it's impossible to asnwer that >> > question. >> > >> > >> Reverting a commit in the latest git is just 1 round of >> patch+configure+make+run, and reverting to the commit before it in the >> binary repository is just one git command. Why would you need a "proper >> regression test"? > > Reverting a patch in latest git is not always possible, instead it's > a very useful test to revert the patch at the suspected regression point > and see if that really helps. That still doesn't require a full regression test, just: $ git checkout -f $SHA1SUM $ ./configure && make -j4 # test $ git show $SHA1SUM | patch -p1 -R $ ./configure && make -j4 # retest -- -Austin

Oct. 18, 2011

Re: po: Update English (US) translation

by Ken Sharp

On 18/10/11 17:05, Alexandre Julliard wrote: > Ken Sharp<kennybobs(a)o2.co.uk> writes: > >> Okay that should be simple enough, but what is po/en_US.po for then? >> Won't the translations in en_US.po override any US translations in the >> .rc files? > > Yes, but in general they should be identical. We have en_US.po because > there are cases where strings need to be different, for instance when > the .rc string contains a context, or non-ASCII chars. > So any changes made should be in both the .rc files AND the .po files to keep them in sync?

Oct. 18, 2011

Re: po: Update English (US) translation

by Alexandre Julliard

Ken Sharp <kennybobs(a)o2.co.uk> writes: > Okay that should be simple enough, but what is po/en_US.po for then? > Won't the translations in en_US.po override any US translations in the > .rc files? Yes, but in general they should be identical. We have en_US.po because there are cases where strings need to be different, for instance when the .rc string contains a context, or non-ASCII chars. -- Alexandre Julliard julliard(a)winehq.org

Oct. 18, 2011

Re: Regression testing breakthrough

by Dmitry Timoshkov

Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > Moreover, often users get asked 'does reverting commit xxxx' help? Without > > performing a proper regression test it's impossible to asnwer that > > question. > > > > > Reverting a commit in the latest git is just 1 round of > patch+configure+make+run, and reverting to the commit before it in the > binary repository is just one git command. Why would you need a "proper > regression test"? Reverting a patch in latest git is not always possible, instead it's a very useful test to revert the patch at the suspected regression point and see if that really helps. -- Dmitry.

Oct. 18, 2011

Re: Regression testing breakthrough

by Damjan Jovanovic

On Tue, Oct 18, 2011 at 2:32 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Henri Verbeet <hverbeet(a)gmail.com> wrote: > > > On 18 October 2011 10:45, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > > (especially during "reverse regression testing"), users find it too > long and > > > technical, and only a small minority of regressions are ever bisected. > And > > Not true. Even for the regressions that are still open it's currently > > 276 bisected vs. 99 not bisected, and Alexandre said about 90% of > > opened regressions get fixed. > > Moreover, often users get asked 'does reverting commit xxxx' help? Without > performing a proper regression test it's impossible to asnwer that > question. > > Reverting a commit in the latest git is just 1 round of patch+configure+make+run, and reverting to the commit before it in the binary repository is just one git command. Why would you need a "proper regression test"?

Oct. 18, 2011

Re: [3/7] d3d9/tests: Add a test for locking partial blocks (try 2)

by Henri Verbeet

On 18 October 2011 12:43, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Changes: Check for dynamic texture support, moved the format-specific tests to > this patch. > That's not really what I meant with "make this part of the test in patch 3/7". The point is that test_lockrect_offset() is about the offset calculation, not so much about what valid rectangles for block based formats are. And it probably wouldn't hurt to run test_partial_block_lock() on the other formats like e.g. ATI2N anyway.

Oct. 18, 2011

Re: po: Update English (US) translation

by Ken Sharp

On 18/10/11 16:15, Frédéric Delanoy wrote: > On Tue, Oct 18, 2011 at 17:01, Francois Gouget<fgouget(a)free.fr> wrote: >> My understanding it that en.po contains the British translation and is >> treated as just another translation. So instead of containing just the >> strings that need to be different, all the other strings are copied as >> well by the translators so they know what has been checked already. > > For clarity, we should probably have no en_US.po but only en.po (and > possibly other en_XX.po like en_GB.po) > maybe a soft link from en_US.po to en.po to make it clear) If en.po is British English there will be a fair few differences for en_US.po (and en_PH.po). > > The current situation (en.po and en_US.po) makes it look like en_US.po > is an "adapted" version of "standard" en.po (which is then presumably > en_GB), as is e.g. fr_CA vs fr.po > > This is not the first time someone adapts the en_US.po IIRC. > > Frédéric >

Oct. 18, 2011

Re: po: Update English (US) translation

by Ken Sharp

On 18/10/11 16:01, Francois Gouget wrote: > On Tue, 18 Oct 2011, Ken Sharp wrote: > [...] >> Okay that should be simple enough, but what is po/en_US.po for then? Won't the >> translations in en_US.po override any US translations in the .rc files? > > Currently it's 100% translated and I suspect all strings are simply > copied as is: > > 2524 (100.0%) translated, 0 (0.0%) fuzzy, 0 (0.0%) untranslated, total 2524 As I understand it, en_US is picked up by _ENGLISH_US or _DEFAULT. _DEFAULT obviously being the default English sublang, but also US should be the fallback. http://wiki.winehq.org/SublangNeutral So either _DEFAULT _is_ US English and hence only the _DEFAULT needs to be translated to US English (and hence there being no actual need for a US translation) or _DEFAULT should be in British English (and hence no need for a British translation). Of course the same link states that _NEUTRAL should be a British translation (and again _ENGLISH_BRITISH would serve no purpose). The other English sublangs pick up the translation from _NEUTRAL which makes sense, but _US picks up _DEFAULT. So... _DEFAULT = _US _NEUTRAL = _BRITISH _US = obsolete _BRITISH = obsolete And all other sublangs = _NEUTRAL > > > Where it gets a bit strange is that en.po is partially translated even > though it claims to be 'Automatically Generated' (so I'd expect either > 0% or 100%): I think the "Automatically Generated" statement comes from when they were created to replace .rc translations. This is updated automatically when using poedit by your own details, but I won't use poedit as it insists on changing the layout of the existing .po files (which may actually be for the best in the long-run). However, I may simply be misunderstanding this and they are automatically generated from the .rc files. If so then this would clear things up for me no end. I would finally see the light! > > 1748 (69.3%) translated, 0 (0.0%) fuzzy, 776 (30.7%) untranslated, total 2524 > > > My understanding it that en.po contains the British translation and is > treated as just another translation. So instead of containing just the > strings that need to be different, all the other strings are copied as > well by the translators so they know what has been checked already. > If en.po is British (and it is automatically generated) it *should* be picking up _NEUTRAL and _BRITISH translations from the .rc files. If this is the case then en_*.po (with the exception of en_US.po) will be almost identical. Could anyone clarify this? The translation Wiki entry doesn't make this abundantly clear to me. Apologies for the confusion.

Oct. 18, 2011

Re: po: Update English (US) translation

by Frédéric Delanoy

On Tue, Oct 18, 2011 at 17:01, Francois Gouget <fgouget(a)free.fr> wrote: > My understanding it that en.po contains the British translation and is > treated as just another translation. So instead of containing just the > strings that need to be different, all the other strings are copied as > well by the translators so they know what has been checked already. For clarity, we should probably have no en_US.po but only en.po (and possibly other en_XX.po like en_GB.po) maybe a soft link from en_US.po to en.po to make it clear) The current situation (en.po and en_US.po) makes it look like en_US.po is an "adapted" version of "standard" en.po (which is then presumably en_GB), as is e.g. fr_CA vs fr.po This is not the first time someone adapts the en_US.po IIRC. Frédéric

Oct. 18, 2011

Re: po: Update English (US) translation

by Francois Gouget

On Tue, 18 Oct 2011, Ken Sharp wrote: [...] > Okay that should be simple enough, but what is po/en_US.po for then? Won't the > translations in en_US.po override any US translations in the .rc files? Currently it's 100% translated and I suspect all strings are simply copied as is: 2524 (100.0%) translated, 0 (0.0%) fuzzy, 0 (0.0%) untranslated, total 2524 Where it gets a bit strange is that en.po is partially translated even though it claims to be 'Automatically Generated' (so I'd expect either 0% or 100%): 1748 (69.3%) translated, 0 (0.0%) fuzzy, 776 (30.7%) untranslated, total 2524 My understanding it that en.po contains the British translation and is treated as just another translation. So instead of containing just the strings that need to be different, all the other strings are copied as well by the translators so they know what has been checked already. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ All generalizations are false, including this one. -- Mark Twain

Oct. 18, 2011

Re: po: Update English (US) translation

by Ken Sharp

On 18/10/11 15:23, Alexandre Julliard wrote: > Ken Sharp<kennybobs(a)o2.co.uk> writes: > >> From 68519bf26da3d912bf92febc13a34ec00cfd7cc4 Mon Sep 17 00:00:00 2001 >> From: Ken Sharp<kennybobs(a)o2.co.uk> >> Date: Sat, 15 Oct 2011 03:50:43 +0100 >> Subject: [PATCH] po: Update English (US) translation > > There's no translation to update, the rc files are already en_US. If the > strings need changing they have to be changed in the rc files. > Okay that should be simple enough, but what is po/en_US.po for then? Won't the translations in en_US.po override any US translations in the .rc files?

Oct. 18, 2011

Re: po: Update English (US) translation

by Alexandre Julliard

Ken Sharp <kennybobs(a)o2.co.uk> writes: > From 68519bf26da3d912bf92febc13a34ec00cfd7cc4 Mon Sep 17 00:00:00 2001 > From: Ken Sharp <kennybobs(a)o2.co.uk> > Date: Sat, 15 Oct 2011 03:50:43 +0100 > Subject: [PATCH] po: Update English (US) translation There's no translation to update, the rc files are already en_US. If the strings need changing they have to be changed in the rc files. -- Alexandre Julliard julliard(a)winehq.org

Oct. 18, 2011

Re: [PATCH 1/2] gdi32: Add a string table resource for the translation.

by Alexandre Julliard

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > @@ -1,7 +1,7 @@ > EXTRADEFS = -D_GDI32_ > MODULE = gdi32.dll > IMPORTLIB = gdi32 > -IMPORTS = advapi32 > +IMPORTS = advapi32 user32 You don't want to import user32 from gdi32. -- Alexandre Julliard julliard(a)winehq.org

Oct. 18, 2011

Re: Regression testing breakthrough

by Frédéric Delanoy

On Tue, Oct 18, 2011 at 13:42, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > If you are talking about using compiling with ccache instead of the binary > repository, "configure" alone is > 40 seconds configure -C option can speed it up a lot

Oct. 18, 2011

Re: mshtml: Added IHTMLDocument2::elementFromPoint implementation

by Jacek Caban

On 10/18/11 15:22, Marvin wrote: > 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=14979 > > Your paranoid android. > > > === TEST64_W7SP1 (32 bit htmldoc) === > htmldoc.c:2865: Test failed: unexpected cmd 109 of CGID_Explorer > htmldoc.c:4446: Test failed: tag = L"BODY" > > === TEST64_W7SP1 (64 bit htmldoc) === > htmldoc.c:2865: Test failed: unexpected cmd 109 of CGID_Explorer > htmldoc.c:4446: Test failed: tag = L"BODY" That machine is already failing on a lot of tests and needs more work before its results are meaningful. Jacek

Oct. 18, 2011

Re: mshtml: Added IHTMLDocument2::elementFromPoint implementation

by Marvin

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=14979 Your paranoid android. === TEST64_W7SP1 (32 bit htmldoc) === htmldoc.c:2865: Test failed: unexpected cmd 109 of CGID_Explorer htmldoc.c:4446: Test failed: tag = L"BODY" === TEST64_W7SP1 (64 bit htmldoc) === htmldoc.c:2865: Test failed: unexpected cmd 109 of CGID_Explorer htmldoc.c:4446: Test failed: tag = L"BODY"

Oct. 18, 2011

Re: Regression testing breakthrough

by Dmitry Timoshkov

Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 18 October 2011 10:45, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > (especially during "reverse regression testing"), users find it too long and > > technical, and only a small minority of regressions are ever bisected. And > Not true. Even for the regressions that are still open it's currently > 276 bisected vs. 99 not bisected, and Alexandre said about 90% of > opened regressions get fixed. Moreover, often users get asked 'does reverting commit xxxx' help? Without performing a proper regression test it's impossible to asnwer that question. -- Dmitry.

Oct. 18, 2011

Re: Regression testing breakthrough

by Henri Verbeet

On 18 October 2011 13:42, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > There's currently another 182 regressions that were closed "ABANDONED". > Maybe if regression testing was easier and faster, people wouldn't abandon > them? > Maybe. That's 182 closed ABANDONED, out of 2590 total closed, so that's on the order of 5-10%. Perhaps it's possible to bring that down by making it easier to do bisects, but it's hardly the case that "only a small minority of regressions are ever bisected". > If you are talking about using compiling with ccache instead of the binary > repository, "configure" alone is > 40 seconds, while the average "git > bisect" on the binary repository is about 4. If you are talking about using > ccache to speed up building the binary repository commit by commit, why, > when for most commits "make" takes about 5 seconds and skips all unnecessary > compilation anyway? > > The other advantage I see is the convenience: instead of having to wait or > take breaks while each commit compiles like in normal regression testing, > you can have the tool compile you a small set of revisions (eg. the last > month) while you are away from your computer, then just quickly test them > all in one go when you come back. And you can regression test several > applications without repeatedly compiling Wine. > Regardless of whether this has much advantages over e.g. ccache, it does strike me that this would mostly be useful for people that do a lot of regression testing already. If it allows those people to do regressions tests faster and find more regressions or find them sooner that way that's great, but these aren't the same people that end up abandoning regressions. The problems there are typically more on the level of "What is git?" / "How do I build Wine?" / "Where do I get all these dependencies?", and typically someone would only do one or two bisects.

Oct. 18, 2011

Re: Regression testing breakthrough

by Scott Ritchie

Exciting! On 10/18/2011 01:45 AM, Damjan Jovanovic wrote: > I haven't figured out how to make the binaries available to users. Few > users can clone a 26 gigabyte repository, and even fewer places can > serve that much to multiple users. Maybe Git can compress it further? > The other idea I had is that users should be able to regression test > through a GUI tool. Maybe the GUI tool can just download and run the +/- > 122 MB binary snapshots for specific commits, instead of having the > entire binary repository locally? > > Any other ideas? Would you like to see this tool? Can I send an > attachment with it? > Perhaps you could use an intermediary server and a script. The user tells the script "works" or "doesn't" and then the script fetches the binary via rsync from a special directory on the server that has the git repo there. That way the user only needs to download the binaries he runs, and even then they'll be done incrementally via rsync magic. Thanks, Scott Ritchie

Oct. 18, 2011

Re: Regression testing breakthrough

by Damjan Jovanovic

On Tue, Oct 18, 2011 at 12:08 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 18 October 2011 10:45, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > (especially during "reverse regression testing"), users find it too long > and > > technical, and only a small minority of regressions are ever bisected. > And > Not true. Even for the regressions that are still open it's currently > 276 bisected vs. 99 not bisected, and Alexandre said about 90% of > opened regressions get fixed. > > There's currently another 182 regressions that were closed "ABANDONED". Maybe if regression testing was easier and faster, people wouldn't abandon them? > > I haven't figured out how to make the binaries available to users. Few > users > > can clone a 26 gigabyte repository, and even fewer places can serve that > > much to multiple users. Maybe Git can compress it further? The other idea > I > > had is that users should be able to regression test through a GUI tool. > > Maybe the GUI tool can just download and run the +/- 122 MB binary > snapshots > > for specific commits, instead of having the entire binary repository > > locally? > > > > Any other ideas? Would you like to see this tool? Can I send an > attachment > > with it? > > > Scripts for making old versions compile may be useful, but for the > most part it sounds like you're essentially duplicating ccache. > If you are talking about using compiling with ccache instead of the binary repository, "configure" alone is > 40 seconds, while the average "git bisect" on the binary repository is about 4. If you are talking about using ccache to speed up building the binary repository commit by commit, why, when for most commits "make" takes about 5 seconds and skips all unnecessary compilation anyway? The other advantage I see is the convenience: instead of having to wait or take breaks while each commit compiles like in normal regression testing, you can have the tool compile you a small set of revisions (eg. the last month) while you are away from your computer, then just quickly test them all in one go when you come back. And you can regression test several applications without repeatedly compiling Wine.

Oct. 18, 2011