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

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?

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.

[James McKenzie]

[e-mail] 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

[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
[e-mail]

[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, <[e-mail]
> > 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

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

[Francois Gouget]

On Thu, 25 Feb 2010, [e-mail] 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'!