Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.

[Francois Gouget]

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   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.

[James McKenzie]

Erich Hoover wrote:
> On Thu, Feb 25, 2010 at 5:38 AM,  > 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.

[Erich Hoover]

On Thu, Feb 25, 2010 at 5:38 AM,  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.

[James McKenzie]

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.

[Joerg-Cyril.Hoehle]

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

[PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.

[Joerg-Cyril.Hoehle]

Hi,

Erich Hoover wrote: >so if we're not testing
>the version we wouldn't know that it got removed.

This is a very valid point. For instance, I'm currently writing
a test that will read
ok(1234123123==mhdr.dwOffset || broken(0==mhdr.dwOffset/*w9x,nt*/) ...)
i.e. w2k+xp+Vista+7 differ from w95+98+me+nt.  The Wine testsuite will
not warn should MS-Windows ever revert back to w9x+nt behaviour.

I've been fixing multimedia bugs in Wine, some of which were present
for almost 10 years now.  My point is: right *now* I'm closely looking
at the exact behaviour under existing versions of MS-Windows (and
having Wine mimick "modern" w2k/xp behaviour), yet the broken()
mechanism prevents the tests from noticing when that behaviour will
change next time.

Patches these days make Wine implement the now "modern" behaviour, but
remember modern is relative and tests with broken() will fail to report
any future change...  Until, perhaps again in ten years, somebody will
look closely at the results, perhaps triggered by a bug report.
Why wait for a bug report?

Somehow, I feel that not noticing changes in behaviour is a waste of
the test automation resources.

broken() shadows broken (not valid any more) assumptions.

Every now and then I wish there were a switch to disable broken()
entirely and see what test.winehq reports for the various OS.
E.g. $WINETEST_STRICT=1 => have broken() always yield 0/false.

The goal to reach becomes WINETEST_STRICT=1 => no test failures on
the system Wine purports to mimick (currently XP(?)).
(Seems like a good idea, expect a patch soon ;)

Regards,
Jörg Höhle
Well, at least the above example of broken() is much stricter than
ok(!rc||broken(rc/*w9x*/)) == anything goes
What does such a test tell except impose Wine's rc?

Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer (try 2).

[Henri Verbeet]

On 19 February 2010 05:22, Erich Hoover  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.

[Erich Hoover]

On Thu, Feb 18, 2010 at 8:59 PM, Juan Lang  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

Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.

[Juan Lang]

> 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.

[Erich Hoover]

On Thu, Feb 18, 2010 at 8:45 PM, Juan Lang  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.

[Juan Lang]

> 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.

[Erich Hoover]

On Thu, Feb 18, 2010 at 8:29 PM, Andrew Nguyen  wrote:
> On Thu, Feb 18, 2010 at 8:51 PM, Erich Hoover  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.

[Andrew Nguyen]

On Thu, Feb 18, 2010 at 8:51 PM, Erich Hoover  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.