Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.
On Thu, 25 Feb 2010, joerg-cyril.hoe...@t-systems.com wrote: Charles Davis wrote: I have noticed a change in configure behavior, though. Me too. On MacOS. Since 1.1.39, Makefiles are created at the rate of ~ 1 per sec. It was much faster in 1.1.38 and before, I estimate ~6 files per second. I think the point is that now most makefiles can be built in parallel with parallel make. So then it really depends how many cores you have of course. It does have weird side-effects. Like make distclean creating new makefiles and thus running 'make depend'! -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...
Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.
joerg-cyril.hoe...@t-systems.com wrote: Charles Davis wrote: I have noticed a change in configure behavior, though. Me too. On MacOS. Since 1.1.39, Makefiles are created at the rate of ~ 1 per sec. It was much faster in 1.1.38 and before, I estimate ~6 files per second. Anyone to confirm this? Yes, and makefiles are built all the way through the process. Very disturbing and not the way that I learned to use them. James McKenzie
Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.
On Thu, Feb 25, 2010 at 5:38 AM, joerg-cyril.hoe...@t-systems.com wrote: Charles Davis wrote: I have noticed a change in configure behavior, though. Me too. On MacOS. Since 1.1.39, Makefiles are created at the rate of ~ 1 per sec. It was much faster in 1.1.38 and before, I estimate ~6 files per second. Anyone to confirm this? ... Is this a reply to a different thread? Erich Hoover ehoo...@mines.edu
Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.
Erich Hoover wrote: On Thu, Feb 25, 2010 at 5:38 AM, joerg-cyril.hoe...@t-systems.com mailto:joerg-cyril.hoe...@t-systems.com wrote: Charles Davis wrote: I have noticed a change in configure behavior, though. Me too. On MacOS. Since 1.1.39, Makefiles are created at the rate of ~ 1 per sec. It was much faster in 1.1.38 and before, I estimate ~6 files per second. Anyone to confirm this? ... Is this a reply to a different thread? Should be. My mistake by replying to it. James McKenzie
Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.
Charles Davis wrote: I have noticed a change in configure behavior, though. Me too. On MacOS. Since 1.1.39, Makefiles are created at the rate of ~ 1 per sec. It was much faster in 1.1.38 and before, I estimate ~6 files per second. Anyone to confirm this? I always do git fetch; git rebase origin I never groked origin in git. I use N+1 trees: one only contains git, no checkout ever and I git fetch from winehq there. The N others come from git clone --local --shared -n /.../wine.git wine-bisect of this distinguished and read only git tree. That's where I compile, write patches, bisect, keep old versions etc. git fetch therein access only the local mirror. I can git-gc, git-fsck, git-rebase, rm -rf the N trees at will. After git-fetch, I use git-update-ref refs/heads/master remotes/origin/master Perhaps that's the equivalent of your git rebase origin? Now nested git rebase and bisect conflicts can berserk my working trees beyond recognition, I get out with rm -rf and still have the pristine 200MB source tree and don't need to download it again. IIRC: du source tree/.git ~200MB du cloned bisect tree/.git ~5MB du wine compiled tree ~400MB (incl. 5MB .git) du wine install tree ~100MB
Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer (try 2).
On 19 February 2010 05:22, Erich Hoover ehoo...@mines.edu wrote: Real Name: Erich Hoover Description: The attached patch adds a test for SetThreadAffinityMask(thread,-1), which succeeds on Windows Vista and newer. This version uses broken() rather than specifically testing versions. Note that this all processors flag is not documented, but was discovered tracking down another issue. Please see the wine-devel thread for more information: http://www.winehq.org/pipermail/wine-devel/2010-February/081879.html ChangeLog: kernel32/tests: Add test for 'all processors' flag on Vista and newer. Shouldn't this need tests for NtSetInformationThread() and NtQueryInformationThread() as well?
Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.
On Thu, Feb 18, 2010 at 8:51 PM, Erich Hoover ehoo...@mines.edu wrote: Real Name: Erich Hoover Description: The attached patch adds a test for SetThreadAffinityMask(thread,-1), which succeeds on Windows Vista and newer. This all processors flag is not documented, but was discovered tracking down another issue. Please see the wine-devel thread for more information: http://www.winehq.org/pipermail/wine-devel/2010-February/081879.html ChangeLog: kernel32/tests: Add test for 'all processors' flag on Vista and newer. The test shouldn't query the Windows version explicitly. Instead, the older return value on pre-Vista version should be denoted by the broken() macro.
Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.
On Thu, Feb 18, 2010 at 8:29 PM, Andrew Nguyen arethus...@gmail.com wrote: On Thu, Feb 18, 2010 at 8:51 PM, Erich Hoover ehoo...@mines.edu wrote: ... The attached patch adds a test for SetThreadAffinityMask(thread,-1), which succeeds on Windows Vista and newer. ... The test shouldn't query the Windows version explicitly. Instead, the older return value on pre-Vista version should be denoted by the broken() macro. Then the test could only be triggered in Wine. What if this feature gets removed again in some later version of Windows? Erich Hoover ehoo...@mines.edu
Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.
Then the test could only be triggered in Wine. What if this feature gets removed again in some later version of Windows? broken() only applies to Windows versions, Wine never succeeds with a broken feature. It really is what you want. --Juan
Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.
On Thu, Feb 18, 2010 at 8:45 PM, Juan Lang juan.l...@gmail.com wrote: Then the test could only be triggered in Wine. What if this feature gets removed again in some later version of Windows? broken() only applies to Windows versions, Wine never succeeds with a broken feature. It really is what you want. --Juan I'm not arguing with the behavior of broken(). I'm saying that since this feature is undocumented it's entirely possible that it could get removed in some future version of Windows*, so if we're not testing the version we wouldn't know that it got removed. We were lucky to stumble upon this thing in the first place, it's starting to look like it's not actually the issue responsible for the slowdown bug for which we are researching. Erich Hoover ehoo...@mines.edu * Though I doubt it, as this seems like a sneaky way to make people believe that their multi-threaded apps run slower on XP,
Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.
I'm not arguing with the behavior of broken(). I'm saying that since this feature is undocumented it's entirely possible that it could get removed in some future version of Windows*, so if we're not testing the version we wouldn't know that it got removed. We were lucky to stumble upon this thing in the first place, it's starting to look like it's not actually the issue responsible for the slowdown bug for which we are researching. Except that an app already depends on the newer behavior, so Microsoft would have to maintain a quirk for the app if they wanted to change the behavior. Since the hypothetical future version of Windows with changed behavior doesn't yet exist, addressing that case seems rather premature. --Juan
Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.
On Thu, Feb 18, 2010 at 8:59 PM, Juan Lang juan.l...@gmail.com wrote: I'm not arguing with the behavior of broken(). I'm saying that since this feature is undocumented it's entirely possible that it could get removed in some future version of Windows*, so if we're not testing the version we wouldn't know that it got removed. We were lucky to stumble upon this thing in the first place, it's starting to look like it's not actually the issue responsible for the slowdown bug for which we are researching. Except that an app already depends on the newer behavior, so Microsoft would have to maintain a quirk for the app if they wanted to change the behavior. Since the hypothetical future version of Windows with changed behavior doesn't yet exist, addressing that case seems rather premature. --Juan Point taken. Erich Hoover ehoo...@mines.edu
