Re: vartest.c - major pain in the build process

2005-03-02 Thread Ferenc Wagner
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > "Ivan Leo Puoti" <[EMAIL PROTECTED]> wrote: > >>> In order to see what tests are affected by desktop visibility and which >>> don't >>> you have to run in both modes and compare the results. Why do it twice if it >>> can be avoided? Right now any f

Re: vartest.c - major pain in the build process

2005-03-02 Thread Dmitry Timoshkov
"Ivan Leo Puoti" <[EMAIL PROTECTED]> wrote: > > In order to see what tests are affected by desktop visibility and which > don't > > you have to run in both modes and compare the results. Why do it twice if it > > can be avoided? Right now any failure in the tests can be attributed to the > > de

Re: vartest.c - major pain in the build process

2005-03-02 Thread Ivan Leo Puoti
Dmitry Timoshkov wrote: > In order to see what tests are affected by desktop visibility and which don't you have to run in both modes and compare the results. Why do it twice if it can be avoided? Right now any failure in the tests can be attributed to the desktop visibility, and until it's fixed

Re: vartest.c - major pain in the build process

2005-03-01 Thread Dmitry Timoshkov
"Ivan Leo Puoti" <[EMAIL PROTECTED]> wrote: > > We can't really separate the tests, but still want the tests to show > > reasonable results in order to compare behaviour with Wine and to track > > the regressions. I don't see the point of publishing broken tests, and > > why running tests interact

Re: vartest.c - major pain in the build process

2005-03-01 Thread Ivan Leo Puoti
On Tue, 1 Mar 2005 08:29:00 +0800, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote: > "Jakob Eriksson" <[EMAIL PROTECTED]> wrote: > > > >I have to repeat again: Winword, Photoshop, Internet Explorer or any other > > >application I and most (if not all) developers and users are care about do > > >not >

Re: vartest.c - major pain in the build process

2005-03-01 Thread Jakob Eriksson
Dmitry Timoshkov wrote: "Ivan Leo Puoti" <[EMAIL PROTECTED]> wrote: We can just have winrash run in interactive mode. Once tests are ready to run, a message pops up saying "new tests available" or something of the sort, the user then chooses to run them now or later, like the windows automatic u

Re: vartest.c - major pain in the build process

2005-02-28 Thread Dmitry Timoshkov
"Jakob Eriksson" <[EMAIL PROTECTED]> wrote: > >I have to repeat again: Winword, Photoshop, Internet Explorer or any other > >application I and most (if not all) developers and users are care about do > >not > >run on an invisible desktop, therefore I don't care about tests running in > >that > >

Re: vartest.c - major pain in the build process

2005-02-28 Thread Ivan Leo Puoti
Dimitrie O. Paun wrote: Don't need to do that, there are plenty of tests that run fine with an invisible desktop, there's enough value in having some automated tests. Maybe we need to separate the results... I don't really care at all, I just think winrash should be kept and should be improved

Re: vartest.c - major pain in the build process

2005-02-28 Thread Dimitrie O. Paun
On Mon, Feb 28, 2005 at 01:10:25PM +0100, Ivan Leo Puoti wrote: > OK, then we can have winrash only run them in interactive mode, end of > story. Don't need to do that, there are plenty of tests that run fine with an invisible desktop, there's enough value in having some automated tests. Maybe we

Re: vartest.c - major pain in the build process

2005-02-28 Thread Ivan Leo Puoti
Dmitry Timoshkov wrote: "Ivan Leo Puoti" <[EMAIL PROTECTED]> wrote: We can just have winrash run in interactive mode. Once tests are ready to run, a message pops up saying "new tests available" or something of the sort, the user then chooses to run them now or later, like the windows automatic u

Re: vartest.c - major pain in the build process

2005-02-28 Thread Dmitry Timoshkov
"Ivan Leo Puoti" <[EMAIL PROTECTED]> wrote: > We can just have winrash run in interactive mode. Once tests are ready to > run, a message pops up > saying "new tests available" or something of the sort, the user then chooses > to run them now or > later, like the windows automatic updates. Like t

Re: vartest.c - major pain in the build process

2005-02-28 Thread Ivan Leo Puoti
Dmitry Timoshkov wrote: Why? What prevents someone to run the tests manually in interactive mode once a day? If that someone can't or won't do it, then we have to find another someone. I'm pretty sure that there are enough not lazy people wishing to help we could to choose from. We can just have wi

Re: vartest.c - major pain in the build process

2005-02-27 Thread Dmitry Timoshkov
"Ferenc Wagner" <[EMAIL PROTECTED]> wrote: > I was under the impression that most of the tests are > independent of desktop visibility. Not really. Any API which directly or indirectly creates windows or uses GDI is affected by the desktop visibility. Also, as I already pointed out, Wine doesn't

Re: vartest.c - major pain in the build process

2005-02-27 Thread Ferenc Wagner
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > I'd actually rise the question of sending the results of running winetest > on an invisible desktop under Windows. For instance I'm interested to see > how my recently added user32 tests behave on different Windows platforms, > but the tests which c

Re: vartest.c - major pain in the build process

2005-02-27 Thread Mike Hearn
On Sun, 27 Feb 2005 17:52:44 +0800, Dmitry Timoshkov wrote: > Alexandre already stated many times that there is no point to have > anything in the CVS tree if it's not compiled by default. A not used > code tends to be rotten very fast. Winetest is built though, as part of the nightly test winrash

Re: vartest.c - major pain in the build process

2005-02-27 Thread Dmitry Timoshkov
"Krzysztof Foltman" <[EMAIL PROTECTED]> wrote: > > Well, I'd argue that compilation time of full Wine tree is much longer > > than that single test. If you compile from source it's your choice. > > It's still an important percentage of the total compile time. And it's > not always possible to us

Re: vartest.c - major pain in the build process

2005-02-27 Thread Dmitry Timoshkov
"Jakob Eriksson" <[EMAIL PROTECTED]> wrote: > Also, that won't stop people from running winetest on linux, I'll bet > $5 winetest.exe downloads from WRT will keep showing up. I'd actually rise the question of sending the results of running winetest on an invisible desktop under Windows. For insta

Re: vartest.c - major pain in the build process

2005-02-26 Thread Krzysztof Foltman
Jakob Eriksson wrote: Also, that won't stop people from running winetest on linux, I'll bet $5 winetest.exe downloads from WRT will keep showing up. Yes. But should something that's useless for the majority of users and developers be enabled by default ? Looks like significant cost with little be

Re: vartest.c - major pain in the build process

2005-02-26 Thread Jakob Eriksson
Mike Hearn wrote: I disable winetest in my tree entirely, and have done for a long time. It should be disabled in CVS as well, nobody should be building winetest on Linux, it just encourages people to submit useless results by saying "oooh I wonder what happens if I do this". Worse this isn't just

Re: vartest.c - major pain in the build process

2005-02-26 Thread Mike Hearn
On Sat, 26 Feb 2005 15:56:56 +0100, Marcus Meissner wrote: > well, 25 minutes for a single file and 25 minutes for the rest of the tree? :) It doesn't take 25 minutes here, how much memory do you have? It takes more like 5, which is still excessive :( I disable winetest in my tree entirely, and h

Re: vartest.c - major pain in the build process

2005-02-26 Thread Marcus Meissner
On Sat, Feb 26, 2005 at 10:32:11PM +0800, Dmitry Timoshkov wrote: > "Krzysztof Foltman" <[EMAIL PROTECTED]> wrote: > > > Is there any reason for gcc 3.3.1 to spend several minutes on compiling > > dlls/oleaut32/tests/vartest.c ? > > > > I guess it can be explained by optimization stage going nut

Re: vartest.c - major pain in the build process

2005-02-26 Thread Dmitry Timoshkov
"Krzysztof Foltman" <[EMAIL PROTECTED]> wrote: > Is there any reason for gcc 3.3.1 to spend several minutes on compiling > dlls/oleaut32/tests/vartest.c ? > > I guess it can be explained by optimization stage going nuts on > compiling long functions with many branches (contained in the macros),

vartest.c - major pain in the build process

2005-02-26 Thread Krzysztof Foltman
Is there any reason for gcc 3.3.1 to spend several minutes on compiling dlls/oleaut32/tests/vartest.c ? I guess it can be explained by optimization stage going nuts on compiling long functions with many branches (contained in the macros), but there must be a way to speed this up. It's barely t